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

[Tom Herbert <[e-mail]>]

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
>