Network Working Group
Internet Engineering Task Force (IETF)                        M. Bagnulo
Internet-Draft
Request for Comments: 7430                                          UC3M
Intended status:
Category: Informational                                        C. Paasch
Expires: September 28, 2015
ISSN: 2070-1721                                                UCLouvain
                                                                 F. Gont
                                                  SI6 Networks / UTN-FRH
                                                          O. Bonaventure
                                                               UCLouvain
                                                               C. Raiciu
                                                                     UPB
                                                          March 27,
                                                               July 2015

   Analysis of MPTCP residual threats Residual Threats and possible fixes
                      draft-ietf-mptcp-attacks-04 Possible Fixes for Multipath TCP
                                (MPTCP)

Abstract

   This documents performs an analysis of document analyzes the residual threats for MPTCP Multipath TCP (MPTCP)
   and explores possible solutions to address them.

Status of This Memo

   This Internet-Draft document is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents not an Internet Standards Track specification; it is
   published for informational purposes.

   This document is a product of the Internet Engineering Task Force
   (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list  It represents the consensus of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid the IETF community.  It has
   received public review and has been approved for publication by the
   Internet Engineering Steering Group (IESG).  Not all documents
   approved by the IESG are a maximum candidate for any level of Internet
   Standard; see Section 2 of RFC 5741.

   Information about the current status of six months this document, any errata,
   and how to provide feedback on it may be updated, replaced, or obsoleted by other documents obtained 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 September 28, 2015.
   http://www.rfc-editor.org/info/rfc7430.

Copyright Notice

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

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  ADD_ADDR attack Attack . . . . . . . . . . . . . . . . . . . . . . .   4
     2.1.  Possible security enhancements Security Enhancements to prevent this attack Prevent This Attack . .  10
   3.  DoS attack Attack on MP_JOIN . . . . . . . . . . . . . . . . . . . .  10  11
     3.1.  Possible security enhancements Security Enhancements to prevent this attack Prevent This Attack . .  11  12
   4.  SYN flooding amplification Flooding Amplification  . . . . . . . . . . . . . . . . .  11  12
     4.1.  Possible security enhancements Security Enhancements to prevent this attack Prevent This Attack . .  12
   5.  Eavesdropper in the initial handshake Initial Handshake . . . . . . . . . . . .  12  13
     5.1.  Possible security enhancements Security Enhancements to prevent this attack Prevent This Attack . .  13
   6.  SYN/JOIN attack Attack . . . . . . . . . . . . . . . . . . . . . . .  13
     6.1.  Possible security enhancements Security Enhancements to prevent this attack Prevent This Attack . .  14
   7.  Reccomendations  Recommendations . . . . . . . . . . . . . . . . . . . . . . .  14
     7.1.  MPTCP Security enhancements Improvements for MPTCP a Standards Track
           Specification . . . . . . . . . . . . . .  15
   8.  Security considerations . . . . . . . .  14
     7.2.  Security Enhancements for MPTCP . . . . . . . . . . . . .  15
   9.  IANA
   8.  Security Considerations . . . . . . . . . . . . . . . . . . .  15
   9.  References  . .  15
   10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .  15
   11.
     9.1.  Normative References  . . . . . . . . . . . . . . . . . .  15
     9.2.  Informative References  . . . . . . .  15
     11.1.  Normative References . . . . . . . . . . .  16
   Acknowledgements  . . . . . . .  16
     11.2.  Informative References . . . . . . . . . . . . . . . . .  16  17
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  17  18

1.  Introduction

   This document provides a complement to the threat analysis for
   Multipath TCP (MPTCP) [RFC6824] documented in RFC 6181 [RFC6181].
   RFC 6181 provided a threat analysis for the general solution space of
   extending TCP to operate with multiple IP addresses per connection.
   Its main goal was to leverage previous experience acquired during the
   design of other multi-address protocols, notably SHIM6 Shim6 [RFC5533],
   SCTP [RFC4960] the
   Stream Control Transmission Protocol (SCTP) [RFC4960], and MIPv6 Mobile
   IPv6 (MIP6) [RFC6275] for designing MPTCP.  Thus, RFC 6181 was
   produced before the actual MPTCP specification (RFC6824) (RFC 6824) was
   completed,
   completed and documented a set of reccommendations recommendations that were
   considered during the production of such that specification.

   This document complements RFC 6181 with a vulnerability analysis of
   the specific mechanisms specified in RFC 6824.  The motivation for this
   analysis is to identify possible security issues with MPTCP as
   currently specified and propose security enhancements to address the
   these identified security issues.

   The goal of the security mechanisms defined in RFC 6824 were was to make
   MPTCP no worse than currently available single-path TCP.  We believe
   that this goal is still valid, so we will perform our analysis on the
   same grounds.  This document describes all the threats identified
   that are specific to MPTCP (as defined in RFC6824) RFC 6824) that are not
   possible with (single-path) single-path TCP.  This means that threats that are
   common to TCP and MPTCP are not covered in this document.

   Types of attackers: for all attacks considered

   For each attack considered in this document, we identify the type of
   attacker.  We can classify the attackers based on their location as
   follows:

   o  Off-path attacker.  This is an attacker that does not need to be
      located in any of the paths of the MPTCP session at any point in
      time during the lifetime of the MPTCP session.  This means that
      the Off-path off-path attacker cannot eavesdrop any of the packets of the
      MPTCP session.

   o  Partial time On-path  Partial-time on-path attacker.  This is an attacker that needs to
      be in at least one of the paths during part but not during of the
      entire lifetime of the
      MPTCP session. session (but not the entire lifetime).  The attacker can be
      in the forward and/or backward directions, directions for the initial subflow
      and/or other subflows.  The specific needs of the attacker will be
      made explicit in the attack description.

   o  On-path attacker.  This attacker needs to be on at least one of
      the paths during the whole duration of the MPTCP session.  The
      attacker can be in the forward and/or backward directions, directions for the
      initial subflow and/or other subflows.  The specific needs of the
      attacker will be made explicit in the attack description.

   We can also classify the attackers based on their actions as follows:

   o  Eavesdropper.  The attacker is able to capture some of the packets
      of the MPTCP session to perform the attack, but it is not capable
      of changing, discarding discarding, or delaying any packet of the MPTCP
      session.  The attacker can be in the forward and/or backward
      directions,
      directions for the initial subflow and/or other subflows.  The
      specific needs of the attacker will be made explicit in the attack
      description.

   o  Active attacker.  The attacker is able to change, discard discard, or
      delay some of the packets of the MPTCP session.  The attacker can
      be in the forward and/or backward directions, directions for the initial
      subflow and/or other subflows.  The specific needs of the attacker
      will be made explicit in the attack description.

   In this document, we consider the following possible combinations of
   attackers:

   o  an On-path on-path eavesdropper

   o  an On-path on-path active attacker

   o  an Off-path off-path active attacker

   o  a Partial-time On-path partial-time on-path eavesdropper

   o  a Partial-time On-path partial-time on-path active attacker

   In the rest of the document document, we describe different attacks that are
   possible against the MPTCP protocol specified in RFC6824 RFC 6824 and we propose
   possible security enhancements to address them.

