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

<mohamed.boucadair@orange.com> Mon, 27 May 2019 09:36 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 DA44912006D for <tcpm@ietfa.amsl.com>; Mon, 27 May 2019 02:36:25 -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 iDYFQsXH-WPT for <tcpm@ietfa.amsl.com>; Mon, 27 May 2019 02:36:23 -0700 (PDT)
Received: from orange.com (mta240.mail.business.static.orange.com [80.12.66.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 58CD0120033 for <tcpm@ietf.org>; Mon, 27 May 2019 02:36:23 -0700 (PDT)
Received: from opfedar00.francetelecom.fr (unknown [xx.xx.xx.11]) by opfedar26.francetelecom.fr (ESMTP service) with ESMTP id 45CBgT5V9mzFqJY; Mon, 27 May 2019 11:36:21 +0200 (CEST)
Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.64]) by opfedar00.francetelecom.fr (ESMTP service) with ESMTP id 45CBgT4SsfzCql5; Mon, 27 May 2019 11:36:21 +0200 (CEST)
Received: from OPEXCAUBMA2.corporate.adroot.infra.ftgroup ([fe80::e878:bd0:c89e:5b42]) by OPEXCAUBMA3.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0439.000; Mon, 27 May 2019 11:36:21 +0200
From: mohamed.boucadair@orange.com
To: Yuchung Cheng <ycheng@google.com>
CC: Olivier Bonaventure <olivier.bonaventure@tessares.net>, "tcpm@ietf.org" <tcpm@ietf.org>
Thread-Topic: [tcpm] Progressing draft-ietf-tcpm-converters
Thread-Index: AQHVEkGTbjKW3YkghkOKhWLDIJr28qZ+uG5w
Date: Mon, 27 May 2019 09:36:21 +0000
Message-ID: <787AE7BB302AE849A7480A190F8B93302EA8F74D@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>
In-Reply-To: <CAK6E8=cDrLB0Oop2act7jCe_CYnNd2gJZU06ZHg_zJXXh_VOXg@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/KDhY2F_GTTjOhh60_CiDjxsduBc>
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: Mon, 27 May 2019 09:36:26 -0000

Hi Yuchung, 

Please see inline.

Cheers,
Med

> -----Message d'origine-----
> De : Yuchung Cheng [mailto:ycheng@google.com]
> Envoyé : vendredi 24 mai 2019 17:01
> À : BOUCADAIR Mohamed TGI/OLN
> Cc : Olivier Bonaventure; tcpm@ietf.org Extensions
> Objet : 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.

[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
> 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://www.tessares.net/mail-disclaimer/
> > > > <https://www.tessares.net/mail-disclaimer/>
> > > >
> > > >
> > >
> > > _______________________________________________
> > > tcpm mailing list
> > > tcpm@ietf.org
> > > https://www.ietf.org/mailman/listinfo/tcpm