--- 1/draft-ietf-mptcp-rfc6824bis-06.txt 2016-10-28 14:16:27.962839519 -0700 +++ 2/draft-ietf-mptcp-rfc6824bis-07.txt 2016-10-28 14:16:28.114843362 -0700 @@ -1,25 +1,25 @@ Internet Engineering Task Force A. Ford Internet-Draft Pexip Obsoletes: 6824 (if approved) C. Raiciu Intended status: Experimental U. Politechnica of Bucharest -Expires: January 7, 2017 M. Handley +Expires: May 1, 2017 M. Handley U. College London O. Bonaventure U. catholique de Louvain C. Paasch Apple, Inc. - July 6, 2016 + October 28, 2016 TCP Extensions for Multipath Operation with Multiple Addresses - draft-ietf-mptcp-rfc6824bis-06 + draft-ietf-mptcp-rfc6824bis-07 Abstract TCP/IP communication is currently restricted to a single path per connection, yet multiple paths often exist between peers. The simultaneous use of these multiple paths for a TCP/IP session would improve resource usage within the network and, thus, improve user experience through higher throughput and improved resilience to network failure. @@ -42,101 +42,101 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on January 7, 2017. + This Internet-Draft will expire on May 1, 2017. Copyright Notice Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents - 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 - 1.1. Design Assumptions . . . . . . . . . . . . . . . . . . . . 4 + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 + 1.1. Design Assumptions . . . . . . . . . . . . . . . . . . . 4 1.2. Multipath TCP in the Networking Stack . . . . . . . . . . 5 1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6 - 1.4. MPTCP Concept . . . . . . . . . . . . . . . . . . . . . . 7 + 1.4. MPTCP Concept . . . . . . . . . . . . . . . . . . . . . . 6 1.5. Requirements Language . . . . . . . . . . . . . . . . . . 8 - 2. Operation Overview . . . . . . . . . . . . . . . . . . . . . . 8 - 2.1. Initiating an MPTCP Connection . . . . . . . . . . . . . . 9 + 2. Operation Overview . . . . . . . . . . . . . . . . . . . . . 8 + 2.1. Initiating an MPTCP Connection . . . . . . . . . . . . . 8 2.2. Associating a New Subflow with an Existing MPTCP - Connection . . . . . . . . . . . . . . . . . . . . . . . . 9 - 2.3. Informing the Other Host about Another Potential - Address . . . . . . . . . . . . . . . . . . . . . . . . . 10 - 2.4. Data Transfer Using MPTCP . . . . . . . . . . . . . . . . 11 - 2.5. Requesting a Change in a Path's Priority . . . . . . . . . 11 - 2.6. Closing an MPTCP Connection . . . . . . . . . . . . . . . 12 - 2.7. Notable Features . . . . . . . . . . . . . . . . . . . . . 12 - 3. MPTCP Protocol . . . . . . . . . . . . . . . . . . . . . . . . 12 - 3.1. Connection Initiation . . . . . . . . . . . . . . . . . . 14 - 3.2. Starting a New Subflow . . . . . . . . . . . . . . . . . . 19 - 3.3. General MPTCP Operation . . . . . . . . . . . . . . . . . 24 + Connection . . . . . . . . . . . . . . . . . . . . . . . 9 + 2.3. Informing the Other Host about Another Potential Address 9 + 2.4. Data Transfer Using MPTCP . . . . . . . . . . . . . . . . 10 + 2.5. Requesting a Change in a Path's Priority . . . . . . . . 11 + 2.6. Closing an MPTCP Connection . . . . . . . . . . . . . . . 11 + 2.7. Notable Features . . . . . . . . . . . . . . . . . . . . 12 + 3. MPTCP Protocol . . . . . . . . . . . . . . . . . . . . . . . 12 + 3.1. Connection Initiation . . . . . . . . . . . . . . . . . . 13 + 3.2. Starting a New Subflow . . . . . . . . . . . . . . . . . 19 + 3.3. General MPTCP Operation . . . . . . . . . . . . . . . . . 25 3.3.1. Data Sequence Mapping . . . . . . . . . . . . . . . . 26 - 3.3.2. Data Acknowledgments . . . . . . . . . . . . . . . . . 29 - 3.3.3. Closing a Connection . . . . . . . . . . . . . . . . . 30 - 3.3.4. Receiver Considerations . . . . . . . . . . . . . . . 31 + 3.3.2. Data Acknowledgments . . . . . . . . . . . . . . . . 30 + 3.3.3. Closing a Connection . . . . . . . . . . . . . . . . 31 + 3.3.4. Receiver Considerations . . . . . . . . . . . . . . . 32 3.3.5. Sender Considerations . . . . . . . . . . . . . . . . 33 - 3.3.6. Reliability and Retransmissions . . . . . . . . . . . 33 + 3.3.6. Reliability and Retransmissions . . . . . . . . . . . 34 3.3.7. Congestion Control Considerations . . . . . . . . . . 35 - 3.3.8. Subflow Policy . . . . . . . . . . . . . . . . . . . . 35 - 3.4. Address Knowledge Exchange (Path Management) . . . . . . . 37 + 3.3.8. Subflow Policy . . . . . . . . . . . . . . . . . . . 36 + 3.4. Address Knowledge Exchange (Path Management) . . . . . . 37 3.4.1. Address Advertisement . . . . . . . . . . . . . . . . 38 - 3.4.2. Remove Address . . . . . . . . . . . . . . . . . . . . 41 - 3.5. Fast Close . . . . . . . . . . . . . . . . . . . . . . . . 42 - 3.6. Subflow Reset . . . . . . . . . . . . . . . . . . . . . . 43 - 3.7. MPTCP Experimental Option . . . . . . . . . . . . . . . . 45 - 3.8. Fallback . . . . . . . . . . . . . . . . . . . . . . . . . 46 - 3.9. Error Handling . . . . . . . . . . . . . . . . . . . . . . 50 - 3.10. Heuristics . . . . . . . . . . . . . . . . . . . . . . . . 50 - 3.10.1. Port Usage . . . . . . . . . . . . . . . . . . . . . . 51 - 3.10.2. Delayed Subflow Start and Subflow Symmetry . . . . . . 51 - 3.10.3. Failure Handling . . . . . . . . . . . . . . . . . . . 52 - 4. Semantic Issues . . . . . . . . . . . . . . . . . . . . . . . 53 - 5. Security Considerations . . . . . . . . . . . . . . . . . . . 54 + 3.4.2. Remove Address . . . . . . . . . . . . . . . . . . . 42 + 3.5. Fast Close . . . . . . . . . . . . . . . . . . . . . . . 43 + 3.6. Subflow Reset . . . . . . . . . . . . . . . . . . . . . . 44 + 3.7. MPTCP Experimental Option . . . . . . . . . . . . . . . . 46 + 3.8. Fallback . . . . . . . . . . . . . . . . . . . . . . . . 47 + 3.9. Error Handling . . . . . . . . . . . . . . . . . . . . . 51 + 3.10. Heuristics . . . . . . . . . . . . . . . . . . . . . . . 51 + 3.10.1. Port Usage . . . . . . . . . . . . . . . . . . . . . 51 + 3.10.2. Delayed Subflow Start and Subflow Symmetry . . . . . 52 + 3.10.3. Failure Handling . . . . . . . . . . . . . . . . . . 53 + 4. Semantic Issues . . . . . . . . . . . . . . . . . . . . . . . 54 + 5. Security Considerations . . . . . . . . . . . . . . . . . . . 55 6. Interactions with Middleboxes . . . . . . . . . . . . . . . . 57 - 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 60 - 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 60 - 8.1. MPTCP Option Subtypes . . . . . . . . . . . . . . . . . . 61 - 8.2. MPTCP Handshake Algorithms . . . . . . . . . . . . . . . . 62 - 8.3. MP_TCPRST Reason Codes . . . . . . . . . . . . . . . . . . 62 - 8.4. Experimental option registry . . . . . . . . . . . . . . . 63 - 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 63 - 9.1. Normative References . . . . . . . . . . . . . . . . . . . 63 - 9.2. Informative References . . . . . . . . . . . . . . . . . . 64 - Appendix A. Notes on Use of TCP Options . . . . . . . . . . . . . 66 - Appendix B. Control Blocks . . . . . . . . . . . . . . . . . . . 68 - B.1. MPTCP Control Block . . . . . . . . . . . . . . . . . . . 68 - B.1.1. Authentication and Metadata . . . . . . . . . . . . . 68 - B.1.2. Sending Side . . . . . . . . . . . . . . . . . . . . . 69 - B.1.3. Receiving Side . . . . . . . . . . . . . . . . . . . . 69 - B.2. TCP Control Blocks . . . . . . . . . . . . . . . . . . . . 69 - B.2.1. Sending Side . . . . . . . . . . . . . . . . . . . . . 69 - B.2.2. Receiving Side . . . . . . . . . . . . . . . . . . . . 70 - Appendix C. Finite State Machine . . . . . . . . . . . . . . . . 70 + 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 61 + 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 61 + 8.1. MPTCP Option Subtypes . . . . . . . . . . . . . . . . . . 62 + 8.2. MPTCP Handshake Algorithms . . . . . . . . . . . . . . . 63 + 8.3. MP_TCPRST Reason Codes . . . . . . . . . . . . . . . . . 63 + 8.4. Experimental option registry . . . . . . . . . . . . . . 64 + 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 64 + 9.1. Normative References . . . . . . . . . . . . . . . . . . 64 + 9.2. Informative References . . . . . . . . . . . . . . . . . 65 + Appendix A. Notes on Use of TCP Options . . . . . . . . . . . . 68 + Appendix B. Control Blocks . . . . . . . . . . . . . . . . . . . 69 + B.1. MPTCP Control Block . . . . . . . . . . . . . . . . . . . 70 + B.1.1. Authentication and Metadata . . . . . . . . . . . . . 70 + B.1.2. Sending Side . . . . . . . . . . . . . . . . . . . . 70 + B.1.3. Receiving Side . . . . . . . . . . . . . . . . . . . 70 + B.2. TCP Control Blocks . . . . . . . . . . . . . . . . . . . 71 + B.2.1. Sending Side . . . . . . . . . . . . . . . . . . . . 71 + B.2.2. Receiving Side . . . . . . . . . . . . . . . . . . . 71 + Appendix C. Finite State Machine . . . . . . . . . . . . . . . . 71 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 72 1. Introduction Multipath TCP (MPTCP) is a set of extensions to regular TCP [RFC0793] to provide a Multipath TCP [RFC6182] service, which enables a transport connection to operate across multiple paths simultaneously. This document presents the protocol changes required to add multipath capability to TCP; specifically, those for signaling and setting up multiple paths ("subflows"), managing these subflows, reassembly of data, and termination of sessions. This is not the only information @@ -776,21 +775,30 @@ B: The second bit, labeled "B", is an extensibility flag, and MUST be set to 0 for current implementations. This will be used for an extensibility mechanism in a future specification, and the impact of this flag will be defined at a later date. If receiving a message with the 'B' flag set to 1, and this is not understood, then this SYN MUST be silently ignored; the sender is expected to retry with a format compatible with this legacy specification. Note that the length of the MP_CAPABLE option, and the meanings of bits "C" through "H", may be altered by setting B=1. - C through H: The remaining bits, labeled "C" through "H", are used + C: The third bit, labeled "C", is set to "1" to indicate that the + sender of this option will not accept additional MPTCP subflows to + the source address and port, and therefore the receiver MUST NOT + try to open any additional subflows towards this address and port. + This is an efficiency improvement for situations where the sender + knows a restriction is in place, for example if the sender is + behind a strict NAT, or operating behind a legacy Layer 4 load + balancer. + + D through H: The remaining bits, labeled "C" through "H", are used for crypto algorithm negotiation. Currently only the rightmost bit, labeled "H", is assigned. Bit "H" indicates the use of HMAC- SHA1 (as defined in Section 3.2). An implementation that only supports this method MUST set bit "H" to 1, and bits "C" through "G" to 0. 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 (that is, it must be treated as a regular TCP handshake). @@ -1818,33 +1825,42 @@ ADD_ADDR option. If the port is not present in the ADD_ADDR option, the HMAC message will nevertheless include two octets of value zero. The rationale for the HMAC is to prevent unauthorized entities from injecting ADD_ADDR signals in an attempt to hijack a connection. Note that additionally the presence of this HMAC prevents the address being changed in flight unless the key is known by an intermediary. If a host receives an ADD_ADDR option for which it cannot validate the HMAC, it SHOULD silently ignore the option. A set of four flags are present after the subtype and before the - Address ID. These are currently unassigned and MUST be set to zero - by a sender and MUST be ignored by the receiver. + Address ID. Only the rightmost bit - labelled 'E' - is assinged + today. The other bits are currently unassigned and MUST be set to + zero by a sender and MUST be ignored by the receiver. + + The 'E' bit exists to provide reliability for this option. Because + this option will often be sent on pure ACKs, there is no guarantee of + reliability. Therefore, a receiver receiving a fresh ADD_ADDR option + (where E=0), will send the same option back to the sender, but not + including the HMAC, and with E=1. The lack of this echo can be used + by the initial ADD_ADDR sender to retransmit the ADD_ADDR according + to local policy. 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +---------------+---------------+-------+-------+---------------+ - | Kind | Length |Subtype|(resvd)| Address ID | + | Kind | Length |Subtype|(rsv)|E| Address ID | +---------------+---------------+-------+-------+---------------+ | Address (IPv4 - 4 octets / IPv6 - 16 octets) | +-------------------------------+-------------------------------+ | Port (2 octets, optional) | | +-------------------------------+ | - | Truncated HMAC (8 octets) | + | Truncated HMAC (8 octets, if length > 10 octets) | | +-------------------------------+ | | +-------------------------------+ Figure 12: Add Address (ADD_ADDR) Option Due to the proliferation of NATs, it is reasonably likely that one host may attempt to advertise private addresses [RFC1918]. It is not desirable to prohibit this, since there may be cases where both hosts have additional interfaces on the same private network, and a host @@ -2810,21 +2824,22 @@ The authors gratefully acknowledge significant input into this document from Sebastien Barre and Andrew McDonald. The authors also wish to acknowledge reviews and contributions from Iljitsch van Beijnum, Lars Eggert, Marcelo Bagnulo, Robert Hancock, Pasi Sarolahti, Toby Moncaster, Philip Eardley, Sergio Lembo, Lawrence Conroy, Yoshifumi Nishida, Bob Briscoe, Stein Gjessing, Andrew McGregor, Georg Hampel, Anumita Biswas, Wes Eddy, Alexey Melnikov, Francis Dupont, Adrian Farrel, Barry Leiba, Robert Sparks, - Sean Turner, Stephen Farrell, Martin Stiemerling, and Gregory Detal. + Sean Turner, Stephen Farrell, Martin Stiemerling, Gregory Detal, and + Fabien Duchene. 8. IANA Considerations This document updates [RFC6824] and as such IANA is requested to update the TCP option space registry to point to this document for Multipath TCP, as follows: +------+--------+-----------------------+---------------+ | Kind | Length | Meaning | Reference | +------+--------+-----------------------+---------------+ @@ -2954,53 +2969,69 @@ 9. References 9.1. Normative References [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, DOI 10.17487/RFC0793, September 1981, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate - Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ - RFC2119, March 1997, + Requirement Levels", BCP 14, RFC 2119, + DOI 10.17487/RFC2119, March 1997, . [RFC6182] Ford, A., Raiciu, C., Handley, M., Barre, S., and J. Iyengar, "Architectural Guidelines for Multipath TCP Development", RFC 6182, DOI 10.17487/RFC6182, March 2011, . [sha1] National Institute of Science and Technology, "Secure Hash Standard", Federal Information Processing Standard - (FIPS) 180-3, October 2008, . + (FIPS) 180-3, October 2008, + . 9.2. Informative References + [howhard] Raiciu, C., Paasch, C., Barre, S., Ford, A., Honda, M., + Duchene, F., Bonaventure, O., and M. Handley, "How Hard + Can It Be? Designing and Implementing a Deployable + Multipath TCP", Usenix Symposium on Networked Systems + Design and Implementation 2012, 2012, + . + + [norm] Handley, M., Paxson, V., and C. Kreibich, "Network + Intrusion Detection: Evasion, Traffic Normalization, and + End-to-End Protocol Semantics", Usenix Security 2001, + 2001, + . + [RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - - Communication Layers", STD 3, RFC 1122, DOI 10.17487/ - RFC1122, October 1989, + Communication Layers", STD 3, RFC 1122, + DOI 10.17487/RFC1122, October 1989, . [RFC1323] Jacobson, V., Braden, R., and D. Borman, "TCP Extensions - for High Performance", RFC 1323, DOI 10.17487/RFC1323, - May 1992, . + for High Performance", RFC 1323, DOI 10.17487/RFC1323, May + 1992, . [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996, . [RFC2018] Mathis, M., Mahdavi, J., Floyd, S., and A. Romanow, "TCP - Selective Acknowledgment Options", RFC 2018, DOI 10.17487/ - RFC2018, October 1996, + Selective Acknowledgment Options", RFC 2018, + DOI 10.17487/RFC2018, October 1996, . [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- Hashing for Message Authentication", RFC 2104, DOI 10.17487/RFC2104, February 1997, . [RFC2979] Freed, N., "Behavior of and Requirements for Internet Firewalls", RFC 2979, DOI 10.17487/RFC2979, October 2000, . @@ -3057,54 +3088,39 @@ (SHA and SHA-based HMAC and HKDF)", RFC 6234, DOI 10.17487/RFC6234, May 2011, . [RFC6356] Raiciu, C., Handley, M., and D. Wischik, "Coupled Congestion Control for Multipath Transport Protocols", RFC 6356, DOI 10.17487/RFC6356, October 2011, . [RFC6528] Gont, F. and S. Bellovin, "Defending against Sequence - Number Attacks", RFC 6528, DOI 10.17487/RFC6528, - February 2012, . + Number Attacks", RFC 6528, DOI 10.17487/RFC6528, February + 2012, . [RFC6824] Ford, A., Raiciu, C., Handley, M., and O. Bonaventure, "TCP Extensions for Multipath Operation with Multiple Addresses", RFC 6824, DOI 10.17487/RFC6824, January 2013, . [RFC6897] Scharf, M. and A. Ford, "Multipath TCP (MPTCP) Application Interface Considerations", RFC 6897, DOI 10.17487/RFC6897, March 2013, . [RFC6994] Touch, J., "Shared Use of Experimental TCP Options", RFC 6994, DOI 10.17487/RFC6994, August 2013, . [TCPLO] Ramaiah, A., "TCP option space extension", Work in Progress, March 2012. - [howhard] Raiciu, C., Paasch, C., Barre, S., Ford, A., Honda, M., - Duchene, F., Bonaventure, O., and M. Handley, "How Hard - Can It Be? Designing and Implementing a Deployable - Multipath TCP", Usenix Symposium on Networked Systems - Design and Implementation 2012, . - - [norm] Handley, M., Paxson, V., and C. Kreibich, "Network - Intrusion Detection: Evasion, Traffic Normalization, and - End-to-End Protocol Semantics", Usenix Security 2001, - 2001, . - Appendix A. Notes on Use of TCP Options 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 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 already be used by options such as timestamp and SACK. We have performed a brief study on the commonly used TCP options in SYN, data, and pure ACK packets, and found that there is enough room