--- 1/draft-ietf-mptcp-rfc6824bis-08.txt 2017-07-28 04:13:47.785715771 -0700 +++ 2/draft-ietf-mptcp-rfc6824bis-09.txt 2017-07-28 04:13:47.957720270 -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 4, 2018 M. Handley +Intended status: Standards Track U. Politechnica of Bucharest +Expires: January 29, 2018 M. Handley U. College London O. Bonaventure U. catholique de Louvain C. Paasch Apple, Inc. - July 3, 2017 + July 28, 2017 TCP Extensions for Multipath Operation with Multiple Addresses - draft-ietf-mptcp-rfc6824bis-08 + draft-ietf-mptcp-rfc6824bis-09 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,21 +42,21 @@ 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 4, 2018. + This Internet-Draft will expire on January 29, 2018. Copyright Notice Copyright (c) 2017 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 @@ -89,21 +89,21 @@ 3.3. General MPTCP Operation . . . . . . . . . . . . . . . . . 25 3.3.1. Data Sequence Mapping . . . . . . . . . . . . . . . . 27 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 . . . . . . . . . . . 34 3.3.7. Congestion Control Considerations . . . . . . . . . . 35 3.3.8. Subflow Policy . . . . . . . . . . . . . . . . . . . 36 3.4. Address Knowledge Exchange (Path Management) . . . . . . 37 - 3.4.1. Address Advertisement . . . . . . . . . . . . . . . . 39 + 3.4.1. Address Advertisement . . . . . . . . . . . . . . . . 38 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 . . . . . . . . . . . . . . . . . . . . . 52 3.10.2. Delayed Subflow Start and Subflow Symmetry . . . . . 52 3.10.3. Failure Handling . . . . . . . . . . . . . . . . . . 53 @@ -806,21 +806,21 @@ 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 "D" 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 + SHA256 (as defined in Section 3.2). An implementation that only supports this method MUST set bit "H" to 1, and bits "D" through "G" to 0. 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 (that is, it must be treated as a regular TCP handshake). The selection of the authentication algorithm also impacts the algorithm used to generate the token and the Initial Data Sequence Number (IDSN). In this specification, with only the SHA-256 @@ -913,21 +913,21 @@ subflow, but it is expected that this will normally be the original connection initiator (see Section 3.10 for heuristics). A new subflow is started as a normal TCP SYN/ACK exchange. The Join Connection (MP_JOIN) MPTCP option is used to identify the connection to be joined by the new subflow. It uses keying material that was exchanged in the initial MP_CAPABLE handshake (Section 3.1), and that handshake also negotiates the crypto algorithm in use for the MP_JOIN handshake. - This section specifies the behavior of MP_JOIN using the HMAC-SHA1 + This section specifies the behavior of MP_JOIN using the HMAC-SHA256 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 format. In the first MP_JOIN on the SYN packet, illustrated in Figure 5, the initiator sends a token, random number, and address ID. The token is used to identify the MPTCP connection and is a cryptographic hash of the receiver's key, as exchanged in the initial MP_CAPABLE handshake (Section 3.1). In this specification, the @@ -1698,46 +1698,35 @@ In the event that the available set of paths changes, a host may wish to signal a change in priority of subflows to the peer (e.g., a subflow that was previously set as backup should now take priority over all remaining subflows). Therefore, the MP_PRIO option, shown in Figure 11, can be used to change the 'B' flag of the subflow on which it is sent. 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| |B| AddrID (opt) | - +---------------+---------------+-------+-----+-+--------------+ + +---------------+---------------+-------+-----+-+ + | Kind | Length |Subtype| |B| + +---------------+---------------+-------+-----+-+ Figure 11: Change Subflow Priority (MP_PRIO) Option It should be noted that the backup flag is a request from a data receiver to a data sender only, and the data sender SHOULD adhere to these requests. A host cannot assume that the data sender will do so, however, since local policies -- or technical difficulties -- may override MP_PRIO requests. Note also that this signal applies to a single direction, and so the sender of this option could choose to continue using the subflow to send data even if it has signaled B=1 to the other host. - This option can also be applied to other subflows than the one on - which it is sent, by setting the optional Address ID field. This - applies the given setting of B to all subflows in this connection - that use the address identified by the given Address ID. The - presence of this field is determined by the option length; if - Length==4 then it is present. If Length==3, then it applies to the - current subflow only. The use case of this is that a host can signal - to its peer that an address is temporarily unavailable (for example, - if it has radio coverage issues) and the peer should therefore drop - to backup state on all subflows using that Address ID. - 3.4. Address Knowledge Exchange (Path Management) We use the term "path management" to refer to the exchange of information about additional paths between hosts, which in this design is managed by multiple addresses at hosts. For more detail of the architectural thinking behind this design, see the MPTCP Architecture document [RFC6182]. This design makes use of two methods of sharing such information, and both can be used on a connection. The first is the direct setup of @@ -2932,21 +2922,21 @@ | Flag | Meaning | Reference | | Bit | | | +---------+----------------------------------+----------------------+ | A | Checksum required | This document, | | | | Section 3.1 | | B | Extensibility | This document, | | | | Section 3.1 | | C | Do not attempt to connect to | This document, | | | source address | Section 3.1 | | D-G | Unassigned | | - | H | HMAC-SHA1 | This document, | + | H | HMAC-SHA256 | This document, | | | | Section 3.2 | +---------+----------------------------------+----------------------+ Table 3: MPTCP Handshake Algorithms Note that the meanings of bits D through H can be dependent upon bit B, depending on how Extensibility is defined in future specifications; see Section 3.1 for more information. Future assignments in this registry are also to be defined by