draft-ietf-mptcp-rfc6824bis-00.txt   draft-ietf-mptcp-rfc6824bis-01.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: Experimental U. Politechnica of Bucharest Intended status: Experimental U. Politechnica of Bucharest
Expires: April 23, 2014 M. Handley Expires: July 3, 2014 M. Handley
U. College London U. College London
O. Bonaventure O. Bonaventure
U. catholique de Louvain U. catholique de Louvain
October 20, 2013 December 30, 2013
TCP Extensions for Multipath Operation with Multiple Addresses TCP Extensions for Multipath Operation with Multiple Addresses
draft-ietf-mptcp-rfc6824bis-00 draft-ietf-mptcp-rfc6824bis-01
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 1, line 47 skipping to change at page 1, line 47
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 April 23, 2014. This Internet-Draft will expire on July 3, 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
skipping to change at page 14, line 46 skipping to change at page 14, line 46
there is not a collision before sending its key in the SYN/ACK. This there is not a collision before sending its key in the SYN/ACK. This
would, however, be costly for a server with thousands of connections. would, however, be costly for a server with thousands of connections.
The subflow handshake mechanism (Section 3.2) will ensure that new The subflow handshake mechanism (Section 3.2) will ensure that new
subflows only join the correct connection, however, through the subflows only join the correct connection, however, through the
cryptographic handshake, as well as checking the connection tokens in cryptographic handshake, as well as checking the connection tokens in
both directions, and ensuring sequence numbers are in-window. So in both directions, and ensuring sequence numbers are in-window. So in
the worst case if there was a token collision, the new subflow would the worst case if there was a token collision, the new subflow would
not succeed, but the MPTCP connection would continue to provide a not succeed, but the MPTCP connection would continue to provide a
regular TCP service. regular TCP service.
Since key generation is implementation-specific, there is no
requirement that they be simply random numbers. An implemention is
free to exchange cryptographic material out-of-band and generate
these keys from this, in order to provide additional mechanisms by
which to verify the identity of the communicating entities. For
example, an implementation could choose to link its MPTCP keys to
those used in higher-layer TLS or SSH connections.
The MP_CAPABLE option is carried on the SYN, SYN/ACK, and ACK packets The MP_CAPABLE option is carried on the SYN, SYN/ACK, and ACK packets
that start the first subflow of an MPTCP connection. The data that start the first subflow of an MPTCP connection. The data
carried by each packet is as follows, where A = initiator and B = carried by each packet is as follows, where A = initiator and B =
listener. listener.
o SYN (A->B): A's Key for this connection. o SYN (A->B): A's Key for this connection.
o SYN/ACK (B->A): B's Key for this connection. o SYN/ACK (B->A): B's Key for this connection.
o ACK (A->B): A's Key followed by B's Key. o ACK (A->B): A's Key followed by B's Key.
skipping to change at page 16, line 37 skipping to change at page 16, line 44
A crypto algorithm MUST be specified. If flag bits C through H are A crypto algorithm MUST be specified. If flag bits C through H are
all 0, the MP_CAPABLE option MUST be treated as invalid and ignored all 0, the MP_CAPABLE option MUST be treated as invalid and ignored
(that is, it must be treated as a regular TCP handshake). (that is, it must be treated as a regular TCP handshake).
The selection of the authentication algorithm also impacts the The selection of the authentication algorithm also impacts the
algorithm used to generate the token and the initial data sequence algorithm used to generate the token and the initial data sequence
number (IDSN). In this specification, with only the SHA-1 algorithm number (IDSN). In this specification, with only the SHA-1 algorithm
(bit "H") specified and selected, the token MUST be a truncated (most (bit "H") specified and selected, the token MUST be a truncated (most
significant 32 bits) SHA-1 hash ([4], [17]) of the key. A different, significant 32 bits) SHA-1 hash ([4], [17]) of the key. A different,
64-bit truncation (the least significant 64 bits) of the SHA-1 hash 56-bit truncation (the least significant 56 bits) of the SHA-1 hash
of the key MUST be used as the initial data sequence number. Note of the key MUST be used as least significant 56 bits of the initial
that the key MUST be hashed in network byte order. Also note that data sequence number. The IDSN is padded to 64 bits by the 8 most
the "least significant" bits MUST be the rightmost bits of the SHA-1 significant bits being set to zero, in order to (for all practical
purposes) remove issues around wrapped sequence numbers. Note that
the key MUST be hashed in network byte order. Also note that the
"least significant" bits MUST be the rightmost bits of the SHA-1
digest, as per [4]. Future specifications of the use of the crypto digest, as per [4]. Future specifications of the use of the crypto
bits may choose to specify different algorithms for token and IDSN bits may choose to specify different algorithms for token and IDSN
generation. generation.
Both the crypto and checksum bits negotiate capabilities in similar Both the crypto and checksum bits negotiate capabilities in similar
ways. For the Checksum Required bit (labeled "A"), if either host ways. For the Checksum Required bit (labeled "A"), if either host
requires the use of checksums, checksums MUST be used. In other requires the use of checksums, checksums MUST be used. In other
words, the only way for checksums not to be used is if both hosts in words, the only way for checksums not to be used is if both hosts in
their SYNs set A=0. This decision is confirmed by the setting of the their SYNs set A=0. This decision is confirmed by the setting of the
"A" bit in the third packet (the ACK) of the handshake. For example, "A" bit in the third packet (the ACK) of the handshake. For example,
skipping to change at page 18, line 7 skipping to change at page 18, line 17
non-MPTCP SYNs could get reordered in the network. Therefore, the non-MPTCP SYNs could get reordered in the network. Therefore, the
final state is inferred from the presence or absence of the final state is inferred from the presence or absence of the
MP_CAPABLE option in the third packet of the TCP handshake. If this MP_CAPABLE option in the third packet of the TCP handshake. If this
option is not present, the connection SHOULD fall back to regular option is not present, the connection SHOULD fall back to regular
TCP, as documented in Section 3.6. TCP, as documented in Section 3.6.
The initial data sequence number on an MPTCP connection is generated The initial data sequence number on an MPTCP connection is generated
from the key. The algorithm for IDSN generation is also determined from the key. The algorithm for IDSN generation is also determined
from the negotiated authentication algorithm. In this specification, from the negotiated authentication algorithm. In this specification,
with only the SHA-1 algorithm specified and selected, the IDSN of a with only the SHA-1 algorithm specified and selected, the IDSN of a
host MUST be the least significant 64 bits of the SHA-1 hash of its host MUST be the least significant 56 bits of the SHA-1 hash of its
key, i.e., IDSN-A = Hash(Key-A) and IDSN-B = Hash(Key-B). This key, with the most significant 8 bits being set to zero, i.e., IDSN-A
= 0x00 + Hash(Key-A) and IDSN-B = 0x00 + Hash(Key-B). This
deterministic generation of the IDSN allows a receiver to ensure that deterministic generation of the IDSN allows a receiver to ensure that
there are no gaps in sequence space at the start of the connection. there are no gaps in sequence space at the start of the connection.
The SYN with MP_CAPABLE occupies the first octet of data sequence The SYN with MP_CAPABLE occupies the first octet of data sequence
space, although this does not need to be acknowledged at the space, although this does not need to be acknowledged at the
connection level until the first data is sent (see Section 3.3). connection level until the first data is sent (see Section 3.3).
3.2. Starting a New Subflow 3.2. Starting a New Subflow
Once an MPTCP connection has begun with the MP_CAPABLE exchange, Once an MPTCP connection has begun with the MP_CAPABLE exchange,
further subflows can be added to the connection. Hosts have further subflows can be added to the connection. Hosts have
skipping to change at page 27, line 35 skipping to change at page 27, line 35
32-bit DSN and implicitly promote it to a 64-bit quantity by 32-bit DSN and implicitly promote it to a 64-bit quantity by
incrementing the upper 32 bits of sequence number each time the lower incrementing the upper 32 bits of sequence number each time the lower
32 bits wrap. A sanity check MUST be implemented to ensure that a 32 bits wrap. A sanity check MUST be implemented to ensure that a
wrap occurs at an expected time (e.g., the sequence number jumps from wrap occurs at an expected time (e.g., the sequence number jumps from
a very high number to a very low number) and is not triggered by out- a very high number to a very low number) and is not triggered by out-
of-order packets. of-order packets.
As with the standard TCP sequence number, the data sequence number As with the standard TCP sequence number, the data sequence number
should not start at zero, but at a random value to make blind session should not start at zero, but at a random value to make blind session
hijacking harder. This specification requires setting the initial hijacking harder. This specification requires setting the initial
data sequence number (IDSN) of each host to the least significant 64 data sequence number (IDSN) of each host to the least significant 56
bits of the SHA-1 hash of the host's key, as described in bits of the SHA-1 hash of the host's key, as described in
Section 3.1. This is required also in order for the receiver to know Section 3.1, and then padded to 64 bits by setting the most
what the expected IDSN is, and thus determine if any initial significant bits to zero. This is required also in order for the
connection-level packets are missing; this is particularly relevant receiver to know what the expected IDSN is, and thus determine if any
if two subflows start transmitting simultaneously. initial connection-level packets are missing; this is particularly
relevant if two subflows start transmitting simultaneously.
A data sequence mapping does not need to be included in every MPTCP A data sequence mapping does not need to be included in every MPTCP
packet, as long as the subflow sequence space in that packet is packet, as long as the subflow sequence space in that packet is
covered by a mapping known at the receiver. This can be used to covered by a mapping known at the receiver. This can be used to
reduce overhead in cases where the mapping is known in advance; one reduce overhead in cases where the mapping is known in advance; one
such case is when there is a single subflow between the hosts, such case is when there is a single subflow between the hosts,
another is when segments of data are scheduled in larger than packet- another is when segments of data are scheduled in larger than packet-
sized chunks. sized chunks.
An "infinite" mapping can be used to fall back to regular TCP by An "infinite" mapping can be used to fall back to regular TCP by
 End of changes. 9 change blocks. 
15 lines changed or deleted 28 lines changed or added

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