Re: [tcpm] Progressing draft-ietf-tcpm-converters
<mohamed.boucadair@orange.com> Wed, 29 May 2019 06:10 UTC
Return-Path: <mohamed.boucadair@orange.com>
X-Original-To: tcpm@ietfa.amsl.com
Delivered-To: tcpm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 673F412008B for <tcpm@ietfa.amsl.com>; Tue, 28 May 2019 23:10:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kDlptRYq0Doy for <tcpm@ietfa.amsl.com>; Tue, 28 May 2019 23:10:54 -0700 (PDT)
Received: from orange.com (mta135.mail.business.static.orange.com [80.12.70.35]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D09F3120045 for <tcpm@ietf.org>; Tue, 28 May 2019 23:10:53 -0700 (PDT)
Received: from opfednr06.francetelecom.fr (unknown [xx.xx.xx.70]) by opfednr20.francetelecom.fr (ESMTP service) with ESMTP id 45DL1S1Tbtz1yqr; Wed, 29 May 2019 08:10:52 +0200 (CEST)
Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.35]) by opfednr06.francetelecom.fr (ESMTP service) with ESMTP id 45DL1S0mTvzDq8H; Wed, 29 May 2019 08:10:52 +0200 (CEST)
Received: from OPEXCAUBMA2.corporate.adroot.infra.ftgroup ([fe80::e878:bd0:c89e:5b42]) by OPEXCAUBM6C.corporate.adroot.infra.ftgroup ([fe80::f58e:8e9d:ae18:b9e3%21]) with mapi id 14.03.0439.000; Wed, 29 May 2019 08:10:51 +0200
From: mohamed.boucadair@orange.com
To: Yuchung Cheng <ycheng@google.com>
CC: "tcpm@ietf.org" <tcpm@ietf.org>
Thread-Topic: [tcpm] Progressing draft-ietf-tcpm-converters
Thread-Index: AQHVFYyvctZJrLYG+E+k02U75BYIjaaBnMqA
Date: Wed, 29 May 2019 06:10:51 +0000
Message-ID: <787AE7BB302AE849A7480A190F8B93302EA90886@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
References: <F92BF1E2-60EB-4E48-84A4-1C82589A056A@tessares.net> <CAK6E8=f-TAUWs3x4P9XHUHbvRhOqBhH9GU910Yoy5v_0vzUxAQ@mail.gmail.com> <A0496204-331F-4D8E-A1C1-83D3E1CE759B@tessares.net> <CAK6E8=e0RVzfRA0j=y8EZK0HonH6vaMBL6m-U3L+8cNO-zpqqw@mail.gmail.com> <787AE7BB302AE849A7480A190F8B93302EA8E8EF@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <CAK6E8=cDrLB0Oop2act7jCe_CYnNd2gJZU06ZHg_zJXXh_VOXg@mail.gmail.com> <MW2PR2101MB1049E8330D990998817F1A82B6020@MW2PR2101MB1049.namprd21.prod.outlook.com> <787AE7BB302AE849A7480A190F8B93302EA8F7C3@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <MW2PR2101MB10493385260DA9D53B92B1A4B61E0@MW2PR2101MB1049.namprd21.prod.outlook.com> <CAK6E8=cMEPW9Qv_tTuCW42uZOPLBVr2qNutC7EjbRTtWMRr8kA@mail.gmail.com>
In-Reply-To: <CAK6E8=cMEPW9Qv_tTuCW42uZOPLBVr2qNutC7EjbRTtWMRr8kA@mail.gmail.com>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.114.13.247]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpm/0ViecusqtpraHqR-UUn_ewNX0SY>
Subject: Re: [tcpm] Progressing draft-ietf-tcpm-converters
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tcpm/>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 29 May 2019 06:10:57 -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 > -----Message d'origine----- > De : Yuchung Cheng [mailto:ycheng@google.com] > Envoyé : mardi 28 mai 2019 21:36 > À : Praveen Balasubramanian > Cc : BOUCADAIR Mohamed TGI/OLN; tcpm@ietf.org > Objet : Re: [tcpm] Progressing draft-ietf-tcpm-converters > > On Tue, May 28, 2019 at 8:22 AM Praveen Balasubramanian > <pravb=40microsoft.com@dmarc.ietf.org> 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: mohamed.boucadair@orange.com <mohamed.boucadair@orange.com> > > Sent: Monday, May 27, 2019 4:38 AM > > To: Praveen Balasubramanian <pravb@microsoft.com>; Yuchung Cheng > <ycheng=40google.com@dmarc.ietf.org> > > Cc: tcpm@ietf.org > > Subject: RE: [tcpm] Progressing draft-ietf-tcpm-converters > > > > Hi Praveen, > > > > Please see inline. > > > > Cheers, > > Med > > > > > -----Message d'origine----- > > > De : Praveen Balasubramanian [mailto:pravb@microsoft.com] Envoyé : > > > vendredi 24 mai 2019 18:45 À : Yuchung Cheng; BOUCADAIR Mohamed > > > TGI/OLN Cc : tcpm@ietf.org 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 <tcpm-bounces@ietf.org> On Behalf Of Yuchung Cheng > > > Sent: Friday, May 24, 2019 8:01 AM > > > To: mohamed.boucadair@orange.com > > > Cc: tcpm@ietf.org Extensions <tcpm@ietf.org> > > > Subject: Re: [tcpm] Progressing draft-ietf-tcpm-converters > > > > > > On Thu, May 23, 2019 at 11:34 PM <mohamed.boucadair@orange.com> wrote: > > > > > > > > Hi Yuchung, > > > > > > > > Please see inline. > > > > > > > > Cheers, > > > > Med > > > > > > > > > -----Message d'origine----- > > > > > De : tcpm [mailto:tcpm-bounces@ietf.org] De la part de Yuchung > > > > > Cheng Envoyé : jeudi 23 mai 2019 18:38 À : Olivier Bonaventure Cc > : > > > > > tcpm@ietf.org Extensions Objet : Re: [tcpm] Progressing > > > > > draft-ietf-tcpm-converters > > > > > > > > > > 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 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&data=02%7C01%7Cpravb%40microsoft.com%7Cd66411576dcc4e9c > > > > > > 2c9308d6e297c18c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63 > > > > > > 6945538746972754&sdata=ZHft4yd79R0Im8I27KM9dETCYgEhpc3zl9jJw > > > > > > vxYZWc%3D&reserved=0%2Fmail-disclaimer%2F&data=02%7C01%7 > > > > > > Cpravb%40m > > > > > > icrosoft.com%7C52f76d6b48524ea33dfc08d6e058bda8%7C72f988bf86f141 > > > > > > af > > > > > > 91ab2d7cd011db47%7C1%7C0%7C636943069081636780&sdata=hxkfj8by > > > > > > IM > > > > > > Txh2UwQBjz%2BoP8oBw3%2FRiYMGG3EMEorQ4%3D&reserved=0 > > > > > > <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F > > > > > > %2 > > > > > > Fwww.tessares.net%2Fmail-disclaimer%2F&data=02%7C01%7Cpravb% > > > > > > 40 > > > > > > microsoft.com%7C52f76d6b48524ea33dfc08d6e058bda8%7C72f988bf86f14 > > > > > > 1a > > > > > > f91ab2d7cd011db47%7C1%7C0%7C636943069081636780&sdata=hxkfj8b > > > > > > yI MTxh2UwQBjz%2BoP8oBw3%2FRiYMGG3EMEorQ4%3D&reserved=0> > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > tcpm mailing list > > > > > tcpm@ietf.org > > > > > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2F > > > > > ww > > > > > w.ietf.org%2Fmailman%2Flistinfo%2Ftcpm&data=02%7C01%7Cpravb%40 > > > > > mi > > > > > crosoft.com%7C52f76d6b48524ea33dfc08d6e058bda8%7C72f988bf86f141af9 > > > > > 1a > > > > > b2d7cd011db47%7C1%7C0%7C636943069081636780&sdata=1lrrMH92jHLh5 > > > > > dq > > > > > U4q33yK%2FKg0LvXJKGR3glcnbAer8%3D&reserved=0 > > > > > > _______________________________________________ > > > tcpm mailing list > > > tcpm@ietf.org > > > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww. > > > ietf > > > .org%2Fmailman%2Flistinfo%2Ftcpm&data=02%7C01%7Cpravb%40microsoft. > > > com% > > > 7C52f76d6b48524ea33dfc08d6e058bda8%7C72f988bf86f141af91ab2d7cd011db47% > > > 7C1% > > > 7C0%7C636943069081636780&sdata=1lrrMH92jHLh5dqU4q33yK%2FKg0LvXJKGR > > > 3glc > > > nbAer8%3D&reserved=0
- [tcpm] Progressing draft-ietf-tcpm-converters Olivier Bonaventure
- Re: [tcpm] Progressing draft-ietf-tcpm-converters Yuchung Cheng
- Re: [tcpm] Progressing draft-ietf-tcpm-converters Olivier Bonaventure
- Re: [tcpm] Progressing draft-ietf-tcpm-converters Yuchung Cheng
- Re: [tcpm] Progressing draft-ietf-tcpm-converters Yuchung Cheng
- Re: [tcpm] Progressing draft-ietf-tcpm-converters mohamed.boucadair
- Re: [tcpm] Progressing draft-ietf-tcpm-converters mohamed.boucadair
- Re: [tcpm] Progressing draft-ietf-tcpm-converters Praveen Balasubramanian
- Re: [tcpm] Progressing draft-ietf-tcpm-converters Yuchung Cheng
- Re: [tcpm] Progressing draft-ietf-tcpm-converters Joe Touch
- Re: [tcpm] Progressing draft-ietf-tcpm-converters mohamed.boucadair
- Re: [tcpm] Progressing draft-ietf-tcpm-converters mohamed.boucadair
- Re: [tcpm] Progressing draft-ietf-tcpm-converters Olivier Bonaventure
- Re: [tcpm] Progressing draft-ietf-tcpm-converters Praveen Balasubramanian
- Re: [tcpm] Progressing draft-ietf-tcpm-converters Yuchung Cheng
- Re: [tcpm] Progressing draft-ietf-tcpm-converters mohamed.boucadair
- Re: [tcpm] Progressing draft-ietf-tcpm-converters Jeremy Harris
- Re: [tcpm] Progressing draft-ietf-tcpm-converters Yuchung Cheng
- Re: [tcpm] Progressing draft-ietf-tcpm-converters Yuchung Cheng
- Re: [tcpm] Progressing draft-ietf-tcpm-converters Jeremy Harris
- Re: [tcpm] Progressing draft-ietf-tcpm-converters Yuchung Cheng
- Re: [tcpm] Progressing draft-ietf-tcpm-converters mohamed.boucadair
- Re: [tcpm] Progressing draft-ietf-tcpm-converters Yuchung Cheng
- Re: [tcpm] Progressing draft-ietf-tcpm-converters mohamed.boucadair