draft-ietf-mptcp-threat-04.txt   draft-ietf-mptcp-threat-05.txt 
Network Working Group M. Bagnulo Network Working Group M. Bagnulo
Internet-Draft UC3M Internet-Draft UC3M
Intended status: Informational November 26, 2010 Intended status: Informational December 6, 2010
Expires: May 30, 2011 Expires: June 9, 2011
Threat Analysis for Multi-addressed/Multi-path TCP Threat Analysis for Multi-addressed/Multi-path TCP
draft-ietf-mptcp-threat-04 draft-ietf-mptcp-threat-05
Abstract Abstract
Multi-path TCP (MPTCP for short) describes the extensions proposed Multi-path TCP (MPTCP for short) describes the extensions proposed
for TCP so that each endpoint of a given TCP connection can use for TCP so that each endpoint of a given TCP connection can use
multiple IP addresses to exchange data (instead of a single IP multiple IP addresses to exchange data (instead of a single IP
address per endpoint as currently defined). Such extensions enable address per endpoint as currently defined). Such extensions enable
the exchange of segments using different source-destination address the exchange of segments using different source-destination address
pairs, resulting in the capability of using multiple paths in a pairs, resulting in the capability of using multiple paths in a
significant number of scenarios. In particular, some level of significant number of scenarios. In particular, some level of
skipping to change at page 1, line 40 skipping to change at page 1, line 40
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 May 30, 2011. This Internet-Draft will expire on June 9, 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 22 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 . . . . . . . . . . . . . . . . . . . . . . . 15 7. Recommendation . . . . . . . . . . . . . . . . . . . . . . . . 15
8. Security Considerations . . . . . . . . . . . . . . . . . . . 15 8. Security Considerations . . . . . . . . . . . . . . . . . . . 15
9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 15 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 15
11. Informative References . . . . . . . . . . . . . . . . . . . . 16 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15
12. Informative References . . . . . . . . . . . . . . . . . . . . 16
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 16 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 16
1. Introduction 1. Introduction
Multi-path TCP (MPTCP for short) describes the extensions proposed Multi-path TCP (MPTCP for short) describes the extensions proposed
for TCP so that each endpoint of a given TCP connection can use for TCP [RFC0793] so that each endpoint of a given TCP connection can
multiple IP addresses to exchange data (instead of a single IP use multiple IP addresses to exchange data (instead of a single IP
address per endpoint as currently defined). Such extensions enable address per endpoint as currently defined). Such extensions enable
the exchange of segments using different source-destination address the exchange of segments using different source-destination address
pairs, resulting in the capability of using multiple paths in a pairs, resulting in the capability of using multiple paths in a
significant number of scenarios. In particular, some level of significant number of scenarios. In particular, some level of
multihoming and mobility support can be achieved through these multihoming and mobility support can be achieved through these
extensions. However, the support for multiple IP addresses per extensions. However, the support for multiple IP addresses per
endpoint may have implications on the security of the resulting MPTCP endpoint may have implications on the security of the resulting MPTCP
protocol. This note includes a threat analysis for MPTCP. It should protocol. This note includes a threat analysis for MPTCP. It should
be noted that there are there may other ways to provide multiple be noted that there are there may other ways to provide multiple
paths for a TCP connection other than the usage of multiple paths for a TCP connection other than the usage of multiple
skipping to change at page 3, line 37 skipping to change at page 3, line 37
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
of multiple IP address per endpoint and that use different source- of multiple IP address per endpoint and that use different source-
destination address pairs as a mean to express different paths. So, destination address pairs as a mean to express different paths. So,
in the rest of this note, the MPTCP expression will refer to this in the rest of this note, the MPTCP expression will refer to this
Multi-addressed flavour of Multi-path TCP. Multi-addressed flavour of Multi-path TCP.
Scope of the analysis
In this note we perform a threat analysis for MPTCP. Introducing the In this note we perform a threat analysis for MPTCP. Introducing the
support of multiple addresses per endpoint in a single TCP connection support of multiple addresses per endpoint in a single TCP connection
may result in additional vulnerabilities. The scope of this note is may result in additional vulnerabilities. The scope of this note is
to identify and characterize these new vulnerabilities. So, the to identify and characterize these new vulnerabilities. So, the
scope of the analysis is limited to the additional vulnerabilities scope of the analysis is limited to the additional vulnerabilities
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
skipping to change at page 4, line 36 skipping to change at page 4, line 33
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) [RFC3775]. [RFC4225] includes the rational in Mobile IPv6 (MIPv6 RO) [RFC3775]. [RFC4225] includes the rational
for the design of the security of MIPv6 RO. All the attacks for the design of the security of MIPv6 RO. All the attacks
described in the aforementioned analysis apply here and are an described in the aforementioned analysis apply here and are an
excellent basis for our 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 o 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
the other hand, it is very important to keep the assumption valid the other hand, it is very important to keep the assumption valid
that the address bindings for a given connection do not affect that the address bindings for a given connection do not affect
other connections. If reusing of binding or security information other connections. If reusing of binding or security information
is to be considered, this assumption could be no longer valid and is to be considered, this assumption could be no longer valid and
the full impact of the vulnerabilities must be assessed. the full impact of the vulnerabilities must be assessed.
o 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 o 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 o As opposed to MPTCP, MIPv6 RO does not have a connection state
information, including sequence numbers, port numbers that could information, including sequence numbers, port numbers that could
be 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 o 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 o 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 o Similarly to MIPv6 RO, Shim6 does not have a connection state
information, including sequence numbers, port that could be information, including sequence numbers, port that could be
leveraged to provide security in some form. leveraged to provide security in some form.
SCTP [RFC2960]is a transport protocol that supports multiple SCTP [RFC4960]is a transport protocol that supports multiple
addresses per endpoint and as such, the security implications are addresses per endpoint and as such, the security implications are
very close to the ones of MPTCP. A security analysis, identifying a very close to the ones of MPTCP. A security analysis, identifying a
set of attacks and proposed solutions was performed in [RFC5062]. set of attacks and proposed solutions was performed in [RFC5062].
The results of this analysis apply directly to the case of MPTCP. The results of this analysis apply directly to the case of MPTCP.
However, the analysis was performed after the base SCTP protocol was However, the analysis was performed after the base SCTP protocol was
designed and the goal of the document was essentially to improve the designed and the goal of the document was essentially to improve the
security of SCTP. As such, the document is very specific to the security of SCTP. As such, the document is very specific to the
actual SCTP specification and relies on the SCTP messages and actual SCTP specification and relies on the SCTP messages and
behaviour to characterize the issues. While some them can be behaviour to characterize the issues. While some them can be
translated to the MPTCP case, some may be caused by specific translated to the MPTCP case, some may be caused by specific
skipping to change at page 7, line 30 skipping to change at page 7, line 27
address field of the IP header address field of the IP header
These two modes have different security properties for some type of These two modes have different security properties for some type of
attacks. The explicit mode seems to be the more vulnerable to abuse. attacks. The explicit mode seems to be the more vulnerable to abuse.
In 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. However, it to add any arbitrary address to an ongoing connection. However, it
should be noted that ingress filtering deployment is far from 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 universal, and as such it is unwise to rely on it as a basis for the
protection of MPTCP. protection of MPTCP.
In addition, further consideration about the interaction between
ingress filtering and implicit mode signaling is needed in the In addition, further consideration about the interaction between
case that we need to remove an address that is no longer available ingress filtering and implicit mode signaling is needed in the case
from the MPTCP connection. In particular a host attached to a that we need to remove an address that is no longer available from
network that performs ingress filtering and using implicit the MPTCP connection. In particular a host attached to a network
signaling would not be able to remove an address that is no longer that performs ingress filtering and using implicit signaling would
available (either because of a failure or due to a mobility event) not be able to remove an address that is no longer available (either
from an ongoing MPTCP connection. 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 15, line 5 skipping to change at page 15, line 5
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. Reccommendation 7. Recommendation
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 as follows:
MPTCP should implement some form of reachabilty check using a
random nonce (e.g. TCP 3-way handshake) before adding a new MPTCP should implement some form of reachability check using a random
address to an ongoing communication in order to prevent flooding nonce (e.g. TCP 3-way handshake) before adding a new address to an
attacks. ongoing communication in order to prevent flooding attacks.
The default security mechanisms for MPTCP should be to exchange a
key in clear text in the establishment of the first subflow and The default security mechanisms for MPTCP should be to exchange a key
then secure following address additions by using a keyed HMAC in clear text in the establishment of the first subflow and then
using the exchanged key. secure following address additions by using a keyed HMAC using the
MPTCP security mechanism should support using a pre-shared key exchanged key.
to be used in the keyed HMAC, providing a higher level of
protection than the previous one. MPTCP security mechanism should support using a pre-shared key to be
A mechanism to prevent replay attacks using these messages used in the keyed HMAC, providing a higher level of protection than
should be provided e.g. a sequence number protected by the HMAC the previous one.
The MPTCP protocol should be extensible and it should able to
accommodate multiple security solutions, in order to enable the A mechanism to prevent replay attacks using these messages should be
usage of more secure mechanisms if needed. 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. IANA Considerations
This document does not require any action from IANA.
10. Contributors
Alan Ford - Roke Manor Research Ltd. Alan Ford - Roke Manor Research Ltd.
10. Acknowledgments 11. Acknowledgments
Rolf Winter, Randall Stewart, Andrew McDonald, Michael Tuexen, Rolf Winter, Randall Stewart, Andrew McDonald, Michael Tuexen,
Michael Scharf, Tim Shepard reviewed an earlier version of this Michael Scharf, Tim Shepard, Yoshifumi Nishida reviewed an earlier
document and provided comments to improve it. 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 12. Informative References
[RFC4225] Nikander, P., Arkko, J., Aura, T., Montenegro, G., and E. [RFC4225] Nikander, P., Arkko, J., Aura, T., Montenegro, G., and E.
Nordmark, "Mobile IP Version 6 Route Optimization Security Nordmark, "Mobile IP Version 6 Route Optimization Security
Design Background", RFC 4225, December 2005. Design Background", RFC 4225, December 2005.
[RFC4218] Nordmark, E. and T. Li, "Threats Relating to IPv6 [RFC4218] Nordmark, E. and T. Li, "Threats Relating to IPv6
Multihoming Solutions", RFC 4218, October 2005. Multihoming Solutions", RFC 4218, October 2005.
[RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)",
RFC 3972, March 2005. RFC 3972, March 2005.
skipping to change at page 16, line 31 skipping to change at page 16, line 40
[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 [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
in IPv6", RFC 3775, June 2004. in IPv6", RFC 3775, June 2004.
[RFC5533] Nordmark, E. and M. Bagnulo, "Shim6: Level 3 Multihoming [RFC5533] Nordmark, E. and M. Bagnulo, "Shim6: Level 3 Multihoming
Shim Protocol for IPv6", RFC 5533, June 2009. Shim Protocol for IPv6", RFC 5533, June 2009.
[RFC2960] Stewart, R., Xie, Q., Morneault, K., Sharp, C., [RFC4960] Stewart, R., "Stream Control Transmission Protocol",
Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M., RFC 4960, September 2007.
Zhang, L., and V. Paxson, "Stream Control Transmission
Protocol", RFC 2960, October 2000. [RFC0793] Postel, J., "Transmission Control Protocol", STD 7,
RFC 793, September 1981.
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
 End of changes. 24 change blocks. 
56 lines changed or deleted 65 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/