Re: [tsvwg] Remaining issues for draft-ietf-tsvwg-udp-options-22

[Gorry Fairhurst <[e-mail]>]

I am unsure I understand this thread: As far as I know, the REQ/RES pair 
is designed to support DPLPMTUD, running over UDP Options.

On 02/07/2023 20:31, Christian Huitema wrote:
>
> On 7/2/2023 6:01 AM, Sebastian Moeller wrote:
>>     [SM] In which case (no immediate response required) this thing 
>> should not be called an echo, as it neither mimics how a real echo 
>> works nor how ICMP echo requests mostly* operate. I note that the REQ 
>> and RES monikers seem fine as they do not contain "echo" once 
>> expanded, but the paragraph text in the draft might be changed if 
>> "delayed/eventual response" is expected as the default mode. And I 
>> think that:
>>     "but no options (including ECHO) ever initiate UDP responses in 
>> the absence of user transmission."
>> pretty much means delayed response is the default.
>
> And I hope that it stays the default! UDP option is by default a clear 
> text protocol. It is very easy for third parties to spoof UDP options 
> requests. We would have a pretty major issue if spoofed packets could 
> generate responses!

UDP Options itself doesn't generate the response, it passes the REQ 
upwards to the protocol that does and that sends the RES option. That 
said, the DLPMTUD for UDP Options ID already has text saying that a RES 
is only generated when DPLPMTUD has been enabled, which amongst other 
things means that the pair of ports has been bound by an application, 
and the application chooses to enable DPLPMTUD, if not, there is no 
response.

>>     For security considerations I want to ask whether it could be 
>> helpful to note in the draft that the REQ option is (considerably) 
>> larger (as expected e.g. for DPLPMTUD probes) than the RES response, 
>> so this mechanism can not be used with spoofed addresses to amplify 
>> an attack but rather attenuate it (at least on the byte volume level)
>
> That too is a major issue. This is 2023, and we have decade of 
> experience with DDOS amplification. We cannot introduce a protocol 
> that facilitate DDOS amplification!

What is the major issue? A REQ is a probe packet of specified size; a 
RES is just an Option with no "probe data" - carried in a single UDP 
datagram or included in a a UDP datagram with some other data sent by 
the remote endpoint.  How is that a major issue?

>
> I think that if such facility remained in the protocol, we would see 
> firewalls programmed to systematically drop any packet carrying UDP 
> options.
>
> -- Christian Huitema
>
Why would this require firewalls to drop a UDP datagram?

Gorry