draft-ietf-mptcp-threat-05.txt   draft-ietf-mptcp-threat-06.txt 
Network Working Group M. Bagnulo Network Working Group M. Bagnulo
Internet-Draft UC3M Internet-Draft UC3M
Intended status: Informational December 6, 2010 Intended status: Informational December 7, 2010
Expires: June 9, 2011 Expires: June 10, 2011
Threat Analysis for Multi-addressed/Multi-path TCP Threat Analysis for Multi-addressed/Multi-path TCP
draft-ietf-mptcp-threat-05 draft-ietf-mptcp-threat-06
Abstract Abstract
Multi-path TCP (MPTCP for short) describes the extensions proposed Multi-path TCP (MPTCP for short) describes the extensions proposed
for TCP so that each endpoint of a given TCP connection can use for TCP so that each endpoint of a given TCP connection can use
multiple IP addresses to exchange data (instead of a single IP multiple IP addresses to exchange data (instead of a single IP
address per endpoint as currently defined). Such extensions enable address per endpoint as currently defined). Such extensions enable
the exchange of segments using different source-destination address the exchange of segments using different source-destination address
pairs, resulting in the capability of using multiple paths in a pairs, resulting in the capability of using multiple paths in a
significant number of scenarios. In particular, some level of significant number of scenarios. In particular, some level of
skipping to change at page 1, line 40 skipping to change at page 1, line 40
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on June 9, 2011. This Internet-Draft will expire on June 10, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 27 skipping to change at page 2, line 27
5. Flooding attacks . . . . . . . . . . . . . . . . . . . . . . . 7 5. Flooding attacks . . . . . . . . . . . . . . . . . . . . . . . 7
6. Hijacking attacks . . . . . . . . . . . . . . . . . . . . . . 10 6. Hijacking attacks . . . . . . . . . . . . . . . . . . . . . . 10
6.1. Hijacking attacks to the Basic MPTCP protocol . . . . . . 10 6.1. Hijacking attacks to the Basic MPTCP protocol . . . . . . 10
6.2. Time-shifted hijacking attacks . . . . . . . . . . . . . . 12 6.2. Time-shifted hijacking attacks . . . . . . . . . . . . . . 12
6.3. NAT considerations . . . . . . . . . . . . . . . . . . . . 14 6.3. NAT considerations . . . . . . . . . . . . . . . . . . . . 14
7. Recommendation . . . . . . . . . . . . . . . . . . . . . . . . 15 7. Recommendation . . . . . . . . . . . . . . . . . . . . . . . . 15
8. Security Considerations . . . . . . . . . . . . . . . . . . . 15 8. Security Considerations . . . . . . . . . . . . . . . . . . . 15
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 15 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 15
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15
12. Informative References . . . . . . . . . . . . . . . . . . . . 16 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 16 12.1. Normative 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 Multi-path TCP (MPTCP for short) describes the extensions proposed
for TCP [RFC0793] so that each endpoint of a given TCP connection can for TCP [RFC0793] so that each endpoint of a given TCP connection can
use multiple IP addresses to exchange data (instead of a single IP use multiple IP addresses to exchange data (instead of a single IP
address per endpoint as currently defined). Such extensions enable address per endpoint as currently defined). Such extensions enable
the exchange of segments using different source-destination address the exchange of segments using different source-destination address
pairs, resulting in the capability of using multiple paths in a pairs, resulting in the capability of using multiple paths in a
significant number of scenarios. In particular, some level of significant number of scenarios. In particular, some level of
skipping to change at page 4, line 16 skipping to change at page 4, line 16
hijacking Man-in-the-Middle attacks and so on. However, it is not hijacking Man-in-the-Middle attacks and so on. However, it is not
possible for the off-path attackers to launch such attacks. There is possible for the off-path attackers to launch such attacks. There is
a middle ground in case the attacker is located along the path for a a middle ground in case the attacker is located along the path for a
short period of time to launch the attack and then moves away, but short period of time to launch the attack and then moves away, but
the attack effects still apply. These are the so-called time-shifted the attack effects still apply. These are the so-called time-shifted
attacks. Since these are not possible in today's TCP, we will also attacks. Since these are not possible in today's TCP, we will also
consider them as part of the analysis. So, summarizing, we will consider them as part of the analysis. So, summarizing, we will
consider both attacks launched by off-path attackers and time-shifted consider both attacks launched by off-path attackers and time-shifted
attacks. Attacks launched by on-path attackers are out of scope, attacks. Attacks launched by on-path attackers are out of scope,
since they also apply to current single-path TCP. since they also apply to current single-path TCP.
It should be noted, however, that some current on-path attacks may
become more difficult with multi-path TCP, since an attacker (on a It should be noted, however, that some current on-path attacks may
single path) will not have visibility of the complete data stream. become more difficult with multi-path TCP, since an attacker (on a
single path) will not have visibility of the complete data stream.
3. Related work 3. Related work
There is significant amount of previous work in terms of analysis of There is significant amount of previous work in terms of analysis of
protocols that support address agility. In this section we present protocols that support address agility. In this section we present
the most relevant ones and we relate them to the current MPTCP the most relevant ones and we relate them to the current MPTCP
effort. effort.
Most of the problems related to address agility have been deeply Most of the problems related to address agility have been deeply
analyzed and understood in the context of Route Optimization support analyzed and understood in the context of Route Optimization support
skipping to change at page 15, line 27 skipping to change at page 15, line 27
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 clear text 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 protocol should be extensible and it should able to
accommodate multiple security solutions, in order to enable the usage accommodate multiple security solutions, in order to enable the usage
of more secure mechanisms if needed. of more secure mechanisms if needed.
8. Security Considerations 8. Security Considerations
This note contains a security analysis for MPTCP, so no further This note contains a security analysis for MPTCP, so no further
security considerations need to be described in this section security considerations need to be described in this section.
9. IANA Considerations 9. IANA Considerations
This document does not require any action from IANA. This document does not require any action from IANA.
10. Contributors 10. Contributors
Alan Ford - Roke Manor Research Ltd. Alan Ford - Roke Manor Research Ltd.
11. Acknowledgments 11. Acknowledgments
skipping to change at page 16, line 14 skipping to change at page 16, line 14
Michael Scharf, Tim Shepard, Yoshifumi Nishida reviewed an earlier Michael Scharf, Tim Shepard, Yoshifumi Nishida reviewed an earlier
version of this document and provided comments to improve it. version of this document and provided comments to improve it.
Mark Handley pointed out the problem with NATs and integrity Mark Handley pointed out the problem with NATs and integrity
protection of MPTCP signaling. protection of MPTCP signaling.
Marcelo Bagnulo is partly funded by Trilogy, a research project Marcelo Bagnulo is partly funded by Trilogy, a research project
supported by the European Commission under its Seventh Framework supported by the European Commission under its Seventh Framework
Program. Program.
12. Informative References 12. References
12.1. Normative References
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7,
RFC 793, September 1981.
12.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 16, line 43 skipping to change at page 17, line 5
[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.
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7,
RFC 793, September 1981.
Author's Address Author's Address
Marcelo Bagnulo Marcelo Bagnulo
Universidad Carlos III de Madrid Universidad Carlos III de Madrid
Av. Universidad 30 Av. Universidad 30
Leganes, Madrid 28911 Leganes, Madrid 28911
SPAIN SPAIN
Phone: 34 91 6248814 Phone: 34 91 6248814
Email: marcelo@it.uc3m.es Email: marcelo@it.uc3m.es
 End of changes. 9 change blocks. 
15 lines changed or deleted 22 lines changed or added

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