Re: [multipathtcp] potential MPTCP proxy charter item

[<[e-mail]>]

Re-,

Please see inline.

Cheers,
Med

> -----Message d'origine-----
> De : Joe Touch [mailto:[e-mail]]
> Envoyé : mardi 8 novembre 2016 15:35
> À : BOUCADAIR Mohamed IMT/OLN; Mirja Kühlewind;
> [e-mail]
> Cc : [e-mail]
> Objet : Re: [multipathtcp] potential MPTCP proxy charter item
> 
> Hi, Med,
> 
> 
> On 11/8/2016 2:07 AM, [e-mail] wrote:
> > Joe,
> >
> > I'm inserting the full text of that section here:
> >
> > ====
> >          4.2.2.5  TCP Options: RFC-793 Section 3.1
> >
> >             A TCP MUST be able to receive a TCP option in any segment.
> >             A TCP MUST ignore without error any TCP option it does not
> >             implement, assuming that the option has a length field (all
> >             TCP options defined in the future will have length fields).
> >             TCP MUST be prepared to handle an illegal option length
> >             (e.g., zero) without crashing; a suggested procedure is to
> >             reset the connection and log the reason.
> > ====
> >
> >    The proposed design for the MP_CONVERT option does not violate that
> >    text, IMO.  I'm listing here the design approaches that we considered
> >    so far:
> >
> >       (1) no change to MP_CAPABLE: MPTCP proxies are prepared by design
> >       to look at the payload of SYN to retrieve MP_CONVERT options.
> >
> >       *  MP_CONVERT options are inserted in the payload of a SYN that
> >          includes MP_CAPABLE.
> >       *  If the remote peer does not support MPTCP, the connection will
> >          be reverted to TCP according to the base MPTCP specification.
> ...
> Please explain. If there is option information in the SYN data, then a
> legacy peer is allowed to keep that data (and ACK it) in the SYN ACK.
> 
> So now it has option info that it interprets as data.

[Med] But a legacy node is not allowed to pass it to the application till the 3WHS is completed. https://tools.ietf.org/html/rfc793#section-3.4 says the following:

  Several examples of connection initiation follow.  Although these
  examples do not show connection synchronization using data-carrying
  segments, this is perfectly legitimate, so long as the receiving TCP
            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^                                   
  doesn't deliver the data to the user until it is clear the data is
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  valid (i.e., the data must be buffered at the receiver until the
  connection reaches the ESTABLISHED state).  The three-way handshake
  reduces the possibility of false connections.

 You can't undo
> that unless you RST the connection, but that violates the cited text in
> RFC1122 above, i.e., you have created an option you cannot ignore by
> simply not ACKing it.

[Med] No error is encountered by the receiver side; we are safe at the front. RSTing the connection would not violate RFC1122, though. Further, this is encountered only at the first connection to a new MPTCP proxy.

> 
> 
> >      (2) change MP_CAPABLE to explicitly indicate that options are
> >       present in the SYN payload:
> >
> >       *  A flag in the MP_CAPABLE will be set to indicate to a remote
> >          peer that MP_CONVERT options are included in the payload.
> >       *  If the remote peer does not support MPTCP, the connection will
> >          be reverted to TCP as per base MPTCP specification.
> ...
> This has exactly the same problem.
> 
> It's not about "MUST ignore" - it's about "without error". Your approach
> creates an error in the TCP connection.

[Med] I agree that "without error" is an important aspect, but this text is about the receiver side. "it does not implement" does not make sense for the sender as it included the option in the first place! In the cases I mentioned above no error is declared by the receiver.  

> 
> Joe