Re: [tsvwg] New Version of draft-ietf-tsvwg-transport-encrypt (12)
Gorry Fairhurst <gorry@erg.abdn.ac.uk> Mon, 16 March 2020 17:23 UTC
Return-Path: <gorry@erg.abdn.ac.uk>
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 E1E1D3A0DB8 for <tsvwg@ietfa.amsl.com>; Mon, 16 Mar 2020 10:23:56 -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, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 TbFOACRLNaY3 for <tsvwg@ietfa.amsl.com>; Mon, 16 Mar 2020 10:23:55 -0700 (PDT)
Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [IPv6:2001:630:42:150::2]) by ietfa.amsl.com (Postfix) with ESMTP id C5A723A0DDE for <tsvwg@ietf.org>; Mon, 16 Mar 2020 10:23:54 -0700 (PDT)
Received: from GF-MacBook-Pro.local (fgrpf.plus.com [212.159.18.54]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPSA id 5145B1B0009C; Mon, 16 Mar 2020 17:23:50 +0000 (GMT)
To: Tom Herbert <tom@herbertland.com>
Cc: Eric Rescorla <ekr@rtfm.com>, "tsvwg@ietf.org" <tsvwg@ietf.org>
References: <158279435525.6196.11790581771168846041.idtracker@ietfa.amsl.com> <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> <CALx6S362N=FjrWoE8bK0AD02TnZvZoKPOWV-O3exz3ZpKJcWxw@mail.gmail.com>
From: Gorry Fairhurst <gorry@erg.abdn.ac.uk>
Message-ID: <b9155393-9b15-b000-6ccf-de401d78ec21@erg.abdn.ac.uk>
Date: Mon, 16 Mar 2020 17:23:49 +0000
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:68.0) Gecko/20100101 Thunderbird/68.5.0
MIME-Version: 1.0
In-Reply-To: <CALx6S362N=FjrWoE8bK0AD02TnZvZoKPOWV-O3exz3ZpKJcWxw@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Content-Language: en-GB
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/L_q-kaH2-6vsMrp0cifjlklKXO8>
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:24:07 -0000
Tom, please comment on David's proposed text - he's the shepherd for this WG document, and it would be useful to know you thoughts. Gorry On 16/03/2020 17:21, Tom Herbert wrote: > 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
- [tsvwg] New Version of draft-ietf-tsvwg-transport… Gorry Fairhurst
- Re: [tsvwg] New Version of draft-ietf-tsvwg-trans… David Schinazi
- Re: [tsvwg] New Version of draft-ietf-tsvwg-trans… Gorry Fairhurst
- Re: [tsvwg] New Version of draft-ietf-tsvwg-trans… Spencer Dawkins at IETF
- Re: [tsvwg] New Version of draft-ietf-tsvwg-trans… Martin Duke
- Re: [tsvwg] New Version of draft-ietf-tsvwg-trans… Spencer Dawkins at IETF
- Re: [tsvwg] New Version of draft-ietf-tsvwg-trans… Joe Touch
- Re: [tsvwg] New Version of draft-ietf-tsvwg-trans… Colin Perkins
- Re: [tsvwg] New Version of draft-ietf-tsvwg-trans… Eric Rescorla
- Re: [tsvwg] New Version of draft-ietf-tsvwg-trans… Martin Duke
- Re: [tsvwg] New Version of draft-ietf-tsvwg-trans… Eric Rescorla
- Re: [tsvwg] New Version of draft-ietf-tsvwg-trans… Martin Duke
- Re: [tsvwg] New Version of draft-ietf-tsvwg-trans… Eric Rescorla
- Re: [tsvwg] New Version of draft-ietf-tsvwg-trans… Gorry Fairhurst
- Re: [tsvwg] New Version of draft-ietf-tsvwg-trans… Gorry Fairhurst
- Re: [tsvwg] New Version of draft-ietf-tsvwg-trans… Eric Rescorla
- Re: [tsvwg] New Version of draft-ietf-tsvwg-trans… Eric Rescorla
- Re: [tsvwg] New Version of draft-ietf-tsvwg-trans… Gorry Fairhurst
- Re: [tsvwg] New Version of draft-ietf-tsvwg-trans… Tom Herbert
- Re: [tsvwg] New Version of draft-ietf-tsvwg-trans… Eric Rescorla
- Re: [tsvwg] New Version of draft-ietf-tsvwg-trans… Gorry Fairhurst
- Re: [tsvwg] New Version of draft-ietf-tsvwg-trans… Gorry Fairhurst
- Re: [tsvwg] New Version of draft-ietf-tsvwg-trans… Tom Herbert
- Re: [tsvwg] New Version of draft-ietf-tsvwg-trans… Gorry Fairhurst
- Re: [tsvwg] New Version of draft-ietf-tsvwg-trans… Tom Herbert
- Re: [tsvwg] New Version of draft-ietf-tsvwg-trans… Gorry Fairhurst
- Re: [tsvwg] New Version of draft-ietf-tsvwg-trans… Tom Herbert
- Re: [tsvwg] New Version of draft-ietf-tsvwg-trans… Black, David
- Re: [tsvwg] New Version of draft-ietf-tsvwg-trans… Tom Herbert
- Re: [tsvwg] New Version of draft-ietf-tsvwg-trans… Black, David