draft-ietf-mptcp-threat-06.txt   draft-ietf-mptcp-threat-07.txt 
Network Working Group M. Bagnulo Network Working Group M. Bagnulo
Internet-Draft UC3M Internet-Draft UC3M
Intended status: Informational December 7, 2010 Intended status: Informational January 11, 2011
Expires: June 10, 2011 Expires: July 15, 2011
Threat Analysis for Multi-addressed/Multi-path TCP Threat Analysis for TCP Extensions for Multi-path Operation with
draft-ietf-mptcp-threat-06 Multiple Addresses
draft-ietf-mptcp-threat-07
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 endpoints of a given TCP connection can use multiple
multiple IP addresses to exchange data (instead of a single IP paths to exchange data. Such extensions enable the exchange of
address per endpoint as currently defined). Such extensions enable segments using different source-destination address pairs, resulting
the exchange of segments using different source-destination address in the capability of using multiple paths in a significant number of
pairs, resulting in the capability of using multiple paths in a scenarios. In particular, some level of multihoming and mobility
significant number of scenarios. In particular, some level of support can be achieved through these extensions. However, the
multihoming and mobility support can be achieved through these support for multiple IP addresses per endpoint may have implications
extensions. However, the support for multiple IP addresses per on the security of the resulting MPTCP protocol. This note includes
endpoint may have implications on the security of the resulting MPTCP a threat analysis for MPTCP.
protocol. This note includes a threat analysis for MPTCP.
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on June 10, 2011. This Internet-Draft will expire on July 15, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2010 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
skipping to change at page 3, line 8 skipping to change at page 3, line 8
10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 15 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 15
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
12.1. Normative References . . . . . . . . . . . . . . . . . . . 16 12.1. Normative References . . . . . . . . . . . . . . . . . . . 16
12.2. Informative References . . . . . . . . . . . . . . . . . . 16 12.2. Informative References . . . . . . . . . . . . . . . . . . 16
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 17 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 endpoints of a given TCP connection can use
use multiple IP addresses to exchange data (instead of a single IP multiple paths to exchange data. Such extensions enable the exchange
address per endpoint as currently defined). Such extensions enable of segments using different source-destination address pairs,
the exchange of segments using different source-destination address resulting in the capability of using multiple paths in a significant
pairs, resulting in the capability of using multiple paths in a number of scenarios. In particular, some level of multihoming and
significant number of scenarios. In particular, some level of mobility support can be achieved through these extensions. However,
multihoming and mobility support can be achieved through these the support for multiple IP addresses per endpoint may have
extensions. However, the support for multiple IP addresses per implications on the security of the resulting MPTCP protocol. This
endpoint may have implications on the security of the resulting MPTCP note includes a threat analysis for MPTCP. It should be noted that
protocol. This note includes a threat analysis for MPTCP. It should there are there may other ways to provide multiple paths for a TCP
be noted that there are there may other ways to provide multiple connection other than the usage of multiple addresses. The threat
paths for a TCP connection other than the usage of multiple analysis performed in this document is limited to the specific case
addresses. The threat analysis performed in this document is limited 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 Multi-path TCP. Essentially what
is needed is for different segments of the communication to be is needed is for different segments of the communication to be
forwarded through different paths by enabling the sender to specify forwarded through different paths by enabling the sender to specify
some form of path selector. There are multiple options for such path some form of path selector. There are multiple options for such a
selector, including the usage of different next hops, using tunnels path selector, including the usage of different next hops, using
to different egress points and so on. In this note, we will focus on tunnels to different egress points and so on. In this note, we will
a particular approach, namely MPTCP approaches that rely on the usage focus on a particular approach, namely MPTCP, that rely on the usage
of multiple IP address per endpoint and that use different source- of multiple IP address per endpoint and that uses different source-
destination address pairs as a mean to express different paths. So, destination address pairs as a mean to express different paths. So,
in the rest of this note, the MPTCP expression will refer to this in the rest of this note, the MPTCP expression will refer to this
Multi-addressed flavour of Multi-path TCP. Multi-addressed flavour of Multi-path TCP
[I-D.ietf-mptcp-multiaddressed].
In this note we perform a threat analysis for MPTCP. Introducing the In this note we perform a threat analysis for MPTCP. Introducing the
support of multiple addresses per endpoint in a single TCP connection support of multiple addresses per endpoint in a single TCP connection
may result in additional vulnerabilities. The scope of this note is may result in additional vulnerabilities compared to single-path TCP.
to identify and characterize these new vulnerabilities. So, the The scope of this note is to identify and characterize these new
scope of the analysis is limited to the additional vulnerabilities vulnerabilities. So, the scope of the analysis is limited to the
resulting from the multi-address support compared to the current TCP additional vulnerabilities resulting from the multi-address support
protocol (where each endpoint only has one address available for use compared to the current TCP protocol (where each endpoint only has
per connection). In other words, a full analysis of the complete set one address available for use per connection). In other words, a
of threats is explicitly out of the scope. The goal of this analysis full analysis of the complete set of threats is explicitly out of the
is to help the MPTCP protocol designers to create a MPTCP that is as scope. The goal of this analysis is to help the MPTCP protocol
secure as the current TCP. It is a non goal of this analysis to help designers create an MPTCP specification that is as secure as the
in the design of MPTCP that is more secure than regular TCP. current TCP. It is a non-goal of this analysis to help in the design
of MPTCP that is more secure than regular TCP.
In particular, we will focus on attackers that are not along the In particular, we will focus on attackers that are not along the
path, at least not during the whole duration of the connection. In path, at least not during the whole duration of the connection. In
the current single path TCP, an on-path attacker can launch a the current single path TCP, an on-path attacker can launch a
significant number of attacks, including eavesdropping, connection significant number of attacks, including eavesdropping, connection
hijacking Man-in-the-Middle attacks and so on. However, it is not hijacking Man-in-the-Middle attacks and so on. However, it is not
possible for the off-path attackers to launch such attacks. There is possible for the off-path attackers to launch such attacks. There is
a middle ground in case the attacker is located along the path for a a middle ground in case the attacker is located along the path for a
short period of time to launch the attack and then moves away, but short period of time to launch the attack and then moves away, but
the attack effects still apply. These are the so-called time-shifted the attack effects still apply. These are the so-called time-shifted
skipping to change at page 4, line 23 skipping to change at page 4, line 24
consider both attacks launched by off-path attackers and time-shifted consider both attacks launched by off-path attackers and time-shifted
attacks. Attacks launched by on-path attackers are out of scope, attacks. Attacks launched by on-path attackers are out of scope,
since they also apply to current single-path TCP. since they also apply to current single-path TCP.
It should be noted, however, that some current on-path attacks may It should be noted, however, that some current on-path attacks may
become more difficult with multi-path TCP, since an attacker (on a become more difficult with multi-path TCP, since an attacker (on a
single path) will not have visibility of the complete data stream. 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 a significant amount of previous work in terms of analysis
protocols that support address agility. In this section we present of protocols that support address agility. In this section we
the most relevant ones and we relate them to the current MPTCP present the most relevant ones and we relate them to the current
effort. 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 rational
for the design of the security of MIPv6 RO. All the attacks for the design of the security of MIPv6 RO. All the attacks
described in the aforementioned analysis apply here and are an described in the aforementioned analysis apply here and are an
excellent basis for our own analysis. The main differences are: excellent basis for our own analysis. The main differences are:
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. In other words, if a binding between two address is is at stake. In other words, if a binding between two addresses
created at the IP layer, this binding can and will affect all the is created at the IP layer, this binding can and will affect all
connections that involve those addresses. However, in MPTCP, if the connections that involve those addresses. However, in MPTCP,
an additional address is added to an ongoing TCP connection, the if an additional address is added to an ongoing TCP connection,
additional address will/can only affect the connection at hand and the additional address will/can only affect the connection at hand
not other connections even if the same address is being used for and not other connections even if the same address is being used
those other connections. The result is that in MPTCP there is for those other connections. The result is that in MPTCP there is
much less at stake and the resulting vulnerabilities are less. On much less at stake and the resulting vulnerabilities are less. On
the other hand, it is very important to keep the assumption valid the other hand, it is very important to keep the assumption valid
that the address bindings for a given connection do not affect that the address bindings for a given connection do not affect
other connections. If reusing of binding or security information other connections. If reusing of binding or security information
is to be considered, this assumption could be no longer valid and is to be considered, this assumption could be no longer valid and
the full impact of the vulnerabilities must be assessed. the full impact of the vulnerabilities must be assessed.
o In MIPv6 RO, there is the assumption that the original path o In MIPv6 RO, there is the assumption that the original path
through which the connection has been established is always through which the connection has been established is always
available and in case it is not, the communication will be lost. available and in case it is not, the communication will be lost.
skipping to change at page 6, line 4 skipping to change at page 6, line 4
However, the analysis was performed after the base SCTP protocol was However, the analysis was performed after the base SCTP protocol was
designed and the goal of the document was essentially to improve the designed and the goal of the document was essentially to improve the
security of SCTP. As such, the document is very specific to the security of SCTP. As such, the document is very specific to the
actual SCTP specification and relies on the SCTP messages and actual SCTP specification and relies on the SCTP messages and
behaviour to characterize the issues. While some them can be behaviour to characterize the issues. While some them can be
translated to the MPTCP case, some may be caused by specific translated to the MPTCP case, some may be caused by specific
behaviour of SCTP as defined. behaviour of SCTP as defined.
So, the conclusion is that while we do have a significant amount of So, the conclusion is that while we do have a 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 we can and will use it as a
basis for this analysis, there are a set of characteristics that are basis for this analysis, there is a set of characteristics that are
specific to MPTCP that grant the need for a specific analysis for 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 protocol designers
to include a set of security mechanisms that prevent the introduction to include a set of security mechanisms that prevent the introduction
of new vulnerabilities to the Internet due to the adoption of MPTCP. of new vulnerabilities to the Internet due to the adoption of MPTCP.
4. Basic MPTCP. 4. Basic MPTCP.
As we stated earlier, the goal of this document is to serve as input As we stated earlier, the goal of this document is to serve as input
for MPTCP protocol designers to properly take into account the for MPTCP protocol designers to properly take into account the
security issues. As such, the analysis cannot be performed for a security issues. As such, the analysis cannot be performed for a
skipping to change at page 8, line 37 skipping to change at page 8, line 37
traffic. The initial connection only involves one IP address per traffic. The initial connection only involves one IP address per
endpoint, namely IPA and IPS. Once that the download is on course, endpoint, namely IPA and IPS. Once that the download is on course,
the second step of the attack (depicted as step 2 in the figure) is the second step of the attack (depicted as step 2 in the figure) is
that the attacker A adds IPT as one of the available addresses for that the attacker A adds IPT as one of the available addresses for
the communication. How the additional address is added depends on the communication. How the additional address is added depends on
the MPTCP address management mode. In explicit address management, the MPTCP address management mode. In explicit address management,
the attacker A only needs to send a signaling packet conveying the attacker A only needs to send a signaling packet conveying
address IPT. In implicit mode, the attacker A would need to send a address IPT. In implicit mode, the attacker A would need to send a
packet with IPT as the source address. Depending on whether ingress packet with IPT as the source address. Depending on whether ingress
filtering is deployed and the location of the attacker, it may be filtering is deployed and the location of the attacker, it may be
possible or not for the attacker to send such packet. At this stage, possible or not for the attacker to send such a packet. At this
the MPTCP connection still has a single address for the Source S i.e. stage, the MPTCP connection still has a single address for the Source
IPS but has two addresses for the Attacker A, namely IPA and IPT. S i.e. IPS but has two addresses for the Attacker A, namely IPA and
The attacker now attempts to get the Source S to send the traffic of IPT. The attacker now attempts to get the Source S to send the
the ongoing download to the Target T IP address i.e. IPT. The traffic of the ongoing download to the Target T IP address i.e. IPT.
attacker can do that by pretending that the path between IPA and IPT The attacker can do that by pretending that the path between IPA and
is congested but that the path between IPS and IPT is not. In order IPT is congested but that the path between IPS and IPT is not. In
to do that, it needs to send ACKs for the data that flows through the order to do that, it needs to send ACKs for the data that flows
path between IPS and IPT and do not send ACKs for the data that is through the path between IPS and IPT and do not send ACKs for the
sent to IPA. The actual details of this will depend on how the data data that is sent to IPA. The actual details of this will depend on
sent through the different paths is ACKed. One possibility is that how the data sent through the different paths is ACKed. One
ACKs for the data sent using a given a given address pair should come possibility is that ACKs for the data sent using a given address pair
in packets containing the same address pair. If so, the attacker should come in packets containing the same address pair. If so, the
would need to send ACKs using packets containing IPT as the source attacker would need to send ACKs using packets containing IPT as the
address to keep the attack flowing. This may be possible or not source address to keep the attack flowing. This may be possible or
depending on the deployment of ingress filtering and the location of not depending on the deployment of ingress filtering and the location
the attacker. The attacker would also need to guess the sequence of the attacker. The attacker would also need to guess the sequence
number of the data being sent to the Target. Once the attacker number of the data being sent to the Target. Once the attacker
manages to perform these actions the attack is on place and the manages to perform these actions the attack is on place and the
download will hit the target. It should be noted that in this type download will hit the target. It should be noted that in this type
of attacks, the Source S still thinks it is sending packets to the of attacks, the Source S still thinks it is sending packets to the
Attacker A while in reality it is sending the packet to Target T. Attacker A while in reality it is sending the packet to Target T.
Once that the traffic from the Source S start hitting the Target T, Once that the traffic from the Source S start hitting the Target T,
the target will react. In particular, since the packets are likely the target will react. In particular, since the packets are likely
to belong to a non existent TCP connection, the Target T will issue to belong to a non existent TCP connection, the Target T will issue
RST packets. It is relevant then to understand how MPTCP reacts to RST packets. It is relevant then to understand how MPTCP reacts to
skipping to change at page 10, line 13 skipping to change at page 10, line 13
nonce (in a HEARTBEAT). nonce (in a HEARTBEAT).
One possible approach to do this reachability test would be to One possible approach to do this reachability test would be to
perform a 3-way handshake for each new address pair that is going to perform a 3-way handshake for each new address pair that is going to
be used in a MPTCP connection. While there are other reasons for be used in a MPTCP connection. While there are other reasons for
doing this (such as NAT traversal), such approach would also act as a doing this (such as NAT traversal), such approach would also act as a
reachability test and would prevent the flooding attacks described in reachability test and would prevent the flooding attacks described in
this section. this section.
Another type of flooding attack that could potentially be performed Another type of flooding attack that could potentially be performed
with MPTCP is one where the attacker initiates a a communication with with MPTCP is one where the attacker initiates a communication with a
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 have managed to achieve an
amplified attack, since by sending a single packet containing all the amplified 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 all
the destinations. the destinations.
6. Hijacking attacks 6. Hijacking attacks
6.1. Hijacking attacks to the Basic MPTCP protocol 6.1. Hijacking attacks to the Basic MPTCP protocol
skipping to change at page 12, line 6 skipping to change at page 12, line 6
once IP1 is removed, all the data sent by Node 2 will reach the once IP1 is removed, all the data sent by Node 2 will reach the
Attacker and the incoming traffic has been hijacked. 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 by Node 2 as part of MPTCP connection. 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 source 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 a Man-in-the-Middle (MitM) attack. The scenario for the attack is
depicted in the figure below. depicted in the figure below.
skipping to change at page 13, line 27 skipping to change at page 13, line 27
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 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. We will next present some general taxonomy of
solutions and we describe the residual threats: solutions and we describe the residual threats:
o Cookie-based solution: As we described earlier, one possible o Cookie-based solution: As we described earlier, one possible
approach is to use a cookie, that is sent in clear text in every 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 MPTCP control message that adds a new address to the existing
connection. The residual threat in this type of solution is that connection. The residual threat in this type of solution is that
any attacker that can sniff any of these control messages will any attacker that can sniff any of these control messages will
learn the cookie and will be able to add new addresses at any 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 o Shared secret exchanged in plain text: An alternative option that
is somehow more secure than the cookie based approach is to is somehow more secure than the cookie based approach is to
exchange a key in clear text during the establishment of the first exchange a key in clear text during the establishment of the first
subflow and then validate the following subflows by using an keyed subflow and then validate the following subflows by using a keyed
HMAC signature using the shared key. This solution would be HMAC signature using the shared key. This solution would be
vulnerable to attackers sniffing the message exchange for the vulnerable to attackers sniffing the message exchange for the
establishment of the first subflow, but after that, the shared key establishment of the first subflow, but after that, the shared key
is not transmitted any more, so the attacker cannot learn it is not transmitted any more, so the attacker cannot learn it
through sniffing any other message. Unfortunately, in order to be through sniffing any other message. Unfortunately, in order to be
compatible with NATs (see analysis below) even though this compatible with NATs (see analysis below) even though this
approach includes a keyed HMAC signature, this signature cannot approach includes a keyed HMAC signature, this signature cannot
cover the IP address that is being added. This basically means cover the IP address that is being added. This basically means
that this type of approaches are also vulnerable to integrity that this type of approaches are also vulnerable to integrity
attacks of the exchanged messages. This means that even though attacks of the exchanged messages. This means that even though
skipping to change at page 16, line 4 skipping to change at page 16, line 4
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
Rolf Winter, Randall Stewart, Andrew McDonald, Michael Tuexen, Rolf Winter, Randall Stewart, Andrew McDonald, Michael Tuexen,
Michael Scharf, Tim Shepard, Yoshifumi Nishida reviewed an earlier Michael Scharf, Tim Shepard, Yoshifumi Nishida, Lars Eggert, Phil
version of this document and provided comments to improve it. Eardley reviewed an earlier 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. References 12. References
skipping to change at page 17, line 5 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.
[I-D.ietf-mptcp-multiaddressed]
Ford, A., Raiciu, C., and M. Handley, "TCP Extensions for
Multipath Operation with Multiple Addresses",
draft-ietf-mptcp-multiaddressed-02 (work in progress),
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
 End of changes. 19 change blocks. 
82 lines changed or deleted 90 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/