2.  ADD_ADDR attack Attack

   Summary of the attack:

      Type of attack: MPTCP session hijack enabling Man-in-the-Middle. a man-in-the-middle
      (MitM) attack

      Type of attacker: Off-path, off-path active attacker. attacker

   Description:

   In this attack, the attacker uses the ADD_ADDR option defined in
   RFC6824 RFC
   6824 to hijack an ongoing MPTCP session and enables enable himself to perform
   a Man-in-the-Middle man-in-the-middle attack on the MPTCP session.

   Consider the following scenario.  Host A with address IPA has one
   MPTCP session with Host B with address IPB.  The MPTCP subflow
   between IPA and IPB is using port PA on host Host A and port PB on host Host B.
   The tokens for the MPTCP session are TA and TB for Host A and Host B B,
   respectively.  Host C is the attacker.  It owns address IPC.  The
   attack is executed as follows:

   1.  Host C sends a forged packet with source address IPA, destination
       address IPB, source port PA PA, and destination port PB.  The packet
       has the ACK flag set.  The TCP sequence number for the segment is
       i
       i, and the ACK sequence number is j.  We will assume all these
       are
       valid, valid; later, we discuss what the attacker needs to figure these ones
       later on.
       them out.  The packet contains the ADD_ADDR option.  The ADD_ADDR
       option announces IPC as an alternative address for the
       connection.  It also contains an eight bit 8-bit address identifier
       which that
       does not bring provide any strong security benefit.

   2.  Host B receives the ADD_ADDR message and it replies by sending a TCP
       SYN packet.  (Note: the

          Note: The MPTCP specification [RFC6824] states that the host
          receiving the ADD_ADDR option may initiate a new subflow.  If
          the host is configured so that it does not initiate a new
       subflow
          subflow, the attack will not succeed.  For example, on the
          current Linux implementation, the server does not create
          subflows.  Only the client does so.) so.

       The source address for the packet is IPB, IPB; the destination address
       for the packet is IPC, IPC; the source port is
       PB' PB'; and the
       destination port is PA' (It (it is not required that PA=PA' nor that
       PB=PB').  The sequence number for this packet is the new initial
       sequence number for this subflow.  The ACK sequence number is not
       relevant as the ACK flag is not set.  The packet carries an
       MP_JOIN option and it carries the token TA.  It also carries a random nonce
       generated by Host B called RB.

   3.  Host C receives the SYN+MP_JOIN packet from Host B, B and it alters it
       in the following way.  It changes the source address to IPC and
       the destination address to IPA.  It sends the modified packet to
       Host A, impersonating Host B.

   4.  Host A receives the SYN+MP_JOIN message and it replies with a
       SYN/ACK+MP_JOIN SYN/
       ACK+MP_JOIN message.  The packet has source address IPA and
       destination address IPC, as well as all the other needed
       parameters.  In particular, Host A computes a valid HMAC Hashed
       Message Authentication Code (HMAC) and places it in the MP_JOIN
       option.

   5.  Host C receives the SYN/ACK+MP_JOIN message and it changes the
       source address to IPC and the destination address to IPB.  It
       sends the modified packet to IPB IPB, impersonating Host A.

   6.  Host B receives the SYN/ACK+MP_JOIN message.  Host B verifies the
       HMAC of the MP_JOIN option and confirms its validity.  It replies
       with an ACK+MP_JOIN packet.  The packet has source address IPB
       and destination address IPC, as well as all the other needed
       parameters.  The returned MP_JOIN option contains a valid HMAC
       computed by Host B.

   7.  Host C receives the ACK+MP_JOIN message from B and it alters it in
       the following way.  It changes the source address to IPC and the
       destination address to IPA.  It sends the modified packet to Host A
       A, impersonating Host B.

   8.  Host A receives the ACK+MP_JOIN message and creates the new
       subflow.  At this point point, the attacker has managed to place itself
       as a MitM for one subflow for the existing MPTCP session.  It
       should be noted that there still exists the subflow between
          address addresses IPA and IPB
       that does not flow through the attacker, attacker still exists, so the
       attacker has not completely intercepted all the packets in the
       communication (yet).  If the attacker wishes to completely
       intercept the MPTCP session session, it can do the following additional
       step.

   9.  Host C sends two TCP RST messages.  One TCP RST packet is sent to
       Host B, with source address IPA and IPA, destination address IPB IPB, and
       source and destination ports PA and PB, respectively.  The other
       TCP RST message is sent to Host A, with source address IPB and IPB,
       destination address IPA IPA, and source and destination ports PB and
       PA, respectively.  Both RST messages must contain a valid
       sequence number.  Note that figuring the sequence numbers to be
       used here for subflow A is the same difficulty as being able to
       send the initial ADD_ADDR option with valid Sequence sequence number and
       ACK value.  If there are more subflows, then the attacker needs
       to find the Sequence Number sequence number and ACK for each subflow.  At this point
       point, the attacker has managed to fully hijack the MPTCP
       session.

   Information required by the attacker to perform the described attack:

   In order to perform this attack the attacker needs to guess or know
   the following pieces of information: (The information.  The attacker need needs this
   information for one of the subflows belonging to the MPTCP session.) session.

   o  the four-tuple {Client-side IP Address, Client-side Port, Server-
      side Address, Servcer-side Server-side Port} that identifies the target TCP
      connection

   o  a valid sequence number for the subflow

   o  a valid ACK sequence number for the subflow

   o  a valid address identifier for IPC

   TCP connections are uniquely identified by the four-tuple {Source
   Address, Source Port, Destination Address, Destination Port}.  Thus,
   in order to attack a TCP connection, an attacker needs to know or be
   able to guess each of the values in that four-tuple.  Assuming the
   two peers of the target TCP connection are known, the Source Address
   and the Destination Address can be assumed to be known.

      We note that in

      Note: In order to be able to successfully perform this attack, the
      attacker needs to be able to send packets with a forged source
      address.  This means that the attacker cannot be located in a
      network where techniques like ingress filtering [RFC2827]  or
      source address validation [RFC7039] are deployed.  However,
      ingress filtering is not as widely implemented as one would expect, expect
      and hence cannot be relied upon as a mitigation for this kind of
      attack.

   Assuming the attacker knows the application protocol for which the
   TCP connection is being employed, the server-side port can also be
   assumed to be known.  Finally, the client-side port will generally
   not be known, known and will need to be guessed by the attacker.  The
   chances of an attacker guessing the client-side port will depend on
   the ephemeral port range employed by the client, client and whether or not
   the client implements port randomization [RFC6056].

   Assuming TCP sequence number randomization is in place (see e.g. e.g.,
   [RFC6528]), an attacker would have to blindly guess a valid TCP
   sequence number.  That is,

      RCV.NXT =< SEG.SEQ < RCV.NXT+RCV.WND or RCV.NXT =<
      SEG.SEQ+SEG.LEN-1 < RCV.NXT+RCV.WND

   As a result, the chances of an attacker to succeed succeeding will depend on the
   TCP receive window size at the target TCP peer.

      We note that automatic

      Note: Automatic TCP buffer tuning mechanisms have been become common
      for popular TCP implementations, and hence implementations; hence, very large TCP window
      sizes of values up to 2 MB could end up being employed by such TCP
      implementations.

   According to [RFC0793], the Acknowledgement Number acknowledgement number is considered
   valid as long as it does not acknowledge the receipt of data that has
   not yet been sent.  That is, the following expression must be true:

      SEG.ACK <= SND.NXT

   However, for implementations that support [RFC5961], the following
   (stricter) validation check is enforced:

      SND.UNA - SND.MAX.WND MAX.SND.WND <= SEG.ACK <= SND.NXT

   Finally, in order for the address identifier to be valid, the only
   requirement is that it needs to be different than from the ones already
   being used by Host A in that MPTCP session, so a random identifier is
   likely to work.

   Given that a large number of factors affect the chances of an
   attacker of successfully performing the aforementioned off-path attacks,
   we provide two general expressions for the expected number of packets
   the attacker needs to send to succeed in the attack: one for MPTCP
   implementations that support [RFC5961], [RFC5961] and another for MPTCP
   implementations that do not.

   Implementations that do not support RFC 5961 5961:

   Packets = (2^32/(RCV_WND)) * 2 * EPH_PORT_SIZE/2 * 1/MSS

   Where the new : parameters are:

   Packets:
      Maximum number of packets required to successfully perform an off-
      path (blind) attack.

   RCV_WND:
      TCP receive window size (RCV.WND) at the target node.

   EPH_PORT_SIZE:
      Number of ports comprising the ephemeral port range at the
      "client" system.

   MSS:
      Maximum Segment Size, assuming the attacker will send full
      segments to maximize the chances to get of getting a hit.

   Notes:
      The value "2^32" represents the size of the TCP sequence number
      space.

      The value "2" accounts for 2 two different ACK numbers (separated by
      2^31) that should be employed to make sure the ACK number is
      valid.

   The following table contains some sample results for the number of
   required packets, based on different values of RCV_WND and
   EPH_PORT_SIZE for a an MSS of 1500 bytes.

          +-------------+---------+---------+--------+---------+
          | Ports \ Win |  16 KB  |  128 KB | 256 KB | 2048 KB |
          +-------------+---------+---------+--------+---------+
          |     4000    |  699050 |  87381  | 43690  |   5461  |
          +-------------+---------+---------+--------+---------+
          |    10000    | 1747626 |  218453 | 109226 |  13653  |
          +-------------+---------+---------+--------+---------+
          |    50000    | 8738133 | 1092266 | 546133 |  68266  |
          +-------------+---------+---------+--------+---------+

         Table 1: Max. Maximum Number of Packets for Successful Attack

   Implementations that do support RFC 5961 5961:

   Packets = (2^32/(RCV_WND)) * (2^32/(2 * SND_MAX_WND)) *
   EPH_PORT_SIZE/2 * 1/MSS

   Where:

   Packets:
      Maximum number of packets required to successfully perform an off-
      path (blind) attack.

   RCV_WND:
      TCP receive window size (RCV.WND) at the target MPTCP endpoint.

   SND_MAX_WND:
      Maximum TCP send window size ever employed by the target MPTCP
      end-point (SND.MAX.WND).
      endpoint (MAX.SND.WND).

   EPH_PORT_SIZE:
      Number of ports comprising the ephemeral port range at the
      "client" system.

   Notes:
      The value "2^32" represents the size of the TCP sequence number
      space.

      The parameter "SND_MAX_WND" "MAX.SND.WND" is specified in [RFC5961].

      The value "2*SND_MAX_WND" "2 * SND_MAX_WND" results from the expresion expression "SND.NXT -
      SND.UNA - MAX.SND.WND", assuming that, for connections that
      perform bulk data transfers, "SND.NXT - SND.UNA == MAX.SND.WND".
      If an attacker targets a TCP endpoint that is not actively
      transferring data, "2 * SND_MAX_WND" would become "SND_MAX_WND"
      (and hence a successful attack would typically require more
      packets).

   The following table contains some sample results for the number of
   required packets, based on different values of RCV_WND, SND_MAX_WND,
   and EPH_PORT_SIZE.  For these implementations, only a limited number
   of sample results are provided, just as provided (as an indication of how [RFC5961]
   increases the difficulty of performing these attacks. attacks).

      +-------------+-------------+-----------+-----------+---------+
      | Ports \ Win |    16 KB    |   128 KB  |   256 KB  | 2048 KB |
      +-------------+-------------+-----------+-----------+---------+
      |     4000    | 45812984490 | 715827882 | 178956970 | 2796202 |
      +-------------+-------------+-----------+-----------+---------+

         Table 2: Max. Maximum Number of Packets for Successful Attack

   Note:
      In the aforementioned table, all values are computed with RCV_WND
      equal to SND_MAX_WND.

