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

["[e-mail]" <[e-mail]>]

On the points below:

> On Apr 9, 2024, at 11:25 AM, C. M. Heard <[e-mail]> wrote:
> 
>>> The backwards compatibility with UDP was considered important in the development of this Spec.
>> 
>> This point is absent, AFAIK in Section 16 of the draft now.

That’s because Section 16 is about why the options are for endpoints, not transit nodes. Again, that’s intended as advice to the IESG for reviewing future extensions or standards using UDP options. The can be made more clear in that section.


> Adding such a discussion is a reasonable request; IMO the best place would be Section 6 (Design Principles).

It’s already design principle #6 and further discussed in section 18 in detail. If there’s something additional needed, it would be useful to know what’s missing.

>  On Tue, Apr 9, 2024 at 10:16 AM Christian Huitema wrote:
>> On 4/9/2024 9:09 AM, Tom Herbert wrote:
>> > I believe that processing of the options is already opt-in. Accepting
>> > UDP surplus area (at least ignoring it and not dropping packet) and the
>> > checksum processing I described are currently mandatory.
>> 
>> And that's probably what need to change before this draft is published.
>> Using the surplus area without the explicit consent of the application
>> is an attack. The proper way to stop such attacks is to drop the whole
>> packet, because only that inflicts a cost to the attacker.
> 
> I disagree that use of the surplus area without the explicit consent of the receiver automatically constitutes an attack, as long as the surplus area is ignored by default.

+1

Receipt of something you didn’t expect isn’t an attack per se. It’s an attack when it creates load AND cannot be avoided. UDP options are silently ignored unless enabled, so the only “load” to endpoints who don’t want to participate is space in the IP packet payload. Sec 24 already explains what to do if options are enabled and their use is inferred as an attack.

Joe