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

["C. M. Heard" <[e-mail]>]

On Sat, Jul 1, 2023 at 1:45 PM Erik Auerswald wrote:
> On Thu, Jun 29, 2023 at 06:28:07PM +0200, Erik Auerswald wrote:
> > On Mon, Jun 26, 2023 at 10:03:00AM +0100, Gorry Fairhurst wrote:
> > * Section 22: The second to last paragraph on page 35 states that
> >   "no options (including ECHO) ever initiate UDP responses in the
> >   absence of user transmission."  I think "ECHO" means "REQ", but
> >   draft-ietf-tsvwg-udp-options-dplpmtud-08 allows for REQ to create
> >   responses without use data, specifically when DPLPMTUD is implemented
> >   inside the "Packetization Layer of UDP Options".  This seems to be
> >   inconsistent.
>
> The description of REQ and RES in section 9.7 does not mention that the
> RES option is only to be sent if some other data is to be sent anyway.
> To the contrary, the description
>
>   "The echo request (REQ, Kind=6) and echo response (RES, Kind=7)
>    options provide a means for UDP options to be used to provide UDP
>    packet-level acknowledgements."
>
> seems to suggest that RES is sent as an acknowledgement when there would
> be none otherwise.  Today, request-response protocols use the receipt
> of the response as acknowledgement for the receipt of the request by
> the receiver (e.g., DNS and RADIUS do this).  The additional capability
> REQ and RES options could provide would be to elicit a response when
> there would be none otherwise.  This is definitely the assumption made
> for DPLPMTUD implemented in the "UDP Options Packetization Layer" (as
> opposed to the application) in draft-ietf-tsvwg-udp-options-dplpmtud-09.

Good catch.

I did actually flag the issue with the Security Considerations in
https://mailarchive.ietf.org/arch/msg/tsvwg/ocDWz4jWZdqVP6CTuAhsBXer2Bc/:

=======================================================================
In draft-ietf-tsvwg-udp-options-22 Section 22, 3rd paragraph, we see:

   UDP options create new potential opportunities for DDOS attacks,
   notably through the use of fragmentation. Except when enabled, UDP
   options cause no additional work at the receiver. At most, the
   required options (if enabled) result in a responding option in the
   next transmitted packet, but no options (including ECHO) ever
   initiate UDP responses in the absence of user transmission.

Corrected:

   UDP options create new potential opportunities for DDOS attacks,
   notably through the use of fragmentation. When enabled, UDP options
   may cause some additional work at the receiver; however, of the
   must-support options, only REQ (when used on a DLPMTUD probe [Fa22])
   will initiate a UDP response in the absence of a user transmission.

Note that [Fa22] needs to be updated to [Fa23].

This comment was made originally against -19 on 27-Jan-2023 but was not
addressed.
=======================================================================

However, I didn't mention the need to bring this up in Section 9.7

Perhaps a reference to the last paragraph in Section 6 of
draft-ietf-tsvwg-udp-options-dplpmtud would help. See

https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-udp-options-dplpmtud#name-examples-with-different-rec

I think this applies no matter whether DLPMTUD is implemented within
the UDP transport service or by an upper layer protocol or application.

Mike Heard