Re: [tsvwg] Remaining issues for draft-ietf-tsvwg-udp-options-22 - REQ and RES description

[Erik Auerswald <[e-mail]>]

Hi all,

On Sun, Jul 02, 2023 at 11:15:41PM +0200, Erik Auerswald wrote:
> On Sun, Jul 02, 2023 at 09:49:55PM +0100, Gorry Fairhurst wrote:
> > 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.)

I would like to suggest the following re-wording of section 9.7:

------------8<------------------------8<------------------------8<------
9.7. Echo Request (REQ) and Echo Response (RES)

   The echo request (REQ, Kind=6) and echo response (RES, Kind=7)
   options provide a means for applications to use UDP options
   to provide UDP packet-level acknowledgements.  If enabled, UDP
   options deliver a REQ to the application.  The application can then
   decide if and when to send a packet including a corresponding RES.
   One such use is described as part of the UDP options variant of
   packetization layer path MTU discovery (PLPMTUD) [Fa22].

   The options both have the format indicated in Figure 14, in which
   the token has no internal structure or meaning.  A RES option
   echoes the token received in the corresponding REQ option.

                  +--------+--------+------------------+
                  |  Kind  | Len=6  |      token       |
                  +--------+--------+------------------+
                    1 byte   1 byte       4 bytes

                 Figure 14   UDP REQ and RES options format

   Each of these option kinds appears at most once in each UDP packet,
   as with other options. Note also that the FRAG option is not used
   when sending DPLPMTUD probes to determine a PLPMTU [Fa22].
------------>8------------------------>8------------------------>8------

> > >> […]

Regards,
Erik