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

Ingemar Johansson S <> Sun, 02 June 2019 13:15 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E70C9120059 for <>; Sun, 2 Jun 2019 06:15:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.011
X-Spam-Status: No, score=-2.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id u3RtKNK10EiR for <>; Sun, 2 Jun 2019 06:15:36 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id AA3C5120041 for <>; Sun, 2 Jun 2019 06:15:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=QtIFQarSmBw3ZZdh+/T5YLfEth5OKAbD8jHXaKFYiZM=; b=oCdFMueGqkyqLLjyEMR4eAa5cEO0FictyXR6UEgI4gz3SRWn/rbkaf1GcYJV+InhrPBGI9gvnHNyEkhGmPwQwoC3FeFbONi/Lz99zEXzS+Xxsdew00emsFtU8Q0vnX9JLOedQI5vtYxqlyJ1kCNwX9yxdyn45y9l6C+o72OXBPw=
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1943.14; Sun, 2 Jun 2019 13:15:32 +0000
Received: from ([fe80::6944:b95e:c64a:6a35]) by ([fe80::6944:b95e:c64a:6a35%5]) with mapi id 15.20.1943.018; Sun, 2 Jun 2019 13:15:32 +0000
From: Ingemar Johansson S <>
To: "" <>
CC: Tom Herbert <>, Mirja Kuehlewind <>, "Bob Briscoe (" <>, Ingemar Johansson S <>
Thread-Topic: [tsvwg] Extension headers in draft-ietf-tsvwg-transport-encrypt-06
Thread-Index: AdUZRBJ0ekVgkRcrT2+XGFf7pS92xg==
Date: Sun, 2 Jun 2019 13:15:31 +0000
Message-ID: <>
Accept-Language: sv-SE, en-US
Content-Language: en-US
X-MS-Has-Attach: yes
authentication-results: spf=none (sender IP is );
x-originating-ip: []
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 1a024beb-6086-4712-6b24-08d6e75c6412
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600148)(711020)(4605104)(1401327)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(49563074)(7193020); SRVR:HE1PR07MB4284;
x-ms-traffictypediagnostic: HE1PR07MB4284:
x-microsoft-antispam-prvs: <>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 005671E15D
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(979002)(366004)(39860400002)(136003)(396003)(346002)(376002)(189003)(199004)(107886003)(4326008)(7696005)(305945005)(102836004)(33656002)(8936002)(6436002)(14454004)(68736007)(53936002)(316002)(2351001)(54906003)(478600001)(86362001)(6306002)(99286004)(9686003)(6246003)(73956011)(81166006)(71200400001)(66574012)(71190400001)(66946007)(64756008)(66446008)(8676002)(7736002)(3846002)(66066001)(6116002)(25786009)(6916009)(53546011)(6506007)(14444005)(2906002)(2501003)(66556008)(66476007)(66616009)(76116006)(256004)(81156014)(1730700003)(99936001)(5640700003)(52536014)(55016002)(74316002)(476003)(486006)(5660300002)(26005)(186003)(229853002)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB4284;; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None ( does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: XjRfv0dcnVlJNcJ4kmUmJUG0LuwH6IJBbSWtAu9v89pHvt65TIM9jDAGWeyptx1VQC3ZMGo9TpcjD/PQ5svmlT+iBq28QcMPyftST78W0/nR5/csuMqcvabyd/7oIHTxziX3/UbOeDUbH/2NJ6BdSwg/jN2x0ufQu6n7Z0SoJ/OdK0Px8RPicAk2CtKqYEJpqx+vs8pZ60o3lkfqIwlkrXnKOU7paPddKM06rRh7PQn9/LB6mF9ns8EQUxdY5vmhY//r7R7TgXH4b3KThNiNjORx/4CR8Vu8D698Riry/GQMuUPKIJK8ZWx4f05Po7M046shgpLA3Qv4Q1UK3AoxkNFbKlN2FjV9UIKEh55P1lpfwSVWa9Ret1lwzSw510kYWTwAODPPirxVUdS6Ge88dNvfvmWNz9taL7y42n/XQ4E=
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_00BD_01D51956.04359540"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 1a024beb-6086-4712-6b24-08d6e75c6412
X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Jun 2019 13:15:31.9741 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB4284
Archived-At: <>
Subject: Re: [tsvwg] Extension headers in draft-ietf-tsvwg-transport-encrypt-06
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Transport Area Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 02 Jun 2019 13:15:39 -0000


Last time I heard of it in a similar context was when IPv6 destination
options was outlined for ConEx ( ).
I liked the idea but for various reasons it did not fly AFAIK, perhaps
because the possible congestion problem was not deemed as problematic enough
to justify the implementation cost ?
If the concept is still plausible then I guess something similar and generic
enough can be implemented for application exposure as well ?.


> ------------------------------
> Message: 2
> Date: Fri, 31 May 2019 08:57:12 -0700
> From: Tom Herbert <>;
> To: tsvwg <>;
> Subject: [tsvwg] Extension headers in
> 	draft-ietf-tsvwg-transport-encrypt-06
> Message-ID:
> 	<CALx6S35NiQJ1etmhBjkCuXc8wdsW2O4b3+MtEyJfYjtiNkxeFQ@
> Content-Type: text/plain; charset="UTF-8"
> Hello,
> Section 5 mentions possible use extension headers. I believe the text
> underestimates their value and overstates the disadvantages as an
> 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
> 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
> may be of interest the network that is not conveyed in transport layers.
> 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_
> 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
> 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
> 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
> is utilized by the protocol itself, and could manipulate the exposed
> information to gain an advantage from the network."
> This presumes that fields in transport protocols are immune to
> 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
> the purposes of making data visible to the network (e.g. the spin-bit in
> 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
> 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
> End of tsvwg Digest, Vol 181, Issue 20
> **************************************