One document matched: draft-nishida-tcpm-apaws-01.xml

<?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-apaws-01">

<?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="Alternative PAWS">
               A-PAWS: Alternative Approach for PAWS 
   </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>
   This documents describe a technique called A-PAWS which can provide protection against 
   old duplicates segments like PAWS. While PAWS requires TCP to set timestamp options in all 
   segments in a TCP connection, A-PAWS supports the same feature without using timestamps. 
   A-PAWS is designed to be used complementary with PAWS. TCP needs to use PAWS when it is 
   necessary and activates A-PAWS only when it is safe to use. 
   Without impairing the reliability and the robustness of TCP, A-PAWS can provide more 
   option space to other TCP extensions.
   </t>
   </abstract>
</front>

<middle>
<section title="Introduction">
<t>
   PAWS (Protect Against Wrapped Sequences) defined in <xref target="RFC1323" /> is
   a technique that can identify old duplicate segments in a TCP connection. 
   An old duplicate segment can be generated when it has been delayed by queueing, etc.
   If such a segment has the sequence number which falls within the receiver's current window, 
   the receiver will accept it without any warning or error. 
   However, this segment can be a segment created by an old connection that has the same port 
   and address pair, or a segments sent 2**32 bytes earlier on the same connection. 
   Although this situation rarely happens, it impairs the reliability of TCP. 
</t>
<t>
   PAWS utilizes timestamp option in <xref target="RFC1323" /> to provide protection
   against this. It is assumed that every received TCP segment contains a timestamp. 
   PAWS can identify old duplicate segments by comparing the timestamp in the received segments and 
   the timestamps from other segments received recently. If both TCP endpoints agree to use PAWS,
   all segments belong to this connection should have timestamp. 
   Since PAWS is the only standardized protection against old duplicate segments, 
   it has been implemented and used in most TCP implementations. 
   However, as some TCP extensions such as <xref target="RFC2018" />, 
   <xref target="RFC5925" /> and <xref target="RFC6824"/> also requires 
   a certain amount of option space in non-SYN segments, using 10-12 bytes length in option
   space for timestamp in all segments tends to be considered expensive in recent discussions. 
</t>    
<t>
   In addition, although PAWS is necessary for connections which transmit more than 2**32 bytes,
   it is not very important for other connections since <xref target="RFC0793" /> already has protection against
   segments from old connections by using timers. Moreover, some research results indicates that
   most of TCP flows tend to transmit small amount of data, which means only small fraction of 
   TCP connections really need PAWS <xref target="QIAN11" />. 
   Timestamp option is also used for RTTM (Round Trip Time Measurement) in <xref target="RFC1323" />.
   Gathering many RTT samples from the timestamp in every TCP segment looks useful approach to 
   improve RTO estimation. However, some research results shows the number of samples per RTT 
   does not affect the effectiveness of the RTO <xref target="MALLMAN99" />. 
   Hence, we can think if PAWS is not used, sending a few timestamps per RTT will be sufficient.
</t>
<t>
   Based on these observations, we propose a new technique called A-PAWS which can archive similar protection 
   against old duplicates segments. The basic idea of A-PAWS is to attain the same protection against old 
   all duplicate segments as PAWS while reducing the use of TS options in segments.
   A-PAWS is designed to be used complementary with PAWS. This means an implementation that 
   supports A-PAWS is still required to supports PAWS. A-PAWS is activated only when it is safe to use. 
   This sounds the applicability of A-PAWS is limited, however, we believe TCP will have a lot of
   chances to save the option space if it uses A-PAWS. 
</t>
<t>
   There are some discussions that PAWS can also be used to enhance security, 
   however, we still believe that A-PAWS can maintain the same level of security as PAWS.
   Detailed discussions on this point are provided in <xref target="sec_discussion" />.
   A-PAWS is an experimental idea yet, but we hope it will contribute to facilitating the use of TCP 
   option space.
