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

[Gorry Fairhurst <[e-mail]>]

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.

---

Gorry