draft-ietf-mptcp-multiaddressed-11.txt   draft-ietf-mptcp-multiaddressed-12.txt 
Internet Engineering Task Force A. Ford Internet Engineering Task Force A. Ford
Internet-Draft Cisco Internet-Draft Cisco
Intended status: Experimental C. Raiciu Intended status: Experimental C. Raiciu
Expires: April 22, 2013 University Politehnica of Expires: April 25, 2013 University Politehnica of
Bucharest Bucharest
M. Handley M. Handley
University College London University College London
O. Bonaventure O. Bonaventure
Universite catholique de Universite catholique de
Louvain Louvain
October 19, 2012 October 22, 2012
TCP Extensions for Multipath Operation with Multiple Addresses TCP Extensions for Multipath Operation with Multiple Addresses
draft-ietf-mptcp-multiaddressed-11 draft-ietf-mptcp-multiaddressed-12
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 49 skipping to change at page 1, line 49
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 22, 2013. This Internet-Draft will expire on April 25, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2012 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 3, line 30 skipping to change at page 3, line 30
Appendix A. Notes on use of TCP Options . . . . . . . . . . . . . 58 Appendix A. Notes on use of TCP Options . . . . . . . . . . . . . 58
Appendix B. Control Blocks . . . . . . . . . . . . . . . . . . . 60 Appendix B. Control Blocks . . . . . . . . . . . . . . . . . . . 60
B.1. MPTCP Control Block . . . . . . . . . . . . . . . . . . . 60 B.1. MPTCP Control Block . . . . . . . . . . . . . . . . . . . 60
B.1.1. Authentication and Metadata . . . . . . . . . . . . . 60 B.1.1. Authentication and Metadata . . . . . . . . . . . . . 60
B.1.2. Sending Side . . . . . . . . . . . . . . . . . . . . . 60 B.1.2. Sending Side . . . . . . . . . . . . . . . . . . . . . 60
B.1.3. Receiving Side . . . . . . . . . . . . . . . . . . . . 61 B.1.3. Receiving Side . . . . . . . . . . . . . . . . . . . . 61
B.2. TCP Control Blocks . . . . . . . . . . . . . . . . . . . . 61 B.2. TCP Control Blocks . . . . . . . . . . . . . . . . . . . . 61
B.2.1. Sending Side . . . . . . . . . . . . . . . . . . . . . 61 B.2.1. Sending Side . . . . . . . . . . . . . . . . . . . . . 61
B.2.2. Receiving Side . . . . . . . . . . . . . . . . . . . . 61 B.2.2. Receiving Side . . . . . . . . . . . . . . . . . . . . 61
Appendix C. Finite State Machine . . . . . . . . . . . . . . . . 62 Appendix C. Finite State Machine . . . . . . . . . . . . . . . . 62
Appendix D. Changelog . . . . . . . . . . . . . . . . . . . . . . 62 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 62
D.1. Changes since draft-ietf-mptcp-multiaddressed-05 . . . . . 63
D.2. Changes since draft-ietf-mptcp-multiaddressed-04 . . . . . 63
D.3. Changes since draft-ietf-mptcp-multiaddressed-03 . . . . . 63
D.4. Changes since draft-ietf-mptcp-multiaddressed-02 . . . . . 63
D.5. Changes since draft-ietf-mptcp-multiaddressed-01 . . . . . 63
D.6. Changes since draft-ietf-mptcp-multiaddressed-00 . . . . . 64
D.7. Changes since draft-ford-mptcp-multiaddressed-03 . . . . . 64
D.8. Changes since draft-ford-mptcp-multiaddressed-02 . . . . . 64
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 64
1. Introduction 1. Introduction
MPTCP is a set of extensions to regular TCP [1] to provide a MPTCP is a set of extensions to regular TCP [1] to provide a
Multipath TCP [2] service, which enables a transport connection to Multipath TCP [2] service, which enables a transport connection to
operate across multiple paths simultaneously. This document presents operate across multiple paths simultaneously. This document presents
the protocol changes required to add multipath capability to TCP; the protocol changes required to add multipath capability to TCP;
specifically, those for signaling and setting up multiple paths specifically, those for signaling and setting up multiple paths
("subflows"), managing these subflows, reassembly of data, and ("subflows"), managing these subflows, reassembly of data, and
termination of sessions. This is not the only information required termination of sessions. This is not the only information required
skipping to change at page 14, line 8 skipping to change at page 14, line 8
undertaken before processing any MPTCP signals, as described in [12]. undertaken before processing any MPTCP signals, as described in [12].
3.1. Connection Initiation 3.1. Connection Initiation
Connection Initiation begins with a SYN, SYN/ACK, ACK exchange on a Connection Initiation begins with a SYN, SYN/ACK, ACK exchange on a
single path. Each packet contains the Multipath Capable (MP_CAPABLE) single path. Each packet contains the Multipath Capable (MP_CAPABLE)
TCP option (Figure 4). This option declares its sender is capable of TCP option (Figure 4). This option declares its sender is capable of
performing multipath TCP and wishes to do so on this particular performing multipath TCP and wishes to do so on this particular
connection. connection.
This option is used to declare the sender's 64 bit key, which is This option is used to declare the 64 bit key which the sender has
uniquely linked to this MPTCP connection. This key is used to generated for this MPTCP connection. This key is used to
authenticate the addition of future subflows to this connection. authenticate the addition of future subflows to this connection.
This is the only time the key will be sent in clear on the wire This is the only time the key will be sent in clear on the wire
(unless "fast close", Section 3.5, is used); all future subflows will (unless "fast close", Section 3.5, is used); all future subflows will
identify the connection using a 32 bit "token". This token is a identify the connection using a 32 bit "token". This token is a
cryptographic hash of this key. The algorithm for this process is cryptographic hash of this key. The algorithm for this process is
dependent on the authentication algorithm selected; the method of dependent on the authentication algorithm selected; the method of
selection is defined later in this section. selection is defined later in this section.
This key is generated by its sender, and its method of generation is This key is generated by its sender, and its method of generation is
implementation-specific. The key MUST be hard to guess, and it MUST implementation-specific. The key MUST be hard to guess, and it MUST
be unique for the sending host at any one time. Recommendations for be unique for the sending host at any one time. Recommendations for
generating random numbers for use in keys are given in [13]. generating random numbers for use in keys are given in [13].
Connections will be indexed at each host by the token (a one-way hash Connections will be indexed at each host by the token (a one-way hash
of the key). Therefore, an implementation will require a mapping of the key). Therefore, an implementation will require a mapping
from each token to the corresponding connection, and in turn to the from each token to the corresponding connection, and in turn to the
keys for the connection. keys for the connection.
There is a very small risk that two different keys will hash to the There is a risk that two different keys will hash to the same token.
same token. An implementation SHOULD check its list of connection The risk of hash collisions is usually small, unless the host is
tokens to ensure there is not a collision before sending its key in handling many tens of thousands of connections. Therefore, an
the SYN/ACK. This would, however, be costly for a server with implementation SHOULD check its list of connection tokens to ensure
thousands of connections. The subflow handshake mechanism there is not a collision before sending its key in the SYN/ACK. This
(Section 3.2) will ensure that new subflows only join the correct would, however, be costly for a server with thousands of connections.
connection, however, by checking tokens in both directions, and The subflow handshake mechanism (Section 3.2) will ensure that new
ensuring sequence numbers are in-window, so in the worst case if subflows only join the correct connection, however, through the
there was a token collision, the new subflow would be closed, but the cryptographic handshake, as well as checking the connection tokens in
MPTCP connection would continue to provide a regular TCP service. both directions, and ensuring sequence numbers are in-window, so in
the worst case if there was a token collision, the new subflow would
not succeed, but the MPTCP connection would continue to provide a
regular TCP service.
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. o SYN (A->B): A's Key for this connection.
o SYN/ACK (B->A): B's Key. 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.
The contents of the option is determined by the SYN and ACK flags of The contents of the option is determined by the SYN and ACK flags of
the packet, verified by the option's length field. For the diagram the packet, verified by the option's length field. For the diagram
shown in Figure 4, "sender" and "receiver" refer to the sender or shown in Figure 4, "sender" and "receiver" refer to the sender or
receiver of the TCP packet (which can be either host). If the SYN receiver of the TCP packet (which can be either host). If the SYN
flag is set, a single key is included; if only an ACK flag is set, flag is set, a single key is included; if only an ACK flag is set,
both keys are present. both keys are present.
skipping to change at page 17, line 47 skipping to change at page 18, line 5
non-MPTCP SYNs could get re-ordered in the network. Therefore, the non-MPTCP SYNs could get re-ordered 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 (IDSN) on a MPTCP connection is The initial Data Sequence Number (IDSN) on a MPTCP connection is
generated from the Key. The algorithm for IDSN generation is also generated from the Key. The algorithm for IDSN generation is also
determined from the negotiated authentication algorithm. In this determined from the negotiated authentication algorithm. In this
specification, with only the SHA-1 algorithm specified and selected, specification, with only the SHA-1 algorithm specified and selected,
the IDSN of a MUST be the least significant 64 bits of the SHA-1 hash the IDSN of a host MUST be the least significant 64 bits of the SHA-1
of the key, i.e. IDSN-A = Hash(Key-A) and IDSN-B = Hash(Key-B). hash of its key, i.e. IDSN-A = Hash(Key-A) and IDSN-B = Hash(Key-B).
This deterministic generation of the IDSN allows a receiver to ensure This deterministic generation of the IDSN allows a receiver to ensure
that there are no gaps in sequence space at the start of the that there are no gaps in sequence space at the start of the
connection. The SYN with MP_CAPABLE occupies the first octet of Data connection. The SYN with MP_CAPABLE occupies the first octet of Data
Sequence Space, although this does not need to be acknowledged at the Sequence 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 38, line 17 skipping to change at page 38, line 17
MAY want to advertise such addresses. The MP_JOIN handshake to MAY want to advertise such addresses. The MP_JOIN handshake to
create a new subflow (Section 3.2) provides mechanisms to minimise create a new subflow (Section 3.2) provides mechanisms to minimise
security risks. The MP_JOIN message contains a 32 bit token that security risks. The MP_JOIN message contains a 32 bit token that
uniquely identifies the connection to the receiving host. If the uniquely identifies the connection to the receiving host. If the
token is unknown, the host will return with a RST. In the unlikely token is unknown, the host will return with a RST. In the unlikely
event that the token is known, subflow setup will continue, but the event that the token is known, subflow setup will continue, but the
HMAC exchange must occur for authentication. This will fail, and HMAC exchange must occur for authentication. This will fail, and
will provide sufficient protection against two unconnected hosts will provide sufficient protection against two unconnected hosts
accidentally setting up a new subflow upon the signal of a private accidentally setting up a new subflow upon the signal of a private
address. Further security considerations around the issue of address. Further security considerations around the issue of
accidental or maliciously misdirecting ADD_ADDR messages are ADD_ADDR messages that accidentally mis-direct, or maliciously
discussed in Section 5. direct, new MP_JOIN attempts are discussed in Section 5.
Ideally, ADD_ADDR and REMOVE_ADDR options would be sent reliably, and Ideally, ADD_ADDR and REMOVE_ADDR options would be sent reliably, and
in order, to the other end. This would ensure that this address in order, to the other end. This would ensure that this address
management does not unnecessarily cause an outage in the connection management does not unnecessarily cause an outage in the connection
when remove/add addresses are processed in reverse order, and also to when remove/add addresses are processed in reverse order, and also to
ensure that all possible paths are used. Note, however, that losing ensure that all possible paths are used. Note, however, that losing
reliability and ordering will not break the multipath connections, it reliability and ordering will not break the multipath connections, it
will just reduce the opportunity to open multipath paths and to will just reduce the opportunity to open multipath paths and to
survive different patterns of path failures. survive different patterns of path failures.
skipping to change at page 62, line 46 skipping to change at page 63, line 5
| snd DATA_ACK[DFIN] V delete MPTCP PCB V | snd DATA_ACK[DFIN] V delete MPTCP PCB V
\ +-----------+ +---------+ \ +-----------+ +---------+
------------------------>|M_TIME WAIT|----------------->| M_CLOSED| ------------------------>|M_TIME WAIT|----------------->| M_CLOSED|
+-----------+ +---------+ +-----------+ +---------+
All subflows in CLOSED All subflows in CLOSED
------------ ------------
delete MPTCP PCB delete MPTCP PCB
Figure 17: Finite State Machine for Connection Closure Figure 17: Finite State Machine for Connection Closure
Appendix D. Changelog
(To be removed by the RFC Editor)
This section maintains logs of significant changes made to this
document between versions.
D.1. Changes since draft-ietf-mptcp-multiaddressed-05
o Added MP_FASTCLOSE mechanism.
D.2. Changes since draft-ietf-mptcp-multiaddressed-04
o Reverted change to MP_CAPABLE from last revision.
o Clarifications in response to comments.
D.3. Changes since draft-ietf-mptcp-multiaddressed-03
o Removed Key from MP_CAPABLE on SYN (it is in the ACK).
o Added optional Address ID to MP_PRIO.
o Responded to review comments.
D.4. Changes since draft-ietf-mptcp-multiaddressed-02
o Changed to using a single TCP option with a sub-type field.
o Merged Data Sequence Number, DATA_ACK, and DATA_FIN.
o Changed DATA_FIN behaviour (separated from subflow FIN).
o Added crypto agility and checksum negotiation.
o Redefined MP_JOIN handshake to use only three TCP options.
o Added pseudo-header to checksum.
o Many clarifications and re-structuring.
o Added more discussion on heuristics.
D.5. Changes since draft-ietf-mptcp-multiaddressed-01
o Added proposal for hash-based security mechanism.
o Added receiver subflow policy control (backup path flags and
MP_PRIO option).
o Changed DSN_MAP checksum to use the TCP checksum algorithm.
D.6. Changes since draft-ietf-mptcp-multiaddressed-00
o Various clarifications and minor re-structuring in response to
comments.
D.7. Changes since draft-ford-mptcp-multiaddressed-03
o Clarified handshake mechanism, especially with regard to error
cases (Section 3.2).
o Added optional port to ADD_ADDR and clarified situation with
private addresses (Section 3.4.1).
o Added path liveness check to REMOVE_ADDR (Section 3.4.2).
o Added chunk checksumming to DSN_MAP (Section 3.3.1) to detect
payload-altering middleboxes, and defined fallback mechanism
(Section 3.6).
o Major clarifications to receive window discussion (Section 3.3.5).
o Various textual clarifications, especially in examples.
D.8. Changes since draft-ford-mptcp-multiaddressed-02
o Remove Version and Address ID in MP_CAPABLE in Section 3.1, and
make ISN be 6 bytes.
o Data sequence numbers are now always 8 bytes. But in some cases
where it is unambiguous it is permissible to only send the lower 4
bytes if space is at a premium.
o Clarified behaviour of MP_JOIN in Section 3.2.
o Added DATA_ACK to Section 3.3.
o Clarified fallback to non-multipath once a non-MP-capable SYN is
sent.
Authors' Addresses Authors' Addresses
Alan Ford Alan Ford
Cisco Cisco
Ruscombe Business Park Ruscombe Business Park
Ruscombe, Berkshire RG10 9NN Ruscombe, Berkshire RG10 9NN
UK UK
Email: alanford@cisco.com Email: alanford@cisco.com
 End of changes. 12 change blocks. 
123 lines changed or deleted 26 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/