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

A few comments as I work through the document, basically minor so far

Section 3.1
<< Given the SYN exchange is different between v1 and v0
   the exchange cannot be immediately downgraded, and therefore if the
   far end has requested a lower version then the initiator SHOULD
   respond with an ACK without any MP_CAPABLE option, to fall back to
   regular TCP.>>
I think it should say "to ensure the exchange cannot..."

<< The first 4 bits of the first octet in the MP_CAPABLE option
   (Figure 4) define the MPTCP option subtype (see Section 8; for
   MP_CAPABLE, this is 0), and the remaining 4 bits of this octet
   specify the MPTCP version in use (for this specification, this is 1).
>>
"The first 4 bits of the first octet in the MP_CAPABLE option" Fig 4 shows two earlier octets (Kind & Length) - I know these arent the MP-CAPABLE option, but I think it might be worth spelling out what they are. 

Would it be better strictly to have "0x0" rather than "0"? (ie match the IANA registry)

Section 3.4.1
<<A set of four flags are present after the subtype and before the
   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.
>>
4 comments:
Assinged /assigned

The 'E' bit - better to say flag?

Section 2.3 needs to be amended to show the reply /echo message for ADD-ADDR. I suggest the pic in S2.3 also shows the E value. 

Not sure - does this open security hole, where an attacker pretends an ADD-ADDR has been received? (the Echo doesn't include an hmac, so is easy to spoof)

And in Fig 12
|        Truncated HMAC (8 octets, if length > 10 octets)       |

Could this be made more straightforward? Ie spell out when length is >10 octets ie IPv6 (if I understand it). This also seems to mean that IPv4 doesn't include the HMAC, is this right??

Thanks
phil

-----Original Message-----
From: multipathtcp [mailto:multipathtcp-bounces@ietf.org] On Behalf Of philip.eardley@bt.com
Sent: 05 June 2018 09:14
To: multipathtcp@ietf.org
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
multipathtcp@ietf.org
https://www.ietf.org/mailman/listinfo/multipathtcp