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

["Black, David" <[e-mail]>]

Hi Tom,

Extracting brief excerpts to focus on what needs to be done to this draft, now ...

> That comes back to the fundamental question that thus far no one has
> been able to answer: "Exactly what transport information do we _need_
> to expose to the network?".

+1 - that question is important, but the problem is complex ... and (to paraphrase HL Mencken), the current situation is that we've found the two clear, simple and wrong answers, namely encrypt everything and encrypt nothing.   A longer, deeper discussion is in order to find more useful answers about what to encrypt vs. expose - this draft is intended as input to that discussion.

> This is why "Transport protocol independence", #1 below, is crucial.
> 
> This mentioned in the draft, but again it's more accepted fact than
> perception:

Noted, expect better discussion of this topic in the next version of the draft, stay tuned ...

> I think the problems associated with Hop-by-Hop options have been
> pretty well documented, a solution to these would be general. I'm not
> sure which WG this would belong in.

That certainly does not belong in this draft.  What would you suggest as a reference that describes current problems with Hop-by-Hop options and/or their current state of deployability?

> > I would want to see more details on what sort of non-conformant devices
> > cause problems, in particular routers.  This is because to the extent that routers
> > are responsible, there's a much steeper hill to climb for a good level of support
> > (e.g., reduced likelihood of a Happy Eyeballs approach working well in general).
> >
> Okay, but in that same vein I think there should be more discussion
> about the pragmatics of developing and deploying a new transport
> protocol especially if we expect that intermediate nodes are going to
> handle the protocol.  It's one thing for protocol developers to
> carefully consider what fields to encrypt, it's an entirely different
> problem to get support in intermediate devices to support the
> protocol.

I think the overall concern will be addressed by added discussion of transport protocol independent vs. dependent exposure of information to the network.

Beyond that, I would suggest that the design of TLS 1.3 and its use in QUIC suggests that there is no IETF expectation "that intermediate nodes are going to handle the [transport] protocol."

Thanks, --David

