[tsvwg] Re: TSVWG Consensus Call concerning draft-ietf-tsvwg-udp-options-18 - DUE, by 13th May 2024

[Sebastian Moeller <[e-mail]>]

Dear List

> On 7. May 2024, at 16:12, Gorry Fairhurst <[e-mail]> wrote:
> 
> This email starts a consensus call to confirm three topics related to draft-ietf-tsvwg-udp-options, as we complte the WGLC.
> 
> The chairs think that each of these topics have discussed by TSVWG during development of the draft. We now wish members of TSVWG to confirm theyr are content about the following three topics:
> 
> 
> 1. UDP Option are ONLY set and modified by the sender when it decides to add the Options to a packet.  Routers ought to forward packets with UDP Options without modification, the current text includes: "UDP Options MUST NOT be modified in transit".
> 
>  Is 1 OK for the WG?

[SM] See 3. below, unless we find a way for the receiver to assert that a packet was not modified, I wqould think it miore pragmatic to go for 'SOULD NOT'...

> 
> 
> 2. Since the Options data is not encrypted, a device on the network path might read this option information. Regarding this, the current text includes: "UDP options are intended for use only by the transport endpoints. They are no more (or less) appropriate to be modified in-transit than any other portion of the transport datagram."
> 
>   Is 2 OK for the WG?

[SM] That wording is neither here nor there for me, if I want to do something like UDP equivalent of MSS clamping (as an example of a potentially useful manipulation of a datagram) this wording is not going to stop me. So do we want to allow such usages or not? Mind you the first sebtence implies read, but the 3rd sentence goes back to modification so cycles back to question 1.

> 
> 
> 3. UDP Options does not by itself provide any mechanism for a device to authenticate the format or contents of the options data, or to detect if the surplus area has been removed from a packet. Mechanisms to support encryption/authentication could separately be added (see section 9.9,9.10).
> 
>    Is 3 OK for the WG?

[SM] The consequence of 1 and 3 seems to be that the only defence against on-path manipulations is the wording  "UDP Options MUST NOT be modified in transit" and IMHO even more tricky the receiver has no way to actually detect such changes. This should not stand, either we allow on-path changes (no need to endorse them thjough) or we make UDP options sufficiently complete to detect them.

So I am a No on either 1. or 3.


Regards
	Sebastian



> 
> 
> Please send an email by 13th May to the list with a "Yes" if you agree with each topic, or provide input to help the chairs to assess the consensus of the group. We plan to include the final consensus as a part of our write-up when we submit the final revision of the ID with a request for publication.
> 
> Best wishes,
> 
> Gorry & Marten
> (TSVWG Co-Chairs)
>