[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 [127.0.0.1]) 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-Level:
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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (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
Hello, 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 network. 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 deployed). "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. Tom
- [tsvwg] Extension headers in draft-ietf-tsvwg-tra… Tom Herbert
- Re: [tsvwg] Extension headers in draft-ietf-tsvwg… Ingemar Johansson S
- Re: [tsvwg] Extension headers in draft-ietf-tsvwg… Tom Herbert
- Re: [tsvwg] Extension headers in draft-ietf-tsvwg… Gorry Fairhurst