One document matched: draft-ietf-mptcp-attacks-04.xml

<?xml version="1.0" encoding="UTF-8"?>

<!DOCTYPE rfc SYSTEM "rfc2629.dtd">

<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>

<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc strict="no" ?>
<rfc obsoletes="" updates="" category="info" ipr="trust200902" 
docName="draft-ietf-mptcp-attacks-04">
<front>
	<title abbrev="MPTCP Residual Threats">
	Analysis of MPTCP residual threats and possible fixes
	</title>


	<author initials="M." surname="Bagnulo" fullname="Marcelo Bagnulo">
		<organization abbrev="UC3M">
		Universidad Carlos III de Madrid
		</organization>
		<address>
		<postal>
		<street>Av. Universidad 30</street>
		<city>Leganes</city>
		<region>Madrid</region>
		<code>28911</code>
		<country>SPAIN</country>					
		</postal>
		<phone>34 91 6249500</phone>
		<email>marcelo@it.uc3m.es</email>
		<uri>http://www.it.uc3m.es</uri>
		</address>
	</author>

	<author initials="C." surname="Paasch" fullname="Christoph Paasch">
		<organization abbrev="UCLouvain">
		UCLouvain
		</organization>
		<address>
		<postal>
		<street>Place Sainte Barbe, 2</street>
		<city>Louvain-la-Neuve,   1348</city>
		<country>Belgium</country>					
		</postal>
		<email>christoph.paasch@uclouvain.be</email>
		</address>
	</author>

	<author fullname="Fernando Gont" initials="F." surname="Gont">
		<organization abbrev="SI6 Networks / UTN-FRH">SI6 Networks / UTN-FRH</organization>
		<address>
			<postal>
		          <street>Evaristo Carriego 2644</street>
		          <code>1706</code>
		          <city>Haedo</city>
		          <region>Provincia de Buenos Aires</region>
		          <country>Argentina</country>
			</postal>

			<phone>+54 11 4650 8472</phone>
			<email>fgont@si6networks.com</email>
			<uri>http://www.si6networks.com</uri>
		</address>
	</author>

	<author fullname="Olivier Bonaventure" initials="O." surname="Bonaventure">
		<organization abbrev="UCLouvain">
		UCLouvain
		</organization>
		<address>
		<postal>
		<street>Place Sainte Barbe, 2</street>
		<city>Louvain-la-Neuve,   1348</city>
		<country>Belgium</country>					
		</postal>
		<email>olivier.bonaventure@uclouvain.be</email>
		</address>
	</author>

	<author fullname="Costin Raiciu" initials="C." surname="Raiciu">
	  <organization abbrev="UPB">Universitatea Politehnica Bucuresti</organization>
	
	  <address>
	    <postal>
	      <street>Splaiul Independentei 313a</street>
	
	      <city>Bucuresti</city>
	
	      <country>Romania</country>
	    </postal>
	
	    <email>costin.raiciu@cs.pub.ro</email>
	  </address>
	</author>


	<date year="2015"/>

	<abstract>
	<t> This documents performs an analysis of the residual threats for MPTCP and explores possible solutions to them.
	</t>
	</abstract>
</front>

<middle>
<section title="Introduction">

<t>	This document provides a complement to the threat analysis for Multipath TCP (MPTCP) <xref target="RFC6824"/> 
	documented in RFC 6181 <xref target="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 <xref target="RFC5533"/>, 
	SCTP <xref target="RFC4960"/> and MIPv6 <xref target="RFC6275"/> for designing MPTCP. Thus, RFC 6181 was produced before 
	the actual MPTCP specification (RFC6824) was completed, and documented a set of reccommendations 
	that were considered during the production of such specification.</t>

<t>	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 identified security issues.</t>

<t>	The goal of the security mechanisms defined in RFC 6824 were 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) that are not possible with (single-path) 
	TCP. This means that threats that are common to TCP and MPTCP are not covered in this document. </t>

