MIME-Version: 1.0
References: <F92BF1E2-60EB-4E48-84A4-1C82589A056A@tessares.net>
 <CAK6E8=f-TAUWs3x4P9XHUHbvRhOqBhH9GU910Yoy5v_0vzUxAQ@mail.gmail.com>
 <A0496204-331F-4D8E-A1C1-83D3E1CE759B@tessares.net>
In-Reply-To: <A0496204-331F-4D8E-A1C1-83D3E1CE759B@tessares.net>
From: Yuchung Cheng <ycheng@google.com>
Date: Thu, 23 May 2019 09:38:14 -0700
Message-ID: <CAK6E8=e0RVzfRA0j=y8EZK0HonH6vaMBL6m-U3L+8cNO-zpqqw@mail.gmail.com>
To: Olivier Bonaventure <olivier.bonaventure@tessares.net>
Cc: "tcpm@ietf.org Extensions" <tcpm@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpm/tUJ5U0QhcVxfXD0R1X9BIvZIGeM>
Subject: Re: [tcpm] Progressing draft-ietf-tcpm-converters
Precedence: list

On Tue, May 21, 2019 at 4:52 AM Olivier Bonaventure
<olivier.bonaventure@tessares.net> 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 b=
e 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 D=
TLS, 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 RFC79=
3, such packets are valid TCP packets. The TFO option, defined in RFC7314 i=
s not and should not be considered as an indication that is required to =E2=
=80=9Cauthorise=E2=80=9D the utilisation of payload inside a SYN packet. Du=
ring the Prague meeting, Christoph Paasch mentioned at the mike that they h=
ave one application that uses data inside the SYN and their measurements in=
dicate that sending this SYN without the TFO option enables it to pass thro=
ugh more middleboxes than when the same SYN contains the TFO option.
> >>
> >> Another point is the socket API. Currently, Linux and MacOS decouple t=
he transmission of data inside the SYN from the utilisation of the TFO opti=
on. 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 wh=
en 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 protoco=
l while the IETF can further tweak and adjust the applicability scope of RF=
C7413. For example, an update can be proposed to RFC7413 to clarify that sp=
ecialized application-level protocols could place cookie information in the=
ir 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 u=
sing the TFO cookie. Those applications can manage their cookie inside the =
SYN payload if needed. Instead of having TFO cookies that are managed by th=
e TCP stack and have limited size, those specialised protocols would use ap=
plication-level cookies which can be longer and are managed by these applic=
ation protocols.
I see. though I suppose this requires changing RFC793 of not uploading
the data to application until 3WHS completes.

>
> > 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 withou=
t the TFO option.
>
>
> Olivier
> --
>
>
> Disclaimer: https://www.tessares.net/mail-disclaimer/
> <https://www.tessares.net/mail-disclaimer/>
>
>