[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00 01

MPTCP Working Group                                       O. Bonaventure
Internet-Draft                                                 UCLouvain
Intended status: Experimental                           October 29, 2014
Expires: May 2, 2015


                     Multipath TCP timestamp option
                  draft-bonaventure-mptcp-timestamp-00

Abstract

   The TCP timestamps defined in [RFC1323] were designed to improve
   round-trip-time estimations and provide protection against wrapped
   sequence numbers (PAWS).  This draft clarifies the utilisation of
   timestamps by Multipath TCP and proposes a new timestamp option that
   better suits the needs of Multipath TCP.

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 May 2, 2015.

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



Bonaventure                Expires May 2, 2015                  [Page 1]


Internet-Draft                  MPTCP-TS                    October 2014


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  The TCP Timestamps option and Multipath TCP . . . . . . . . .   3
   3.  The Multipath TCP Timestamp option  . . . . . . . . . . . . .   4
   4.  Security Considerations . . . . . . . . . . . . . . . . . . .   5
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   5
   6.  Conclusion  . . . . . . . . . . . . . . . . . . . . . . . . .   5
   7.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   6
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   6
     8.1.  Normative References  . . . . . . . . . . . . . . . . . .   6
     8.2.  Informative References  . . . . . . . . . . . . . . . . .   6
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   6

1.  Introduction

   The Timestamps option was proposed in [RFC1323].  Each Timestamps
   option contains two timestamps.  The first one corresponds to the
   current value of the sender's clock.  The second timestamp allows to
   echo the most recent timestamp received from the remote host.  The
   utilisation of this option can be negotiated on a per-connection
   basis during the three-way handshake.  The timestamps option was
   motivated by two usages :

   o  improve the accuracy of the round-trip-time measurements

   o  provide protection against wrapped TCP sequence numbers (PAWS)

   Although these two usages have completely different purposes, they
   are coupled in [RFC1323].  [RFC7323] goes further by requiring that
   the TCP timestamps option be included in all segments once the option
   has been negotiated in the three-way handshake.  Forcing the
   utilisation of this option in all segments is required to support
   PAWS.  However, there is no reason to force TCP hosts to include the
   timestamp option in all segments when PAWS is not required.

   In practice, there are two important use cases where PAWS is not
   required.  The first is when the TCP connections are so short that
   TCP sequence numbers cannot wrap around.  The second use case is when
   Multipath TCP is used.  Multipath TCP, defined in [RFC6824], is a TCP
   extension that enables a TCP connection to exchange data over
   multiple paths.  This TCP extension uses 64 bits sequence number
   which solves the PAWS problem in a cleaner way than [RFC7323].  Once
   Multipath TCP has been negotiated, the PAWS part of [RFC1323] becomes
   useless and should be disabled.

   This document is organised as follows.  We first summarize in section
   Section 2 the issues with the TCP timestamps option defined in



Bonaventure                Expires May 2, 2015                  [Page 2]


Internet-Draft                  MPTCP-TS                    October 2014


   [RFC1323].  We then propose in section Section 3 a Multipath TCP
   Timestamp option that should be used by Multipath TCP implementations
   instead of the regular [RFC7323] timestamps options.

2.  The TCP Timestamps option and Multipath TCP

   The TCP timestamps option defined in [RFC1323] is encoded as shown in
   figure Figure 1.

    +-------+-------+---------------------+---------------------+
    |Kind=8 |  10   |   TS Value (TSval)  |TS Echo Reply (TSecr)|
    +-------+-------+---------------------+---------------------+
       1       1              4                     4


               Figure 1: Original RFC1323 Timestamps option

   This option consummes 10 bytes.  When [RFC1323] was published,
   consumming 10 bytes in the SYN segment to negotiate the utilisation
   of this option and later in all data segments was not a severe
   concern given the limited number of TCP options that were used at
   that time.  This is not anymore the case today with Multipath TCP
   [RFC6824] or the Selective Acknowledgements [RFC2018] option.

   A Multipath TCP implementation SHOULD not use the [RFC7323]
   timestamps option on Multipath TCP connections.  However, a regular
   TCP connection SHOULD use the [RFC7323] timestamp option to protect
   against wrapped sequence numbers.  To achieve this objective,
   Multipath TCP implementations SHOULD operate as follows :

   o  an active Multipath TCP opener SHOULD place both the Timestamps
      and MP_CAPABLE options in SYN segments when trying to open a TCP
      connection unless the remote host (and the path towards this host)
      is known to support Multipath TCP.  In this case, the Timestamps
      option can be ignored in the SYN segment.

   o  a passive Multipath TCP opener that receives a SYN segment
      containing both the Timestamp and the MP_CAPABLE options SHOULD
      only include the MP_CAPABLE option in the returned SYN+ACK
      segment.  This would disable the [RFC7323] timestamps on the
      Multipath TCP connection.

   When creating subflows, the Timestamps option SHOULD NOT be
   associated with the MP_JOIN option in the SYN segments.  Furthermore,
   if a Multipath TCP host receives a valid SYN segment that contains
   both the MP_JOIN option and the Timestamps option, it should not
   include the Timestamps option in the returned SYN+ACK segment.




Bonaventure                Expires May 2, 2015                  [Page 3]


Internet-Draft                  MPTCP-TS                    October 2014


3.  The Multipath TCP Timestamp option

   The Timestamps option defined in [RFC7323] encodes two 32 bits
   timestamps.  Having two timestamps is useful when data transfer is
   bidirectional but in practice very few TCP connections are totally
   bidirectional.  Most TCP connections send data in one directions and
   acknowledgments in the opposite.  For these connections, placing two
   timestamps in each segment that carries data and each acknowledgement
   is a waste of TCP options space.  To preserve the TCP options space
   while still enabling the utilisation of timestamps in some TCP
   segments, we propose a new Multipath TCP Timestamp option that
   contains a single timestamp.  This option is an MPTCP option subtype
   whose format is shown in figure Figure 2.

                            1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +---------------+---------------+-------+-------+---------------+
       |     Kind      |    Length     |Subtype|E 0 0 0|    TS         |
       +---------------+---------------+-------+-------+---------------+
       |             TS (cont.)                        |
       +-----------------------------------------------+



                   Figure 2: The MPTCP Timestamp Option

   The MPTCP TS option contains four flags.  One of these flags,
   labelled 'E' in figure Figure 2, is defined in this document.  The
   three other flags, labelled 0 in figure Figure 2, MUST be set to zero
   on transmission and ignored on reception.  The MPTCP TS option
   contains one 32 bits timestamp.  It has thus a length of 7 bytes.
   The 'E' (or Echo) flag is set to 0 if the timestamp (TS) has been
   generated by the sender of the option.  If the 'E' flag is set to 1,
   then the timestamp echoes a value that was generated by the remote
   host.

   The MPTCP TS option may be sent in any TCP segment except those
   having the SYN flag set.

   When a host receives a segment containing an MPTCP TS option whose
   'E' flag is reset, it SHOULD reply immediately by echoing the
   received timestamp in a returned MPTCP TS option whose 'E' flag is
   set.  This MPTCP TS option can be included in either a segment that
   carries data, if one is pending, or an acknowledgement.  This implies
   that a host does not need to maintain additional state to process the
   received MPTCP TS option since it can reply directly to any received
   MPTCP TS option.




Bonaventure                Expires May 2, 2015                  [Page 4]


Internet-Draft                  MPTCP-TS                    October 2014


   The MPTCP TS option can be used to improve the quality of the round-
   trip-time estimator.  The discussion in section 4.2 of [RFC7323] is
   also applicable for the Timestamp proposed in this document.

   The MPTCP TS may also be used to verify that a subflow remains active
   by forcing a remote host to reply to an MPTCP segment without sending
   data.

4.  Security Considerations

   A middlexbox may remove the MPTCP TS option.  This is unlikely if the
   Multipath TCP connection operates corectly.  Since the MPTCP TS
   option is only informational, such a behaviour would not affect the
   reliability of the Multipath TCP connection.

   Some of the security considerations from [RFC7323] and in particular
   the following paragraph apply for the MPTCP TS option :

   A naive implementation that derives the timestamp clock value
   directly from a system uptime clock may unintentionally leak this
   information to an attacker.  This does not directly compromise any of
   the mechanisms described in this document.  However, this may be
   valuable information to a potential attacker.  It is therefore
   RECOMMENDED to generate a random, per-Multipath TCP connection offset
   to be used with the clock source when generating the Timestamps
   option value.
   By carefully choosing this random offset, further improvements as
   described in [RFC6191] are possible.

5.  IANA Considerations

   This document proposes a new MPTCP option subtype for the MPTCP
   Timestamp.

      +-------+--------------+----------------------------+
      | Value |    Symbol    |            Name            |
      +-------+--------------+----------------------------+
      |  TBD  |  MP_TS       | Multipath TCP Timestamp    |
      +-------+--------------+----------------------------+


                    Figure 3: MPTCP Timestamp suboption

6.  Conclusion

   This document has proposed a new Timestamp option to replace the
   [RFC7323] Timestamps option on Multipath TCP connections.  The MPTCP




Bonaventure                Expires May 2, 2015                  [Page 5]


Internet-Draft                  MPTCP-TS                    October 2014


   TS option can be included in MPTCP segments only when needed to
   preserve TCP option space notably for the MPTCP and SACK options.

7.  Acknowledgements

   This work was partially supported by the EC within the FP7-Trilogy2
   project.  The author would like to thank Raphael Bauduin for his
   comments and Joe Touch whose comments on the mptcp mailing list
   encouraged the writing of this draft.

8.  References

8.1.  Normative References

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

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

   [RFC7323]  Borman, D., Braden, B., Jacobson, V., and R.
              Scheffenegger, "TCP Extensions for High Performance", RFC
              7323, September 2014.

8.2.  Informative References

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

   [RFC6191]  Gont, F., "Reducing the TIME-WAIT State Using TCP
              Timestamps", BCP 159, RFC 6191, April 2011.

Author's Address

   Olivier Bonaventure
   UCLouvain

   Email: Olivier.Bonaventure@uclouvain.be












Bonaventure                Expires May 2, 2015                  [Page 6]


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