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

Tom Herbert <tom@herbertland.com> Mon, 03 June 2019 14:48 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 2ED47120242 for <tsvwg@ietfa.amsl.com>; Mon, 3 Jun 2019 07:48:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 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, URIBL_BLOCKED=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 MklXzUkfIBf2 for <tsvwg@ietfa.amsl.com>; Mon, 3 Jun 2019 07:48:43 -0700 (PDT)
Received: from mail-qt1-x844.google.com (mail-qt1-x844.google.com [IPv6:2607:f8b0:4864:20::844]) (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 1098E12001E for <tsvwg@ietf.org>; Mon, 3 Jun 2019 07:48:42 -0700 (PDT)
Received: by mail-qt1-x844.google.com with SMTP id i34so9654284qta.6 for <tsvwg@ietf.org>; Mon, 03 Jun 2019 07:48:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=tJ6ttiZhouV/LtaNg9Qt+u2WN6a6cd3oHnBNNBiMWSY=; b=hMGMEQET7pcFPsTbEx5WMbuzMeRUZO/U5/Pu96cYsKeCCuJ1mIXnmmuylmX8tbI3bH YlYLu94b3MwDuOjrF2pVE7AOPBlya8RBksQ6ErYM+yjOZ7+lQz8/fYfPggXgSgFYWLIE ZQ4BvIaJh3KPrgFFusibKW2ukT5H7LMkihms1PILbbpj5KK7YMP7fKYaFFCpIyHPWlsH CHCIbjG48B4hb2bTFgX//mYN2UmMdcEUMxRAWKvpRFOWBd8Ed97/H8W9iP/OlX+tKp5x d282o5ERyVyinR3TFMjoZ9tkpmkYihyzoAS9r2GsSxxpnEA/jzfaFuaeSYw4koVheIYS lxzQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=tJ6ttiZhouV/LtaNg9Qt+u2WN6a6cd3oHnBNNBiMWSY=; b=dPCxrMXUg9v148ypnK7Q8xXe/a0lBFnesS6R0OUVdWvxZ4q1mye2rUJb3Bb8LpgGlo THM9aFuoZl3+c+0zDyJDyLarxGzDhoED/oWllzjgNK9APfS2Tv3nKX8xzb4hsAOu6JTQ u3SM28Q/NJkp3w7alY9wjIY0Bi6VhiRth3QV7meVC+epbyOEu43b+2mxsmnPU8Iqksjo zEAq3UtxBfmXKVfVjGUnZsQ81GpxVrcCrvIe+bMzfmlKh1ZjDcNeBskRrfyqwIup2Hd9 hQIsQU6QNsWO6v3QqsFWKGzqBAj/Vq27QC7czf/Bhejs9Uicxv3jC1CCCQYkiTIKVzpS zkcQ==
X-Gm-Message-State: APjAAAXxxCUUKJxwK0ySSslL8LuQYHHsLLC5TVd/Y1LV/WgZh5k/76Fg Dd0X/lPw6umZdqwzBMUOGigE0q2VWcrWxgtu8WxkPQ==
X-Google-Smtp-Source: APXvYqx2aMqXdQnESPFodFeY++zex7q6PZn7wB4bE3jNOA3yGaOcYDoWPM4QixHnf8bOxITBw7eJWoGFtmBQYKr3lEk=
X-Received: by 2002:ac8:87d:: with SMTP id x58mr23572199qth.368.1559573321587; Mon, 03 Jun 2019 07:48:41 -0700 (PDT)
MIME-Version: 1.0
References: <HE1PR07MB4425E864408D88F09428DACEC21B0@HE1PR07MB4425.eurprd07.prod.outlook.com>
In-Reply-To: <HE1PR07MB4425E864408D88F09428DACEC21B0@HE1PR07MB4425.eurprd07.prod.outlook.com>
From: Tom Herbert <tom@herbertland.com>
Date: Mon, 3 Jun 2019 07:48:30 -0700
Message-ID: <CALx6S35oXG9QbkzquwzArpLVfRN-LyQq8-J0SwgUXecSVWmi0w@mail.gmail.com>
To: Ingemar Johansson S <ingemar.s.johansson@ericsson.com>
Cc: "tsvwg@ietf.org" <tsvwg@ietf.org>, Mirja Kuehlewind <mirja.kuehlewind@ericsson.com>, "Bob Briscoe (ietf@bobbriscoe.net)" <ietf@bobbriscoe.net>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/B3YPdXjHXVUKQvhwQMkLscROqys>
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: Mon, 03 Jun 2019 14:48:46 -0000

On Sun, Jun 2, 2019 at 6:15 AM Ingemar Johansson S
<ingemar.s.johansson@ericsson.com>; wrote:
>
> 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 ?.

Hi Ingemar,

Thanks for the reference. Indeed, ConEx is a good example of the
concept of hosts signaling transport related information to the
network in a generic and transport protocol agnostic manner.

RFC7837 defines a Destination Option for ConEx. Section 3 states that
the preferred solution is a Hop-by-Hop Option. I imagine that the
reason DO was chosen is because per RFC2460 all nodes in the path must
process HBH Options, but in practice that requirement has proven
impractical. RFC8200 subsequently relaxed the requirements to allow
nodes to ignore Hop-by-Hop Options.

Tom

>
> /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
> > **************************************