<t>	Types of attackers: for all attacks considered in this document, we identify the type
	of attacker.

	We can classify the attackers based on their location as follows:
	<list style="symbols">
	<t>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 attacker cannot eavesdrop any of the packets of the MPTCP session.</t>
	<t> 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 the entire lifetime of the MPTCP session. The attacker can be in the 
	forward and/or backward directions, for the initial subflow and/or other subflows. The specific
	needs of the attacker will be made explicit in the attack description.</t>  
	<t> 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, for the initial 
	subflow and/or other subflows. The specific needs of the attacker will be made explicit in the 
	attack description.</t>
	</list></t>

	<t>We can also classify the attackers based on their actions as follows:
    <list style ="symbols">
	<t> 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 or delaying any packet of the MPTCP session.
	The attacker can be in the forward and/or backward directions, for the initial subflow and/or 
	other subflows. The specific needs of the attacker will be made explicit in the attack description.</t>
	<t> Active attacker. The attacker is able to change, discard or delay some of the packets of the 
	MPTCP session. The attacker can be in the forward and/or backward directions, for the initial 
	subflow and/or other subflows. The specific needs of the attacker will be made explicit in the 
	attack description.</t>
    </list></t>

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

	<list style="symbols">

	<t>an On-path eavesdropper</t>
	<t>an On-path active attacker </t>
	<t>an Off-path active attacker</t>
	<t>a Partial-time On-path eavesdropper </t>
	<t>a Partial-time On-path active attacker</t>
    </list></t>

<t>	In the rest of the document we describe different attacks that are possible against the MPTCP protocol specified in RFC6824
	and we propose possible security enhancements to address them.</t>
</section>

<section title="ADD_ADDR attack">
	
<t>Summary of the attack:

<list>
<t>Type of attack: MPTCP session hijack enabling Man-in-the-Middle.</t>
<t>Type of attacker: Off-path, active attacker.</t>
</list></t>

<t>Description: </t>

<t>In this attack, the attacker uses the ADD_ADDR option defined in RFC6824 to hijack an ongoing MPTCP session
and enables himself to perform a Man-in-the-Middle attack on the MPTCP session.</t>

<t>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 A and port PB on host B.
The tokens for the MPTCP session are TA and TB for Host A and Host B respectively.
Host C is the attacker. It owns address IPC.
The attack is executed as follows:

<list style="numbers">
<t>Host C sends a forged packet with source address IPA, destination address IPB, source port PA and destination port PB.
The packet has the ACK flag set. The TCP sequence number for the segment is i and the 
ACK sequence number is j. We will assume all these are valid, we discuss what the attacker needs to figure  
these ones later on.  
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 address identifier which does not bring any strong security benefit.</t>

<t>Host B receives the ADD_ADDR message and it replies by sending a TCP SYN packet. 
(Note: the MPTCP specification 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 the attack will not succeed. For example, 
on the current Linux implementation, the server does not create subflows. Only the client does so.)
The source address for the packet is IPB, the destination address for the packet is IPC, the source port is PB' 
and the destination port is PA' (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.</t>

<t>Host C receives the SYN+MP_JOIN packet from Host 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.</t>

<t>Host A receives the SYN+MP_JOIN message and it replies with a 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 and places it in the MP_JOIN option.</t>

<t>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 impersonating Host A.</t>

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

<t>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 impersonating Host B.</t>

<t>Host A receives the ACK+MP_JOIN message and creates the new subflow.
<list style="hanging">
<t>At this 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 IPA and IPB that does not flow through the 
attacker, so the attacker has not completely intercepted all the packets in the communication (yet).
If the attacker wishes to completely intercept the MPTCP session it can do the following additional step.</t>
</list>
</t>

<t>Host C sends two TCP RST messages. One TCP RST packet is sent to Host B, with source address IPA and destination 
	address 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 destination address 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 number and ACK value. 
	If there are more subflows, then the attacker needs to find the Sequence Number and ACK for each subflow.
<list style="hanging">
<t>At this point the attacker has managed to fully hijack the MPTCP session.</t>
</list>
</t>

</list>
</t>


<t>Information required by the attacker to perform the described attack:</t>

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

<list style="symbols">
<t>the four-tuple {Client-side IP Address, Client-side Port, Server-side Address, Servcer-side Port} that identifies the target TCP connection</t>
<t>a valid sequence number for the subflow</t>
<t>a valid ACK sequence number for the subflow</t>
<t>a valid address identifier for IPC</t>
</list></t>

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

