draft-ietf-mptcp-rfc6824bis-14.txt   draft-ietf-mptcp-rfc6824bis-15.txt 
Internet Engineering Task Force A. Ford Internet Engineering Task Force A. Ford
Internet-Draft Pexip Internet-Draft Pexip
Obsoletes: 6824 (if approved) C. Raiciu Obsoletes: 6824 (if approved) C. Raiciu
Intended status: Standards Track U. Politechnica of Bucharest Intended status: Standards Track U. Politechnica of Bucharest
Expires: November 4, 2019 M. Handley Expires: November 9, 2019 M. Handley
U. College London U. College London
O. Bonaventure O. Bonaventure
U. catholique de Louvain U. catholique de Louvain
C. Paasch C. Paasch
Apple, Inc. Apple, Inc.
May 3, 2019 May 8, 2019
TCP Extensions for Multipath Operation with Multiple Addresses TCP Extensions for Multipath Operation with Multiple Addresses
draft-ietf-mptcp-rfc6824bis-14 draft-ietf-mptcp-rfc6824bis-15
Abstract Abstract
TCP/IP communication is currently restricted to a single path per TCP/IP communication is currently restricted to a single path per
connection, yet multiple paths often exist between peers. The connection, yet multiple paths often exist between peers. The
simultaneous use of these multiple paths for a TCP/IP session would simultaneous use of these multiple paths for a TCP/IP session would
improve resource usage within the network and, thus, improve user improve resource usage within the network and, thus, improve user
experience through higher throughput and improved resilience to experience through higher throughput and improved resilience to
network failure. network failure.
skipping to change at page 2, line 7 skipping to change at page 2, line 7
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on November 4, 2019. This Internet-Draft will expire on November 9, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 14, line 42 skipping to change at page 14, line 42
created when either end is behind a NAT, MPTCP uses the ADD_ADDR created when either end is behind a NAT, MPTCP uses the ADD_ADDR
message. 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. This is discussed in Section 3.7. middlebox alters the payload. This is discussed in Section 3.7.
o To address the threats identified in [RFC6181], the following o To address the threats identified in [RFC6181], the following
steps are taken: keys are sent in the clear in the MP_CAPABLE steps are taken: keys are sent in the clear in the MP_CAPABLE
messages; MP_JOIN messages are secured with HMAC-SHA256 messages; MP_JOIN messages are secured with HMAC-SHA256
([RFC2104], [SHS]) using those keys; and standard TCP validity ([RFC2104], [RFC6234]) using those keys; and standard TCP validity
checks are made on the other messages (ensuring sequence numbers checks are made on the other messages (ensuring sequence numbers
are in-window [RFC5961]). Residual threats to MPTCP v0 were are in-window [RFC5961]). Residual threats to MPTCP v0 were
identified in [RFC7430], and those affecting the protocol (i.e. identified in [RFC7430], and those affecting the protocol (i.e.
modification to ADD_ADDR) have been incorporated in this document. modification to ADD_ADDR) have been incorporated in this document.
Further discussion of security can be found in Section 5. Further discussion of security can be found in Section 5.
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.
skipping to change at page 21, line 22 skipping to change at page 21, line 22
through "G" to 0. through "G" to 0.
A crypto algorithm MUST be specified. If flag bits D through H are A crypto algorithm MUST be specified. If flag bits D through H are
all 0, the MP_CAPABLE option MUST be treated as invalid and ignored all 0, the MP_CAPABLE option MUST be treated as invalid and ignored
(that is, it must be treated as a regular TCP handshake). (that is, it must be treated as a regular TCP handshake).
The selection of the authentication algorithm also impacts the The selection of the authentication algorithm also impacts the
algorithm used to generate the token and the Initial Data Sequence algorithm used to generate the token and the Initial Data Sequence
Number (IDSN). In this specification, with only the SHA-256 Number (IDSN). In this specification, with only the SHA-256
algorithm (bit "H") specified and selected, the token MUST be a algorithm (bit "H") specified and selected, the token MUST be a
truncated (most significant 32 bits) SHA-256 hash ([SHS], [RFC6234]) truncated (most significant 32 bits) SHA-256 hash ([RFC6234]) of the
of the key. A different, 64-bit truncation (the least significant 64 key. A different, 64-bit truncation (the least significant 64 bits)
bits) of the SHA-256 hash of the key MUST be used as the IDSN. Note of the SHA-256 hash of the key MUST be used as the IDSN. Note that
that the key MUST be hashed in network byte order. Also note that the key MUST be hashed in network byte order. Also note that the
the "least significant" bits MUST be the rightmost bits of the "least significant" bits MUST be the rightmost bits of the SHA-256
SHA-256 digest, as per [SHS]. Future specifications of the use of digest, as per [RFC6234]. Future specifications of the use of the
the crypto bits may choose to specify different algorithms for token crypto bits may choose to specify different algorithms for token and
and IDSN generation. 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 (labeled "A"), if either host ways. For the Checksum Required bit (labeled "A"), if either host
requires the use of checksums, checksums MUST be used. In other requires the use of checksums, checksums MUST be used. In other
words, the only way for checksums not to be used is if both hosts in words, the only way for checksums not to be used is if both hosts in
their SYNs set A=0. This decision is confirmed by the setting of the their SYNs set A=0. This decision is confirmed by the setting of the
"A" bit in the third packet (the ACK) of the handshake. For example, "A" bit in the third packet (the ACK) of the handshake. For example,
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 23, line 35 skipping to change at page 23, line 35
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-256 ([SHS], tokens presented in this option are generated by the SHA-256
[RFC6234]) algorithm, truncated to the most significant 32 bits. The [RFC6234] algorithm, truncated to the most significant 32 bits. The
token included in the MP_JOIN option is the token that the receiver token included in the MP_JOIN option is the token that the receiver
of the packet uses to identify this connection; i.e., Host A will of the packet uses to identify this connection; i.e., Host A will
send 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 sends not only the token (which is static for a The MP_JOIN SYN sends not only 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. Recommendations for the replay attacks on the authentication method. Recommendations for the
generation of random numbers for this purpose are given in [RFC4086]. generation of random numbers for this purpose are given in [RFC4086].
skipping to change at page 25, line 17 skipping to change at page 25, line 17
protection against blind state exhaustion attacks; therefore, there protection against blind state exhaustion attacks; therefore, there
is no need to provide mechanisms to allow a responder to operate is no need to provide mechanisms to allow a responder to operate
statelessly at the MP_JOIN stage. statelessly at the MP_JOIN stage.
An HMAC is sent by both hosts -- by the initiator (Host A) in the An HMAC is sent by both hosts -- by the initiator (Host A) in the
third packet (the ACK) and by the responder (Host B) in the second third packet (the ACK) and by the responder (Host B) in the second
packet (the SYN/ACK). Doing the HMAC exchange at this stage allows packet (the SYN/ACK). Doing the HMAC exchange at this stage allows
both hosts to have first exchanged random data (in the first two SYN both hosts to have first exchanged random data (in the first two SYN
packets) that is used as the "message". This specification defines packets) that is used as the "message". This specification defines
that HMAC as defined in [RFC2104] is used, along with the SHA-256 that HMAC as defined in [RFC2104] is used, along with the SHA-256
hash algorithm [SHS] (potentially implemented as in [RFC6234]), thus hash algorithm [RFC6234], thus generating a 160-bit / 20-octet HMAC.
generating a 160-bit / 20-octet HMAC. Due to option space Due to option space limitations, the HMAC included in the SYN/ACK is
limitations, the HMAC included in the SYN/ACK is truncated to the truncated to the leftmost 64 bits, but this is acceptable since
leftmost 64 bits, but this is acceptable since random numbers are random numbers are used; thus, an attacker only has one chance to
used; thus, an attacker only has one chance to guess the HMAC guess the HMAC correctly (if the HMAC is incorrect, the TCP
correctly (if the HMAC is incorrect, the TCP connection is closed, so connection is closed, so a new MP_JOIN negotiation with a new random
a new MP_JOIN negotiation with a new random number is required). number is required).
The initiator's authentication information is sent in its first ACK The initiator's authentication information is sent in its first ACK
(the third packet of the handshake), as shown in Figure 7. This data (the third packet of the handshake), as shown in Figure 7. This data
needs to be sent reliably, since it is the only time this HMAC is needs to be sent reliably, since it is the only time this HMAC is
sent; therefore, receipt of this packet MUST trigger a regular TCP sent; therefore, receipt of this packet MUST trigger a regular TCP
ACK in response, and the packet MUST be retransmitted if this ACK is ACK in response, and the packet MUST be retransmitted if this ACK is
not received. In other words, sending the ACK/MP_JOIN packet places not received. In other words, sending the ACK/MP_JOIN packet places
the subflow in the PRE_ESTABLISHED state, and it moves to the the subflow in the PRE_ESTABLISHED state, and it moves to the
ESTABLISHED state only on receipt of an ACK from the receiver. It is ESTABLISHED state only on receipt of an ACK from the receiver. It is
not permitted to send data while in the PRE_ESTABLISHED state. The not permitted to send data while in the PRE_ESTABLISHED state. The
skipping to change at page 43, line 6 skipping to change at page 43, line 6
the explicit specification of a different port is required. If no the explicit specification of a different port is required. If no
port is specified, MPTCP SHOULD attempt to connect to the specified port is specified, MPTCP SHOULD attempt to connect to the specified
address on the same port as is already in use by the subflow on which address on the same port as is already in use by the subflow on which
the ADD_ADDR signal was sent; this is discussed in more detail in the ADD_ADDR signal was sent; this is discussed in more detail in
Section 3.9. Section 3.9.
The Truncated HMAC present in this Option is the rightmost 64 bits of The Truncated HMAC present in this Option is the rightmost 64 bits of
an HMAC, negotiated and calculated in the same way as for MP_JOIN as an HMAC, negotiated and calculated in the same way as for MP_JOIN as
described in Section 3.2. For this specification of MPTCP, as there described in Section 3.2. For this specification of MPTCP, as there
is only one hash algorithm option specified, this will be HMAC as is only one hash algorithm option specified, this will be HMAC as
defined in [RFC2104], using the SHA-256 hash algorithm [SHS], defined in [RFC2104], using the SHA-256 hash algorithm [RFC6234]. In
implemented as in [RFC6234]. In the same way as for MP_JOIN, the key the same way as for MP_JOIN, the key for the HMAC algorithm, in the
for the HMAC algorithm, in the case of the message transmitted by case of the message transmitted by Host A, will be Key-A followed by
Host A, will be Key-A followed by Key-B, and in the case of Host B, Key-B, and in the case of Host B, Key-B followed by Key-A. These are
Key-B followed by Key-A. These are the keys that were exchanged in the keys that were exchanged in the original MP_CAPABLE handshake.
the original MP_CAPABLE handshake. The message for the HMAC is the The message for the HMAC is the Address ID, IP Address, and Port
Address ID, IP Address, and Port which precede the HMAC in the which precede the HMAC in the ADD_ADDR option. If the port is not
ADD_ADDR option. If the port is not present in the ADD_ADDR option, present in the ADD_ADDR option, the HMAC message will nevertheless
the HMAC message will nevertheless include two octets of value zero. include two octets of value zero. The rationale for the HMAC is to
The rationale for the HMAC is to prevent unauthorized entities from prevent unauthorized entities from injecting ADD_ADDR signals in an
injecting ADD_ADDR signals in an attempt to hijack a connection. attempt to hijack a connection. Note that additionally the presence
Note that additionally the presence of this HMAC prevents the address of this HMAC prevents the address being changed in flight unless the
being changed in flight unless the key is known by an intermediary. key is known by an intermediary. If a host receives an ADD_ADDR
If a host receives an ADD_ADDR option for which it cannot validate option for which it cannot validate the HMAC, it SHOULD silently
the HMAC, it SHOULD silently ignore the option. ignore the option.
A set of four flags are present after the subtype and before the A set of four flags are present after the subtype and before the
Address ID. Only the rightmost bit - labelled 'E' - is assigned in Address ID. Only the rightmost bit - labelled 'E' - is assigned in
this specification. The other bits are currently unassigned and MUST this specification. The other bits are currently unassigned and MUST
be set to zero by a sender and MUST be ignored by the receiver. be set to zero by a sender and MUST be ignored by the receiver.
The 'E' flag exists to provide reliability for this option. Because The 'E' flag exists to provide reliability for this option. Because
this option will often be sent on pure ACKs, there is no guarantee of this option will often be sent on pure ACKs, there is no guarantee of
reliability. Therefore, a receiver receiving a fresh ADD_ADDR option reliability. Therefore, a receiver receiving a fresh ADD_ADDR option
(where E=0), will send the same option back to the sender, but not (where E=0), will send the same option back to the sender, but not
skipping to change at page 66, line 38 skipping to change at page 66, line 38
Table 4: MPTCP MP_TCPRST Reason Codes Table 4: MPTCP MP_TCPRST Reason Codes
9. References 9. References
9.1. Normative References 9.1. Normative References
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, [RFC0793] Postel, J., "Transmission Control Protocol", STD 7,
RFC 793, DOI 10.17487/RFC0793, September 1981, RFC 793, DOI 10.17487/RFC0793, September 1981,
<https://www.rfc-editor.org/info/rfc793>. <https://www.rfc-editor.org/info/rfc793>.
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
Hashing for Message Authentication", RFC 2104,
DOI 10.17487/RFC2104, February 1997, <https://www.rfc-
editor.org/info/rfc2104>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, <https://www.rfc- DOI 10.17487/RFC2119, March 1997, <https://www.rfc-
editor.org/info/rfc2119>. editor.org/info/rfc2119>.
[RFC5961] Ramaiah, A., Stewart, R., and M. Dalal, "Improving TCP's
Robustness to Blind In-Window Attacks", RFC 5961,
DOI 10.17487/RFC5961, August 2010, <https://www.rfc-
editor.org/info/rfc5961>.
[RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms
(SHA and SHA-based HMAC and HKDF)", RFC 6234,
DOI 10.17487/RFC6234, May 2011, <https://www.rfc-
editor.org/info/rfc6234>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[SHS] National Institute of Science and Technology, "Secure Hash
Standard", Federal Information Processing Standard
(FIPS) 180-4, August 2015,
<http://nvlpubs.nist.gov/nistpubs/FIPS/
NIST.FIPS.180-4.pdf>.
9.2. Informative References 9.2. Informative References
[deployments] [deployments]
Bonaventure, O. and S. Seo, "Multipath TCP Deployments", Bonaventure, O. and S. Seo, "Multipath TCP Deployments",
IETF Journal 2016, November 2016, IETF Journal 2016, November 2016,
<https://www.ietfjournal.org/multipath-tcp-deployments/>. <https://www.ietfjournal.org/multipath-tcp-deployments/>.
[howhard] Raiciu, C., Paasch, C., Barre, S., Ford, A., Honda, M., [howhard] Raiciu, C., Paasch, C., Barre, S., Ford, A., Honda, M.,
Duchene, F., Bonaventure, O., and M. Handley, "How Hard Duchene, F., Bonaventure, O., and M. Handley, "How Hard
Can It Be? Designing and Implementing a Deployable Can It Be? Designing and Implementing a Deployable
skipping to change at page 67, line 42 skipping to change at page 68, line 5
[RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G.,
and E. Lear, "Address Allocation for Private Internets", and E. Lear, "Address Allocation for Private Internets",
BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996, BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996,
<https://www.rfc-editor.org/info/rfc1918>. <https://www.rfc-editor.org/info/rfc1918>.
[RFC2018] Mathis, M., Mahdavi, J., Floyd, S., and A. Romanow, "TCP [RFC2018] Mathis, M., Mahdavi, J., Floyd, S., and A. Romanow, "TCP
Selective Acknowledgment Options", RFC 2018, Selective Acknowledgment Options", RFC 2018,
DOI 10.17487/RFC2018, October 1996, <https://www.rfc- DOI 10.17487/RFC2018, October 1996, <https://www.rfc-
editor.org/info/rfc2018>. editor.org/info/rfc2018>.
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
Hashing for Message Authentication", RFC 2104,
DOI 10.17487/RFC2104, February 1997, <https://www.rfc-
editor.org/info/rfc2104>.
[RFC2979] Freed, N., "Behavior of and Requirements for Internet [RFC2979] Freed, N., "Behavior of and Requirements for Internet
Firewalls", RFC 2979, DOI 10.17487/RFC2979, October 2000, Firewalls", RFC 2979, DOI 10.17487/RFC2979, October 2000,
<https://www.rfc-editor.org/info/rfc2979>. <https://www.rfc-editor.org/info/rfc2979>.
[RFC2992] Hopps, C., "Analysis of an Equal-Cost Multi-Path [RFC2992] Hopps, C., "Analysis of an Equal-Cost Multi-Path
Algorithm", RFC 2992, DOI 10.17487/RFC2992, November 2000, Algorithm", RFC 2992, DOI 10.17487/RFC2992, November 2000,
<https://www.rfc-editor.org/info/rfc2992>. <https://www.rfc-editor.org/info/rfc2992>.
[RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network
Address Translator (Traditional NAT)", RFC 3022, Address Translator (Traditional NAT)", RFC 3022,
skipping to change at page 68, line 33 skipping to change at page 68, line 37
editor.org/info/rfc4086>. editor.org/info/rfc4086>.
[RFC4987] Eddy, W., "TCP SYN Flooding Attacks and Common [RFC4987] Eddy, W., "TCP SYN Flooding Attacks and Common
Mitigations", RFC 4987, DOI 10.17487/RFC4987, August 2007, Mitigations", RFC 4987, DOI 10.17487/RFC4987, August 2007,
<https://www.rfc-editor.org/info/rfc4987>. <https://www.rfc-editor.org/info/rfc4987>.
[RFC5681] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion [RFC5681] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion
Control", RFC 5681, DOI 10.17487/RFC5681, September 2009, Control", RFC 5681, DOI 10.17487/RFC5681, September 2009,
<https://www.rfc-editor.org/info/rfc5681>. <https://www.rfc-editor.org/info/rfc5681>.
[RFC5961] Ramaiah, A., Stewart, R., and M. Dalal, "Improving TCP's
Robustness to Blind In-Window Attacks", RFC 5961,
DOI 10.17487/RFC5961, August 2010, <https://www.rfc-
editor.org/info/rfc5961>.
[RFC6181] Bagnulo, M., "Threat Analysis for TCP Extensions for [RFC6181] Bagnulo, M., "Threat Analysis for TCP Extensions for
Multipath Operation with Multiple Addresses", RFC 6181, Multipath Operation with Multiple Addresses", RFC 6181,
DOI 10.17487/RFC6181, March 2011, <https://www.rfc- DOI 10.17487/RFC6181, March 2011, <https://www.rfc-
editor.org/info/rfc6181>. editor.org/info/rfc6181>.
[RFC6182] Ford, A., Raiciu, C., Handley, M., Barre, S., and J. [RFC6182] Ford, A., Raiciu, C., Handley, M., Barre, S., and J.
Iyengar, "Architectural Guidelines for Multipath TCP Iyengar, "Architectural Guidelines for Multipath TCP
Development", RFC 6182, DOI 10.17487/RFC6182, March 2011, Development", RFC 6182, DOI 10.17487/RFC6182, March 2011,
<https://www.rfc-editor.org/info/rfc6182>. <https://www.rfc-editor.org/info/rfc6182>.
[RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms
(SHA and SHA-based HMAC and HKDF)", RFC 6234,
DOI 10.17487/RFC6234, May 2011, <https://www.rfc-
editor.org/info/rfc6234>.
[RFC6356] Raiciu, C., Handley, M., and D. Wischik, "Coupled [RFC6356] Raiciu, C., Handley, M., and D. Wischik, "Coupled
Congestion Control for Multipath Transport Protocols", Congestion Control for Multipath Transport Protocols",
RFC 6356, DOI 10.17487/RFC6356, October 2011, RFC 6356, DOI 10.17487/RFC6356, October 2011,
<https://www.rfc-editor.org/info/rfc6356>. <https://www.rfc-editor.org/info/rfc6356>.
[RFC6528] Gont, F. and S. Bellovin, "Defending against Sequence [RFC6528] Gont, F. and S. Bellovin, "Defending against Sequence
Number Attacks", RFC 6528, DOI 10.17487/RFC6528, February Number Attacks", RFC 6528, DOI 10.17487/RFC6528, February
2012, <https://www.rfc-editor.org/info/rfc6528>. 2012, <https://www.rfc-editor.org/info/rfc6528>.
[RFC6897] Scharf, M. and A. Ford, "Multipath TCP (MPTCP) Application [RFC6897] Scharf, M. and A. Ford, "Multipath TCP (MPTCP) Application
skipping to change at page 79, line 5 skipping to change at page 79, line 5
documents "Use Cases and Operational Experience with Multipath documents "Use Cases and Operational Experience with Multipath
TCP" [RFC8041] and the IETF Journal article "Multipath TCP TCP" [RFC8041] and the IETF Journal article "Multipath TCP
Deployments" [deployments]. Deployments" [deployments].
o Connection initiation, through the exchange of the MP_CAPABLE o Connection initiation, through the exchange of the MP_CAPABLE
MPTCP option, is different from RFC6824. The SYN no longer MPTCP option, is different from RFC6824. The SYN no longer
includes the initiator's key, allowing the MP_CAPABLE option on includes the initiator's key, allowing the MP_CAPABLE option on
the SYN to be shorter in length, and to avoid duplicating the the SYN to be shorter in length, and to avoid duplicating the
sending of keying material. sending of keying material.
o This requires MP_CAPABLE to also be sent reliably on the third o This also ensures reliable delivery of the key on the MP_CAPABLE
ACK. If safe receipt of the third ACK cannot be inferred, the option by allowing its transmission to be combined with data and
MP_CAPABLE option must be repeated on the first data packet. thus using TCP's in-built reliability mechanism. If the initiator
does not immediately have data to send, the MP_CAPABLE option with
the keys will be repeated on the first data packet. If the other
end is first to send, then the presence of the DSS option
implicitly confirms the receipt of the MP_CAPABLE.
o In the Flags field of MP_CAPABLE, C is now assigned to mean that o In the Flags field of MP_CAPABLE, C is now assigned to mean that
the sender of this option will not accept additional MPTCP the sender of this option will not accept additional MPTCP
subflows to the source address and port. This is an efficiency subflows to the source address and port. This is an efficiency
improvement, for example where the sender is behind a strict NAT. improvement, for example where the sender is behind a strict NAT.
o In the Flags field of MP_CAPABLE, H now indicates the use of HMAC- o In the Flags field of MP_CAPABLE, H now indicates the use of HMAC-
SHA256 (rather than HMAC-SHA1). SHA256 (rather than HMAC-SHA1).
o Connection initiation also defines the procedure for version o Connection initiation also defines the procedure for version
 End of changes. 16 change blocks. 
61 lines changed or deleted 59 lines changed or added

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