Re: [multipathtcp] WG Last Call for draft-ietf-mptcp-rfc6824bis

[Christoph Paasch <[e-mail]>]

Hello Phil,

this summary looks good to me.


Cheers,
Christoph

On 05/07/18 - 08:20:50, [e-mail] wrote:
> Hi,
> Fyi I prepared some text describing the main differences between the bis and rfc6824, and the reasons for those changes. I wrote it in the context of helping the IESG when they get to reviewing it - but I thought it might be useful to helping prompt WG comments at this stage (which we urgently need). The text is draft.
> Best wishes,
> Phil
> 
> --
> This summarises the changes in draft-ietf-mptcp-rfc6824bis compared to the RFC6824. 
> https://tools.ietf.org/rfcdiff?url1=https://www.ietf.org/id/draft-ietf-mptcp-rfc6824bis-11.txt&url2=https://www.rfc-editor.org/rfc/rfc6824.txt   
> 1.	It obsoletes RFC6824. This is considered a replacement for RFC6824, as it improves it in several ways. It is not backwards compatible with RFC6824 (the protocol changes in #4 and #9 in particular). 
> 2.	Its Intended Status is Standards Track. RFC6824 is an Experimental Track document. When it was completed, it was agreed to re-charter the WG with the primary goal to create a bis version of the protocol document on the Standards track. 
> a.	The bis incorporates lessons learnt from the various implementations, deployments and experiments. RFC8041 discusses "Use Cases and Operational Experience with Multipath TCP" https://tools.ietf.org/html/rfc8041 and an IETF Journal article describes "Multipath TCP Deployments" https://www.ietfjournal.org/multipath-tcp-deployments/ 
> b.	In summary, MPTCP is extensively deployed, especially on smartphones (it is in Apple's iOS and macOS operating systems and is in several models of commercial Android smartphones), and is also deployed in some hybrid access networks.  
> c.	The 'reference', maintained Linux implementation of RFC6824 is available at https://multipath-tcp.org/ 
> d.	RFC6824bis-11 has been implemented in Linux, but has not been released (yet).
> 3.	Christoph Paasch is added as an author, as he proposed several of the new elements
> 4.	Connection initiation, through the exchange of the MP-CAPABLE MPTCP option, is different from RFC6824. Assuming that host A sends the SYN and ACK, and host B sends the SYN-ACK:-
> a.	Unlike RFC6824, the SYN doesn't include A's key (it is still sent in the ACK). This change means that A's key, which is sent in the clear, is not sent until B is known to be MPTCP-enabled.
> b.	The ACK can include data. This change means that A can send data without having to wait for B to send it data, as only then can it be sure the ACK has been received. To handle this case, the MP-CAPABLE option includes fields with the Data-Level Length and optionally a Checksum. 
> c.	In the Flags field, C is now assigned to mean that the sender of this option will not accept additional MPTCP subflows to the source address and port. This is an efficiency improvement, for example where the sender is behind a strict NAT.
> d.	In the flags field, D now indicates the use of HMAC-SHA256 (rather than HMAC-SHA1).
> 5.	Connection initiation also defines the procedure for version negotiation, for implementations that support both v0 (RFC6824) and v1 (RFC6824bis). The initiator indicates the highest version it supports, the responder indicates if it supports this version. To prevent a downgrade attack, the initiator SHOULD fall back to regular TCP, alternatively it MAY establish a new connection with the lower version of MPTCP. 
> 6.	The HMAC-SHA256 (rather than HMAC-SHA1) algorithm is used, as the algorithm provides better security. It is used to generate the token in the MP_JOIN and ADD_ADDR messages, and to set the initial data sequence number.
> 7.	As in RFC6824, a TCP RST for the subflow re-sets the subflow, or (in response to MP_JOIN) rejects an attempt to open a subflow. The change is that the process is enhanced by adding a MP_TCPRST Option:-
> a.	The new option includes a flag indicating whether the error condition is permanent or temporary, and a field with the "MP_TCPRST Reason Code", which indicates why the TCP RST is being sent. 
> b.	The receiving host MAY use this information to decide, for example, whether it tries to re-establish the subflow immediately, later, or never.
> c.	IANA is requested to create a further sub-registry with the "MP_TCPRST Reason Codes". 
> 8.	The MP_PRIO option, which is used to signal a change of priority for a subflow, no longer includes the AddrID field. Its purpose was to allow the changed priority to be  applied on a subflow other than the one it was sent on. However, it has been realised that this could be used by a man-in-the-middle to divert all traffic on to its own path, and this is an easy attack since MP_PRIO does not include a token or other security mechanism. The issue was discussed at IETF-99 and since no implementer was known to use the address identifier on MP-PRIO, it was agreed that the best approach was to remove it.
> 9.	The ADD_ADDR option, which is used to inform the other host about another potential address, is different in several ways:
> a.	It now includes an HMAC of the added address. This is for enhanced security. The RFC6824 procedure for adding an address is open to an attack where an off-path attacker creates a spoofed ADD_ADDR that enables it to hijack an MPTCP-enabled connection. Including an HMAC in the ADD_ADDR message makes it as secure as MP_JOIN. 
> b.	This was the primary driver for incrementing the version number. This was first discussed at an interim meeting in 2015 and subsequently at IETF-96. The WG consensus was that this approach was better than incorporating an alternative add address mechanism within an enhanced version 0 of the protocol. The problem and solution is discussed further in RFC7430.
> c.	Reliability for the ADD_ADDR option. The IPVer field is replaced with a flag field (the IP version field was not useful, since it is known anyway), and one flag is assigned (E) which is used as an 'Echo' so a host can indicate that it has received the option. Hence this provides reliability for the ADD_ADDR option. 
> 10.	An additional way of performing a Fast Close is described. The host sends a RST containing the MPT_FASTCLOSE option on all subflows. This allows the host to tear down the subflows and the connection immediately. 
> 11.	In the IANA registry a new MPTCP subtype option, MP_EXPERIMENTAL, is Reserved for private experiments. However, the document doesn't define how to use the subtype option. 
> 12.	A new Appendix discusses the usage of both the MPTCP and TCP Fast Open on the same packet. The two main issues are discussed: 
> a.	The potential lack of enough option space in a TCP packet. This is more likely to be an issue on the SYN+ACK packet, and the suggestion is to use a shorter TFO cookie if necessary.
> b.	A potential problem with data sequence mapping under some circumstances. The suggestion is that the TFO data is not considered part of the Data Sequence Number space.
> 
> -----Original Message-----
> From: Eardley,PL,Philip,TUD1 R 
> Sent: 04 July 2018 08:31
> To: '[e-mail]' <[e-mail]>
> Subject: RE: WG Last Call for draft-ietf-mptcp-rfc6824bis
> 
> We urgently need your comments about this document. 
> 
> It's been in WG last call for just on 4 weeks, but I think the only comments so far are from the WG chairs - clearly we need more comments before the document can advance. We'd like to discuss and close issues before or during the IETF.
> 
> So please can you dedicate some time to checking the document.
> 
> Thanks,
> Phil & Yoshi
> 
> -----Original Message-----
> From: Eardley,PL,Philip,TUD1 R 
> Sent: 26 June 2018 08:33
> To: [e-mail]
> Subject: RE: WG Last Call for draft-ietf-mptcp-rfc6824bis
> 
> Hi,
> Just a reminder about the WGLC for the protocol bis. Please send comments, Thanks!
> Phil & Yoshi
> 
> -----Original Message-----
> From: multipathtcp [mailto:[e-mail]] On Behalf Of [e-mail]
> Sent: 05 June 2018 12:21
> To: [e-mail]
> Subject: Re: [multipathtcp] WG Last Call for draft-ietf-mptcp-rfc6824bis
> 
> As a reminder, this document Obsoletes: 6824 (if approved) and its Intended status is Standards Track.
> 
> As well as suggested changes or edits, positive review comments ("It's ready") are also very valuable. 
> 
> -----Original Message-----
> From: multipathtcp [mailto:[e-mail]] On Behalf Of [e-mail]
> Sent: 05 June 2018 09:14
> To: [e-mail]
> Subject: [multipathtcp] WG Last Call for draft-ietf-mptcp-rfc6824bis
> 
> This starts a WG Last Call for draft-ietf-mptcp-rfc6824bis. Please send comments by the end of June. 
> 
> Please note there are three IPR disclosures (we're working on getting them added to the rfc6824bis page): 
> 
> * two are inherited from RFC6824  https://datatracker.ietf.org/ipr/search/?submit=draft&id=draft-ietf-mptcp-multiaddressed    
> * one is inherited from draft-paasch-mptcp-syncookies (which got include in rfc6824bis) https://datatracker.ietf.org/ipr/2678/ 
> 
> Thanks,
> Phil & Yoshi
> _______________________________________________
> multipathtcp mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/multipathtcp
> 
> _______________________________________________
> multipathtcp mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/multipathtcp
> 
> _______________________________________________
> multipathtcp mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/multipathtcp