Re: [saag] [tsvwg] 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

[Fernando Gont <[e-mail]>]

On 11/2/21 06:50, Gorry Fairhurst wrote:
[....]
>>
>> 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.

Yes. ANything where you have two copies of the same information, and 
different parties are likely to act on different copies, is prone to the 
same thing.

(I guess, unless you can enforce that the two match, and have a strong 
requirement that all parties check that, and otherwise drop the packet 
-- something that in practice, many don't)



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

I'd be happy to. I'll craft text and come back to you on this one.




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

That's perfect, and indeed addressed my comment.

Thanks!

Regards,
-- 
Fernando Gont
SI6 Networks
e-mail: [e-mail]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492