Network TAP versus SPAN/Mirror Port
Monitoring, analysis and out-of-band security tools all have one thing in common: they need a reliable data source from which to obtain network data, and they depend on this source to function. But what is the best way to feed the network data to these tools?
Many believe that they can simply configure a SPAN port, also called a mirror port, on existing switches to route out the network data. Depending on the configuration, a copy of the network data running through the switch is then output on this port.
Others prefer to use Network TAPs (TAP stands for Test Access Point or Test Access Port), i.e. special devices that are looped into a network line and that send out a copy of the network data sent over this line from the productive network.
Which of these two options one should choose and the reasons for doing so will be examined in more detail on the following pages.
2. How a SPAN/Mirror port works
To know the advantages and disadvantages of a SPAN port, one must first understand how it works.
The concept itself is very simple. After the user has defined a free port on a switch as a SPAN port, incoming data packets are duplicated accordingly by the switch’s operating system and output as a duplicate on that SPAN port.
At the same time, the SPAN port loses its function as a switch port, as all incoming packets are discarded by the switch.
3. How a Network TAP works
Unlike a SPAN port, which has to create the duplicates in software, a Network TAP works on OSI Layer 1, i.e. signal level, by means of a dedicated FPGA.
But beware! Really every TAP? Not at all! Please note that in the following we refer to a Network TAP which, like our PacketRaven models, relies on a corresponding FPGA chipset.
To date, the term TAP is neither protected nor standardised. Some manufacturers continue to use regular switches with their Network TAPs and offer the TAP functionality by means of a fixed SPAN session. To these and similar approaches, the following advantages that a TAP can bring do NOT apply, of course!
A TAP is typically placed between 2 network devices and the connection of these two network devices is looped through network ports A and B. Thus, the TAP sits transparently in the line to be monitored and, insofar as it is an FPGA-based TAP, can duplicate all packets exchanged by the network devices at the signal level.
This is also an important difference to the SPAN port, which due to its mode of operation can only duplicate valid Ethernet packets during processing, but a TAP picks up the data at the lowest OSI layer and will always and in principle make all exchanged information available to the connected system. As long as it is an Ethernet packet, it will be duplicated, no matter what size it is and how many tunnels or encapsulations there are. Even defective packets that a switch discards without exception are duplicated without loss while maintaining data integrity.
4. Configuration effort and risk of misconfiguration
As noted above, a SPAN port must be manually selected and defined. For this, of course, a free port is needed first, which is to output the duplicated data from the system. Depending on the scenario, this alone can already lead to the first problems, as free ports on switches are sometimes in short supply, depending on the environment.
The user must also be clear about exactly which connections he wants to monitor, as a switch can only duplicate packets on the input side; data leaving the switch can no longer be accessed/duplicated by the software.
However, a large part of the risk of a SPAN port is the risk of incorrect configuration. Since a SPAN port does not process incoming data and tries to discard it completely, a misconfiguration can lead to the administrator locking himself out of the system if he accidentally defines the only port with the MGMT IP as a SPAN port.
An important asset in package analysis is the order of the packages themselves! For example, if the data arrives in your monitoring in the wrong order, it can no longer make any evaluations. Since the switch has to “touch” each packet, figuratively speaking, there is always room for incorrect handling of the packets, justified among other things by the best-effort principle, which we will deal with separately below.
A wrong sequence is therefore not uncommon in heavily utilised networks. But not only the order itself can be affected, the so-called timing of the data, ensured by the Inter Frame Gap (IFG), can also change, making the accuracy of any analysis questionable.
However, even if none of the above side effects occur, temporally accurate measurements with a SPAN port are difficult to achieve, simply because of the added latency (Figure 3.) to the duplicated data. While an FPGA-based network TAP may add an additional latency in the single-digit nanosecond range to the duplicated data, such a statement cannot even be made for switches, as we are many factors higher here and can also be subject to enormous fluctuations.
Another risk of misconfiguration is the danger of duplicate packets. Here, too, it can happen very quickly that incorrectly made configurations on the SPAN session and the resulting duplicate data records can cause an overbooking of your SPAN port or even of your connected solution itself.
Here is an example (Figure 4.) using a VLAN-based SPAN session: If you want to output the data of VLAN 100 and VLAN 200 on a SPAN port, the switch will output the data it receives with VLAN 100 on the SPAN port and then output the same data, but this time stamped with VLAN 200, also on the SPAN port. The result is then duplicate packets in the direction of your monitoring system.
The use of the parameter “Both” when setting up a SPAN session can also provoke such behaviour. “Both” here refers to the send and receive direction of the transmitted data, in combination with a VLAN the switch will accordingly duplicate all data that enters the VLAN and those that leaves it again, here too duplicate packets are the result, which will be visible on your monitoring system.
Up to this point, we have only talked about possible errors in the software-side setup of the switch. However, the physical component should not be ignored. If a SPAN session has been set up for certain ports, but a colleague/employee, either unknowingly whether the SPAN session or for other reasons, simply hangs up the devices to be monitored on another port, you will lose all monitoring as long as the SPAN session has not been adjusted accordingly. Patching devices to other ports can quickly lead to the loss of important network transparency.
5. Visibility in the network
A Network TAP is, as already mentioned, always and basically 100% invisible in the network due to its FPGA-based construction! Since it operates on OSI layer 1, it also has no MAC or IP address and cannot be hacked or compromised.
To be fair, however, it should be noted that a SPAN port is also invisible on the network, but not immune to attacks. The switch itself offers great attack surfaces for intruders who have ways and means to put a SPAN port out of operation, this is impossible with a Network TAP.
So while a TAP is always invisible and unassailable, a SPAN port is also invisible per se, but not unassailable.
6. Risk of compromise
A TAP does not offer any kind of attack surface for any kind of compromise, it can neither be recognised nor hacked, which is not even possible due to its FPGA design.
A SPAN port itself does not offer any attack surface, but the operating system of the switch, which is also responsible for duplicating and providing the data for the SPAN port, does!
Checking and installing regular updates on the switch is an absolute must here, depending on the environment!
A Network TAP neither offers the mentioned attack surface nor does it need any updates.
7. Potential oversubscription
The danger of oversubscripting the SPAN port is imminent. A SPAN port has several limitations in terms of throughput, one of which is, of course, the maximum theoretical bandwidth of the port, which is theoretically 1000 Mbit/s for a link negotiation with 1000Base-T. The SPAN port is also limited in terms of throughput. However, this value is difficult to achieve because the “source” of the data is a software component of the system that has to do the duplication in addition to its regular task of switching.
But how exactly can you oversubscribe a SPAN port? If you look again at how exactly a SPAN port is set up, you will see that it can happen very quickly that you add too many source ports to the SPAN session and this then exceeds the maximum bandwidth of the SPAN port.
Here is an example: 2 servers and 4 clients are connected to a switch. If you want to read and evaluate all data exchanged between server and clients, all 6 ports are added to the SPAN session. You might now think that it is enough to monitor the 2 ports with the connected server.
One of the disadvantages of a SPAN session is that only incoming packets are duplicated, not outgoing packets.
If you want to do a full-duplex analysis of the traffic between clients and servers, the clients must also be included in the SPAN session and thus also all data traffic of the clients that is not intended for the servers, since a switch cannot make a distinction here.
Thus, the sum of the duplicated packets can very quickly exceed the theoretical bandwidth of a SPAN port, not to mention the actual bandwidth of that port, which is limited by the switch’s software. The result is that not all data packets are sent to your connected solution.
A Network TAP can also help here! A TAP always works with the maximum theoretical bandwidth and can never be overbooked, even microbursts, no matter what size, are processed regularly and output as duplicates, the only limitation is the network itself!
8. Best-effort principle and high network load
This brings us directly to the next problem which, depending on the point of view, is also deliberate! The primary task of a switch is switching, for which the device was developed, produced and ultimately also purchased by the customer.
The possibility of setting up a SPAN session is only an additional extra provided by the manufacturers. This is accompanied by the so-called best-effort principle, which ensures that in the event of a high network load, regular operation and thus switching always and at all times has priority over other possible tasks of the switch, such as the generation of Netflow data or a SPAN session.
This property, which all switches have in common, could be exploited by a potential attacker by artificially creating a high load on the network and thus forcing the switch to be unable to duplicate packets for the SPAN session because it is too busy with its basic work. The best-effort principle thus allows the switch to give the SPAN session a low priority.
A Network TAP, on the other hand, has none of these restrictions. It is not subject to a best-effort principle, nor does it allow itself to be upset by a high network load; the FPGA ensures that all signals are always duplicated at all times. It is important to clarify once again that a TAP works at signal level and not at MAC or even IP level, it therefore has no concept for best-effort or the like, all signals are processed at full line rate without bottlenecks.
9. Completeness of the transmitted data
Here, too, we can directly follow on from the point made above and talk about another important issue, namely the completeness of the data. In summary, it can be said that this is not always the case, precisely because of the best-effort principle already mentioned, under which the SPAN port operates.
Unfortunately, there are no counters or memories that cache or at least count the unduplicated packets. This quickly leads to the conclusion that a SPAN port is not a reliable data source for your monitoring, let alone your security installation.
It should therefore already be possible to see that a Network TAP, precisely because of the absence of any disadvantages of a SPAN port, guarantees the completeness as well as the integrity of the data at all times!
10. Integrity of the transmitted data
Especially with regard to security and perhaps even possible cyber insurance, data integrity is of incontrovertible importance!
The magic words here are “usability in court”. Unfortunately, a SPAN port can never deliver data of this quality, since, for example, any VLANs that the switch stamps on outgoing data packets cannot be duplicated.
Thus, important information is lost and the software-based duplication of the data does the rest in terms of possible manipulation of the data.
It can therefore never really be ensured that the duplicated data is an exact copy of the actual network traffic.
11. Uni directional data diode design on the productive network
The Network TAP is again ahead in this point: Not only does a switch possibly cause higher latencies in the network due to an activated SPAN session, but blocking incoming data at the SPAN port is also a software-side function.
An open security hole, an unapplied patch or similar could allow an attacker to gain access to the switch and thus to your network via a compromised monitoring system.
All this is impossible with a TAP, as it relies on a number of security features, some of which are of a purely physical nature. One of these is the data diode function (Figure 9.), which is common to all our electrified TAPs. Data that the monitoring system sends back to the TAP is either not even passed through to the FPGA due to galvanic isolation.
In the case of our hybrid TAPs, the return of data via the monitoring ports to the network ports fails due to the optical-electrical-optical conversion, which again prevents a return effect into the network by means of physically non-wired components.
With pure fibre optic TAPs we can also implement such uni directional data diode design by means of special splitters (Figure 8.).
In virtual environments, so-called virtual SPAN/Mirror ports are used analogous to the physical network world. For this purpose we offer Virtual TAPs (vTAPs). However, the advantages of these TAPs differ from their physical relatives and will be explained in more detail in another white paper from us shortly.
It remains to be said: Tapping network traffic via a Network TAP has many advantages over routing it out via a SPAN port. Network TAPs are the only reliable data source that guarantee you 100% transparency, visibility and security in the network!
We would be happy to advise you on our various PacketRaven Network TAPs and their features, as well as on your individual requirements. You can find our contact details below!