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

[Gorry Fairhurst <[e-mail]>]

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.

> 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