<?xml version="1.0" encoding="utf-8"?>
<?xml-model href="rfc7991bis.rnc"?> 

<!DOCTYPE rfc [
  <!ENTITY nbsp    "&#160;">
  <!ENTITY zwsp   "&#8203;">
  <!ENTITY nbhy   "&#8209;">
  <!ENTITY wj     "&#8288;">
]>

<rfc
  xmlns:xi="http://www.w3.org/2001/XInclude"
  category="std"
  docName="draft-ietf-tcpm-tcp-ghost-acks-01"
  ipr="trust200902"
  obsoletes=""
  updates=""
  submissionType="IETF"
  xml:lang="en"
  version="3">

  <front>
    <!-- <title abbrev="Abbreviated Title">Improving TCP handling of Out-of-Window Packets</title>  -->
    <title abbrev="Ghost ACKs Mitigation">Improve TCP Handling of Out-of-Window Packets to Mitigate Ghost ACKs</title>
    <seriesInfo name="Internet-Draft" value="draft-ietf-tcpm-tcp-ghost-acks-01"/> 
  
    <author fullname="Yepeng Pan" initials="Y." surname="Pan"> 
      <organization>CISPA Helmholtz Center for Information Security</organization>
      <address>
      <email>yepeng.pan@cispa.de</email>
      </address>
    </author>
    <author fullname="Christian Rossow" initials="C." surname="Rossow">
      <organization>CISPA Helmholtz Center for Information Security</organization>
      <address>
      <email>rossow@cispa.de</email>
      </address>
    </author>

    <date year="2024" month="10" day="18"/> 

    <area>Transport</area>
    <workgroup>TCPM</workgroup>
    <keyword>TCP</keyword>
    <keyword>TCPM</keyword>
    <keyword>transport layer</keyword>
    <keyword>internet transport</keyword>
    <!-- 
    I will not discuss the TCP TCP spoofing/injection attacks in detail,
    People could refer to RFC 5961 for the motivation of streghten acceptable ACK value validation.
    The aim of the RFC draft is thus: to prevent TCP from accepting invalid ACK values.
   -->
    <abstract pn="section-abstract">
      <t indent="0" pn="section-abstract-1">
        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.<br></br>

        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.
      </t>
    </abstract>
  </front>

  <middle>
    <section>
      <name>Introduction</name>
      <t>
        TCP as specified in <xref target="RFC0793"/> is widely deployed in today's Internet. 
        Against the threat of the blind data injection attack, <xref target="RFC5961"/> 
        section 5 proposed to improve the validation of the SEG.ACK field of incoming TCP segments.
        <!-- However, the ACK validation proposed by RFC 5961 fails for newly established TCP connections 
        where there is no data acknowledged previously by the peer (unless data is already sent during the handshake), 
        and thus duplicate/old ACK values shall not be accepted. -->
        Currently, <xref target="RFC9293"/> is the latest main document for TCP, which obsoletes <xref target="RFC0793"/> and incorporates the SEG.ACK validation proposed by <xref target="RFC5961"/>
        as an optional implementation choice.

        The SEG.ACK validation introduced in <xref target="RFC9293"/> (with or without the <xref target="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).
        <br></br>


        This document aims to improve the SEG.ACK value validation
        in <xref target="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.
      </t>
      
      <section anchor="Terminology">
      <!-- anchor is an optional attribute -->
        <name>Terminology</name>
        <t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
        "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>",
        "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
        "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
        "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
        be interpreted as described in
        BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when,
        they appear in all capitals, as shown here.</t>
        <t>TCP terminology should be interpreted as described in <xref target="RFC9293"/>. 
        </t>
      </section>
      <!-- The 'Requirements Language' section is optional -->
    </section>
    
    <section>
      <name>Ghost ACKs</name>
      <t>
      As described in <xref target="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 <xref target="RFC5961"/>, 
      an incoming segment whose SEG.ACK value satisfies the condition SND.UNA - MAX.SND.WND =&lt; SEG.ACK =&lt; SND.NXT is considered acceptable,
      and the segment is further processed.
      
      When the <xref target="RFC5961"/> mitigation is not implemented, an incoming segment with SEG.ACK =&lt; SND.NXT is accepted and further processed.
      </t>

      <t>
      <!-- However, for a newly established TCP connection, assuming there is no data transferred during the handshake, 
      there is SND.UNA == SND.NXT == ISS + 1.
      However, in this case, the above acceptable ACK value condition also accepts ACK vlues before ISS+1, 
      which represents data that the endpoint has never sent. -->

      <!-- 
        I decide to avoid discussing early data tranmission in handshake phase. 
        In the end, the accpetable ACK conditions introduced in the following section should apply to the early data case.
        The early data should only affect the SND.UNA initial value discussion here.
      -->

      However, there are cases where the number of bytes sent by the endpoint is less than MAX.SND.WND or 2<sup>31</sup> - 1, and this can result in
      accepting a segment with an SEG.ACK value acknowledging bytes the endpoint has never sent.<br/>

      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 &lt; 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.



    </t>
    </section>


    <section>
      <name>Security Implications of Ghost ACKs</name>

      <t>
        Ghost ACKs allow an attacker to inject payloads into a newly established connection.
        This extends the threat model as described in <xref target="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 <xref target="SP2024Spoof" format="default" sectionFormat="of" derivedContent="1"/>.
      </t>

    </section>

    <section>
      <name>Mitigation</name>
      <t>
      TCP stacks <bcp14>MAY</bcp14> implement one of the following two mitigations.
      Both mitigation options assume <xref target="RFC5961"/> is already supported by the TCP stack.
      </t>
      <!--  I'm planning to give two choices, one from *bsd one from linux

      1. One could save the ISS number and a wraparound flag. 
      Before wraparound, check whether the ISS+1 is larger than incoming segment's ACK value.

      2. Another option is to save the number of bytes acknowledged by peer. 
      only accept ACK value within SND.UNA - min(MAX.SND.WND,bytes_acked) =< SEG.ACK =< SND.NXT

      -->
      <section>

        <!-- <name>Mitigation Option 1 (assumes <xref target="RFC5961"/> support)</name> -->
        <name>Mitigation Option 1 (generic)</name>
          <t>TCP stacks that implement this mitigation <bcp14>SHOULD</bcp14> add
          the additional boolean state variable NO_ISS_CHECK for each
          established connection.
          This variable <bcp14>SHOULD</bcp14> be initialized to false.
          At the beginning of the SEG.ACK validation, it <bcp14>SHOULD</bcp14>
          be checked if the ISS is still needed:</t>
          <sourcecode>
          if (!NO_ISS_CHECK &amp;&amp; SND.UNA >= ISS + (65535 &lt;&lt; Snd.Wind.Shift)) {
              /* Checking SEG.ACK against ISS is definitely redundant. */
              NO_ISS_CHECK = true;
          }
          </sourcecode>
          <t>Snd.Wind.Shift is defined in <xref target="RFC7323"/>.
          Then a local variable ACK.MIN <bcp14>SHOULD</bcp14> be computed,
          which is later used to validate the SEG.ACK.
          It is used to perform the validation, which is stricter.</t>
          <sourcecode>
          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;
              }
          }
          </sourcecode>
          <t>Finally the validation of SEG.ACK <bcp14>SHOULD</bcp14> be
          performed:</t>
          <sourcecode>
          if (SEG.ACK &lt; ACK.MIN) {
          	send_challenge_ack;
          	return;
          }
          </sourcecode>
      </section>

      <section>
        <name>Mitigation Option 2 (assumes <xref target="RFC4898"/> support)</name>
          <t>
            TCP stacks that implemented the <xref target="RFC4898"/> tcpEStatsAppHCThruOctetsAcked statistics, which tracks the number of bytes that are already acknowledged by the peer, can adopt this option.</t>
            <t>To implement this mitigation, TCP stacks <bcp14>MUST</bcp14> add the SND.UNA - min(MAX.SND.WND, tcpEStatsAppHCThruOctetsAcked) =&lt; 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 <xref target="RFC9293"/>.
            Otherwise, the segment <bcp14>MUST</bcp14> 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.


            <!-- For TCP stacks that do not implement the <xref target="RFC5961"/> SEG.ACK validation, MAX.SND.WND should be replaced with 2<sup>31</sup> - 1. -->
          </t>
      </section>

    </section>


    
  </middle>

  <back>
    <references>
      <name>References</name>
      <references>
        <name>Normative References</name>
        
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.0793.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4898.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5961.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7323.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9293.xml"/>

      </references>
 
      <references>
        <name>Informative References</name>             
          <reference anchor="SP2024Spoof" target="https://doi.ieeecomputersociety.org/10.1109/SP54263.2024.00182">
            <front>
              <title>TCP Spoofing: Reliable Payload Transmission Past the Spoofed TCP Handshake</title>
              <author initials="Y." surname="Pan" fullname="Y. Pan"></author>
              <author initials="C." surname="Rossow" fullname="C. Rossow"></author>
              <date year="2024" month="may"></date>
            </front>
            <seriesInfo name="DOI" value="10.1109/SP54263.2024.00182"></seriesInfo>
          </reference>
      </references>
    </references>
    
    <!-- <section>
      <name>Appendix 1</name>
      <t>This becomes an Appendix</t>
    </section> -->

    <section anchor="Acknowledgements" numbered="false">
      <!-- an Acknowledgements section is optional -->
      <name>Acknowledgements</name>
      <t>This template uses extracts from templates written by Pekka Savola, Elwyn Davies and 
        Henrik Levkowetz.</t>
      <t>We thank Eric Dumazet for proposing the second mitigation option using tcpEStatsAppHCThruOctetsAcked.</t>
      <!-- Maybe I should also add an acknowledgment for *BSD developers, they provide one possible implementation for the 1nd mitigation option in *BSD systems' netfilter -->
    </section>
    
    <!-- <section anchor="Contributors" numbered="false">
      
      <name>Contributors</name>
      <t>Thanks to all of the contributors.</t>
      <contact fullname="Jane Doe" initials="J" surname="Doe">
        
        <organization>Acme</organization>
        <address>
          <email>jdoe@example.com</email>
        </address>
      </contact>
    </section> -->
    
 </back>
</rfc>
