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

From: Jeremy Harris <[email-masked]>
Date: Mon, 3 Jun 2019 15:37:22 +0100

On 29/05/2019 17:27, Praveen Balasubramanian wrote:
> 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. 

There is a bit in the tcp_fastopen sysctl for Linux described so:

    0x200: (server) accept data-in-SYN w/o any cookie option present.

It doesn't say explicitly that the data is presented to the application
(neither does the doc for the with-cookie server TFO control bit).
Does anybody know whether it is?

-- 
Cheers,
  Jeremy

---

From: Yuchung Cheng <[email-masked]>
Date: Mon, 3 Jun 2019 10:58:43 -0700

> Does anybody know whether it is?
I am not sure what you mean - what is "it" in your last question?

when this option is used (0x200), TFO will accept the data in SYN w/o
or w/ any cookie. Accept(2) will return in 3WHS. but note that SYN-ACK
is returned immediately upon receiving SYN-data in this mode. so this
mode will not support the latest tcpm-converter proposal where SYN-ack
is delayed upon (in-data) cookie verification and proxy 3WHS
completion. This change requires non-trivial implementation for a
listener handling millions of requests in Linux.

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

---

From: Yuchung Cheng <[email-masked]>
Date: Mon, 3 Jun 2019 11:01:16 -0700

On Fri, May 31, 2019 at 5:17 AM <[email-masked]> wrote:
>
> Hi Yuchung,
>
> Thank you for clarifying your concern. Below a text proposal to address this comment:
>
> > 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.
>
> 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.
Sorry for the late reply. How about adding to the last sentence:

"When TFO is not used, the transport converter needs a corresponding
change to RFC793 to allow posting data in SYN to application upon
receiving the SYN packet".

Thanks for the improved wording.
>
>
> Better?
>
> Cheers,
> Med
>
> > -----Message d'origine-----
> > De : Yuchung Cheng [mailto:[email-masked]]
> > Envoyé : mercredi 29 mai 2019 23:46
> > À : BOUCADAIR Mohamed TGI/OLN
> > Cc : [email-masked]
> > Objet : Re: [tcpm] Progressing draft-ietf-tcpm-converters
> >
> > On Tue, May 28, 2019 at 11:10 PM <[email-masked]> wrote:
> > >
> > > 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.
> > ?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.

---

From: Jeremy Harris <[email-masked]>
Date: Mon, 3 Jun 2019 19:09:18 +0100

> I am not sure what you mean - what is "it" in your last question?

Whether the data, that arrived on the SYN, is available to the
application (before, the item I forgot to specify, the ACK for the
SYN,ACK arrives at the server).

> listener handling millions of requests in Linux.

That's a separate point of interest, as is whether it will ever be
feasible to carry data on the SYN,ACK (either for cookieless or
cookieful mode).

-- 
Cheers,
  Jeremy

---

From: Yuchung Cheng <[email-masked]>
Date: Mon, 3 Jun 2019 12:09:15 -0700

> SYN,ACK arrives at the server).
Then answer is yes (if not clear from my previous post).

---

From: <[email-masked]>
Date: Wed, 5 Jun 2019 12:18:27 +0000

Hi Yuchung, 

Please see inline. 

Cheers,
Med

> Envoyé : lundi 3 juin 2019 20:01

[Med] I'm afraid that the proposed sentence can be misinterpreted as if the use of TFO would not require that change to 793. The first paragraph of the proposed text already indicate that a change is needed.

---

From: Yuchung Cheng <[email-masked]>
Date: Wed, 5 Jun 2019 10:59:27 -0700

> [Med] I'm afraid that the proposed sentence can be misinterpreted as if the use of TFO would not require that change to 793. The first paragraph of the proposed text already indicate that a change…
Sure that works for me.

---

From: <[email-masked]>
Date: Thu, 6 Jun 2019 05:10:28 +0000

Hi Yuchung, 

Thank you. 

We will release an updated version with this NEW text.

Cheers,
Med

> Envoyé : mercredi 5 juin 2019 19:59
> > > > Thank you for clarifying your concern. Below a text proposal to
> address
> > > this comment:
> > > >
> > [Med] I'm afraid that the proposed sentence can be misinterpreted as if
> the use of TFO would not require that change to 793. The first paragraph
> of the proposed text already indicate that a change is needed.
> Sure that works for me.
> 
> >
> > > > > > This spec is an Experiment which relaxes a constraint in RFC793
> in
> > > the *
> > > > > > Given that RFC7413 isn't tagged as updating RFC793, we are
> assuming
> > > that