<list style="hanging">
<t>We note that 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 <xref target="RFC2827"/>  or source 
address validation <xref target="RFC7039"/> are deployed. However, ingress filtering is not as widely 
implemented as one would expect, and hence cannot be relied upon as a mitigation for this kind of attack.</t>
</list>

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, 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, and whether the client implements port randomization <xref target="RFC6056"/>.</t>

<t>Assuming TCP sequence number randomization is in place (see e.g. <xref target="RFC6528"/>), an attacker would have to blindly guess a valid TCP sequence number. That is,
<list style="hanging">
<t>
RCV.NXT =< SEG.SEQ < RCV.NXT+RCV.WND or RCV.NXT =< SEG.SEQ+SEG.LEN-1 < RCV.NXT+RCV.WND</t>
</list>
As a result, the chances of an attacker to succeed will depend on the TCP receive window size at the target TCP peer. 

<list style="hanging">
<!-- <t><xref target="RFC4953"/> contains an analysis on the number of packets and the amount of time needed for a TCP blind-attack to succeed.</t> -->
<t>We note that automatic TCP buffer tuning mechanisms have been become common for popular TCP implementations, and hence very large TCP window sizes of values up to 2 MB could end up being employed by such TCP implementations.</t>
</list>
</t>

<t>According to <xref target="RFC0793"/>, the 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:
<list style="hanging">
<t>SEG.ACK <= SND.NXT</t>
</list>
However, for implementations that support <xref target="RFC5961"/>, the following (stricter) validation check is enforced:
<list style="hanging">
<t>
SND.UNA - SND.MAX.WND <= SEG.ACK <= SND.NXT
</t>
</list>
</t>

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


<t>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 <xref target="RFC5961"/>, and another for MPTCP implementations that do not.
</t>

<t>Implementations that do not support RFC 5961</t>

<t>Packets = (2^32/(RCV_WND)) * 2 * EPH_PORT_SIZE/2 * 1/MSS</t>
<!-- [fgont] Me, I'd remove the "/2 * 1/MSS" from the expression above -->
<t>Where the new :

<list style="hanging">
<t hangText="Packets:">
<vspace blankLines="0" />Maximum number of packets required to successfully perform an off-path (blind) attack.</t>
<t hangText="RCV_WND:">
<vspace blankLines="0" />TCP receive window size (RCV.WND) at the target node.</t>
<t hangText="EPH_PORT_SIZE:">
<vspace blankLines="0" />Number of ports comprising the ephemeral port range at the "client" system.</t>
<t hangText="MSS:">
<vspace blankLines="0" />Maximum Segment Size, assuming the attacker will send full segments to maximize the chances to get a hit.</t>

</list>

<list style="hanging">
<t hangText="Notes:">
<vspace blankLines="0" />The value "2^32" represents the size of the TCP sequence number space.
<vspace blankLines="0" />The value "2" accounts for 2 different ACK numbers (separated by 2^31) that should be employed to make sure the ACK number is valid.</t>
</list>
</t>

<t>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 MSS of 1500 bytes.
</t>

    <texttable title="Max. Number of Packets for Successful Attack" style="all" anchor="table-packets-1">
        <ttcol align="center">Ports \ Win</ttcol>
        <ttcol align="center">16 KB</ttcol>
        <ttcol align="center">128 KB</ttcol>
        <ttcol align="center">256 KB</ttcol>
        <ttcol align="center">2048 KB</ttcol>
        <c>4000</c>
	<c>699050</c>
	<c>87381</c>
	<c>43690</c>
	<c>5461</c>
        <c>10000</c>
	<c>1747626</c>
	<c>218453</c>
	<c>109226</c>
	<c>13653</c>
        <c>50000</c>
	<c>8738133</c>
	<c>1092266</c>
	<c>546133</c>
	<c>68266</c>
    </texttable>
<!--
<t>It should be noted that the aforementioned computations assume that no data are being transferred over the corresponding TCP connection. Otherwise, the computations become more complex, since the valid Sequence Numbers and Acknowledgement Numbers will vary as data are transferred over the connection.
</t> --> 

<t>Implementations that do support RFC 5961</t>

<t>Packets = (2^32/(RCV_WND)) * (2^32/(2 * SND_MAX_WND)) * EPH_PORT_SIZE/2 * 1/MSS</t>
<!-- [fgont] Me, I'd remove the "/2 * 1/MSS" from the expression above -->
<t>
Where:

