draft-ietf-mptcp-threat-00.txt   draft-ietf-mptcp-threat-01.txt 
Network Working Group M. Bagnulo Network Working Group M. Bagnulo
Internet-Draft UC3M Internet-Draft UC3M
Intended status: Informational February 18, 2010 Intended status: Informational March 8, 2010
Expires: August 22, 2010 Expires: September 9, 2010
Threat Analysis for Multi-addressed/Multi-path TCP Threat Analysis for Multi-addressed/Multi-path TCP
draft-ietf-mptcp-threat-00 draft-ietf-mptcp-threat-01
Abstract Abstract
Multi-addresses/Multi-path TCP (MPTCP for short) describes the Multi-addresses/Multi-path TCP (MPTCP for short) describes the
extensions proposed for TCP so that each endpoint of a given TCP extensions proposed for TCP so that each endpoint of a given TCP
connection can use multiple IP addresses to exchange data (instead of connection can use multiple IP addresses to exchange data (instead of
a single IP address per endpoint as currently defined). Such a single IP address per endpoint as currently defined). Such
extensions enable the exchange of segments using different source- extensions enable the exchange of segments using different source-
destination address pairs, resulting in the capability of using destination address pairs, resulting in the capability of using
multiple paths in a significant number of scenarios. In particular, multiple paths in a significant number of scenarios. In particular,
skipping to change at page 1, line 47 skipping to change at page 1, line 47
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 22, 2010. This Internet-Draft will expire on September 9, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
skipping to change at page 2, line 26 skipping to change at page 2, line 26
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Related work . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Related work . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Basic MPTCP. . . . . . . . . . . . . . . . . . . . . . . . . . 6 4. Basic MPTCP. . . . . . . . . . . . . . . . . . . . . . . . . . 6
5. Flooding attacks . . . . . . . . . . . . . . . . . . . . . . . 7 5. Flooding attacks . . . . . . . . . . . . . . . . . . . . . . . 7
6. Hijacking attacks . . . . . . . . . . . . . . . . . . . . . . 9 6. Hijacking attacks . . . . . . . . . . . . . . . . . . . . . . 9
6.1. Hijacking attacks to the Basic MPTCP protocol . . . . . . 9 6.1. Hijacking attacks to the Basic MPTCP protocol . . . . . . 9
6.2. Time-shifted hijacking attacks to cookie based secured 6.2. Time-shifted hijacking attacks . . . . . . . . . . . . . . 12
MPTCP . . . . . . . . . . . . . . . . . . . . . . . . . . 12 6.3. NAT considerations . . . . . . . . . . . . . . . . . . . . 13
7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 7. Security Considerations . . . . . . . . . . . . . . . . . . . 14
8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 12 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 14
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14
10. Informative References . . . . . . . . . . . . . . . . . . . . 13 10. Informative References . . . . . . . . . . . . . . . . . . . . 14
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 13 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 15
1. Introduction 1. Introduction
Multi-addresses/Multi-path TCP (MPTCP for short) describes the Multi-addresses/Multi-path TCP (MPTCP for short) describes the
extensions proposed for TCP so that each endpoint of a given TCP extensions proposed for TCP so that each endpoint of a given TCP
connection can use multiple IP addresses to exchange data (instead of connection can use multiple IP addresses to exchange data (instead of
a single IP address per endpoint as currently defined). Such a single IP address per endpoint as currently defined). Such
extensions enable the exchange of segments using different source- extensions enable the exchange of segments using different source-
destination address pairs, resulting in the capability of using destination address pairs, resulting in the capability of using
multiple paths in a significant number of scenarios. In particular, multiple paths in a significant number of scenarios. In particular,
skipping to change at page 11, line 47 skipping to change at page 11, line 47
v IPA v v IPA v
+--------+ +--------+
|Attacker| |Attacker|
| A | | A |
+--------+ +--------+
In this case, there is an established connection between Node 1 and In this case, there is an established connection between Node 1 and
Node 2. The Attacker A will use the MPTCP address agility Node 2. The Attacker A will use the MPTCP address agility
capabilities to place itself as a MitM. In order to do so, it will capabilities to place itself as a MitM. In order to do so, it will
add IP address IPA as an additional address for the MPTCP connection add IP address IPA as an additional address for the MPTCP connection
on both Node 1 and Node 2. this is essentially the same technique on both Node 1 and Node 2. This is essentially the same technique
described earlier in this section, only that it is used against both described earlier in this section, only that it is used against both
nodes involved in the communication. The main difference is that in nodes involved in the communication. The main difference is that in
this case, the attacker can simply sniff the content of the this case, the attacker can simply sniff the content of the
communication that is forwarded through it and in turn forward the communication that is forwarded through it and in turn forward the
data to the peer of the communication. The result is that the data to the peer of the communication. The result is that the
attacker can place himself in the middle of the communication and attacker can place himself in the middle of the communication and
sniff part of the traffic unnoticed. Similar considerations about sniff part of the traffic unnoticed. Similar considerations about
how the attacker can manage to get to see all the traffic by removing how the attacker can manage to get to see all the traffic by removing
the genuine address of the peer apply. the genuine address of the peer apply.
6.2. Time-shifted hijacking attacks to cookie based secured MPTCP 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 to launch hijacking
attacks is to provide security of the control messages that add and attacks is to provide security of the control messages that add and
remove addresses by the usage of a cookie. In this type of remove 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 plain text during the establishment of
the connection and that needs to be presented in every control packet the 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
skipping to change at page 12, line 40 skipping to change at page 12, line 40
through cookies and the current TCP protocol are the time shifted through cookies and the current TCP protocol are the time shifted
attacks. As we described earlier, a time shifted attack is one where attacks. As we described earlier, a time shifted attack is one where
the attacker is along the path during a period of time, and then the attacker is along the path during a period of time, and then
moves away but the effects of the attack still remains, after the moves away but the effects of the attack still remains, after the
attacker is long gone. In the case of a MPTCP protocol secured attacker is long gone. In the case of a MPTCP protocol secured
through the usage of cookies, the attacker needs to be along the path through the usage of cookies, the attacker needs to be along the path
until the cookie is exchanged. After the attacker has learnt the until the cookie is exchanged. After the attacker has learnt the
cookie, it can move away from the path and can still launch the cookie, it can move away from the path and can still launch the
hijacking attacks described in the previous section. hijacking attacks described in the previous section.
There are several type of approaches that provide some protection
against hijacking attacks and that are vulnerable to some forms of
time-shifted attacks. We will next present some general taxonomy of
solutions based on the residual threats:
o Cookie-based solution: As we described earlier, one possible
approach is to use a cookie, that is sent in clear text in every
MPTCP control message that adds a new address to the existing
connection. The residual threat in this type of solution 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
endpoints will not detect the attack since the original cookie is
being used by the attacker. Summarizing, the vulnerability window
of this type of attacks includes all the flow establishment
exchanges and it is undetectable by the endpoints.
o Shared secret exchanged in plain text: An alternative option that
is somehow more secure than the cookie based approach is to
exchange a secret in clear text during the establishment of the
first subflow and then validate the following subflows by using an
keyed HMAC signature using the shared secret. This solution would
be vulnerable to attackers sniffing the message exchange for the
establishment of the first subflow, but after that, the shared
secret is not transmitted any more, so the attacker cannot learn
it through sniffing any other message. Unfortunately, in order to
be compatible with NATs (see analysis below) even though this
approach includes a keyed HMAC signature, this signature cannot
cover the IP address that is being added. This basically means
that this type of approaches are also vulnerable to integrity
attacks of the exchanged messages. This means that even though
the attacker cannot learn the shared secret by sniffing the
subsequent sublfow establishment, the attacker can modify the
subflow establishment message and change the address that is being
added. So, the vulnerability window for confidentially to the
shared secret is limited to the establishment of the first
subflow, but the vulnerability window for integrity attacks still
includes all the subflow establishment exchanges. These attacks
are still undetectable by the endpoints.
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
chain anchor. In this case, subsequent sublfows could be
protected by using the crypto material associated to that anchor.
An attacker in this case would need to change the crypto material
exchanged in the connection establishment phase. As a result the
vulnerability window for forging the crypto anchor is limited to
the initial connection establishment exchange. Similarly to the
previous case, due to NAT traversal considerations, the
vulnerability window for integrity attacks include all the subflow
establishment exchanges. As opposed to the previous one, because
the attacker needs to change the crypto anchor, this approach are
detectable by the endpoints, if they communicate directly.
6.3. NAT considerations
In order to be widely adopted MPTCP must work through NATs. NATs are
an interesting device from a security perspective. In terms of MPTCP
they essentially behave as a Man-in-the-middle attacker. As we have
described earlier, MPTCP security goal is to prevent from any
attacker to insert their addresses as valid addresses for a given
MPTCP connection. But that is exactly what a NAT does, they modify
the addresses. So, if MPTCP is to work through NATs, MPTCP must
accept address rewritten by NATs as valid addresses for a given
session. The most direct corollary is that the MPTCP messages that
add addresses in the implicit mode (i.e. the SYN of new subflows)
cannot be protected against integrity attacks, since they must allow
for NATs to change their addresses. This basically rules out any
solution that would rely on providing integrity protection to prevent
an attacker from changing the address used in a subflow establishment
exchange. This implies that alternative creative mechanisms are
needed to protect from integrity attacks to the MPTCP signaling that
adds new addresses to a connection. It is far from obvious how one
such creative approach could look like at this point.
7. Security Considerations 7. 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
8. Contributors 8. Contributors
Alan Ford - Roke Manor Research Ltd. Alan Ford - Roke Manor Research Ltd.
9. Acknowledgments 9. Acknowledgments
Rolf Winter reviewed an earlier version of this document and provided Rolf Winter reviewed an earlier version of this document and provided
comments to improve it. comments to improve it.
Mark Handley pointed out the problem with NATs and integrity
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.
10. Informative References 10. 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.
 End of changes. 8 change blocks. 
13 lines changed or deleted 89 lines changed or added

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