Network Packet Brokers (NPBs) have come a long way from their modest roots as data monitoring switches, though their intended application remains nearly the same. The NPB is still primarily used as a device to maximize the performance of monitoring and security tools. The NPB’s most important features remain unchanged, these includes, 1:1, 1:N, N:1, and N:N port mappings, full L2-L4 filtering options, and configurable load balancing options. In the pursuit of gaining a competitive advantage, vendors continue to add advanced features. This adds complexity in selecting the right product for your network. The key to selecting the right product is the understanding of each advanced feature and its alternatives. Looking at Deduplication, SSL/TLS decryption, and Netflow generation are a good place to start.
This is the second blog in a three-part series highlighting the Network Packet Broker. Check out the other blogs here:
Deduplication is a feature offered by many NPB vendors, which provides a mechanism for removing identical packets in a defined “window” of time. The exact implementation of this feature varies from vendor to vendor but essentially all packets coming into a port supporting deduplication will be sent to an internal FPGA/Packet processor. A hash value is created and temporarily stored, the size of the storage block defines the deduplication window. As new packets come into the system, the new hash value is compared to the already stored hash values of the preceding packets. If the hash values match, then the packet is deemed to be a duplicate and immediately discarded. Additional mechanisms can be in place to check against false positives.
Duplicate packets can occur in any monitoring network, but most of these duplicates come from using SPAN ports. Typically, SPAN ports mirror both ingress and egress ports or can be configured to Mirror traffic on a given VLAN. This can result in > 50% of duplicate traffic feeding your monitoring network. These duplicates can be addressed at the source of the problem by moving away from SPAN ports in favor of well placed Network TAPs. Network TAPs significantly reduce the number of duplicate packets. There will still be some duplicate packets but network engineers need to look at the sensitivity of their monitoring tools to decide if the remaining duplicates need to be removed, and if deduplication is still a necessary feature.
Industry experts are predicting SSL/TLS traffic to exceed 70% of all network traffic by the end of 2019. So, is this feature important? Absolutely, but a decision needs to be made whether or not this should be done within the NPB or sent out to an external platform dedicated to SSL decryption/encryption. The technical details of SSL decryption is beyond the scope of this blog, but at a high level any secure connection starts with a handshake process. During the handshake the client and server agree on an encryption key and which cypher to use during the session. After the handshake both endpoints have a symmetric key, and all subsequent transmissions are encrypted.
The NPB or SSL visibility appliance act as either active or passive man-in-the middle (MITH). For passive MITM the NPB needs to contain all server’s private keys. For active MITM, a SSL connection is made from the client to the NPB and from the NPB to the server. Active MITM is more commonly used, especially as we move towards TLS 1.3. Regardless of active or passive MITH, SSL/TLS decryption, along with the required data masking, is extremely computationally expensive. Using an NPB as a network’s only means of TLS decryption may not be the best choice. The very nature of TLS decryption can degrade the performance of the device as a whole, so caution needs to be taken in using SSL decryption in an NPB. A dedicated SSL visibility appliance seems to be the safer choice in any network, allowing for scalability, high-availability deployment, and line-rate performance without compromising other features.
Metadata generation is an interesting topic as it relates to monitoring and visibility. Visibility fabrics constantly aim to see all traffic traversing a network and metadata generation opposes that. Under the names Netflow, S-Flow, or IPFIX, metadata generation provides sampled summary statistics of network traffic flows. Flow details generally include information on the 5-tuple, protocol information and insights in the application layer. If a network’s tools are flow based then the ability to generate these flows becomes critical. The choice of Netflow, S-flow, or IPFIX is completely dependent on the network and the tools that are planned for deployment.
As vendors continue to grow the feature set of the NPB, careful considerations need to be taken when making a purchasing decision. Network engineers need to decide if they prefer one device that that can perform these features at a satisfactory level or multiple devices that perform their targeted task at the highest performance. Their are obviously pros and cons to each approach but based on the success of companies making highly targeted, high performance devices, one can deduce that using the decentralized approach may be the better choice in the long run.