</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="The A-PAWS Design">
<t>   
A-PAWS assumes PAWS as it is designed to be used complementary with PAWS. 
Hence, a node which supports A-PAWS MUST support PAWS. 
The following mechanisms are required in TCP in order to perform A-PAWS.
</t>

<section title="Signaling Method" anchor="signaling">
<t> 
A-PAWS requires a signaling mechanism to enable this feature as it employs different logics 
from <xref target="RFC2119"/> to process TS options. A-PAWS presumes the use of PAWS. 
Hence, if TS option is not negotiated during SYN exchanges, A-PAWS MUST NOT be activated. 
An important point for A-PAWS is that it does not require synchronized signaling between senders and receivers.
In <xref target="table_1"/> illustrates possible combinations for PAWS and A-PAWS. It should be noted that 
when receiver employs A-PAWS, it does not matter if sender uses PAWS or A-PAWS (case 2 and case 4). 
This allows us to use less synchronized signaling mechanisms described in the following sections. 
However, we must avoid the situation where the sender activates A-PAWS while the receiver uses PAWS (case 3). 
</t>

<texttable anchor="table_1" title="Possible Combinations for PAWS and A-PAWS">
    <ttcol align='center'>case #</ttcol>
    <ttcol align='center'>Sender</ttcol>
    <ttcol align='center'>Receiver</ttcol>
    <ttcol align='center'> </ttcol>
    <c>1</c>
    <c>PAWS</c>
    <c>PAWS</c>
    <c>Work</c>
    <c>2</c>
    <c>PAWS</c>
    <c>A-PAWS</c>
    <c>Work</c>
    <c>3</c>
    <c>A-PAWS</c>
    <c>PAWS</c>
    <c>Doesn't work</c>
    <c>4</c>
    <c>A-PAWS</c>
    <c>A-PAWS</c>
    <c>Work</c>
</texttable>

<t>
Based on these requirements, the followings are possible approach for A-PAWS signaling.

