draft-ietf-mptcp-multiaddressed-10.txt   draft-ietf-mptcp-multiaddressed-11.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 6, 2013 University Politehnica of Expires: April 22, 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 3, 2012 October 19, 2012
TCP Extensions for Multipath Operation with Multiple Addresses TCP Extensions for Multipath Operation with Multiple Addresses
draft-ietf-mptcp-multiaddressed-10 draft-ietf-mptcp-multiaddressed-11
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 6, 2013. This Internet-Draft will expire on April 22, 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 2, line 26 skipping to change at page 2, line 26
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 . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Design Assumptions . . . . . . . . . . . . . . . . . . . . 4 1.1. Design Assumptions . . . . . . . . . . . . . . . . . . . . 4
1.2. Multipath TCP in the Networking Stack . . . . . . . . . . 5 1.2. Multipath TCP in the Networking Stack . . . . . . . . . . 5
1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6 1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6
1.4. MPTCP Concept . . . . . . . . . . . . . . . . . . . . . . 6 1.4. MPTCP Concept . . . . . . . . . . . . . . . . . . . . . . 7
1.5. Requirements Language . . . . . . . . . . . . . . . . . . 8 1.5. Requirements Language . . . . . . . . . . . . . . . . . . 8
2. Operation Overview . . . . . . . . . . . . . . . . . . . . . . 8 2. Operation Overview . . . . . . . . . . . . . . . . . . . . . . 8
2.1. Initiating an MPTCP connection . . . . . . . . . . . . . . 8 2.1. Initiating an MPTCP connection . . . . . . . . . . . . . . 9
2.2. Associating a new subflow with an existing MPTCP 2.2. Associating a new subflow with an existing MPTCP
connection . . . . . . . . . . . . . . . . . . . . . . . . 9 connection . . . . . . . . . . . . . . . . . . . . . . . . 9
2.3. Informing the other Host about another potential 2.3. Informing the other Host about another potential
address . . . . . . . . . . . . . . . . . . . . . . . . . 9 address . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.4. Data transfer using MPTCP . . . . . . . . . . . . . . . . 10 2.4. Data transfer using MPTCP . . . . . . . . . . . . . . . . 11
2.5. Requesting a change in a path's priority . . . . . . . . . 11 2.5. Requesting a change in a path's priority . . . . . . . . . 11
2.6. Closing an MPTCP connection . . . . . . . . . . . . . . . 11 2.6. Closing an MPTCP connection . . . . . . . . . . . . . . . 12
2.7. Notable features . . . . . . . . . . . . . . . . . . . . . 11 2.7. Notable features . . . . . . . . . . . . . . . . . . . . . 12
3. MPTCP Protocol . . . . . . . . . . . . . . . . . . . . . . . . 12 3. MPTCP Protocol . . . . . . . . . . . . . . . . . . . . . . . . 12
3.1. Connection Initiation . . . . . . . . . . . . . . . . . . 13 3.1. Connection Initiation . . . . . . . . . . . . . . . . . . 13
3.2. Starting a New Subflow . . . . . . . . . . . . . . . . . . 17 3.2. Starting a New Subflow . . . . . . . . . . . . . . . . . . 18
3.3. General MPTCP Operation . . . . . . . . . . . . . . . . . 22 3.3. General MPTCP Operation . . . . . . . . . . . . . . . . . 23
3.3.1. Data Sequence Mapping . . . . . . . . . . . . . . . . 24 3.3.1. Data Sequence Mapping . . . . . . . . . . . . . . . . 25
3.3.2. Data Acknowledgments . . . . . . . . . . . . . . . . . 27 3.3.2. Data Acknowledgments . . . . . . . . . . . . . . . . . 28
3.3.3. Closing a Connection . . . . . . . . . . . . . . . . . 28 3.3.3. Closing a Connection . . . . . . . . . . . . . . . . . 29
3.3.4. Receiver Considerations . . . . . . . . . . . . . . . 29 3.3.4. Receiver Considerations . . . . . . . . . . . . . . . 30
3.3.5. Sender Considerations . . . . . . . . . . . . . . . . 30 3.3.5. Sender Considerations . . . . . . . . . . . . . . . . 31
3.3.6. Reliability and Retransmissions . . . . . . . . . . . 31 3.3.6. Reliability and Retransmissions . . . . . . . . . . . 32
3.3.7. Congestion Control Considerations . . . . . . . . . . 32 3.3.7. Congestion Control Considerations . . . . . . . . . . 33
3.3.8. Subflow Policy . . . . . . . . . . . . . . . . . . . . 33 3.3.8. Subflow Policy . . . . . . . . . . . . . . . . . . . . 34
3.4. Address Knowledge Exchange (Path Management) . . . . . . . 34 3.4. Address Knowledge Exchange (Path Management) . . . . . . . 35
3.4.1. Address Advertisement . . . . . . . . . . . . . . . . 35 3.4.1. Address Advertisement . . . . . . . . . . . . . . . . 36
3.4.2. Remove Address . . . . . . . . . . . . . . . . . . . . 38 3.4.2. Remove Address . . . . . . . . . . . . . . . . . . . . 39
3.5. Fast Close . . . . . . . . . . . . . . . . . . . . . . . . 39 3.5. Fast Close . . . . . . . . . . . . . . . . . . . . . . . . 40
3.6. Fallback . . . . . . . . . . . . . . . . . . . . . . . . . 40 3.6. Fallback . . . . . . . . . . . . . . . . . . . . . . . . . 41
3.7. Error Handling . . . . . . . . . . . . . . . . . . . . . . 43 3.7. Error Handling . . . . . . . . . . . . . . . . . . . . . . 44
3.8. Heuristics . . . . . . . . . . . . . . . . . . . . . . . . 44 3.8. Heuristics . . . . . . . . . . . . . . . . . . . . . . . . 45
3.8.1. Port Usage . . . . . . . . . . . . . . . . . . . . . . 44 3.8.1. Port Usage . . . . . . . . . . . . . . . . . . . . . . 45
3.8.2. Delayed Subflow Start . . . . . . . . . . . . . . . . 44 3.8.2. Delayed Subflow Start . . . . . . . . . . . . . . . . 45
3.8.3. Failure Handling . . . . . . . . . . . . . . . . . . . 45 3.8.3. Failure Handling . . . . . . . . . . . . . . . . . . . 46
4. Semantic Issues . . . . . . . . . . . . . . . . . . . . . . . 46 4. Semantic Issues . . . . . . . . . . . . . . . . . . . . . . . 47
5. Security Considerations . . . . . . . . . . . . . . . . . . . 47 5. Security Considerations . . . . . . . . . . . . . . . . . . . 48
6. Interactions with Middleboxes . . . . . . . . . . . . . . . . 49 6. Interactions with Middleboxes . . . . . . . . . . . . . . . . 51
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 53 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 54
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 53 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 54
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 55 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 56
9.1. Normative References . . . . . . . . . . . . . . . . . . . 55 9.1. Normative References . . . . . . . . . . . . . . . . . . . 56
9.2. Informative References . . . . . . . . . . . . . . . . . . 55 9.2. Informative References . . . . . . . . . . . . . . . . . . 56
Appendix A. Notes on use of TCP Options . . . . . . . . . . . . . 57 Appendix A. Notes on use of TCP Options . . . . . . . . . . . . . 58
Appendix B. Control Blocks . . . . . . . . . . . . . . . . . . . 58 Appendix B. Control Blocks . . . . . . . . . . . . . . . . . . . 60
B.1. MPTCP Control Block . . . . . . . . . . . . . . . . . . . 59 B.1. MPTCP Control Block . . . . . . . . . . . . . . . . . . . 60
B.1.1. Authentication and Metadata . . . . . . . . . . . . . 59 B.1.1. Authentication and Metadata . . . . . . . . . . . . . 60
B.1.2. Sending Side . . . . . . . . . . . . . . . . . . . . . 59 B.1.2. Sending Side . . . . . . . . . . . . . . . . . . . . . 60
B.1.3. Receiving Side . . . . . . . . . . . . . . . . . . . . 60 B.1.3. Receiving Side . . . . . . . . . . . . . . . . . . . . 61
B.2. TCP Control Blocks . . . . . . . . . . . . . . . . . . . . 60 B.2. TCP Control Blocks . . . . . . . . . . . . . . . . . . . . 61
B.2.1. Sending Side . . . . . . . . . . . . . . . . . . . . . 60 B.2.1. Sending Side . . . . . . . . . . . . . . . . . . . . . 61
B.2.2. Receiving Side . . . . . . . . . . . . . . . . . . . . 60 B.2.2. Receiving Side . . . . . . . . . . . . . . . . . . . . 61
Appendix C. Finite State Machine . . . . . . . . . . . . . . . . 61 Appendix C. Finite State Machine . . . . . . . . . . . . . . . . 62
Appendix D. Changelog . . . . . . . . . . . . . . . . . . . . . . 61 Appendix D. Changelog . . . . . . . . . . . . . . . . . . . . . . 62
D.1. Changes since draft-ietf-mptcp-multiaddressed-05 . . . . . 62 D.1. Changes since draft-ietf-mptcp-multiaddressed-05 . . . . . 63
D.2. Changes since draft-ietf-mptcp-multiaddressed-04 . . . . . 62 D.2. Changes since draft-ietf-mptcp-multiaddressed-04 . . . . . 63
D.3. Changes since draft-ietf-mptcp-multiaddressed-03 . . . . . 62 D.3. Changes since draft-ietf-mptcp-multiaddressed-03 . . . . . 63
D.4. Changes since draft-ietf-mptcp-multiaddressed-02 . . . . . 62 D.4. Changes since draft-ietf-mptcp-multiaddressed-02 . . . . . 63
D.5. Changes since draft-ietf-mptcp-multiaddressed-01 . . . . . 62 D.5. Changes since draft-ietf-mptcp-multiaddressed-01 . . . . . 63
D.6. Changes since draft-ietf-mptcp-multiaddressed-00 . . . . . 63 D.6. Changes since draft-ietf-mptcp-multiaddressed-00 . . . . . 64
D.7. Changes since draft-ford-mptcp-multiaddressed-03 . . . . . 63 D.7. Changes since draft-ford-mptcp-multiaddressed-03 . . . . . 64
D.8. Changes since draft-ford-mptcp-multiaddressed-02 . . . . . 63 D.8. Changes since draft-ford-mptcp-multiaddressed-02 . . . . . 64
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 63 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 4, line 51 skipping to change at page 4, line 51
o It can be assumed that one or both hosts are multihomed and o It can be assumed that one or both hosts are multihomed and
multiaddressed multiaddressed
To simplify the design we assume that the presence of multiple To simplify the design we assume that the presence of multiple
addresses at a host is sufficient to indicate the existence of addresses at a host is sufficient to indicate the existence of
multiple paths. These paths need not be entirely disjoint: they may multiple paths. These paths need not be entirely disjoint: they may
share one or many routers between them. Even in such a situation share one or many routers between them. Even in such a situation
making use of multiple paths is beneficial, improving resource making use of multiple paths is beneficial, improving resource
utilisation and resilience to a subset of node failures. The utilisation and resilience to a subset of node failures. The
congestion control algorithms defined in [5] ensure this does not act congestion control algorithms defined in [5] ensure this does not act
detrimentally. detrimentally. Furthermore, there may be some scenarios where
different TCP ports on a single host can provide disjoint paths (such
as through certain ECMP implementations [7]), and so the MPTCP design
also supports the use of ports in path identifiers.
There are three aspects to the backwards-compatibility listed above There are three aspects to the backwards-compatibility listed above
(discussed in more detail in [2]): (discussed in more detail in [2]):
External Constraints: The protocol must function through the vast External Constraints: The protocol must function through the vast
majority of existing middleboxes such as NATs, firewalls and majority of existing middleboxes such as NATs, firewalls and
proxies, and as such must resemble existing TCP as far as possible proxies, and as such must resemble existing TCP as far as possible
on the wire. Furthermore, the protocol must not assume the on the wire. Furthermore, the protocol must not assume the
segments it sends on the wire arrive unmodified at the segments it sends on the wire arrive unmodified at the
destination: they may be split or coalesced; TCP options may be destination: they may be split or coalesced; TCP options may be
skipping to change at page 5, line 26 skipping to change at page 5, line 28
Application Constraints: The protocol must be usable with no change Application Constraints: The protocol must be usable with no change
to existing applications that use the common TCP API (although it to existing applications that use the common TCP API (although it
is reasonable that not all features would be available to such is reasonable that not all features would be available to such
legacy applications). Furthermore, the protocol must provide the legacy applications). Furthermore, the protocol must provide the
same service model as regular TCP to the application. same service model as regular TCP to the application.
Fall-back: The protocol should be able to fall back to standard TCP Fall-back: The protocol should be able to fall back to standard TCP
with no interference from the user, to be able to communicate with with no interference from the user, to be able to communicate with
legacy hosts. legacy hosts.
The complementary application considerations document [6] discusses
the necessary features of an API to provide backwards-compatibility,
as well as API extensions to convey the behaviour of MPTCP at a level
of control and information equivalent to that available with regular,
single-path TCP.
Further discussion of the design constraints and associated design Further discussion of the design constraints and associated design
decisions are given in the MPTCP Architecture document [2]. decisions are given in the MPTCP Architecture document [2].
1.2. Multipath TCP in the Networking Stack 1.2. Multipath TCP in the Networking Stack
MPTCP operates at the transport layer and aims to be transparent to MPTCP operates at the transport layer and aims to be transparent to
both higher and lower layers. It is a set of additional features on both higher and lower layers. It is a set of additional features on
top of standard TCP; Figure 1 illustrates this layering. MPTCP is top of standard TCP; Figure 1 illustrates this layering. MPTCP is
designed to be usable by legacy applications with no changes; designed to be usable by legacy applications with no changes;
detailed discussion of its interactions with applications is given in detailed discussion of its interactions with applications is given in
skipping to change at page 6, line 12 skipping to change at page 6, line 24
Figure 1: Comparison of Standard TCP and MPTCP Protocol Stacks Figure 1: Comparison of Standard TCP and MPTCP Protocol Stacks
1.3. Terminology 1.3. Terminology
This document makes use of a number of terms which are either MPTCP- This document makes use of a number of terms which are either MPTCP-
specific, or have defined meaning in the context of MPTCP, as specific, or have defined meaning in the context of MPTCP, as
follows: follows:
Path: A sequence of links between a sender and a receiver, defined Path: A sequence of links between a sender and a receiver, defined
in this context by a source and destination address pair. in this context by a 4-tuple of source and destination address/
port pairs.
Subflow: A flow of TCP segments operating over an individual path, Subflow: A flow of TCP segments operating over an individual path,
which forms part of a larger MPTCP connection. A subflow is which forms part of a larger MPTCP connection. A subflow is
started and terminated similarly to a regular TCP connection. started and terminated similarly to a regular TCP connection.
(MPTCP) Connection: A set of one or more subflows, over which an (MPTCP) Connection: A set of one or more subflows, over which an
application can communicate between two hosts. There is a one-to- application can communicate between two hosts. There is a one-to-
one mapping between a connection and an application socket. one mapping between a connection and an application socket.
Data-level: The payload data is nominally transferred over a Data-level: The payload data is nominally transferred over a
skipping to change at page 6, line 34 skipping to change at page 6, line 47
term "data-level" is synonymous with "connection level", in term "data-level" is synonymous with "connection level", in
contrast to "subflow-level" which refers to properties of an contrast to "subflow-level" which refers to properties of an
individual subflow. individual subflow.
Token: A locally unique identifier given to a multipath connection Token: A locally unique identifier given to a multipath connection
by a host. May also be referred to as a "Connection ID". by a host. May also be referred to as a "Connection ID".
Host: A end host operating an MPTCP implementation, and either Host: A end host operating an MPTCP implementation, and either
initiating or accepting an MPTCP connection. initiating or accepting an MPTCP connection.
MPTCP's interpretation of, and effect on, regular single-path TCP In addition to these terms, note that MPTCP's interpretation of, and
semantics are discussed in Section 4. effect on, regular single-path TCP semantics are discussed in
Section 4.
1.4. MPTCP Concept 1.4. MPTCP Concept
This section provides a high-level summary of normal operation of This section provides a high-level summary of normal operation of
MPTCP, and is illustrated by the scenario shown in Figure 2. A MPTCP, and is illustrated by the scenario shown in Figure 2. A
detailed description of operation is given in Section 3. detailed description of operation is given in Section 3.
o To a non-MPTCP-aware application, MPTCP will behave the same as o To a non-MPTCP-aware application, MPTCP will behave the same as
normal TCP. Extended APIs could provide additional control to normal TCP. Extended APIs could provide additional control to
MPTCP-aware applications [6]. An application begins by opening a MPTCP-aware applications [6]. An application begins by opening a
skipping to change at page 8, line 13 skipping to change at page 8, line 30
Figure 2: Example MPTCP Usage Scenario Figure 2: Example MPTCP Usage Scenario
1.5. Requirements Language 1.5. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [3]. document are to be interpreted as described in RFC 2119 [3].
2. Operation Overview 2. Operation Overview
This section presents a single description of standard MPTCP This section presents a single description of common MPTCP operation,
operation, with reference to the protocol operation. This is a high- with reference to the protocol operation. This is a high-level
level overview of the key functions; the full specification follows overview of the key functions; the full specification follows in
in Section 3. Considerable reference is made to symbolic names of Section 3. Extensibility and negotiated features are not discussed
MPTCP options throughout this section - these are subtypes of the here. Considerable reference is made to symbolic names of MPTCP
IANA-assigned MPTCP option (see Section 8), and their formats are options throughout this section - these are subtypes of the IANA-
defined in the detailed protocol specification which follows in assigned MPTCP option (see Section 8), and their formats are defined
Section 3. in the detailed protocol specification which follows in Section 3.
A Multipath TCP connection provides a bidirectionnal bytestream A Multipath TCP connection provides a bidirectionnal bytestream
between two hosts communicating like normal TCP and thus does not between two hosts communicating like normal TCP and thus does not
require any change to the applications. However, Multipath TCP require any change to the applications. However, Multipath TCP
enables the hosts to use different paths with different IP addresses enables the hosts to use different paths with different IP addresses
to exchange packets belonging to the MPTCP connection. A Multipath to exchange packets belonging to the MPTCP connection. A Multipath
TCP connection appears like a normal TCP connection to an TCP connection appears like a normal TCP connection to an
application. However, to the network layer each MPTCP subflows looks application. However, to the network layer each MPTCP subflows looks
like a regular TCP flow whose segments carry a new TCP option type. like a regular TCP flow whose segments carry a new TCP option type.
Multipath TCP manages the creation, removal and utilization of these Multipath TCP manages the creation, removal and utilization of these
skipping to change at page 12, line 15 skipping to change at page 12, line 37
o To cope with NATs on the path, addresses are referred to by o To cope with NATs on the path, addresses are referred to by
Address IDs, in case the IP packet's source address gets changed Address IDs, in case the IP packet's source address gets changed
by a NAT. Setting up a new TCP flow is not possible if the by a NAT. Setting up a new TCP flow is not possible if the
passive opener is behind a NAT; to allow subflows to be created passive opener is behind a NAT; to allow subflows to be created
when either end is behind a NAT, MPTCP uses the ADD_ADDR message. when either end is behind a NAT, MPTCP uses the ADD_ADDR message.
o MPTCP falls back to ordinary TCP if MPTCP operation is not o MPTCP falls back to ordinary TCP if MPTCP operation is not
possible. For example if one host is not MPTCP capable, or if a possible. For example if one host is not MPTCP capable, or if a
middlebox alters the payload. middlebox alters the payload.
o To meet the threats identified in [7], the following steps are o To meet the threats identified in [8], the following steps are
taken: keys are sent in the clear in the MP_CAPABLE messages; taken: keys are sent in the clear in the MP_CAPABLE messages;
MP_JOIN messages are secured with HMAC-SHA1 ([8], [4]) using those MP_JOIN messages are secured with HMAC-SHA1 ([9], [4]) using those
keys; and standard TCP validity checks are made on the other keys; and standard TCP validity checks are made on the other
messages (ensuring sequence numbers are in-window). messages (ensuring sequence numbers are in-window).
3. MPTCP Protocol 3. MPTCP Protocol
This section describes the operation of the MPTCP protocol, and is This section describes the operation of the MPTCP protocol, and is
subdivided into sections for each key part of the protocol operation. subdivided into sections for each key part of the protocol operation.
All MPTCP operations are signalled using optional TCP header fields. All MPTCP operations are signalled using optional TCP header fields.
A single TCP option number ("Kind") will be assigned by IANA for A single TCP option number ("Kind") will be assigned by IANA for
skipping to change at page 12, line 50 skipping to change at page 13, line 24
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 |Subtype| | | Kind | Length |Subtype| |
+---------------+---------------+-------+ | +---------------+---------------+-------+ |
| Subtype-specific data | | Subtype-specific data |
| (variable length) | | (variable length) |
+---------------------------------------------------------------+ +---------------------------------------------------------------+
Figure 3: MPTCP option format Figure 3: MPTCP option format
Those MPTCP options associated with subflow initiation must be Those MPTCP options associated with subflow initiation are used on
included on packets with the SYN flag set. Additionally, there is packets with the SYN flag set. Additionally, there is one MPTCP
one MPTCP option for signaling metadata to ensure segmented data can option for signaling metadata to ensure segmented data can be
be recombined for delivery to the application. recombined for delivery to the application.
The remaining options, however, are signals that do not need to be on The remaining options, however, are signals that do not need to be on
a specific packet, such as those for signaling additional addresses. a specific packet, such as those for signaling additional addresses.
Whilst an implementation may desire to send MPTCP options as soon as Whilst an implementation may desire to send MPTCP options as soon as
possible, it may not be possible to combine all desired options (both possible, it may not be possible to combine all desired options (both
those for MPTCP and for regular TCP, such as SACK [9]) on a single those for MPTCP and for regular TCP, such as SACK [10]) on a single
packet. Therefore, an implementation may choose to send duplicate packet. Therefore, an implementation may choose to send duplicate
ACKs containing the additional signaling information. This changes ACKs containing the additional signaling information. This changes
the semantics of a duplicate ACK, these are usually only sent as a the semantics of a duplicate ACK, these are usually only sent as a
signal of a lost segment [10] in regular TCP. Therefore, an MPTCP signal of a lost segment [11] in regular TCP. Therefore, an MPTCP
implementation receiving a duplicate ACK which contains an MPTCP implementation receiving a duplicate ACK which contains an MPTCP
option MUST NOT treat it as a signal of congestion. Additionally, an option MUST NOT treat it as a signal of congestion. Additionally, an
MPTCP implementation SHOULD NOT send more than two duplicate ACKs in MPTCP implementation SHOULD NOT send more than two duplicate ACKs in
a row for the purposes of sending MPTCP options alone, in order to a row for the purposes of sending MPTCP options alone, in order to
ensure no middleboxes misinterpret this as a sign of congestion. ensure no middleboxes misinterpret this as a sign of congestion.
Furthermore, standard TCP validity checks (such as ensuring the Furthermore, standard TCP validity checks (such as ensuring the
Sequence Number and Acknowledgement Number are within window) MUST be Sequence Number and Acknowledgement Number are within window) MUST be
undertaken before processing any MPTCP signals, as described in [11]. 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 sender's 64 bit key, which is
skipping to change at page 13, line 47 skipping to change at page 14, line 21
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 numers for use in keys are given in [12]. 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 very small risk that two different keys will hash to the
same token. An implementation SHOULD check its list of connection same token. An implementation SHOULD check its list of connection
tokens to ensure there is not a collision before sending its key in tokens to ensure there is not a collision before sending its key in
the SYN/ACK. This would, however, be costly for a server with the SYN/ACK. This would, however, be costly for a server with
thousands of connections. The subflow handshake mechanism thousands of connections. The subflow handshake mechanism
skipping to change at page 16, line 10 skipping to change at page 16, line 27
bit, labelled "H", is assigned. Bit "H" indicates the use of bit, labelled "H", is assigned. Bit "H" indicates the use of
HMAC-SHA1 (as defined in Section 3.2). An implementation that HMAC-SHA1 (as defined in Section 3.2). An implementation that
only supports this method MUST set bit "H" to 1, and bits "C" only supports this method MUST set bit "H" to 1, and bits "C"
through "G" to 0. through "G" to 0.
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. In this specification, with algorithm used to generate the token and the Initial Data Sequence
only the SHA-1 algorithm (bit "H") specified and selected, the token Number. In this specification, with only the SHA-1 algorithm (bit
MUST be a truncated (most significant 32 bits) SHA-1 hash [4]. A "H") specified and selected, the token MUST be a truncated (most
different, 64 bit truncation (the least significant 64 bits) of the significant 32 bits) SHA-1 hash ([4], [14]) of the key. A different,
hash of the key is RECOMMENDED to be used as the Initial Data 64 bit truncation (the least significant 64 bits) of the SHA-1 hash
Sequence Number. Future specifications of the use of the crypto bits of the key MUST be used as the Initial Data Sequence Number. Note
may choose to specify different token generation algorithms. 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
bits may choose to specify different algorithms for token and IDSN
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 (labelled "A"), if either host ways. For the Checksum Required bit (labelled "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,
if the initiator sets A=0 in the SYN, but the responder sets A=1 in if the initiator sets A=0 in the SYN, but the responder sets A=1 in
the SYN/ACK, checksums MUST be used in both directions, and the the SYN/ACK, checksums MUST be used in both directions, and the
initiator will set A=1 in the ACK. The decision whether to use initiator will set A=1 in the ACK. The decision whether to use
skipping to change at page 17, line 22 skipping to change at page 17, line 43
fall back to single-path TCP (i.e. without the MP_CAPABLE Option) in fall back to single-path TCP (i.e. without the MP_CAPABLE Option) in
order to work around middleboxes that may drop packets with unknown order to work around middleboxes that may drop packets with unknown
options; however, the number of multipath-capable attempts that are options; however, the number of multipath-capable attempts that are
made first will be up to local policy. It is possible that MPTCP and made first will be up to local policy. It is possible that MPTCP and
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 MUST be The initial Data Sequence Number (IDSN) on a MPTCP connection is
hard to guess. It is RECOMMENDED that the IDSN is generated as a generated from the Key. The algorithm for IDSN generation is also
hash from the Key, i.e. IDSN-A = Hash(Key-A) and IDSN-B = determined from the negotiated authentication algorithm. In this
Hash(Key-B). A suggested algorithm for this version of the specification, with only the SHA-1 algorithm specified and selected,
specification is to use the least significant 64 bits of the SHA-1 the IDSN of a MUST be the least significant 64 bits of the SHA-1 hash
hash of the key, however a receiver MUST NOT make any assumptions of the key, i.e. IDSN-A = Hash(Key-A) and IDSN-B = Hash(Key-B).
about the IDSN generation algorithm. The SYN with MP_CAPABLE This deterministic generation of the IDSN allows a receiver to ensure
occupies the first octet of Data Sequence Space, although this does that there are no gaps in sequence space at the start of the
not need to be acknowledged at the connection level until the first connection. The SYN with MP_CAPABLE occupies the first octet of Data
data is sent (see Section 3.3). Sequence Space, although this does not need to be acknowledged at the
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
knowledge of their own address(es), and can become aware of the other knowledge of their own address(es), and can become aware of the other
host's addresses through signaling exchanges as described in host's addresses through signaling exchanges as described in
Section 3.4. Using this knowledge, a host can initiate a new subflow Section 3.4. Using this knowledge, a host can initiate a new subflow
over a currently unused pair of addresses. It is permitted for over a currently unused pair of addresses. It is permitted for
either host in a connection to initiate the creation of a new either host in a connection to initiate the creation of a new
skipping to change at page 18, line 16 skipping to change at page 18, line 37
algorithm. An MP_JOIN option is present in the SYN, SYN/ACK and ACK algorithm. An MP_JOIN option is present in the SYN, SYN/ACK and ACK
of the three-way handshake, although in each case with a different of the three-way handshake, although in each case with a different
format. format.
In the first MP_JOIN on the SYN packet, illustrated in Figure 5, the In the first MP_JOIN on the SYN packet, illustrated in Figure 5, the
initiator sends a token, random number, and address ID. initiator sends a token, random number, and address ID.
The token is used to identify the MPTCP connection and is a The token is used to identify the MPTCP connection and is a
cryptographic hash of the receiver's key, as exchanged in the initial cryptographic hash of the receiver's key, as exchanged in the initial
MP_CAPABLE handshake (Section 3.1). In this specification, the MP_CAPABLE handshake (Section 3.1). In this specification, the
tokens presented in this option are generated by the SHA-1 [4] tokens presented in this option are generated by the SHA-1 ([4],
algorithm, truncated to the most significant 32 bits. The token [14]) algorithm, truncated to the most significant 32 bits. The
included in the MP_JOIN option is the token that the receiver of the token included in the MP_JOIN option is the token that the receiver
packet uses to identify this connection, i.e. Host A will send of the packet uses to identify this connection, i.e. Host A will
Token-B (which is generated from Key-B). Note that the hash send Token-B (which is generated from Key-B). Note that the hash
generation algorithm can be overridden by the choice of cryptographic generation algorithm can be overridden by the choice of cryptographic
handshake algorithm, as defined in Section 3.1. handshake algorithm, as defined in Section 3.1.
The MP_JOIN SYN not only sends the token (which is static for a The MP_JOIN SYN not only sends the token (which is static for a
connection) but also Random Numbers (nonces) that are used to prevent connection) but also Random Numbers (nonces) that are used to prevent
replay attacks on the authentication method. replay attacks on the authentication method. Recommendations for the
generation of random numbers for this purpose are given in [13].
The MP_JOIN option includes an "Address ID". This is an identifier The MP_JOIN option includes an "Address ID". This is an identifier
that only has significance within a single connection, where it that only has significance within a single connection, where it
identifies the source address of this packet, even if the IP header identifies the source address of this packet, even if the IP header
has been changed in transit by a middlebox. The Address ID allows has been changed in transit by a middlebox. The Address ID allows
address removal (Section 3.4.2) without needing to know what the address removal (Section 3.4.2) without needing to know what the
source address at the receiver is, thus allowing address removal source address at the receiver is, thus allowing address removal
through NATs. The Address ID also allows correlation between new through NATs. The Address ID also allows correlation between new
subflow setup attempts and address signaling (Section 3.4.1), to subflow setup attempts and address signaling (Section 3.4.1), to
prevent setting up duplicate subflows on the same path, if a MP_JOIN prevent setting up duplicate subflows on the same path, if a MP_JOIN
skipping to change at page 19, line 41 skipping to change at page 20, line 16
token in the MP_JOIN SYN gives sufficient protection against blind token in the MP_JOIN SYN gives sufficient protection against blind
state exhaustion attacks and therefore there is no need to provide state exhaustion attacks and therefore there is no need to provide
mechanisms to allow a responder to operate statelessly at the MP_JOIN mechanisms to allow a responder to operate statelessly at the MP_JOIN
stage. 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 [8] is used, along with the SHA-1 hash that HMAC as defined in [9] is used, along with the SHA-1 hash
algorithm [4] (thus generating a 160-bit / 20 octet HMAC). Due to algorithm [4] (potentially implemented as in [14]), thus generating a
option space limitations, the HMAC included in the SYN/ACK is 160-bit / 20 octet HMAC. Due to option space limitations, the HMAC
truncated to the leftmost 64 bits, but this is acceptable since included in the SYN/ACK is truncated to the leftmost 64 bits, but
random numbers are used, and thus an attacker only has one chance to this is acceptable since random numbers are used, and thus an
guess the HMAC correctly (if the HMAC is incorrect, the TCP attacker only has one chance to guess the HMAC correctly (if the HMAC
connection is closed, so a new MP_JOIN negotiation with a new random is incorrect, the TCP connection is closed, so a new MP_JOIN
number is required). 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 and therefore receipt of this packet MUST trigger a regular TCP sent and 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 23, line 52 skipping to change at page 24, line 52
data sequence mapping are described in Section 3.3.3. The remaining data sequence mapping are described in Section 3.3.3. The remaining
reserved bits MUST be set to zero by an implementation of this reserved bits MUST be set to zero by an implementation of this
specification. 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 checksum field
MUST be ignored. If a checksum is not present when its use has been MUST be ignored. If a checksum is not present when its use has been
negotiated, the receiver SHOULD close the subflow with a RST as it is negotiated, the receiver MUST close the subflow with a RST as it is
considered broken. considered broken.
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
mandated) that SACK [9] is used at the subflow level to improve mandated) that SACK [10] is used at the subflow level to improve
efficiency. efficiency.
The Data Sequence Mapping specifies a mapping from subflow sequence The Data Sequence Mapping specifies a mapping from subflow sequence
space to data sequence space. This is expressed in terms of starting space to data sequence space. This is expressed in terms of starting
sequence numbers for the subflow and the data level, and a length of sequence numbers for the subflow and the data level, and a length of
bytes for which this mapping is valid. This explicit mapping for a bytes for which this mapping is valid. This explicit mapping for a
range of data was chosen rather than per-packet signaling to assist range of data was chosen rather than per-packet signaling to assist
with compatibility with situations where TCP/IP segmentation or with compatibility with situations where TCP/IP segmentation or
coalescing is undertaken separately from the stack that is generating coalescing is undertaken separately from the stack that is generating
the data flow (e.g. through the use of TCP segmentation offloading on the data flow (e.g. through the use of TCP segmentation offloading on
skipping to change at page 26, line 25 skipping to change at page 27, line 25
Data sequence numbers are always 64 bit quantities, and MUST be Data sequence numbers are always 64 bit quantities, and MUST be
maintained as such in implementations. If a connection is maintained as such in implementations. If a connection is
progressing at a slow rate, so protection against wrapped sequence progressing at a slow rate, so protection against wrapped sequence
numbers is not required, then it is permissible to include just the numbers is not required, then it is permissible to include just the
lower 32 bits of the data sequence number in the Data Sequence lower 32 bits of the data sequence number in the Data Sequence
Mapping and/or Data ACK as an optimization, and an implementation can Mapping and/or Data ACK as an optimization, and an implementation can
make this choice independently for each packet. make this choice independently for each packet.
An implementation MUST send the full 64 bit Data Sequence Number if An implementation MUST send the full 64 bit Data Sequence Number if
it is transmitting at a sufficiently high rate that the 32 bit value it is transmitting at a sufficiently high rate that the 32 bit value
could wrap within the Maximum Segment Lifetime (MSL) [13]. The could wrap within the Maximum Segment Lifetime (MSL) [15]. The
lengths of the DSNs used in these values (which may be different) are lengths of the DSNs used in these values (which may be different) are
declared with flags in the DSS option. Implementations MUST accept a declared with flags in the DSS option. Implementations MUST accept a
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 suggests 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 64
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. Section 3.1.
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-
skipping to change at page 33, line 33 skipping to change at page 34, line 33
throughput. Application requirements such as these are discussed in throughput. Application requirements such as these are discussed in
detail in [6]. detail in [6].
The ability to make effective choices at the sender requires full The ability to make effective choices at the sender requires full
knowledge of the path "cost", which is unlikely to be the case. It knowledge of the path "cost", which is unlikely to be the case. It
would be desirable for a receiver to be able to signal their own would be desirable for a receiver to be able to signal their own
preferences for paths, since they will often be the multihomed party, preferences for paths, since they will often be the multihomed party,
and may have to pay for metered incoming bandwidth. and may have to pay for metered incoming bandwidth.
Whilst fine-grained control may be the most powerful solution, that Whilst fine-grained control may be the most powerful solution, that
would require some mechanism such as overloading the ECN signal [14], would require some mechanism such as overloading the ECN signal [16],
which is undesirable, and it is felt that there would not be which is undesirable, and it is felt that there would not be
sufficient benefit to justify an entirely new signal. Therefore the sufficient benefit to justify an entirely new signal. Therefore the
MP_JOIN option (see Section 3.2) contains the 'B' bit, which allows a MP_JOIN option (see Section 3.2) contains the 'B' bit, which allows a
host to indicate to its peer that this path should be treated as a host to indicate to its peer that this path should be treated as a
backup path to use only in the event of failure of other working backup path to use only in the event of failure of other working
subflows (i.e. a subflow where the receiver has indicated B=1 SHOULD subflows (i.e. a subflow where the receiver has indicated B=1 SHOULD
NOT be used to send data unless there are no usable subflows where NOT be used to send data unless there are no usable subflows where
B=0). B=0).
In the event that the available set of paths changes, a host may wish In the event that the available set of paths changes, a host may wish
skipping to change at page 37, line 4 skipping to change at page 38, line 4
| Kind | Length |Subtype| IPVer | Address ID | | Kind | Length |Subtype| IPVer | Address ID |
+---------------+---------------+-------+-------+---------------+ +---------------+---------------+-------+-------+---------------+
| Address (IPv4 - 4 octets / IPv6 - 16 octets) | | Address (IPv4 - 4 octets / IPv6 - 16 octets) |
+-------------------------------+-------------------------------+ +-------------------------------+-------------------------------+
| Port (2 octets, optional) | | Port (2 octets, optional) |
+-------------------------------+ +-------------------------------+
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 [15]. It is not host may attempt to advertise private addresses [17]. 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. Such advertisements must not, MAY want to advertise such addresses. The MP_JOIN handshake to
however, cause harm or security vulnerabilities. The standard create a new subflow (Section 3.2) provides mechanisms to minimise
mechanism to create a new subflow (Section 3.2) contains a 32 bit security risks. The MP_JOIN message contains a 32 bit token that
token that uniquely identifies the connection to the receiving host. uniquely identifies the connection to the receiving host. If the
If the token is unknown, the host will return with a RST. In the token is unknown, the host will return with a RST. In the unlikely
unlikely event that the token is known, subflow setup will continue, event that the token is known, subflow setup will continue, but the
but the HMAC exchange must occur for authentication. This will fail, HMAC exchange must occur for authentication. This will fail, and
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. address. Further security considerations around the issue of
accidental or maliciously misdirecting ADD_ADDR messages 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 38, line 8 skipping to change at page 39, line 10
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.
During normal MPTCP operation, it is unlikely that there will be During normal MPTCP operation, it is unlikely that there will be
sufficient TCP option space for ADD_ADDR to be included along with sufficient TCP option space for ADD_ADDR to be included along with
those for data sequence numbering (Section 3.3.1). Therefore, it is those for data sequence numbering (Section 3.3.1). Therefore, it is
expected that an MPTCP implementation will send the ADD_ADDR option expected that an MPTCP implementation will send the ADD_ADDR option
on separate ACKs. As discussed earlier, however, an MPTCP on separate ACKs. As discussed earlier, however, an MPTCP
implementation MUST NOT treat duplicate ACKs with any MPTCP option, implementation MUST NOT treat duplicate ACKs with any MPTCP option,
with the exception of the DSS option, as indications of congestion with the exception of the DSS option, as indications of congestion
[10], and an MPTCP implementation SHOULD NOT send more than two [11], and an MPTCP implementation SHOULD NOT send more than two
duplicate ACKs in a row for signaling purposes. duplicate ACKs in a row for signaling purposes.
3.4.2. Remove Address 3.4.2. Remove Address
If, during the lifetime of an MPTCP connection, a previously- If, during the lifetime of an MPTCP connection, a previously-
announced address becomes invalid (e.g. if the interface disappears), announced address becomes invalid (e.g. if the interface disappears),
the affected host SHOULD announce this so that the peer can remove the affected host SHOULD announce this so that the peer can remove
subflows related to this address. subflows related to this address.
This is achieved through the Remove Address (REMOVE_ADDR) option This is achieved through the Remove Address (REMOVE_ADDR) option
(Figure 13), which will remove a previously-added address (or list of (Figure 13), which will remove a previously-added address (or list of
addresses) from a connection and terminate any subflows currently addresses) from a connection and terminate any subflows currently
using that address. using that address.
For security purposes, if a host receives a REMOVE_ADDR option, it For security purposes, if a host receives a REMOVE_ADDR option, it
must ensure the affected path(s) are no longer in use before it must ensure the affected path(s) are no longer in use before it
instigates closure. The receipt of REMOVE_ADDR SHOULD first trigger instigates closure. The receipt of REMOVE_ADDR SHOULD first trigger
the sending of a TCP Keepalive [16] on the path, and if a response is the sending of a TCP Keepalive [18] on the path, and if a response is
received the path SHOULD NOT be removed. Typical TCP validity tests received the path SHOULD NOT be removed. Typical TCP validity tests
on the subflow (e.g. ensuring sequence and ack numbers are correct) on the subflow (e.g. ensuring sequence and ack numbers are correct)
MUST also be undertaken. An implementation can use indications of MUST also be undertaken. An implementation can use indications of
these test failures as part of intrusion detection or error logging. these test failures as part of intrusion detection or error logging.
The sending and receipt (if no keepalive response was received) of The sending and receipt (if no keepalive response was received) of
this message SHOULD trigger the sending of RSTs by both hosts on the this message SHOULD trigger the sending of RSTs by both hosts on the
affected subflow(s) (if possible), as a courtesy to cleaning up affected subflow(s) (if possible), as a courtesy to cleaning up
middlebox state, before cleaning up any local state. middlebox state, before cleaning up any local state.
skipping to change at page 44, line 45 skipping to change at page 45, line 45
This strategy is intended to maximize the probability of the SYN This strategy is intended to maximize the probability of the SYN
being permitted by a firewall or NAT at the recipient and to avoid being permitted by a firewall or NAT at the recipient and to avoid
confusing any network monitoring software. confusing any network monitoring software.
There may also be cases, however, where the passive opener wishes to There may also be cases, however, where the passive opener wishes to
signal to the other host that a specific port should be used, and signal to the other host that a specific port should be used, and
this facility is provided in the Add Address option as documented in this facility is provided in the Add Address option as documented in
Section 3.4.1. It is therefore feasible to allow multiple subflows Section 3.4.1. It is therefore feasible to allow multiple subflows
between the same two addresses but using different port pairs, and between the same two addresses but using different port pairs, and
such a facility could be used to allow load balancing within the such a facility could be used to allow load balancing within the
network based on 5-tuples (e.g. some ECMP implementations). network based on 5-tuples (e.g. some ECMP implementations [7]).
3.8.2. Delayed Subflow Start 3.8.2. Delayed Subflow Start
Many TCP connections are short-lived and consist only of a few Many TCP connections are short-lived and consist only of a few
segments, and so the overheads of using MPTCP outweigh any benefits. segments, and so the overheads of using MPTCP outweigh any benefits.
A heuristic is required, therefore, to decide when to start using A heuristic is required, therefore, to decide when to start using
additional subflows in an MPTCP connection. We expect that additional subflows in an MPTCP connection. We expect that
experience gathered from deployments will provide further guidance on experience gathered from deployments will provide further guidance on
this, and will be affected by particular application characteristics this, and will be affected by particular application characteristics
(which are likely to change over time). However, a suggested (which are likely to change over time). However, a suggested
skipping to change at page 47, line 40 skipping to change at page 48, line 40
5-tuple: The 5-tuple (protocol, local address, local port, remote 5-tuple: The 5-tuple (protocol, local address, local port, remote
address, remote port) presented by kernel APIs to the application address, remote port) presented by kernel APIs to the application
layer in a non-multipath-aware application is that of the first layer in a non-multipath-aware application is that of the first
subflow, even if the subflow has since been closed and removed subflow, even if the subflow has since been closed and removed
from the connection. This decision, and other related API issues, from the connection. This decision, and other related API issues,
are discussed in more detail in [6]. are discussed in more detail in [6].
5. Security Considerations 5. Security Considerations
As identified in [7], the addition of multipath capability to TCP As identified in [8], the addition of multipath capability to TCP
will bring with it a number of new classes of threat. In order to will bring with it a number of new classes of threat. In order to
prevent these, [2] presents a set of requirements for a security prevent these, [2] presents a set of requirements for a security
solution for MPTCP. The fundamental goal is for the security of solution for MPTCP. The fundamental goal is for the security of
MPTCP to be "no worse" than regular TCP today, and the key security MPTCP to be "no worse" than regular TCP today, and the key security
requirements are: requirements are:
o Provide a mechanism to confirm that the parties in a subflow o Provide a mechanism to confirm that the parties in a subflow
handshake are the same as in the original connection setup. handshake are the same as in the original connection setup.
o Provide verification that the peer can receive traffic at a new o Provide verification that the peer can receive traffic at a new
skipping to change at page 48, line 28 skipping to change at page 49, line 28
cryptographic material, future subflows use a truncated cryptographic cryptographic material, future subflows use a truncated cryptographic
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 (HMAC) used on subflow setup, in order to verify Authentication Codes (HMAC) used on subflow setup, in order to verify
that the parties in the handshake are the same as in the original that the parties in the handshake are the same as in the original
connection setup. It also provides verification that the peer can connection setup. It also provides verification that the peer can
receive traffic at this new address. Replay attacks would still be receive traffic at this new address. Replay attacks would still be
possible when only keys are used, and therefore the handshakes use possible when only keys are used, and therefore the handshakes use
single-use random numbers (nonces) at both ends - this ensures the single-use random numbers (nonces) at both ends - this ensures the
HMAC will never be the same on two handshakes. Guidance on HMAC will never be the same on two handshakes. Guidance on
generating random numbers suitable for use as keys is given in [12] generating random numbers suitable for use as keys is given in [13]
and discussed in Section 3.1. and discussed in Section 3.1.
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 would be additional crypto mechanisms in the future. Note that this would be
susceptible to bid-down attacks only if the attacker was on-path (and susceptible to bid-down attacks only if the attacker was on-path (and
thus would be able to modify the data anyway). The security thus would be able to modify the data anyway). The security
mechanism presented in this draft should therefore protect against mechanism presented in this draft should therefore protect against
all forms of flooding and hijacking attacks discussed in [7]. all forms of flooding and hijacking attacks discussed in [8].
During normal operation, regular TCP protection mechanisms (such as During normal operation, regular TCP protection mechanisms (such as
ensuring sequence numbers are in-window) will provide the same level ensuring sequence numbers are in-window) will provide the same level
of protection against attacks on indivudal TCP subflows as exists for of protection against attacks on indivudal TCP subflows as exists for
regular TCP today. Implementations will introduce additional buffers regular TCP today. Implementations will introduce additional buffers
compared to regular TCP, to reassemble data at the connection level. compared to regular TCP, to reassemble data at the connection level.
The application of window sizing will minimize the risk of denial-of- The application of window sizing will minimize the risk of denial-of-
service attacks consuming resources. service attacks consuming resources.
As discussed in Section 3.4.1, a host may advertise its private
addresses, but these might point to different hosts in the receiver's
network. The MP_JOIN handshake (Section 3.2) will ensure that this
does not succeed in setting up a subflow to the incorrect host.
However, it could still create unwanted TCP handshake traffic. This
feature of MPTCP could be a target for denial-of-service exploits,
with malicious participants in MPTCP connections encouraging the
recipient to target other hosts in the network. Therefore,
implementations should consider heuristics (Section 3.8) at both the
sender and receiver to reduce the impact of this.
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 analyis ([7]), since attacks only ever get worse, it is likely threat analyis ([8]), since attacks only ever get worse, it is likely
that a future standards-track version of MPTCP would need to be able that a future standards-track version of MPTCP would need to be able
to support stronger security. There are several ways the security of to support stronger security. There are several ways the security of
MPTCP could potentially be improved; some of these would be MPTCP could potentially be improved; some of these would be
compatible with MPTCP as defined in this document, whilst others may compatible with MPTCP as defined in this document, whilst others 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 threat current approach, establish what might work and check that the threat
analysis is still accurate. 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.
o defining how to secure data transfer with MPTCP, whilst not o defining how to secure data transfer with MPTCP, whilst not
changing the signalling part of the protocol. changing the signalling part of the protocol.
o defining security that requires more option space, perhaps in o defining security that requires more option space, perhaps in
conjunction with a "long options" proposal for extending the TCP conjunction with a "long options" proposal for extending the TCP
options space (such as those surveyed in [17]), or perhaps options space (such as those surveyed in [19]), or perhaps
building on the current approach with a second stage of MPTCP- building on the current approach with a second stage of MPTCP-
option-based security. option-based security.
o re-visiting the working group's decision to exclusively use TCP o re-visiting the working group's decision to exclusively use TCP
options for MPTCP signalling, and instead look at also making use options for MPTCP signalling, and instead look at also making use
of the TCP payloads. of the TCP payloads.
MPTCP has been designed with several methods available to indicate a MPTCP has been designed with several methods available to indicate a
new security mechanism, including: new security mechanism, including:
skipping to change at page 51, line 50 skipping to change at page 52, line 50
of some Data ACKs, but performance will degrade as the fraction of of some Data ACKs, but performance will degrade as the fraction of
stripped options increases. We do not expect such cases to appear in stripped options increases. We do not expect such cases to appear in
practice, though: most middleboxes will either strip all options or practice, though: most middleboxes will either strip all options or
let them all through. let them all through.
We end this section with a list of middlebox classes, their behaviour We end this section with a list of middlebox classes, their behaviour
and the elements in the MPTCP design that allow operation through and the elements in the MPTCP design that allow operation through
such middleboxes. Issues surrounding dropping packets with options such middleboxes. Issues surrounding dropping packets with options
or stripping options were discussed above, and are not included here: or stripping options were discussed above, and are not included here:
o NATs [18] (Network Address (and Port) Translators) change the o NATs [20] (Network Address (and Port) Translators) change the
source address (and often source port) of packets. This means source address (and often source port) of packets. This means
that a host will not know its public-facing address for signaling that a host will not know its public-facing address for signaling
in MPTCP. Therefore, MPTCP permits implicit address addition via in MPTCP. Therefore, MPTCP permits implicit address addition via
the MP_JOIN option, and the handshake mechanism ensures that the MP_JOIN option, and the handshake mechanism ensures that
connection attempts to private addresses [15] do not cause connection attempts to private addresses [17] do not cause
problems. Explicit address removal is undertaken by an Address ID problems. Explicit address removal is undertaken by an Address ID
to allow no knowledge of the source address. to allow no knowledge of the source address.
o Performance Enhancing Proxies (PEPs) [19] might pro-actively ACK o Performance Enhancing Proxies (PEPs) [21] might pro-actively ACK
data to increase performance. MPTCP, however, relies on accurate data to increase performance. MPTCP, however, relies on accurate
congestion control signals from the end host, and non-MPTCP-aware congestion control signals from the end host, and non-MPTCP-aware
PEPs will not be able to provide such signals. MPTCP will PEPs will not be able to provide such signals. MPTCP will
therefore fall back to single-path TCP, or close the problematic therefore fall back to single-path TCP, or close the problematic
subflow (see Section 3.6). subflow (see Section 3.6).
o Traffic Normalizers [20] may not allow holes in sequence numbers, o Traffic Normalizers [22] may not allow holes in sequence numbers,
and may cache packets and retransmit the same data. MPTCP looks and may cache packets and retransmit the same data. MPTCP looks
like standard TCP on the wire, and will not retransmit different like standard TCP on the wire, and will not retransmit different
data on the same subflow sequence number. In the event of a data on the same subflow sequence number. In the event of a
retransmission, the same data will be retransmitted on the retransmission, the same data will be retransmitted on the
original TCP subflow even if it is additionally retransmitted at original TCP subflow even if it is additionally retransmitted at
the connection-level on a different subflow. the connection-level on a different subflow.
o Firewalls [21] might perform initial sequence number randomization o Firewalls [23] might perform initial sequence number randomization
on TCP connections. MPTCP uses relative sequence numbers in data on TCP connections. MPTCP uses relative sequence numbers in data
sequence mapping to cope with this. Like NATs, firewalls will not sequence mapping to cope with this. Like NATs, firewalls will not
permit many incoming connections, so MPTCP supports address permit many incoming connections, so MPTCP supports address
signaling (ADD_ADDR) so that a multi-addressed host can invite its signaling (ADD_ADDR) so that a multi-addressed host can invite its
peer behind the firewall/NAT to connect out to its additional peer behind the firewall/NAT to connect out to its additional
interface. interface.
o Intrusion Detection Systems look out for traffic patterns and o Intrusion Detection Systems look out for traffic patterns and
content that could threaten a network. Multipath will mean that content that could threaten a network. Multipath will mean that
such data is potentially spread, so it is more difficult for an such data is potentially spread, so it is more difficult for an
skipping to change at page 53, line 38 skipping to change at page 54, line 38
Alan Ford was originally supported by Roke Manor Research. Alan Ford was originally supported by Roke Manor Research.
The authors gratefully acknowledge significant input into this The authors gratefully acknowledge significant input into this
document from Sebastien Barre, Christoph Paasch, and Andrew McDonald. document from Sebastien Barre, Christoph Paasch, 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, and Anumita Biswas. Andrew McGregor, Georg Hampel, Anumita Biswas, Wes Eddy, Alexey
Melnikov, Francis Dupont, Adrian Farrel, Barry Leiba, Robert Sparks,
Sean Turner, Stephen Farrell, and Martin Stiemerling.
8. IANA Considerations 8. IANA Considerations
This document defines a new TCP option for MPTCP, assigned a value of This document defines a new TCP option for MPTCP, assigned a value of
30 (decimal) from the TCP Option space. This value is the value of 30 (decimal) from the TCP Option space. This value is the value of
"Kind" as seen in all MPTCP options in this document. This value is "Kind" as seen in all MPTCP options in this document. This value is
defined as: defined as:
+------+--------+---------------+-----------------+ +------+--------+---------------+-----------------+
| Kind | Length | Meaning | Reference | | Kind | Length | Meaning | Reference |
+------+--------+---------------+-----------------+ +------+--------+---------------+-----------------+
| 30 | N | Multipath TCP | (This document) | | 30 | N | Multipath TCP | (This document) |
+------+--------+---------------+-----------------+ +------+--------+---------------+-----------------+
Table 1: TCP Option Kind Numbers Table 1: TCP Option Kind Numbers
This document also defines a four-bit subtype field, for which IANA This document also defines a four-bit subtype field, for which IANA
is to create and maintain a new sub-registry entitled "MPTCP option is to create and maintain a new sub-registry entitled "MPTCP option
subtype values" under the TCP Parameters registry. Initial values subtype values" under the TCP Parameters registry. Initial values
for the MPTCP option subtype registry are given below; future for the MPTCP option subtype registry are given below; future
assignments are to be defined by Standards Action as defined by [22]. assignments are to be defined by Standards Action as defined by [24].
Assignments consist of the MPTCP subtype's symbolic name and its Assignments consist of the MPTCP subtype's symbolic name and its
associated value, as per the following table. associated value, as per the following table.
+--------------+----------------------------+---------------+-------+ +--------------+----------------------------+---------------+-------+
| Symbol | Name | Reference | Value | | Symbol | Name | Reference | Value |
+--------------+----------------------------+---------------+-------+ +--------------+----------------------------+---------------+-------+
| MP_CAPABLE | Multipath Capable | Section 3.1 | 0x0 | | MP_CAPABLE | Multipath Capable | Section 3.1 | 0x0 |
| MP_JOIN | Join Connection | Section 3.2 | 0x1 | | MP_JOIN | Join Connection | Section 3.2 | 0x1 |
| DSS | Data Sequence Signal (Data | Section 3.3 | 0x2 | | DSS | Data Sequence Signal (Data | Section 3.3 | 0x2 |
| | ACK and Data Sequence | | | | | ACK and Data Sequence | | |
skipping to change at page 55, line 25 skipping to change at page 56, line 25
| H | HMAC-SHA1 | This document, Section 3.2 | | H | HMAC-SHA1 | This document, Section 3.2 |
+----------+-------------------+----------------------------+ +----------+-------------------+----------------------------+
Table 3: MPTCP Handshake Algorithms Table 3: MPTCP Handshake Algorithms
Note that the meanings of bits C through H can be dependent upon bit Note that the meanings of bits C through H can be dependent upon bit
B, depending on how Extensibility is defined in future B, depending on how Extensibility is defined in future
specifications; see Section 3.1 for more information. specifications; see Section 3.1 for more information.
Future assignments in this registry are also to be defined by Future assignments in this registry are also to be defined by
Standards Action as defined by [22]. Assignments consist of the Standards Action as defined by [24]. Assignments consist of the
value of the flags, a symbolic name for the algorithm, and a value of the flags, a symbolic name for the algorithm, and a
reference to its specification. reference to its specification.
9. References 9. References
9.1. Normative References 9.1. Normative References
[1] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, [1] Postel, J., "Transmission Control Protocol", STD 7, RFC 793,
September 1981. September 1981.
[2] Ford, A., Raiciu, C., Handley, M., Barre, S., and J. Iyengar, [2] Ford, A., Raiciu, C., Handley, M., Barre, S., and J. Iyengar,
"Architectural Guidelines for Multipath TCP Development", "Architectural Guidelines for Multipath TCP Development",
RFC 6182, March 2011. RFC 6182, March 2011.
[3] Bradner, S., "Key words for use in RFCs to Indicate Requirement [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997. Levels", BCP 14, RFC 2119, March 1997.
[4] Eastlake, D. and T. Hansen, "US Secure Hash Algorithms (SHA and [4] National Institute of Science and Technology, "Secure Hash
SHA-based HMAC and HKDF)", RFC 6234, May 2011. Standard", Federal Information Processing Standard
(FIPS) 180-3, October 2008, <http://csrc.nist.gov/publications/
fips/fips180-3/fips180-3_final.pdf>.
9.2. Informative References 9.2. Informative References
[5] Raiciu, C., Handley, M., and D. Wischik, "Coupled Congestion [5] Raiciu, C., Handley, M., and D. Wischik, "Coupled Congestion
Control for Multipath Transport Protocols", RFC 6356, Control for Multipath Transport Protocols", RFC 6356,
October 2011. October 2011.
[6] Scharf, M. and A. Ford, "MPTCP Application Interface [6] Scharf, M. and A. Ford, "MPTCP Application Interface
Considerations", draft-ietf-mptcp-api-05 (work in progress), Considerations", draft-ietf-mptcp-api-05 (work in progress),
April 2012. April 2012.
[7] Bagnulo, M., "Threat Analysis for TCP Extensions for Multipath [7] Hopps, C., "Analysis of an Equal-Cost Multi-Path Algorithm",
RFC 2992, November 2000.
[8] Bagnulo, M., "Threat Analysis for TCP Extensions for Multipath
Operation with Multiple Addresses", RFC 6181, March 2011. Operation with Multiple Addresses", RFC 6181, March 2011.
[8] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing [9] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing
for Message Authentication", RFC 2104, February 1997. for Message Authentication", RFC 2104, February 1997.
[9] Mathis, M., Mahdavi, J., Floyd, S., and A. Romanow, "TCP [10] Mathis, M., Mahdavi, J., Floyd, S., and A. Romanow, "TCP
Selective Acknowledgment Options", RFC 2018, October 1996. Selective Acknowledgment Options", RFC 2018, October 1996.
[10] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion [11] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion
Control", RFC 5681, September 2009. Control", RFC 5681, September 2009.
[11] Gont, F., "Survey of Security Hardening Methods for [12] Gont, F., "Survey of Security Hardening Methods for
Transmission Control Protocol (TCP) Implementations", Transmission Control Protocol (TCP) Implementations",
draft-ietf-tcpm-tcp-security-03 (work in progress), March 2012. draft-ietf-tcpm-tcp-security-03 (work in progress), March 2012.
[12] Eastlake, D., Schiller, J., and S. Crocker, "Randomness [13] Eastlake, D., Schiller, J., and S. Crocker, "Randomness
Requirements for Security", BCP 106, RFC 4086, June 2005. Requirements for Security", BCP 106, RFC 4086, June 2005.
[13] Jacobson, V., Braden, B., and D. Borman, "TCP Extensions for [14] Eastlake, D. and T. Hansen, "US Secure Hash Algorithms (SHA and
SHA-based HMAC and HKDF)", RFC 6234, May 2011.
[15] Jacobson, V., Braden, B., and D. Borman, "TCP Extensions for
High Performance", RFC 1323, May 1992. High Performance", RFC 1323, May 1992.
[14] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition of [16] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition of
Explicit Congestion Notification (ECN) to IP", RFC 3168, Explicit Congestion Notification (ECN) to IP", RFC 3168,
September 2001. September 2001.
[15] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and E. [17] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and E.
Lear, "Address Allocation for Private Internets", BCP 5, Lear, "Address Allocation for Private Internets", BCP 5,
RFC 1918, February 1996. RFC 1918, February 1996.
[16] Braden, R., "Requirements for Internet Hosts - Communication [18] Braden, R., "Requirements for Internet Hosts - Communication
Layers", STD 3, RFC 1122, October 1989. Layers", STD 3, RFC 1122, October 1989.
[17] Ramaiah, A., "TCP option space extension", [19] Ramaiah, A., "TCP option space extension",
draft-ananth-tcpm-tcpoptext-00 (work in progress), March 2012. draft-ananth-tcpm-tcpoptext-00 (work in progress), March 2012.
[18] Srisuresh, P. and K. Egevang, "Traditional IP Network Address [20] Srisuresh, P. and K. Egevang, "Traditional IP Network Address
Translator (Traditional NAT)", RFC 3022, January 2001. Translator (Traditional NAT)", RFC 3022, January 2001.
[19] Border, J., Kojo, M., Griner, J., Montenegro, G., and Z. [21] Border, J., Kojo, M., Griner, J., Montenegro, G., and Z.
Shelby, "Performance Enhancing Proxies Intended to Mitigate Shelby, "Performance Enhancing Proxies Intended to Mitigate
Link-Related Degradations", RFC 3135, June 2001. Link-Related Degradations", RFC 3135, June 2001.
[20] Handley, M., Paxson, V., and C. Kreibich, "Network Intrusion [22] Handley, M., Paxson, V., and C. Kreibich, "Network Intrusion
Detection: Evasion, Traffic Normalization, and End-to-End Detection: Evasion, Traffic Normalization, and End-to-End
Protocol Semantics", Usenix Security 2001, 2001, <http:// Protocol Semantics", Usenix Security 2001, 2001, <http://
www.usenix.org/events/sec01/full_papers/handley/handley.pdf>. www.usenix.org/events/sec01/full_papers/handley/handley.pdf>.
[21] Freed, N., "Behavior of and Requirements for Internet [23] Freed, N., "Behavior of and Requirements for Internet
Firewalls", RFC 2979, October 2000. Firewalls", RFC 2979, October 2000.
[22] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA [24] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
Considerations Section in RFCs", BCP 26, RFC 5226, May 2008. Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
Appendix A. Notes on use of TCP Options Appendix A. Notes on use of TCP Options
The TCP option space is limited due to the length of the Data Offset The TCP option space is limited due to the length of the Data Offset
field in the TCP header (4 bits), which defines the TCP header length field in the TCP header (4 bits), which defines the TCP header length
in 32 bit words. With the standard TCP header being 20 bytes, this in 32 bit words. With the standard TCP header being 20 bytes, this
leaves a maximum of 40 bytes for options, and many of these may leaves a maximum of 40 bytes for options, and many of these may
already be used by options such as timestamp and SACK. already be used by options such as timestamp and SACK.
 End of changes. 69 change blocks. 
161 lines changed or deleted 201 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/