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

[<[e-mail]>]

Christoph,
I think that basically works.

>>   The client may then retry a new connection with MPTCP v0. Additionally,
   the client can cache this information for future connections.

I think we could expand this a bit?
The client MAY re-try a new connection with MPTCP v0 or with TCP, based on considerations such as .... <importance of using multiple paths, danger of MPTCP downgrade attack...> Additionally the client MAY cache this information for future connections. 

Also, the document mostly uses the terms initiator and listener  (client & server as just in the TFO Appendix).

phil

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] 
Sent: 16 July 2018 11:31
To: Eardley,PL,Philip,TUD1 R <[e-mail]>
Cc: [e-mail]
Subject: Re: [multipathtcp] WG Last Call for draft-ietf-mptcp-rfc6824bis

In-line

On 16/07/18 - 14:49:45, [e-mail] wrote:
> In-line
> 
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]
> Sent: 15 July 2018 15:12
> To: Eardley,PL,Philip,TUD1 R <[e-mail]>
> Cc: [e-mail]
> Subject: 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, [e-mail] 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.
> 
> [phil] re-reading, I think I mis-interpreted the phrase "Given the SYN exchange is different between v1 and v0  the exchange cannot be immediately downgraded". -- I think you're saying "A downgrade attack is not immediately possible because the SYN exchange is different in v0 and v1". I don't understand - the downgrade attack is possible, in what sense isn't it immediately possible" ? 

The paragraph is not really about attackers trying to downgrade an MPTCP-version. What this part is describing is when the client supports v1 (and requests v1 in the SYN), while the server only supports v0.

In that case, the server would reply with a SYN/ACK and MP_CAPABLE of version 0. The client then needs to fallback to regular TCP as the two versions are not compatible. (because the SYN-exchange has changed).

Re-re-reading again as well, I realize that actually the above would not happen. If a server only supports v0, he will ignore the MP_CAPABLE option in the SYN, because its size is not what it expects.

I suggest the following text for this whole paragraph. Please let me know if that looks good:

   The MP_CAPABLE exchange in this specification (v1) is different to
   that specified in v0 [RFC6824].  If a host supports multiple versions
   of MPTCP, the sender of the MP_CAPABLE option SHOULD signal the
   highest version number it supports.  The passive opener, on receipt
   of this, will signal the version number it wishes to use, which MUST
   be equal to or lower than the version number indicated in the initial
   MP_CAPABLE.
   There is a caveat though with respect to this version negotiation with
   old servers that only support v0. A server that supports v0 expects that
   the MP_CAPABLE option in the SYN-segment includes the client's key. If a
   client however already upgraded to v1, it won't include the key in the
   SYN-segment. Thus, the server will ignore the MP_CAPABLE of this
   SYN-segment and reply with a SYN/ACK that does not include an MP_CAPABLE.
   The client may then retry a new connection with MPTCP v0. Additionally,
   the client can cache this information for future connections.

> Re SHOULD vs MUST. Are there circumstances when you might want to use 
> mptvp v0 rather than use tcp?. Perhaps where an operator has control 
> of both end points (even in a proxy scenario)

Yes, I think so that one would rather use MPTCP v0 than use TCP.


Christoph