<list style="hanging" hangIndent="4">
<t hangText="1) Option Exchange in SYN"><vspace />
This method requires using new codepoint for TCP option and exchange them during SYN negotiation.
The use of <xref target="RFC6994" /> 
is recommended. Since A-PAWS negotiation is 1 bit information (on or off),
new option does not need to have any content. Hence, if 16-bit EXID is used, the option size for A-PAWS 
can be kept in 4 bytes length. 
In this signaling method, when an endpoint does not find A-PAWS option in received SYN or SYN-ACK segment, 
it MUST not send segments with A-PAWS logic in <xref target="sender_logic"/>. 
However, it MUST activate A-PAWS receiver logic in <xref target="receiver_logic"/>
if it has sent A-PAWS option in the SYN packet. This is because some middleboxes may remove A-PAWS option 
in SYN-ACK. 
Although this is a straightforward approach, it requires additional option space in SYN segments.
</t>
<t hangText="2) Timestamp Field Negotiation in SYN" ><vspace />
This method is based on timestamp field negotiation proposed in 
<xref target="I-D.scheffenegger-tcpm-timestamp-negotiation" />.
The draft proposes to utilize timestamp values in SYN segments in order to negotiate 
additional capabilities for timestamps. The advantage of this approach is that it does not require extra option space 
(hence new codepoint, either) for this, although detailed mechanisms are still under discussion. 
However, we will need some mechanisms to avoid case 3 in <xref target="table_1"/>.
</t>
<t hangText="3) Option Exchange in non-SYN Segments"><vspace />
This method uses new codepoint for TCP option, however, the options are not used during SYN negotiation.
Just like option exchange in SYN segments, when a endpoint sets A-PAWS option in the segments, 
it indicates that it can receive the segments from A-PAWS senders. Hence, it MUST activate 
A-PAWS receiver logic in <xref target="receiver_logic"/> if it sends the options. 
However, it MUST not send segments with A-PAWS logic in <xref target="sender_logic"/> until it receives 
A-PAWS options. This approach does not require extra option space or special timestamp value in SYN segments.
However, negotiating features in non-SYN segments will require to address further arguments 
such as when to send the options or how to retransmits the options. We will discuss these points in the next section.
</t>
</list>
</t> 
</section>
<section title="Negotiating Features Using non-SYN segments" anchor="non_syn_nego">
<t>
As explained in <xref target="signaling"/>, A-PAWS will explore a signaling method that utilizes non-SYN segments.
If robust and reliable signaling mechanisms are necessary, we will probably need to invent another three-way 
handshake like mechanisms that use non-SYN segments. This will require drastic changes in the current TCP semantics.
Instead, in case of A-PAWS, we can use a relatively simple and easy mechanism for feature negotiation. 
One important characteristic for A-PAWS is the signaling mechanism does not require tight synchronization between endpoints.
This is because A-PAWS receivers can interact with both A-PAWS senders and PAWS senders. 
Hence, we can use a less reliable method for A-PAWS signaling. For example, when an endpoint sends A-PAWS option 
and the other endpoint does not send back A-PAWS option, we are not very sure if the other endpoint disabled the feature
or a middlebox in the forward or the return path removed the option. However, A-PAWS endpoints are not confused 
in these cases by using the following two rules. 
<list style="empty">
<t>Rule 1: An endpoint MUST activate A-PAWS receiver logic in <xref target="receiver_logic"/> before it sends A-PAWS option.
</t>
<t>Rule 2: An endpoint MUST not send segments with A-PAWS logic in <xref target="sender_logic"/> until it receives A-PAWS option 
from the other endpoint.
</t>
</list>
By having these rules, A-PAWS sender logic will not be activated without explicit signaling from its peer, which 
allows us to avoid the case 3 in <xref target="table_1"/> even if some signaling has been lost.
</t>
<t>
Another discussion point for this signaling method is when to set A-PAWS option in segments. As A-PAWS employs 
asynchronous signaling, both endpoints basically can set A-PAWS option in segments anytime they want. 
However, we recommend using the following rules for setting options.
<list style="empty">
<t>Rule 3: An endpoint SHOULD use a data segment when it sets A-PAWS option in a segment.
</t>
<t>Rule 4: When an endpoint receives a data segment with A-PAWS option, it SHOULD set A-PAWS option for its ACK segment.
</t>
<t>Rule 5: An endpoint SHOULD NOT set A-PAWS options in retransmitted segments.
</t>
</list>
These rules allow endpoints to have loose synchronized signaling so that they can at least solicit responses 
from their peers. Of course, even an endpoint solicit a response by setting A-PAWS option in a data segment, 
it might not receive A-PAWS option in the ACK segment. This can be caused by the lost of the ACK segment or 
middleboxes that remove unknown options. In order to address these cases, the following rules can be used.

<list style="empty">
<t>Rule 6: As long as an endpoint does not violate the other rules, it MAY set A-PAWS option in multiple data segments with a certain interval in case no A-PAWS options has been sent from the peer.
</t>
</list>
This rule can address the cases where A-PAWS options has been removed by middleboxes or segments with A-PAWS options has been lost.
</t>
</section>
<section title="Sending Behavior" anchor="sender_logic">
<t> A-PAWS enabled TCP transmits segments, it needs to follow the rules below.
<list style="numbers">
<t> TCP needs to check how many bytes has been transmitted in a connection.
If the transmitted bytes exceeds 2**32 - 'Sender.Offset', 
TCP migrates PAWS mode and MUST set timestamp option in all segments to be transmitted. 
The value for 'Sender.Offset' is discussed in <xref target="sec_discussion" />.
</t>
<t> If the number of bytes transmitted in a TCP connection does not exceeds 2**32 - 'Sender.Offset', 
TCP MAY omit timestamp option in segments as long as it does not affect RTTM. 
This draft does not define how much TCP can omit timestamps because it should be determined by RTTM.
</t>
</list>
</t>
</section>

