draft-ietf-mptcp-threat-07.txt   draft-ietf-mptcp-threat-08.txt 
Network Working Group M. Bagnulo Network Working Group M. Bagnulo
Internet-Draft UC3M Internet-Draft UC3M
Intended status: Informational January 11, 2011 Intended status: Informational January 26, 2011
Expires: July 15, 2011 Expires: July 30, 2011
Threat Analysis for TCP Extensions for Multi-path Operation with Threat Analysis for TCP Extensions for Multi-path Operation with
Multiple Addresses Multiple Addresses
draft-ietf-mptcp-threat-07 draft-ietf-mptcp-threat-08
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 endpoints of a given TCP connection can use multiple for 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. In particular, some level of multihoming and mobility scenarios. Some level of multihoming and mobility support can be
support can be achieved through these extensions. However, the achieved through these extensions. However, the support for multiple
support for multiple IP addresses per endpoint may have implications IP addresses per endpoint may have implications on the security of
on the security of the resulting MPTCP protocol. This note includes the resulting MPTCP protocol. This note includes a threat analysis
a threat analysis for MPTCP. 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 July 15, 2011. This Internet-Draft will expire on July 30, 2011.
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
skipping to change at page 2, line 24 skipping to change at page 2, line 24
2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Related work . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Related work . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Basic MPTCP. . . . . . . . . . . . . . . . . . . . . . . . . . 6 4. Basic MPTCP. . . . . . . . . . . . . . . . . . . . . . . . . . 6
5. Flooding attacks . . . . . . . . . . . . . . . . . . . . . . . 7 5. Flooding attacks . . . . . . . . . . . . . . . . . . . . . . . 7
6. Hijacking attacks . . . . . . . . . . . . . . . . . . . . . . 10 6. Hijacking attacks . . . . . . . . . . . . . . . . . . . . . . 10
6.1. Hijacking attacks to the Basic MPTCP protocol . . . . . . 10 6.1. Hijacking attacks to the Basic MPTCP protocol . . . . . . 10
6.2. Time-shifted hijacking attacks . . . . . . . . . . . . . . 12 6.2. Time-shifted hijacking attacks . . . . . . . . . . . . . . 12
6.3. NAT considerations . . . . . . . . . . . . . . . . . . . . 14 6.3. NAT considerations . . . . . . . . . . . . . . . . . . . . 14
7. Recommendation . . . . . . . . . . . . . . . . . . . . . . . . 15 7. Recommendation . . . . . . . . . . . . . . . . . . . . . . . . 15
8. Security Considerations . . . . . . . . . . . . . . . . . . . 15 8. Security Considerations . . . . . . . . . . . . . . . . . . . 15
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 15 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 16
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16
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 endpoints of a given TCP connection can use for 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. In particular, some level of multihoming and number of scenarios. Some level of multihoming and mobility support
mobility support can be achieved through these extensions. However, can be achieved through these extensions. However, the support for
the support for multiple IP addresses per endpoint may have multiple IP addresses per endpoint may have implications on the
implications on the security of the resulting MPTCP protocol. This security of the resulting MPTCP protocol. This note includes a
note includes a threat analysis for MPTCP. It should be noted that threat analysis for MPTCP. There are there may other ways to provide
there are there may other ways to provide multiple paths for a TCP multiple paths for a TCP connection other than the usage of multiple
connection other than the usage of multiple addresses. The threat addresses. The threat analysis performed in this document is limited
analysis performed in this document is limited to the specific case to the specific case of using multiple addresses per endpoint.
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 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. In this note, we will
focus on a particular approach, namely MPTCP, that rely on the usage focus on a particular approach, namely MPTCP, that rely on the usage
skipping to change at page 3, line 44 skipping to change at page 3, line 43
Multi-addressed flavour of Multi-path TCP Multi-addressed flavour of Multi-path TCP
[I-D.ietf-mptcp-multiaddressed]. [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 compared to single-path TCP. may result in additional vulnerabilities compared to single-path TCP.
The scope of this note is to identify and characterize these new The scope of this note is to identify and characterize these new
vulnerabilities. So, the scope of the analysis is limited to the vulnerabilities. So, the scope of the analysis is limited to the
additional vulnerabilities resulting from the multi-address support additional vulnerabilities resulting from the multi-address support
compared to the current TCP protocol (where each endpoint only has compared to the current TCP protocol (where each endpoint only has
one address available for use per connection). In other words, a one address available for use per connection). A full analysis of
full analysis of the complete set of threats is explicitly out of the the complete set of threats is explicitly out of the scope. The goal
scope. The goal of this analysis is to help the MPTCP protocol of this analysis is to help the MPTCP protocol designers create an
designers create an MPTCP specification that is as secure as the MPTCP specification that is as secure as the current TCP. It is a
current TCP. It is a non-goal of this analysis to help in the design non-goal of this analysis to help in the design of MPTCP that is more
of MPTCP that is more secure than regular TCP. secure than regular TCP.
In particular, we will focus on attackers that are not along the We will focus on attackers that are not along the path, at least not
path, at least not during the whole duration of the connection. In during the whole duration of the connection. In the current single
the current single path TCP, an on-path attacker can launch a path TCP, an on-path attacker can launch a significant number of
significant number of attacks, including eavesdropping, connection attacks, including eavesdropping, connection hijacking Man-in-the-
hijacking Man-in-the-Middle attacks and so on. However, it is not Middle attacks and so on. However, it is not possible for the off-
possible for the off-path attackers to launch such attacks. There is path attackers to launch such attacks. There is a middle ground in
a middle ground in case the attacker is located along the path for a case the attacker is located along the path for a short period of
short period of time to launch the attack and then moves away, but time to launch the attack and then moves away, but the attack effects
the attack effects still apply. These are the so-called time-shifted still apply. These are the so-called time-shifted attacks. Since
attacks. Since these are not possible in today's TCP, we will also these are not possible in today's TCP, we will also consider them as
consider them as part of the analysis. So, summarizing, we will part of the analysis. So, summarizing, we will consider both attacks
consider both attacks launched by off-path attackers and time-shifted launched by off-path attackers and time-shifted attacks. Attacks
attacks. Attacks launched by on-path attackers are out of scope, launched by on-path attackers are out of scope, since they also apply
since they also apply to current single-path TCP. to current single-path TCP.
It should be noted, however, that some current on-path attacks may However, that some current on-path attacks may become more difficult
become more difficult with multi-path TCP, since an attacker (on a with multi-path TCP, since an attacker (on a single path) will not
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. In this section we
present the most relevant ones and we relate them to the current present the most relevant ones and we relate them to the current
MPTCP 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 addresses is at stake. If a binding between two addresses is created at the
is created at the IP layer, this binding can and will affect all IP layer, this binding can and will affect all the connections
the connections that involve those addresses. However, in MPTCP, that involve those addresses. However, in MPTCP, if an additional
if an additional address is added to an ongoing TCP connection, address is added to an ongoing TCP connection, the additional
the additional address will/can only affect the connection at hand address will/can only affect the connection at hand and not other
and not other connections even if the same address is being used connections even if the same address is being used for those other
for those other connections. The result is that in MPTCP there is connections. The result is that in MPTCP there is much less at
much less at stake and the resulting vulnerabilities are less. On stake and the resulting vulnerabilities are less. On the other
the other hand, it is very important to keep the assumption valid hand, it is very important to keep the assumption valid that the
that the address bindings for a given connection do not affect address bindings for a given connection do not affect other
other connections. If reusing of binding or security information connections. If reusing of binding or security information is to
is to be considered, this assumption could be no longer valid and be considered, this assumption could be no longer valid and the
the full impact of the vulnerabilities must be assessed. full impact of the vulnerabilities must be assessed.
o In MIPv6 RO, there is the assumption that the original path o In MIPv6 there is a trusted third party, called the Home Agent
through which the connection has been established is always that can help with some security problems, as expanded in the next
available and in case it is not, the communication will be lost. bullet.
In MPTCP, it is an explicit goal to provide communication o In MIPv6 RO, there is the assumption that the original address
resilience when one of the address pairs is no longer usable, so (Home Address) through which the connection has been established
it is not possible to leverage on the original address pair to be is always available and in case it is not, the communication will
always working. be lost. This is achieved by leveraging in the on the trusted
party (the Home Agent) to rely the packets to the current location
of the Mobile Node. In MPTCP, it is an explicit goal to provide
communication resilience when one of the address pairs is no
longer usable, so it is not possible to leverage on the original
address pair to be always working.
o MIPv6 RO is of course designed for IPv6 and it is an explicit goal o MIPv6 RO is of course designed for IPv6 and it is an explicit goal
of MPTCP to support both IPv6 and IPv4. Some MIPv6 RO security of MPTCP to support both IPv6 and IPv4. Some MIPv6 RO security
solutions rely on the usage of some characteristics of IPv6 (such solutions rely on the usage of some characteristics of IPv6 (such
as the usage of CGAs [RFC3972]), which will not be usable in the as the usage of CGAs [RFC3972]), which will not be usable in the
context of MPTCP. context of MPTCP.
o As opposed to MPTCP, MIPv6 RO does not have a connection state o As opposed to MPTCP, MIPv6 RO does not have a connection state
information, including sequence numbers, port numbers that could information, including sequence numbers, port numbers that could
be leveraged to provide security in some form. be leveraged to provide security in some form.
In the Shim6 [RFC5533] design, similar issues related to address In the Shim6 [RFC5533] design, similar issues related to address
agility were considered and a threat analysis was also performed agility were considered and a threat analysis was also performed
[RFC4218]. The analysis performed for Shim6 also largely applies to [RFC4218]. The analysis performed for Shim6 also largely applies to
the MPTCP context, the main difference being: the MPTCP context, the main difference being:
o Similarly to the MPTCP case, the Shim6 protocol is a layer 3 o The Shim6 protocol is a layer 3 protocol so all the communications
protocol so all the communications involving the target address involving the target address are at stake; in MPTCP, the impact
are at stake, as opposed to the MPTCP case, where the impact can can be limited to a single TCP connection.
be limited to a single TCP connection.
o Similarly to MIPv6 RO, Shim6 only uses IPv6 addresses as o Similarly to MIPv6 RO, Shim6 only uses IPv6 addresses as
identifiers and leverages on some of their properties to provide identifiers and leverages on some of their properties to provide
the security, such as relying on CGAs or HBAs [RFC5535], which is the security, such as relying on CGAs or HBAs [RFC5535], which is
not possible in the MPTCP case where IPv4 addresses must be not possible in the MPTCP case where IPv4 addresses must be
supported. supported.
o Similarly to MIPv6 RO, Shim6 does not have a connection state o Similarly to MIPv6 RO, Shim6 does not have a connection state
information, including sequence numbers, port that could be information, including sequence numbers, port that could be
leveraged to provide security in some form. leveraged to provide security in some form.
SCTP [RFC4960]is a transport protocol that supports multiple SCTP [RFC4960]is a transport protocol that supports multiple
addresses per endpoint and as such, the security implications are addresses per endpoint and the security implications are very close
very close to the ones of MPTCP. A security analysis, identifying a to the ones of MPTCP. A security analysis, identifying a set of
set of attacks and proposed solutions was performed in [RFC5062]. attacks and proposed solutions was performed in [RFC5062]. The
The results of this analysis apply directly to the case of MPTCP. results of this analysis apply directly to the case of MPTCP.
However, the analysis was performed after the base SCTP protocol was However, the analysis was performed after the base SCTP protocol was
designed and the goal of the document was essentially to improve the designed and the goal of the document was essentially to improve the
security of SCTP. As such, the document is very specific to the security of SCTP. As such, the document is very specific to the
actual SCTP specification and relies on the SCTP messages and actual SCTP specification and relies on the SCTP messages and
behaviour to characterize the issues. While some them can be behaviour to characterize the issues. While some them can be
translated to the MPTCP case, some may be caused by specific translated to the MPTCP case, some may be caused by specific
behaviour of SCTP as defined. behaviour of SCTP.
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 is 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 The goal of this document is to serve as input for MPTCP protocol
for MPTCP protocol designers to properly take into account the designers to properly take into account the security issues. As
security issues. As such, the analysis cannot be performed for a such, the analysis cannot be performed for a specific MPTCP
specific MPTCP specification, but must be a general analysis that specification, but must be a general analysis that applies to the
applies to the widest possible set of MPTCP designs. In order to do widest possible set of MPTCP designs. We will characterize what are
that, we will characterize what are the fundamental features that any the fundamental features that any MPTCP protocol must provide and
MPTCP protocol must provide and attempt to perform the security attempt to perform the security implications only assuming those. In
implications only assuming those. In some cases, we will have a some cases, we will have a design choice that will significantly
design choice that will significantly influence the security aspects influence the security aspects of the resulting protocol. In that
of the resulting protocol. In that case we will consider both case we will consider both options and try to characterize both
options and try to characterize both designs. designs.
We assume that any MPTCP will behave in the case of a single address We assume that any MPTCP will behave in the case of a single address
per endpoint as TCP. This means that a MPTCP connection will be per endpoint as TCP. This means that a MPTCP connection will be
established by using the TCP 3-way handshake and will use a single established by using the TCP 3-way handshake and will use a single
address pair. 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. In particular, the address used as destination by the upper layers. The address used as destination address in the
address in the SYN packet is the address that the application is SYN packet is the address that the application is using to identify
using to identify the peer and has been obtained either through the the peer and has been obtained either through the DNS (with or
DNS (with or without DNSSEC validation) or passed by a referral or without DNSSEC validation) or passed by a referral or manually
manually introduced by the user. As such, the initiator does have a introduced by the user. As such, the initiator does have a certain
certain amount of trust in the fact that it is establishing a amount of trust in the fact that it is establishing a communication
communication with that particular address. If due to MPTCP, packets with that particular address. If due to MPTCP, packets end up being
end up being delivered to an alternative address, the trust that the delivered to an alternative address, the trust that the initiator has
initiator has placed on that address would be deceived. In any case, placed on that address would be deceived. In any case, the adoption
the adoption of MPTCP necessitates a slight evolution of the of MPTCP necessitates a slight evolution of the traditional TCP trust
traditional TCP trust model, in that the initiator is additionally model, in that the initiator is additionally trusting the peer to
trusting the peer to provide additional addresses which it will trust provide additional addresses which it will trust to the same degree
to the same degree as the original pair. An application or as the original pair. An application or implementation that cannot
implementation that cannot trust the peer in this way should not make trust the peer in this way should not make use of multiple paths.
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. We assume that a MPTCP connection
will use a single sequence number for the data, even if the data is will use a single sequence number for the data, even if the data is
exchanged through different paths, as MPTCP provides an in-order exchanged through different paths, as MPTCP provides an in-order
delivery service of bytes 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. In order to do that each to add addresses for each of the endpoints. This is achieved by each
end will need to send a control message containing the additional end sending a control message containing the additional address(es).
address(es). In order to associate the additional address to an In order to associate the additional address to an ongoing
ongoing connection, the connection needs to be identified. We assume connection, the connection needs to be identified. We assume that
that the connection can be identified by the 4-tuple of source the connection can be identified by the 4-tuple of source address,
address, source port, destination address, destination port used for source port, destination address, destination port used for the
the establishment of the connection. So, at least, the control establishment of the connection. So, at least, the control message
message that will convey the additional address information can also that will convey the additional address information can also contain
contain the 4-tuple in order to inform about what connection the the 4-tuple in order to inform about what connection the address
address belong to (if no other connection identifier is defined). belong to (if no other connection identifier is defined). There are
There are two different ways to convey address information: 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.
In particular, the implicit mode may benefit from forms of ingress The implicit mode may benefit from forms of ingress filtering
filtering security, which would reduce the possibility of an attacker security, which would reduce the possibility of an attacker to add
to add any arbitrary address to an ongoing connection. However, it any arbitrary address to an ongoing connection. However, ingress
should be noted that ingress filtering deployment is far from filtering deployment is far from universal, and it is unwise to rely
universal, and as such it is unwise to rely on it as a basis for the on it as a basis for the protection of MPTCP.
protection of MPTCP.
In addition, further consideration about the interaction between Further consideration about the interaction between ingress filtering
ingress filtering and implicit mode signaling is needed in the case and implicit mode signaling is needed in the case that we need to
that we need to remove an address that is no longer available from remove an address that is no longer available from the MPTCP
the MPTCP connection. In particular a host attached to a network connection. A host attached to a network that performs ingress
that performs ingress filtering and using implicit signaling would filtering and using implicit signaling would not be able to remove an
not be able to remove an address that is no longer available (either address that is no longer available (either because of a failure or
because of a failure or due to a mobility event) from an ongoing due to a mobility event) from an ongoing MPTCP connection.
MPTCP connection.
In addition, we will assume that MPTCP will use all the address pairs We will assume that MPTCP will use all the address pairs that it has
that it has available for sending packets and that it will distribute available for sending packets and that it will distribute the load
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 so called flooding (or bombing) attacks. The setup for this the flooding (or bombing) attacks. The setup for this attack is
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. In streaming server), called source S and that has IP address IPS.
addition, we have the target of the flooding attack, target T which Target T has an IP address IPT.
has an IP address IPT.
In the first step of this attack (depicted as step 1 in the figure), In step 1 of this attack, the attacker A establishes a MPTCP
the attacker A establishes a MPTCP connection with the source of the connection with the source of the traffic server S and starts
traffic server S and starts downloading a significant amount of downloading a significant amount of traffic. The initial connection
traffic. The initial connection only involves one IP address per only involves one IP address per endpoint, IPA and IPS. Once that
endpoint, namely IPA and IPS. Once that the download is on course, the download is on course, in the step 2 of the attack is that the
the second step of the attack (depicted as step 2 in the figure) is attacker A adds IPT as one of the available addresses for the
that the attacker A adds IPT as one of the available addresses for communication. How the additional address is added depends on the
the communication. How the additional address is added depends on MPTCP address management mode. In explicit address management, the
the MPTCP address management mode. In explicit address management, attacker A only needs to send a signaling packet conveying address
the attacker A only needs to send a signaling packet conveying IPT. In implicit mode, the attacker A would need to send a packet
address IPT. In implicit mode, the attacker A would need to send a 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 a packet. At this possible or not for the attacker to send such a packet. At this
stage, the MPTCP connection still has a single address for the Source stage, the MPTCP connection still has a single address for the Source
S i.e. IPS but has two addresses for the Attacker A, namely IPA and S i.e. IPS but has two addresses for the Attacker A, IPA and IPT.
IPT. The attacker now attempts to get the Source S to send the The attacker now attempts to get the Source S to send the traffic of
traffic of the ongoing download to the Target T IP address i.e. IPT. the ongoing download to the Target T IP address i.e. IPT. The
The attacker can do that by pretending that the path between IPA and attacker can do that by pretending that the path between IPA and IPT
IPT is congested but that the path between IPS and IPT is not. In is congested but that the path between IPS and IPT is not. In order
order to do that, it needs to send ACKs for the data that flows to do that, it needs to send ACKs for the data that flows through the
through the path between IPS and IPT and do not send ACKs for the path between IPS and IPT and do not send ACKs for the data that is
data that is sent to IPA. The actual details of this will depend on sent to IPA. The details of this will depend on how the data sent
how the data sent through the different paths is ACKed. One through the different paths is ACKed. One possibility is that ACKs
possibility is that ACKs for the data sent using a given address pair for the data sent using a given address pair should come in packets
should come in packets containing the same address pair. If so, the containing the same address pair. If so, the attacker would need to
attacker would need to send ACKs using packets containing IPT as the send ACKs using packets containing IPT as the source address to keep
source address to keep the attack flowing. This may be possible or the attack flowing. This may be possible or not depending on the
not depending on the deployment of ingress filtering and the location deployment of ingress filtering and the location of the attacker.
of the attacker. The attacker would also need to guess the sequence The attacker would also need to guess the sequence number of the data
number of the data being sent to the Target. Once the attacker being sent to the Target. Once the attacker manages to perform these
manages to perform these actions the attack is on place and the actions the attack is on place and the download will hit the target.
download will hit the target. It should be noted that in this type In this type of attacks, the Source S still thinks it is sending
of attacks, the Source S still thinks it is sending packets to the packets to the Attacker A while in reality it is sending the packet
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 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. Since the packets are likely to belong to a
to belong to a non existent TCP connection, the Target T will issue non existent TCP connection, the Target T will issue RST packets. It
RST packets. It is relevant then to understand how MPTCP reacts to is relevant then to understand how MPTCP reacts to incoming RST
incoming RST packets. It seems that the at least the MPTCP that packets. It seems that the at least the MPTCP that receives a RST
receives a RST packet should terminate the packet exchange packet should terminate the packet exchange corresponding to the
corresponding to the particular address pair (maybe not the complete particular address pair (maybe not the complete MPTCP connection, but
MPTCP connection, but at least it should not send more packets with at least it should not send more packets with the address pair
the address pair involved in the RST packet). However, if the involved in the RST packet). However, if the attacker, before
attacker, before redirecting the traffic has managed to increase the redirecting the traffic has managed to increase the window size
window size considerably, the flight size could be enough to impose a considerably, the flight size could be enough to impose a significant
significant amount of traffic to the Target node. There is a subtle amount of traffic to the Target node. There is a subtle operation
operation that the attacker needs to achieve in order to launch a that the attacker needs to achieve in order to launch a significant
significant attack. On the one hand it needs to grow the window attack. On the one hand it needs to grow the window enough so that
enough so that the flight size is big enough to cause enough effect the flight size is big enough to cause enough effect and on the other
and on the other hand the attacker needs to be able to simulate hand the attacker needs to be able to simulate congestion on the IPA-
congestion on the IPA-IPS path so that traffic is actually redirected IPS path so that traffic is actually redirected to the alternative
to the alternative path without significantly reducing the window. path without significantly reducing the window. This will heavily
This will heavily depend on how the coupling of the windows between depend on how the coupling of the windows between the different paths
the different paths works, in particular how the windows are works, in particular how the windows are increased. Some designs of
increased. Some designs of the congestion control window coupling the congestion control window coupling could render this attack
could render this attack ineffective. In particular, if the MPTCP ineffective. If the MPTCP protocol requires performing slow start
protocol requires performing slow start per subflow, then the per subflow, then the flooding will be limited by the slow-start
flooding will be limited 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. In other words, the before actually sending data to a new address. The solution used in
solution used in other protocols, would include the Source S to other protocols, would include the Source S to explicitly asking the
explicitly asking the host sitting in the new address (in this case host sitting in the new address (the Target T sitting in IPT) whether
the Target T sitting in IPT) whether it is willing to accept packets it is willing to accept packets from the MPTCP connection identified
from the MPTCP connection identified by the 4-tuple IPA, port A, IPS, by the 4-tuple IPA, port A, IPS, port S. Since this is not part of
port S. Since this is not part of the established connection that the established connection that Target T has, T would not accept the
Target T has, T would not accept the request and Source S would not request and Source S would not use IPT to send packets for this MPTCP
use IPT to send packets for this MPTCP connection. Usually, the connection. Usually, the request also includes a nonce that cannot
request also includes a nonce that cannot be guessed by the attacker be guessed by the attacker A so that it cannot fake the reply to the
A so that it cannot fake the reply to the request easily. In request easily. In the case of SCTP, it sends a message with a 64-
particular, In the case of SCTP, it sends a message with a 64-bit bit 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 communication with a with MPTCP is one where the attacker initiates a communication with a
skipping to change at page 10, line 48 skipping to change at page 10, line 44
+------+ /+------+ +------+ /+------+
/ /
/ /
/ /
v IPA v IPA
+--------+ +--------+
|Attacker| |Attacker|
| A | | A |
+--------+ +--------+
In this case, we have a MPTCP connection established between Node 1 We have a MPTCP connection established between Node 1 and Node 2.
and Node 2. The connection is using only one address per endpoint, The connection is using only one address per endpoint, IP1 and IP2.
namely IP1 and IP2. The attacker then launches the hijacking attack The attacker then launches the hijacking attack by adding IPA as an
by adding IPA as an additional address for Node 1. In this case, additional address for Node 1. There is not much difference between
there is not much difference between explicit or implicit address explicit or implicit address management, since in both cases the
management, since in both cases the Attacker A could easily send a Attacker A could easily send a control packet adding the address IPA,
control packet adding the address IPA, either as control data or as either as control data or as the source address of the control
the source address of the control packet. In order to be able to packet. In order to be able to hijack the connection, the attacker
hijack the connection, the attacker needs to know the 4-tuple that needs to know the 4-tuple that identifies the connection, including
identifies the connection, including the pair of addresses and the the pair of addresses and the pair of ports. It seems reasonable to
pair of ports. It seems reasonable to assume that knowing the source assume that knowing the source and destination IP addresses and the
and destination IP addresses and the port of the server side is port of the server side is fairly easy for the attacker. Learning
fairly easy for the attacker. Learning the port of the client (i.e. the port of the client (i.e. of the initiator of the connection) may
of the initiator of the connection) may prove to be more challenging. prove to be more challenging. The attacker would need to guess what
The attacker would need to guess what the port is or to learn it by the port is or to learn it by intercepting the packets. Assuming
intercepting the packets. Assuming that the attacker can gather the that the attacker can gather the 4-tuple and issue the message adding
4-tuple and issue the message adding IPA to the addresses available IPA to the addresses available for the MPTCP connection, then the
for the MPTCP connection, then the attacker A has been able to attacker A has been able to participate in the communication. In
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 multi-path
capabilities, we can assume that unless there are already many IP capabilities, we can assume that unless there are already many IP
address pairs in use in the MPTCP connection, Node 2 will start 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 per se, already has negative effects, since Node 1 will not This already has negative effects, since Node 1 will not receive
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 DoS attack, since the byte flow
will stop waiting for the missing data. However, it is not enough will stop waiting for the missing data. However, it is not enough
to achieve full hijacking of the connection, since part of data to achieve full hijacking of the connection, since part of data
will be still delivered to IP1, so it would reach Node 1 and not will be still delivered to IP1, so it would reach Node 1 and not
the Attacker. In order for the attacker to receive all the data the Attacker. In order for the attacker to receive all the data
of the MPTCP connection, the Attacker must somehow remove IP1 of of the MPTCP connection, the Attacker must somehow remove IP1 of
the set of available addresses for the connection. in the case of the set of available addresses for the connection. in the case of
implicit address management, this operation is likely to imply implicit address management, this operation is likely to imply
sending a termination packet with IP1 as source address, which may sending a termination packet with IP1 as source address, which may
or not be possible for the attacker depending on whether ingress or not be possible for the attacker depending on whether ingress
filtering is in place and the location of the attacker. If filtering is in place and the location of the attacker. If
explicit address management is used, then the attacker will send a explicit address management is used, then the attacker will send a
remove address control packet containing IP1. The result is that remove address control packet containing IP1. Once IP1 is
once IP1 is removed, all the data sent by Node 2 will reach the removed, all the data sent by Node 2 will reach the Attacker and
Attacker and the incoming traffic has been hijacked. 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 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
skipping to change at page 12, line 30 skipping to change at page 12, line 27
+------+ \ /+------+ +------+ \ /+------+
\ / \ /
\ / \ /
\ / \ /
v IPA v v IPA v
+--------+ +--------+
|Attacker| |Attacker|
| A | | A |
+--------+ +--------+
In this case, there is an established connection between Node 1 and There is an established connection between Node 1 and Node 2. The
Node 2. The Attacker A will use the MPTCP address agility Attacker A will use the MPTCP address agility capabilities to place
capabilities to place itself as a MitM. In order to do so, it will itself as a MitM. In order to do so, it will add IP address IPA as
add IP address IPA as an additional address for the MPTCP connection an additional address for the MPTCP connection on both Node 1 and
on both Node 1 and Node 2. This is essentially the same technique Node 2. This is essentially the same technique described earlier in
described earlier in this section, only that it is used against both this section, only that it is used against both nodes involved in the
nodes involved in the communication. The main difference is that in communication. The main difference is that in this case, the
this case, the attacker can simply sniff the content of the attacker can simply sniff the content of the communication that is
communication that is forwarded through it and in turn forward the forwarded through it and in turn forward the data to the peer of the
data to the peer of the communication. The result is that the communication. The result is that the attacker can place himself in
attacker can place himself in the middle of the communication and the middle of the communication and sniff part of the traffic
sniff part of the traffic unnoticed. Similar considerations about unnoticed. Similar considerations about how the attacker can manage
how the attacker can manage to get to see all the traffic by removing to get to see all the traffic by removing the genuine address of the
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 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
skipping to change at page 13, line 43 skipping to change at page 13, line 40
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 more secure than the cookie based approach is to exchange a key
exchange a key in clear text during the establishment of the first in clear text during the establishment of the first subflow and
subflow and then validate the following subflows by using a keyed then validate the following subflows by using a keyed HMAC
HMAC signature using the shared key. This solution would be signature using the shared key. This solution would be vulnerable
vulnerable to attackers sniffing the message exchange for the to attackers sniffing the message exchange for the establishment
establishment of the first subflow, but after that, the shared key of the first subflow, but after that, the shared key is not
is not transmitted any more, so the attacker cannot learn it transmitted any more, so the attacker cannot learn it through
through sniffing any other message. Unfortunately, in order to be 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 means that this
that this type of approaches are also vulnerable to integrity type of approaches are also vulnerable to integrity attacks of the
attacks of the exchanged messages. This means that even though exchanged messages. This means that even though the attacker
the attacker cannot learn the shared key by sniffing the cannot learn the shared key by sniffing the subsequent subflow
subsequent subflow establishment, the attacker can modify the establishment, the attacker can modify the subflow establishment
subflow establishment message and change the address that is being message and change the address that is being added. So, the
added. So, the vulnerability window for confidentially to the vulnerability window for confidentially to the shared key is
shared key is limited to the establishment of the first subflow, limited to the establishment of the first subflow, but the
but the vulnerability window for integrity attacks still includes vulnerability window for integrity attacks still includes all the
all the subflow establishment exchanges. These attacks are still subflow establishment exchanges. These attacks are still
undetectable by the endpoints. It should be noted that the SCTP undetectable by the endpoints. The SCTP security falls in this
security falls in this category. category.
o Strong crypto anchor exchange. Another approach that could be o Strong crypto anchor exchange. Another approach that could be
used would be to exchange some strong crypto anchor while the 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. In this case, subsequent subflows could be chain anchor. Subsequent subflows could be protected by using the
protected by using the crypto material associated to that anchor. crypto material associated to that anchor. An attacker in this
An attacker in this case would need to change the crypto material case would need to change the crypto material exchanged in the
exchanged in the connection establishment phase. As a result the connection establishment phase. As a result the vulnerability
vulnerability window for forging the crypto anchor is limited to window for forging the crypto anchor is limited to the initial
the initial connection establishment exchange. Similarly to the connection establishment exchange. Similarly to the previous
previous case, due to NAT traversal considerations, the case, due to NAT traversal considerations, the vulnerability
vulnerability window for integrity attacks include all the subflow window for integrity attacks include all the subflow establishment
establishment exchanges. As opposed to the previous one, because exchanges. Because the attacker needs to change the crypto
the attacker needs to change the crypto anchor, this approach are anchor, this approach are detectable by the endpoints, if they
detectable by the endpoints, if they communicate directly. communicate 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 are
an interesting device from a security perspective. In terms of MPTCP an interesting device from a security perspective. In terms of MPTCP
they essentially behave as a Man-in-the-Middle attacker. As we have they essentially behave as a Man-in-the-Middle attacker. MPTCP
described earlier, MPTCP security goal is to prevent from any security goal is to prevent from any attacker to insert their
attacker to insert their addresses as valid addresses for a given addresses as valid addresses for a given MPTCP connection. But that
MPTCP connection. But that is exactly what a NAT does, they modify is exactly what a NAT does, they modify the addresses. So, if MPTCP
the addresses. So, if MPTCP is to work through NATs, MPTCP must is to work through NATs, MPTCP must accept address rewritten by NATs
accept address rewritten by NATs as valid addresses for a given as valid addresses for a given session. The most direct corollary is
session. The most direct corollary is that the MPTCP messages that that the MPTCP messages that add addresses in the implicit mode (i.e.
add addresses in the implicit mode (i.e. the SYN of new subflows) the SYN of new subflows) cannot be protected against integrity
cannot be protected against integrity attacks, since they must allow attacks, since they must allow for NATs to change their addresses.
for NATs to change their addresses. This basically rules out any This rules out any solution that would rely on providing integrity
solution that would rely on providing integrity protection to prevent protection to prevent an attacker from changing the address used in a
an attacker from changing the address used in a subflow establishment subflow establishment exchange. This implies that alternative
exchange. This implies that alternative creative mechanisms are creative mechanisms are needed to protect from integrity attacks to
needed to protect from integrity attacks to the MPTCP signaling that the MPTCP signaling that adds new addresses to a connection. It is
adds new addresses to a connection. It is far from obvious how one far from obvious how one such creative approach could look like at
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 MPTCP option. Now the question is what address to include in
the MPTCP option that conveys address information. If the address
included is the address configured in the host interface and that
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
point in conveying it and even less in securing it. It would be
possible to envision the usage of NAT traversal techniques such as
STUN to learn the address and port that the NAT has assigned and
convey that information in a secure. While this is possible, it
relies on using NAT traversal 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. In
order to define a proper security solution, we need to assess the order to define a proper security solution, we need to assess the
tradeoff and make a recommendation. After evaluating the different tradeoff and make a recommendation. After evaluating the different
aspects in the MPTCP WG, our conclusion are 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
skipping to change at page 16, line 5 skipping to change at page 16, line 17
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, Lars Eggert, Phil Michael Scharf, Tim Shepard, Yoshifumi Nishida, Lars Eggert, Phil
Eardley reviewed an earlier version of this document and provided Eardley, Jari Arkko, David Harrington, Dan Romascanu, Alexey Melnikov
comments to improve it. 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
 End of changes. 35 change blocks. 
286 lines changed or deleted 297 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/