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

Yuchung Cheng <ycheng@google.com> Thu, 23 May 2019 16:38 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 F2972120113 for <tcpm@ietfa.amsl.com>; Thu, 23 May 2019 09:38:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.411
X-Spam-Level:
X-Spam-Status: No, score=-7.411 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_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, URIBL_SBL=10, URIBL_SBL_A=0.1, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=no 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 49teGWhVRmxv for <tcpm@ietfa.amsl.com>; Thu, 23 May 2019 09:38:54 -0700 (PDT)
Received: from mail-wr1-x434.google.com (mail-wr1-x434.google.com [IPv6:2a00:1450:4864:20::434]) (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 786B912006D for <tcpm@ietf.org>; Thu, 23 May 2019 09:38:54 -0700 (PDT)
Received: by mail-wr1-x434.google.com with SMTP id m3so7018675wrv.2 for <tcpm@ietf.org>; Thu, 23 May 2019 09:38:54 -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=Qw3MVrMtOqSLsvhAr+qH3WQ8tYegNR3pVSeSJ5NJnbQ=; b=ka0zHOpg07vjHmyfejsHtSS7WVVrGwuqJUs3JRRT3qf+x9F1tXSJoYgzNaGEbhdzxJ o2X6ETBlkdFkPz10P6XnBdDonN6nLPr4FfFHiIUmOhYMoQHK1WNQ1WlHthIn7FOt36fE owFuPi7uGDAXPlz/kFPwWUc9gNE8ZTtJUqB4+t6fg5MN2Fq/5zp6+2rzvxLOaPS4z3RA lEObfm4U3ZeXsOtdPdO5XHUr6bJrsRvjGHXK2K75jwZkXNr/euMpgvw9cZF+oa5y4KMb 6OKqRA+fimipuAEBz7PVtDZ8uRO9aXGJfOdafwBs/vkmVFgiROybn/dfHp7CMi3G/XlA 4CJg==
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=Qw3MVrMtOqSLsvhAr+qH3WQ8tYegNR3pVSeSJ5NJnbQ=; b=C5nDJglk5ToHomHpcQelhGQfbYTHo9ofaB5zTrSlYkHYn3rvlXyo6pwCuXh56lHhRb QaZ1RZJtfPEYCBCDR7TiffbK9a3A7uv9ru1OOW3x03lFTtSK6SlnHcYQ2ZYKUOS/TIP+ wnAfTcodAOxMdLX3g4Z3PhKI3OdrQr5R7Zk58NEbSZBy4pSEFEdPitx0OAt7DVv3InrV ddak7P9UAMT1ZGWF1X98xxobvu7dKA5QQTQP0hqgl92PZoxFunpU1OHgFuihAefOSFe/ ns7bJ3gJJx7LorRfv0Zy3EKiapeaDjIMuvG4Xs1I/74bj71zW/AgbbwTqAHHkO+h7BF0 iqpg==
X-Gm-Message-State: APjAAAX883rGCdP/HXApXy8eSpms13t4f3foiNu0OSwiqE9N1rKAlICL Qg5vbISV+DxKzbeXGzOpTXxxkqJx9OrWzxpZOW65gV0B
X-Google-Smtp-Source: APXvYqxMDVRD3DFQL4AKm/F9vxd8R26jcz/kECq1vINGuJQnHWitj1PME+3wqAeolsO+97BiiOe/iJTptGIIV90NbRY=
X-Received: by 2002:adf:81a2:: with SMTP id 31mr58681128wra.165.1558629532169; Thu, 23 May 2019 09:38:52 -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>
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
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: Thu, 23 May 2019 16:38:57 -0000

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.

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