<section title="Receiving Behavior" anchor="receiver_logic">
<t> A-PAWS enabled TCP receives segments, it needs to follow the rules below.
<list style="numbers">
<t> TCP needs to check how many bytes has been received in a TCP connection.
If it exceeds 2**32 bytes, A-PAWS nodes SHOULD discard the received segments which does not have timestamp option.
TCP MUST perform PAWS check when received bytes exceeds 2**32 bytes.
</t> 
<t>
If the number of bytes received in a TCP connection does not exceeds 2**32 bytes, 
A-PAWS nodes SHOULD accept the segments even if it does not have timestamp option. 
A-PAWS nodes MAY skip PAWS check until the received bytes exceeds 2**32 bytes.
</t>
</list>
</t>
</section>

</section>

<section title="When To Use A-PAWS" anchor="sec_usage">
<t>
In basic principal, A-PAWS capable nodes can always use A-PAWS as long as the peers agree with them.
However, the following cases require special considerations to enable A-PAWS.
<list style="numbers">
<t>
As "When To Keep Quiet" section in <xref target="RFC0793" /> suggests, it is recommended that TCP keeps quiet 
for a MSL upon starting up or recovering from a crash where memory of sequence numbers has been lost.
However,  if timestamps are being used and if the timestamp clock can be guaranteed to be 
increased monotonically, this quiet time may be unnecessary. Because TCP can identify the segments 
from old connections by checking the timestamp. 
We think some TCP implementations may disable the quiet time because of using timestamps from this 
reason. 
However, since A-PAWS nodes does not set timestamp options in all segments, TCP cannot rely on this approach. 
To avoid decreasing the robustness of TCP connection, TCP MUST NOT use A-PAWS for a MSL upon 
starting up or recovering from a crash.
</t>
<t> Various TCP implementations provide APIs such as setsockopt() that can set SO_REUSEADDR flag on TCP connections. 
If this flag is set, the TCP connection allows to reuse the same local port without waiting for 2 MSL period.
While this option is useful when users want to relaunch applications immediately, it makes the TCP connection 
a little vulnerable as TCP stack might receive duplicate segments from earlier incarnations. 
It has been said that PAWS can contribute to mitigate this risk by checking the timestamps in segments.
In order to keep the same level of protection, TCP SHOULD NOT enable A-PAWS when SO_REUSEADDR flag is set.
</t>
</list>
</t>
</section>

<section title="Discussion" anchor="sec_discussion">
 <t>
As A-PAWS is an experimental logic, the following points need to be considered and discussed.
 </t>
<section title="Protection Against Early Incarnations">
 <t> 
