draft-ietf-mptcp-threat-08.txt   rfc6181.txt 
Network Working Group M. Bagnulo Internet Engineering Task Force (IETF) M. Bagnulo
Internet-Draft UC3M Request for Comments: 6181 UC3M
Intended status: Informational January 26, 2011 Category: Informational March 2011
Expires: July 30, 2011 ISSN: 2070-1721
Threat Analysis for TCP Extensions for Multi-path Operation with Threat Analysis for TCP Extensions for Multipath Operation
Multiple Addresses with Multiple Addresses
draft-ietf-mptcp-threat-08
Abstract Abstract
Multi-path TCP (MPTCP for short) describes the extensions proposed Multipath TCP (MPTCP for short) describes the extensions proposed for
for TCP so that endpoints of a given TCP connection can use multiple TCP so that endpoints of a given TCP connection can use multiple
paths to exchange data. Such extensions enable the exchange of paths to exchange data. Such extensions enable the exchange of
segments using different source-destination address pairs, resulting segments using different source-destination address pairs, resulting
in the capability of using multiple paths in a significant number of in the capability of using multiple paths in a significant number of
scenarios. Some level of multihoming and mobility support can be scenarios. Some level of multihoming and mobility support can be
achieved through these extensions. However, the support for multiple achieved through these extensions. However, the support for multiple
IP addresses per endpoint may have implications on the security of IP addresses per endpoint may have implications on the security of
the resulting MPTCP protocol. This note includes a threat analysis the resulting MPTCP. This note includes a threat analysis for MPTCP.
for MPTCP.
Status of this Memo
This Internet-Draft is submitted in full conformance with the Status of This Memo
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering This document is not an Internet Standards Track specification; it is
Task Force (IETF). Note that other groups may also distribute published for informational purposes.
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Not all documents
approved by the IESG are a candidate for any level of Internet
Standard; see Section 2 of RFC 5741.
This Internet-Draft will expire on July 30, 2011. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc6181.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2011 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
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified 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 . . . . . . . . . . . . . . . . . . . . . . . 8
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 . . . . . . . . . . . 10
6.2. Time-shifted hijacking attacks . . . . . . . . . . . . . . 12 6.2. Time-Shifted Hijacking Attacks . . . . . . . . . . . . . . 13
6.3. NAT considerations . . . . . . . . . . . . . . . . . . . . 14 6.3. NAT Considerations . . . . . . . . . . . . . . . . . . . . 14
7. Recommendation . . . . . . . . . . . . . . . . . . . . . . . . 15 7. Recommendation . . . . . . . . . . . . . . . . . . . . . . . . 15
8. Security Considerations . . . . . . . . . . . . . . . . . . . 15 8. Security Considerations . . . . . . . . . . . . . . . . . . . 16
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 16
10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 16 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 11.1. Normative References . . . . . . . . . . . . . . . . . . . 16
12.1. Normative References . . . . . . . . . . . . . . . . . . . 16 11.2. Informative References . . . . . . . . . . . . . . . . . . 16
12.2. Informative References . . . . . . . . . . . . . . . . . . 16
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 17
1. Introduction 1. Introduction
Multi-path TCP (MPTCP for short) describes the extensions proposed Multipath TCP (MPTCP for short) describes the extensions proposed for
for TCP [RFC0793] so that endpoints of a given TCP connection can use TCP [RFC0793] so that endpoints of a given TCP connection can use
multiple paths to exchange data. Such extensions enable the exchange multiple paths to exchange data. Such extensions enable the exchange
of segments using different source-destination address pairs, of segments using different source-destination address pairs,
resulting in the capability of using multiple paths in a significant resulting in the capability of using multiple paths in a significant
number of scenarios. Some level of multihoming and mobility support number of scenarios. Some level of multihoming and mobility support
can be achieved through these extensions. However, the support for can be achieved through these extensions. However, the support for
multiple IP addresses per endpoint may have implications on the multiple IP addresses per endpoint may have implications on the
security of the resulting MPTCP protocol. This note includes a security of the resulting MPTCP. This note includes a threat
threat analysis for MPTCP. There are there may other ways to provide analysis for MPTCP. There are many other ways to provide multiple
multiple paths for a TCP connection other than the usage of multiple paths for a TCP connection other than the usage of multiple
addresses. The threat analysis performed in this document is limited addresses. The threat analysis performed in this document is limited
to the specific case of using multiple addresses per endpoint. 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 Multipath 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 a some form of path selector. There are multiple options for such a
path selector, including the usage of different next hops, using path selector, including the usage of different next hops, using
tunnels to different egress points and so on. In this note, we will tunnels to different egress points, and so on. The scope of the
focus on a particular approach, namely MPTCP, that rely on the usage analysis included in this note is limited to a particular approach,
of multiple IP address per endpoint and that uses different source- namely MPTCP, that relies on the usage of multiple IP address per
destination address pairs as a mean to express different paths. So, endpoint and that uses different source-destination address pairs as
in the rest of this note, the MPTCP expression will refer to this a means to express different paths. So, in the rest of this note,
Multi-addressed flavour of Multi-path TCP the MPTCP expression will refer to this multi-addressed flavor of
[I-D.ietf-mptcp-multiaddressed]. Multipath TCP [MPTCP-MULTIADDRESSED].
In this note we perform a threat analysis for MPTCP. Introducing the This goal of this note is to perform a threat analysis for MPTCP.
support of multiple addresses per endpoint in a single TCP connection Introducing the support of multiple addresses per endpoint in a
may result in additional vulnerabilities compared to single-path TCP. single TCP connection may result in additional vulnerabilities
The scope of this note is to identify and characterize these new compared to single-path TCP. The scope of this note is to identify
vulnerabilities. So, the scope of the analysis is limited to the and characterize these new vulnerabilities. So, the scope of the
additional vulnerabilities resulting from the multi-address support analysis is limited to the additional vulnerabilities resulting from
compared to the current TCP protocol (where each endpoint only has the multi-address support compared to the current TCP (where each
one address available for use per connection). A full analysis of endpoint only has one address available for use per connection). A
the complete set of threats is explicitly out of the scope. The goal full analysis of the complete set of threats is explicitly out of the
of this analysis is to help the MPTCP protocol designers create an scope. The goal of this analysis is to help the MPTCP designers
MPTCP specification that is as secure as the current TCP. It is a create an MPTCP specification that is as secure as the current TCP.
non-goal of this analysis to help in the design of MPTCP that is more It is a non-goal of this analysis to help in the design of MPTCP that
secure than regular TCP. is more secure than regular TCP.
We will focus on attackers that are not along the path, at least not The focus of the analysis is on attackers that are not along the
during the whole duration of the connection. In the current single path, at least not during the whole duration of the connection. In
path TCP, an on-path attacker can launch a significant number of the current single-path TCP, an on-path attacker can launch a
attacks, including eavesdropping, connection hijacking Man-in-the- significant number of attacks, including eavesdropping, connection
Middle attacks and so on. However, it is not possible for the off- hijacking Man-in-the-Middle (MiTM) attacks, and so on. However, it
path attackers to launch such attacks. There is a middle ground in is not possible for the off-path attackers to launch such attacks.
case the attacker is located along the path for a short period of There is a middle ground in case the attacker is located along the
time to launch the attack and then moves away, but the attack effects path for a short period of time to launch the attack and then moves
still apply. These are the so-called time-shifted attacks. Since away, but the attack effects still apply. These are the so-called
these are not possible in today's TCP, we will also consider them as time-shifted attacks. Since these are not possible in today's TCP,
part of the analysis. So, summarizing, we will consider both attacks they are also consider in the analysis. So, summarizing, both
launched by off-path attackers and time-shifted attacks. Attacks attacks launched by off-path attackers and time-shifted attacks are
launched by on-path attackers are out of scope, since they also apply considered to be within scope. Attacks launched by on-path attackers
to current single-path TCP. are out of scope, since they also apply to current single-path TCP.
However, that some current on-path attacks may become more difficult However, that some current on-path attacks may become more difficult
with multi-path TCP, since an attacker (on a single path) will not with Multipath TCP, since an attacker (on a single path) will not
have visibility of the complete data stream. have visibility of the complete data stream.
3. Related work 3. Related Work
There is a significant amount of previous work in terms of analysis There is a significant amount of previous work in terms of analysis
of protocols that support address agility. In this section we of protocols that support address agility. The most relevant ones
present the most relevant ones and we relate them to the current are presented in this section.
MPTCP 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
for the design of the security of MIPv6 RO. All the attacks rationale for the design of the security of MIPv6 RO. All the
described in the aforementioned analysis apply here and are an attacks described in the aforementioned analysis apply here and are
excellent basis for our own analysis. The main differences are: an excellent basis for our own analysis. The main differences are as
follows:
o 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. If a binding between two addresses is created at the is at stake. If a binding between two addresses is created at the
IP layer, this binding can and will affect all the connections IP layer, this binding can and will affect all the connections
that involve those addresses. However, in MPTCP, if an additional that involve those addresses. However, in MPTCP, if an additional
address is added to an ongoing TCP connection, the additional address is added to an ongoing TCP connection, the additional
address will/can only affect the connection at hand and not other address will/can only affect the connection at hand and not other
connections even if the same address is being used for those other connections, even if the same address is being used for those
connections. The result is that in MPTCP there is much less at other connections. The result is that, in MPTCP, there is much
stake and the resulting vulnerabilities are less. On the other less at stake and the resulting vulnerabilities are less. On the
hand, it is very important to keep the assumption valid that the other hand, it is very important to keep the assumption valid that
address bindings for a given connection do not affect other the address bindings for a given connection do not affect other
connections. If reusing of binding or security information is to connections. If reusing of binding or security information is to
be considered, this assumption could be no longer valid and the be considered, this assumption could be no longer valid and the
full impact of the vulnerabilities must be assessed. full impact of the vulnerabilities must be assessed.
o In MIPv6 there is a trusted third party, called the Home Agent o In MIPv6, there is a trusted third party, called the Home Agent
that can help with some security problems, as expanded in the next that can help with some security problems, as expanded in the next
bullet. bullet.
o In MIPv6 RO, there is the assumption that the original address o In MIPv6 RO, there is the assumption that the original address
(Home Address) through which the connection has been established (Home Address) through which the connection has been established
is always available and in case it is not, the communication will is always available, and in case it is not, the communication will
be lost. This is achieved by leveraging in the on the trusted be lost. This is achieved by leveraging in the on the trusted
party (the Home Agent) to rely the packets to the current location party (the Home Agent) to relay the packets to the current
of the Mobile Node. In MPTCP, it is an explicit goal to provide location of the Mobile Node. In MPTCP, it is an explicit goal to
communication resilience when one of the address pairs is no provide communication resilience when one of the address pairs is
longer usable, so it is not possible to leverage on the original no longer usable, so it is not possible to leverage on the
address pair to be always working. original address pair to be always working.
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 o MIPv6 RO is, of course, designed for IPv6, and it is an explicit
solutions rely on the usage of some characteristics of IPv6 (such goal of MPTCP to support both IPv6 and IPv4. Some MIPv6 RO
as the usage of CGAs [RFC3972]), which will not be usable in the security solutions rely on the usage of some characteristics of
context of MPTCP. IPv6 (such as the usage of Cryptographically Generated Addresses
o As opposed to MPTCP, MIPv6 RO does not have a connection state (CGA) [RFC3972]), which will not be usable in the context of
MPTCP.
o As opposed to MPTCP, MIPv6 RO does not have 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 differences being:
o The Shim6 protocol is a layer 3 protocol so all the communications o The Shim6 protocol is a layer 3 protocol so all the communications
involving the target address are at stake; in MPTCP, the impact involving the target address are at stake; in MPTCP, the impact
can be limited to a single TCP connection. can be limited to a single TCP connection.
o Similarly to MIPv6 RO, Shim6 only uses IPv6 addresses as
identifiers and leverages on some of their properties to provide o Similar to MIPv6 RO, Shim6 only uses IPv6 addresses as identifiers
the security, such as relying on CGAs or HBAs [RFC5535], which is and leverages on some of their properties to provide the security,
not possible in the MPTCP case where IPv4 addresses must be such as relying on CGA or Hash-Based Addresses (HBA) [RFC5535],
supported. which is not possible in the MPTCP case where IPv4 addresses must
o Similarly to MIPv6 RO, Shim6 does not have a connection state be supported.
o Similar 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 [RFC4960]is a transport protocol that supports multiple Stream Control Transmission Protocol (SCTP) [RFC4960]is a transport
addresses per endpoint and the security implications are very close protocol that supports multiple addresses per endpoint and the
to the ones of MPTCP. A security analysis, identifying a set of security implications are very close to the ones of MPTCP. A
attacks and proposed solutions was performed in [RFC5062]. The security analysis, identifying a set of attacks and proposed
results of this analysis apply directly to the case of MPTCP. solutions was performed in [RFC5062]. The results of this analysis
However, the analysis was performed after the base SCTP protocol was apply directly to the case of MPTCP. However, the analysis was
designed and the goal of the document was essentially to improve the performed after the base SCTP was designed and the goal of the
security of SCTP. As such, the document is very specific to the document was essentially to improve the security of SCTP. As such,
actual SCTP specification and relies on the SCTP messages and the document is very specific to the actual SCTP specification and
behaviour to characterize the issues. While some them can be relies on the SCTP messages and behavior to characterize the issues.
translated to the MPTCP case, some may be caused by specific While some them can be translated to the MPTCP case, some may be
behaviour of SCTP. caused by the specific behavior of SCTP.
So, the conclusion is that while we do have a significant amount of So, the conclusion is that while there is 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 it can and will be used it
basis for this analysis, there is a set of characteristics that are as a basis for this analysis, there is a set of characteristics that
specific to MPTCP that grant the need for a specific analysis for are 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 designers to
to include a set of security mechanisms that prevent the introduction include a set of security mechanisms that prevent the introduction of
of new vulnerabilities to the Internet due to the adoption of MPTCP. new vulnerabilities to the Internet due to the adoption of MPTCP.
4. Basic MPTCP. 4. Basic MPTCP
The goal of this document is to serve as input for MPTCP protocol The goal of this document is to serve as input for MPTCP designers to
designers to properly take into account the security issues. As properly take into account the security issues. As such, the
such, the analysis cannot be performed for a specific MPTCP analysis cannot be performed for a specific MPTCP specification, but
specification, but must be a general analysis that applies to the must be a general analysis that applies to the widest possible set of
widest possible set of MPTCP designs. We will characterize what are MPTCP designs. In order to do that, the fundamental features that
the fundamental features that any MPTCP protocol must provide and any MPTCP must provide are identified and only those are assumed
attempt to perform the security implications only assuming those. In while performing the security analysis. In some cases, there is a
some cases, we will have a design choice that will significantly design choice that significantly influences the security aspects of
influence the security aspects of the resulting protocol. In that the resulting protocol. In that case, both options are considered.
case we will consider both options and try to characterize both
designs.
We assume that any MPTCP will behave in the case of a single address It is assumed that any MPTCP will behave in the case of a single
per endpoint as TCP. This means that a MPTCP connection will be address per endpoint as TCP. This means that an MPTCP connection
established by using the TCP 3-way handshake and will use a single will be established by using the TCP 3-way handshake and will use a
address pair. single address pair.
The addresses used for the establishment of the connection do have a The addresses used for the establishment of the connection do have a
special role in the sense that this is the address used as identifier special role in the sense that this is the address used as identifier
by the upper layers. The address used as destination address in the by the upper layers. The address used as destination address in the
SYN packet is the address that the application is using to identify SYN packet is the address that the application is using to identify
the peer and has been obtained either through the DNS (with or the peer and has been obtained either through the DNS (with or
without DNSSEC validation) or passed by a referral or manually without DNS Security (DNSSEC) validation) or passed by a referral or
introduced by the user. As such, the initiator does have a certain manually introduced by the user. As such, the initiator does have a
amount of trust in the fact that it is establishing a communication certain amount of trust in the fact that it is establishing a
with that particular address. If due to MPTCP, packets end up being communication with that particular address. If due to MPTCP, packets
delivered to an alternative address, the trust that the initiator has end up being delivered to an alternative address, the trust that the
placed on that address would be deceived. In any case, the adoption initiator has placed on that address would be deceived. In any case,
of MPTCP necessitates a slight evolution of the traditional TCP trust the adoption of MPTCP necessitates a slight evolution of the
model, in that the initiator is additionally trusting the peer to traditional TCP trust model, in that the initiator is additionally
provide additional addresses which it will trust to the same degree trusting the peer to provide additional addresses that it will trust
as the original pair. An application or implementation that cannot to the same degree as the original pair. An application or
trust the peer in this way should not make use of multiple paths. implementation that cannot trust the peer in this way should not make
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. It is assumed that an MPTCP
will use a single sequence number for the data, even if the data is connection will use a single sequence number for the data, even if
exchanged through different paths, as MPTCP provides an in-order the data is exchanged through different paths, as MPTCP provides an
delivery service of bytes 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. This is achieved by each to add addresses for each of the endpoints. This is achieved by each
end sending a control message containing the additional address(es). end sending a control message containing the additional address(es).
In order to associate the additional address to an ongoing In order to associate the additional address to an ongoing
connection, the connection needs to be identified. We assume that connection, the connection needs to be identified. It is assumed
the connection can be identified by the 4-tuple of source address, that the connection can be identified by the 4-tuple of source
source port, destination address, destination port used for the address, source port, destination address, destination port used for
establishment of the connection. So, at least, the control message the establishment of the connection. So, at least, the control
that will convey the additional address information can also contain message that will convey the additional address information can also
the 4-tuple in order to inform about what connection the address contain the 4-tuple in order to inform about what connection the
belong to (if no other connection identifier is defined). There are address belong to (if no other connection identifier is defined).
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 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.
The implicit mode may benefit from forms of ingress filtering The implicit mode may benefit from forms of ingress filtering
security, which would reduce the possibility of an attacker to add security, which would reduce the possibility of an attacker to add
any arbitrary address to an ongoing connection. However, ingress any arbitrary address to an ongoing connection. However, ingress
filtering deployment is far from universal, and it is unwise to rely filtering deployment is far from universal, and it is unwise to rely
on it as a basis for the protection of MPTCP. on it as a basis for the protection of MPTCP.
skipping to change at page 7, line 33 skipping to change at page 7, line 40
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.
The implicit mode may benefit from forms of ingress filtering The implicit mode may benefit from forms of ingress filtering
security, which would reduce the possibility of an attacker to add security, which would reduce the possibility of an attacker to add
any arbitrary address to an ongoing connection. However, ingress any arbitrary address to an ongoing connection. However, ingress
filtering deployment is far from universal, and it is unwise to rely filtering deployment is far from universal, and it is unwise to rely
on it as a basis for the protection of MPTCP. on it as a basis for the protection of MPTCP.
Further consideration about the interaction between ingress filtering Further consideration regarding the interaction between ingress
and implicit mode signaling is needed in the case that we need to filtering and implicit mode signaling is needed in the case that an
remove an address that is no longer available from the MPTCP address that is no longer available from the MPTCP connection is
connection. A host attached to a network that performs ingress removed. A host attached to a network that performs ingress
filtering and using implicit signaling would not be able to remove an filtering and using implicit signaling would not be able to remove an
address that is no longer available (either because of a failure or address that is no longer available (either because of a failure or
due to a mobility event) from an ongoing MPTCP connection. due to a mobility event) from an ongoing MPTCP connection.
We will assume that MPTCP will use all the address pairs that it has It is assumed that MPTCP will use all the address pairs that it has
available for sending packets and that it will distribute the load available for sending packets, and that it will distribute the load
based on congestion among the different paths. 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 flooding (or bombing) attacks. The setup for this attack is the flooding (or bombing) attacks. The setup for this attack is
depicted in the following figure: depicted in the following figure:
+--------+ (step 1) +------+ +--------+ (step 1) +------+
|Attacker| ------------------------- |Source| |Attacker| ------------------------- |Source|
| A |IPA IPS| S | | A |IPA IPS| S |
+--------+ /+------+ +--------+ /+------+
/ /
(step 2) / (step 2) /
/ /
v IPT v IPT
+------+ +------+
|Target| |Target|
| T | | T |
+------+ +------+
The scenario consists of an attacker A who has an IP address IPA. A The scenario consists of an Attacker A who has an IP address IPA. A
server that can generate a significant amount of traffic (such as a server that can generate a significant amount of traffic (such as a
streaming server), called source S and that has IP address IPS. streaming server), called source S and that has IP address IPS.
Target T has an IP address IPT. Target T has an IP address IPT.
In step 1 of this attack, the attacker A establishes a MPTCP In step 1 of this attack, the Attacker A establishes an MPTCP
connection with the source of the traffic server S and starts connection with the source of the traffic server S and starts
downloading a significant amount of traffic. The initial connection downloading a significant amount of traffic. The initial connection
only involves one IP address per endpoint, IPA and IPS. Once that only involves one IP address per endpoint, IPA and IPS. Once the
the download is on course, in the step 2 of the attack is that the download is on course, in step 2 of the attack, the Attacker A adds
attacker A adds IPT as one of the available addresses for the IPT as one of the available addresses for the communication. How the
communication. How the additional address is added depends on the additional address is added depends on the MPTCP address management
MPTCP address management mode. In explicit address management, the mode. In explicit address management, the Attacker A only needs to
attacker A only needs to send a signaling packet conveying address send a signaling packet conveying address IPT. In implicit mode, the
IPT. In implicit mode, the attacker A would need to send a packet Attacker A would need to send a packet with IPT as the source
with IPT as the source address. Depending on whether ingress address. Depending on whether ingress filtering is deployed and the
filtering is deployed and the location of the attacker, it may be location of the attacker, it may or may not be possible for the
possible or not for the attacker to send such a packet. At this attacker to send such a packet. At this stage, the MPTCP connection
stage, the MPTCP connection still has a single address for the Source still has a single address for the Source S, i.e., IPS, but has two
S i.e. IPS but has two addresses for the Attacker A, IPA and IPT. addresses for the Attacker A, IPA, and IPT. The attacker now
The attacker now attempts to get the Source S to send the traffic of attempts to get the Source S to send the traffic of the ongoing
the ongoing download to the Target T IP address i.e. IPT. The download to the Target T IP address, i.e., IPT. The attacker can do
attacker can do that by pretending that the path between IPA and IPT that by pretending that the path between IPA and IPT is congested but
is congested but that the path between IPS and IPT is not. In order that the path between IPS and IPT is not. In order to do that, it
to do that, it needs to send ACKs for the data that flows through the needs to send ACKs for the data that flows through the path between
path between IPS and IPT and do not send ACKs for the data that is IPS and IPT and not send ACKs for the data that is sent to IPA. The
sent to IPA. The details of this will depend on how the data sent details of this will depend on how the data sent through the
through the different paths is ACKed. One possibility is that ACKs different paths is ACKed. One possibility is that ACKs for the data
for the data sent using a given address pair should come in packets sent using a given address pair should come in packets containing the
containing the same address pair. If so, the attacker would need to same address pair. If so, the attacker would need to send ACKs using
send ACKs using packets containing IPT as the source address to keep packets containing IPT as the source address to keep the attack
the attack flowing. This may be possible or not depending on the flowing. This may or may not be possible depending on the deployment
deployment of ingress filtering and the location of the attacker. of ingress filtering and the location of the attacker. The attacker
The attacker would also need to guess the sequence number of the data would also need to guess the sequence number of the data being sent
being sent to the Target. Once the attacker manages to perform these to the Target. Once the attacker manages to perform these actions,
actions the attack is on place and the download will hit the target. the attack is on place and the download will hit the target. In this
In this type of attacks, the Source S still thinks it is sending type of attack, the Source S still thinks it is sending packets to
packets to the Attacker A while in reality it is sending the packet the Attacker A while in reality it is sending the packet to Target T.
to Target T.
Once that the traffic from the Source S start hitting the Target T, Once the traffic from the Source S start hitting the Target T, the
the target will react. Since the packets are likely to belong to a target will react. Since the packets are likely to belong to a non-
non existent TCP connection, the Target T will issue RST packets. It existent TCP connection, the Target T will issue RST packets. It is
is relevant then to understand how MPTCP reacts to incoming RST relevant to understand how MPTCP reacts to incoming RST packets. It
packets. It seems that the at least the MPTCP that receives a RST seems that the at least the MPTCP that receives a RST packet should
packet should terminate the packet exchange corresponding to the terminate the packet exchange corresponding to the particular address
particular address pair (maybe not the complete MPTCP connection, but pair (maybe not the complete MPTCP connection, but at least it should
at least it should not send more packets with the address pair not send more packets with the address pair involved in the RST
involved in the RST packet). However, if the attacker, before packet). However, if the attacker, before redirecting the traffic
redirecting the traffic has managed to increase the window size has managed to increase the window size considerably, the flight size
considerably, the flight size could be enough to impose a significant could be enough to impose a significant amount of traffic to the
amount of traffic to the Target node. There is a subtle operation Target node. There is a subtle operation that the attacker needs to
that the attacker needs to achieve in order to launch a significant achieve in order to launch a significant attack. On the one hand, it
attack. On the one hand it needs to grow the window enough so that needs to grow the window enough so that the flight size is big enough
the flight size is big enough to cause enough effect and on the other to cause enough effect; on the other hand, the attacker needs to be
hand the attacker needs to be able to simulate congestion on the IPA- able to simulate congestion on the IPA-IPS path so that traffic is
IPS path so that traffic is actually redirected to the alternative actually redirected to the alternative path without significantly
path without significantly reducing the window. This will heavily reducing the window. This will heavily depend on how the coupling of
depend on how the coupling of the windows between the different paths the windows between the different paths works, in particular how the
works, in particular how the windows are increased. Some designs of windows are increased. Some designs of the congestion control window
the congestion control window coupling could render this attack coupling could render this attack ineffective. If the MPTCP requires
ineffective. If the MPTCP protocol requires performing slow start performing slow start per subflow, then the flooding will be limited
per subflow, then the flooding will be limited by the slow-start by the slow-start initial window size.
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. The solution used in before actually sending data to a new address. The solution used in
other protocols, would include the Source S to explicitly asking the other protocols would include the Source S to explicitly asking the
host sitting in the new address (the Target T sitting in IPT) whether host sitting in the new address (the Target T sitting in IPT) whether
it is willing to accept packets from the MPTCP connection identified it is willing to accept packets from the MPTCP connection identified
by the 4-tuple IPA, port A, IPS, port S. Since this is not part of by the 4-tuple IPA, port A, IPS, port S. Since this is not part of
the established connection that Target T has, T would not accept the the established connection that Target T has, T would not accept the
request and Source S would not use IPT to send packets for this MPTCP request and Source S would not use IPT to send packets for this MPTCP
connection. Usually, the request also includes a nonce that cannot connection. Usually, the request also includes a nonce that cannot
be guessed by the attacker A so that it cannot fake the reply to the be guessed by the Attacker A so that it cannot fake the reply to the
request easily. In the case of SCTP, it sends a message with a 64- request easily. In the case of SCTP, it sends a message with a 64-
bit nonce (in a HEARTBEAT). 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 an 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 Another type of flooding attack that could potentially be performed
with MPTCP is one where the attacker initiates a communication with a with MPTCP is one where the attacker initiates a communication with a
peer and includes a long list of alternative addresses in explicit peer and includes a long list of alternative addresses in explicit
mode. If the peer decides to establish subflows with all the mode. If the peer decides to establish subflows with all the
available addresses, the attacker have managed to achieve an available addresses, the attacker has managed to achieve an amplified
amplified attack, since by sending a single packet containing all the attack, since by sending a single packet containing all the
alternative addresses it triggers the peer to generate packets to all alternative addresses, it triggers the peer to generate packets to
the destinations. 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
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
packets to the target). packets to the target).
The scenario for a hijacking attack is described in the next figure. The scenario for a hijacking attack is described in the next figure.
+------+ +------+ +------+ +------+
| Node | ------------------------- | Node | | Node | ------------------------- | Node |
| 1 |IP1 IP2| 2 | | 1 |IP1 IP2| 2 |
+------+ /+------+ +------+ /+------+
/ /
/ /
/ /
v IPA v IPA
+--------+ +--------+
|Attacker| |Attacker|
| A | | A |
+--------+ +--------+
We have a MPTCP connection established between Node 1 and Node 2. An MPTCP connection is established between Node 1 and Node 2. The
The connection is using only one address per endpoint, IP1 and IP2. connection is using only one address per endpoint, IP1 and IP2. The
The attacker then launches the hijacking attack by adding IPA as an attacker then launches the hijacking attack by adding IPA as an
additional address for Node 1. There is not much difference between additional address for Node 1. There is not much difference between
explicit or implicit address management, since in both cases the explicit or implicit address management, since, in both cases, the
Attacker A could easily send a control packet adding the address IPA, Attacker A could easily send a control packet adding the address IPA,
either as control data or as the source address of the control either as control data or as the source address of the control
packet. In order to be able to hijack the connection, the attacker packet. In order to be able to hijack the connection, the attacker
needs to know the 4-tuple that identifies the connection, including needs to know the 4-tuple that identifies the connection, including
the pair of addresses and the pair of ports. It seems reasonable to the pair of addresses and the pair of ports. It seems reasonable to
assume that knowing the source and destination IP addresses and the assume that knowing the source and destination IP addresses and the
port of the server side is fairly easy for the attacker. Learning port of the server side is fairly easy for the attacker. Learning
the port of the client (i.e. of the initiator of the connection) may the port of the client (i.e., of the initiator of the connection) may
prove to be more challenging. The attacker would need to guess what prove to be more challenging. The attacker would need to guess what
the port is or to learn it by intercepting the packets. Assuming the port is or to learn it by intercepting the packets. Assuming
that the attacker can gather the 4-tuple and issue the message adding that the attacker can gather the 4-tuple and issue the message adding
IPA to the addresses available for the MPTCP connection, then the IPA to the addresses available for the MPTCP connection, then the
attacker A has been able to participate in the communication. In Attacker A has been able to participate in the communication. In
particular: 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 multipath
capabilities, we can assume that unless there are already many IP capabilities, it can be assumed that unless there are already many
address pairs in use in the MPTCP connection, Node 2 will start IP 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 already has negative effects, since Node 1 will not receive This already has negative effects, since Node 1 will not receive
all the data from Node 2. Moreover, from the application all the data from Node 2. Moreover, from the application
perspective, this would result in DoS attack, since the byte flow perspective, this would result in a Denial-of-Service (DoS)
will stop waiting for the missing data. However, it is not enough attack, since the byte flow will stop waiting for the missing
to achieve full hijacking of the connection, since part of data data. However, it is not enough to achieve full hijacking of the
will be still delivered to IP1, so it would reach Node 1 and not connection, since part of data will be still delivered to IP1, so
the Attacker. In order for the attacker to receive all the data it would reach Node 1 and not the attacker. In order for the
of the MPTCP connection, the Attacker must somehow remove IP1 of attacker to receive all the data of the MPTCP connection, the
the set of available addresses for the connection. in the case of attacker must somehow remove IP1 of the set of available addresses
implicit address management, this operation is likely to imply for the connection. In the case of implicit address management,
sending a termination packet with IP1 as source address, which may this operation is likely to imply sending a termination packet
or not be possible for the attacker depending on whether ingress with IP1 as source address, which may or may not be possible for
filtering is in place and the location of the attacker. If the attacker depending on whether ingress filtering is in place
explicit address management is used, then the attacker will send a and the location of the attacker. If explicit address management
remove address control packet containing IP1. Once IP1 is is used, then the attacker will send a remove address control
removed, all the data sent by Node 2 will reach the Attacker and packet containing IP1. Once IP1 is removed, all the data sent by
the incoming traffic has been hijacked. Node 2 will reach the 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
Attacker can send packets using IPA and those packets will be attacker can send packets using IPA, and those packets will be
considered by Node 2 as part of MPTCP connection. This means that considered as part of MPTCP connection by Node 2. This means that
the attacker will be able to inject data into the MPTCP the attacker will be able to inject data into the MPTCP
connection, so from this perspective, the attacker has hijacked connection, so from this perspective, the attacker has hijacked
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 sources of MPTCP connection. This means that there will be two sources 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 an MiTM attack. The scenario for the attack is depicted in the
depicted in the figure below. figure below.
+------+ +------+ +------+ +------+
| Node | --------------- | Node | | Node | --------------- | Node |
| 1 |IP1 IP2| 2 | | 1 |IP1 IP2| 2 |
+------+ \ /+------+ +------+ \ /+------+
\ / \ /
\ / \ /
\ / \ /
v IPA v v IPA v
+--------+ +--------+
|Attacker| |Attacker|
| A | | A |
+--------+ +--------+
There is an established connection between Node 1 and Node 2. The There is an established connection between Node 1 and Node 2. The
Attacker A will use the MPTCP address agility capabilities to place Attacker A will use the MPTCP address agility capabilities to place
itself as a MitM. In order to do so, it will add IP address IPA as itself as a MiTM. In order to do so, it will add IP address IPA as
an additional address for the MPTCP connection on both Node 1 and an additional address for the MPTCP connection on both Node 1 and
Node 2. This is essentially the same technique described earlier in Node 2. This is essentially the same technique described earlier in
this section, only that it is used against both nodes involved in the this section, only that it is used against both nodes involved in the
communication. The main difference is that in this case, the communication. The main difference is that in this case, the
attacker can simply sniff the content of the communication that is attacker can simply sniff the content of the communication that is
forwarded through it and in turn forward the data to the peer of the forwarded through it and in turn forward the data to the peer of the
communication. The result is that the attacker can place himself in communication. The result is that the attacker can place himself in
the middle of the communication and sniff part of the traffic the middle of the communication and sniff part of the traffic
unnoticed. Similar considerations about how the attacker can manage unnoticed. Similar considerations about how the attacker can manage
to get to see all the traffic by removing the genuine address of the to get to see all the traffic by removing the genuine address of the
peer apply. peer apply.
6.2. Time-shifted hijacking attacks 6.2. Time-Shifted Hijacking Attacks
A simple way to prevent off-path attackers to launch hijacking A simple way to prevent off-path attackers from launching hijacking
attacks is to provide security of the control messages that add and attacks is to provide security for the control messages that adds and
remove addresses by the usage of a cookie. In this type of removes addresses by the usage of a cookie. In this type of
approaches, the peers involved in the MPTCP connection agree on a approaches, the peers involved in the MPTCP connection agree on a
cookie, that is exchanged in plain text during the establishment of cookie that is exchanged in plaintext during the establishment of the
the connection and that needs to be presented in every control packet connection and that needs to be presented in every control packet
that adds or removes an address for any of the peers. The result is that adds or removes an address for any of the peers. The result is
that the attacker needs to know the cookie in order to launch any of that the attacker needs to know the cookie in order to launch any of
the hijacking attacks described earlier. This implies that off path the hijacking attacks described earlier. This implies that off-path
attackers can no longer perform the hijacking attacks and that only attackers can no longer perform the hijacking attacks and that only
on-path attackers can do so, so one may consider that a cookie based on-path attackers can do so, so one may consider a cookie-based
approach to secure MPTCP connection results in similar security than approach to secure MPTCP connection results in similar security to
current TCP. While it is close, it is not entirely true. current TCP. While it is close, it is not entirely true.
The main difference between the security of a MPTCP protocol secured The main difference between the security of an MPTCP secured through
through cookies and the current TCP protocol are the time shifted cookies and the current TCP is the time-shifted attacks. As has been
attacks. As we described earlier, a time shifted attack is one where described earlier, a time-shifted attack is one where the attacker is
the attacker is along the path during a period of time, and then along the path during a period of time, and then moves away but the
moves away but the effects of the attack still remains, after the effects of the attack still remain, after the attacker is long gone.
attacker is long gone. In the case of a MPTCP protocol secured In the case of an MPTCP secured through the usage of cookies, the
through the usage of cookies, the attacker needs to be along the path attacker needs to be along the path until the cookie is exchanged.
until the cookie is exchanged. After the attacker has learnt the After the attacker has learned the cookie, it can move away from the
cookie, it can move away from the path and can still launch the path and can still launch the hijacking attacks described in the
hijacking attacks described in the previous section. previous section.
There are several types of approaches that provide some protection There are several types of approaches that provide some protection
against hijacking attacks and that are vulnerable to some forms of against hijacking attacks and that are vulnerable to some forms of
time-shifted attacks. We will next present some general taxonomy of time-shifted attacks. A general taxonomy of solutions and the
solutions and we describe the residual threats: residual threats for each type is presented next:
o Cookie-based solution: As we described earlier, one possible
approach is to use a cookie, that is sent in clear text in every o Cookie-based solution: As it has been described earlier, one
MPTCP control message that adds a new address to the existing possible approach is to use a cookie that is sent in cleartext in
connection. The residual threat in this type of solution is that every MPTCP control message that adds a new address to the
any attacker that can sniff any of these control messages will existing connection. The residual threat in this type of solution
learn the cookie and will be able to add new addresses at any is that any attacker that can sniff any of these control messages
will learn the cookie and will be able to add new addresses at any
given point in the lifetime of the connection. Moreover, the given point in the lifetime of the connection. Moreover, the
endpoints will not detect the attack since the original cookie is endpoints will not detect the attack since the original cookie is
being used by the attacker. Summarizing, the vulnerability window being used by the attacker. Summarizing, the vulnerability window
of this type of attacks includes all the flow establishment of this type of attacks includes all the flow establishment
exchanges and it is undetectable by the endpoints. exchanges and it is undetectable by the endpoints.
o Shared secret exchanged in plain text: An alternative option that
is more secure than the cookie based approach is to exchange a key o Shared secret exchanged in plaintext: An alternative option that
in clear text during the establishment of the first subflow and is more secure than the cookie-based approach is to exchange a key
then validate the following subflows by using a keyed HMAC in cleartext during the establishment of the first subflow and
signature using the shared key. This solution would be vulnerable then validate the following subflows by using a keyed Hashed
to attackers sniffing the message exchange for the establishment Message Authentication Code (HMAC) signature using the shared key.
of the first subflow, but after that, the shared key is not This solution would be vulnerable to attackers sniffing the
transmitted any more, so the attacker cannot learn it through message exchange for the establishment of the first subflow, but
sniffing any other message. Unfortunately, in order to be after that, the shared key is not transmitted any more, so the
compatible with NATs (see analysis below) even though this attacker cannot learn it through sniffing any other message.
approach includes a keyed HMAC signature, this signature cannot Unfortunately, in order to be compatible with NATs (see analysis
cover the IP address that is being added. This means that this below) even though this approach includes a keyed HMAC signature,
type of approaches are also vulnerable to integrity attacks of the this signature cannot cover the IP address that is being added.
exchanged messages. This means that even though the attacker This means that this type of approaches are also vulnerable to
cannot learn the shared key by sniffing the subsequent subflow integrity attacks of the exchanged messages. This means that even
establishment, the attacker can modify the subflow establishment though the attacker cannot learn the shared key by sniffing the
message and change the address that is being added. So, the subsequent subflow establishment, the attacker can modify the
vulnerability window for confidentially to the shared key is subflow establishment message and change the address that is being
limited to the establishment of the first subflow, but the added. So, the vulnerability window for confidentially to the
vulnerability window for integrity attacks still includes all the shared key is limited to the establishment of the first subflow,
subflow establishment exchanges. These attacks are still but the vulnerability window for integrity attacks still includes
all the subflow establishment exchanges. These attacks are still
undetectable by the endpoints. The SCTP security falls in this undetectable by the endpoints. The SCTP security falls in this
category. category.
o Strong crypto anchor exchange. Another approach that could be
used would be to exchange some strong crypto anchor while the o Strong crypto anchor exchange: Another approach that could be 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. Subsequent subflows could be protected by using the chain anchor. Subsequent subflows could be protected by using the
crypto material associated to that anchor. An attacker in this crypto material associated to that anchor. An attacker in this
case would need to change the crypto material exchanged in the case would need to change the crypto material exchanged in the
connection establishment phase. As a result the vulnerability connection establishment phase. As a result, the vulnerability
window for forging the crypto anchor is limited to the initial window for forging the crypto anchor is limited to the initial
connection establishment exchange. Similarly to the previous connection establishment exchange. Similar to the previous case,
case, due to NAT traversal considerations, the vulnerability due to NAT traversal considerations, the vulnerability window for
window for integrity attacks include all the subflow establishment integrity attacks include all the subflow establishment exchanges.
exchanges. Because the attacker needs to change the crypto Because the attacker needs to change the crypto anchor, this
anchor, this approach are detectable by the endpoints, if they approach are detectable by the endpoints, if they communicate
communicate directly. 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
an interesting device from a security perspective. In terms of MPTCP are an interesting device from a security perspective. In terms of
they essentially behave as a Man-in-the-Middle attacker. MPTCP MPTCP, they essentially behave as an MiTM attacker. MPTCP's security
security goal is to prevent from any attacker to insert their goal is to prevent from any attacker to insert their addresses as
addresses as valid addresses for a given MPTCP connection. But that valid addresses for a given MPTCP connection. But that is exactly
is exactly what a NAT does, they modify the addresses. So, if MPTCP what a NAT does: it modifies the addresses. So, if MPTCP is to work
is to work through NATs, MPTCP must accept address rewritten by NATs through NATs, MPTCP must accept address rewritten by NATs as valid
as valid addresses for a given session. The most direct corollary is addresses for a given session. The most direct corollary is that the
that the MPTCP messages that add addresses in the implicit mode (i.e. MPTCP messages that add addresses in the implicit mode (i.e., the SYN
the SYN of new subflows) cannot be protected against integrity of new subflows) cannot be protected against integrity attacks, since
attacks, since they must allow for NATs to change their addresses. they must allow for NATs to change their addresses. This rules out
This rules out any solution that would rely on providing integrity any solution that would rely on providing integrity protection to
protection to prevent an attacker from changing the address used in a prevent an attacker from changing the address used in a subflow
subflow establishment exchange. This implies that alternative establishment exchange. This implies that alternative creative
creative mechanisms are needed to protect from integrity attacks to mechanisms are needed to protect from integrity attacks to the MPTCP
the MPTCP signaling that adds new addresses to a connection. It is signaling that adds new addresses to a connection. It is far from
far from obvious how one such creative approach could look like at obvious how one such creative approach could look like at this point.
this point.
In the case of explicit mode, you could protect the address included In the case of explicit mode, you could protect the address included
in the MPTCP option. Now the question is what address to include in in the MPTCP option. Now the question is what address to include in
the MPTCP option that conveys address information. If the address the MPTCP option that conveys address information. If the address
included is the address configured in the host interface and that included is the address configured in the host interface and that
interface is behind a NAT, the address information is useless, as the interface is behind a NAT, the address information is useless, as the
address is not actually reachable from the other end so there is no address is not actually reachable from the other end so there is no
point in conveying it and even less in securing it. It would be point in conveying it and even less in securing it. It would be
possible to envision the usage of NAT traversal techniques such as possible to envision the usage of NAT traversal techniques, such as
STUN to learn the address and port that the NAT has assigned and Session Traversal Utilities for NAT (STUN) to learn the address and
convey that information in a secure. While this is possible, it port that the NAT has assigned and convey that information in a
relies on using NAT traversal techniques and also tools to convey the secure. While this is possible, it relies on using NAT traversal
address and the port in a secure manner. techniques and also tools to convey the address and the port in a
secure manner.
7. Recommendation 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. After
order to define a proper security solution, we need to assess the evaluating the different aspects in the MPTCP WG, the conclusions are
tradeoff and make a recommendation. After evaluating the different as follows:
aspects in the MPTCP WG, our conclusion are as follows:
MPTCP should implement some form of reachability check using a random MPTCP should implement some form of reachability check using a random
nonce (e.g. TCP 3-way handshake) before adding a new address to an nonce (e.g., TCP 3-way handshake) before adding a new address to an
ongoing communication in order to prevent flooding attacks. ongoing communication in order to prevent flooding attacks.
The default security mechanisms for MPTCP should be to exchange a key The default security mechanisms for MPTCP should be to exchange a key
in clear text in the establishment of the first subflow and then in cleartext in the establishment of the first subflow and then
secure following address additions by using a keyed HMAC using the secure following address additions by using a keyed HMAC using the
exchanged key. exchanged key.
MPTCP security mechanism should support using a pre-shared key to be MPTCP security mechanism should support using a pre-shared key to be
used in the keyed HMAC, providing a higher level of protection than used in the keyed HMAC, providing a higher level of protection than
the previous one. the previous one.
A mechanism to prevent replay attacks using these messages should be A mechanism to prevent replay attacks using these messages should be
provided e.g. a sequence number protected by the HMAC. provided, e.g., a sequence number protected by the HMAC.
The MPTCP protocol should be extensible and it should able to The MPTCP should be extensible and it should be able to accommodate
accommodate multiple security solutions, in order to enable the usage multiple security solutions, in order to enable the usage of more
of more secure mechanisms if needed. 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. IANA Considerations 9. Contributors
This document does not require any action from IANA.
10. Contributors
Alan Ford - Roke Manor Research Ltd. Alan Ford - Roke Manor Research, Ltd.
11. Acknowledgments 10. Acknowledgments
Rolf Winter, Randall Stewart, Andrew McDonald, Michael Tuexen, Rolf Winter, Randall Stewart, Andrew McDonald, Michael Tuexen,
Michael Scharf, Tim Shepard, Yoshifumi Nishida, Lars Eggert, Phil Michael Scharf, Tim Shepard, Yoshifumi Nishida, Lars Eggert, Phil
Eardley, Jari Arkko, David Harrington, Dan Romascanu, Alexey Melnikov Eardley, Jari Arkko, David Harrington, Dan Romascanu, and Alexey
reviewed an earlier version of this document and provided comments to Melnikov reviewed an earlier version of this document and provided
improve it. 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.
12. References 11. References
12.1. Normative References 11.1. Normative References
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, [RFC0793] Postel, J., "Transmission Control Protocol", STD 7,
RFC 793, September 1981. RFC 793, September 1981.
12.2. Informative References 11.2. 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 17, line 18 skipping to change at page 17, line 17
[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.
[RFC4960] Stewart, R., "Stream Control Transmission Protocol", [RFC4960] Stewart, R., "Stream Control Transmission Protocol",
RFC 4960, September 2007. RFC 4960, September 2007.
[I-D.ietf-mptcp-multiaddressed] [MPTCP-MULTIADDRESSED]
Ford, A., Raiciu, C., and M. Handley, "TCP Extensions for Ford, A., Raiciu, C., and M. Handley, "TCP Extensions for
Multipath Operation with Multiple Addresses", Multipath Operation with Multiple Addresses", Work
draft-ietf-mptcp-multiaddressed-02 (work in progress), in Progress, October 2010.
October 2010.
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
URI: http://www.it.uc3m.es URI: http://www.it.uc3m.es
 End of changes. 92 change blocks. 
387 lines changed or deleted 389 lines changed or added

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