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

Versions: 00

MPTCP                                                          C. Paasch
Internet-Draft                                            O. Bonaventure
Intended status: Experimental                                  UCLouvain
Expires: August 15, 2014                               February 11, 2014


               A generic control stream for Multipath TCP
                  draft-paasch-mptcp-control-stream-00

Abstract

   Multipath TCP's extensive use of TCP options to exchange control
   information consumes a significant part of the TCP option space.
   Extending MPTCP to add more control information into the session
   becomes cumbersome as the TCP option space is limited to 40 bytes.

   This draft introduces a control stream that allows to send control
   information as part of the subflow's payload.  The control stream is
   mapped into a separate sequence number space and uses a TLV-format
   for maximum extensibility.  It is left to future documents to specify
   how the TLV-format might be used to exchange control information.  As
   the control stream is sent as part of the subflow's payload, it is
   not subject to the 40 bytes limitation of the TCP option space.

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 August 15, 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



Paasch & Bonaventure     Expires August 15, 2014                [Page 1]


Internet-Draft            MPTCP Control Stream             February 2014


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

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  The control stream  . . . . . . . . . . . . . . . . . . . . .   3
     2.1.  Window considerations . . . . . . . . . . . . . . . . . .   5
   3.  Connection initiation . . . . . . . . . . . . . . . . . . . .   5
   4.  Starting a new subflow  . . . . . . . . . . . . . . . . . . .   8
   5.  Examples of key negotiation through the control stream  . . .   9
     5.1.  Reusing the application's TLS key . . . . . . . . . . . .  10
     5.2.  TLS-like key exchange . . . . . . . . . . . . . . . . . .  10
     5.3.  Tcpcrypt-like key exchange  . . . . . . . . . . . . . . .  10
   6.  Other example use cases of the control stream . . . . . . . .  10
     6.1.  Address signaling . . . . . . . . . . . . . . . . . . . .  10
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .  10
   8.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .  11
   9.  Informative References  . . . . . . . . . . . . . . . . . . .  11
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  11

1.  Introduction

   Multipath TCP [RFC6824] uses the TCP options to exchange control
   information between the communication hosts.  [RFC6824] defines
   several new TCP options that are used during the three-way handshake
   and the data transfer.  Using options is the standard method to
   extend the TCP protocol.  Unfortunately, the maximum length of the
   TCP options field is 40 bytes.  This severely limit the utilisation
   of options to exchange control information between communicating
   hosts.  During the three-way handshake, the TCP options space is
   further limited by the other TCP options that are also included in
   the SYN and SYN+ACK segments.  [RFC6824] did its best to minimize the
   size of the MP_CAPABLE option inside the SYN and SYN+ACK segments
   given the presence of other options (typically MSS, timestamp,
   selective acknowledgements and window scale).  However, this has been
   at the cost of a reduced security due to the utilization of security
   keys that are too short.

   The security requirements for MPTCP ask for a strong authentication
   of additional subflows [RFC6181].  Given the restriction in the size
   of the MPTCP options, it seems very difficult to provide strong
   security by relying only on TCP options that cannot be longer than 40



Paasch & Bonaventure     Expires August 15, 2014                [Page 2]


Internet-Draft            MPTCP Control Stream             February 2014


   bytes and are not exchanged reliably.  Although a design to overcome
   these problems would probably be possible, it would add a lot of
   complexity to the protocol.

   Furthermore, today's MPTCP control information is sent in an
   unreliable manner.  This means that control information like MP_PRIO,
   ADD_ADDR or REMOVE_ADDRESS might get lost, resulting in potential
   suboptimal performance of Multipath TCP.

   In this document, we show that another design is possible.  Instead
   of using only TCP options to exchange control information, we show
   how it is possible to define a control stream in parallel with the
   data stream that is used to exchange data over the established
   subflows.  By using this control stream, two MPTCP hosts can reliably
   exchange control information without being restricted by TCP option
   space.  The control stream can be used to exchange cryptographic
   material to authenticate the handshake of additional subflows or for
   any other purpose.

   Together with the control stream, we propose to modify the MPTCP-
   handshake so that no crypto information is exchanged within the TCP
   options.  We suggest to use the control stream instead.  Within the
   control stream, different key-negotiation schemes can be specified
   (e.g., reuse SSL-key, tcpcrypt-style, Diffie-Hellman,...)

   This document is structured as follows.  First, we define how the
   control stream can be used within an MPTCP session.  Section 3
   presents the modified MPTCP handshake of the initial subflow, while
   Section 4 specifies the handshake of additional subflows.  Section 5
   gives some example use-cases for the key negotiation through the
   control stream.  Finally, Section 6 gives another example on how to
   use the control stream to conduct the MPTCP session.

