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

[Christoph Paasch <[e-mail]>]

Hello Phil,

On 17/07/18 - 21:02:32, [e-mail] wrote:
> 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. 

thanks I expanded it in your suggested way.

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

Changed client/server to initiator/listener in the TFO appendix.


Christoph

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