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

Ingemar Johansson S <ingemar.s.johansson@ericsson.com> Sun, 02 June 2019 13:15 UTC

Return-Path: <ingemar.s.johansson@ericsson.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 E70C9120059 for <tsvwg@ietfa.amsl.com>; Sun, 2 Jun 2019 06:15:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.011
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 u3RtKNK10EiR for <tsvwg@ietfa.amsl.com>; Sun, 2 Jun 2019 06:15:36 -0700 (PDT)
Received: from EUR03-VE1-obe.outbound.protection.outlook.com (mail-eopbgr50055.outbound.protection.outlook.com [40.107.5.55]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AA3C5120041 for <tsvwg@ietf.org>; Sun, 2 Jun 2019 06:15:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; 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 HE1PR07MB4425.eurprd07.prod.outlook.com (20.176.167.142) by HE1PR07MB4284.eurprd07.prod.outlook.com (20.176.166.157) 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 HE1PR07MB4425.eurprd07.prod.outlook.com ([fe80::6944:b95e:c64a:6a35]) by HE1PR07MB4425.eurprd07.prod.outlook.com ([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 <ingemar.s.johansson@ericsson.com>
To: "tsvwg@ietf.org" <tsvwg@ietf.org>
CC: Tom Herbert <tom@herbertland.com>, Mirja Kuehlewind <mirja.kuehlewind@ericsson.com>, "Bob Briscoe (ietf@bobbriscoe.net)" <ietf@bobbriscoe.net>, Ingemar Johansson S <ingemar.s.johansson@ericsson.com>
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: <HE1PR07MB4425E864408D88F09428DACEC21B0@HE1PR07MB4425.eurprd07.prod.outlook.com>
Accept-Language: sv-SE, en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=ingemar.s.johansson@ericsson.com;
x-originating-ip: [192.176.1.82]
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: <HE1PR07MB42848280FA96FD01178D73F2C21B0@HE1PR07MB4284.eurprd07.prod.outlook.com>
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; H:HE1PR07MB4425.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None (protection.outlook.com: ericsson.com 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-OriginatorOrg: ericsson.com
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-CrossTenant-userprincipalname: ingemar.s.johansson@ericsson.com
X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB4284
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/F5llO_4zb7YRsN0KLZ9sJHpG4G8>
Subject: Re: [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: Sun, 02 Jun 2019 13:15:39 -0000

Hi

Last time I heard of it in a similar context was when IPv6 destination
options was outlined for ConEx (https://datatracker.ietf.org/doc/rfc7837/ ).
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 ?.

/Ingemar  

> 
> ------------------------------
> 
> Message: 2
> Date: Fri, 31 May 2019 08:57:12 -0700
> From: Tom Herbert <tom@herbertland.com>;
> To: tsvwg <tsvwg@ietf.org>;
> Subject: [tsvwg] Extension headers in
> 	draft-ietf-tsvwg-transport-encrypt-06
> Message-ID:
> 	<CALx6S35NiQJ1etmhBjkCuXc8wdsW2O4b3+MtEyJfYjtiNkxeFQ@
> mail.gmail.com>
> 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
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
> 
> 
> 
> End of tsvwg Digest, Vol 181, Issue 20
> **************************************