Re: [tsvwg] [saag] Fwd: Last Call: <draft-ietf-tsvwg-transport-encrypt-19.txt> (Considerations around Transport Header Confidentiality, Network Operations, and the Evolution of Internet Transport Protocols) to Informational RFC

Thanks Fernando,

Please see below:

On 10/02/2021 22:53, Black, David wrote:
> Adding TSVWG list, Thanks, --David
>
> -----Original Message-----
> From: saag <saag-bounces@ietf.org> On Behalf Of Fernando Gont
> Sent: Wednesday, February 10, 2021 5:08 PM
> To: Benjamin Kaduk; saag@ietf.org
> Subject: Re: [saag] Fwd: Last Call: <draft-ietf-tsvwg-transport-encrypt-19.txt> (Considerations around Transport Header Confidentiality, Network Operations, and the Evolution of Internet Transport Protocols) to Informational RFC
>
>
> [EXTERNAL EMAIL]
>
> Hello, Ben,
>
> For some reason, I failed to find the relevant email message on the last-call list :-/
>
>
> Some very specific comments on some parts:
>
> * Section 5.1:
>
>      For example, an
>      endpoint that sends an IPv6 Hop-by-Hop option [RFC8200] can provide
>      explicit transport layer information that can be observed and used by
>      network devices on the path.
>
> This is not as easy as it sounds. If you convey this information in
> multiple places (e.g. the transport protocol itself (that you cannot
> see), and e.g. IPv6 options, then the two might not much -- and devices
> could e.g. enforce a security policy on contents (e.g., the info in the
> IPv6 options), that the destination endpoint might possibly e.g. ignore.

This sounds similar to the case of explicitly exposing other 
information. In this case, the network will make decisions on what it 
sees or infers - without knowledge of the contents of the encrypted part 
Would you like to propose some text to help explain this?

> * Section 5.1:
>
>      Protocol methods can be designed to
>      probe to discover whether the specific option(s) can be used along
>      the current path, enabling use on arbitrary paths.
>
> This might be a problem of "English as a second language", but the above
> text sounds to me like you can enable use of this feature on arbitrary
> paths.... where's I'd probably argue that what you can do is to
> *disable* the feature on paths where the feature cannot be used, such
> that you may still communicate (albeit without using the aforementioned
> feature).
>
> Another simpler fix might be s/arbitrary/specific/

The whole para currently reads:

    An arbitrary path can include one or more network devices that drop
    packets that include a specific header or option used for this
    purpose (see [RFC7872]).  This could impact the proper functioning of
    the protocols using the path.  Protocol methods can be designed to
    probe to discover whether the specific option(s) can be used along
    the current path, enabling use on arbitrary paths.

I think this last sentence can indeed be improved, and I suggest 
something like:

    Protocol methods can be designed to
    probe to discover whether the specific option(s) can be used along
    the current path, enabling or disabling their use on the path.

Is that better?

> At the end of the day, when it comes to new features (i.e., features
> that folks do not currently rely on), the folks operating the networks
> trump everything else.  -- same as when folks decide to tunnel things on
> e.g. UDP, but then find out they are rate limited....
Agree.
> Thanks,
> Fernando
>
Best wishes,

Gorry

>
>
> On 10/2/21 03:25, Benjamin Kaduk wrote:
>> You may recall that this draft has a storied history, and that the results
>> of the third WGLC included adding a note for the IETF LC that the IETF
>> consensus (or lack thereof) is unknown and needs to be explicitly
>> determined for this draft
>> (https://mailarchive.ietf.org/arch/msg/saag/PQfMkaORBJRE3zkKC8UfLv8JYhU/).
>>
>> -Ben
>>
>> On Fri, Feb 05, 2021 at 04:39:58PM -0800, The IESG wrote:
>>> The IESG has received a request from the Transport Area Working Group WG
>>> (tsvwg) to consider the following document: - 'Considerations around
>>> Transport Header Confidentiality, Network
>>>      Operations, and the Evolution of Internet Transport Protocols'
>>>     <draft-ietf-tsvwg-transport-encrypt-19.txt> as Informational RFC
>>>
>>> The IESG plans to make a decision in the next few weeks, and solicits final
>>> comments on this action. Please send substantive comments to the
>>> last-call@ietf.org mailing lists by 2021-02-19. Exceptionally, comments may
>>> be sent to iesg@ietf.org instead. In either case, please retain the beginning
>>> of the Subject line to allow automated sorting.
>>>
>>> Abstract
>>>
>>>
>>>      To protect user data and privacy, Internet transport protocols have
>>>      supported payload encryption and authentication for some time.  Such
>>>      encryption and authentication is now also starting to be applied to
>>>      the transport protocol headers.  This helps avoid transport protocol
>>>      ossification by middleboxes, mitigate attacks against the transport
>>>      protocol, and protect metadata about the communication.  Current
>>>      operational practice in some networks inspect transport header
>>>      information within the network, but this is no longer possible when
>>>      those transport headers are encrypted.
>>>
>>>      This document discusses the possible impact when network traffic uses
>>>      a protocol with an encrypted transport header.  It suggests issues to
>>>      consider when designing new transport protocols or features.
>>>
>>>
>>>
>>>
>>> The file can be obtained via
>>> https://datatracker.ietf.org/doc/draft-ietf-tsvwg-transport-encrypt/
>>>
>>>
>>>
>>> No IPR declarations have been submitted directly on this I-D.
>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> IETF-Announce mailing list
>>> IETF-Announce@ietf.org
>>> https://www.ietf.org/mailman/listinfo/ietf-announce
>> _______________________________________________
>> saag mailing list
>> saag@ietf.org
>> https://www.ietf.org/mailman/listinfo/saag
>>
>