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

[<[e-mail]>]

Hi Yuchung, 

This spec is an Experiment which relaxes a constraint in RFC793 in the * SAME *  way the TFO Experiment relaxes that * SAME * constraint. 

Given that RFC7413 isn't tagged as updating RFC793, we are assuming that the same conclusion applies for our spec. 

I don't think an Experimental RFC can be tagged as updating RFC793, anyway. 

Cheers,
Med

> -----Message d'origine-----
> De : Yuchung Cheng [mailto:[e-mail]]
> Envoyé : mardi 28 mai 2019 21:36
> À : Praveen Balasubramanian
> Cc : BOUCADAIR Mohamed TGI/OLN; [e-mail]
> Objet : Re: [tcpm] Progressing draft-ietf-tcpm-converters
> 
> On Tue, May 28, 2019 at 8:22 AM Praveen Balasubramanian
> <pravb=[e-mail]> wrote:
> >
> > TFO is a new RFC and server is opting in to receive early data which
> implies being aware of the replay issues. If the TFO state machine
> succeeds (valid cookie with data in SYN) only then the application can
> retrieve data even before handshake completes.
> >
> > Without TFO, the standard sockets API does not allow an application to
> receive data before 3WHS completes, even if data is received in the SYN.
> What you seem to be asking for is a modification of 793 and/or API
> behavior which will need a new opt-in socket option for preserving compat
> for existing applications.
> 
> yes that's my sense as well (i.e. this draft requires a change in RFC793).
> 
> >
> >
> > -----Original Message-----
> > From: [e-mail] <[e-mail]>
> > Sent: Monday, May 27, 2019 4:38 AM
> > To: Praveen Balasubramanian <[e-mail]>; Yuchung Cheng
> <ycheng=[e-mail]>
> > Cc: [e-mail]
> > Subject: RE: [tcpm] Progressing draft-ietf-tcpm-converters
> >
> > Hi Praveen,
> >
> > Please see inline.
> >
> > Cheers,
> > Med
> >
> > > -----Message d'origine-----
> > > De : Praveen Balasubramanian [mailto:[e-mail]] Envoyé :
> > > vendredi 24 mai 2019 18:45 À : Yuchung Cheng; BOUCADAIR Mohamed
> > > TGI/OLN Cc : [e-mail] Extensions Objet : RE: [tcpm] Progressing
> > > draft-ietf-tcpm-converters
> > >
> > > Agreed and I had raised the same question before: " Isn't passing data
> > > in the SYN up to the application before 3WHS invalid per RFC 793?
> >
> > [Med] This is similar to what TFO does. Both (i.e., TFO and the
> application-based cookie) are relaxing that constraint from 793.
> >
> >  How is the
> > > converter (T) extracting the server IP address and port from the SYN
> > > payload? Is it running some custom TCP implementation that violates
> 793?"
> > > 7413 allows nil-cookie and app can encode cookie and data in SYN if it
> > > wants. If TFO option is not used at all then it would be a change to
> > > 793 and not 7413.
> >
> > [Med] This is what the initial message from Olivier tried to address.
> The issue is what is the point in enclosing the TFO option if the cookie
> is supplied by the application? The same protection level can be provided
> with the application-supplied cookie without requiring to insert the TFO
> option.
> >
> > >
> > > -----Original Message-----
> > > From: tcpm <[e-mail]> On Behalf Of Yuchung Cheng
> > > Sent: Friday, May 24, 2019 8:01 AM
> > > To: [e-mail]
> > > Cc: [e-mail] Extensions <[e-mail]>
> > > Subject: 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.
> > >
> > > So if we think this is an "extension" to 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://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%
> > > > > > 2F
> > > > > > https://nam06.safelinks.protection.outlook.com/?url=www.tessares
> > > > > > .net&amp;data=02%7C01%7Cpravb%40microsoft.com%7Cd66411576dcc4e9c
> > > > > > 2c9308d6e297c18c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63
> > > > > > 6945538746972754&amp;sdata=ZHft4yd79R0Im8I27KM9dETCYgEhpc3zl9jJw
> > > > > > vxYZWc%3D&amp;reserved=0%2Fmail-disclaimer%2F&amp;data=02%7C01%7
> > > > > > Cpravb%40m
> > > > > > icrosoft.com%7C52f76d6b48524ea33dfc08d6e058bda8%7C72f988bf86f141
> > > > > > af
> > > > > > 91ab2d7cd011db47%7C1%7C0%7C636943069081636780&amp;sdata=hxkfj8by
> > > > > > IM
> > > > > > Txh2UwQBjz%2BoP8oBw3%2FRiYMGG3EMEorQ4%3D&amp;reserved=0
> > > > > > <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F
> > > > > > %2
> > > > > > Fwww.tessares.net%2Fmail-disclaimer%2F&amp;data=02%7C01%7Cpravb%
> > > > > > 40
> > > > > > microsoft.com%7C52f76d6b48524ea33dfc08d6e058bda8%7C72f988bf86f14
> > > > > > 1a
> > > > > > f91ab2d7cd011db47%7C1%7C0%7C636943069081636780&amp;sdata=hxkfj8b
> > > > > > yI MTxh2UwQBjz%2BoP8oBw3%2FRiYMGG3EMEorQ4%3D&amp;reserved=0>
> > > > > >
> > > > > >
> > > > >
> > > > > _______________________________________________
> > > > > tcpm mailing list
> > > > > [e-mail]
> > > > > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2F
> > > > > ww
> > > > > w.ietf.org%2Fmailman%2Flistinfo%2Ftcpm&amp;data=02%7C01%7Cpravb%40
> > > > > mi
> > > > > crosoft.com%7C52f76d6b48524ea33dfc08d6e058bda8%7C72f988bf86f141af9
> > > > > 1a
> > > > > b2d7cd011db47%7C1%7C0%7C636943069081636780&amp;sdata=1lrrMH92jHLh5
> > > > > dq
> > > > > U4q33yK%2FKg0LvXJKGR3glcnbAer8%3D&amp;reserved=0
> > >
> > > _______________________________________________
> > > tcpm mailing list
> > > [e-mail]
> > > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
> > > ietf
> > > .org%2Fmailman%2Flistinfo%2Ftcpm&amp;data=02%7C01%7Cpravb%40microsoft.
> > > com%
> > > 7C52f76d6b48524ea33dfc08d6e058bda8%7C72f988bf86f141af91ab2d7cd011db47%
> > > 7C1%
> > > 7C0%7C636943069081636780&amp;sdata=1lrrMH92jHLh5dqU4q33yK%2FKg0LvXJKGR
> > > 3glc
> > > nbAer8%3D&amp;reserved=0