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

[Christoph Paasch <[e-mail]>]

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