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

From: Olivier Bonaventure <[email-masked]>
Date: Mon, 20 May 2019 19:07:19 +0200

Hello,

During the Prague meeting, I presented the updated version of draft-ietf-tcpm-converter. This new draft places data inside the SYN, but does not use the TFO option defined in RFC7413. After the meeting, we had some discussions by email with Praveen Balasubramanian and Christoph Paasch. Praveen suggested to use an empty TFO option, but we do not believe that this would be a good solution. I would like to summarise the main points of the discussion and solicit the opinion of the working group.

According to RFC793, a SYN can contain a non-zero payload. The Experimental RFC7413 proposes the utilisation of a  cookie to protect the server from some forms of attacks. RFC7413 was designed for generic application-level that do not include the possibility of placing the cookie in the first packet of the payload. For this reason, RFC7413 uses a TCP option to encode the cookie. This design choice limits the length of the cookies and thus their security.

The 0-RTT convert protocol is a specialised application level protocol that takes a different approach by putting the cookie inside the SYN payload as part of the application data. This reduces the consumption of TCP options and enables the utilisation of longer and more secure cookies. We believe that this is the right approach in the long term. 

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. 

As indicated during the Prague meeting, we would like to finalize the 0-rtt convert protocol soon. Unless there are objections, we would like to ask to kindly issue a WGLC for the draft.

Comments are more than welcome. 

Olivier and Med

-- 

Disclaimer: https://www.tessares.net/mail-disclaimer/ 
<https://www.tessares.net/mail-disclaimer/>

---

From: Yuchung Cheng <[email-masked]>
Date: Mon, 20 May 2019 10:24:00 -0700

> 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 approac…
Just to confirm: you mean an API that
let application sets the TFO cookie (on either server and client)?
otherwise obviously application can place any data in their TCP payload for its
purposes.

> _______________________________________________
> tcpm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tcpm

---

From: Olivier Bonaventure <[email-masked]>
Date: Tue, 21 May 2019 13:52:18 +0200

Yuchung,

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

> otherwise obviously application can place any data in their TCP payload for its

This is what we proposed in Prague, i.e. using data in the TCP SYN without the TFO option.

Olivier
--

---

From: Yuchung Cheng <[email-masked]>
Date: Thu, 23 May 2019 09:38:14 -0700

> 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 cook…
I see. though I suppose this requires changing RFC793 of not uploading
the data to application until 3WHS completes.

---

From: Yuchung Cheng <[email-masked]>
Date: Fri, 24 May 2019 08:00:53 -0700

