SPAN-aggregation and packet brokers. Protocol Stripping

Why you may need protocol stripping function?

As you know there are 7 OSI model levels. Each one adds some particular volume header to the packet. 

Linux "show mac-address-table" analogue

Few days ago I could see a user question about Linux analogue for Cisco "show mac-address-table" command. He wo'nt use the "arp"or "arp -a" command for some hidden reasons. And I think it may be interesting for other users.

Routing and ACL direction

Sometimes I can see questions related to the ACL directions needed for the traffic filtering on the network equipment.

Let's suppose a case when PC is located in the network 10.0.10.0/24 and DNS server - in the 10.0.20.0/24 one. See the picture.

Does DNS use TCP or UDP? RFC says...

Usually we mean DNS uses UDP port 53 but TCP port 53 is reserved for DNS too.
After some time the one question may become interesting for any specialist working with information technologies or information security:

When does DNS use UDP or TCP?

Answer is provided by  RFC5966, section 4. Transport Protocol Selection, where you may find such statements:

Most DNS [RFC1034] transactions take place over UDP [RFC0768].  TCP
[RFC0793] is always used for zone transfers and is often used for
messages whose sizes exceed the DNS protocol's original 512-byte
limit.

So, every request except zone transfer (query type AXFR) and the large message (more than 512 bytes) containing one is processed by UDP.
One can ask: "Why AXFR and large messages must use TCP?". The reason is ability to use UDP-based services with large responses for DDoS-attacks.

All general-purpose DNS implementations MUST support both UDP and TCP
transport.

It means that each DNS-server implementation must support both transport protocols.

Some more particular cases are described in the RFC5966 too:

Authoritative server implementations MUST support TCP so that they
do not limit the size of responses to what fits in a single UDP
packet.

So, authoritative server holds zone must support TCP. For zone transfer purposes at least.

Recursive server (or forwarder) implementations MUST support TCP
so that they do not prevent large responses from a TCP-capable
server from reaching its TCP-capable clients.

Recursive server must support TCP to have an ability to forward large response received by TCP to client using the same TCP protocol for source IP spoofing prevention.

Stub resolver implementations (e.g., an operating system's DNS
resolution library) MUST support TCP since to do otherwise would
limit their interoperability with their own clients and with
upstream servers. 

Stub resolver is a small and stupid recursive server used for minimal clients quantity serving. For example it is a SOHO router. It serves some client devices and forwards their requests to upper servers.

Stub resolver implementations MAY omit support for TCP when
specifically designed for deployment in restricted environments where
truncation can never occur or where truncated DNS responses are
acceptable.

One can see that RFC gives some indulgence for SOHO devices vendors to decrease its' load in the environment where large DNS responses are unbelievable or harmless.

And as a finale we can see protocols usage sequence:

A resolver SHOULD send a UDP
query first, but MAY elect to send a TCP query instead if it has good
reason to expect the response would be truncated if it were sent over
UDP (with or without EDNS0) or for other operational reasons, in
particular, if it already has an open TCP connection to the server.

So, (small and stupid) recursive server must try to use UDP for DNS-request but in the case of high truncated response possibility or if the TCP session exists (e.g. serving another request) it may use TCP.

Desktop virtualization. Historical review :)

It was Ancient Computer Sparta. Every computer had to pass survival of the fittest on the PC manufacturing plant. If some PC was sick and ill it was exposed to the hillside. A survived one became thin client...

SPAN-aggregation and packet brokers. Packets deduplication

One can ask: is it real to be so stupid implementing TAPs and brokers that packets are duplicated? Yes, of course, and it doesn't indicate architects' stupidity. E.g. we need the datacenter traffic analysis. So, it is necessary to mirror datacenter uplinks (no matter Internet or corporate) to have an incoming/outgoing traffic visibility, and aggregation/service layer links according to the datacenter network design. Inbound/outbound packet has no duplicates if it is going to some segment connected via dedicated physical lines, no router/firewall on a stick etc.

Let's assume some network part on the picture 1. TAPs mirror traffic to aggregators and then it is sent to information security systems. Users' connections path to servers is going through at least 2 TAPs copying traffic to the aggregator. As a result security sensors receive much more traffic for analysis.

  

Picture 1. Network fragment.

This issue may be addressed using the packet deduplication function shown below. If SPAN-aggregator is able to do it without false positives or negatives then information security systems efficiency may increase a lot.


Picture 2. Packet deduplication explanation.

 So it is packet deduplication feature in brief.