Protocol-level TCP attacks¶
Attack pattern¶
TCP was built to survive a flaky network, not a hostile one. Its reliability machinery, the three-way handshake, sequence and acknowledgement numbers, windows and timers, all assume the other end is honest and the packets in between untampered. Attacks at this level work that assumption directly: guess or forge the numbers to inject into or reset a connection, exhaust the state a router must hold for every session, or lean on an extension the stack still supports. BGP feels it because a BGP session is just one long-lived TCP connection carrying the routing table.
1. Protocol-level TCP attacks [OR]
1.1 Connection hijacking [AND]
1.1.1 Off-path sequence number prediction
1.1.1.1 Exploit poor initial sequence number generation
1.1.1.2 Analyse timestamp-based sequence number leaks
1.1.1.3 Predict sequence numbers through statistical analysis
1.1.1.4 Capitalise on low entropy in random number generation
1.1.2 Malicious packet injection
1.1.2.1 RST spoofing to terminate BGP sessions
1.1.2.2 FIN spoofing for covert session termination
1.1.2.3 Data injection into established BGP sessions
1.1.2.4 Crafted packet injection to corrupt BGP state
1.2 Amplification/reflection attacks [OR]
1.2.1 TCP middlebox reflection
1.2.1.1 Exploit stateful firewall behaviour
1.2.1.2 Abuse load balancer TCP handling
1.2.1.3 Utilise proxy server amplification
1.2.1.4 Reflect through misconfigured network devices
1.2.2 ACK/PSH flood abuse
1.2.2.1 Generate high-volume ACK storms
1.2.2.2 Abuse push flag to force processing
1.2.2.3 Consume router CPU with packet processing
1.2.2.4 Trigger resource exhaustion on target systems
1.2.3 BGP update reflection/amplification
1.2.3.1 Spoof BGP update source addresses
1.2.3.2 Amplify route advertisements through reflection
1.2.3.3 Cause routing churn through reflected updates
1.2.3.4 Exploit BGP's path vector protocol characteristics
1.3 Resource exhaustion attacks [OR]
1.3.1 TCP state table exhaustion
1.3.1.1 Create numerous half-open connections
1.3.1.2 Maintain persistent connection attempts
1.3.1.3 Exploit maximum connection limits
1.3.1.4 Target BGP session establishment resources
1.3.2 Buffer manipulation attacks
1.3.2.1 Force excessive buffer allocation
1.3.2.2 Exploit TCP window size advertising
1.3.2.3 Cause buffer bloat conditions
1.3.2.4 Trigger memory exhaustion through crafted packets
1.4 Protocol manipulation attacks [OR]
1.4.1 TCP option exploitation
1.4.1.1 Craft malicious TCP option fields
1.4.1.2 Exploit option processing vulnerabilities
1.4.1.3 Cause parser failures through invalid options
1.4.1.4 Abuse timestamp options for sequence prediction
1.4.2 Flow control mechanism abuse
1.4.2.1 Manipulate window size advertisements
1.4.2.2 Exploit congestion control algorithms
1.4.2.3 Cause throughput degradation
1.4.2.4 Trigger retransmission storms
1.5 Timing and side-channel attacks [OR]
1.5.1 Timing analysis attacks
1.5.1.1 Measure packet processing times
1.5.1.2 Infer network congestion state
1.5.1.3 Detect sequence number validation timing
1.5.1.4 Exploit timing differences in packet processing
1.5.2 Side-channel information leakage
1.5.2.1 Extract information through behavioural analysis
1.5.2.2 Infer internal state through response patterns
1.5.2.3 Exploit implementation-specific characteristics
1.5.2.4 Gather intelligence for targeted attacks
Built for a friendlier network¶
TCP’s own design carries weaknesses that predate any thought of an adversary.
Stacks differ, and each implementation has its own flaws in sequence-number generation, option handling and behaviour under load.
Behaviour is predictable: sequence numbers, timers and responses follow patterns an attacker can study.
Devices have finite room for connection state, and exhausting it is one of the surer ways to drop a session.
Holding TCP state is expensive and intricate, and intricate state is where bugs live.
Every extension still supported for interoperability widens the surface.
Backward compatibility keeps old, weak features in the code because something, somewhere, still needs them.