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

[Tom Herbert <[e-mail]>]

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