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

[Erik Auerswald <[e-mail]>]

Hi,

On Sun, Jul 02, 2023 at 09:11:55AM +0100, Gorry Fairhurst wrote:
> On 01/07/2023 22:39, C. M. Heard wrote:
> >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
> 
> I wonder if it may be better to explain this as when "explicitly" enabled:
> 
> NEW:
> 
>    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 explicitly enabled
> 
>    for a DLPMTUD probe (Section 6 of [Fa22])
>    will initiate a UDP response in the absence of a user transmission.

Yes, I think that would be better for the security considerations section.
I would suggest to designate DPLPMTUD as an example by inserting "e.g., "
directly after the opening parenthesis:

    (e.g., when explicitly enabled for DPLPMTUD probing (Section 6 of
    [Fa22]))

I still think that this behavior needs to be explicitly described in
the sections before the security considerations.

The idea that REQ does in general not result in RES, even after enabling
UDP Option processing, unless application data were to be sent from the
receiver of the REQ option irrespective of this REQ, or unless some
additional mechanism (e.g., a DPLPMTUD State Machine sitting between
the application and UDP Options) were to process the REQ and create a
response including a RES, does not seem to be obvious from reading the
UDP Options specification as currently written.  I'd say that it should
be made obvious.

Regards,
Erik