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

Yuchung Cheng <ycheng@google.com> Wed, 29 May 2019 21:46 UTC

Return-Path: <ycheng@google.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 E7552120148 for <tcpm@ietfa.amsl.com>; Wed, 29 May 2019 14:46:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.51
X-Spam-Level:
X-Spam-Status: No, score=-17.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com
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 xsN1VfRpsphc for <tcpm@ietfa.amsl.com>; Wed, 29 May 2019 14:46:15 -0700 (PDT)
Received: from mail-wr1-x42d.google.com (mail-wr1-x42d.google.com [IPv6:2a00:1450:4864:20::42d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D9AE120169 for <tcpm@ietf.org>; Wed, 29 May 2019 14:46:15 -0700 (PDT)
Received: by mail-wr1-x42d.google.com with SMTP id d9so2799763wrx.0 for <tcpm@ietf.org>; Wed, 29 May 2019 14:46:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=ZDof5Sb34nMsPfzavyxwbAeHgkPxSS70jc9x6AHZVM8=; b=rmOSEryJR7mb7117BXZBl/FtJDWEwiHU4Y/XeH2r6qpJZtUlKETnvkvBWd5tAXGfW7 QI9MSC2SSpZ+YkFTYLujXA2zsVv/Ys7BpPBu4qMZ2Rjy+W/xmhPPLCpbZSs5JsdTnsSO 4z1XPQtwGha9XXmFMqITdMYCiI3MPo0XFBeF3ceFPSUtioymKvf1rRA7cCUfp+palrT8 XZ5FXPLwP0zKjJ5rMQ6y3A+NguASPEuiLHQJRp4BDqHkYx4r4k6+rAFt6SqzCCqOhJ8p MP4l301YSW1U7rWhSlHKrQMuToeTE/H9hkdg10N4v6kd+WCHFPO9gO8eqrLvJ8yxwoGS 1xDw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=ZDof5Sb34nMsPfzavyxwbAeHgkPxSS70jc9x6AHZVM8=; b=IDPl2zuoCSZxCPsM6UkE+Tv484jQDE3b/wJl9QwuT6xVHixl7cxeM33UjlaImkt2rd 1O1JsY0XBZNYciVsELchHUo9LnTRoNasgL/g8iO4yRnyZ5XByQ5g9EXi0ZueNCSbismY blpYPLCEt4woEbzO/WUrV78tVat7o954Ay2ybdFbLO3YjayqV3ST7Jg7jXqKdcWPU9VI z9IbJ81IV56y3mmq7QRAcbNTzyg1IhD27kRLxt2pwFdo7RBbnHMcD9+ozn8chsYBquva dYHP7KtolBmTRX3sdWtSL3HbIHp8hnSMJlZwLAnOh10jbgKJ7pkWMc6j1+OxDGHliir6 y7gg==
X-Gm-Message-State: APjAAAXVEmgGgcqsJE1YIFF4aLl7NkXYF6Sh8u8Jqj3ho7F9in4IiXdJ 9sVJwkfK1UYwSsybuMnoutF5MgPKTMdz2hhalDW2oQ==
X-Google-Smtp-Source: APXvYqwtjmczaJdlQ4wZYScDbetkzpJ92T+2rAPR4bfHp5feXsc5Kpco1BsamwWNpX3ZvAf80fw+3ktU/O06lUC6ZYI=
X-Received: by 2002:a5d:69cf:: with SMTP id s15mr143770wrw.75.1559166373034; Wed, 29 May 2019 14:46:13 -0700 (PDT)
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> <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> <787AE7BB302AE849A7480A190F8B93302EA90886@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
In-Reply-To: <787AE7BB302AE849A7480A190F8B93302EA90886@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
From: Yuchung Cheng <ycheng@google.com>
Date: Wed, 29 May 2019 14:45:35 -0700
Message-ID: <CAK6E8=d+w9dTTJLNdgzBrpPt=jp=Z+g_jqi1kJo+mEerMzvEqA@mail.gmail.com>
To: mohamed.boucadair@orange.com
Cc: "tcpm@ietf.org" <tcpm@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpm/NBEm-QxdZrLR9TwdgAdubORJe_c>
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 21:46:20 -0000

On Tue, May 28, 2019 at 11:10 PM <mohamed.boucadair@orange.com>; 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.

draft-06

"" 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.  This
   restriction was motivated by two concerns.  First, duplicate SYNs can
   cause problems for some applications that rely on TCP [RFC7413].
   Second, TCP suffers from SYN flooding attacks [RFC4987].  TCP Fast
   Open [RFC7413] 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."


RFC7413

2.  Data in SYN

   Standard TCP already allows data to be carried in SYN packets
   ([RFC793], Section 3.4) but forbids the receiver from delivering it
   to the application until the 3WHS is completed.  This is because
   TCP's initial handshake serves to capture old or duplicate SYNs.

   To enable applications to exchange data in a TCP handshake, TFO
   removes the constraint and allows data in SYN packets to be delivered
   to the application.  This change to TCP semantic raises two issues
   (discussed in the following subsections) that make TFO unsuitable for
   certain applications.

   Therefore, TCP implementations MUST NOT use TFO by default, but only
   use TFO if requested explicitly by the application on a per-service-
   port basis.  Applications need to evaluate TFO applicability as
   described in Section 6 before using TFO.




>
> 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