draft-ietf-mptcp-threat-03.txt   draft-ietf-mptcp-threat-04.txt 
Network Working Group M. Bagnulo Network Working Group M. Bagnulo
Internet-Draft UC3M Internet-Draft UC3M
Intended status: Informational October 4, 2010 Intended status: Informational November 26, 2010
Expires: April 7, 2011 Expires: May 30, 2011
Threat Analysis for Multi-addressed/Multi-path TCP Threat Analysis for Multi-addressed/Multi-path TCP
draft-ietf-mptcp-threat-03 draft-ietf-mptcp-threat-04
Abstract Abstract
Multi-addresses/Multi-path TCP (MPTCP for short) describes the Multi-path TCP (MPTCP for short) describes the extensions proposed
extensions proposed for TCP so that each endpoint of a given TCP for TCP so that each endpoint of a given TCP connection can use
connection can use multiple IP addresses to exchange data (instead of multiple IP addresses to exchange data (instead of a single IP
a single IP address per endpoint as currently defined). Such address per endpoint as currently defined). Such extensions enable
extensions enable the exchange of segments using different source- the exchange of segments using different source-destination address
destination address pairs, resulting in the capability of using pairs, resulting in the capability of using multiple paths in a
multiple paths in a significant number of scenarios. In particular, significant number of scenarios. In particular, some level of
some level of multihoming and mobility support can be achieved multihoming and mobility support can be achieved through these
through these extensions. However, the support for multiple IP extensions. However, the support for multiple IP addresses per
addresses per endpoint may have implications on the security of the endpoint may have implications on the security of the resulting MPTCP
resulting MPTCP protocol. This note includes a threat analysis for protocol. This note includes a threat analysis for MPTCP.
MPTCP.
Status of this Memo Status of this Memo
This Internet-Draft is submitted 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). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. 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."
This Internet-Draft will expire on April 7, 2011. This Internet-Draft will expire on May 30, 2011.
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
skipping to change at page 2, line 23 skipping to change at page 2, line 22
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 . . . . . . . . . . . . . . . . . . . . . . 10 6. Hijacking attacks . . . . . . . . . . . . . . . . . . . . . . 10
6.1. Hijacking attacks to the Basic MPTCP protocol . . . . . . 10 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 . . . . . . . . . . . . . . . . . . . . 14 6.3. NAT considerations . . . . . . . . . . . . . . . . . . . . 14
7. Reccommendation . . . . . . . . . . . . . . . . . . . . . . . 14 7. Reccommendation . . . . . . . . . . . . . . . . . . . . . . . 15
8. Security Considerations . . . . . . . . . . . . . . . . . . . 15 8. Security Considerations . . . . . . . . . . . . . . . . . . . 15
9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 15 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 15
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15
11. Informative References . . . . . . . . . . . . . . . . . . . . 15 11. Informative References . . . . . . . . . . . . . . . . . . . . 16
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 16 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 16
1. Introduction 1. Introduction
Multi-addresses/Multi-path TCP (MPTCP for short) describes the Multi-path TCP (MPTCP for short) describes the extensions proposed
extensions proposed for TCP so that each endpoint of a given TCP for TCP so that each endpoint of a given TCP connection can use
connection can use multiple IP addresses to exchange data (instead of multiple IP addresses to exchange data (instead of a single IP
a single IP address per endpoint as currently defined). Such address per endpoint as currently defined). Such extensions enable
extensions enable the exchange of segments using different source- the exchange of segments using different source-destination address
destination address pairs, resulting in the capability of using pairs, resulting in the capability of using multiple paths in a
multiple paths in a significant number of scenarios. In particular, significant number of scenarios. In particular, some level of
some level of multihoming and mobility support can be achieved multihoming and mobility support can be achieved through these
through these extensions. However, the support for multiple IP extensions. However, the support for multiple IP addresses per
addresses per endpoint may have implications on the security of the endpoint may have implications on the security of the resulting MPTCP
resulting MPTCP protocol. This note includes a threat analysis for protocol. This note includes a threat analysis for MPTCP. It should
MPTCP. be noted that there are there may other ways to provide multiple
paths for a TCP connection other than the usage of multiple
addresses. The threat analysis performed in this document is limited
to the specific case of using multiple addresses per endpoint.
2. Scope 2. Scope
There are multiple ways to achieve Multi-path TCP. Essentially what There are multiple ways to achieve Multi-path TCP. Essentially what
is needed is for different segments of the communication to be is needed is for different segments of the communication to be
forwarded through different paths by enabling the sender to specify forwarded through different paths by enabling the sender to specify
some form of path selector. There are multiple options for such path some form of path selector. There are multiple options for such path
selector, including the usage of different next hops, using tunnels selector, including the usage of different next hops, using tunnels
to different egress points and so on. In this note, we will focus on to different egress points and so on. In this note, we will focus on
a particular approach, namely MPTCP approaches that rely on the usage a particular approach, namely MPTCP approaches that rely on the usage
skipping to change at page 3, line 51 skipping to change at page 4, line 7
resulting from the multi-address support compared to the current TCP resulting from the multi-address support compared to the current TCP
protocol (where each endpoint only has one address available for use protocol (where each endpoint only has one address available for use
per connection). In other words, a full analysis of the complete set per connection). In other words, a full analysis of the complete set
of threats is explicitly out of the scope. The goal of this analysis of threats is explicitly out of the scope. The goal of this analysis
is to help the MPTCP protocol designers to create a MPTCP that is as is to help the MPTCP protocol designers to create a MPTCP that is as
secure as the current TCP. It is a non goal of this analysis to help secure as the current TCP. It is a non goal of this analysis to help
in the design of MPTCP that is more secure than regular TCP. in the design of MPTCP that is more secure than regular TCP.
In particular, we will focus on attackers that are not along the In particular, we will focus on attackers that are not along the
path, at least not during the whole duration of the connection. In path, at least not during the whole duration of the connection. In
the current single path TCP, on-path attacker can launch a the current single path TCP, an on-path attacker can launch a
significant number of attacks, including eavesdropping, connection significant number of attacks, including eavesdropping, connection
hijacking Man in the Middle attacks and so on. However, it is not hijacking Man-in-the-Middle attacks and so on. However, it is not
possible for the off-path attackers to launch such attacks. There is possible for the off-path attackers to launch such attacks. There is
a middle ground in case the attacker is located along the path for a a middle ground in case the attacker is located along the path for a
short period of time to launch the attack and then moves away, but short period of time to launch the attack and then moves away, but
the attack effects still apply. These are the so-called time-shifted the attack effects still apply. These are the so-called time-shifted
attacks. Since these are not possible in today's TCP, we will also attacks. Since these are not possible in today's TCP, we will also
consider them as part of the analysis. So, summarizing, we will consider them as part of the analysis. So, summarizing, we will
consider both attacks launched by off-path attackers and time-shifted consider both attacks launched by off-path attackers and time-shifted
attacks. Attacks launched by on-path attackers are out of scope, attacks. Attacks launched by on-path attackers are out of scope,
since they also apply to current single-path TCP. since they also apply to current single-path TCP.
It should be noted, however, that some current on-path attacks may It should be noted, however, that some current on-path attacks may
skipping to change at page 5, line 13 skipping to change at page 5, line 18
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 not 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 As opposed to MPTCP, MIPv6 RO does not have a connection state
information, including sequence numbers, port that could be information, including sequence numbers, port numbers that could
leveraged to provide security in some form. be leveraged to provide security in some form.
In the Shim6 [RFC5533] design, similar issues related to address In the Shim6 [RFC5533] design, similar issues related to address
agility were considered and a threat analysis was also performed agility were considered and a threat analysis was also performed
[RFC4218]. The analysis performed for Shim6 also largely applies to [RFC4218]. The analysis performed for Shim6 also largely applies to
the MPTCP 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
skipping to change at page 9, line 33 skipping to change at page 9, line 33
significant amount of traffic to the Target node. There is a subtle significant amount of traffic to the Target node. There is a subtle
operation that the attacker needs to achieve in order to launch a operation that the attacker needs to achieve in order to launch a
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. In particular, if the MPTCP
protocol requires performing slow start per subflow, then the
flooding will be limited by the slow-start initial window size.
Previous protocols, such as MIPv6 RO and SCTP, that have to deal with Previous protocols, such as MIPv6 RO and SCTP, that have to deal with
this type of attacks have done so by adding a reachability check this type of attacks have done so by adding a reachability check
before actually sending data to a new address. In other words, the before actually sending data to a new address. In other words, the
solution used in other protocols, would include the Source S to solution used in other protocols, would include the Source S to
explicitly asking the host sitting in the new address (in this case explicitly asking the host sitting in the new address (in this case
the Target T sitting in IPT) whether it is willing to accept packets the Target T sitting in IPT) whether it is willing to accept packets
from the MPTCP connection identified by the 4-tuple IPA, port A, IPS, from the MPTCP connection identified by the 4-tuple IPA, port A, IPS,
port S. Since this is not part of the established connection that port S. Since this is not part of the established connection that
Target T has, T would not accept the request and Source S would not Target T has, T would not accept the request and Source S would not
skipping to change at page 10, line 9 skipping to change at page 10, line 12
particular, In the case of SCTP, it sends a message with a 64-bit particular, In the case of SCTP, it sends a message with a 64-bit
nonce (in a HEARTBEAT). 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.
Another type of flooding attack that could potentially be performed
with MPTCP is one where the attacker initiates a a communication with
a peer and includes a long list of alternative addresses in explicit
mode. If the peer decides to establish subflows with all the
available addresses, the attacker have managed to achieve an
amplified attack, since by sending a single packet containing all the
alternative addresses it triggers the peer to generate packets to all
the destinations.
6. Hijacking attacks 6. Hijacking attacks
6.1. Hijacking attacks to the Basic MPTCP protocol 6.1. Hijacking attacks to the Basic MPTCP protocol
The hijacking attacks essentially use the MPTCP address agility to The hijacking attacks essentially use the MPTCP address agility to
allow an attacker to hijack a connection. This means that the victim allow an attacker to hijack a connection. This means that the victim
of a connection thinks that it is talking to a peer, while it is of a connection thinks that it is talking to a peer, while it is
actually exchanging packets with the attacker. In some sense it is actually exchanging packets with the attacker. In some sense it is
the dual of the flooding attacks (where the victim thinks it is the dual of the flooding attacks (where the victim thinks it is
exchanging packets with the attacker but in reality is sending the exchanging packets with the attacker but in reality is sending the
skipping to change at page 11, line 51 skipping to change at page 12, line 14
part of the outgoing traffic. However, Node 1 would still be able part of the outgoing traffic. However, Node 1 would still be able
to send traffic that will be received by Node 2 as part of the to send traffic that will be received by Node 2 as part of the
MPTCP connection. This means that there will be two source of MPTCP connection. This means that there will be two source of
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
skipping to change at page 14, line 5 skipping to change at page 14, line 17
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 subflow 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
would be to exchange some strong crypto anchor while the used 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 subflows 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.
6.3. NAT considerations 6.3. NAT considerations
In order to be widely adopted MPTCP must work through NATs. NATs are In order to be widely adopted MPTCP must work through NATs. NATs are
an interesting device from a security perspective. In terms of MPTCP an interesting device from a security perspective. In terms of MPTCP
they essentially behave as a Man-in-the-middle attacker. As we have they essentially behave as a Man-in-the-Middle attacker. As we have
described earlier, MPTCP security goal is to prevent from any described earlier, MPTCP security goal is to prevent from any
attacker to insert their addresses as valid addresses for a given attacker to insert their addresses as valid addresses for a given
MPTCP connection. But that is exactly what a NAT does, they modify MPTCP connection. But that is exactly what a NAT does, they modify
the addresses. So, if MPTCP is to work through NATs, MPTCP must the addresses. So, if MPTCP is to work through NATs, MPTCP must
accept address rewritten by NATs as valid addresses for a given accept address rewritten by NATs as valid addresses for a given
session. The most direct corollary is that the MPTCP messages that session. The most direct corollary is that the MPTCP messages that
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
skipping to change at page 15, line 4 skipping to change at page 15, line 15
7. Reccommendation 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 are: aspects in the MPTCP WG, our conclusion are:
MPTCP should implement some form of reachabilty check using a MPTCP should implement some form of reachabilty check using a
random nonce (e.g. TCP 3-way handshake) before adding a new random nonce (e.g. TCP 3-way handshake) before adding a new
address to an ongoing communication in order to prevent flooding address to an ongoing communication in order to prevent flooding
attacks, attacks.
The default security mechanisms for MPTCP should be to exchange a The default security mechanisms for MPTCP should be to exchange a
key in the establishment of the first subflow and then secure key in clear text in the establishment of the first subflow and
following address additions by using a keyed HMAC using the then secure following address additions by using a keyed HMAC
exchanged key. using the exchanged key.
MPTCP security mechanism should support using a pre-shared key MPTCP security mechanism should support using a pre-shared key
to be used in the keyed HMAC, providing a higher level of to be used in the keyed HMAC, providing a higher level of
protection than the previous one. protection than the previous one.
A mechanism to prevent replay attacks using these messages A mechanism to prevent replay attacks using these messages
should be provided e.g. a sequence number protected by the HMAC should be provided e.g. a sequence number protected by the HMAC
The MPTCP protocol should be extensible and it should able to The MPTCP protocol should be extensible and it should able to
accommodate multiple security solutions, in order to enable the accommodate multiple security solutions, in order to enable the
usage of more secure mechanisms if needed. 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, Randall Stewart, Andrew McDonald, Michael Tuexen Rolf Winter, Randall Stewart, Andrew McDonald, Michael Tuexen,
reviewed an earlier version of this document and provided comments to Michael Scharf, Tim Shepard reviewed an earlier version of this
improve it. 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
 End of changes. 18 change blocks. 
46 lines changed or deleted 59 lines changed or added

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