Internet DRAFT - draft-paasch-mptcp-lowoverhead

draft-paasch-mptcp-lowoverhead






MPTCP                                                     C. Paasch, Ed.
Internet-Draft                                            O. Bonaventure
Intended status: Informational                                 UCLouvain
Expires: April 18, 2013                                 October 15, 2012


                       MultiPath TCP Low Overhead
                   draft-paasch-mptcp-lowoverhead-00

Abstract

   This document describes a low overhead connection establishment
   mechanism for Multipath TCP.  Its goal is to reduce the computational
   overhead of establishing an MPTCP connection and the associated TCP
   subflows in controlled environments where security attacks are not a
   concern.

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 April 18, 2013.

Copyright Notice

   Copyright (c) 2012 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.



Paasch & Bonaventure     Expires April 18, 2013                 [Page 1]

Internet-Draft             MPTCP Low Overhead               October 2012


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
   2.  Connection initiation . . . . . . . . . . . . . . . . . . . . . 3
   3.  Starting a new subflow  . . . . . . . . . . . . . . . . . . . . 6
   4.  Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
     4.1.  Generating the token  . . . . . . . . . . . . . . . . . . . 7
     4.2.  Stateless Servers . . . . . . . . . . . . . . . . . . . . . 7
   5.  Security Considerations . . . . . . . . . . . . . . . . . . . . 8
   6.  Informative References  . . . . . . . . . . . . . . . . . . . . 8
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . . 8








































Paasch & Bonaventure     Expires April 18, 2013                 [Page 2]

Internet-Draft             MPTCP Low Overhead               October 2012


1.  Introduction

   This document introduces a variant of the MPTCP handshake that is
   suitable for an environment where security attacks are not an issue.
   The proposed handshake is a low overhead, low security version of the
   MPTCP handshake defined in [I-D.ietf-mptcp-multiaddressed].

   Its goal is to provide an MPTCP handshake and authentication
   mechanism, reducing the computational overhead provided by MPTCP
   version 0.


2.  Connection initiation

   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.  Each host generates a locally unique token that unambiguously
       identifies 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

   Before discussing the proposed low overhead handshake, it is
   important to have in mind how [I-D.ietf-mptcp-multiaddressed] 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 the size of the MP_CAPABLE option.  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,
   [I-D.ietf-mptcp-multiaddressed] 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 the Multipath TCP
   handshake.

   The third requirement is more subtle but is also important to ensure



Paasch & Bonaventure     Expires April 18, 2013                 [Page 3]

Internet-Draft             MPTCP Low Overhead               October 2012


   the reliability of a Multipath TCP connection.  Let us assume that
   Multipath TCP hosts do not agree on an Initial Data Sequence Number.
   Consider the following scenario.  Host A opens the initial TCP
   subflow of the Multipath TCP connection.  Host B opens a second
   subflow in this Multipath TCP connection.  Host B sends one byte with
   DSN x over the initial subflow, but this data never reaches host A.
   Host B then sends one byte, starting at DSN x+1 over the second
   subflow.  If host A does not know the Initial Data Sequence Number
   used by host B, it cannot determine whether the byte received over
   the second subflow can be acknowledged at the DSN level or not.
   [I-D.ietf-mptcp-multiaddressed] solves this problem by allowing the
   two hosts to derive the Initial Data Sequence Number from the keys
   exchanged in the MP_CAPABLE option.  However, this is achieved by
   computing a hash over the exchanged keys, which increases the
   computational overhead of generating/processing the MP_CAPABLE
   option.

   The figure below provides a simpler and low overhead handshake that
   meets the three requirements identified above.

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

                     Handshake of the initial subflow.

                                 Figure 1

   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 and one 32 bits random number in the SYN and SYN/ACK
   segments.  The third ACK includes an MP_CAPABLE option that contains
   the two tokens and random numbers.  The tokens are used to explictely
   exchange identifier of the Multipath TCP connection.  The random
   numbers, combined with the tokens produce the Initial Data Sequence
   Numbers.  Echoing all the information back in the third ACK allows



Paasch & Bonaventure     Expires April 18, 2013                 [Page 4]

