draft-ietf-mptcp-rfc6824bis-17.txt   draft-ietf-mptcp-rfc6824bis-18.txt 
Internet Engineering Task Force A. Ford Internet Engineering Task Force A. Ford
Internet-Draft Pexip Internet-Draft Pexip
Obsoletes: 6824 (if approved) C. Raiciu Obsoletes: 6824 (if approved) C. Raiciu
Intended status: Standards Track U. Politechnica of Bucharest Intended status: Standards Track U. Politechnica of Bucharest
Expires: December 1, 2019 M. Handley Expires: December 10, 2019 M. Handley
U. College London U. College London
O. Bonaventure O. Bonaventure
U. catholique de Louvain U. catholique de Louvain
C. Paasch C. Paasch
Apple, Inc. Apple, Inc.
May 30, 2019 June 8, 2019
TCP Extensions for Multipath Operation with Multiple Addresses TCP Extensions for Multipath Operation with Multiple Addresses
draft-ietf-mptcp-rfc6824bis-17 draft-ietf-mptcp-rfc6824bis-18
Abstract Abstract
TCP/IP communication is currently restricted to a single path per TCP/IP communication is currently restricted to a single path per
connection, yet multiple paths often exist between peers. The connection, yet multiple paths often exist between peers. The
simultaneous use of these multiple paths for a TCP/IP session would simultaneous use of these multiple paths for a TCP/IP session would
improve resource usage within the network and, thus, improve user improve resource usage within the network and, thus, improve user
experience through higher throughput and improved resilience to experience through higher throughput and improved resilience to
network failure. network failure.
skipping to change at page 2, line 7 skipping to change at page 2, line 7
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 December 1, 2019. This Internet-Draft will expire on December 10, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 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 48 skipping to change at page 2, line 48
2.5. Requesting a Change in a Path's Priority . . . . . . . . 13 2.5. Requesting a Change in a Path's Priority . . . . . . . . 13
2.6. Closing an MPTCP Connection . . . . . . . . . . . . . . . 13 2.6. Closing an MPTCP Connection . . . . . . . . . . . . . . . 13
2.7. Notable Features . . . . . . . . . . . . . . . . . . . . 14 2.7. Notable Features . . . . . . . . . . . . . . . . . . . . 14
3. MPTCP Protocol . . . . . . . . . . . . . . . . . . . . . . . 15 3. MPTCP Protocol . . . . . . . . . . . . . . . . . . . . . . . 15
3.1. Connection Initiation . . . . . . . . . . . . . . . . . . 16 3.1. Connection Initiation . . . . . . . . . . . . . . . . . . 16
3.2. Starting a New Subflow . . . . . . . . . . . . . . . . . 23 3.2. Starting a New Subflow . . . . . . . . . . . . . . . . . 23
3.3. General MPTCP Operation . . . . . . . . . . . . . . . . . 28 3.3. General MPTCP Operation . . . . . . . . . . . . . . . . . 28
3.3.1. Data Sequence Mapping . . . . . . . . . . . . . . . . 30 3.3.1. Data Sequence Mapping . . . . . . . . . . . . . . . . 30
3.3.2. Data Acknowledgments . . . . . . . . . . . . . . . . 33 3.3.2. Data Acknowledgments . . . . . . . . . . . . . . . . 33
3.3.3. Closing a Connection . . . . . . . . . . . . . . . . 34 3.3.3. Closing a Connection . . . . . . . . . . . . . . . . 34
3.3.4. Receiver Considerations . . . . . . . . . . . . . . . 35 3.3.4. Receiver Considerations . . . . . . . . . . . . . . . 36
3.3.5. Sender Considerations . . . . . . . . . . . . . . . . 37 3.3.5. Sender Considerations . . . . . . . . . . . . . . . . 37
3.3.6. Reliability and Retransmissions . . . . . . . . . . . 37 3.3.6. Reliability and Retransmissions . . . . . . . . . . . 38
3.3.7. Congestion Control Considerations . . . . . . . . . . 39 3.3.7. Congestion Control Considerations . . . . . . . . . . 39
3.3.8. Subflow Policy . . . . . . . . . . . . . . . . . . . 39 3.3.8. Subflow Policy . . . . . . . . . . . . . . . . . . . 39
3.4. Address Knowledge Exchange (Path Management) . . . . . . 40 3.4. Address Knowledge Exchange (Path Management) . . . . . . 40
3.4.1. Address Advertisement . . . . . . . . . . . . . . . . 42 3.4.1. Address Advertisement . . . . . . . . . . . . . . . . 42
3.4.2. Remove Address . . . . . . . . . . . . . . . . . . . 45 3.4.2. Remove Address . . . . . . . . . . . . . . . . . . . 45
3.5. Fast Close . . . . . . . . . . . . . . . . . . . . . . . 46 3.5. Fast Close . . . . . . . . . . . . . . . . . . . . . . . 46
3.6. Subflow Reset . . . . . . . . . . . . . . . . . . . . . . 48 3.6. Subflow Reset . . . . . . . . . . . . . . . . . . . . . . 48
3.7. Fallback . . . . . . . . . . . . . . . . . . . . . . . . 49 3.7. Fallback . . . . . . . . . . . . . . . . . . . . . . . . 49
3.8. Error Handling . . . . . . . . . . . . . . . . . . . . . 53 3.8. Error Handling . . . . . . . . . . . . . . . . . . . . . 53
3.9. Heuristics . . . . . . . . . . . . . . . . . . . . . . . 53 3.9. Heuristics . . . . . . . . . . . . . . . . . . . . . . . 53
skipping to change at page 25, line 17 skipping to change at page 25, line 17
protection against blind state exhaustion attacks; therefore, there protection against blind state exhaustion attacks; therefore, there
is no need to provide mechanisms to allow a responder to operate is no need to provide mechanisms to allow a responder to operate
statelessly at the MP_JOIN stage. statelessly at the MP_JOIN stage.
An HMAC is sent by both hosts -- by the initiator (Host A) in the An HMAC is sent by both hosts -- by the initiator (Host A) in the
third packet (the ACK) and by the responder (Host B) in the second third packet (the ACK) and by the responder (Host B) in the second
packet (the SYN/ACK). Doing the HMAC exchange at this stage allows packet (the SYN/ACK). Doing the HMAC exchange at this stage allows
both hosts to have first exchanged random data (in the first two SYN both hosts to have first exchanged random data (in the first two SYN
packets) that is used as the "message". This specification defines packets) that is used as the "message". This specification defines
that HMAC as defined in [RFC2104] is used, along with the SHA-256 that HMAC as defined in [RFC2104] is used, along with the SHA-256
hash algorithm [RFC6234], thus generating a 160-bit / 20-octet HMAC. hash algorithm [RFC6234], and that the output is truncated to the
Due to option space limitations, the HMAC included in the SYN/ACK is leftmost 160 bits (20 octets). Due to option space limitations, the
truncated to the leftmost 64 bits, but this is acceptable since HMAC included in the SYN/ACK is truncated to the leftmost 64 bits,
random numbers are used; thus, an attacker only has one chance to but this is acceptable since random numbers are used; thus, an
guess the HMAC correctly (if the HMAC is incorrect, the TCP attacker only has one chance to correctly guess the HMAC that matches
connection is closed, so a new MP_JOIN negotiation with a new random the random number previously sent by the peer (if the HMAC is
number is required). incorrect, the TCP connection is closed, so a new MP_JOIN negotiation
with a new random number is required).
The initiator's authentication information is sent in its first ACK The initiator's authentication information is sent in its first ACK
(the third packet of the handshake), as shown in Figure 7. This data (the third packet of the handshake), as shown in Figure 7. This data
needs to be sent reliably, since it is the only time this HMAC is needs to be sent reliably, since it is the only time this HMAC is
sent; therefore, receipt of this packet MUST trigger a regular TCP sent; therefore, receipt of this packet MUST trigger a regular TCP
ACK in response, and the packet MUST be retransmitted if this ACK is ACK in response, and the packet MUST be retransmitted if this ACK is
not received. In other words, sending the ACK/MP_JOIN packet places not received. In other words, sending the ACK/MP_JOIN packet places
the subflow in the PRE_ESTABLISHED state, and it moves to the the subflow in the PRE_ESTABLISHED state, and it moves to the
ESTABLISHED state only on receipt of an ACK from the receiver. It is ESTABLISHED state only on receipt of an ACK from the receiver. It is
not permitted to send data while in the PRE_ESTABLISHED state. The not permitted to send data while in the PRE_ESTABLISHED state. The
skipping to change at page 26, line 26 skipping to change at page 26, line 26
Figure 6: Join Connection (MP_JOIN) Option (for Responding SYN/ACK) Figure 6: Join Connection (MP_JOIN) Option (for Responding SYN/ACK)
1 2 3 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+-------+-----------------------+ +---------------+---------------+-------+-----------------------+
| Kind | Length = 24 |Subtype| (reserved) | | Kind | Length = 24 |Subtype| (reserved) |
+---------------+---------------+-------+-----------------------+ +---------------+---------------+-------+-----------------------+
| | | |
| | | |
| Sender's HMAC (160 bits) | | Sender's Truncated HMAC (160 bits) |
| | | |
| | | |
+---------------------------------------------------------------+ +---------------------------------------------------------------+
Figure 7: Join Connection (MP_JOIN) Option (for Third ACK) Figure 7: Join Connection (MP_JOIN) Option (for Third ACK)
These various MPTCP options fit together to enable authenticated These various MPTCP options fit together to enable authenticated
subflow setup as illustrated in Figure 8. subflow setup as illustrated in Figure 8.
Host A Host B Host A Host B
skipping to change at page 27, line 48 skipping to change at page 27, line 48
If the token is accepted at Host B, but the HMAC returned to Host A If the token is accepted at Host B, but the HMAC returned to Host A
does not match the one expected, Host A MUST close the subflow with a does not match the one expected, Host A MUST close the subflow with a
TCP RST. In this, and all following cases of sending a RST in this TCP RST. In this, and all following cases of sending a RST in this
section, the sender SHOULD send a MP_TCPRST option (Section 3.6) on section, the sender SHOULD send a MP_TCPRST option (Section 3.6) on
this RST packet with the reason code for a "MPTCP specific error". this RST packet with the reason code for a "MPTCP specific error".
If Host B does not receive the expected HMAC, or the MP_JOIN option If Host B does not receive the expected HMAC, or the MP_JOIN option
is missing from the ACK, it MUST close the subflow with a TCP RST. is missing from the ACK, it MUST close the subflow with a TCP RST.
If the HMACs are verified as correct, then both hosts have If the HMACs are verified as correct, then both hosts have verified
authenticated each other as being the same peers as existed at the each other as being the same peers as existed at the start of the
start of the connection, and they have agreed of which connection connection, and they have agreed of which connection this subflow
this subflow will become a part. will become a part.
If the SYN/ACK as received at Host A does not have an MP_JOIN option, If the SYN/ACK as received at Host A does not have an MP_JOIN option,
Host A MUST close the subflow with a TCP RST. Host A MUST close the subflow with a TCP RST.
This covers all cases of the loss of an MP_JOIN. In more detail, if This covers all cases of the loss of an MP_JOIN. In more detail, if
MP_JOIN is stripped from the SYN on the path from A to B, and Host B MP_JOIN is stripped from the SYN on the path from A to B, and Host B
does not have a listener on the relevant port, it will respond with a does not have a listener on the relevant port, it will respond with a
RST in the normal way. If in response to a SYN with an MP_JOIN RST in the normal way. If in response to a SYN with an MP_JOIN
option, a SYN/ACK is received without the MP_JOIN option (either option, a SYN/ACK is received without the MP_JOIN option (either
since it was stripped on the return path, or it was stripped on the since it was stripped on the return path, or it was stripped on the
skipping to change at page 29, line 39 skipping to change at page 29, line 39
o m = Data sequence number is 8 octets (if not set, DSN is 4 octets) o m = Data sequence number is 8 octets (if not set, DSN is 4 octets)
The flags 'a' and 'm' only have meaning if the corresponding 'A' or The flags 'a' and 'm' only have meaning if the corresponding 'A' or
'M' flags are set; otherwise, they will be ignored. The maximum 'M' flags are set; otherwise, they will be ignored. The maximum
length of this option, with all flags set, is 28 octets. length of this option, with all flags set, is 28 octets.
The 'F' flag indicates "Data FIN". If present, this means that this The 'F' flag indicates "Data FIN". If present, this means that this
mapping covers the final data from the sender. This is the mapping covers the final data from the sender. This is the
connection-level equivalent to the FIN flag in single-path TCP. A connection-level equivalent to the FIN flag in single-path TCP. A
connection is not closed unless there has been a Data FIN exchange, connection is not closed unless there has been a Data FIN exchange, a
or an implementation-specific, connection-level timeout. The purpose MP_FASTCLOSE (Section 3.5) message, or an implementation-specific,
of the Data FIN and the interactions between this flag, the subflow- connection-level send timeout. The purpose of the Data FIN and the
level FIN flag, and the data sequence mapping are described in interactions between this flag, the subflow-level FIN flag, and the
Section 3.3.3. The remaining reserved bits MUST be set to zero by an data sequence mapping are described in Section 3.3.3. The remaining
implementation of this specification. reserved bits MUST be set to zero by an implementation of this
specification.
Note that the checksum is only present in this option if the use of Note that the checksum is only present in this option if the use of
MPTCP checksumming has been negotiated at the MP_CAPABLE handshake MPTCP checksumming has been negotiated at the MP_CAPABLE handshake
(see Section 3.1). The presence of the checksum can be inferred from (see Section 3.1). The presence of the checksum can be inferred from
the length of the option. If a checksum is present, but its use had the length of the option. If a checksum is present, but its use had
not been negotiated in the MP_CAPABLE handshake, the checksum field not been negotiated in the MP_CAPABLE handshake, the receiver MUST
MUST be ignored. If a checksum is not present when its use has been close the subflow with a RST as it not behaving as negotiated. If a
negotiated, the receiver MUST close the subflow with a RST as it is checksum is not present when its use has been negotiated, the
considered broken. This RST SHOULD be accompanied with a MP_TCPRST receiver MUST close the subflow with a RST as it is considered
option (Section 3.6) with the reason code for a "MPTCP specific broken. In both cases, this RST SHOULD be accompanied with a
error". MP_TCPRST option (Section 3.6) with the reason code for a "MPTCP
specific error".
3.3.1. Data Sequence Mapping 3.3.1. Data Sequence Mapping
The data stream as a whole can be reassembled through the use of the The data stream as a whole can be reassembled through the use of the
data sequence mapping components of the DSS option (Figure 9), which data sequence mapping components of the DSS option (Figure 9), which
define the mapping from the subflow sequence number to the data define the mapping from the subflow sequence number to the data
sequence number. This is used by the receiver to ensure in-order sequence number. This is used by the receiver to ensure in-order
delivery to the application layer. Meanwhile, the subflow-level delivery to the application layer. Meanwhile, the subflow-level
sequence numbers (i.e., the regular sequence numbers in the TCP sequence numbers (i.e., the regular sequence numbers in the TCP
header) have subflow-only relevance. It is expected (but not header) have subflow-only relevance. It is expected (but not
skipping to change at page 31, line 12 skipping to change at page 31, line 14
such as firewalls that undertake Initial Sequence Number (ISN) such as firewalls that undertake Initial Sequence Number (ISN)
randomization. randomization.
The data sequence mapping also contains a checksum of the data that The data sequence mapping also contains a checksum of the data that
this mapping covers, if use of checksums has been negotiated at the this mapping covers, if use of checksums has been negotiated at the
MP_CAPABLE exchange. Checksums are used to detect if the payload has MP_CAPABLE exchange. Checksums are used to detect if the payload has
been adjusted in any way by a non-MPTCP-aware middlebox. If this been adjusted in any way by a non-MPTCP-aware middlebox. If this
checksum fails, it will trigger a failure of the subflow, or a checksum fails, it will trigger a failure of the subflow, or a
fallback to regular TCP, as documented in Section 3.7, since MPTCP fallback to regular TCP, as documented in Section 3.7, since MPTCP
can no longer reliably know the subflow sequence space at the can no longer reliably know the subflow sequence space at the
receiver to build data sequence mappings. receiver to build data sequence mappings. Without checksumming
enabled, corrupt data may be delivered to the application if a
middlebox alters segment boundaries, alters content, or does not
deliver all segments covered by a data sequence mapping. It is
therefore RECOMMENDED to use checksumming unless it is known the
network path contains no such devices.
The checksum algorithm used is the standard TCP checksum [RFC0793], The checksum algorithm used is the standard TCP checksum [RFC0793],
operating over the data covered by this mapping, along with a pseudo- operating over the data covered by this mapping, along with a pseudo-
header as shown in Figure 10. header as shown in Figure 10.
1 2 3 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+--------------------------------------------------------------+ +--------------------------------------------------------------+
| | | |
| Data Sequence Number (8 octets) | | Data Sequence Number (8 octets) |
skipping to change at page 44, line 25 skipping to change at page 44, line 25
| +-------------------------------+ | +-------------------------------+
| | | |
+-------------------------------+ +-------------------------------+
Figure 12: Add Address (ADD_ADDR) Option Figure 12: Add Address (ADD_ADDR) Option
Due to the proliferation of NATs, it is reasonably likely that one Due to the proliferation of NATs, it is reasonably likely that one
host may attempt to advertise private addresses [RFC1918]. It is not host may attempt to advertise private addresses [RFC1918]. It is not
desirable to prohibit this, since there may be cases where both hosts desirable to prohibit this, since there may be cases where both hosts
have additional interfaces on the same private network, and a host have additional interfaces on the same private network, and a host
MAY want to advertise such addresses. The MP_JOIN handshake to MAY advertise such addresses. The MP_JOIN handshake to create a new
create a new subflow (Section 3.2) provides mechanisms to minimize subflow (Section 3.2) provides mechanisms to minimize security risks.
security risks. The MP_JOIN message contains a 32-bit token that The MP_JOIN message contains a 32-bit token that uniquely identifies
uniquely identifies the connection to the receiving host. If the the connection to the receiving host. If the token is unknown, the
token is unknown, the host will return with a RST. In the unlikely host will return with a RST. In the unlikely event that the token is
event that the token is valid at the receiving host, subflow setup valid at the receiving host, subflow setup will continue, but the
will continue, but the HMAC exchange must occur for authentication. HMAC exchange must occur for authentication. This will fail, and
This will fail, and will provide sufficient protection against two will provide sufficient protection against two unconnected hosts
unconnected hosts accidentally setting up a new subflow upon the accidentally setting up a new subflow upon the signal of a private
signal of a private address. Further security considerations around address. Further security considerations around the issue of
the issue of ADD_ADDR messages that accidentally misdirect, or ADD_ADDR messages that accidentally misdirect, or maliciously direct,
maliciously direct, new MP_JOIN attempts are discussed in Section 5. new MP_JOIN attempts are discussed in Section 5.
A host that receives an ADD_ADDR but finds a connection set up to A host that receives an ADD_ADDR but finds a connection set up to
that IP address and port number is unsuccessful SHOULD NOT perform that IP address and port number is unsuccessful SHOULD NOT perform
further connection attempts to this address/port combination for this further connection attempts to this address/port combination for this
connection. A sender that wants to trigger a new incoming connection connection. A sender that wants to trigger a new incoming connection
attempt on a previously advertised address/port combination can attempt on a previously advertised address/port combination can
therefore refresh ADD_ADDR information by sending the option again. therefore refresh ADD_ADDR information by sending the option again.
A host can therefore send an ADD_ADDR message with an already A host can therefore send an ADD_ADDR message with an already
assigned Address ID, but the Address MUST be the same as previously assigned Address ID, but the Address MUST be the same as previously
skipping to change at page 58, line 23 skipping to change at page 58, line 23
hash of this key as the connection identification "token". The keys hash of this key as the connection identification "token". The keys
are concatenated and used as keys for creating Hash-based Message are concatenated and used as keys for creating Hash-based Message
Authentication Codes (HMACs) used on subflow setup, in order to Authentication Codes (HMACs) used on subflow setup, in order to
verify that the parties in the handshake are the same as in the verify that the parties in the handshake are the same as in the
original connection setup. It also provides verification that the original connection setup. It also provides verification that the
peer can receive traffic at this new address. Replay attacks would peer can receive traffic at this new address. Replay attacks would
still be possible when only keys are used; therefore, the handshakes still be possible when only keys are used; therefore, the handshakes
use single-use random numbers (nonces) at both ends -- this ensures use single-use random numbers (nonces) at both ends -- this ensures
the HMAC will never be the same on two handshakes. Guidance on the HMAC will never be the same on two handshakes. Guidance on
generating random numbers suitable for use as keys is given in generating random numbers suitable for use as keys is given in
[RFC4086] and discussed in Section 3.1. HMAC is also used to secure [RFC4086] and discussed in Section 3.1. The nonces are valid for the
lifetime of the TCP connection attempt. HMAC is also used to secure
the ADD_ADDR option, due to the threats identified in [RFC7430]. the ADD_ADDR option, due to the threats identified in [RFC7430].
The use of crypto capability bits in the initial connection handshake The use of crypto capability bits in the initial connection handshake
to negotiate use of a particular algorithm allows the deployment of to negotiate use of a particular algorithm allows the deployment of
additional crypto mechanisms in the future. Note that this additional crypto mechanisms in the future. This negotiation would
negotiation would be susceptible to a bid-down attack by an on-path nevertheless be susceptible to a bid-down attack by an on-path active
active attacker who could modify the crypto capability bits response attacker who could modify the crypto capability bits in the response
from the receiver to use a less secure crypto mechanism. The from the receiver to use a less secure crypto mechanism. The
security mechanism presented in this document should therefore security mechanism presented in this document should therefore
protect against all forms of flooding and hijacking attacks discussed protect against all forms of flooding and hijacking attacks discussed
in [RFC6181]. in [RFC6181].
The version negotiation specified in Section 3.1, if differing MPTCP The version negotiation specified in Section 3.1, if differing MPTCP
versions shared a common negotiation format, would allow an on-path versions shared a common negotiation format, would allow an on-path
attacker to apply a theoretical bid-down attack. Since the v1 and v0 attacker to apply a theoretical bid-down attack. Since the v1 and v0
protocols have a different handshake, such an attack would require protocols have a different handshake, such an attack would require
the client to re-establish the connection using v0, and this being the client to re-establish the connection using v0, and this being
skipping to change at page 59, line 32 skipping to change at page 59, line 33
ADD_ADDR injection into the stream. ADD_ADDR injection into the stream.
A small security risk could theoretically exist with key reuse, but A small security risk could theoretically exist with key reuse, but
in order to accomplish a replay attack, both the sender and receiver in order to accomplish a replay attack, both the sender and receiver
keys, and the sender and receiver random numbers, in the MP_JOIN keys, and the sender and receiver random numbers, in the MP_JOIN
handshake (Section 3.2) would have to match. handshake (Section 3.2) would have to match.
Whilst this specification defines a "medium" security solution, Whilst this specification defines a "medium" security solution,
meeting the criteria specified at the start of this section and the meeting the criteria specified at the start of this section and the
threat analysis ([RFC6181]), since attacks only ever get worse, it is threat analysis ([RFC6181]), since attacks only ever get worse, it is
likely that a future Standards Track version of MPTCP would need to likely that a future version of MPTCP would need to be able to
be able to support stronger security. There are several ways the support stronger security. There are several ways the security of
security of MPTCP could potentially be improved; some of these would MPTCP could potentially be improved; some of these would be
be compatible with MPTCP as defined in this document, whilst others compatible with MPTCP as defined in this document, whilst others may
may not be. For now, the best approach is to get experience with the not be. For now, the best approach is to get experience with the
current approach, establish what might work, and check that the current approach, establish what might work, and check that the
threat analysis is still accurate. threat analysis is still accurate.
Possible ways of improving MPTCP security could include: Possible ways of improving MPTCP security could include:
o defining a new MPCTP cryptographic algorithm, as negotiated in o defining a new MPCTP cryptographic algorithm, as negotiated in
MP_CAPABLE. A sub-case could be to include an additional MP_CAPABLE. A sub-case could be to include an additional
deployment assumption, such as stateful servers, in order to allow deployment assumption, such as stateful servers, in order to allow
a more powerful algorithm to be used. a more powerful algorithm to be used.
skipping to change at page 63, line 50 skipping to change at page 63, line 51
The authors gratefully acknowledge significant input into this The authors gratefully acknowledge significant input into this
document from Sebastien Barre and Andrew McDonald. document from Sebastien Barre and Andrew McDonald.
The authors also wish to acknowledge reviews and contributions from The authors also wish to acknowledge reviews and contributions from
Iljitsch van Beijnum, Lars Eggert, Marcelo Bagnulo, Robert Hancock, Iljitsch van Beijnum, Lars Eggert, Marcelo Bagnulo, Robert Hancock,
Pasi Sarolahti, Toby Moncaster, Philip Eardley, Sergio Lembo, Pasi Sarolahti, Toby Moncaster, Philip Eardley, Sergio Lembo,
Lawrence Conroy, Yoshifumi Nishida, Bob Briscoe, Stein Gjessing, Lawrence Conroy, Yoshifumi Nishida, Bob Briscoe, Stein Gjessing,
Andrew McGregor, Georg Hampel, Anumita Biswas, Wes Eddy, Alexey Andrew McGregor, Georg Hampel, Anumita Biswas, Wes Eddy, Alexey
Melnikov, Francis Dupont, Adrian Farrel, Barry Leiba, Robert Sparks, Melnikov, Francis Dupont, Adrian Farrel, Barry Leiba, Robert Sparks,
Sean Turner, Stephen Farrell, Martin Stiemerling, Gregory Detal, Sean Turner, Stephen Farrell, Martin Stiemerling, Gregory Detal,
Fabien Duchene, Xavier de Foy, Rahul Jadhav, and Klemens Schragel. Fabien Duchene, Xavier de Foy, Rahul Jadhav, Klemens Schragel, Mirja
Kuehlewind, Sheng Jiang, Alissa Cooper, Ines Robles, Roman Danyliw,
Adam Roach, Barry Leiba, Alexey Melnikov, Eric Vyncke, and Ben Kaduk.
8. IANA Considerations 8. IANA Considerations
This document obsoletes RFC6824 and as such IANA is requested to This document obsoletes RFC6824 and as such IANA is requested to
update the TCP option space registry to point to this document for update the TCP option space registry to point to this document for
Multipath TCP, as follows: Multipath TCP, as follows:
+------+--------+-----------------------+---------------+ +------+--------+-----------------------+---------------+
| Kind | Length | Meaning | Reference | | Kind | Length | Meaning | Reference |
+------+--------+-----------------------+---------------+ +------+--------+-----------------------+---------------+
skipping to change at page 74, line 11 skipping to change at page 74, line 11
space is checksummed. We also note that this does not entail a loss space is checksummed. We also note that this does not entail a loss
of functionality, because TFO-data is always only sent on the initial of functionality, because TFO-data is always only sent on the initial
subflow before any attempt to create additional subflows. subflow before any attempt to create additional subflows.
B.3. Connection establishment examples B.3. Connection establishment examples
The following shows a few examples of possible TFO+MPTCP The following shows a few examples of possible TFO+MPTCP
establishment scenarios. establishment scenarios.
Before an initiator can send data together with the SYN, it must Before an initiator can send data together with the SYN, it must
request a cookie to the listener, as shown in Figure Figure 18. This request a cookie to the listener, as shown in Figure 18. This is
is done by simply combining the TFO and MPTCP options. done by simply combining the TFO and MPTCP options.
initiator listener initiator listener
| | | |
| S Seq=0(Length=0) <MP_CAPABLE>, <TFO cookie request> | | S Seq=0(Length=0) <MP_CAPABLE>, <TFO cookie request> |
| -----------------------------------------------------------> | | -----------------------------------------------------------> |
| | | |
| S. 0(0) ack 1 <MP_CAPABLE>, <TFO cookie> | | S. 0(0) ack 1 <MP_CAPABLE>, <TFO cookie> |
| <----------------------------------------------------------- | | <----------------------------------------------------------- |
| | | |
| . 0(0) ack 1 <MP_CAPABLE> | | . 0(0) ack 1 <MP_CAPABLE> |
| -----------------------------------------------------------> | | -----------------------------------------------------------> |
| | | |
Figure 18: Cookie request - sequence number and length are annotated Figure 18: Cookie request - sequence number and length are annotated
as Seq(Length) and used hereafter in the figures. as Seq(Length) and used hereafter in the figures.
Once this is done, the received cookie can be used for TFO, as shown Once this is done, the received cookie can be used for TFO, as shown
in Figure Figure 19. In this example, the initiator first sends 20 in Figure 19. In this example, the initiator first sends 20 bytes in
bytes in the SYN. The listener immediately replies with 100 bytes the SYN. The listener immediately replies with 100 bytes following
following the SYN-ACK upon which the initiator replies with 20 more the SYN-ACK upon which the initiator replies with 20 more bytes.
bytes. Note that the last segment in the figure has a TCP sequence Note that the last segment in the figure has a TCP sequence number of
number of 21, while the DSS subflow sequence number is 1 (because the 21, while the DSS subflow sequence number is 1 (because the TFO data
TFO data is not part of the data sequence number space, as explained is not part of the data sequence number space, as explained in
in Section Appendix B.2. Section Appendix B.2.
initiator listener initiator listener
| | | |
| S 0(20) <MP_CAPABLE>, <TFO cookie> | | S 0(20) <MP_CAPABLE>, <TFO cookie> |
| -----------------------------------------------------------> | | -----------------------------------------------------------> |
| | | |
| S. 0(0) ack 21 <MP_CAPABLE> | | S. 0(0) ack 21 <MP_CAPABLE> |
| <----------------------------------------------------------- | | <----------------------------------------------------------- |
| | | |
| . 1(100) ack 21 <DSS ack=1 seq=1 ssn=1 dlen=100> | | . 1(100) ack 21 <DSS ack=1 seq=1 ssn=1 dlen=100> |
skipping to change at page 75, line 25 skipping to change at page 75, line 25
| | | |
| . 21(0) ack 1 <MP_CAPABLE> | | . 21(0) ack 1 <MP_CAPABLE> |
| -----------------------------------------------------------> | | -----------------------------------------------------------> |
| | | |
| . 21(20) ack 101 <DSS ack=101 seq=1 ssn=1 dlen=20> | | . 21(20) ack 101 <DSS ack=101 seq=1 ssn=1 dlen=20> |
| -----------------------------------------------------------> | | -----------------------------------------------------------> |
| | | |
Figure 19: The listener supports TFO Figure 19: The listener supports TFO
In Figure Figure 20, the listener does not support TFO. The In Figure 20, the listener does not support TFO. The initiator
initiator detects that no state is created in the listener (as no detects that no state is created in the listener (as no data is
data is acked), and now sends the MP_CAPABLE in the third ack, in acked), and now sends the MP_CAPABLE in the third ack, in order for
order for the listener to build its MPTCP context at then end of the the listener to build its MPTCP context at then end of the
establishment. Now, the tfo data, retransmitted, becomes part of the establishment. Now, the tfo data, retransmitted, becomes part of the
data sequence mapping because it is effectively sent (in fact re- data sequence mapping because it is effectively sent (in fact re-
sent) after the establishment. sent) after the establishment.
initiator listener initiator listener
| | | |
| S 0(20) <MP_CAPABLE>, <TFO cookie> | | S 0(20) <MP_CAPABLE>, <TFO cookie> |
| -----------------------------------------------------------> | | -----------------------------------------------------------> |
| | | |
| S. 0(0) ack 1 <MP_CAPABLE> | | S. 0(0) ack 1 <MP_CAPABLE> |
skipping to change at page 76, line 6 skipping to change at page 76, line 6
| . 1(20) ack 1 <DSS ack=1 seq=1 ssn=1 dlen=20> | | . 1(20) ack 1 <DSS ack=1 seq=1 ssn=1 dlen=20> |
| -----------------------------------------------------------> | | -----------------------------------------------------------> |
| | | |
| . 0(0) ack 21 <DSS ack=21 seq=1 ssn=1 dlen=0> | | . 0(0) ack 21 <DSS ack=21 seq=1 ssn=1 dlen=0> |
| <----------------------------------------------------------- | | <----------------------------------------------------------- |
| | | |
Figure 20: The listener does not support TFO Figure 20: The listener does not support TFO
It is also possible that the listener acknowledges only part of the It is also possible that the listener acknowledges only part of the
TFO data, as illustrated in Figure Figure 21. The initiator will TFO data, as illustrated in Figure 21. The initiator will simply
simply retransmit the missing data together with a DSS-mapping. retransmit the missing data together with a DSS-mapping.
initiator listener initiator listener
| | | |
| S 0(1000) <MP_CAPABLE>, <TFO cookie> | | S 0(1000) <MP_CAPABLE>, <TFO cookie> |
| -----------------------------------------------------------> | | -----------------------------------------------------------> |
| | | |
| S. 0(0) ack 501 <MP_CAPABLE> | | S. 0(0) ack 501 <MP_CAPABLE> |
| <----------------------------------------------------------- | | <----------------------------------------------------------- |
| | | |
| . 501(0) ack 1 <MP_CAPABLE> | | . 501(0) ack 1 <MP_CAPABLE> |
skipping to change at page 76, line 47 skipping to change at page 76, line 47
C.1. MPTCP Control Block C.1. MPTCP Control Block
The MPTCP control block contains the following variable per The MPTCP control block contains the following variable per
connection. connection.
C.1.1. Authentication and Metadata C.1.1. Authentication and Metadata
Local.Token (32 bits): This is the token chosen by the local host on Local.Token (32 bits): This is the token chosen by the local host on
this MPTCP connection. The token must be unique among all this MPTCP connection. The token must be unique among all
established MPTCP connections, generated from the local key. established MPTCP connections, and is generated from the local
key.
Local.Key (64 bits): This is the key sent by the local host on this Local.Key (64 bits): This is the key sent by the local host on this
MPTCP connection. MPTCP connection.
Remote.Token (32 bits): This is the token chosen by the remote host Remote.Token (32 bits): This is the token chosen by the remote host
on this MPTCP connection, generated from the remote key. on this MPTCP connection, generated from the remote key.
Remote.Key (64 bits): This is the key chosen by the remote host on Remote.Key (64 bits): This is the key chosen by the remote host on
this MPTCP connection this MPTCP connection
 End of changes. 22 change blocks. 
69 lines changed or deleted 81 lines changed or added

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