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

[Sebastian Moeller <[e-mail]>]

Hi List,

> On Jul 2, 2023, at 14:28, Erik Auerswald <[e-mail]> wrote:
> 
> 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.

	[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.


	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)

Regards
	Sebastian


*) modulo rate-limiting and de-prioritization, and similar operations at the remote end.


> 
> Regards,
> Erik