Internet-Draft | Ghost ACKs Mitigation | October 2024 |
Pan & Rossow | Expires 21 April 2025 | [Page] |
Historically, TCP as specified in RFC 793 was threatened
by the blind data injection attack because of the loose SEG.ACK value validation, where the SEG.ACK value of a
TCP segment is considered valid as long as it does not acknowledge data ahead of what has been sent.
RFC 5961 improved the input validation by
shrinking the range of acceptable SEG.ACK values in a TCP segment. Later, RFC 9293
incorporated 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 TCP segment containing
an SEG.ACK value acknowledging data that the endpoint has never sent. This document specifies small modifications to the
way TCP verifies incoming TCP segments' SEG.ACK value to prevent TCP from accepting such invalid SEG.ACK values.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 21 April 2025.¶
Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
TCP as specified in [RFC0793] is widely deployed in today's Internet.
Against the threat of the blind data injection attack, [RFC5961]
section 5 proposed to improve the validation of the SEG.ACK field of incoming TCP segments.
Currently, [RFC9293] is the latest main document for TCP, which obsoletes [RFC0793] and incorporates the SEG.ACK validation proposed by [RFC5961]
as an optional implementation choice.
The SEG.ACK validation introduced in [RFC9293] (with or without the [RFC5961] implementation choice)
accepts a certain range of SEG.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 SEG.ACK validation accepts segments with invalid SEG.ACK values that acknowledge data that an endpoint has never sent as "duplicate/old" SEG.ACK values (ghost ACKs).
This document aims to improve the SEG.ACK value validation
in [RFC9293],
such that TCP would only accept duplicate/old SEG.ACK values acknowledging data already sent by the endpoint, eliminating the security risks imposed by ghost ACKs.¶
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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
TCP terminology should be interpreted as described in [RFC9293].¶
As described in [RFC9293], when receiving a segment, the endpoint performs checks on the SEG.ACK field of the incoming segment. Suppose the TCP stack has implemented the mitigation for blind data injection attack proposed by Section 5 of [RFC5961], an incoming segment whose SEG.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 [RFC5961] mitigation is not implemented, an incoming segment with 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 231 - 1, and this can result in
accepting a segment with an SEG.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 SEG.ACK validation condition.¶
Ghost ACKs allow an attacker to inject payloads into a newly established connection. This extends the threat model as described in [RFC5961], 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 [SP2024Spoof].¶
TCP stacks MAY implement one of the following two mitigations. Both mitigation options assume [RFC5961] is already supported by the TCP stack.¶
TCP stacks that implement this mitigation SHOULD add the additional boolean state variable NO_ISS_CHECK for each established connection. This variable SHOULD be initialized to false. At the beginning of the SEG.ACK validation, it SHOULD be checked if the ISS is still needed:¶
if (!NO_ISS_CHECK && SND.UNA >= ISS + (65535 << Snd.Wind.Shift)) { /* Checking SEG.ACK against ISS is definitely redundant. */ NO_ISS_CHECK = true; }¶
Snd.Wind.Shift is defined in [RFC7323]. Then a local variable ACK.MIN SHOULD be computed, which is later used to validate the SEG.ACK. It is used to perform the validation, which is stricter.¶
if (NO_ISS_CHECK) { /* Check for too old ACKs (RFC 5961, Section 5.2). */ ACK.MIN = SND.UNA - MAX.SND.WND; } else { if (ISS + 1 > SND.UNA - MAX.SND.WND) { /* Checking for ghost ACKs is stricter. */ ACK.MIN = ISS + 1; } else { /* Checking for too old ACKs (RFC 5961, Section 5.2) is stricter. */ ACK.MIN = SND.UNA - MAX.SND.WND; } }¶
Finally the validation of SEG.ACK SHOULD be performed:¶
if (SEG.ACK < ACK.MIN) { send_challenge_ack; return; }¶
TCP stacks that implemented the [RFC4898] 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 SEG.ACK values of any incoming segments. Segments with ACK values satisfying the above condition are further validated and processed as specified in [RFC9293]. Otherwise, the segment MUST be discarded and a challenge ACK sent back. Though unlikely to happen, the 64-bit tcpEStatsAppHCThruOctetsAcked counter can overflow. An implementation has to deal with tcpEStatsAppHCThruOctetsAcked overflows.¶
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.¶