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

["Black, David" <[e-mail]>]

Adding TSVWG list, Thanks, --David

-----Original Message-----
From: saag <[e-mail]> On Behalf Of Fernando Gont
Sent: Wednesday, February 10, 2021 5:08 PM
To: Benjamin Kaduk; [e-mail]
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.


* 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/


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



Thanks,
Fernando




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
>> [e-mail] mailing lists by 2021-02-19. Exceptionally, comments may
>> be sent to [e-mail] 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
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/ietf-announce
> 
> _______________________________________________
> saag mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/saag
> 


-- 
Fernando Gont
e-mail: [e-mail] || [e-mail]
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1



_______________________________________________
saag mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/saag