2.1.  Possible security enhancements Security Enhancements to prevent this attack Prevent This Attack

   1.  To include the token of the connection in the ADD_ADDR option.
       This would make it harder for the attacker to launch the attack,
       since he the attacker needs to either eavesdrop the token (so this
       can no longer be a blind attack) or to guess it, but a random 32 bit
       32-bit number is not so easy to guess.  However, this would imply
       that any eavesdropper that is able to see the token, token would be able
       to launch this attack.  This solution then increases the
       vulnerability window against eavesdroppers from the initial 3-way
       handshake for the MPTCP session to any exchange of the ADD_ADDR
       messages.

   2.  To include the HMAC of the address contained in the ADD_ADDR
       option.  The key used for the HMAC is the concatenation of the
       key of the receiver and the key of the sender (in the same way
       they are used for generating the HMAC of the MP_JOIN message).
       This makes it much more secure, since it requires the attacker to
       have both keys (either by eavesdropping it in the first exchange
       or by guessing it).  Because this solution relies on the key used
       in the MPTCP session, the protection of this solution would
       increase if new key generation methods are defined for MPTCP
       (e.g.
       (e.g., using SSL Secure Socket Layer (SSL) keys as has been
       proposed).

   3.  To include the destination address of the SYN packet in the HMAC
       of the MP_JOIN message.  As the attacker requires to change changing the
       destination address to perform the described attack, protecting
       it would prevent the attack.  It wouldn't allow hosts behind NATs
       to be reached by an address in the ADD_ADDR option, even with
       static NAT bindings (like a web server at home).

   Out of

   Of the options described above, option 2 is reccommended recommended as it
   achieves a higher security level while preserving the required
   functionality (i.e. (i.e., NAT compatibility).

3.  DoS attack Attack on MP_JOIN

   Summary of the attack:

      Type of attack: MPTCP Denial-of-Service denial-of-service attack, preventing the
      hosts from creating new subflows. subflows

      Type of attacker: Off-path, off-path active attacker

   Description:

   As currently specified, the initial SYN+MP_JOIN message of the 3-way
   handshake for additional subflows creates state in the host receiving
   the message.  This is because the SYN+MP_JOIN contains the 32-bit
   token that allows the receiver to identify the MPTCP-session MPTCP session and the
   32-bit random nonce, nonce used in the HMAC calculation.  As this
   information is not resent re-sent in the third ACK of the 3-way handshake, a
   host must create state upon reception of a SYN+MP_JOIN.

   Assume that there exists an MPTCP-session MPTCP session exists between host Host A and host Host B, with token Ta
   tokens TA and Tb. TB.  An attacker, sending a SYN+MP_JOIN to host Host B, with
   the valid token Tb, TB, will trigger the creation of state on host Host B.
   The number of these half-open connections a host can store per
   MPTCP-session MPTCP
   session is limited by a certain number, number and it is
   implementation-dependent. implementation-
   dependent.  The attacker can simply exhaust this limit by sending
   multiple SYN+MP_JOINs with different 5-tuples.  The (possibly forged)
   source address of the attack packets will typically correspond to an
   address that is not in use, or else else, the SYN/ACK sent by Host B would
   elicit a RST from the impersonated node, thus removing the
   corresponding state at Host B.  Further discussion of traditional SYN-flood SYN
   flooding attacks and common mitigations can be found in
   [RFC4987] [RFC4987].

   This effectively prevents the host Host A from sending any more SYN+MP_JOINs
   to host Host B, as the number of acceptable half-open connections per MPTCP-session
   MPTCP session on host Host B has been exhausted.

   The attacker needs to know the token Tb TB in order to perform the
   described attack.  This can be achieved if it is a Partial-time On- partial-time on-
   path eavesdropper , observing the 3-way handshake of the establishment
   of an additional subflow between host Host A and host Host B.  If the attacker
   is never on-path, it has to guess the 32-bit token.

3.1.  Possible security enhancements Security Enhancements to prevent this attack Prevent This Attack

   The third packet of the 3-way handshake could be extended to contain also
   contain the 32-bit token and the random nonce that has been sent in
   the SYN+MP_JOIN.  Further, host Host B will have to generate its own
   random nonce in a reproducible fashion (e.g., a Hash hash of the 5-tuple +
   initial sequence-number sequence number + local secret).  This will allow host Host B to
   reply to a SYN+MP_JOIN without having to create state.  Upon the
   reception of the third ACK, host Host B can then verify the correctness of
   the HMAC and create the state.

4.  SYN flooding amplification Flooding Amplification

   Summary of the attack:

      Type of attack: The attacker can use the uses SYN+MP_JOIN messages to amplify
      the SYN flooding attack.

      Type of attacker: Off-path, off-path active attacker

   Description:

   SYN flooding attacks [RFC4987] use SYN messages to exhaust the
   server's resources and prevent new TCP connections.  A common
   mitigation is the use of SYN cookies [RFC4987] that allow the stateless
   processing of the initial SYN message.

   With MPTCP, the initial SYN can be processed in a stateless fashion
   using the aforementioned SYN cookies.  However, as we described in the
   previous section, as currently specified, the SYN+MP_JOIN messages are
   not processed in a stateless manner.  This opens a new attack vector.
   The attacker can now open a an MPTCP session by sending a regular SYN
   and creating the associated state but then send sending as many
   SYN+MP_JOIN messages as supported by the server with different
   combinations of source address and source port combinations, port, consuming the
   server's resources without having to create state in the attacker.
   This is an amplification attack, where the cost on the attacker side
   is only the cost of the state associated with the initial SYN while
   the cost on the server side is the state for the initial SYN plus all
   the state associated to with all the following SYN+MP_JOIN. SYN+MP_JOINs.

4.1.  Possible security enhancements Security Enhancements to prevent this attack Prevent This Attack

   1.  The solution described for the previous DoS attack on MP_JOIN
       would also prevent this attack.

   2.  Limiting the number of half open half-open subflows to a low number (e.g. 3 (e.g.,
       three subflows) would also limit the impact of this attack.

5.  Eavesdropper in the initial handshake Initial Handshake

   Summary of the attack attack:

      Type of attack: An eavesdropper present in the initial handshake
      where the keys are exchanged can hijack the MPTCP session at any
      time in the future.

      Type of attacker: a Partial-time On-path partial-time on-path eavesdropper

   Description:

   In this case, the attacker is present along the path when the initial
   3-way handshake takes place, place and therefore is able to learn the keys
   used in the MPTCP session.  This allows the attacker to move away
   from the MPTCP session path and still be able to hijack the MPTCP
   session in the future.  This vulnerability was readily identified at
   the moment of the design of
   when designing the MPTCP security solution [RFC6181], and the threat
   was considered acceptable.

5.1.  Possible security enhancements Security Enhancements to prevent this attack Prevent This Attack

   There are many techniques that can be used to prevent this attack attack,
   and each of them represents different tradeoffs. trade-offs.  At this point, we
   limit ourselves to enumerate them and provide useful pointers.

   1.  Use of hash-chains. hash chains.  The use of hash chains for MPTCP has been
       explored in [hash-chains] [HASH-CHAINS].

   2.  Use of SSL keys for MPTCP security as described in
       [I-D.paasch-mptcp-ssl] [MPTCP-SSL].

   3.  Use of Cryptographically-Generated Cryptographically Generated Addresses (CGAs) for MPTCP
       security.  CGAs [RFC3972] have been used in the past to secure
       multi addressed
       multi-addressed protocols like SHIM6 Shim6 [RFC5533].

   4.  Use of TCPCrypt [I-D.bittau-tcp-crypt] tcpcrypt [TCPCRYPT].

   5.  Use of DNSSEC.  DNSSEC has been proposed to secure the Mobile IP
       protocol [dnssec] [DNSSEC].

6.  SYN/JOIN attack Attack

   Summary of the attack attack:

      Type of attack: An attacker that can intercept the SYN/JOIN
      message can alter the source address being added.

      Type of attacker: a Partial-time On-path partial-time on-path eavesdropper
   Description:

   The attacker is present along the path when the SYN/JOIN exchange
   takes place, and this place.  This allows the attacker to add any new address it
   wants to by simply substituting the source address of the SYN/JOIN
   packet for one it chooses.  This vulnerability was readily identified
   at the moment of the design of
   when designing the MPTCP security solution [RFC6181], and the threat
   was considered acceptable.

6.1.  Possible security enhancements Security Enhancements to prevent this attack Prevent This Attack

   It should be noted that this vulnerability is fundamental due to the
   NAT support requirement.  In other words, MPTCP must work through
   NATs in order to be deployable in the current Internet.  NAT behavior
   is unfortunately indistinguishable from this attack.  It is
   impossible to secure the source address, since doing so would prevent
   MPTCP to work though from working through NATs.  This basically implies that the
   solution cannot rely on securing the address.  A more promising
   approach would be then to look into securing the payload exchanged, exchanged and
   thus limiting the impact that the attack would have in the
   communication (e.g.
   TCPCrypt [I-D.bittau-tcp-crypt] (e.g., tcpcrypt [TCPCRYPT] or similar).

7.  Reccomendations

   Current  Recommendations

   The current MPTCP specification [RFC6824] is experimental. Experimental.  There is
   an ongoing effort to move it to Standards track. Track.  We believe that the
   work on MPTCP security should follow two threads:

   o  The work on improving MPTCP security so that is enough to the MPTCP
      specification [RFC6824] can become a
      Standard Standards Track document.

   o  The work on analyzing possible additional security enhancements to
      provide a more secure version of MPTCP.

   We will expand on these two next. in the following subsections.

7.1.  MPTCP security Security Improvements for a Standard Standards Track specification. Specification

   We believe that in order for MPTCP to progress to Standard Standards Track,
   the ADD_ADDR attack must be addressed.  We believe that the solution
   that should be adopted in order to deal with this attack is to
   include an HMAC to the ADD_ADDR message (with the address being added
   used as input to the HMAC, HMAC as well as the key).  This would make the
   ADD_ADDR message as secure as the JOIN message.  In addition, this
   implies that if we implement a more secure way to create the key used
   in the MPTCP connection, then the security of both the MP_JOIN and
   the ADD_ADDR messages is automatically improved (since both use the
   same key in the HMAC).

   We believe that this is enough for MPTCP to progress as a Standard
   track document, Standards
   Track document because the security level is similar to single path
   TCP, as results from single-path
   TCP per our previous analysis.  Moreover, the security level achieved
   with these changes is exactly the same as other
   Standard Standards Track
   documents.  In particular, this would be the same security level as
   SCTP with dynamic addresses as defined in [RFC5061].  The Security Consideration
   Considerations section of RFC5061 RFC 5061 (which is a
   Standard Standards Track
   document) reads:

      The addition and or deletion of an IP address to an existing
      association does provide an additional mechanism by which existing
      associations can be hijacked.  Therefore, this document requires
      the use of the authentication mechanism defined in [RFC4895] to
      limit the ability of an attacker to hijack an association.

      Hijacking an association by using the addition and deletion of an
      IP address is only possible for an attacker who is able to
      intercept the initial two packets of the association setup when
      the SCTP-AUTH extension is used without pre-shared keys.  If such
      a threat is considered a possibility, then the [RFC4895] extension
      must
      MUST be used with a preconfigured shared endpoint pair key to
      mitigate this threat.

   This is the same security level that would be achieved by MPTCP plus with
   the addition of the ADD_ADDR security measure reccommended.

7.1. recommended in this
   document.

7.2.  Security enhancements Enhancements for MPTCP

   We also believe that is worthwhile exploring to explore alternatives to secure
   MPTCP.  As we identified earlier, the problem is of securing JOIN
   messages is fundamentally incompatible with NAT support, so it is
   likely that a solution to this problem involves the protection of the
   data itself.  Exploring the integration of MPTCP and approaches like
   TCPCrypt [I-D.bittau-tcp-crypt] or
   tcpcrypt [TCPCRYPT] and exploring integration with SSL seem
   promising venues.
   promising.

8.  Security considerations Considerations

   This whole document is about security considerations for MPTCP.

9.  IANA Considerations

   There are no IANA considerations in this memo.

11.  References

11.1.

9.1.  Normative References

   [RFC0793]  Postel, J., "Transmission Control Protocol", STD 7, RFC
              793, DOI 10.17487/RFC0793, September 1981. 1981,
              <http://www.rfc-editor.org/info/rfc793>.

   [RFC3972]  Aura, T., "Cryptographically Generated Addresses (CGA)",
              RFC 3972, DOI 10.17487/RFC3972, March 2005. 2005,
              <http://www.rfc-editor.org/info/rfc3972>.

   [RFC4895]  Tuexen, M., Stewart, R., Lei, P., and E. Rescorla,
              "Authenticated Chunks for the Stream Control Transmission
              Protocol (SCTP)", RFC 4895, DOI 10.17487/RFC4895, August
              2007, <http://www.rfc-editor.org/info/rfc4895>.

   [RFC5061]  Stewart, R., Xie, Q., Tuexen, M., Maruyama, S., and M.
              Kozuka, "Stream Control Transmission Protocol (SCTP)
              Dynamic Address Reconfiguration", RFC 5061, DOI 10.17487/
              RFC5061, September 2007,
              <http://www.rfc-editor.org/info/rfc5061>.

   [RFC5961]  Ramaiah, A., Stewart, R., and M. Dalal, "Improving TCP's
              Robustness to Blind In-Window Attacks", RFC 5961, DOI
              10.17487/RFC5961, August
              2010. 2010,
              <http://www.rfc-editor.org/info/rfc5961>.

   [RFC6056]  Larsen, M. and F. Gont, "Recommendations for Transport-
              Protocol Port Randomization", BCP 156, RFC 6056, DOI
              10.17487/RFC6056, January
              2011. 2011,
              <http://www.rfc-editor.org/info/rfc6056>.

   [RFC6528]  Gont, F. and S. Bellovin, "Defending against Sequence
              Number Attacks", RFC 6528, DOI 10.17487/RFC6528, February 2012.

   [RFC5061]  Stewart, R., Xie, Q., Tuexen, M., Maruyama, S., and M.
              Kozuka, "Stream Control Transmission Protocol (SCTP)
              Dynamic Address Reconfiguration", RFC 5061, September
              2007.

   [RFC4895]  Tuexen, M., Stewart, R., Lei, P., and E. Rescorla,
              "Authenticated Chunks for the Stream Control Transmission
              Protocol (SCTP)", RFC 4895, August 2007.
              2012, <http://www.rfc-editor.org/info/rfc6528>.

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

11.2. 2013,
              <http://www.rfc-editor.org/info/rfc6824>.

9.2.  Informative References

   [RFC6181]

   [DNSSEC]   Kukec, A., Bagnulo, M., "Threat Analysis Ayaz, S., Bauer, C., and W. Eddy,
              "ROAM-DNSSEC: Route Optimization for TCP Extensions Aeronautical Mobility
              using DNSSEC", 4th ACM International Workshop on Mobility
              in the Evolving Internet Architecture (MobiArch), 2009.

   [HASH-CHAINS]
              Diez, J., Bagnulo, M., Valera, F., and I. Vidal, "Security
              for
              Multipath Operation multipath TCP: a constructive approach", International
              Journal of Internet Protocol Technology, Vol. 6, No. 3,
              2011.

   [MPTCP-SSL]
              Paasch, C. and O. Bonaventure, "Securing the MultiPath TCP
              handshake with Multiple Addresses", external keys", Work in Progress, draft-
              paasch-mptcp-ssl-00, October 2012.

   [RFC2827]  Ferguson, P. and D. Senie, "Network Ingress Filtering:
              Defeating Denial of Service Attacks which employ IP Source
              Address Spoofing", BCP 38, RFC 6181,
              March 2011. 2827, DOI 10.17487/RFC2827,
              May 2000, <http://www.rfc-editor.org/info/rfc2827>.

   [RFC4960]  Stewart, R., Ed., "Stream Control Transmission Protocol",
              RFC 4960, DOI 10.17487/RFC4960, September 2007,
              <http://www.rfc-editor.org/info/rfc4960>.

   [RFC4987]  Eddy, W., "TCP SYN Flooding Attacks and Common
              Mitigations", RFC 4987, DOI 10.17487/RFC4987, August 2007,
              <http://www.rfc-editor.org/info/rfc4987>.

   [RFC5533]  Nordmark, E. and M. Bagnulo, "Shim6: Level 3 Multihoming
              Shim Protocol for IPv6", RFC 5533, DOI 10.17487/RFC5533,
              June 2009.

   [RFC4960]  Stewart, R., "Stream Control Transmission Protocol", 2009, <http://www.rfc-editor.org/info/rfc5533>.

   [RFC6181]  Bagnulo, M., "Threat Analysis for TCP Extensions for
              Multipath Operation with Multiple Addresses", RFC
              4960, September 2007. 6181,
              DOI 10.17487/RFC6181, March 2011,
              <http://www.rfc-editor.org/info/rfc6181>.

   [RFC6275]  Perkins, C., Ed., Johnson, D., and J. Arkko, "Mobility
              Support in IPv6", RFC 6275, DOI 10.17487/RFC6275, July 2011.

   [RFC2827]  Ferguson, P. and D. Senie, "Network Ingress Filtering:
              Defeating Denial of Service Attacks which employ IP Source
              Address Spoofing", BCP 38, RFC 2827, May 2000.
              2011, <http://www.rfc-editor.org/info/rfc6275>.

   [RFC7039]  Wu, J., Bi, J., Bagnulo, M., Baker, F., and C. Vogt, Ed.,
              "Source Address Validation Improvement (SAVI) Framework",
              RFC 7039, DOI 10.17487/RFC7039, October 2013.

   [RFC4987]  Eddy, W., "TCP SYN Flooding Attacks and Common
              Mitigations", RFC 4987, August 2007.

   [I-D.paasch-mptcp-ssl]
              Paasch, C. and O. Bonaventure, "Securing the MultiPath TCP
              handshake with external keys", draft-paasch-mptcp-ssl-00
              (work in progress), October 2012.

   [I-D.bittau-tcp-crypt] 2013,
              <http://www.rfc-editor.org/info/rfc7039>.

   [TCPCRYPT]
              Bittau, A., Boneh, D., Hamburg, M., Handley, M., Mazieres,
              D., and Q. Slack, "Cryptographic protection of TCP Streams
              (tcpcrypt)", draft-bittau-tcp-crypt-04 (work Work in progress), Progress, draft-bittau-tcp-crypt-04,
              February 2014.

   [hash-chains]
              Diez, J., Bagnulo, M., Valera, F., and I. Vidal, "Security
              for multipath TCP: a constructive approach", International
              Journal of Internet Protocol Technology 6, 2011.

   [dnssec]   Kukec, A., Bagnulo, M., Ayaz, S., Bauer, C., and W. Eddy,
              "OAM-DNSSEC: Route Optimization for Aeronautical Mobility
              using DNSSEC", 4th ACM International Workshop on Mobility
              in the Evolving Internet Architecture MobiArch 2009, 2009.

10.  Acknowledgments

Acknowledgements

   We would like to thank Mark Handley for his comments on the attacks
   and countermeasures discussed in this document.  thanks  We would also like
   to thank to Alissa
   Copper, Cooper, Phil Eardley, Yoshifumi Nishida, Barry
   Leiba, Stephen Farrell, and Stefan Winter for the their comments and review.
   reviews.

   Marcelo Bagnulo,
   Christophe Christoph Paasch, Oliver Bonaventure Bonaventure, and Costin
   Raiciu are partially funded by the EU Trilogy 2 project.

Authors' Addresses

   Marcelo Bagnulo
   Universidad Carlos III de Madrid
   Av. Universidad 30
   Leganes, Madrid  28911
   SPAIN
   Spain

   Phone: 34 91 6249500
   Email: marcelo@it.uc3m.es
   URI:   http://www.it.uc3m.es

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

   Email: christoph.paasch@uclouvain.be christoph.paasch@gmail.com

   Fernando Gont
   SI6 Networks / UTN-FRH
   Evaristo Carriego 2644
   Haedo, Provincia de Buenos Aires  1706
   Argentina

   Phone: +54 11 4650 8472
   Email: fgont@si6networks.com
   URI:   http://www.si6networks.com

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

   Email: olivier.bonaventure@uclouvain.be
   Costin Raiciu
   Universitatea Politehnica Bucuresti
   Splaiul Independentei 313a
   Bucuresti
   Romania

   Email: costin.raiciu@cs.pub.ro