Re: [tsvwg] New Version of draft-ietf-tsvwg-transport-encrypt (12)

Tom Herbert <tom@herbertland.com> Mon, 16 March 2020 17:21 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 29FE83A0DAA for <tsvwg@ietfa.amsl.com>; Mon, 16 Mar 2020 10:21:40 -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, 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 6f8xSyhFnk7t for <tsvwg@ietfa.amsl.com>; Mon, 16 Mar 2020 10:21:38 -0700 (PDT)
Received: from mail-ed1-x533.google.com (mail-ed1-x533.google.com [IPv6:2a00:1450:4864:20::533]) (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 559303A0DA3 for <tsvwg@ietf.org>; Mon, 16 Mar 2020 10:21:38 -0700 (PDT)
Received: by mail-ed1-x533.google.com with SMTP id z65so23000733ede.0 for <tsvwg@ietf.org>; Mon, 16 Mar 2020 10:21:38 -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:content-transfer-encoding; bh=Ihrdty6cqOlkZbWVQw+eN36duwo+3SIEC5UjCj+d+iI=; b=n6NKC6Z9iyO367FKPC/ixMwqB66YoX7ap7woZfhdjImv3SW0GaGv4rLryx/CrP+ag3 sIWZbLB/BPrBWbjy61r9MVDjz17C/isfSzFmVlZEFCQwtFrGEuMxESi88sfE//Ksygf3 mr3SXbxnGqK9Sak2V5EQ8L/tvyyVNeIvOFPDijUpq36ziyHkcUcjMixLEzWlKyonYjeZ NUjZy1rkmtPIDs0CzRQ4xSTNyObMXInGIfg82ZnmkO7XxTVIu70An+LMT23cxbTV6liu 1Pn8aN3VsecmkHvMp12fnMjy2V7evc4HxHOcEZonFxM9GWLPJqHfBQfdEX7Lo2BJNeuY Bg9g==
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:content-transfer-encoding; bh=Ihrdty6cqOlkZbWVQw+eN36duwo+3SIEC5UjCj+d+iI=; b=lODVciHhH5PKEuB5evHWZAbNAdJhVs95A/kASdLroHtbCwwvs4ey9z8Ir3D7cgGa69 FSUyxGwy29NBnPHLwHZXTZ+ieohIYybaTiB5WdLdTwfRr76qFi9qZPKCUBtURBM1Hhky UMciD+5DEvwO8sWdcwDMXimFCTfPN41nON42g4w/Z4tZCJaHpBZua6RZeUiGnOuPzGGF jqQvKoD2wpybqylKM9Si3KxB7onMvGSGT2mn8k2Wa+Ole0j2Gv44Ef4kDCJADR47gVjW cIblz6eHqb3fOIx2lkSrfoBuA3AJIE0YXs712wOlNponNEkR7E2r/yZCcx7dnQJjWV+X Q4XA==
X-Gm-Message-State: ANhLgQ30+BRCY0ZU7ZK86tNuIb9Lwc2rhYLEIXl942SCrPjaQvULr5Ho BqymizamJ18+0eXSumeEmQazm/8nwYlUBNplnMM+yA==
X-Google-Smtp-Source: =?utf-8?q?ADFU+vuzO4WA/ooR/tSJrSIhfYAOAh99LK0JOkdCQraO?= =?utf-8?q?wxzoUwXoX0kousbgcUC8YZ5qv5UJCPH7uJ13XWDvPGFPcfU=3D?=
X-Received: by 2002:aa7:d585:: with SMTP id r5mr980818edq.241.1584379296483; Mon, 16 Mar 2020 10:21:36 -0700 (PDT)
MIME-Version: 1.0
References: <158279435525.6196.11790581771168846041.idtracker@ietfa.amsl.com> <3c7f9e3c-d4f6-b002-5e16-6611d654c8eb@erg.abdn.ac.uk> <CAPDSy+5e0HYhBJdQm-ZhBcqmqwKGkpaKU8t_9R2_P=nAOs9s2w@mail.gmail.com> <CABcZeBOdDU0zQ+ZNQqu1vDWxQuLUzGqi9MMXPDUs-izZEgVQsg@mail.gmail.com> <CAM4esxTA9mheGALtp4zKKYVV7wNUfhp-0pdt3C62G=tkTQhaDQ@mail.gmail.com> <CABcZeBOPxLWfT3Un=+_DQoaP5Zf0_COJ=cBLsVwMZHGgu5BOHw@mail.gmail.com> <CAM4esxQMPEemk6db6hGTLdt4xetHRhV=9DD51sjd3ppn+SffEw@mail.gmail.com> <CABcZeBMR61e0CsdCg5y8PkQskm0tbR-+BKXWQghavGKBN6PyHA@mail.gmail.com> <abdc3cc8-5948-1b5d-516d-6d736b7ecda2@erg.abdn.ac.uk> <CABcZeBNVZp_H+02D_B-bg56_==W_9feZ_Z91Oc5R+6P4giftnA@mail.gmail.com> <c6b40d15-244b-5f63-8aed-e3eca3373638@erg.abdn.ac.uk> <CALx6S36Ou_L=sgAAVjLTJcEF3f0i6K6+YOkeuJc_qOW6hQt2rw@mail.gmail.com> <2e51ff5a-e502-bcde-24c9-ff2e2fa13ac4@erg.abdn.ac.uk> <CALx6S35kF8YaqK0vxUZ9c6nzZPR8gr2gbae0T2iXTX5jNbeEpA@mail.gmail.com> <964a5c73-2b12-ca87-c558-fe44b5fa39f9@erg.abdn.ac.uk>
In-Reply-To: <964a5c73-2b12-ca87-c558-fe44b5fa39f9@erg.abdn.ac.uk>
From: Tom Herbert <tom@herbertland.com>
Date: Mon, 16 Mar 2020 10:21:25 -0700
Message-ID: <CALx6S362N=FjrWoE8bK0AD02TnZvZoKPOWV-O3exz3ZpKJcWxw@mail.gmail.com>
To: Gorry Fairhurst <gorry@erg.abdn.ac.uk>
Cc: Eric Rescorla <ekr@rtfm.com>, "tsvwg@ietf.org" <tsvwg@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/nOTqy7t9cS7RNXMBtqso_qpUZqM>
Subject: Re: [tsvwg] New Version of draft-ietf-tsvwg-transport-encrypt (12)
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, 16 Mar 2020 17:21:40 -0000

On Mon, Mar 16, 2020 at 10:10 AM Gorry Fairhurst <gorry@erg.abdn.ac.uk> wrote:
>
>
> On 16/03/2020 16:28, Tom Herbert wrote:
> > On Mon, Mar 16, 2020 at 8:54 AM Gorry Fairhurst <gorry@erg.abdn.ac.uk> wrote:
> >>
> >> On 16/03/2020 15:21, Tom Herbert wrote:
> >>
> >> On Mon, Mar 16, 2020 at 7:52 AM Gorry Fairhurst <gorry@erg.abdn.ac.uk> wrote:
> >>
> >> On 16/03/2020 13:06, Eric Rescorla wrote:
> >>
> >>
> >>
> >> On Mon, Mar 16, 2020 at 2:36 AM Gorry Fairhurst <gorry@erg.abdn.ac.uk> wrote:
> >>
> >> Ekr,
> >>
> >> On 15/03/2020 13:19, Eric Rescorla wrote:
> >>
> >> Let me try to expand my point a bit.
> >>
> >> Longstanding practice is for entities in the middle of the network to
> >> use signals that were intended for the endpoint for their own
> >> purposes.  With QUIC (and a lesser extent SCTP/DTLS), those signals
> >> are being encrypted and thus unavailable to those non-endpoint
> >> entities; this draft is mostly devoted to documenting the negative
> >> impact of that change on the operations of those entities.
> >>
> >> I disagree that this is "documenting the negative impact of that change".
> >>
> >> The draft is about how this protocol information has and is being used. As long as I can remember, there has been devices that utilise some of this information, at the edge of an enterprise there is often at least one device with this role; within a managed network there are devices; etc. If the trend to use encrypted methods continues, some of these practices need to be re-assessed, and the functions more widely understood than in an era when nearly everything was thought to be TCP or "multimedia".
> >>
> >> I'm not sure what you're arguing here. What I said above is that
> >> this draft was "mostly devoted to documenting the negative
> >> impact of that change on the operations of those entities."
> >> In other words, it lists a bunch of things that people do now
> >> that will stop working. Do you not think that much of the
> >> material in this draft is of that form?
> >>
> >> -Ekr
> >>
> >> So the conclusion, para 2 states:
> >>
> >> "   This document has described some current practises, and the
> >>     implications for some stakeholders, when transport layer header
> >>     encryption is used.  It does not judge whether these practises are
> >>     necessary, or endorse the use of any specific practise.
> >>
> >> Gorry,
> >>
> >> Section 5.2 states:
> >>
> >> "Current measurement results suggest that it could currently be
> >> undesirable to rely on methods requiring end-to-end support of network
> >> options or extension headers across the Internet."
> >>
> >> That _is_ a subjective judgment
> >>
> >> That would be better to reference 6Man debate - however, the words are chosen carefully: "to rely upon ... across the Internet"
> >>
> >> Prievously David suggested to you:
> >>
> >> "Additional considerations apply to use of methods requiring end-to-end support of network options or extension headers across the Internet.  IPv4 network options may not be supported (or may utilize a slower processing path) and some IPv6 networks have been observed to drop npackets that set an IPv6 header extension (e.g., results from 2016 in    [RFC7872])."
> >>
> >>
> >> - if you think that needs more explanation, we could perhaps expand a little more about the IETF view on this, please suggest an alternative.
> >>
> > Gorry,
> >
> > It's not clear to me what the intent is here. If the intent is to
> > suggest that extension headers should be evaluated as a potential
> > alternative then I think there should be some discussion on how they
> > could work for exposing transport layer information and what the
> > benefits are. AFAIK, extension headers are the _only_ protocol
> > conformant method there is to expose arbitrary information to networks
> > which would include transport layer information-- that should be
> > mentioned.
>
> This was discussed on the TSVWG list, and at the time we decided not to
> speculate on new methods not currently deployed.
>
Gorry,

But that's exactly what the draft is doing wrt extension headers. IMO
either this topic needs to be given more balanced discussion about the
possibility of using the mechanism, or all discussion about it should
be removed from the draft in the spirit that the draft is not making
recommendations or judgments about alternatives.

Tom


> > Also, there is one question that really needs to be
> > addressed and is mostly ignored by this draft: what specific transport
> > information do networks needs and when do they need?
> That's a good question. It's not this draft's remit.
> > It should be
> > obvious that even if hosts or applications are willing to expose
> > transport layer information then they'll want to do that very
> > selectively. Some data might be appropriate to expose, some not. There
> > needs to be a lot more discussion on this.
> Indeed.
> > As for extension headers being dropped by some networks, that is true.
> > But that is not the same thing as saying they are undesirable and that
> > the problems, some of which are caused by the very network devices
> > that might need the transport information, can't be fixed. Besides,
> > extension headers are the first protocol that are dropped by networks,
> > even just a couple of years ago IPv6 was also commonly dropped by a
> > lot of networks, but that wasn't a reason for IETF to stop working on
> > it. IMO, instead of accepting protocol ossification, we should fix it
> > or work around it.
> >
> > Tom
> I suggest we add a little to the text David' proposed and also cite the
> references to uses of ext headers?
>
> Gorry
>
>
> >> (Editor-hat off: I'm pretty sure Extension Headers are viable in some places, and not currently in other places, expecting this to work end-to-end could be unduly pessimistic. Anticipating this would never work would be wrong also.)
> >>
> >>   about a technique that is not
> >> currently used with little discussion on why they're undesirable or
> >> what needs to be done to make them desirable.  As I've said before, I
> >> think the document is too easily dismisses this alternative.
> >>
> >> You think this dismissses this? I don't believe that was an intent. Would it help to suggest text that includes: RFC6564
> >> or perhaps: {RFC8250; draft-ietf-ippm-ioam-ipv6-options; draft-ietf-6man-segment-routing-header}?
> >>
> >> If the
> >> point of this document is to describe the implications of transport
> >> header encryption without any diligent consideration of alternatives
> >> to expose the necessary transport information to the network, then I
> >> suggest that the discussion of extension headers and other
> >> alternatives should be removed and deferred to other documents.
> >>
> >> Tom
> >>
> >> Gorry
> >>
> >> I agree many existing tools would stop working if IPsec formed the majority of traffic, same for QUIC. I think when considering what to do next, it can be useful to work from the current position and understand the implications of changes that are being proposed/used/whatever.
> >>
> >> At least from my personal position, this document was providing some input to that thinking. So, I do not understand your issue.
> >>
> >> Gorry