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&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
> > > > > tcpm@ietf.org
> > > > > 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
> > > tcpm@ietf.org
> > > 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