<list style="hanging">
<t hangText="Packets:">
<vspace blankLines="0" />Maximum number of packets required to successfully perform an off-path (blind) attack.</t>
<t hangText="RCV_WND:">
<vspace blankLines="0" />TCP receive window size (RCV.WND) at the target MPTCP endpoint.</t>
<t hangText="SND_MAX_WND:">
<vspace blankLines="0" />Maximum TCP send window size ever employed by the target MPTCP end-point (SND.MAX.WND).</t>
<t hangText="EPH_PORT_SIZE:">
<vspace blankLines="0" />Number of ports comprising the ephemeral port range at the "client" system.</t>
</list>

<list style="hanging">
<t hangText="Notes:">
<vspace blankLines="0" />The value "2^32" represents the size of the TCP sequence number space.
<vspace blankLines="0" />The parameter "SND_MAX_WND" is specified in <xref target="RFC5961"/>.
<vspace blankLines="0" />The value "2*SND_MAX_WND" results from the expresion "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).</t>
</list>
</t>

<t>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 an indication of how <xref target="RFC5961"/> increases the difficulty of performing these attacks.
</t>

    <texttable title="Max. Number of Packets for Successful Attack" style="all" anchor="table-packets-2">
        <ttcol align="center">Ports \ Win</ttcol>
        <ttcol align="center">16 KB</ttcol>
        <ttcol align="center">128 KB</ttcol>
        <ttcol align="center">256 KB</ttcol>
        <ttcol align="center">2048 KB</ttcol>
        <c>4000</c>
	<c>45812984490</c>
	<c>715827882</c>
	<c>178956970</c>
	<c>2796202</c>
    </texttable>
<t>
<list style="hanging">
<t hangText="Note:">
<vspace blankLines="0" />In the aforementioned table, all values are computed with RCV_WND equal to SND_MAX_WND.</t>
</list>
</t>
<!-- [fgont] I removed the comments that were here, such that old comments don't distract you from the new ones -->


<section title="Possible security enhancements to prevent this attack">
<t>
<list style="numbers">
<t>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 needs to either eavesdrop the token (so this 
can no longer be a blind attack) or to guess it, but a random 32 bit number is not so easy to guess.
However, this would imply that any eavesdropper that is able to see the 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. </t>

<t>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. using SSL keys as has been 
proposed).</t>

<!--
<t>To include the destination address of the ADD_ADDR message in the HMAC. This would certainly make 
the attack harder (the attacker would need to know the key). 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). 
Probably it would make sense to combine it with option 2) (i.e. to have the HMAC of the address in the ADD_ADDR 
option and the destination address of the packet).</t>
-->
<t>To include the destination address of the SYN packet in the HMAC of the MP_JOIN message.
	As the attacker requires to change 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).
<!--This has the same problems than option 3) in the presence of NATs.--></t>
</list>
</t>

<t>Out of the options described above, option 2 is reccommended as it achieves a higher security level while
	preserving the required functionality (i.e. NAT compatibility).</t> 

</section>
</section>

<section title="DoS attack on MP_JOIN">

<t>Summary of the attack:
<list>
<t>Type of attack: MPTCP Denial-of-Service attack, preventing the hosts from creating new subflows.</t>
<t>Type of attacker: Off-path, active attacker</t>
</list></t>

<t>Description: </t>

<t>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 and the 32-bit random nonce, used in the HMAC calculation.
As this information is not resent in the third ACK of the 3-way handshake, a host must create
state upon reception of a SYN+MP_JOIN.</t>

<t>Assume that there exists an MPTCP-session between host A and host B, with token Ta and Tb.
An attacker, sending a SYN+MP_JOIN to host B, with the valid token Tb, will trigger the creation
of state on host B. The number of these half-open connections a host can store per
MPTCP-session is limited by a certain number, and it is 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 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 attacks and common mitigations can be found in <xref target="RFC4987"/></t>

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

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

<section title="Possible security enhancements to prevent this attack">

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

</section>
</section>

<section title="SYN flooding amplification">

