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

[Tom Herbert <[e-mail]>]

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. 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? 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.

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

> (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