<?xml version="1.0" encoding="UTF-8"?>
<!-- edited with XMLSPY v5 rel. 3 U (http://www.xmlspy.com)
     by Daniel M Kohn (private) -->

<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
    <!ENTITY rfc2119 PUBLIC '' 
      'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml'>
]>

<rfc category="exp" ipr="trust200902" docName="draft-nishida-tcpm-disabling-paws-00">

<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>

<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes"?>
<?rfc iprnotified="no" ?>
<?rfc strict="yes" ?>

   <front>
   <title abbrev="Disabling PAWS">
              Disabling PAWS When Other Protections Are Available 
   </title>

    <author initials='Y.N' surname="Nishida" fullname='Yoshifumi Nishida'> 
      <organization> GE Global Research </organization>
      <address><postal> <street>2623 Camino Ramon</street>
        <city>San Ramon</city> <region>CA </region><code>94583</code>
        <country>USA</country>
        </postal>
        <email>nishida@wide.ad.jp</email>
      </address>
    </author>

   <date/>
   <abstract>
   <t>
     PAWS provides protection against old duplicated segments caused by wrapped sequence
     or earlier incarnated connections. One drawback of PAWS is that it requires to place timestamp
     option in all segments, which consumes 10-12 bytes in the option space of TCP.
     In addition, since PAWS just checks if timestamps is older or not, the protection logic is not
     very strong against malicious attacks or cannot work properly in some situations.
     On the other hand, some other technologies which can provide stronger protections than
     PAWS are becoming available these days.
     In this document, we propose to utilize other protection mechanisms as replacements of
     PAWS when they are available.
   </t>
   </abstract>
</front>

<middle>
<section title="Introduction">
<t>
   PAWS (Protect Against Wrapped Sequences) defined in <xref target="RFC7323" /> is
   a technique that can identify old duplicate segments in a TCP connection or segments 
   from earlier incarnated connections.    
   PAWS utilizes timestamp option in TCP segments. When both TCP endpoints agree to use PAWS,
   all segments belong to this connection will have the options, which consumes 10-12 bytes
   of 40 bytes option space.
   As recent TCP connections use option space for other TCP extensions such
   as <xref target="RFC2018" />,  <xref target="RFC5925" /> and <xref target="RFC6824"/>,  
   this feature tends to be considered as expensive these days.
</t>
<t>
   Timestamp option is also used for RTTM (Round Trip Time Measurement).
   Gathering many RTT samples from the timestamp in every TCP segment may look useful approach to 
   improve RTO estimations. However, some research results shows taking a few timestamps per RTT
   can be sufficient <xref target="MALLMAN99" />. Also, some TCP implementations 
   record the transmission time of each packet. In this case, timestamp option is not necessary
   to measure RTTs. 
</t>
<t>
   The basic idea of PAWS is that a received segment is considered as an old duplicate
   if the timestamp in it is less than the timestamps recently received on a connection. 
   The timestamp values used in PAWS is 32-bit unsigned integers. Hence, when PAWS 
   compares two timestamp values: t1, t2, it regards t2 as "newer than t1" 
   if 0 &lt; (t2 - t1) &lt; 2^31, otherwise t2 is considered as "older than t1". 
   This logic presumes timestamp is monotonically increased across connections, however, 
   it can be confused in some cases such as where multiple nodes are behind the same NAT.
   In addition, if malicious attackers try to cheat the PAWS logic with random timestamp values,
   there will be 50% of chance for success on each try. This basically means PAWS can hardly 
   contribute to securing TCP connections.
   On the other hand, several technologies which can be utilized for the same purpose
   are becoming available.
</t>
<t>
   Based on these observations, we propose to utilize other mechanisms as replacements
   of PAWS when it is possible. The goal of the proposal in the draft is to provide
   stronger protections for old duplicated segments while facilitating the use of TCP option
   space by suppressing timestamp options. Another benefit of the proposal is that
   it can contribute to facilitating recycling of TCP connections in TIME_WAIT stat, which
   will be useful for busy servers.
</t>
</section>

<section title="Conventions and Terminology">
   <t>
  The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
  "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
  document are to be interpreted as described in <xref target="RFC2119"/>.
   </t>
</section>

<section title="Possible Mechanisms AS Replacements of PAWS">
<t>
   In this section, we present several possible mechanisms that can be used as replacements of PAWS.
   When these mechanisms are available and are activated in a TCP connection, 
   PAWS can be disabled as it will be redundant.
   In order to disable PAWS protection, a simple signaling mechanism will 
   be needed as this will require agreement on both ends.
   We discuss how to utilize these mechanisms and how to disable PAWS safely below.
</t>

<section title="TCP Increased Security (tcpinc)" anchor="tcpinc">
  <t>
  Currently, TCP extensions that can provide unauthenticated 
  encryption and integrity protection to TCP streams have been actively discussed in
  IETF <xref target="TCPINC" />.
  As these proposed extensions is based on encryption algorithms, old duplicated segments in the
  same connection or segments from early connections with the same 4 tuples will easily 
  be identified. In addition, it will be harder for malicious attacks to cheat
  this protections. To utilize this feature as a replacement of PAWS, we propose to
  update the encryption negotiation option (TCP-ENO) <xref target="I-D.ietf-tcpinc-tcpeno" /> 
  by using 1 bit of global suboption in initial suboption byte.
  This bit indicates that the end point supports disabling PAWS.
  After endpoints confirm that both ends support disabling PAWS and encryption
  negotiation has been successful, they will disable PAWS and will use timestamp options
  only for RTTM. However, in case TCP-ENO has failed or either side does not support
  disabling PAWS, PAWS MUST NOT be disabled if the use of TS option is negotiated.
  </t>
