< draft-bagnulo-mptcp-attacks-00.txt   draft-bagnulo-mptcp-attacks-01.txt >
Network Working Group M. Bagnulo Network Working Group M. Bagnulo
Internet-Draft UC3M Internet-Draft UC3M
Intended status: Informational C. Paasch Intended status: Informational C. Paasch
Expires: January 15, 2014 UCLouvain Expires: April 4, 2014 UCLouvain
F. Gont F. Gont
SI6 Networks / UTN-FRH SI6 Networks / UTN-FRH
O. Bonaventure O. Bonaventure
UCLouvain UCLouvain
C. Raiciu C. Raiciu
UPB UPB
July 14, 2013 October 1, 2013
Analysis of MPTCP residual threats and possible fixes Analysis of MPTCP residual threats and possible fixes
draft-bagnulo-mptcp-attacks-00 draft-bagnulo-mptcp-attacks-01
Abstract Abstract
This documents performs an analysis of the residual threats for MPTCP This documents performs an analysis of the residual threats for MPTCP
and explores possible solutions to them. and explores possible solutions to them.
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 January 15, 2014. This Internet-Draft will expire on April 4, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. ADD_ADDR attack . . . . . . . . . . . . . . . . . . . . . . . 4 2. ADD_ADDR attack . . . . . . . . . . . . . . . . . . . . . . . 5
2.1. Possible security enhancements to prevent this attack . . 9 2.1. Possible security enhancements to prevent this attack . . 10
3. DoS attack on MP_JOIN . . . . . . . . . . . . . . . . . . . . 10 3. DoS attack on MP_JOIN . . . . . . . . . . . . . . . . . . . . 12
3.1. Possible security enhancements to prevent this attack . . 11 3.1. Possible security enhancements to prevent this attack . . 13
4. SYN flooding amplification . . . . . . . . . . . . . . . . . 11 4. SYN flooding amplification . . . . . . . . . . . . . . . . . . 14
4.1. Possible security enhancements to prevent this attack . . 12 4.1. Possible security enhancements to prevent this attack . . 14
5. Eavesdropper in the initial handshake . . . . . . . . . . . . 12 5. Eavesdropper in the initial handshake . . . . . . . . . . . . 15
5.1. Possible security enhancements to prevent this attack . . 13 5.1. Possible security enhancements to prevent this attack . . 15
6. Security considerations . . . . . . . . . . . . . . . . . . . 13 6. SYN/JOIN attack . . . . . . . . . . . . . . . . . . . . . . . 16
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 6.1. Possible security enhancements to prevent this attack . . 16
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 7. Reccomendation . . . . . . . . . . . . . . . . . . . . . . . . 17
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 8. Security considerations . . . . . . . . . . . . . . . . . . . 19
9.1. Normative References . . . . . . . . . . . . . . . . . . 13 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
9.2. Informative References . . . . . . . . . . . . . . . . . 14 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22
11.1. Normative References . . . . . . . . . . . . . . . . . . . 22
11.2. Informative References . . . . . . . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24
1. Introduction 1. Introduction
This document provides a complement to the threat analysis for This document provides a complement to the threat analysis for
Multipath TCP (MPTCP) [RFC6824] documented in RFC 6181 [RFC6181]. Multipath TCP (MPTCP) [RFC6824] documented in RFC 6181 [RFC6181].
RFC 6181 provided a threat analysis for the general solution space of RFC 6181 provided a threat analysis for the general solution space of
extending TCP to operate with multiple IP addresses per connection. extending TCP to operate with multiple IP addresses per connection.
Its main goal was to leverage previous experience acquired during the Its main goal was to leverage previous experience acquired during the
design of other multi-address protocols, notably SHIM6 [RFC5533], design of other multi-address protocols, notably SHIM6 [RFC5533],
SCTP [RFC4960] and MIPv6 [RFC3775] during the design of MPTCP. Thus, SCTP [RFC4960] and MIPv6 [RFC3775] during the design of MPTCP. Thus,
skipping to change at page 3, line 5 skipping to change at page 3, line 29
the specific mechanisms specified in RFC 6824. The motivation for the specific mechanisms specified in RFC 6824. The motivation for
this analysis is to identify possible security issues with MPTCP as this analysis is to identify possible security issues with MPTCP as
currently specified and propose security enhancements to address the currently specified and propose security enhancements to address the
identified security issues. identified security issues.
The goal of the security mechanisms defined in RFC 6824 were to make The goal of the security mechanisms defined in RFC 6824 were to make
MPTCP no worse than currently available single-path TCP. We believe MPTCP no worse than currently available single-path TCP. We believe
that this goal is still valid, so we will perform our analysis on the that this goal is still valid, so we will perform our analysis on the
same grounds. same grounds.
Types of attackers: for all attacks considered in this documents, we Types of attackers: for all attacks considered in this document, we
identify the type of attacker. We can classify the attackers based identify the type of attacker. We can classify the attackers based
on their location as follows: on their location as follows:
o Off-path attacker. This is an attacker that does not need to be o Off-path attacker. This is an attacker that does not need to be
located in any of the paths of the MPTCP session at any point in located in any of the paths of the MPTCP session at any point in
time during the lifetime of the MPTCP session. This means that time during the lifetime of the MPTCP session. This means that
the Off-path attacker cannot eavesdrop any of the packets of the the Off-path attacker cannot eavesdrop any of the packets of the
MPTCP session. MPTCP session.
o Partial time On-path attacker. This is an attacker that needs to o Partial time On-path attacker. This is an attacker that needs to
skipping to change at page 4, line 38 skipping to change at page 5, line 31
Consider the following scenario. Host A with address IPA has one Consider the following scenario. Host A with address IPA has one
MPTCP session with Host B with address IPB. The MPTCP subflow MPTCP session with Host B with address IPB. The MPTCP subflow
between IPA and IPB is using port PA on host A and port PB on host B. between IPA and IPB is using port PA on host A and port PB on host B.
The tokens for the MPTCP session are TA and TB for Host A and Host B The tokens for the MPTCP session are TA and TB for Host A and Host B
respectively. Host C is the attacker. It owns address IPC. The respectively. Host C is the attacker. It owns address IPC. The
attack is executed as follows: attack is executed as follows:
1. Host C sends a forged packet with source address IPA, destination 1. Host C sends a forged packet with source address IPA, destination
address IPB, source port PA and destination port PB. The packet address IPB, source port PA and destination port PB. The packet
has the ACK flag set. The TCP sequence number for the segment is has the ACK flag set. The TCP sequence number for the segment is
i and the ACK sequence number is j. We will assume all these are i and the ACK sequence number is j. We will assume all these are
valid, we discuss what the attacker needs to figure these ones valid, we discuss what the attacker needs to figure these ones
later on. The packet contains the ADD_ADDR option. The ADD_ADDR later on. The packet contains the ADD_ADDR option. The ADD_ADDR
option announces IPC as an alternative address for the option announces IPC as an alternative address for the
connection. It also contains an eight bit address identifier connection. It also contains an eight bit address identifier
which does not bring any strong security benefit. which does not bring any strong security benefit.
2. Host B receives the ADD_ADDR message and it replies by sending a 2. Host B receives the ADD_ADDR message and it replies by sending a
TCP SYN packet. (Note: the MPTCP specification states that the TCP SYN packet. (Note: the MPTCP specification states that the
host receiving the ADD_ADDR option may initiate a new subflow. host receiving the ADD_ADDR option may initiate a new subflow.
If the host is configured so that it does not initiate a new If the host is configured so that it does not initiate a new
skipping to change at page 5, line 14 skipping to change at page 6, line 7
destination address for the packet is IPC, the source port is PB' destination address for the packet is IPC, the source port is PB'
and the destination port is PA' (It is not required that PA=PA' and the destination port is PA' (It is not required that PA=PA'
nor that PB=PB'). The sequence number for this packet is the new nor that PB=PB'). The sequence number for this packet is the new
initial sequence number for this subflow. The ACK sequence initial sequence number for this subflow. The ACK sequence
number is not relevant as the ACK flag is not set. The packet number is not relevant as the ACK flag is not set. The packet
carries an MP_JOIN option and it carries the token TA. It also carries an MP_JOIN option and it carries the token TA. It also
carries a random nonce generated by Host B called RB. carries a random nonce generated by Host B called RB.
3. Host C receives the SYN+MP_JOIN packet from Host B, and it alters 3. Host C receives the SYN+MP_JOIN packet from Host B, and it alters
it in the following way. It changes the source address to IPC it in the following way. It changes the source address to IPC
and and the destination address to IPA. It sends the modified and the destination address to IPA. It sends the modified packet
packet to Host A, impersonating Host B. to Host A, impersonating Host B.
4. Host A receives the SYN+MP_JOIN message and it replies with a SYN 4. Host A receives the SYN+MP_JOIN message and it replies with a
/ACK+MP_JOIN message. The packet has source address IPA and SYN/ACK+MP_JOIN message. The packet has source address IPA and
destination address IPC, as well as all the other needed destination address IPC, as well as all the other needed
parameters. In particular, Host A computes a valid HMAC and parameters. In particular, Host A computes a valid HMAC and
places it in the MP_JOIN option. places it in the MP_JOIN option.
5. Host C receives the SYN/ACK+MP_JOIN message and it changes the 5. Host C receives the SYN/ACK+MP_JOIN message and it changes the
source address to IPC and the destination address to IPB. It source address to IPC and the destination address to IPB. It
sends the modified packet to IPB impersonating Host A. sends the modified packet to IPB impersonating Host A.
6. Host B receives the SYN/ACK+MP_JOIN message. Host B verifies the 6. Host B receives the SYN/ACK+MP_JOIN message. Host B verifies the
HMAC of the MP_JOIN option and confirms its validity. It replies HMAC of the MP_JOIN option and confirms its validity. It replies
skipping to change at page 5, line 42 skipping to change at page 6, line 35
computed by Host B. computed by Host B.
7. Host C receives the ACK+MP_JOIN message from B and it alters it 7. Host C receives the ACK+MP_JOIN message from B and it alters it
in the following way. It changes the source address to IPC and in the following way. It changes the source address to IPC and
the destination address to IPA. It sends the modified packet to the destination address to IPA. It sends the modified packet to
Host A impersonating Host B. Host A impersonating Host B.
8. Host A receives the ACK+MP_JOIN message and creates the new 8. Host A receives the ACK+MP_JOIN message and creates the new
subflow. subflow.
At this point the attacker has managed to place itself as a At this point the attacker has managed to place itself as a
MitM for one subflow for the existing MPTCP session. It MitM for one subflow for the existing MPTCP session. It
should be noted that there still exists the subflow between should be noted that there still exists the subflow between
address IPA and IPB that does not flow through the address IPA and IPB that does not flow through the attacker,
attacker, so the attacker has not completely intercepted so the attacker has not completely intercepted all the packets
all the packets in the communication (yet). If the in the communication (yet). If the attacker wishes to
attacker wishes to completely intercept the MPTCP session completely intercept the MPTCP session it can do the following
it can do the following additional step. additional step.
9. Host C sends two TCP RST messages. One TCP RST packet is sent to 9. Host C sends two TCP RST messages. One TCP RST packet is sent to
Host B, with source address IPA and destination address IPB and Host B, with source address IPA and destination address IPB and
source and destination ports PA and PB, respectively. The other source and destination ports PA and PB, respectively. The other
TCP RST message is sent to Host A, with source address IPB and TCP RST message is sent to Host A, with source address IPB and
destination address IPA and source and destination ports PB and destination address IPA and source and destination ports PB and
PA, respectively. Both RST messages must contain a valid PA, respectively. Both RST messages must contain a valid
sequence number. Note that figuring the sequence numbers to be sequence number. Note that figuring the sequence numbers to be
used here for subflow A is the same difficulty as being able to used here for subflow A is the same difficulty as being able to
send the initial ADD_ADDR option with valid Sequence number and send the initial ADD_ADDR option with valid Sequence number and
ACK value. If there are more subflows, then the attacker needs ACK value. If there are more subflows, then the attacker needs
to find the Sequence Number and ACK for each subflow. to find the Sequence Number and ACK for each subflow.
At this point the attacker has managed to fully hijack the At this point the attacker has managed to fully hijack the
MPTCP session. MPTCP session.
Information required by the attacker to perform the described attack: Information required by the attacker to perform the described attack:
In order to perform this attack the attacker needs to guess or know In order to perform this attack the attacker needs to guess or know
the following pieces of information: (The attacker need this the following pieces of information: (The attacker need this
information for one of the subflows belonging to the MPTCP session.) information for one of the subflows belonging to the MPTCP session.)
o the four-tuple {Client-side IP Address, Client-side Port, Server- o the four-tuple {Client-side IP Address, Client-side Port, Server-
side Address, Servcer-side Port} that identifies the target TCP side Address, Servcer-side Port} that identifies the target TCP
connection connection
o a valid sequence number for the subflow o a valid sequence number for the subflow
o a valid ACK sequence number for the subflow o a valid ACK sequence number for the subflow
o a valid address identifier for IPC o a valid address identifier for IPC
TCP connections are uniquely identified by the four-tuple {Source TCP connections are uniquely identified by the four-tuple {Source
Address, Source Port, Destination Address, Destination Port}. Thus, Address, Source Port, Destination Address, Destination Port}. Thus,
in order to attack a TCP connection, an attacker needs to know or be in order to attack a TCP connection, an attacker needs to know or be
able to guess each of the values in that four-tuple. Assuming the able to guess each of the values in that four-tuple. Assuming the
two peers of the target TCP connection are known, the Source Address two peers of the target TCP connection are known, the Source Address
and the Destination Address can be assumed to be known. and the Destination Address can be assumed to be known.
We note that in order to be able to successfully perform this We note that in order to be able to successfully perform this
attack, the attacker needs to be able to send packets with a attack, the attacker needs to be able to send packets with a
forged source address. This means that the attacker cannot be forged source address. This means that the attacker cannot be
located in a network where techniques like ingress filtering located in a network where techniques like ingress filtering
[RFC2827] or source address validation [I-D.ietf-savi-framework] [RFC2827] or source address validation [I-D.ietf-savi-framework]
are deployed. However, ingress filtering is not as widely are deployed. However, ingress filtering is not as widely
implemented as one would expect, and hence cannot be relied upon implemented as one would expect, and hence cannot be relied upon
as a mitigation for this kind of attack. as a mitigation for this kind of attack.
Assuming the attacker knows the application protocol for which the Assuming the attacker knows the application protocol for which the
TCP connection is being employed, the server-side port can also be TCP connection is being employed, the server-side port can also be
assumed to be known. Finally, the client-side port will generally assumed to be known. Finally, the client-side port will generally
not be known, and will need to be guessed by the attacker. The not be known, and will need to be guessed by the attacker. The
chances of an attacker guessing the client-side port will depend on chances of an attacker guessing the client-side port will depend on
the ephemeral port range employed by the client, and whether the the ephemeral port range employed by the client, and whether the
client implements port randomization [RFC6056]. client implements port randomization [RFC6056].
Assuming TCP sequence number randomization is in place (see e.g. Assuming TCP sequence number randomization is in place (see e.g.
[RFC6528]), an attacker would have to blindly guess a valid TCP [RFC6528]), an attacker would have to blindly guess a valid TCP
sequence number. That is, sequence number. That is,
RCV.NXT =< SEG.SEQ < RCV.NXT+RCV.WND or RCV.NXT =< RCV.NXT =< SEG.SEQ < RCV.NXT+RCV.WND or RCV.NXT =< SEG.SEQ+
SEG.SEQ+SEG.LEN-1 < RCV.NXT+RCV.WND SEG.LEN-1 < RCV.NXT+RCV.WND
As a result, the chances of an attacker to succeed will depend on the As a result, the chances of an attacker to succeed will depend on the
TCP receive window size at the target TCP peer. TCP receive window size at the target TCP peer.
We note that automatic TCP buffer tuning mechanisms have been We note that automatic TCP buffer tuning mechanisms have been
become common for popular TCP implementations, and hence very become common for popular TCP implementations, and hence very
large TCP window sizes of values up to 2 MB could end up being large TCP window sizes of values up to 2 MB could end up being
employed by such TCP implementations. employed by such TCP implementations.
According to [RFC0793], the Acknowledgement Number is considered According to [RFC0793], the Acknowledgement Number is considered
skipping to change at page 7, line 48 skipping to change at page 8, line 37
Finally, in order for the address identifier to be valid, the only Finally, in order for the address identifier to be valid, the only
requirement is that it needs to be different than the ones already requirement is that it needs to be different than the ones already
being used by Host A in that MPTCP session, so a random identifier is being used by Host A in that MPTCP session, so a random identifier is
likely to work. likely to work.
Given that a large number of factors affect the chances of an Given that a large number of factors affect the chances of an
attacker of successfully performing the aforementioned off-path attacker of successfully performing the aforementioned off-path
attacks, we provide two general expressions for the expected number attacks, we provide two general expressions for the expected number
of packets the attacker needs to send to succeed in the attack: one of packets the attacker needs to send to succeed in the attack: one
for MTCP implementations that support [RFC5961], and another for for MPTCP implementations that support [RFC5961], and another for
MPTCP implementations that do not. MPTCP implementations that do not.
Implementations that do not support RFC 5961 Implementations that do not support RFC 5961
Packets = (2^32/(RCV_WND)) * 2 * EPH_PORT_SIZE/2 * 1/MSS Packets = (2^32/(RCV_WND)) * 2 * EPH_PORT_SIZE/2 * 1/MSS
Where the new : Where the new :
Packets: Packets:
Maximum number of packets required to successfully perform an off- Maximum number of packets required to successfully perform an off-
path (blind) attack. path (blind) attack.
RCV_WND: RCV_WND:
TCP receive window size (RCV.WND) at the target node. TCP receive window size (RCV.WND) at the target node.
skipping to change at page 8, line 37 skipping to change at page 9, line 30
2^31) that should be employed to make sure the ACK number is 2^31) that should be employed to make sure the ACK number is
valid. valid.
The following table contains some sample results for the number of The following table contains some sample results for the number of
required packets, based on different values of RCV_WND and required packets, based on different values of RCV_WND and
EPH_PORT_SIZE for a MSS of 1500 bytes. EPH_PORT_SIZE for a MSS of 1500 bytes.
+-------------+---------+---------+--------+---------+ +-------------+---------+---------+--------+---------+
| Ports \ Win | 16 KB | 128 KB | 256 KB | 2048 KB | | Ports \ Win | 16 KB | 128 KB | 256 KB | 2048 KB |
+-------------+---------+---------+--------+---------+ +-------------+---------+---------+--------+---------+
| 4000 | 699050 | 87381 | 43690 | 5461 | | 4000 | 699050 | 87381 | 43690 | 5461 |
+-------------+---------+---------+--------+---------+ +-------------+---------+---------+--------+---------+
| 10000 | 1747626 | 218453 | 109226 | 13653 | | 10000 | 1747626 | 218453 | 109226 | 13653 |
+-------------+---------+---------+--------+---------+ +-------------+---------+---------+--------+---------+
| 50000 | 8738133 | 1092266 | 546133 | 68266 | | 50000 | 8738133 | 1092266 | 546133 | 68266 |
+-------------+---------+---------+--------+---------+ +-------------+---------+---------+--------+---------+
Table 1: Max. Number of Packets for Successful Attack Table 1: Max. Number of Packets for Successful Attack
Implementations that do not support RFC 5961 Implementations that do support RFC 5961
Packets = (2^32/(RCV_WND)) * (2^32/(SND_MAX_WND)) * EPH_PORT_SIZE/2 * Packets = (2^32/(RCV_WND)) * (2^32/(2 * SND_MAX_WND)) *
1/MSS EPH_PORT_SIZE/2 * 1/MSS
Where: Where:
Packets: Packets:
Maximum number of packets required to successfully perform an off- Maximum number of packets required to successfully perform an off-
path (blind) attack. path (blind) attack.
RCV_WND: RCV_WND:
TCP receive window size (RCV.WND) at the target MPTCP endpoint. TCP receive window size (RCV.WND) at the target MPTCP endpoint.
skipping to change at page 9, line 24 skipping to change at page 10, line 20
end-point (SND.MAX.WND). end-point (SND.MAX.WND).
EPH_PORT_SIZE: EPH_PORT_SIZE:
Number of ports comprising the ephemeral port range at the Number of ports comprising the ephemeral port range at the
"client" system. "client" system.
Notes: Notes:
The value "2^32" represents the size of the TCP sequence number The value "2^32" represents the size of the TCP sequence number
space. space.
The parameter "SND_MAX_WND" is specified in [RFC5961]. The parameter "SND_MAX_WND" is specified in [RFC5961].
The value "2*SND_MAX_WND" results from the expresion "SND.NXT -
SND.UNA - MAX.SND.WND", assuming that, for connections that
perform bulk data transfers, "SND.NXT - SND.UNA == MAX.SND.WND".
If an attacker targets a TCP endpoint that is not actively
transferring data, "2 * SND_MAX_WND" would become "SND_MAX_WND"
(and hence a successful attack would typically require more
packets).
The following table contains some sample results for the number of The following table contains some sample results for the number of
required packets, based on different values of RCV_WND, SND_MAX_WND, required packets, based on different values of RCV_WND, SND_MAX_WND,
and EPH_PORT_SIZE. For these implementations, only a limited number and EPH_PORT_SIZE. For these implementations, only a limited number
of sample results are provided, just as an indication of how of sample results are provided, just as an indication of how
[RFC5961] increases the difficulty of performing these attacks. [RFC5961] increases the difficulty of performing these attacks.
+-------------+-------------+------------+-----------+---------+ +-------------+-------------+-----------+-----------+---------+
| Ports \ Win | 16 KB | 128 KB | 256 KB | 2048 KB | | Ports \ Win | 16 KB | 128 KB | 256 KB | 2048 KB |
+-------------+-------------+------------+-----------+---------+ +-------------+-------------+-----------+-----------+---------+
| 4000 | 91625968967 | 1431655765 | 357913941 | 559240 | | 4000 | 45812984490 | 715827882 | 178956970 | 2796202 |
+-------------+-------------+------------+-----------+---------+ +-------------+-------------+-----------+-----------+---------+
Table 2: Max. NUmber of Packets for Successful Attack Table 2: Max. Number of Packets for Successful Attack
Note: Note:
In the aforementioned table, all values are computed with RCV_WND In the aforementioned table, all values are computed with RCV_WND
equal to SND_MAX_WND. equal to SND_MAX_WND.
2.1. Possible security enhancements to prevent this attack 2.1. Possible security enhancements to prevent this attack
1. To include the token of the connection in the ADD_ADDR option. 1. To include the token of the connection in the ADD_ADDR option.
This would make it harder for the attacker to launch the attack, This would make it harder for the attacker to launch the attack,
since he needs to either eavesdrop the token (so this can no since he needs to either eavesdrop the token (so this can no
skipping to change at page 10, line 16 skipping to change at page 11, line 19
2. To include the HMAC of the address contained in the ADD_ADDR 2. To include the HMAC of the address contained in the ADD_ADDR
option concatenated with the key of the receiver of the ADD-ADDR option concatenated with the key of the receiver of the ADD-ADDR
message. This makes it much more secure, since it requires the message. This makes it much more secure, since it requires the
attacker to have both keys (either by eavesdropping it in the attacker to have both keys (either by eavesdropping it in the
first exchange or by guessing it). Because this solution relies first exchange or by guessing it). Because this solution relies
on the key used in the MPTCP session, the protection of this on the key used in the MPTCP session, the protection of this
solution would increase if new key generation methods are defined solution would increase if new key generation methods are defined
for MPTCP (e.g. using SSL keys as has been proposed). for MPTCP (e.g. using SSL keys as has been proposed).
3. To include the destination address of the ADD_ADDR msg in the 3. To include the destination address of the ADD_ADDR message in the
HMAC. This would certainly make the attack harder (the attacker HMAC. This would certainly make the attack harder (the attacker
would need to know the key). It wouldn't allow hosts behind NATs would need to know the key). It wouldn't allow hosts behind NATs
to be reached by an address in the ADD_ADDR option, even with to be reached by an address in the ADD_ADDR option, even with
static NAT bindings (like a web server at home). Probably it static NAT bindings (like a web server at home). Probably it
would make sense to combine it option 2) (i.e. to have the HMAC would make sense to combine it with option 2) (i.e. to have the
of the address in the ADD_ADDR option and the destination address HMAC of the address in the ADD_ADDR option and the destination
of the packet. address of the packet).
4. To include the destination address of the SYN packet in the HMAC 4. To include the destination address of the SYN packet in the HMAC
of the MP_JOIN message. This has the same problems than option of the MP_JOIN message. This has the same problems than option
3) in the presence of NATs. 3) in the presence of NATs.
3. DoS attack on MP_JOIN 3. DoS attack on MP_JOIN
Summary of the attack: Summary of the attack:
Type of attack: MPTCP Denial-of-Service attack, preventing the Type of attack: MPTCP Denial-of-Service attack, preventing the
skipping to change at page 11, line 19 skipping to change at page 12, line 41
MPTCP-session is limited by a certain number, and it is MPTCP-session is limited by a certain number, and it is
implementation-dependent. The attacker can simply exhaust this limit implementation-dependent. The attacker can simply exhaust this limit
by sending multiple SYN+MP_JOINs with different 5-tuples. The by sending multiple SYN+MP_JOINs with different 5-tuples. The
(possibly forged) source address of the attack packets will typically (possibly forged) source address of the attack packets will typically
correspond to an address that is not in use, or else the SYN/ACK sent correspond to an address that is not in use, or else the SYN/ACK sent
by Host B would elicit a RST from the impersonated node, thus by Host B would elicit a RST from the impersonated node, thus
removing the corresponding state at Host B. Further discussion of removing the corresponding state at Host B. Further discussion of
traditional SYN-flod attacks and common mitigations can be found in traditional SYN-flod attacks and common mitigations can be found in
[RFC4987] [RFC4987]
This effectively prevents the host A from sending any more This effectively prevents the host A from sending any more SYN+
SYN+MP_JOINs to host B, as the number of acceptable half-open MP_JOINs to host B, as the number of acceptable half-open connections
connections per MPTCP-session on host B has been exhausted. per MPTCP-session on host B has been exhausted.
The attacker needs to know the token Tb in order to perform the The attacker needs to know the token Tb in order to perform the
described attack. This can be achieved if it is a partial on-time described attack. This can be achieved if it is a partial on-time
eavesdropper, observing the 3-way handshake of the establishment of eavesdropper, observing the 3-way handshake of the establishment of
an additional subflow between host A and host B. If the attacker is an additional subflow between host A and host B. If the attacker is
never on-path, it has to guess the 32-bit token. never on-path, it has to guess the 32-bit token.
Christoph: can you provide text about the birthday paradox and busy
servers?
3.1. Possible security enhancements to prevent this attack 3.1. Possible security enhancements to prevent this attack
The third packet of the 3-way handshake could be extended to contain The third packet of the 3-way handshake could be extended to contain
also the 32-bit token and the random nonce that has been sent in the also the 32-bit token and the random nonce that has been sent in the
SYN+MP_JOIN. Further, host B will have to generate its own random SYN+MP_JOIN. Further, host B will have to generate its own random
nonce in a reproducible fashion (e.g., a Hash of the 5-tuple + nonce in a reproducible fashion (e.g., a Hash of the 5-tuple +
initial sequence-number + local secret). This will allow host B to initial sequence-number + local secret). This will allow host B to
reply to a SYN+MP_JOIN without having to create state. Upon the reply to a SYN+MP_JOIN without having to create state. Upon the
reception of the third ACK, host B can then verify the correctness of reception of the third ACK, host B can then verify the correctness of
the HMAC and create the state. the HMAC and create the state.
skipping to change at page 13, line 28 skipping to change at page 16, line 5
3. Use of Cryptographically-Generated Addresses (CGAs) for MPTCP 3. Use of Cryptographically-Generated Addresses (CGAs) for MPTCP
security. CGAs [RFC3972] have been used in the past to secure security. CGAs [RFC3972] have been used in the past to secure
multi addressed protocols like SHIM6 [RFC5533]. multi addressed protocols like SHIM6 [RFC5533].
4. Use of TCPCrypt [I-D.bittau-tcp-crypt] 4. Use of TCPCrypt [I-D.bittau-tcp-crypt]
5. Use DNSSEC. DNSSEC has been proposed to secure the Mobile IP 5. Use DNSSEC. DNSSEC has been proposed to secure the Mobile IP
protocol [dnssec] protocol [dnssec]
6. Security considerations 6. SYN/JOIN attack
Summary of the attack
Type of attack: An attacker that can intercept the SYN/JOIN
message can alter the source address being added.
Type of attacker: a Partial-time On-path eavesdropper
Threat: Low
Description:
The attacker is present along the path when the SYN/JOIN exchange
takes place, and this allows the attacker to add any new address it
wants to by simply substituting the source address of the SYN/JOIN
packet for one it chooses. This vulnerability was readily identified
at the moment of the design of the MPTCP security solution and the
threat was considered acceptable.
6.1. Possible security enhancements to prevent this attack
It should be noted that this vulnerability is fundamental due to the
NAT support requirement. In other words, MPTCP MUST work through
NATS in order to be deployable in the current Internet. NAT behavior
is unfortunately indistinguishable from this attack. It is
impossible to secure the source address, since doing so would prevent
MPTCP to work though NATS. This basically implies that the solution
cannot rely on securing the address. A more promising approach would
be then to look into securing the payload exchanged, limiting the
impact that the attack would have in the communication (e.g.
TCPCrypt or similar).
7. Reccomendation
Current MPTCP specification [RFC6824] is experimental. There is an
ongoing effort to move it to Standards track. We believe that the
work on MPTCP security should follow two treads:
o The work on improving MPTCP security so that is enough to become a
Standard Track document.
o The work on analyzing possible additional security enhancements to
provide a more secure version of MPTCP.
We will expand on these two next.
MPTCP security for a Standard Track specification.
We believe that in order for MPTCP to progress to Standard Track, the
ADD-ADDR attack must be addressed. We believe that the solution that
should be adopted in order to deal with this attack is to include an
HMAC to the ADD ADDR message (with the address being added used as
input to the HMAC, as well as the key). This would make the ADD ADDR
message as secure as the JOIN message. In addition, this implies
that if we implement a more secure way to create the key used in the
MPTCP connection, it can be used to improve the security of both the
JOIN and the ADD ADDR message automatically (since both use the same
key in the HMAC).
We believe that this is enough for MPTCP to progress as a Standard
track document. This is so because the security level is similar to
single path TCP, as results from our previous analysis. Moreover,
the security level achieved with these changes is exactly the same as
other Standard Track documents. In particular, this would be the
same security level that SCPT with dynamic addresses as defined in
[RFC5061]. The Security Consideration section of RFC5061 (which is a
Standard Track document) reads:
The addition and or deletion of an IP address to an existing
association does provide an additional mechanism by which existing
associations can be hijacked. Therefore, this document requires
the use of the authentication mechanism defined in [RFC4895] to
limit the ability of an attacker to hijack an association.
Hijacking an association by using the addition and deletion of an
IP address is only possible for an attacker who is able to
intercept the initial two packets of the association setup when
the SCTP-AUTH extension is used without pre-shared keys. If such
a threat is considered a possibility, then the [RFC4895] extension
MUST be used with a preconfigured shared endpoint pair key to
mitigate this threat.
This is the same security level that would be achieved by MPTCP plus
the ADD ADDR security measure recommended.
Security enhancements for MPTCP
We also believe that is worthwhile exploring alternatives to secure
MPTCP. As we identified earlier, the problem is securing JOIN
messages is fundamentally incompatible with NAT support, so it is
likely that a solution to this problem involves the protection of the
data itself. Exploring the integration of MPTCP and approaches like
TCPCrypt seems a promising venue.
8. Security considerations
This whole document is about security considerations for MPTCP. This whole document is about security considerations for MPTCP.
7. IANA Considerations 9. IANA Considerations
There are no IANA considerations in this memo. There are no IANA considerations in this memo.
8. Acknowledgments 10. Acknowledgments
We would like to thank Mark Handley for his comments on the attacks We would like to thank Mark Handley for his comments on the attacks
and countermeasures discussed in this document. and countermeasures discussed in this document.
9. References 11. References
9.1. Normative References 11.1. Normative References
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC [RFC0793] Postel, J., "Transmission Control Protocol", STD 7,
793, September 1981. RFC 793, September 1981.
[RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)",
RFC 3972, March 2005. RFC 3972, March 2005.
[RFC5961] Ramaiah, A., Stewart, R., and M. Dalal, "Improving TCP's [RFC5961] Ramaiah, A., Stewart, R., and M. Dalal, "Improving TCP's
Robustness to Blind In-Window Attacks", RFC 5961, August Robustness to Blind In-Window Attacks", RFC 5961,
2010. August 2010.
[RFC6056] Larsen, M. and F. Gont, "Recommendations for Transport- [RFC6056] Larsen, M. and F. Gont, "Recommendations for Transport-
Protocol Port Randomization", BCP 156, RFC 6056, January Protocol Port Randomization", BCP 156, RFC 6056,
2011. January 2011.
[RFC6528] Gont, F. and S. Bellovin, "Defending against Sequence [RFC6528] Gont, F. and S. Bellovin, "Defending against Sequence
Number Attacks", RFC 6528, February 2012. Number Attacks", RFC 6528, February 2012.
9.2. Informative References [RFC5061] Stewart, R., Xie, Q., Tuexen, M., Maruyama, S., and M.
Kozuka, "Stream Control Transmission Protocol (SCTP)
Dynamic Address Reconfiguration", RFC 5061,
September 2007.
11.2. Informative References
[RFC6824] Ford, A., Raiciu, C., Handley, M., and O. Bonaventure, [RFC6824] Ford, A., Raiciu, C., Handley, M., and O. Bonaventure,
"TCP Extensions for Multipath Operation with Multiple "TCP Extensions for Multipath Operation with Multiple
Addresses", RFC 6824, January 2013. Addresses", RFC 6824, January 2013.
[RFC6181] Bagnulo, M., "Threat Analysis for TCP Extensions for [RFC6181] Bagnulo, M., "Threat Analysis for TCP Extensions for
Multipath Operation with Multiple Addresses", RFC 6181, Multipath Operation with Multiple Addresses", RFC 6181,
March 2011. March 2011.
[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", RFC [RFC4960] Stewart, R., "Stream Control Transmission Protocol",
4960, September 2007. RFC 4960, September 2007.
[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.
[RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering:
Defeating Denial of Service Attacks which employ IP Source Defeating Denial of Service Attacks which employ IP Source
Address Spoofing", BCP 38, RFC 2827, May 2000. Address Spoofing", BCP 38, RFC 2827, May 2000.
[I-D.ietf-savi-framework] [I-D.ietf-savi-framework]
Wu, J., Bi, J., Bagnulo, M., Baker, F., and C. Vogt, Wu, J., Bi, J., Bagnulo, M., Baker, F., and C. Vogt,
"Source Address Validation Improvement Framework", draft- "Source Address Validation Improvement Framework",
ietf-savi-framework-06 (work in progress), January 2012. draft-ietf-savi-framework-06 (work in progress),
January 2012.
[RFC4987] Eddy, W., "TCP SYN Flooding Attacks and Common [RFC4987] Eddy, W., "TCP SYN Flooding Attacks and Common
Mitigations", RFC 4987, August 2007. Mitigations", RFC 4987, August 2007.
[I-D.paasch-mptcp-ssl] [I-D.paasch-mptcp-ssl]
Paasch, C. and O. Bonaventure, "Securing the MultiPath TCP Paasch, C. and O. Bonaventure, "Securing the MultiPath TCP
handshake with external keys", draft-paasch-mptcp-ssl-00 handshake with external keys", draft-paasch-mptcp-ssl-00
(work in progress), October 2012. (work in progress), October 2012.
[I-D.bittau-tcp-crypt] [I-D.bittau-tcp-crypt]
skipping to change at page 15, line 15 skipping to change at page 23, line 31
D., and Q. Slack, "Cryptographic protection of TCP Streams D., and Q. Slack, "Cryptographic protection of TCP Streams
(tcpcrypt)", draft-bittau-tcp-crypt-03 (work in progress), (tcpcrypt)", draft-bittau-tcp-crypt-03 (work in progress),
September 2012. September 2012.
[hash-chains] [hash-chains]
Diez, J., Bagnulo, M., Valera, F., and I. Vidal, "Security Diez, J., Bagnulo, M., Valera, F., and I. Vidal, "Security
for multipath TCP: a constructive approach", International for multipath TCP: a constructive approach", International
Journal of Internet Protocol Technology 6, 2011. Journal of Internet Protocol Technology 6, 2011.
[dnssec] Kukec, A., Bagnulo, M., Ayaz, S., Bauer, C., and W. Eddy, [dnssec] Kukec, A., Bagnulo, M., Ayaz, S., Bauer, C., and W. Eddy,
"OAM-DNSSEC: Route Optimization for Aeronautical Mobility "OAM-DNSSEC: Route Optimization for Aeronautical Mobility
using DNSSEC", 4th ACM International Workshop on Mobility using DNSSEC", 4th ACM International Workshop on Mobility
in the Evolving Internet Architecture MobiArch 2009, 2009. in the Evolving Internet Architecture MobiArch 2009, 2009.
Authors' Addresses Authors' Addresses
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
 End of changes. 40 change blocks. 
80 lines changed or deleted 188 lines changed or added

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