Vulnerability Issues in TCP

NISCC Vulnerability Advisory 236929

Vulnerability Issues in TCP

What is Affected?

The vulnerability described in this advisory affects implementations of the Transmission Control Protocol (TCP) that comply with the Internet Engineering Task Force’s (IETF’s) Requests For Comments (RFCs) for TCP, including RFC 793, the original specification, and RFC 1323, TCP Extensions for High Performance.



The impact of this vulnerability varies by vendor and application, but in some deployment scenarios it is rated critical.


The Border Gateway Protocol (BGP) is judged to be potentially most affected by this vulnerability.



The issue described in this advisory is the practicability of resetting an established TCP connection by sending suitable TCP packets with the RST (Reset) or SYN (Synchronise) flags set.

The packets need to have source and destination IP addresses that match the established connection as well as the same source and destination TCP ports.

The fact that TCP sessions can be reset by sending suitable RST and SYN packets is a design feature of TCP according to RFC 793, but a reset attack is only possible at all because the source IP address and TCP port can be forged or “spoofed”.

Although denial of service using crafted TCP packets is a well known weakness of TCP, until recently it was believed that a successful denial of service attack was not achievable in practice. The reason for this is that the receiving TCP implementation checks the sequence number of the RST or SYN packet, which is a 32 bit number, giving a probability of 1/2^32 of guessing the sequence number correctly (assuming a random distribution).

The discoverer of the practicability of the RST attack was Paul A. Watson, who describes his research in his paper “Slipping In The Window: TCP Reset Attacks”, presented at the CanSecWest 2004 conference. He noticed that the probability of guessing an acceptable sequence number is much higher than 1/2^32 because the receiving TCP implementation will accept any sequence number in a certain range (or “window”) of the expected sequence number. The window makes TCP reset attacks practicable.

Any application protocol which relies on long term TCP connections and for which the source and destination IP addresses and TCP ports are known or can be easily guessed will be vulnerable to at least denial of service attacks.



The following mitigation steps are still being evaluated and may be incomplete. Customers should work with vendors for the workaround most appropriate for the product in question.

In the absence of vendor patching of the TCP implementation, the following are general mitigating steps:

Implement IP Security (IPSEC) which will encrypt traffic at the network layer, so TCP information will not be visible
Reduce the TCP window size (although this could increase traffic loss and subsequent retransmission)
Do not publish TCP source port information



Please refer to the Vendor Information section of this advisory for implementation specific remediation.

Some vendors will have reduced the likelihood of successful denial of service by amending the TCP implementation to issue a further acknowledgment packet challenge for RST and SYN packets that do not have exactly the expected sequence number.

The Internet Engineering Task Force (IETF) has published an Internet Draft to co-incide with the release of this advisory. The text of this draft is available from the IETF web site:

NISCC has produced best practice guidelines for BGP available at Filtering Guide.pdf

Secure configuration templates for BGP implementations on Cisco IOS and Juniper JUNOS can be found at:

• Cisco
• Juniper

Guidance on tuning of the IP stack for a number of different UNIX operating systems is available at

(omitted below)

Similar Posts:

Comments 2