</section>
<section title="Multipath TCP" anchor="mptcp">
  <t>
  Multipath TCP <xref target="RFC6824" /> can also be used for a replacement of PAWS.
  Multipath TCP maintains 64 bits sequence number space in the session and use DSS
  (Data Sequence Signal) option for this purpose in addition to the sequence number
  field in the TCP header. This DSS option can be served to provide the same protections
  as PAWS. By checking Data sequence number is DSS option, it can identify old duplicated
  segments. Because the data sequence number in the option should be exactly matched with the
  number stored in the session, MPTCP can provide stronger protection than PAWS.
  One way to signal disabling PAWS information is to use MP_EXPERIMENTAL option defined
  in <xref target="I-D.ietf-mptcp-rfc6824bis" /> during initial connection setup.
  Or, using 'B' bit in MP_CAPABLE option and extend MP_CAPABLE option to convey the info.
  Another requirement for disabling PAWS in an MPTCP session is that DSS mapping should be
  put in all data segments in the session. In case an MPTCP session falls back to TCP during SYN
  negotiation or either side does not support disabling PAWS, PAWS MUST not be disabled
  if the use of TS option is negotiated.
  
  </t>
</section>
<section title="TLS" anchor="tls">
  <t>
  When TLS <xref target="RFC5246" /> is used for a TCP connection, old duplicated
  segments can be identified as segments in the connection are protected by encryption algorithms.
  One difficulty for using TLS as a replacement of PAWS is that it will be hard for
  TCP layer to know whether TLS is used or not. One possible way is to presume
  the use of TLS from port numbers (e.g. 443). Or, providing APIs to signal TCP 
  layer can be another way although this will require to update applications.
  In addition, TCP needs to check if the other end supports disabling PAWS. In order for this,
  we will need to define a new TCP option in order to be used during SYN exchange.
  Another possibility is to utilize timestamp values in SYN segments in order to encode
  the feature negotiation information. An example of using timestamp value in SYN segments for feature
  negotiation is described in <xref target="I-D.scheffenegger-tcpm-timestamp-negotiation" />.
  When either side does not support disabling PAWS, PAWS MUST not be disabled
  if the use of TS option is negotiated.
  </t>
</section>
</section>

<section title="Duplicates from Earlier Connection Incarnations" anchor="reusesss">
 <t>
   As described in <xref target="RFC7323" />, the main purpose of PAWS is to protect
   against old duplicates from the same connection. In addition, it is expected to
   provide additional security against old duplicates from earlier connections.
   Although this feature is not strongly encouraged in the RFC, some implementations support it.
   We believe the protection described above can be used for this purpose as well.
   By using encryption logics or extended sequence number space, they can distinguish between the
   packets from the current connection and the packets from earlier connections.
   The protections will even be stronger than the protection PAWS can provide.
   We believe the replacements of PAWS will also be able to facilitate recycling the connections in TIME_WAIT.
   For example, it was reported some implementations replaced the connections in TIME_WAIT by
   a new incoming connection with the same 4 tuples when its timestamp is newer than the one
   in TIME_WAIT. However, this logic will not work properly when multiple clients behind NAT or
   when a node doesn't maintain global timestamp offset across all TCP connections.
   On the other hand, when a TCP connection can utilize the protections described above,
   it can recycle the connection in TIME_WAIT with more robust algorithms.
 </t>
</section>

<section title="Security Considerations">
 <t>
 TBD
 </t>
</section>

<section title="IANA Considerations">
<t>
This document may uses the Experimental Option Experiment Identifier defined in <xref target="RFC6994" />.
In this case, an application for this codepoint in the IANA TCP Experimental Option ExID registry will be submitted.
</t>
</section>

</middle>

<back>
<references title='Normative References'> 
	  <?rfc include="reference.RFC.2119" ?> 
	  <?rfc include="reference.RFC.7323" ?>
  	  <?rfc include="reference.RFC.6824" ?>
    	  <?rfc include="reference.RFC.5246" ?>
          <?rfc include="reference.I-D.ietf-tcpinc-tcpeno.xml"?>
          <?rfc include="reference.I-D.ietf-mptcp-rfc6824bis.xml"?>
</references>
<references title='Informative References'>
  <?rfc include="reference.RFC.2018" ?>
  <?rfc include="reference.RFC.5925" ?>
  <?rfc include="reference.RFC.6994" ?>
  <?rfc include="reference.I-D.draft-scheffenegger-tcpm-timestamp-negotiation-05" ?>
  
  <reference anchor="MALLMAN99" target="">
   <front>
    <title> On Estimating End-to-End Network Path Properties </title>
    <author initials="M." surname="Allman" fullname="">   <organization />  </author>
    <author initials="V." surname="Paxson" fullname="">   </author>
      <date month="September" year="1999" />
   </front>
   <seriesInfo name="Proceedings of the ACM SIGCOMM" value="" />
  </reference>

  <reference anchor="TCPINC">
    <front>
      <title>The TCPINC Working Group, https://datatracker.ietf.org/wg/tcpinc/documents/
      </title>
      <author>
	<organization>The IETF</organization>
      </author>
      <date year="2014" />
    </front>
  </reference>

  
</references>
</back>

</rfc>
