[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02

Network Working Group                                         Y. Nishida
Internet-Draft                                        GE Global Research
Intended status: Experimental                              June 10, 2014
Expires: December 12, 2014


                 A-PAWS: Alternative Approach for PAWS
                      draft-nishida-tcpm-apaws-01

Abstract

   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.

Status of This Memo

   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 http://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 December 12, 2014.

Copyright Notice

   Copyright (c) 2014 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
   (http://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



Nishida                 Expires December 12, 2014               [Page 1]


Internet-Draft              Alternative PAWS                   June 2014


   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Conventions and Terminology . . . . . . . . . . . . . . . . .   3
   3.  The A-PAWS Design . . . . . . . . . . . . . . . . . . . . . .   3
     3.1.  Signaling Method  . . . . . . . . . . . . . . . . . . . .   4
     3.2.  Negotiating Features Using non-SYN segments . . . . . . .   5
     3.3.  Sending Behavior  . . . . . . . . . . . . . . . . . . . .   6
     3.4.  Receiving Behavior  . . . . . . . . . . . . . . . . . . .   7
   4.  When To Use A-PAWS  . . . . . . . . . . . . . . . . . . . . .   7
   5.  Discussion  . . . . . . . . . . . . . . . . . . . . . . . . .   8
     5.1.  Protection Against Early Incarnations . . . . . . . . . .   8
     5.2.  Protection Against Security Threats . . . . . . . . . . .   8
     5.3.  Middlebox Considerations  . . . . . . . . . . . . . . . .   9
     5.4.  Aggressive Mode in A-PAWS . . . . . . . . . . . . . . . .   9
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .   9
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   9
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   9
     8.1.  Normative References  . . . . . . . . . . . . . . . . . .  10
     8.2.  Informative References  . . . . . . . . . . . . . . . . .  10
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  11

1.  Introduction

   PAWS (Protect Against Wrapped Sequences) defined in [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.

   PAWS utilizes timestamp option in [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



Nishida                 Expires December 12, 2014               [Page 2]


Internet-Draft              Alternative PAWS                   June 2014


   implementations.  However, as some TCP extensions such as [RFC2018],
   [RFC5925] and [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.

   In addition, although PAWS is necessary for connections which
   transmit more than 2**32 bytes, it is not very important for other
   connections since [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 [QIAN11].  Timestamp option is also used for RTTM
   (Round Trip Time Measurement) in [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 [MALLMAN99].  Hence, we can think if PAWS is not used, sending a
   few timestamps per RTT will be sufficient.

   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.

   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 Section 5.  A-PAWS is an experimental idea yet, but we
   hope it will contribute to facilitating the use of TCP option space.

2.  Conventions and Terminology

   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 [RFC2119].

3.  The A-PAWS Design

   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.



Nishida                 Expires December 12, 2014               [Page 3]


Internet-Draft              Alternative PAWS                   June 2014


3.1.  Signaling Method

   A-PAWS requires a signaling mechanism to enable this feature as it
   employs different logics from [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 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).

               +--------+--------+----------+--------------+
               | case # | Sender | Receiver |              |
               +--------+--------+----------+--------------+
               |   1    |  PAWS  |   PAWS   |     Work     |
               |        |        |          |              |
               |   2    |  PAWS  |  A-PAWS  |     Work     |
               |        |        |          |              |
               |   3    | A-PAWS |   PAWS   | Doesn't work |
               |        |        |          |              |
               |   4    | A-PAWS |  A-PAWS  |     Work     |
               +--------+--------+----------+--------------+

            Table 1: Possible Combinations for PAWS and A-PAWS

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

   1) Option Exchange in SYN
       This method requires using new codepoint for TCP option and
       exchange them during SYN negotiation.  The use of [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 Section 3.3.
       However, it MUST activate A-PAWS receiver logic in Section 3.4 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.

   2) Timestamp Field Negotiation in SYN



Nishida                 Expires December 12, 2014               [Page 4]


Internet-Draft              Alternative PAWS                   June 2014


       This method is based on timestamp field negotiation proposed in
       [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 Table 1.

   3) Option Exchange in non-SYN Segments
       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
       Section 3.4 if it sends the options.  However, it MUST not send
       segments with A-PAWS logic in Section 3.3 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.

3.2.  Negotiating Features Using non-SYN segments

   As explained in Section 3.1, 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.

      Rule 1: An endpoint MUST activate A-PAWS receiver logic in
      Section 3.4 before it sends A-PAWS option.






Nishida                 Expires December 12, 2014               [Page 5]


Internet-Draft              Alternative PAWS                   June 2014


      Rule 2: An endpoint MUST not send segments with A-PAWS logic in
      Section 3.3 until it receives A-PAWS option from the other
      endpoint.

   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 Table 1 even if some signaling has been lost.

   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.

      Rule 3: An endpoint SHOULD use a data segment when it sets A-PAWS
      option in a segment.

      Rule 4: When an endpoint receives a data segment with A-PAWS
      option, it SHOULD set A-PAWS option for its ACK segment.

      Rule 5: An endpoint SHOULD NOT set A-PAWS options in retransmitted
      segments.

   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.

      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.

   This rule can address the cases where A-PAWS options has been removed
   by middleboxes or segments with A-PAWS options has been lost.

3.3.  Sending Behavior

   A-PAWS enabled TCP transmits segments, it needs to follow the rules
   below.

   1.  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 Section 5.



Nishida                 Expires December 12, 2014               [Page 6]


Internet-Draft              Alternative PAWS                   June 2014


   2.  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.

3.4.  Receiving Behavior

   A-PAWS enabled TCP receives segments, it needs to follow the rules
   below.

   1.  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.

   2.  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.

4.  When To Use A-PAWS

   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.

   1.  As "When To Keep Quiet" section in [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.

   2.  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



Nishida                 Expires December 12, 2014               [Page 7]


Internet-Draft              Alternative PAWS                   June 2014


       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.

5.  Discussion

   As A-PAWS is an experimental logic, the following points need to be
   considered and discussed.

5.1.  Protection Against Early Incarnations

   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 Section 4, duplicate segments from early incarnations should not
   be received by TCP.

5.2.  Protection Against Security Threats

   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.

   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 [RFC0793].
   However, if timestamps are generated from a global counter, it may
   leak some information such as system uptime as discussed in
   [SILBERSACK05].  A-PAWS might be able to allows TCP to use random
   timestamp values per connections.



Nishida                 Expires December 12, 2014               [Page 8]


Internet-Draft              Alternative PAWS                   June 2014


5.3.  Middlebox Considerations

   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.

   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.

5.4.  Aggressive Mode in A-PAWS

   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.

6.  Security Considerations

   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 Section 5.

7.  IANA Considerations

   This document may request new TCP option codepoint or other
   resources.

8.  References







Nishida                 Expires December 12, 2014               [Page 9]


Internet-Draft              Alternative PAWS                   June 2014


8.1.  Normative References

   [RFC0793]  Postel, J., "Transmission Control Protocol", STD 7, RFC
              793, September 1981.

   [RFC1323]  Jacobson, V., Braden, B., and D. Borman, "TCP Extensions
              for High Performance", RFC 1323, May 1992.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

8.2.  Informative References

   [I-D.scheffenegger-tcpm-timestamp-negotiation]
              Scheffenegger, R., Kuehlewind, M., and B. Trammell,
              "Additional negotiation in the TCP Timestamp Option field
              during the TCP handshake", draft-scheffenegger-tcpm-
              timestamp-negotiation-05 (work in progress), October 2012.

   [MALLMAN99]
              Allman, M. and V. Paxson, "On Estimating End-to-End
              Network Path Properties", Proceedings of the ACM SIGCOMM ,
              September 1999.

   [QIAN11]   Qian, L. and B. Carpenter, "A Flow-Based Performance
              Analysis of TCP and TCP Applications", 3rd International
              Conference on Computer and Network Technology (ICCNT 2011)
              , February 2011.

   [RFC2018]  Mathis, M., Mahdavi, J., Floyd, S., and A. Romanow, "TCP
              Selective Acknowledgment Options", RFC 2018, October 1996.

   [RFC5925]  Touch, J., Mankin, A., and R. Bonica, "The TCP
              Authentication Option", RFC 5925, June 2010.

   [RFC6824]  Ford, A., Raiciu, C., Handley, M., and O. Bonaventure,
              "TCP Extensions for Multipath Operation with Multiple
              Addresses", RFC 6824, January 2013.

   [RFC6994]  Touch, J., "Shared Use of Experimental TCP Options", RFC
              6994, August 2013.

   [SILBERSACK05]
              Silbersack, M., "Improving TCP/IP security through
              randomization without sacrificing interoperability.",
              EuroBSDCon 2005 , November 2005.





Nishida                 Expires December 12, 2014              [Page 10]


Internet-Draft              Alternative PAWS                   June 2014


Author's Address

   Yoshifumi Nishida
   GE Global Research
   2623 Camino Ramon
   San Ramon, CA   94583
   USA

   Email: nishida@wide.ad.jp










































Nishida                 Expires December 12, 2014              [Page 11]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/