draft-ietf-mptcp-threat-02.txt   draft-ietf-mptcp-threat-03.txt 
Network Working Group M. Bagnulo Network Working Group M. Bagnulo
Internet-Draft UC3M Internet-Draft UC3M
Intended status: Informational March 29, 2010 Intended status: Informational October 4, 2010
Expires: September 30, 2010 Expires: April 7, 2011
Threat Analysis for Multi-addressed/Multi-path TCP Threat Analysis for Multi-addressed/Multi-path TCP
draft-ietf-mptcp-threat-02 draft-ietf-mptcp-threat-03
Abstract Abstract
Multi-addresses/Multi-path TCP (MPTCP for short) describes the Multi-addresses/Multi-path TCP (MPTCP for short) describes the
extensions proposed for TCP so that each endpoint of a given TCP extensions proposed for TCP so that each endpoint of a given TCP
connection can use multiple IP addresses to exchange data (instead of connection can use multiple IP addresses to exchange data (instead of
a single IP address per endpoint as currently defined). Such a single IP address per endpoint as currently defined). Such
extensions enable the exchange of segments using different source- extensions enable the exchange of segments using different source-
destination address pairs, resulting in the capability of using destination address pairs, resulting in the capability of using
multiple paths in a significant number of scenarios. In particular, multiple paths in a significant number of scenarios. In particular,
some level of multihoming and mobility support can be achieved some level of multihoming and mobility support can be achieved
through these extensions. However, the support for multiple IP through these extensions. However, the support for multiple IP
addresses per endpoint may have implications on the security of the addresses per endpoint may have implications on the security of the
resulting MPTCP protocol. This note includes a threat analysis for resulting MPTCP protocol. This note includes a threat analysis for
MPTCP. MPTCP.
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF). Note that other groups may also distribute
other groups may also distribute working documents as Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at This Internet-Draft will expire on April 7, 2011.
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on September 30, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
skipping to change at page 2, line 15 skipping to change at page 2, line 10
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Related work . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Related work . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Basic MPTCP. . . . . . . . . . . . . . . . . . . . . . . . . . 6 4. Basic MPTCP. . . . . . . . . . . . . . . . . . . . . . . . . . 6
5. Flooding attacks . . . . . . . . . . . . . . . . . . . . . . . 7 5. Flooding attacks . . . . . . . . . . . . . . . . . . . . . . . 7
6. Hijacking attacks . . . . . . . . . . . . . . . . . . . . . . 9 6. Hijacking attacks . . . . . . . . . . . . . . . . . . . . . . 10
6.1. Hijacking attacks to the Basic MPTCP protocol . . . . . . 9 6.1. Hijacking attacks to the Basic MPTCP protocol . . . . . . 10
6.2. Time-shifted hijacking attacks . . . . . . . . . . . . . . 12 6.2. Time-shifted hijacking attacks . . . . . . . . . . . . . . 12
6.3. NAT considerations . . . . . . . . . . . . . . . . . . . . 13 6.3. NAT considerations . . . . . . . . . . . . . . . . . . . . 14
7. Reccomendation . . . . . . . . . . . . . . . . . . . . . . . . 14 7. Reccommendation . . . . . . . . . . . . . . . . . . . . . . . 14
8. Security Considerations . . . . . . . . . . . . . . . . . . . 14 8. Security Considerations . . . . . . . . . . . . . . . . . . . 15
9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 14 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 15
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15
11. Informative References . . . . . . . . . . . . . . . . . . . . 15 11. Informative References . . . . . . . . . . . . . . . . . . . . 15
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 15 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 16
1. Introduction 1. Introduction
Multi-addresses/Multi-path TCP (MPTCP for short) describes the Multi-addresses/Multi-path TCP (MPTCP for short) describes the
extensions proposed for TCP so that each endpoint of a given TCP extensions proposed for TCP so that each endpoint of a given TCP
connection can use multiple IP addresses to exchange data (instead of connection can use multiple IP addresses to exchange data (instead of
a single IP address per endpoint as currently defined). Such a single IP address per endpoint as currently defined). Such
extensions enable the exchange of segments using different source- extensions enable the exchange of segments using different source-
destination address pairs, resulting in the capability of using destination address pairs, resulting in the capability of using
multiple paths in a significant number of scenarios. In particular, multiple paths in a significant number of scenarios. In particular,
skipping to change at page 4, line 28 skipping to change at page 4, line 28
3. Related work 3. Related work
There is significant amount of previous work in terms of analysis of There is significant amount of previous work in terms of analysis of
protocols that support address agility. In this section we present protocols that support address agility. In this section we present
the most relevant ones and we relate them to the current MPTCP the most relevant ones and we relate them to the current MPTCP
effort. effort.
Most of the problems related to address agility have been deeply Most of the problems related to address agility have been deeply
analyzed and understood in the context of Route Optimization support analyzed and understood in the context of Route Optimization support
in Mobile IPv6 (MIPv6 RO). [RFC4225] includes the rational for the in Mobile IPv6 (MIPv6 RO) [RFC3775]. [RFC4225] includes the rational
design of the security of MIPv6 RO. All the attacks described in the for the design of the security of MIPv6 RO. All the attacks
aforementioned analysis apply here and are an excellent basis for our described in the aforementioned analysis apply here and are an
own analysis. The main differences are: excellent basis for our own analysis. The main differences are:
In MIPv6 RO, the address binding affects all the communications In MIPv6 RO, the address binding affects all the communications
involving an address, while in the MPTCP case, a single connection involving an address, while in the MPTCP case, a single connection
is at stake. In other words, if a binding between two address is is at stake. In other words, if a binding between two address is
created at the IP layer, this binding can and will affect all the created at the IP layer, this binding can and will affect all the
connections that involve those addresses. However, in MPTCP, if connections that involve those addresses. However, in MPTCP, if
an additional address is added to an ongoing TCP connection, the an additional address is added to an ongoing TCP connection, the
additional address will/can only affect the connection at hand and additional address will/can only affect the connection at hand and
not other connections even if the same address is being used for not other connections even if the same address is being used for
those other connections. The result is that in MPTCP there is those other connections. The result is that in MPTCP there is
much less at stake and the resulting vulnerabilities are less. On much less at stake and the resulting vulnerabilities are less. On
skipping to change at page 5, line 10 skipping to change at page 5, line 10
In MIPv6 RO, there is the assumption that the original path In MIPv6 RO, there is the assumption that the original path
through which the connection has been established is always through which the connection has been established is always
available and in case it is not, the communication will be lost. available and in case it is not, the communication will be lost.
In MPTCP, it is an explicit goal to provide communication In MPTCP, it is an explicit goal to provide communication
resilience when one of the address pairs is no longer usable, so resilience when one of the address pairs is no longer usable, so
it is not possible to leverage on the original address pair to be it is not possible to leverage on the original address pair to be
always working. always working.
MIPv6 RO is of course designed for IPv6 and it is an explicit goal MIPv6 RO is of course designed for IPv6 and it is an explicit goal
of MPTCP to support both IPv6 and IPv4. Some MIPv6 RO security of MPTCP to support both IPv6 and IPv4. Some MIPv6 RO security
solutions rely on the usage of some characteristics of IPv6 (such solutions rely on the usage of some characteristics of IPv6 (such
as the usage of CGAs [RFC3972]), which will no be usable in the as the usage of CGAs [RFC3972]), which will not be usable in the
context of MPTCP. context of MPTCP.
As opposed to MPTCP, MIPv6 RO does not have a connection state
information, including sequence numbers, port that could be
leveraged to provide security in some form.
In the Shim6 design, similar issues related to address agility were In the Shim6 [RFC5533] design, similar issues related to address
considered and a threat analysis was also performed [RFC4218]. The agility were considered and a threat analysis was also performed
analysis performed for Shim6 also largely applies to the MPTCP [RFC4218]. The analysis performed for Shim6 also largely applies to
context, the main difference being: the MPTCP context, the main difference being:
Similarly to the MPTCP case, the Shim6 protocol is a layer 3 Similarly to the MPTCP case, the Shim6 protocol is a layer 3
protocol so all the communications involving the target address protocol so all the communications involving the target address
are at stake, as opposed to the MPTCP case, where the impact can are at stake, as opposed to the MPTCP case, where the impact can
be limited to a single TCP connection. be limited to a single TCP connection.
Similarly to MIPv6 RO, Shim6 only uses IPv6 addresses as Similarly to MIPv6 RO, Shim6 only uses IPv6 addresses as
identifiers and leverages on some of their properties to provide identifiers and leverages on some of their properties to provide
the security, such as relying on CGAs or HBAs [RFC5535], which is the security, such as relying on CGAs or HBAs [RFC5535], which is
not possible in the MPTCP case where IPv4 addresses must be not possible in the MPTCP case where IPv4 addresses must be
supported. supported.
Similarly to MIPv6 RO, Shim6 does not have a connection state
information, including sequence numbers, port that could be
leveraged to provide security in some form.
SCTP is a transport protocol that supports multiple addresses per SCTP [RFC2960]is a transport protocol that supports multiple
endpoint and as such, the security implications are very close to the addresses per endpoint and as such, the security implications are
ones of MPTCP. A security analysis, identifying a set of attacks and very close to the ones of MPTCP. A security analysis, identifying a
proposed solutions was performed in [RFC5062]. The results of this set of attacks and proposed solutions was performed in [RFC5062].
analysis apply directly to the case of MPTCP. However, the analysis The results of this analysis apply directly to the case of MPTCP.
was performed after the base SCTP protocol was designed and the goal However, the analysis was performed after the base SCTP protocol was
of the document was essentially to improve the security of SCTP. As designed and the goal of the document was essentially to improve the
such, the document is very specific to the actual SCTP specification security of SCTP. As such, the document is very specific to the
and relies on the SCTP messages and behaviour to characterize the actual SCTP specification and relies on the SCTP messages and
issues. While some them can be translated to the MPTCP case, some behaviour to characterize the issues. While some them can be
may be caused by specific behaviour of SCTP as defined. In translated to the MPTCP case, some may be caused by specific
particular, one issue that is different in the MPTCP case compared to behaviour of SCTP as defined.
the SCTP case is that in MPTCP it is fundamental that multiple paths
are used simultaneously, which does have security implications.
So, the conclusion is that while we do have a significant amount of So, the conclusion is that while we do have a significant amount of
previous work that is closely related and we can and will use it as a previous work that is closely related and we can and will use it as a
basis for this analysis, there are a set of characteristics that are basis for this analysis, there are a set of characteristics that are
specific to MPTCP that grant the need for a specific analysis for specific to MPTCP that grant the need for a specific analysis for
MPTCP. The goal of this analysis is to help MPTCP protocol designers MPTCP. The goal of this analysis is to help MPTCP protocol designers
to include a set of security mechanisms that prevent the introduction to include a set of security mechanisms that prevent the introduction
of new vulnerabilities to the Internet due to the adoption of MPTCP. of new vulnerabilities to the Internet due to the adoption of MPTCP.
4. Basic MPTCP. 4. Basic MPTCP.
skipping to change at page 6, line 44 skipping to change at page 6, line 45
initiator has placed on that address would be deceived. In any case, initiator has placed on that address would be deceived. In any case,
the adoption of MPTCP necessitates a slight evolution of the the adoption of MPTCP necessitates a slight evolution of the
traditional TCP trust model, in that the initiator is additionally traditional TCP trust model, in that the initiator is additionally
trusting the peer to provide additional addresses which it will trust trusting the peer to provide additional addresses which it will trust
to the same degree as the original pair. An application or to the same degree as the original pair. An application or
implementation that cannot trust the peer in this way should not make implementation that cannot trust the peer in this way should not make
use of multiple paths. use of multiple paths.
During the 3-way handshake, the sequence number will be synchronized During the 3-way handshake, the sequence number will be synchronized
for both ends, as in regular TCP. We assume that a MPTCP connection for both ends, as in regular TCP. We assume that a MPTCP connection
will use a sequence number for the data, even if the data is will use a single sequence number for the data, even if the data is
exchanged through different paths. exchanged through different paths, as MPTCP provides an in-order
delivery service of bytes
Once the connection is established, the MPTCP extensions can be used Once the connection is established, the MPTCP extensions can be used
to add addresses for each of the endpoints. In order to do that each to add addresses for each of the endpoints. In order to do that each
end will need to send a control message containing the additional end will need to send a control message containing the additional
address(es). In order to associate the additional address to an address(es). In order to associate the additional address to an
ongoing connection, the connection needs to be identified. We assume ongoing connection, the connection needs to be identified. We assume
that the connection can be identified by the 4-tuple of source that the connection can be identified by the 4-tuple of source
address, source port, destination address, destination port used for address, source port, destination address, destination port used for
the establishment of the connection. So, at least, the control the establishment of the connection. So, at least, the control
message that will convey the additional address information can also message that will convey the additional address information can also
contain the 4-tuple in order to inform about what connection the contain the 4-tuple in order to inform about what connection the
address belong to (if no other connection identifier is defined). address belong to (if no other connection identifier is defined).
There are two different ways to convey address information: There are two different ways to convey address information:
o Explicit mode: the control message contain a list of addresses. o Explicit mode: the control message contain a list of addresses.
o Implicit mode: the address added is the one included in the source o Implicit mode: the address added is the one included in the source
address field of the IP header address field of the IP header
These two modes have significantly different security properties. These two modes have different security properties for some type of
The explicit mode seems to be the more vulnerable to abuse. In attacks. The explicit mode seems to be the more vulnerable to abuse.
particular, the implicit mode may benefit from forms of ingress In particular, the implicit mode may benefit from forms of ingress
filtering security, which would reduce the possibility of an attacker filtering security, which would reduce the possibility of an attacker
to add any arbitrary address to an ongoing connection. to add any arbitrary address to an ongoing connection. However, it
should be noted that ingress filtering deployment is far from
universal, and as such it is unwise to rely on it as a basis for the
protection of MPTCP.
In addition, further consideration about the interaction between
ingress filtering and implicit mode signaling is needed in the
case that we need to remove an address that is no longer available
from the MPTCP connection. In particular a host attached to a
network that performs ingress filtering and using implicit
signaling would not be able to remove an address that is no longer
available (either because of a failure or due to a mobility event)
from an ongoing MPTCP connection.
In addition, we will assume that MPTCP will use all the address pairs In addition, we will assume that MPTCP will use all the address pairs
that it has available for sending packets and that it will distribute that it has available for sending packets and that it will distribute
the load based on congestion among the different paths. the load based on congestion among the different paths.
5. Flooding attacks 5. Flooding attacks
The first type of attacks that are introduced by address agility are The first type of attacks that are introduced by address agility are
the so called flooding (or bombing) attacks. The setup for this the so called flooding (or bombing) attacks. The setup for this
attack is depicted in the following figure: attack is depicted in the following figure:
skipping to change at page 9, line 15 skipping to change at page 9, line 35
significant attack. On the one hand it needs to grow the window significant attack. On the one hand it needs to grow the window
enough so that the flight size is big enough to cause enough effect enough so that the flight size is big enough to cause enough effect
and on the other hand the attacker needs to be able to simulate and on the other hand the attacker needs to be able to simulate
congestion on the IPA-IPS path so that traffic is actually redirected congestion on the IPA-IPS path so that traffic is actually redirected
to the alternative path without significantly reducing the window. to the alternative path without significantly reducing the window.
This will heavily depend on how the coupling of the windows between This will heavily depend on how the coupling of the windows between
the different paths works, in particular how the windows are the different paths works, in particular how the windows are
increased. Some designs of the congestion control window coupling increased. Some designs of the congestion control window coupling
could render this attack ineffective. could render this attack ineffective.
Previous protocols that have to deal with this type of attacks have Previous protocols, such as MIPv6 RO and SCTP, that have to deal with
done so by adding a reachability check before actually sending data this type of attacks have done so by adding a reachability check
to a new address. In other words, the solution used in other before actually sending data to a new address. In other words, the
protocols such as MIPv6 RO, would include the Source S to explicitly solution used in other protocols, would include the Source S to
asking the host sitting in the new address (in this case the Target T explicitly asking the host sitting in the new address (in this case
sitting in IPT) whether it is willing to accept packets from the the Target T sitting in IPT) whether it is willing to accept packets
MPTCP connection identified by the 4-tuple IPA, port A, IPS, port S. from the MPTCP connection identified by the 4-tuple IPA, port A, IPS,
Since this is not part of the established connection that Target T port S. Since this is not part of the established connection that
has, T would not accept the request and Source S would not use IPT to Target T has, T would not accept the request and Source S would not
send packets for this MPTCP connection. Usually, the request also use IPT to send packets for this MPTCP connection. Usually, the
includes a nonce that cannot be guessed by the attacker A so that it request also includes a nonce that cannot be guessed by the attacker
cannot fake the reply to the request easily. A so that it cannot fake the reply to the request easily. In
particular, In the case of SCTP, it sends a message with a 64-bit
nonce (in a HEARTBEAT).
One possible approach to do this reachability test would be to One possible approach to do this reachability test would be to
perform a 3-way handshake for each new address pair that is going to perform a 3-way handshake for each new address pair that is going to
be used in a MPTCP connection. While there are other reasons for be used in a MPTCP connection. While there are other reasons for
doing this (such as NAT traversal), such approach would also act as a doing this (such as NAT traversal), such approach would also act as a
reachability test and would prevent the flooding attacks described in reachability test and would prevent the flooding attacks described in
this section. this section.
6. Hijacking attacks 6. Hijacking attacks
skipping to change at page 10, line 45 skipping to change at page 11, line 19
for the MPTCP connection, then the attacker A has been able to for the MPTCP connection, then the attacker A has been able to
participate in the communication. In particular: participate in the communication. In particular:
o Segments flowing from the Node 2:Depending how the usage of o Segments flowing from the Node 2:Depending how the usage of
addresses is defined, Node 2 will start using IPA to send data to. addresses is defined, Node 2 will start using IPA to send data to.
In general, since the main goal is to achieve multi-path In general, since the main goal is to achieve multi-path
capabilities, we can assume that unless there are already many IP capabilities, we can assume that unless there are already many IP
address pairs in use in the MPTCP connection, Node 2 will start address pairs in use in the MPTCP connection, Node 2 will start
sending data to IPA. This means that part of the data of the sending data to IPA. This means that part of the data of the
communication will reach the Attacker but probably not all of it. communication will reach the Attacker but probably not all of it.
This per se, already has negative effects, since Node 1 will not This per se, already has negative effects, since Node 1 will not
receive all the data from Node 2. However, it is not enough to receive all the data from Node 2. Moreover, from the application
achieve full hijacking of the connection, since part of data will perspective, this would result in DoS attack, since the byte flow
be still delivered to IP1, so it would reach Node 1 and not the will stop waiting for the missing data. However, it is not enough
Attacker. In order for the attacker to receive all the data of to achieve full hijacking of the connection, since part of data
the MPTCP connection, the Attacker must somehow remove IP1 of the will be still delivered to IP1, so it would reach Node 1 and not
set of available addresses for the connection. in the case of the Attacker. In order for the attacker to receive all the data
of the MPTCP connection, the Attacker must somehow remove IP1 of
the set of available addresses for the connection. in the case of
implicit address management, this operation is likely to imply implicit address management, this operation is likely to imply
sending a termination packet with IP1 as source address, which may sending a termination packet with IP1 as source address, which may
or not be possible for the attacker depending on whether ingress or not be possible for the attacker depending on whether ingress
filtering is in place and the location of the attacker. If filtering is in place and the location of the attacker. If
explicit address management is used, then the attacker will send a explicit address management is used, then the attacker will send a
remove address control packet containing IP1. The result is that remove address control packet containing IP1. The result is that
once IP1 is removed, all the data sent by Node 2 will reach the once IP1 is removed, all the data sent by Node 2 will reach the
Attacker and the incoming traffic has been hijacked. Attacker and the incoming traffic has been hijacked.
o Segments flowing to the Node 2: As soon as IPA is accepted by Node o Segments flowing to the Node 2: As soon as IPA is accepted by Node
2 as part of the address set for the MPTCP connection, the 2 as part of the address set for the MPTCP connection, the
skipping to change at page 11, line 30 skipping to change at page 12, line 6
data i.e. Node 1 and the attacker, potentially preventing the data i.e. Node 1 and the attacker, potentially preventing the
full hijacking of the outgoing traffic by the attacker. In order full hijacking of the outgoing traffic by the attacker. In order
to achieve a full hijacking, the attacker would need to remove IP1 to achieve a full hijacking, the attacker would need to remove IP1
from the set of available addresses. This can be done using the from the set of available addresses. This can be done using the
same techniques described in the previous paragraph. same techniques described in the previous paragraph.
A related attack that can be achieved using similar techniques would A related attack that can be achieved using similar techniques would
be a Man in the Middle (MitM) attack. The scenario for the attack is be a Man in the Middle (MitM) attack. The scenario for the attack is
depicted in the figure below. depicted in the figure below.
+------+ +------+ +------+ +------+
| Node | --------------- | Node | | Node | --------------- | Node |
| 1 |IP1 IP2| 2 | | 1 |IP1 IP2| 2 |
+------+ \ /+------+ +------+ \ /+------+
\ / \ /
\ / \ /
\ / \ /
v IPA v v IPA v
+--------+ +--------+
|Attacker| |Attacker|
| A | | A |
+--------+ +--------+
In this case, there is an established connection between Node 1 and In this case, there is an established connection between Node 1 and
Node 2. The Attacker A will use the MPTCP address agility Node 2. The Attacker A will use the MPTCP address agility
capabilities to place itself as a MitM. In order to do so, it will capabilities to place itself as a MitM. In order to do so, it will
add IP address IPA as an additional address for the MPTCP connection add IP address IPA as an additional address for the MPTCP connection
on both Node 1 and Node 2. This is essentially the same technique on both Node 1 and Node 2. This is essentially the same technique
described earlier in this section, only that it is used against both described earlier in this section, only that it is used against both
nodes involved in the communication. The main difference is that in nodes involved in the communication. The main difference is that in
this case, the attacker can simply sniff the content of the this case, the attacker can simply sniff the content of the
communication that is forwarded through it and in turn forward the communication that is forwarded through it and in turn forward the
skipping to change at page 13, line 22 skipping to change at page 13, line 46
vulnerable to attackers sniffing the message exchange for the vulnerable to attackers sniffing the message exchange for the
establishment of the first subflow, but after that, the shared key establishment of the first subflow, but after that, the shared key
is not transmitted any more, so the attacker cannot learn it is not transmitted any more, so the attacker cannot learn it
through sniffing any other message. Unfortunately, in order to be through sniffing any other message. Unfortunately, in order to be
compatible with NATs (see analysis below) even though this compatible with NATs (see analysis below) even though this
approach includes a keyed HMAC signature, this signature cannot approach includes a keyed HMAC signature, this signature cannot
cover the IP address that is being added. This basically means cover the IP address that is being added. This basically means
that this type of approaches are also vulnerable to integrity that this type of approaches are also vulnerable to integrity
attacks of the exchanged messages. This means that even though attacks of the exchanged messages. This means that even though
the attacker cannot learn the shared key by sniffing the the attacker cannot learn the shared key by sniffing the
subsequent sublfow establishment, the attacker can modify the subsequent subflow establishment, the attacker can modify the
subflow establishment message and change the address that is being subflow establishment message and change the address that is being
added. So, the vulnerability window for confidentially to the added. So, the vulnerability window for confidentially to the
shared key is limited to the establishment of the first subflow, shared key is limited to the establishment of the first subflow,
but the vulnerability window for integrity attacks still includes but the vulnerability window for integrity attacks still includes
all the subflow establishment exchanges. These attacks are still all the subflow establishment exchanges. These attacks are still
undetectable by the endpoints. It should be noted that the SCTP undetectable by the endpoints. It should be noted that the SCTP
security falls in this category. security falls in this category.
o Strong crypto anchor exchange. another approach that could be used o Strong crypto anchor exchange. another approach that could be used
would be to exchange some strong crypto anchor while the would be to exchange some strong crypto anchor while the
establishment of the first subflow, such as a public key or a hash establishment of the first subflow, such as a public key or a hash
chain anchor. In this case, subsequent sublfows could be chain anchor. In this case, subsequent subflows could be
protected by using the crypto material associated to that anchor. protected by using the crypto material associated to that anchor.
An attacker in this case would need to change the crypto material An attacker in this case would need to change the crypto material
exchanged in the connection establishment phase. As a result the exchanged in the connection establishment phase. As a result the
vulnerability window for forging the crypto anchor is limited to vulnerability window for forging the crypto anchor is limited to
the initial connection establishment exchange. Similarly to the the initial connection establishment exchange. Similarly to the
previous case, due to NAT traversal considerations, the previous case, due to NAT traversal considerations, the
vulnerability window for integrity attacks include all the subflow vulnerability window for integrity attacks include all the subflow
establishment exchanges. As opposed to the previous one, because establishment exchanges. As opposed to the previous one, because
the attacker needs to change the crypto anchor, this approach are the attacker needs to change the crypto anchor, this approach are
detectable by the endpoints, if they communicate directly. detectable by the endpoints, if they communicate directly.
skipping to change at page 14, line 18 skipping to change at page 14, line 41
add addresses in the implicit mode (i.e. the SYN of new subflows) add addresses in the implicit mode (i.e. the SYN of new subflows)
cannot be protected against integrity attacks, since they must allow cannot be protected against integrity attacks, since they must allow
for NATs to change their addresses. This basically rules out any for NATs to change their addresses. This basically rules out any
solution that would rely on providing integrity protection to prevent solution that would rely on providing integrity protection to prevent
an attacker from changing the address used in a subflow establishment an attacker from changing the address used in a subflow establishment
exchange. This implies that alternative creative mechanisms are exchange. This implies that alternative creative mechanisms are
needed to protect from integrity attacks to the MPTCP signaling that needed to protect from integrity attacks to the MPTCP signaling that
adds new addresses to a connection. It is far from obvious how one adds new addresses to a connection. It is far from obvious how one
such creative approach could look like at this point. such creative approach could look like at this point.
7. Reccomendation 7. Reccommendation
The presented analysis shows that there is a tradeoff between the The presented analysis shows that there is a tradeoff between the
complexity of the security solution and the residual threats. In complexity of the security solution and the residual threats. In
order to define a proper security solution, we need to assess the order to define a proper security solution, we need to assess the
tradeoff and make a recommendation. After evaluating the different tradeoff and make a recommendation. After evaluating the different
aspects in the MPTCP WG, our conclusion is that the default security aspects in the MPTCP WG, our conclusion are:
mechanisms for MPTCP should be to exchange a key in the establishment MPTCP should implement some form of reachabilty check using a
of the first subflow and then secure following address additions by random nonce (e.g. TCP 3-way handshake) before adding a new
using a keyed HMAC using the exchanged key (i.e. similar to the one address to an ongoing communication in order to prevent flooding
used by SCTP). attacks,
The default security mechanisms for MPTCP should be to exchange a
In addition, our recommendation is that the MPTCP protocol should be key in the establishment of the first subflow and then secure
extensible and it should able to accommodate multiple security following address additions by using a keyed HMAC using the
solutions, in order to enable the usage of more secure mechanisms if exchanged key.
needed. MPTCP security mechanism should support using a pre-shared key
to be used in the keyed HMAC, providing a higher level of
protection than the previous one.
A mechanism to prevent replay attacks using these messages
should be provided e.g. a sequence number protected by the HMAC
The MPTCP protocol should be extensible and it should able to
accommodate multiple security solutions, in order to enable the
usage of more secure mechanisms if needed.
8. Security Considerations 8. Security Considerations
This note contains a security analysis for MPTCP, so no further This note contains a security analysis for MPTCP, so no further
security considerations need to be described in this section security considerations need to be described in this section
9. Contributors 9. Contributors
Alan Ford - Roke Manor Research Ltd. Alan Ford - Roke Manor Research Ltd.
10. Acknowledgments 10. Acknowledgments
Rolf Winter reviewed an earlier version of this document and provided Rolf Winter, Randall Stewart, Andrew McDonald, Michael Tuexen
comments to improve it. reviewed an earlier version of this document and provided comments to
improve it.
Mark Handley pointed out the problem with NATs and integrity Mark Handley pointed out the problem with NATs and integrity
protection of MPTCP signaling. protection of MPTCP signaling.
Marcelo Bagnulo is partly funded by Trilogy, a research project Marcelo Bagnulo is partly funded by Trilogy, a research project
supported by the European Commission under its Seventh Framework supported by the European Commission under its Seventh Framework
Program. Program.
11. Informative References 11. Informative References
skipping to change at page 15, line 32 skipping to change at page 16, line 16
RFC 3972, March 2005. RFC 3972, March 2005.
[RFC5062] Stewart, R., Tuexen, M., and G. Camarillo, "Security [RFC5062] Stewart, R., Tuexen, M., and G. Camarillo, "Security
Attacks Found Against the Stream Control Transmission Attacks Found Against the Stream Control Transmission
Protocol (SCTP) and Current Countermeasures", RFC 5062, Protocol (SCTP) and Current Countermeasures", RFC 5062,
September 2007. September 2007.
[RFC5535] Bagnulo, M., "Hash-Based Addresses (HBA)", RFC 5535, [RFC5535] Bagnulo, M., "Hash-Based Addresses (HBA)", RFC 5535,
June 2009. June 2009.
[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
in IPv6", RFC 3775, June 2004.
[RFC5533] Nordmark, E. and M. Bagnulo, "Shim6: Level 3 Multihoming
Shim Protocol for IPv6", RFC 5533, June 2009.
[RFC2960] Stewart, R., Xie, Q., Morneault, K., Sharp, C.,
Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M.,
Zhang, L., and V. Paxson, "Stream Control Transmission
Protocol", RFC 2960, October 2000.
Author's Address Author's Address
Marcelo Bagnulo Marcelo Bagnulo
Universidad Carlos III de Madrid Universidad Carlos III de Madrid
Av. Universidad 30 Av. Universidad 30
Leganes, Madrid 28911 Leganes, Madrid 28911
SPAIN SPAIN
Phone: 34 91 6248814 Phone: 34 91 6248814
Email: marcelo@it.uc3m.es Email: marcelo@it.uc3m.es
 End of changes. 28 change blocks. 
97 lines changed or deleted 131 lines changed or added

This html diff was produced by rfcdiff 1.39. The latest version is available from http://tools.ietf.org/tools/rfcdiff/