2.  The control stream

   In contrast with SCTP [RFC4960], TCP and Multipath TCP [RFC6824] only
   support one data stream.  SCTP uses chunks to allow the communicating
   hosts to exchange control information of almost unlimited size.  As
   explained earlier, having a control stream in Multipath TCP would
   enable a reliable delivery of the control information without strict
   length limitations.

   This section defines a control stream that allows to exchange MPTCP
   control information of arbitrary length besides the regular data
   stream.  The control stream holds data in a TLV-format and thus any
   type of data can be added to it.  Further, the control stream
   provides a reliable and in-order delivery of the control data.




Paasch & Bonaventure     Expires August 15, 2014                [Page 3]


Internet-Draft            MPTCP Control Stream             February 2014


   The control stream is sent within the payload of the TCP segments.
   This ensures a reliable delivery of the TLVs exchanged in the control
   stream.  Further, a separate control-sequence number space is defined
   for the control stream to ensure in-order delivery of the control
   stream.  The Initial Control stream Sequence Number (ICSN) is the
   same as the IDSN in the respective directions.  A DSS-mapping is used
   within the TCP option space to signal the control stream sequence
   numbers as well as a control stream acknowledgement.  This DSS-
   mapping option is the same as the one defined in [RFC6824].  To
   differentiate the control stream from the data stream, we use the
   last bit of the 'reserved' field of the MPTCP DSS option.  We call
   this bit the Stream (S) bit.  When the DSS option is used to map
   regular data, this bit is set to 0.  When the DSS option is used to
   map one TLV on the control stream, it is set to 1 (see Figure Figure
   1)

       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|(reserved)|S|F|m|M|a|A|
       +---------------+---------------+-------+----------------------+
       |        Control ACK (4 or 8 octets, depending on flags)       |
       +--------------------------------------------------------------+
       |Control sequence number (4 or 8 octets, depending on flags)   |
       +--------------------------------------------------------------+
       |              Subflow Sequence Number (4 octets)              |
       +-------------------------------+------------------------------+
       |Control-Level Length (2 octets)|      Checksum (2 octets)     |
       +-------------------------------+------------------------------+

     The S bit of the 'reserved' field is set to 1 when sending on the
                              control stream.

                                 Figure 1

   The control information exchanged in the control stream is encoded by
   using a TLV format, where the type and length are 16-bit values.
   This allows for maximum extensibility and to use very long data
   within the control stream.  The format of the TLV option is shown in
   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
       +---------------+---------------+-------+----------------------+
       |              Type             |             Length           |
       +---------------+---------------+-------+----------------------+
       |                      Value (Length - 4)                      |
       +-------------------------------+------------------------------+



Paasch & Bonaventure     Expires August 15, 2014                [Page 4]


Internet-Draft            MPTCP Control Stream             February 2014


                           The TLV option format

                                 Figure 2

2.1.  Window considerations

   MPTCP uses the receive-window to do flow-control at the receiver.
   The receive-window within MPTCP is being used at the data sequence
   level, however any segment sent on a subflow must obey to the last
   window-announcement received on this particular subflow with respect
   to the subflow-level sequence number.

   The control stream is no different with respect to this last point.
   The subflow-sequence numbers used for control stream data must fit
   within the window announced over this specific subflow.  However, to
   avoid issues of receive-window handling at the control stream
   sequence number level, a host may never have more than one
   unacknowledged TLV-field in-flight.  This effectively limits the
   amount of memory required to support the control-stream down to 64KB
   (the maximum size of a TLV-field).

   TCP uses the congestion-window to limit the amount of unacknowledged
   in-flight data within a TCP connection.  The control stream must also
   obey to this limitation.  As the control stream uses regular TCP
   sequence numbers, the congestion-window limitations apply too.