> -----Original Message-----
> From: Tom Herbert <[e-mail]>
> Sent: Thursday, March 19, 2020 11:02 AM
> To: Black, David
> Cc: [e-mail]
> Subject: Re: [tsvwg] New Version of draft-ietf-tsvwg-transport-encrypt (12)
> 
> 
> [EXTERNAL EMAIL]
> 
> On Wed, Mar 18, 2020 at 4:06 PM Black, David <[e-mail]>
> wrote:
> >
> > Hi Tom,
> > [writing as draft shepherd]
> >
> > I understand where this is going, but I think that the initial proposed text
> (below) has gone over to unbalanced in the other direction, and the draft ought
> to wind up somewhere in the middle.
> >
> > Here's the TL;DR summary of the two things I would suggest doing next:
> >
> > [A-Draft authors] Edit draft with a goal of placing roughly equal emphasis on
> <selective exposure of information from encrypted transport protocol headers>
> and <design of new transport protocols> as motivations and intended uses of
> this draft.  That looks like it will help respond to Ekr's comment.
> 
> I'm all for considering these, however wrt to "design of new transport
> protocols" I think we need a better answer than saying new protocols
> need to selectively determine which fields to encrypt and which do
> not. Reality is that it's not relevant since intermediate devices
> aren't going to support parsing new transports in any bounded time.
> Consider, SCTP has been around for years with a completely plaintext
> header, few network nodes process it, and so it has achieved little
> deployment. This is why "Transport protocol independence", #1 below,
> is crucial.
> 
> This mentioned in the draft, but again it's more accepted fact than
> perception: "One motive to use encryption is a response to perceptions
> that the network has become ossified by over-reliance on middleboxes
> that prevent new protocols and mechanisms from being deployed."
> 
> >
> > [B-Tom] Edit/expand final paragraph of new text on network support for IPv6
> Hop-by-Hop options to provide more details about what sort of devices are
> responsible for the observed problems.
> 
> I think the problems associated with Hop-by-Hop options have been
> pretty well documented, a solution to these would be general. I'm not
> sure which WG this would belong in.
> 
> It's a general problem that has been discussed in other documents.
> > ----------------------------
> > In more detail ...backing out to a higher level, the proposed new text
> articulates three rationales for use of IPv6 Hop-by-Hop options:
> >
> >         1.  Transport protocol independence.
> >         2.  Explicit control of exposed content.
> >         3.  Standards compliance by comparison to alternatives such as IPv4
> options and DPI.
> >
> > Of these three, I view rationale #2 (Explicit control of exposed content) as
> crucial, because it appears to also be related to Ekr's comment.  Digging into
> that comment and related discussion, my initial take is that the draft has (in
> 20/20 hindsight) not paid enough attention to selective exposure of information
> from encrypted transport protocol headers by comparison to design of new
> transport protocols.  In particular, I concur with Martin's observation: "I suspect
> loss bits are not the last time someone will want to expose more info [from
> QUIC transport headers]." ... and I would still concur even if he weren't an
> incoming Transport AD ;-).
> >
> That comes back to the fundamental question that thus far no one has
> been able to answer: "Exactly what transport information do we _need_
> to expose to the network?".
> 
> > So, I recommend editing the draft  to better balance <selective exposure of
> information from encrypted transport protocol headers> as a motivation for
> the draft with  <design of new transport protocols>.  These changes ought to
> start early in the draft, e.g., work selective exposure of encrypted header
> information into the first sentence of this paragraph of the Introduction:
> >
> >    The direction in which the use of transport header confidentiality
> >    evolves could have significant implications on the way the Internet
> >    architecture develops, and therefore needs to be considered as a part
> >    of protocol design.  This include considering whether the endpoints
> >    permit network devices to observe a specific field of the transport
> >    header; whether the devices could modify that field; and whether any
> >    modification can be detected by the receiving endpoint.
> >
> > Then, somewhere in or near Section 5 of the draft, it would be useful to add a
> brief discussion of the possible means of exposing such information.  That
> would be a good place to deal with transport-independence vs. transport-
> specificity of exposed information, which encompasses rationale #1, and
> including IPv6 Hop-by-Hop options [RFC8200] is a fine example of a transport-
> independent approach.
> >
> > Turning to rationale #3, I tend to take a dim view of standards compliance as
> an end in-and-of itself in a draft like this that has a strong network operational
> emphasis.  It would be reasonable to explain why the example of IPv6 hop-by-
> hop options is superior to IPv4 options, but DPI, which often goes well beyond
> the transport protocol headers, seems beyond the immediate focus of this
> draft.
> 
> Standard compliance is not an end in itself. That becomes readily
> apparent when we consider the effects when compliance is not
> practiced. The material effects caused by middelbox non-conformance in
> being intrusive in transport protocols are protocol ossification,
> weakened security, impeded Internet evolution, loss of robustness,
> etc. In fact, forcing intermediate nodes back into standards
> compliance is probably the biggest motivation for encrypting the
> transport layer. The draft says exactly this: "This has lead to a
> perception that there is too much "manipulation" of protocol headers
> within the network, and that designing to deploy in such networks is
> preventing transport evolution." Again, whether this is perception or
> established fact is debatable.
> 
> >
> > One more thing ... the topic of network non-support for extension headers
> keeps coming up as something that needs carefully crafted text.   Starting from
> the paragraph proposed below:
> >
> >    Some networks drop extension headers because of non-conformant
> >    intermediate devices. In order to make their use viable, fixes and
> >    workarounds are needed. Once class of workarounds would involving
> >    probing to destinations to deduce what paths are amenable use of
> >    Hop-by-Hop options extension headers (this might be in the same spirit
> >    of Happy Eyeballs for IPv6).
> >
> > I would want to see more details on what sort of non-conformant devices
> cause problems, in particular routers.  This is because to the extent that routers
> are responsible, there's a much steeper hill to climb for a good level of support
> (e.g., reduced likelihood of a Happy Eyeballs approach working well in general).
> >
> 
> Okay, but in that same vein I think there should be more discussion
> about the pragmatics of developing and deploying a new transport
> protocol especially if we expect that intermediate nodes are going to
> handle the protocol. It's one thing for protocol developers to
> carefully consider what fields to encrypt, it's an entirely different
> problem to get support in intermediate devices to support the
> protocol. This is why were stuck with deploying new protocols in UDP,
> it gives us the best change to be conformant with the network.
> Completely plaintext transport protocol haven't helped make them
> deployable (again see SCTP).
> 
> Tom
> 
> > Thanks, --David
> >
> > > -----Original Message-----
> > > From: tsvwg <[e-mail]> On Behalf Of Tom Herbert
> > > Sent: Monday, March 16, 2020 2:53 PM
> > > To: Gorry Fairhurst
> > > Cc: [e-mail]
> > > Subject: Re: [tsvwg] New Version of draft-ietf-tsvwg-transport-encrypt (12)
> > >
> > >
> > > [EXTERNAL EMAIL]
> > >
> > > On Mon, Mar 16, 2020 at 10:23 AM Gorry Fairhurst
> <[e-mail]>
> > > wrote:
> > > >
> > > > 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.
> > > >
> > >
> > > Hi Gorry,
> > >
> > > David's text only softens the language that implies extension headers
> > > are not considered a viable option.
> > >
> > > May I suggest this text?:
> > >
> > > IPv6 Hop-by-Hop options [RFC8200] could be used by hosts to convey and
> > > signal arbitrary information to intermediate network devices. This
> > > potentially includes the ability to selectively expose transport layer
> > > information in network headers that is useful to network node. The use
> > > of Hop-by-Hop options to expose transport information has several
> > > advantages over the practice of extracting information directly from
> > > transport layer headers:
> > >
> > > * Hop-by-Hop options work with any transport protocol. Intermediate
> > > nodes do not have to worry about parsing various transport protocols,
> > > they only need to handle the Hop-by-Hop option. This facilitates the
> > > deployment of new transport protocols, use of encrypted transport
> > > protocols, arbitrary encapsulations that contain transport protocols,
> > > etc. This eschews the use Deep Packet Inspection (DPI) since
> > > intermediate devices only neet to process network layer headers
> > > (Hop-by-Hop options immediately follow the IPv6 header).
> > >
> > > * Hop-by-Hop options are explicit so that the end host or application
> > > control their content. This means that the user can decide what
> > > transport layer information is exposed and when. For instance, if the
> > > destination of a communication is in the local trusted network then
> > > the user may be willing to expose some transport information per the
> > > network's request in order to receive some tangible benefit, but for
> > > some random destination in the Internet minimal exposure of
> > > information is more likely desired.
> > >
> > > * Hop-by-Hop options are the only protocol conformant method to expose
> > > arbitrary information to the network (IPv4 options also are, but they
> > > are too limited). Their design conforms to the end-to-end architecture
> > > of the Internet, and they are robust. Other methods, in particular DPI
> > > to extract information from transport layer headers, are not
> > > conformant nor robust and are a cause of protocol ossification which
> > > is a primary motivation for encrypting transport headers.
> > >
> > > Some networks drop extension headers because of non-conformant
> > > intermediate devices. In order to make their use viable, fixes and
> > > workarounds are needed. Once class of workarounds would involving
> > > probing to destinations to deduce what paths are amenable use of
> > > Hop-by-Hop options extension headers (this might be in the same spirit
> > > of Happy Eyeballs for IPv6).
> > >
> > >
> > >
> > > > On 16/03/2020 17:21, Tom Herbert wrote:
> > > > > On Mon, Mar 16, 2020 at 10:10 AM Gorry Fairhurst
> > > <[e-mail]> wrote:
> > > > >>
> > > > >> On 16/03/2020 16:28, Tom Herbert wrote:
> > > > >>> On Mon, Mar 16, 2020 at 8:54 AM Gorry Fairhurst
> > > <[e-mail]> wrote:
> > > > >>>> On 16/03/2020 15:21, Tom Herbert wrote:
> > > > >>>>
> > > > >>>> On Mon, Mar 16, 2020 at 7:52 AM Gorry Fairhurst
> > > <[e-mail]> wrote:
> > > > >>>>
> > > > >>>> On 16/03/2020 13:06, Eric Rescorla wrote:
> > > > >>>>
> > > > >>>>
> > > > >>>>
> > > > >>>> On Mon, Mar 16, 2020 at 2:36 AM Gorry Fairhurst
> > > <[e-mail]> 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
> >