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

[Erik Auerswald <[e-mail]>]

Hi all,

On Sun, Jul 02, 2023 at 09:49:55PM +0100, Gorry Fairhurst wrote:
> 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.

IMHO this is not obvious from just reading the draft, therefore I suggest
to add a sentence to the description on REQ and RES to explicitly state
that no RES is generated automatically by a UDP Options implementation.

As far as I understand it now (after re-reading the drafts and the mailing
list discussion), using RES requires activation on a per-socket basis.
This can be done by a DPLPMTUD implementation after an application
activates DPLPMTUD for a "connection".

(I do not have a good suggestion for a formulation.)

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

AFAIUI even an activated RES could not be used for amplification, because
it does not echo the REQ packet, but only sends the 4 byte token from
the REQ (without any added padding).

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

IMHO the biggest risk is an unclear specification that might result in
implementations that do not follow the idea of UDP Options.  Thus my
asking for clarifications.

Regards,
Erik