]> CISPA Helmholtz Center for Information Security

yepeng.pan@cispa.de

CISPA Helmholtz Center for Information Security

rossow@cispa.de

Transport TCPM TCP TCPM transport layer internet transport Historically, TCP as specified in RFC 793 was threatened by the blind data injection attack because of the loose acceptable ACK value validation, where the ACK value of a data segment is considered valid as long as it does not acknowledge data ahead of the next segment to send. RFC 5961 improved the defect by shrinking the range of acceptable ACK values in a data segment. Later, RFC 9293 involved the updates proposed by RFC 5961 as a TCP stack implementation option.

However, an endpoint that follows the RFC 9293 specifications can still accept a data segment containing an ACK value acknowledging data that the endpoint has never sent. This document specifies small modifications to the way TCP verifies incoming data segments' ACK value to prevent TCP from accepting invalid ACK values.

Introduction TCP as specified in is widely deployed in today's Internet. Against the threat of the blind data injection attack, section 5 proposed to improve the validation of data segments with duplicate/old ACK values. Currently, is the latest main document for TCP, which obsoletes and involves the ACK validation proposed by as an optional implementation choice. ACK validation introduced in (with or without the implementation choice) accepts a certain range of ACK values before SND.UNA as duplicate/old ACK values. This also applies to connections without data (or with little data) transferred previously. Consequently, current ACK validation accepts segments with invalid ACK values that acknowledge data that a server has never sent as "duplicate/old" ACK values (ghost ACKs).

This document aims to improve the ACK value validation in , such that TCP would only accept duplicate/old ACK values acknowledging data already sent by the endpoint, eliminating the security risks imposed by ghost ACKs.

Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here. TCP terminology should be interpreted as described in .

Ghost ACKs As described in , when receiving a segment, the endpoint performs checks on the ACK field of the incoming segment. Suppose the TCP stack has implemented the mitigation for blind data injection attack proposed by Section 5 of , an incoming segment whose ACK value satisfies the condition SND.UNA - MAX.SND.WND =< SEG.ACK =< SND.NXT is considered acceptable, and the segment is further processed. When the mitigation is not implemented, an incoming segment with SND.UNA - (2³¹ - 1) =< SEG.ACK =< SND.NXT is accepted and further processed. However, there are cases where the number of bytes sent by the endpoint is less than MAX.SND.WND or 2³¹ - 1, and this can result in accepting a segment with an ACK value acknowledging bytes the endpoint has never sent.
As a concrete example, consider a newly established TCP connection without data transferred during the handshake. There is SND.UNA == SND.NXT == ISS + 1. In this case, any segments with SEG.ACK < SND.UNA acknowledges bytes that the endpoint has never sent, but they are still considered acceptable since they satisfy the above ACK validation condition.

Security Implications of Ghost ACKs Ghost ACKs allow an attacker to inject payloads into a newly established connection. This extends the threat model as described in , where an off-path attacker can perform injection attacks against an existing foreign connection. Ghost ACKs further allow attackers that spoof the TCP handshake to use the spoofed TCP connection and transmit payloads .

Mitigation TCP stacks MAY implement one of the following two mitigations.

Mitigation Option 1 (generic):

TCP stacks that implement this mitigation MUST add an additional state variable for each established connection, ISS_CHECK_NOT_REQUIRED. When validating the ACK value of any incoming segments, TCP stacks that implement this mitigation MUST add an additional input check ISS_CHECK_NOT_REQUIRED || SND.UNA =< SEG.ACK || ISS + 1 =< SEG.ACK. The first part of the condition checks if the ISS comparison is required, more details regarding the ISS_CHECK_NOT_REQUIRED state follow later. When ISS comparison is required, the second part of the condition verifies if the segment acknowledges unacknowledged data (no ghost ACKs by definition). If not, the last part of the condition verifies whether the segment's ACK value is after ISS, which guarantees no ghost ACKs are accepted. Segments with ACK values satisfying the above condition are further validated and processed as specified in . Otherwise, the incoming segment MUST be discarded and a challenge ACK sent back.

When a connection is initialized, ISS_CHECK_NOT_REQUIRED is set to false. Once the SND.UNA satisfies condition SND.UNA != ISS && ISS + 1 =< SND.UNA - (2³¹-1), ISS_CHECK_NOT_REQUIRED is set to true. When the current send window meets the above condition, any acceptable old ACK values are after ISS, and thus no ghost ACKs by definition. In this case, the original specification is enough to validate the ACK value.

Mitigation Option 2 (assumes support)

TCP stacks that implemented the tcpEStatsAppHCThruOctetsAcked statistics, which tracks the number of bytes that are already acknowledged by the peer, can adopt this option.

To implement this mitigation, TCP stacks MUST add the SND.UNA - min(MAX.SND.WND, tcpEStatsAppHCThruOctetsAcked) =< SEG.ACK input checks for ACK values of any incoming segments. Segments with ACK values satisfying the above condition are further validated and processed as specified in . Otherwise, the segment MUST be discarded and an ACK sent back. For TCP stacks that do not implement the ACK validation, MAX.SND.WND should be replaced with 2³¹ - 1.

References Normative References Informative References

Acknowledgements This template uses extracts from templates written by Pekka Savola, Elwyn Davies and Henrik Levkowetz. We thank Eric Dumazet for proposing the second mitigation option using tcpEStatsAppHCThruOctetsAcked.