<t>Summary of the attack: 
<list>
<t>Type of attack: The attacker can use the SYN+MP_JOIN messages to amplify the SYN flooding attack.</t>
<t>Type of attacker: Off-path, active attacker</t>
</list></t>

<t>Description:</t>

<t>SYN flooding attacks <xref target="RFC4987"/> use SYN messages to exhaust the server's resources and prevent
new TCP connections. A common mitigation is the use of SYN cookies <xref target="RFC4987"/> that allow the 
stateless processing of the initial SYN message. </t>

<t>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 MPTCP session by sending a regular SYN and creating the associated
state but then send as many SYN+MP_JOIN messages as supported by the server with different source 
address source port combinations, consuming 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 all the following SYN+MP_JOIN.</t>

<section title="Possible security enhancements to prevent this attack">


<t>
<list style="numbers">
<t>The solution described for the previous DoS attack on MP_JOIN would also prevent this attack.</t>
<t>Limiting the number of half open subflows to a low number (e.g. 3 subflows) would also limit the 
impact of this attack.</t>
</list>
</t>
</section>
</section>

<section title="Eavesdropper in the initial handshake">

<t>Summary of the attack
<list>
<t>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.</t>
<t>Type of attacker: a Partial-time On-path eavesdropper</t> 
</list></t>

<t>Description:</t>

<t>In this case, the attacker is present along the path when the initial 3-way handshake takes 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 the MPTCP security solution and the 
threat was considered acceptable.</t>

<section title="Possible security enhancements to prevent this attack">

<t>There are many techniques that can be used to prevent this attack and each of them represents different tradeoffs. At this point, we limit ourselves to enumerate them and provide useful pointers.
<list style="numbers">

<t>Use of hash-chains. The use of hash chains for MPTCP has been explored in <xref target="hash-chains"/> </t>
<t>Use of SSL keys for MPTCP security as described in  <xref target="I-D.paasch-mptcp-ssl"/></t>
<t>Use of Cryptographically-Generated Addresses (CGAs) for MPTCP security. CGAs <xref target="RFC3972"/> have been used in the past to secure multi addressed
protocols like SHIM6 <xref target="RFC5533"/>. </t>
<t>Use of TCPCrypt <xref target="I-D.bittau-tcp-crypt"/></t>
<t>Use DNSSEC. DNSSEC has been proposed to secure the Mobile IP protocol <xref target="dnssec"/> </t>
</list></t>

</section>
</section>

<section title="SYN/JOIN attack">

<t>Summary of the attack
<list>
<t>Type of attack: An attacker that can intercept the SYN/JOIN message can alter the source address being added.</t>
<t>Type of attacker: a Partial-time On-path eavesdropper</t> 
</list></t>

<t>Description:</t>

<t>The attacker is present along the path when the SYN/JOIN exchange takes place, 
and 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 the MPTCP security solution and the 
threat was considered acceptable.</t>

<section title="Possible security enhancements to prevent this attack">

<t>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 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, limiting the impact that the attack would have in the communication (e.g. TCPCrypt <xref target="I-D.bittau-tcp-crypt"/> or similar).</t>

</section>
</section>

<section title="Reccomendations">
<t>Current MPTCP specification <xref target="RFC6824"/> is experimental. There is an ongoing effort to move it to Standards track. 
We believe that the work on MPTCP security should follow two threads:
<list style="symbols">
	<t>The work on improving MPTCP security so that is enough to become a Standard Track document.</t>
	<t>The work on analyzing possible additional security enhancements to provide a more secure version of MPTCP.</t>
</list>
We will expand on these two next.</t>

<t>MPTCP security for a Standard Track specification.</t>
<t>We believe that in order for MPTCP to progress to Standard 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, 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).</t>
<t>We believe that this is enough for MPTCP to progress as a Standard
   track document, because the security level is similar to single path TCP, as results from our previous analysis. Moreover, the security level achieved with these changes is exactly the same as other Standard Track documents. In particular, this would be the same security level as SCTP with dynamic addresses as defined in <xref target="RFC5061"/>. The Security Consideration section of RFC5061 (which is a Standard Track document) reads: 
<list><t>
	   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 be used
	   with a preconfigured shared endpoint pair key to mitigate this
	   threat.
	</t></list></t>

<t>This is the same security level that would be achieved by MPTCP plus the ADD_ADDR security measure reccommended. </t>

