Re: [tsvwg] Review of draft-ietf-tsvwg-udp-options-32

[Sebastian Moeller <[e-mail]>]

Hi Christian,

> On 10. Apr 2024, at 04:11, Christian Huitema <[e-mail]> wrote:
> 
> 
> 
> On 4/9/2024 3:41 PM, Joe Touch wrote:
>>> On Apr 9, 2024, at 12:17 PM, Christian Huitema<[e-mail]>  wrote:
>>> the maximum segment size option.
>>> Anything that adds clear text to an already encrypted packet should be considered an attack.
>> That would make all TCP or IP options used with TLS an attack. Please let us know when those are addressed.
> 
> But there have indeed been attacks against clear text TCP headers, from SYN attacks to RST to data insertion. There are also lots of intermediaries that like to mess with the TCP headers, for example rewriting flow control parameters or the maximum segment size option.

[SM] This on path modification of the MSS option can be quite positive, e.g. if used to avoid fragmentation... Sure it can be abused, but so can be almost everything... it is not that changing a single bit in a QUIC packet will have no consequences (yes, QUICK will notice and drop the packet, but that in itself is a consequence).

> These have been addressed over time in TCP.
> 
> These attacks are largely mitigated in encrypted transports like QUIC. Adding clear text options to encrypted transports will bring new attack scenarios, which will typically only be discovered over time and which will necessitate ad hoc mitigations.

[SM] While I am not opposed to having options that can be read and modified by the network, I guess I agree that not all options fall into that cartegory. But as mentioned here we have a decent conceptual solution for those fields that should stay private and for those that should be read-only.

Most of this seems moot anyway, without a real user for UDP options none of these issues are likely to crop up in real life. And honestly, seeing these options developed without real users to actually implement und confirm their utility makes me believe they will not be a perfect fit anyway. So in the end UDP options might serve as an example set of potential generic components a real-life UDP-based protocol might be inspired from and less of a toolkit to use directly.

> 
> -- Christian Huitema
>