3.  Connection initiation

   The control stream allows to negotiate the crypto material to
   authenticate new subflows.  Thus, the handshake of the initial
   subflow does not need anymore to send the 64-bit key in plaintext.
   The suggested modification to the initial handshake is detailled in
   this section.

   MultiPath TCP uses the MP_CAPABLE option in the handshake for the
   initial subflow.  This handshake was designed to meet several
   requirements.  When designing another variant of the Multipath TCP
   handshake, it is important to have these requirements in mind.  These
   requirements are :

   1.  Detect whether the peer supports MultiPath TCP.

   2.  Exchange locally unique tokens that unambiguously identify the
       Multipath TCP connection

   3.  Agree on an Initial Data Sequence Number to initialize the MPTCP
       state on each direction of the Multipath TCP connection




Paasch & Bonaventure     Expires August 15, 2014                [Page 5]


Internet-Draft            MPTCP Control Stream             February 2014


   Before discussing the proposed handshake, it is important to have in
   mind how [RFC6824] meets the three requirements above.

   The first requirement is simply met by using a Multipath TCP specific
   option, like all TCP extensions.

   To meet the second requirement, a simple solution would have been to
   encode the token inside the MP_CAPABLE option.  However, this would
   have increased its size.  This would have limited the possibility of
   extending Multipath TCP later by adding new TCP options that require
   space inside the SYN segments.  To minimize the number of option
   bytes consummed in the SYN segment, [RFC6824] uses a hash function to
   compute the token based on the keys exchanged in clear.  However,
   using hash functions implies that implementations must handle the
   possible collisions which increases the complexity of implementing
   the Multipath TCP handshake.

   In this document we suggest a simplified handshake that meets the
   above three goals.  This simplified handshake avoids negotiating the
   crypto-material during the three-way handshake.  Instead, security
   information is exchanged reliably by relying on the control stream.
   The figure below provides an overview of the proposed handshake.

                Host A                               Host B
              ----------                           ----------
              Address A1                           Address B1
              ----------                           ----------
                  |                                    |
                  |  SYN+MP_CAPABLE(Token-A)   |
                  |----------------------------------->|
                  |                                    |
                  |SYN/ACK+MP_CAPABLE(Token-B) |
                  |<-----------------------------------|
                  |                                    |
                  |  ACK+MP_CAPABLE(Token-A, Token-B)  |
                  |                                    |
                  |----------------------------------->|

                     Handshake of the initial subflow.

                                 Figure 3

   MPTCP's establishment of the initial subflow follows TCP's regular
   3-way handshake, but the SYN, SYN/ACK and ACK packets contain the
   MP_CAPABLE-option.  The proposed MP_CAPABLE option contains one 32
   bits token in the SYN and SYN/ACK segments.  The third ACK includes
   an MP_CAPABLE option that contains the two tokens.  Echoing all the
   information back in the third ACK allows stateless operation of the



Paasch & Bonaventure     Expires August 15, 2014                [Page 6]