There are some discussions that timestamp can enhance the robustness against early incarnations.
Since A-PAWS does not set timestamps in all segments, some may say that it degrades the robustness 
of TCP. We believe that the degradation caused by A-PAWS on this point is negligible. As long as
TCP limits the usage of A-PAWS as described in <xref target="sec_usage" />, 
duplicate segments from early incarnations should not be received by TCP. 
</t>
</section>
<section title="Protection Against Security Threats">
<t>
A TCP connection can be identified by a 5-tuple: source address, destination address, source port number, 
destination port number and protocol. Crackers need to guess all these parameters when they try malicious
attacks on the connection. PAWS can enhance the protection for this as it additionally requires timestamp checking.
However, we think the effect of PAWS against malicious attacks is limited due to the simplicity of PAWS check. 
In PAWS, a segment can be considered as an old duplicate if the timestamp in the segment less than
some timestamps recently received on the connection. The "less than" in this context is determined 
by processing timestamp values as 32 bit unsigned integers in a modular 32-bit space. 
For example, if t1 and t2 are timestamp values, t1 < t2 is verified when 0 < (t2 - t1) < 2**31 computed in 
unsigned 32-bit arithmetic. Hence, if crackers set a random value in the timestamp option, there will be
50% chance for them to trick PAWS check. Moreover, there will be more chances if they send multiple 
segments with different timestamps, which will not be difficult to perform. 
</t>
<t>
In addition, we think there might be a case where using PAWS increases security risks.  
PAWS recommends to increase timestamp over a system when TCP waives the "quiet time" described in 
<xref target="RFC0793" />.
However, if timestamps are generated from a global counter, it may leak some information such as 
system uptime as discussed in <xref target="SILBERSACK05" />. 
A-PAWS might be able to allows TCP to use random timestamp values per connections.
</t>
</section>
<section title="Middlebox Considerations">
<t>
A-PAWS is designed to be robust against middleboxes. This means that endpoints will not be messed 
up even if middleboxes discard A-PAWS option. This is because A-PAWS sender logic is 
activated only when TCP receives a segment with A-PAWS options. A-PAWS receiver logic 
does not need to know whether the sender is using PAWS or A-PAWS. Activating A-PAWS receiving
logic for PAWS sender might be redundant as it requires additional overheads.
However, we believe the overhead will be acceptable in most cases because of the simplicity 
of A-PAWS logic.
</t>
<t>
Another concern on middleboxes is that they can insert or delete some bytes in TCP connections.
If a middlebox inserts extra bytes into a TCP connections, there might be a situation where 
an A-PAWS sender can transmit segments without timestamp, while an A-PAWS receiver
perform PAWS check on them as it already has received 2**32 bytes. 
In order to avoid discarding segments unnecessarily, we recommend that A-PAWS sender should have 
a certain amount of offset bytes in order to migrate PAWS mode before the receiver receives 2**32 bytes.
We call this protocol parameter 'Sender.Offset'. The proper value for 'Sender.Offset' needs to be 
discussed. 
</t>
</section>
<section title="Aggressive Mode in A-PAWS">
<t>
The current A-PAWS requires TCP to migrate PAWS mode after sending/receiving 2**32 bytes.
However, if both nodes check if 2 MSL has already passed during sending/receiving 2**32 bytes, 
they might be able to continue using A-PAWS. We call this "Aggressive mode". 
We currently do not recommend this mode as it requires additional complexities in A-PAWS.
</t>
</section>
</section>
<section title="Security Considerations">
<t>
We believe A-PAWS can maintain the same level of security as PAWS does, but further discussions
will be needed. Some security aspects of A-PAWS are discussed in <xref target="sec_discussion" />.
</t>
</section>
<section title="IANA Considerations">
<t>
This document may request new TCP option codepoint or other resources.
</t>
 </section>
</middle>

<back>
<references title='Normative References'> 
	  <?rfc include="reference.RFC.2119" ?> 
	  <?rfc include="reference.RFC.0793" ?> 
	  <?rfc include="reference.RFC.1323" ?> 
</references>
<references title='Informative References'>
    <?rfc include="reference.RFC.2018" ?> 
    <?rfc include="reference.RFC.5925" ?> 
    <?rfc include="reference.RFC.6824" ?> 
    <?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="SILBERSACK05" target="">
   <front>
   <title> Improving TCP/IP security through randomization without sacrificing interoperability.</title>
    <author initials="M." surname="Silbersack" fullname="">
    </author>
      <date month="November" year="2005" />
   </front>
   <seriesInfo name="EuroBSDCon 2005" value="" />
  </reference>

  <reference anchor="QIAN11" target="">
   <front>
   <title> A Flow-Based Performance Analysis of TCP and TCP Applications </title>
    <author initials="L." surname="Qian" fullname="">  <organization />  </author>
    <author initials="B." surname="Carpenter" fullname="">  <organization />  </author>
    <date month="February" year="2011" />
   </front>
   <seriesInfo name="3rd International Conference on Computer and Network Technology (ICCNT 2011)" value="" />
  </reference>
</references>
</back>

</rfc>