Re: [tcpm] Progressing draft-ietf-tcpm-converters

[<[e-mail]>]

Hi Yuchung, 

Please see inline.

Cheers,
Med

> -----Message d'origine-----
> De : Yuchung Cheng [mailto:[e-mail]]
> Envoyé : vendredi 24 mai 2019 17:01
> À : BOUCADAIR Mohamed TGI/OLN
> Cc : Olivier Bonaventure; [e-mail] Extensions
> Objet : Re: [tcpm] Progressing draft-ietf-tcpm-converters
> 
> On Thu, May 23, 2019 at 11:34 PM <[e-mail]> wrote:
> >
> > Hi Yuchung,
> >
> > Please see inline.
> >
> > Cheers,
> > Med
> >
> > > -----Message d'origine-----
> > > De : tcpm [mailto:[e-mail]] De la part de Yuchung Cheng
> > > Envoyé : jeudi 23 mai 2019 18:38
> > > À : Olivier Bonaventure
> > > Cc : [e-mail] Extensions
> > > Objet : Re: [tcpm] Progressing draft-ietf-tcpm-converters
> > >
> > > On Tue, May 21, 2019 at 4:52 AM Olivier Bonaventure
> > > <[e-mail]> wrote:
> > > >
> > > > Yuchung,
> > > >
> > > > >>
> > > > >> We believe that a specialised TCP application should be allowed
> to
> > > use its own cookie inside the payload instead of relying on the TCP
> header
> > > to use fast open. The 0-RTT convert protocol is one example, but there
> > > could be others. Looking at other application layer protocols, I
> noticed
> > > that TLS1.3 (rfc8446) also includes a cookie which is mainly designed
> > > enable servers to get a confirmation of the reachability of the client
> IP
> > > addresses for DTLS, but the same approach could be used when TLS sends
> its
> > > initial data in the SYN as well.
> > > > >>
> > > > >> Another point that should be clarified in RFC7413 are how
> middleboxes
> > > should handle SYN packets containing a non-zero payload. According to
> > > RFC793, such packets are valid TCP packets. The TFO option, defined in
> > > RFC7314 is not and should not be considered as an indication that is
> > > required to “authorise” the utilisation of payload inside a SYN
> packet.
> > > During the Prague meeting, Christoph Paasch mentioned at the mike that
> > > they have one application that uses data inside the SYN and their
> > > measurements indicate that sending this SYN without the TFO option
> enables
> > > it to pass through more middleboxes than when the same SYN contains
> the
> > > TFO option.
> > > > >>
> > > > >> Another point is the socket API. Currently, Linux and MacOS
> decouple
> > > the transmission of data inside the SYN from the utilisation of the
> TFO
> > > option. This makes it possible for a client to send data inside the
> SYN
> > > without enabling TFO. On Windows, the API seems to force the
> utilisation
> > > of TFO when there is data in the SYN. As indicated earlier, RFC793
> does
> > > not mandate the presence of the TFO to place data inside the SYN.
> > > > >>
> > > > >> The approach we are proposing has the benefits of RFC7413 but
> without
> > > its drawbacks. Moreover, given that RFC7413 is Experimental, we don't
> > > think that there is a harm if we proceed with the approach 0-rtt
> convert
> > > protocol while the IETF can further tweak and adjust the applicability
> > > scope of RFC7413. For example, an update can be proposed to RFC7413 to
> > > clarify that specialized application-level protocols could place
> cookie
> > > information in their payload and thus not use the TFO option.
> > > > > Just to confirm: you mean an API that
> > > > > let application sets the TFO cookie (on either server and client)?
> > > >
> > > >
> > > > No, we suggest to let specific applications use data in the SYN
> without
> > > using the TFO cookie. Those applications can manage their cookie
> inside
> > > the SYN payload if needed. Instead of having TFO cookies that are
> managed
> > > by the TCP stack and have limited size, those specialised protocols
> would
> > > use application-level cookies which can be longer and are managed by
> these
> > > application protocols.
> > > I see. though I suppose this requires changing RFC793 of not uploading
> > > the data to application until 3WHS completes.
> > >
> >
> > [Med] That constraint can be relaxed following a rationale similar to
> the one in RFC7413.
> >
> > Is there any particular reason why a change to RFC793 would be required
> here but not for RFC7413?
> It's an interesting question -
> 
> RFC793 long allows data-in-SYN but requires data to be posted after
> handshake. RFC7413 relaxes that but also requires a cookie.

[Med] Yeah. Same with any other approach using a cookie. I don’t see a valid reason why an approach would be marked as updating 793 but the alternative wouldn't.

> 
> So if we think this is an "extension" to TFO

[Med] It is not an extension per se. It is another way to achieve the same goals as TFO but without the TFO issues (e.g., tcp option space, middleboxes stripping tfo).

, then perhaps extends
> RFC7413 not changing RFC793? personally I do think that makes sense.
> IMO TFO implementation provides a generic way to do data-in-SYN.
> Application can use whatever they prefer to protect or optimize
> data-in-SYN. TFO cookie is just a default simple mechanism for
> application who finds that acceptable.
> 
> >
> > > >
> > > > > otherwise obviously application can place any data in their TCP
> > > payload for its
> > > > > purposes.
> > > >
> > > > This is what we proposed in Prague, i.e. using data in the TCP SYN
> > > without the TFO option.
> > > >
> > > >
> > > > Olivier
> > > > --
> > > >
> > > >
> > > > Disclaimer: https://www.tessares.net/mail-disclaimer/
> > > > <https://www.tessares.net/mail-disclaimer/>
> > > >
> > > >
> > >
> > > _______________________________________________
> > > tcpm mailing list
> > > [e-mail]
> > > https://www.ietf.org/mailman/listinfo/tcpm