[tcpm] Progressing draft-ietf-tcpm-converters

Olivier Bonaventure <olivier.bonaventure@tessares.net> Mon, 20 May 2019 17:07 UTC

Return-Path: <olivier.bonaventure@tessares.net>
X-Original-To: tcpm@ietfa.amsl.com
Delivered-To: tcpm@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 2D25E1200A3 for <tcpm@ietfa.amsl.com>; Mon, 20 May 2019 10:07:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=tessares-net.20150623.gappssmtp.com
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id 7xjOB9tWuV6D for <tcpm@ietfa.amsl.com>; Mon, 20 May 2019 10:07:23 -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 4D547120073 for <tcpm@ietf.org>; Mon, 20 May 2019 10:07:23 -0700 (PDT)
Received: by mail-wr1-x434.google.com with SMTP id d18so15472666wrs.5 for <tcpm@ietf.org>; Mon, 20 May 2019 10:07:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tessares-net.20150623.gappssmtp.com; s=20150623; h=from:mime-version:subject:message-id:date:cc:to :content-transfer-encoding; bh=+/NLy5yIqMEK7ffbDgCZG2Cbkfl+WhAsFzpjhlXxAyw=; b=aN6OJ3Sttea78kZsxekC3BVktkq8kQHpEN4QJTiQR0Gqa5StKhRktsbpkaOqhdJYtq Hsp2fGkIPP3/kaNOA71N2YJGbc6GnzejYyrJKjFkbHwCIZ5gX/WL/ofMk0PNEP3Rkvjr DLs9JKvOnTJJexkAniFxOYLJOnPRYfwNOLNysNgMTUByjTYx56/CvnStAeq5wrLaPa6N /17ButGqM8WxlzUc/hHBFq8WDQw/ouQQPjOzra7qgzRU8kQBOaLEgB8TX+PHntAKz5e7 WjdP3hsJT5JNg25yf8pNi+/XWTM6kp+3BtlmTQk2w+OFMzPTFKxLCqIL+n+Lp506zsXE 8KeA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:message-id:date:cc:to :content-transfer-encoding; bh=+/NLy5yIqMEK7ffbDgCZG2Cbkfl+WhAsFzpjhlXxAyw=; b=NvE+OaVYfb02uuEZro4xirbhOOZ7/x5AfcbTR/bEHWiomk+qlosag5Ls7nmd9QUW30 JvIBpT6NcvnoxWvjeB8hUdvx9a1KLpeiuHM0GcbdUHic35hBF51oidoYGGHDbz3FHsdK eg89skOKFkkR4pp/lYPS/cXB3MpSKdW8iMT2b1dgi8Io5pLTAdvIuf8FBPUtWzgrkocY w++TYu4trH9H8ntAxffe2mzAXTxQwbRT9p4S5nM0A0RdKo4OXpPG+0e6m+vXDrodZPOg S+R7WCCX21ntWjIWv+LQx98cOKc0olH1ldcpExWxgA8fPgFRie527f/NQoh+uhQbLxzI GzVg==
X-Gm-Message-State: APjAAAXnNcuxw4fP0ZDYg4Oky2KrFEww0KQ+sIyWvkGL4+J5qcoImol5 j+XIRYwE3i9Y68EZXpiySqMRwB4y1BD9YgZBNg3W41yczFFD18HNFU5Ne/92yMsQiul7QxsS8tU BIQ==
X-Google-Smtp-Source: APXvYqxnjFnR1H0vvsHMjKCZnMROLydYL8nOhEXwXCqh3J5diawf/OixU2cu3pP634RsEy21Xo/dJg==
X-Received: by 2002:adf:f041:: with SMTP id t1mr40673569wro.74.1558372041391; Mon, 20 May 2019 10:07:21 -0700 (PDT)
Received: from ?IPv6:2001:6a8:308f:2:e028:e7a6:1a3c:937a? ([2001:6a8:308f:2:e028:e7a6:1a3c:937a]) by smtp.gmail.com with ESMTPSA id q13sm18307399wrn.27.2019. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 20 May 2019 10:07:20 -0700 (PDT)
From: Olivier Bonaventure <olivier.bonaventure@tessares.net>
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.8\))
Message-Id: <F92BF1E2-60EB-4E48-84A4-1C82589A056A@tessares.net>
Date: Mon, 20 May 2019 19:07:19 +0200
To: tcpm@ietf.org
X-Mailer: Apple Mail (2.3445.104.8)
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpm/u9bAYOcb2QQ3NyYvCUj73ITPVNg>
Subject: [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, 20 May 2019 17:07:27 -0000


During the Prague meeting, I presented the updated version of draft-ietf-tcpm-converter. This new draft places data inside the SYN, but does not use the TFO option defined in RFC7413. After the meeting, we had some discussions by email with Praveen Balasubramanian and Christoph Paasch. Praveen suggested to use an empty TFO option, but we do not believe that this would be a good solution. I would like to summarise the main points of the discussion and solicit the opinion of the working group.

According to RFC793, a SYN can contain a non-zero payload. The Experimental RFC7413 proposes the utilisation of a  cookie to protect the server from some forms of attacks. RFC7413 was designed for generic application-level that do not include the possibility of placing the cookie in the first packet of the payload. For this reason, RFC7413 uses a TCP option to encode the cookie. This design choice limits the length of the cookies and thus their security.

The 0-RTT convert protocol is a specialised application level protocol that takes a different approach by putting the cookie inside the SYN payload as part of the application data. This reduces the consumption of TCP options and enables the utilisation of longer and more secure cookies. We believe that this is the right approach in the long term. 

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. 

As indicated during the Prague meeting, we would like to finalize the 0-rtt convert protocol soon. Unless there are objections, we would like to ask to kindly issue a WGLC for the draft.

Comments are more than welcome. 

Olivier and Med


Disclaimer: https://www.tessares.net/mail-disclaimer/