<section title="Security enhancements for MPTCP">
<t>We also believe that is worthwhile exploring alternatives to secure MPTCP. As we identified earlier, the problem is 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 <xref target="I-D.bittau-tcp-crypt"/> or integration with SSL seem promising venues.</t>
</section>	
</section>



<section title="Security considerations">
<t>This whole document is about security considerations for MPTCP.</t>
</section>

<section title="IANA Considerations">
<t>There are no IANA considerations in this memo.</t>
</section>


<section title="Acknowledgments">
<t>We would like to thank Mark Handley for his comments on the attacks and countermeasures discussed in this document. 
	thanks to Alissa Copper, Phil Eardley, Yoshifumi Nishida, Barry Leiba, Stephen Farrell, Stefan Winter for the comments and review.
	Marcelo Bagnulo, Christophe Paasch, Oliver Bonaventure and Costin Raiciu are partially funded by the EU Trilogy 2 project.
	</t>
</section>

</middle>

<back>


<references title='Normative References'>
	<?rfc include='reference.RFC.0793'?>
	<?rfc include='reference.RFC.3972'?>
	<?rfc include='reference.RFC.5961'?>
	<?rfc include='reference.RFC.6056'?>
	<?rfc include='reference.RFC.6528'?>
		<?rfc include='reference.RFC.5061'?>

		<?rfc include='reference.RFC.4895'?>
		<?rfc include='reference.RFC.6824'?>	
</references>

<references title='Informative References'>

	<?rfc include='reference.RFC.6181'?>
	<?rfc include='reference.RFC.5533'?>
	<?rfc include='reference.RFC.4960'?>
	<?rfc include='reference.RFC.6275'?>
	<?rfc include='reference.RFC.2827'?>
    	<?rfc include='reference.RFC.7039'?>
<!--	<?rfc include='reference.RFC.4953'?> -->
	<?rfc include='reference.RFC.4987'?>
	<?rfc include='reference.I-D.paasch-mptcp-ssl'?>
	<?rfc include='reference.I-D.bittau-tcp-crypt'?>
		
	<reference anchor='hash-chains'>
		<front>
		<title>Security for multipath TCP: a constructive approach</title>

		<author initials='J.' surname='Diez' fullname='Javier Diez'>
		    <organization />
		</author>

		<author initials='M.' surname='Bagnulo' fullname='Marcelo Bagnulo'>
		    <organization />
		</author>

		<author initials='F.' surname='Valera' fullname='Francisco Valera'>
		    <organization />
		</author>

		<author initials='I.' surname='Vidal' fullname='Ivan Vidal'>
		    <organization />
		</author>

		<date year='2011' />

		<abstract><t>Multipath TCP (MPTCP) is a new protocol being developed in the IETF's MPTCP working 
		group in order to provide higher communication availability and to improve the throughput 
		between two multi-addressed endpoints by using multiple paths. Due to the multipath nature 
		and specifically its path management, some new security threats arise apart from those that 
		are already present in standard single-path TCP. These new attacks include flooding and 
		hijacking attacks performed by an off-path attacker.</t></abstract>

		</front>

		<seriesInfo name='International Journal of Internet Protocol Technology' value='6' />
		<format type='TXT' />
	</reference>

	<reference anchor='dnssec'>
		<front>
		<title>OAM-DNSSEC: 
			Route Optimization for Aeronautical Mobility using DNSSEC</title>

		<author initials='A.' surname='Kukec' fullname='Ana Kukec'>
		    <organization />
		</author>

		<author initials='M.' surname='Bagnulo' fullname='Marcelo Bagnulo'>
		    <organization />
		</author>

		<author initials='S.' surname='Ayaz' fullname='S. Ayaz'>
		    <organization />
		</author>

		<author initials='C.' surname='Bauer' fullname='C. Bauer'>
		    <organization />
		</author>

		<author initials='W.' surname='Eddy' fullname='Wes Eddy'>
		    <organization />
		</author>


		<date year='2009' />


		</front>

		<seriesInfo name='4th ACM International Workshop on Mobility in the Evolving Internet Architecture' 
		 value='MobiArch 2009' />
		
		<format type='TXT' />
	</reference>

</references>
</back>
</rfc>