Architecture for
a Hardware-based, TCP/IP Content-Processing System
A new architecture
performs content scanning of TCP flows in high-speed networks.
Combining a TCP processing engine, a per-flow state store
and a content-scanning engine, this architecture permits
complete payload inspections on 8 million TCP flows at
2.5Gbps.
Abstract. The
Transmission Control Protocol is the workhorse protocol
of the Internet. Most of the data passing through the Internet
transits the network using TCP layered atop the Internet
Protocol (IP). Monitoring, capturing, filtering, and blocking
traffic on highspeed Internet links requires the ability
to directly process TCP packets in hardware. Because TCP
is a stream-oriented protocol that operates above an unreliable
datagram network, there are complexities in reconstructing
the underlying data flow.
High-speed network intrusion
detection and prevention systems guard against several types
of threats. When used in backbone networks, these content-
scanning systems must not inhibit network throughput. Gilder’s
law predicts that the need for bandwidth will grow at least
three times as fast as computing power.1 As the gap between
network bandwidth and computing power widens, improved microelectronic
architectures are needed to monitor and filter network traffic
without limiting throughput. To address these issues, we’ve
designed a hardwarebased TCP/IP content-processing system
that supports content scanning and flow blocking for millions
of flows at gigabit line rates.
TCP
Splitter. The TCP splitter technology was previously
developed to monitor TCP data streams, sending a consistent
byte stream of data to a client application for every TCP
data flow passing through the circuit. The TCP splitter
accomplishes this task by tracking the TCP sequence number
along with the current flow state. Out-of-order packets
are dropped to ensure that the client application receives
the full TCP data stream without the need for large stream
reassembly buffers.
Dropping packets to maintain
an ordered packet flow throughout the network can adversely
affect the network’s overall throughput. Jaiswal et
al. analyzed out-of-sequence packets in tier-1 IP backbones.
They noted that approximately 95 percent of all TCP packets
on Internet backbone links were in proper sequence. Network-induced
packet reordering accounted for a small fraction of out-of-sequence
packets, with most resulting from retransmissions due to
data loss. More than 86 percent of all observed TCP flows
contained no out-of-sequence packets.
|