Internet-Draft            MPTCP Control Stream             February 2014


   server.  The tokens are used to explicitly exchange the identifiers
   of the Multipath TCP connection.

   It is required that the server, upon reception of the SYN generates a
   token different from the client's token.  This is necessary to
   protect against reflection attacks when establishing additional
   subflows.

   The format of the proposed MP_CAPABLE option is proposed in the
   figures below.

                         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|Version|A|B|C|D|E|F|G|H|
     +---------------+---------------+-------+-------+---------------+
     |                     Sender's Token (32 bits)                  |
     +---------------------------------------------------------------+

      Format of the MP_CAPABLE-option in the SYN and SYN/ACK packets

                                 Figure 4

                         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|Version|A|B|C|D|E|F|G|H|
     +---------------+---------------+-------+-------+---------------+
     |                     Sender's Token (32 bits)                  |
     +---------------------------------------------------------------+
     |                     Receiver's Token (32 bits)                |
     +---------------------------------------------------------------+

     Format of the MP_CAPABLE-option in the third ACK of the handshake

                                 Figure 5

   The format of the MP_CAPABLE option is shown in Figure 4.  To
   indicate that this MP_CAPABLE contains tokens numbers and not keys
   (as in [RFC6824]), the Version-field is set to 1.  The message format
   of the third ACK's MP_CAPABLE option is show in Figure 5.

   The Initial Data Sequence Number (IDSN) serves to initialize the
   MPTCP state on the end-hosts in the same way as TCP's sequence
   numbers do during the 3-way handshake.  There is one IDSN for each
   direction of the data-stream.  The IDSN for the data from the client
   to the server is the 64 low-order bits of the hash (SHA1) of the
   concatenation of the tokens (Token-A || Token-B).  For the data from



Paasch & Bonaventure     Expires August 15, 2014                [Page 7]


Internet-Draft            MPTCP Control Stream             February 2014


   server to client, the IDSN is 64 low-order bits of the hash (SHA1) of
   the reverse concatenation (Token-B || Token-A).  The tokens should be
   generated with sufficient randomness so that they are hard to guess.
   Recommendations for generating random numbers are given in [RFC4086].

   The meaning of the other fields and behavior of the end-hosts during
   the MP_CAPABLE exchange is the same as specified in [RFC6824].

4.  Starting a new subflow

   The handshake for the establishment of a new subflow is similar to
   the one specified in [RFC6824].  There are three important
   differences.  First, the HMAC is computed by using the keys
   negotiated over the control stream.  Second, the token and the
   client's random numbers are included inside the third ack to allow
   stateless operation of the passive opener of an additional subflow.
   Finally, the token is used within the message of the HMAC.  This
   protects against reflection attacks, as the HMAC cannot be sent in
   the reverse direction anymore, because the tokens are ensured to be
   different on both end-hosts.

              Host A                                  Host B
             ----------                             ----------
             Address A2                             Address B2
             ----------                             ----------
                 |                                      |
                 |   SYN + MP_JOIN(Token-B, R-A)        |
                 |------------------------------------->|
                 |                                      |
                 |   SYN/ACK + MP_JOIN(HMAC-B, R-B)     |
                 |<-------------------------------------|
                 |                                      |
                 |  ACK + MP_JOIN(Token-B, R-A, HMAC-A) |
                 |------------------------------------->|

             HMAC-A = HMAC(Key, Msg=(Token-B+R-A+R-B))
             HMAC-B = HMAC(Key, Msg=(Token-B+R-B+R-A))

                        Handshake of a new subflow.

                                 Figure 6

   In order to allow the Token-B and R-A inside the third ack, the
   HMAC-A must also be a truncated version of the 160-bit HMAC-SHA1.
   Thus, HMAC-A is the truncated (leftmost 128 bits) of the HMAC as
   shown in Figure 6.





Paasch & Bonaventure     Expires August 15, 2014                [Page 8]


Internet-Draft            MPTCP Control Stream             February 2014


   The message-format of the MP_JOIN-option in the SYN and the SYN/ACK
   is the same as in [RFC6824].  As the third ACK includes the Token and
   the random nonce, the MP_JOIN message format of the third ack is as
   shown in Figure 7.  The length of the MP_JOIN-option in the third ACK
   is 28 bytes.  Thus, there remains enough space to insert the
   timestamp option in the third ACK.

                         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|     |B|   Address ID  |
     +---------------+---------------+-------+-------+---------------+
     |                                                               |
     |                Sender's Truncated HMAC (128 bits)             |
     |                                                               |
     +---------------------------------------------------------------+
     |                Sender's Random Number (32 bits)               |
     +---------------------------------------------------------------+
     |                     Receiver's Token (32 bits)                |
     +---------------------------------------------------------------+

                       Format of the MP_JOIN-option

                                 Figure 7

   The semantics of the backup-bit "B" and the Address ID are the same
   as in [RFC6824].

