Tunnel under security and network packet brokers
Tunneling and transmission of traffic to monitoring and information security systems
GTP, GRE, L2TP, PPPoE, VXLAN and other tunnel acronyms are familiar to any network engineer. Tunneling traffic allows you to:
- Provide data flow control by building a network at the 3rd level of the OSI model
- Link remote offices into a single network with shared resources
- Simplify network administration by separating infrastructure and user layers
- Build unified networks based on various technologies
- Provide user mobility (mobile networks, migration of virtual machines in data centers)
But the use of tunnels imposes additional requirements in terms of ensuring information security.
Most of the information security systems and monitoring systems work with a copy of the traffic. At the same time, data transfer from the infrastructure is provided in one of three ways:
- Packets are duplicated by additional network equipment functions and sent to dedicated (SPAN) ports
- Passive traffic taps (TAP) are installed in the optical line, dividing the optical power into two lines – the original recipient and the DPI system
- A network packet broker is added to the infrastructure, which performs the function of packet mirroring, as in the case of TAP – the original recipient and the DPI system
As we wrote earlier, in modern infrastructure, SPAN ports are practically not used: they do not provide either the required bandwidth or guarantee of data transfer. Tunnels only exacerbate the problem: the criteria for transmission to the monitoring port can only be the outer header fields (tunnel header), and thus pre-filtering by user packet fields (nested headers) becomes impossible.
The most commonly used combination of passive optical couplers and network packet brokers.
TAPs ensure network reliability is maintained, while network packet brokers ensure correct data transfer to DPI systems and optimize their use. However, when using tunneling, this is possible only in one case – if the network packet broker supports analysis of tunnel structures and can distribute traffic based on the nested headers of the tunneled traffic packets.
Filtering and classification of tunneled traffic
Without the ability of the broker to analyze the nested headers of the tunneled packets by the broker, it makes no sense to talk about DPI optimization. Filtering and classification, allowing to reduce the load on DPI systems and reduce their number, should work precisely on the fields of user traffic (nested headers). Otherwise, it is impossible to separate the IP addresses of specific users, the required protocols or encrypted traffic – it will just be a tunnel by the external fields. An attempt to cleanse traffic to DPI systems from non-targeted traffic in external fields will only create a “security hole” – targeted traffic will “slip past” information security and monitoring in the tunnel.
As a result, in the absence of the analysis function by nested headers, to ensure security or quality monitoring, all traffic must be directed to the analysis systems. Buy new servers and licenses for additional performance, rent space for server rooms and hire additional employees who will serve this park.
Tunneling traffic balancing
The problem of balancing tunneled traffic is even more multifaceted. Firstly, when distributing user packets between different tunnels (in mobile networks, when redundant with load balancing, or simply when transmitting a forward and reverse flow through different tunnels), it is impossible to ensure the integrity of user exchange sessions without analyzing the nested headers.
Let’s take 2 sessions (AB-VA and CD-DC) and transmit them through the tunneled channels T1, T2 and T3. Let’s say we are talking about subscribers of a mobile operator walking between base stations. The packets of these sessions will be in different tunnels and when tunneled traffic hits the network packet broker, there are 2 options for balancing them while maintaining the integrity of the sessions:
- Balancing by external headers. In fact, the network packet broker will split different tunnels between DPI systems: T1 and T3 in DPI 1, and T2 in DPI 2. At the same time, the request packets (AB) of the AB-BA information flow, encapsulated in the T1 and T2 tunnels to ensure the subscriber’s mobility, end up in different DPI systems, and response packets (BAs) in tunnels T2 and T3, respectively, will get into DPI 1 and DPI 2. A similar situation will happen with the CD-DC information stream. Most DPI systems require all traffic data to function correctly. By decapsulating traffic, each DPI system will see “scraps” of information exchange, consider it not to be processed (as failed), or will process it incorrectly. This balancing may be interesting for monitoring the state of individual sections of the infrastructure (when in fact all packets of a given tunnel should come to the analysis system), but for this, filtering is usually used.
- Balancing on nested headers. The network packet broker for balancing ignores external headers and distributes packets between DPI systems while maintaining the integrity of the AB-BA and CD-DC sessions. At the same time, to monitor the state of individual sections of the infrastructure, you can configure filtering by external headers. Thus, each DPI engine will receive an entire stream of user traffic, and monitoring tools will receive all the packets of a given tunnel.
The second problem of balancing tunneled traffic is the uneven loading of tunnels. When monitoring highly loaded channels with a small number of tunnels, there is a problem of uneven load and packet loss due to an excess of the output port performance.
That is, if sessions AB and CD of 10 Gbps each are encapsulated in a T1 tunnel, then 20 Gbps traffic is obtained (which can be transmitted over the 40GbE / 100GbE interface or through 10GbE LAG aggregated links). After copying and getting this stream into the network packet broker, it becomes necessary to unbalance this traffic for several DPI systems over 10 GbE interfaces. It is impossible to do this while maintaining the integrity of sessions using external headers – the stream will exceed the bandwidth of the output interface and packets will start to be lost.
Balancing on nested headers provides the ability to split the stream into smaller ones without compromising the integrity of information exchange and the quality of DPI systems.
Balancing fragmented tunneled traffic
A separate balancing issue is traffic fragmentation caused by tunneling: the addition of tunnel headers leads to exceeding MTU and packet fragmentation.
When a packet with a size equal to the MTU arrives at the input of the tunneling device, then after adding the tunnel headers, the packet begins to exceed the MTU (by the number of bytes of the tunnel header) and is divided into fragments. Moreover, the nested header is contained only in the first fragment. As a result, two packets of the same session (AB1 and AB2) that got into different tunnels (T1 with XY header and T2 with XZ header) turn into four packets:
- with an external XY header and a nested AB header
- with external XY header without tunneling signs
- with an external XZ header and a nested AB header
- with external XZ header without tunneling signs
In this case, without the fragment tracking function, the choice will be between the violation of the integrity of the information stream due to the distribution of different tunnels between different DPI systems and the violation of the integrity of the information stream due to the distribution of different fragments between different DPI systems. Tracking chunks balanced against nested headers ensures integrity is maintained even in such cases.
Those who have encountered these problems in a large part of the traffic understand them and solve them. As usual, the worst thing is when the problem affects less than 10% of the traffic – it can be invisible and the illusion is created that everything is safe. And under the security is the tunnel.