Internet-Draft             MPTCP Low Overhead               October 2012


   stateless operation of the server.

   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)                  |
     +---------------------------------------------------------------+
     |                 Sender's Random Number (32 bits)              |
     +---------------------------------------------------------------+

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

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

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

                                 Figure 3

   The format of the MP_CAPABLE option is shown in Figure 2.  To
   indicate that this MP_CAPABLE contains tokens/random numbers and not
   keys (as in [I-D.ietf-mptcp-multiaddressed], the Version-field is set
   to 1.  The message format of the third ACK's MP_CAPABLE option is
   show in Figure 3.

   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



Paasch & Bonaventure     Expires April 18, 2013                 [Page 5]

Internet-Draft             MPTCP Low Overhead               October 2012


   to the server is the concatenation of Rand-A and Token-A (Rand-A||
   Token-A).  Rand-A is thus the high-order 32 bits of the IDSN, and
   Token-A the low-order 32 bits.  For the data from server to client,
   the IDSN is the concatenation of Rand-B and Token-B (Rand-B||
   Token-B).  Rand-A and Rand-B MUST be random numbers with sufficient
   randomness so that they are hard to guess.  Recommendations for
   generating random numers for use in keys 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
   [I-D.ietf-mptcp-multiaddressed].


3.  Starting a new subflow

   Once an MPTCP connection has been established and the tokens
   exchanged, new subflows can be established.  The establishment of the
   new subflows follows the handshake as show in Figure 4.

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

                       Handshake for a new subflow.

                                 Figure 4

   As the low-overhead version of MPTCP does not try to protect against
   hijacking attacks, the only goal of the MP_JOIN inside the 3-way
   handshake is to identify the MPTCP connection this subflow is
   joining.  The token inside the MP_JOIN of the SYN-segment allows the
   server to identify the connection.  The SYN/ACK also contains an
   MP_JOIN option because the server needs to signal to the client that
   it indeed received the SYN together with the MP_JOIN and that there
   is no middlebox that removes MPTCP options on this path.  Finally,
   the client replies with the third ack.  This third ack contains again
   token B. This allows the server to handle MP_JOIN's in a stateless
   manner, as described below.  The third ack is sent in a reliable



Paasch & Bonaventure     Expires April 18, 2013                 [Page 6]

Internet-Draft             MPTCP Low Overhead               October 2012


   manner as explained in [I-D.ietf-mptcp-multiaddressed].

                         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  |
     +---------------+---------------+-------+-------+---------------+
     |                     Receiver's Token (32 bits)                |
     |                      (if option Length == 8)                  |
     +---------------------------------------------------------------+

                       Format of the MP_JOIN-option

                                 Figure 5

   The semantics of the backup-bit "B" and the Address ID are the same
   as in [I-D.ietf-mptcp-multiaddressed].


4.  Operation

4.1.  Generating the token

   The token must only be locally unique.  The method used to generate
   the token is implementation specific.  One possible way to generate
   the token is by applying a block-cipher on a counter together with a
   local secret.  This approach has the benefit of a higher probability
   of uniqueness of the token.  We will only have a token collision
   after the counter has wrapped around.  This means, that a connection
   must have survived 2^32 other connections to cause a collision.
   Thus, a token collision is less likely to occur than with
   [I-D.ietf-mptcp-multiaddressed].

4.2.  Stateless Servers

   To allow stateless SYN+Join handling, the server has to perform the
   following upon reception of a SYN:

   o  Check whether there exists an MPTCP-connection corresponding to
      the token inside the MP_JOIN option.

   o  Send a SYN/ACK as it is done on today's stateless servers.

   When receiving the third ACK (sent reliably as it is done in today's
   MPTCP), the server verifies that indeed it has generated a SYN/ACK
   (like regular TCP's SYN-cookie mechanism) and thanks to the token
   echoed back in the third ACK, the server can find the MPTCP-session
   this subflow is joining.



Paasch & Bonaventure     Expires April 18, 2013                 [Page 7]

Internet-Draft             MPTCP Low Overhead               October 2012


   Handling the SYN+Join in a stateless manner allows the server to
   protect itself against attackers that are flooding the server with
   SYN+Join messages.  As the server does not need to create state when
   sending the SYN/ACK, flooding performed by the attacker will not
   prevent real clients from establishing new subflows.


5.  Security Considerations

   The proposed solution removes the HMAC authentication mechanism
   described in [I-D.ietf-mptcp-multiaddressed].  It is assumed that
   end-hosts will only use this low-overhead version of MPTCP for non-
   security critical traffic or in controlled environments like isolated
   data-centers.

   Security-critical traffic is nowadays typically sent over SSL/TLS or
   similar secure application level protocols.  This is done because the
   transport protocols like TCP do not provide a sufficient security.
   An application using SSL over MPTCP benefits from the same security
   provided by SSL.  There is one downside of using SSL over MPTCP.  If
   an attacker manages to join an existing connection thanks to a JOIN-
   exchange, he can inject data into the SSL-session.  However, thanks
   to the MAC-authentication of the SSL messages, the end-hosts will
   tear down the SSL session.


6.  Informative References

   [I-D.ietf-mptcp-multiaddressed]
              Ford, A., Raiciu, C., Handley, M., and O. Bonaventure,
              "TCP Extensions for Multipath Operation with Multiple
              Addresses", draft-ietf-mptcp-multiaddressed-10 (work in
              progress), October 2012.

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


Authors' Addresses

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

   Email: christoph.paasch@uclouvain.be




Paasch & Bonaventure     Expires April 18, 2013                 [Page 8]

Internet-Draft             MPTCP Low Overhead               October 2012


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

   Email: olivier.bonaventure@uclouvain.be












































Paasch & Bonaventure     Expires April 18, 2013                 [Page 9]