[tsvwg] Extension headers in draft-ietf-tsvwg-transport-encrypt-06

Tom Herbert <tom@herbertland.com> Fri, 31 May 2019 15:57 UTC

Return-Path: <tom@herbertland.com>
X-Original-To: tsvwg@ietfa.amsl.com
Delivered-To: tsvwg@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id EB8D1120052 for <tsvwg@ietfa.amsl.com>; Fri, 31 May 2019 08:57:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Status: No, score=-1.898 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_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id PA9BIl02xUq8 for <tsvwg@ietfa.amsl.com>; Fri, 31 May 2019 08:57:24 -0700 (PDT)
Received: from mail-qk1-x72a.google.com (mail-qk1-x72a.google.com [IPv6:2607:f8b0:4864:20::72a]) (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 40BFE120099 for <tsvwg@ietf.org>; Fri, 31 May 2019 08:57:24 -0700 (PDT)
Received: by mail-qk1-x72a.google.com with SMTP id g18so6618321qkl.3 for <tsvwg@ietf.org>; Fri, 31 May 2019 08:57:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=0AhPqg9mKZb4+c5J+rCPVYxbXOLnjGI3o92yiVyIYjI=; b=mOGOqKTlmGszeT106+6/CTfgOjGxQF8UJWZV64ly7gOiq2fW6cIwTADIM9CnU2B4wE 0S4O711KP74bk8jptx2zlvAopdskX6I6KgA1lpbrpBMJ9H9oLpcPuWVh0ucI3JMz9BKy iBY6UBugwbMSKcjPjQWYCBZrXx6XCF5WNwZDjUfzIVycw3qLlKn/U2ABQXXVhQMPchIW cczqQKBnUZqe/tpKoyyq12QUSBTQlLhzdpCeS89m2n5mf+iMJMEkOsPpNEC/+xcGmBhL HYGIiZ6xB0hBiKNqqjxlQSW6fkUPgZWFLnIsCY72Xky65ZPIfNXuKRzB4Lpc0n5Xt0lK /1UQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=0AhPqg9mKZb4+c5J+rCPVYxbXOLnjGI3o92yiVyIYjI=; b=dpgiKKudp5Zw0k++NqlI9f9kNGeQojJ8FxSik7qpTjQrxJefKV85pycNDu6fVd5oZB qBxo8oercIpONyC2F9Z3vA+/XD486ZsRxx8itU2FzC6Wre/TqsHTqyQY3Qzv9uMJjUqF 1CW8mrp2EP6oxaw2NxU3yNNkKDFawK+mHcRhwnN2ftEWbbuXYadj7LN6O9l6bJl/cymm NB7IQ4hao09FnxKWPQz9qn3CYkK4brqKeKr2qNRsl4h3t3EDIrow5Q20SAMugboaQGbh 62uUn3gROKVBunbvY7L+gCxKPQ64Cph0fHnB2nNx1GJ8VLwNlJUlcadvnwmjZB7k6Bym rt/w==
X-Gm-Message-State: APjAAAX52fZiAXXonjhM6WQ2gdHgRpJRhdJ7DFy7lufZxgHSny108A1q hj0lKNk8YR7aFtl2CtBjBEm8p5/etsU17fAh2mUme+gpDGY=
X-Google-Smtp-Source: APXvYqwHyUfUiwraQET0H3F3Vz1wc20lyHLwh/USdi4k5rP8eLdOZb29Jzy5ifOERkDJpwD9Q827no0NNNFtQSzvtCY=
X-Received: by 2002:ae9:ec10:: with SMTP id h16mr9228356qkg.215.1559318242898; Fri, 31 May 2019 08:57:22 -0700 (PDT)
MIME-Version: 1.0
From: Tom Herbert <tom@herbertland.com>
Date: Fri, 31 May 2019 08:57:12 -0700
Message-ID: <CALx6S35NiQJ1etmhBjkCuXc8wdsW2O4b3+MtEyJfYjtiNkxeFQ@mail.gmail.com>
To: tsvwg <tsvwg@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/qX_j8Wkbv70NdO5-C5rd8QWJ214>
Subject: [tsvwg] Extension headers in draft-ietf-tsvwg-transport-encrypt-06
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tsvwg/>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 31 May 2019 15:57:27 -0000


Section 5 mentions possible use extension headers. I believe the text
underestimates their value and overstates the disadvantages as an
alternative method to signal transport related information to the

Please consider the following advantages:

1) Extension headers work with _all_ transport protocols as well as
any combination of encrypted or encapsulated transport headers.
2) Intermediate devices that consume transport layer information no
longer need to perform DPI. They don't need to support every transport
protocol and every possible encapsulation method, i.e. we can get
beyond plain TCP and sometimes UDP as being the only transport
protocols we're allowed to use.
3) Extension headers can contain arbitrary transport related
information including that which isn't available in the transport
headers. For instance, packet loss rate is not easily derived from the
TCP header.
4) They're stateless to the network, but can convey stateful
information maintained at the endpoint nodes.
5) They can provide information about transport protocols whose
headers convey little or no information, UDP for instance.
6) They avoid the problem in parsing transport protocols that are
carried in UDP payload, QUIC for instance, where the port number may
be misinterpreted [RFC7605], and hence the transport data may be
incorrectly interpreted.
7) Extension headers can carry information about the application
protocols that may be of interest the network that is not conveyed in
transport layers. For instance, an intermediate node might figure out
some flow is a video stream and if it can figure out the frame rate it
might be able to optimize the flow.
8) Other uses of extension headers for host to network signaling are
being defined and deployed (e.g. Hop-by-Hop options for IOAM).
9) The _user_ controls what information that is exposed per _their_
secuirity policy!

As for the listed disadvantages:

"some IPv6 networks are also known to drop packets that set an IPv6
header extension (e.g., [RFC7872])".

Yes, some networks drop such packets, but on the other hand some
networks also drop SCTP, DCCP, UDP, and even IPv6. The draft seems to
being drawing a far reaching conclusion that extension headers are not
viable, nor will never be viable, for this nor presumably any purpose.
That's a pretty big extrapolation from one snapshot of data (now three
years old BTW), and I don't believe that's the consensus of IETF. Even
if the argument is that extension headers don't work on the Internet,
they will work in restricted domains (e.g. IOAM EH and SRH are being

"Another disadvantage is that protocols that separately expose header
information do not necessarily have an incentive to expose the
information that is utilized by the protocol itself, and could
manipulate the exposed header information to gain an advantage from
the network."

This presumes that fields in transport protocols are immune to
manipulation. That's not necessarily true. Consider STT, or how easy
it would be to spoof a QUIC packet just by setting the right
destination port number.  This also becomes a problem when fields are
added to the transport layer header just for the purposes of making
data visible to the network (e.g. the spin-bit in QUIC). Where is the
incentive for a host to not manipulate that information?

If the network is sensitive to plain text data in packets that could
be manipulated and doesn't trust communicating nodes to be honest,
that is a _security_ problem not a transport problem. For instance in
FAST, the network authenticates the ticket for services set by a host.