5.  Examples of key negotiation through the control stream

   The control stream's primary goal is to negotiate the crypto-material
   to authenticate additional subflows.  Both hosts must agree on which
   key-negotiation scheme to use over the control stream.  The option
   "key select" of the control stream is of type 1 and it negotiates the
   available key-negotiation schemes.  The value-field of the "key
   select"-option contains a bitmask of available key-negotiation
   schemes.  The bitmask remains to be defined as the schemes are being
   defined.  The bits within the bitmask are numbered, starting from the
   leftmost as being '1'.

   The key-select must be initiated by one host and answered by the
   other one.  During the initiation, the host offers the available
   schemes, and the answering host selects one of the offered ones.  The
   hosts need thus to ensure an order among themself of who initiates
   the "key select" option.  A possibility would be that the host with
   the smaller token initiates the "key select" option.





Paasch & Bonaventure     Expires August 15, 2014                [Page 9]


Internet-Draft            MPTCP Control Stream             February 2014


   The following are examples of how the control stream could be used to
   negotiate the cryptographic material.  A proper specification is
   probably needed for each of them.

5.1.  Reusing the application's TLS key

   Within the "key select"-option, this negotiation scheme takes the bit
   number 1.  It signals to the peer that the connection should use a
   derivate of TLS's master key to authenticate new subflows with this
   "MPTCP key".  It is required that indeed TLS is being used within the
   data stream.

   As TLS allows to modify the key being used during a TLS session, the
   control stream might be used to ensure that both end hosts agree on
   the "MPTCP key" being used at a specific moment in time through the
   exchange of the hash of the "MPTCP key".

5.2.  TLS-like key exchange

   It enables a key-negotiation in an TLS-like manner, thus
   authenticating the client/server through a certificate.

5.3.  Tcpcrypt-like key exchange

   It uses the control stream, to exchange a secret key in a tcpcrypt-
   like manner.  Optionally, it may include a data-sequence number to
   define from which moment on the data stream should be encrypted.

6.  Other example use cases of the control stream

   This shows one example of how the control stream can be used within
   MPTCP.

6.1.  Address signaling

   In RFC6824, the address-signaling is achieved through the ADD_ADDRESS
   and REMOVE_ADDRESS options.  These options are sent within the TCP
   options-space and thus do not benefit from reliable delivery.
   Further, security-concerns have rosen concerning the ADD_ADDRESS-
   option.  Using the control stream to signal the addition or removal
   of addresses allows to make these options reliable and provides the
   space to add any kind of cryptographic material to enhance their
   security.

7.  Security Considerations

   TBD




Paasch & Bonaventure     Expires August 15, 2014               [Page 10]


Internet-Draft            MPTCP Control Stream             February 2014


8.  Acknowledgments

   This work is supported by the European FP7 Project "Trilogy2" under
   grant agreement 317756.

9.  Informative References

   [RFC4086]  Eastlake, D., Schiller, J., and S. Crocker, "Randomness
              Requirements for Security", BCP 106, RFC 4086, June 2005.

   [RFC4960]  Stewart, R., "Stream Control Transmission Protocol", RFC
              4960, September 2007.

   [RFC6181]  Bagnulo, M., "Threat Analysis for TCP Extensions for
              Multipath Operation with Multiple Addresses", RFC 6181,
              March 2011.

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

Authors' Addresses

   Christoph Paasch
   UCLouvain
   Place Sainte Barbe, 2
   Louvain-la-Neuve  1348
   BE

   Email: christoph.paasch@uclouvain.be


   Olivier Bonaventure
   UCLouvain
   Place Sainte Barbe, 2
   Louvain-la-Neuve  1348
   BE

   Email: olivier.bonaventure@uclouvain.be












Paasch & Bonaventure     Expires August 15, 2014               [Page 11]


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