On Thu, May 23, 2019 at 11:34 PM <[email-masked]> wrote:
>
> Hi Yuchung,
>
> Please see inline.
>
> Cheers,
> Med
>
> > -----Message d'origine-----
> > De : tcpm [mailto:[email-masked]] De la part de Yuchung Cheng
> > Envoyé : jeudi 23 mai 2019 18:38
> > À : Olivier Bonaventure
> > Cc : [email-masked] Extensions
> > Objet : Re: [tcpm] Progressing draft-ietf-tcpm-converters
> >
> > > >> 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.
> > > 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.
> [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.

---

From: <[email-masked]>
Date: Mon, 27 May 2019 09:36:21 +0000

Hi Yuchung, 

Please see inline.

Cheers,
Med

> De : Yuchung Cheng [mailto:[email-masked]]
> Envoyé : vendredi 24 mai 2019 17:01
> À : BOUCADAIR Mohamed TGI/OLN
> Cc : Olivier Bonaventure; [email-masked] Extensions

[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

---

From: <[email-masked]>
Date: Mon, 27 May 2019 11:37:50 +0000

Hi Praveen,

Please see inline. 

Cheers,
Med

> De : Praveen Balasubramanian [mailto:[email-masked]]
> Envoyé : vendredi 24 mai 2019 18:45
> À : Yuchung Cheng; BOUCADAIR Mohamed TGI/OLN
> 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 <[email-masked]> On Behalf Of Yuchung Cheng
> Sent: Friday, May 24, 2019 8:01 AM
> To: [email-masked]
> Cc: [email-masked] Extensions <[email-masked]>
> Subject: Re: [tcpm] Progressing draft-ietf-tcpm-converters
> 
> > > Envoyé : jeudi 23 mai 2019 18:38 À : Olivier Bonaventure Cc :
> > > [email-masked] Extensions Objet : Re: [tcpm] Progressing
> > > draft-ietf-tcpm-converters
> > >
> > > 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.
> > > > >>
> > > should handle SYN packets containing a non-zero payload. According
> > > to RFC793, such packets are valid TCP packets. The TFO option,
> > > defined in
> > > 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.
> > > > >>
> > > 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.
> > > > >>
> > > 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)?
> > > >
> > > >
> > > 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.
> > >
> >
> 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.
> 
> >
> > > >
> > > > Disclaimer:
> > > > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2F
> > > > www.tessares.net%2Fmail-disclaimer%2F&amp;data=02%7C01%7Cpravb%40m
> > > > icrosoft.com%7C52f76d6b48524ea33dfc08d6e058bda8%7C72f988bf86f141af
> > > > 91ab2d7cd011db47%7C1%7C0%7C636943069081636780&amp;sdata=hxkfj8byIM
> > > > 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%7C72f988bf86f141a
> > > > f91ab2d7cd011db47%7C1%7C0%7C636943069081636780&amp;sdata=hxkfj8byI
> > > > MTxh2UwQBjz%2BoP8oBw3%2FRiYMGG3EMEorQ4%3D&amp;reserved=0>
> > > >
> > > >
> > >
> > > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fww
> > > w.ietf.org%2Fmailman%2Flistinfo%2Ftcpm&amp;data=02%7C01%7Cpravb%40mi
> > > crosoft.com%7C52f76d6b48524ea33dfc08d6e058bda8%7C72f988bf86f141af91a
> > > b2d7cd011db47%7C1%7C0%7C636943069081636780&amp;sdata=1lrrMH92jHLh5dq
> > > U4q33yK%2FKg0LvXJKGR3glcnbAer8%3D&amp;reserved=0
> 
> 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%2FKg0LvXJKGR3glc
> nbAer8%3D&amp;reserved=0

---

From: Praveen Balasubramanian <[email-masked]>
Date: Tue, 28 May 2019 15:22:22 +0000

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. 

-----Original Message-----
From: [email-masked] <[email-masked]> 
Sent: Monday, May 27, 2019 4:38 AM
To: Praveen Balasubramanian <[email-masked]>; Yuchung Cheng <ycheng=[email-masked]>
Cc: [email-masked]
Subject: RE: [tcpm] Progressing draft-ietf-tcpm-converters

Hi Praveen,

Please see inline. 

Cheers,
Med

> De : Praveen Balasubramanian [mailto:[email-masked]] Envoyé : 
> vendredi 24 mai 2019 18:45 À : Yuchung Cheng; BOUCADAIR Mohamed 
> TGI/OLN Cc : [email-masked] Extensions Objet : RE: [tcpm] Progressing 
> 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?

 How is the
> wants. If TFO option is not used at all then it would be a change to 
> 793 and not 7413.

> > > De : tcpm [mailto:[email-masked]] De la part de Yuchung 
> > > Cheng Envoyé : jeudi 23 mai 2019 18:38 À : Olivier Bonaventure Cc :
> > > 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 
> > > RFC7314 is not and should not be considered as an indication that 
> > > is required to “authorise” the utilisation of payload inside a SYN
> packet.
> > > 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.
> > > > >>
> > > 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.
> > [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?
> data-in- SYN. TFO cookie is just a default simple mechanism for 
> > > > > 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=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 
> > > > f91ab2d7cd011db47%7C1%7C0%7C636943069081636780&amp;sdata=hxkfj8b
> > > > yI MTxh2UwQBjz%2BoP8oBw3%2FRiYMGG3EMEorQ4%3D&amp;reserved=0>
> > > >
> > > >
> > >
> > > ww

---

From: Yuchung Cheng <[email-masked]>
Date: Tue, 28 May 2019 12:35:37 -0700

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

yes that's my sense as well (i.e. this draft requires a change in RFC793).

---

From: Joe Touch <[email-masked]>
Date: Tue, 28 May 2019 13:03:58 -0700

On May 28, 2019, at 12:35 PM, Yuchung Cheng <ycheng=[email-masked]> wrote:

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

That’s not trivial and shouldn’t be assumed a viable way forward. 

Joe

---

From: <[email-masked]>
Date: Wed, 29 May 2019 06:00:42 +0000

Hi Praveen,

Please see inline.

Cheers,
Med

> Envoyé : mardi 28 mai 2019 17:22
> À : BOUCADAIR Mohamed TGI/OLN; Yuchung Cheng
> Cc : [email-masked]
> TFO is a new RFC

[Med] ...which relaxes the constraint in 793. This is exactly what an application-supplied cookie would be doing.

I still don't understand why TFO wasn't tagged as updating RFC793. 

 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.

[Med] That same procedure is followed with application supplied cookies. Below an excerpt from the spec:

   A Transport Converter that has been configured to use the optional
   Cookie TLV MUST verify the presence of this TLV in the payload of the
   received SYN.  If this TLV is present, the Transport Converter MUST
   validate the Cookie by means similar to those in Section 4.1.2 of
   [RFC7413] (i.e., IsCookieValid).  If the Cookie is valid, the
   connection establishment procedure can continue.  Otherwise, the
   Transport Converter MUST return an Error TLV set to "Not Authorized"
   and close the connection.

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

[Med] Olivier already clarified the API point:

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

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

---

From: <[email-masked]>
Date: Wed, 29 May 2019 06:10:51 +0000

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

> Envoyé : mardi 28 mai 2019 21:36
> À : Praveen Balasubramanian
> Cc : BOUCADAIR Mohamed TGI/OLN; [email-masked]
> > 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
> > [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

---

From: Olivier Bonaventure <[email-masked]>
Date: Wed, 29 May 2019 09:49:45 +0200

Praveen,

> On 28 May 2019, at 17:22, Praveen Balasubramanian <pravb=[email-masked]> wrote:
> 
> TFO is a new RFC and server is opting in to receive early data which implies being aware of the replay issues.

The same applies to draft-ietf-tcpm-converters, the server opts to receive early data and is 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.
> 

The only difference with RFC7413 is that the server itself manages the cookie and checks its validity. Once the cookie has been validated, it can process the other elements of the payload.

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

Yes, but as already mentioned, this behaviour is already implemented on the Linux and Apple stacks. This has probably been motivated by other use cases.

Olivier

--

---

From: Praveen Balasubramanian <[email-masked]>
Date: Wed, 29 May 2019 16:27:41 +0000

These are two different things.
1. Ability to SEND data in SYN payload on client. This is only supported on Linux and macOS when TFO API is not used. On Windows the only way to achieve this is using the TFO API. If TFO API is not used Windows stack will buffer the data to be sent *after* 3WHS completes. 
2. Ability to RECEIVE data in SYN payload on server. This is only supported on all OS *after* 3WHS is completed. This is per RFC 793. The only exception is if TFO API is used, and then if cookie is validated the application will  receive early-data. There is no way to retrieve early data otherwise. 

Yuchung and I are pointing to bullet 2 as requiring a RFC modification / API modification. Does this make sense?

-----Original Message-----
From: Olivier Bonaventure <[email-masked]> 
Sent: Wednesday, May 29, 2019 12:50 AM
To: Praveen Balasubramanian <[email-masked]>
Cc: [email-masked]; Yuchung Cheng <[email-masked]>; [email-masked]
Subject: Re: [tcpm] Progressing draft-ietf-tcpm-converters

Praveen,

Olivier

>> 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?
> 
>> 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.
> 
>>>> which is mainly designed enable servers to get a confirmation of 
>>>> the reachability of the client IP addresses for DTLS, but the same 
>>>> 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 
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Ftcpm&amp;data=02%7C01%7Cpravb%40microsoft.com%7C1a143764ad894b127db408d6e40a4cef%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636947130233725936&amp;sdata=x5PdSir0VO040deFdiOemBJ1mz939LdYFLQJRWfqfBs%3D&amp;reserved=0

-- 

Disclaimer: https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.tessares.net%2Fmail-disclaimer%2F&amp;data=02%7C01%7Cpravb%40microsoft.com%7C1a143764ad894b127db408d6e40a4cef%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636947130233725936&amp;sdata=2kn%2Bq%2FigobiHOl6JPANYEajQupiEtkFk9RXGjkkOQQY%3D&amp;reserved=0 
<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.tessares.net%2Fmail-disclaimer%2F&amp;data=02%7C01%7Cpravb%40microsoft.com%7C1a143764ad894b127db408d6e40a4cef%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636947130233725936&amp;sdata=2kn%2Bq%2FigobiHOl6JPANYEajQupiEtkFk9RXGjkkOQQY%3D&amp;reserved=0>

---

From: Yuchung Cheng <[email-masked]>
Date: Wed, 29 May 2019 14:45:35 -0700

> I don't think an Experimental RFC can be tagged as updating RFC793, anyway.
?Which of my emails asks to tag this draft as RFC793-update?

I merely pointed out, if TFO is not used, as the draft and the
original email refer to, the draft should be explicit this requires a
change in RFC793. It's rather vague.

draft-06

"" Standard TCP ([RFC0793], Section 3.4) allows a SYN packet to carry
   data inside its payload but forbids the receiver from delivering it
   to the application until completion of the three-way-handshake.  This
   restriction was motivated by two concerns.  First, duplicate SYNs can
   cause problems for some applications that rely on TCP [RFC7413].
   Second, TCP suffers from SYN flooding attacks [RFC4987].  TCP Fast
   Open [RFC7413] solves these two problems for applications that can
   tolerate replays by using the TCP Fast Open option that includes a
   cookie.  However, the utilization of this option consumes space in
   the limited TCP extended header.  Furthermore, there are situations,
   as noted in Section 7.3 of [RFC7413] where it is possible to accept
   the payload of SYN packets without creating additional security risks
   such as a network where addresses cannot be spoofed and the Transport
   Converter only serves a set of hosts that are identified by these
   addresses.  For these reasons, this specification does not mandate
   the use of the TCP Fast Open option when the Client sends a
   connection establishment packet towards a Transport Converter.  The
   Convert protocol includes an optional Cookie TLV that provides
   similar protection as the TCP Fast Open option without consuming
   space in the extended TCP header."

RFC7413

2.  Data in SYN

   Standard TCP already allows data to be carried in SYN packets
   ([RFC793], Section 3.4) but forbids the receiver from delivering it
   to the application until the 3WHS is completed.  This is because
   TCP's initial handshake serves to capture old or duplicate SYNs.

   To enable applications to exchange data in a TCP handshake, TFO
   removes the constraint and allows data in SYN packets to be delivered
   to the application.  This change to TCP semantic raises two issues
   (discussed in the following subsections) that make TFO unsuitable for
   certain applications.

   Therefore, TCP implementations MUST NOT use TFO by default, but only
   use TFO if requested explicitly by the application on a per-service-
   port basis.  Applications need to evaluate TFO applicability as
   described in Section 6 before using TFO.

---

From: <[email-masked]>
Date: Fri, 31 May 2019 12:17:06 +0000

Hi Yuchung, 

> change in RFC793. It's rather vague.
 
UPDATED:

   Standard TCP ([RFC0793], Section 3.4) allows a SYN packet to carry
   data inside its payload but forbids the receiver from delivering it
   to the application until completion of the three-way-handshake.  To
   enable applications to exchange data in a TCP handshake, this
   specification follows an approach similar to TCP Fast Open [RFC7413]
   and thus removes the constraint by allowing data in SYN packets to be
   delivered to the application.

   As discussed in [RFC7413], such change to TCP semantic raises two
   issues.  First, duplicate SYNs can cause problems for some
   applications that rely on TCP.  Second, TCP suffers from SYN flooding
   attacks [RFC4987].  TFO solves these two problems for applications
   that can tolerate replays by using the TCP Fast Open option that
   includes a cookie.  However, the utilization of this option consumes
   space in the limited TCP extended header.  Furthermore, there are
   situations, as noted in Section 7.3 of [RFC7413] where it is possible
   to accept the payload of SYN packets without creating additional
   security risks such as a network where addresses cannot be spoofed
   and the Transport Converter only serves a set of hosts that are
   identified by these addresses.

   For these reasons, this specification does not mandate the use of the
   TCP Fast Open option when the Client sends a connection establishment
   packet towards a Transport Converter.  The Convert protocol includes
   an optional Cookie TLV that provides similar protection as the TCP
   Fast Open option without consuming space in the extended TCP header.

Better?

Cheers,
Med

> Envoyé : mercredi 29 mai 2019 23:46
> > 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.
> >