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

Hello Phil,

some replies to your comments inline:

On 14/06/18 - 10:55:37, philip.eardley@bt.com wrote:
> 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..."

I'm not sure where you would put the "to ensure the exchange cannot..."?

However, reading through this paragraph, I think the SHOULD should rather be
a MUST, no? Because, if conflicting versions are being requested we anyways
can't do MPTCP.

> << 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. 

What about:

"
Like all MPTCP options, the MP_CAPABLE option starts with the Kind and Length
to specify the TCP-option kind and its length. Followed by that is the
MP_CAPABLE option. The first 4 bits of the first octed in the MP_CAPABLE option
(Figure 4) define the MPTCP option subtype ...
"

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

I agree with that.

> 
> 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

Fixed.

> The 'E' bit - better to say flag?

Agreed.

> 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. 

Agreed - changed this.

> 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)

I don't think there is a security hole. But worth taking a closer look at.

> 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??

I'm not sure why we have the "if length > 10 octets" in here.

The HMAC should be there always. I think, we should remove the "if length >
10 octets".

I opened a first pull-request with the changes mentioned in here at
https://github.com/multipath-tcp/draft-ietf-mptcp-rfc6824bis/pull/4.

Christoph

> 
> 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
> 
> _______________________________________________
> multipathtcp mailing list
> multipathtcp@ietf.org
> https://www.ietf.org/mailman/listinfo/multipathtcp