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

[Erik Auerswald <[e-mail]>]

Hi,

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:
> > The ID-Cutoff deadline of 2023-07-10, and I thought it might be
> > helpful for us all to see where we are !
> > 
> > The current active issues that I saw are (please update as needed):
> 
> I have read draft-ietf-tsvwg-udp-options-22 and would like to add some
> issues to the list.
> […]
> * 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.

I did not expect that the security considerations introduce additional
requirements on the protocol.  I would have expected all the requirements
to be described in the specification.  The security considerations then
consider the security implications of the specified protocol and suggest
mitigations, but do not change the protocol.

Regards,
Erik