Re: [tsvwg] I-D Action: draft-ietf-tsvwg-udp-options-dplpmtud-02.txt

[Gorry Fairhurst <[e-mail]>]

On 08/12/2021 12:19, [e-mail] wrote:
> Hi Gorry,
>
> Thank you for taking into account the first set of comments. Please find below some additional comments. Most of them are nits.
>
> * Consider updating Section 2 to indicate that the reader should be familiar with the terms defined in Sections 2 and 5 of RFC8899.
> * Section 3:
> (1) (nit)
>
> OLD: An upper PL (or application ..
> NEW: An upper PL (or application) ..
Done in author's version.
> (2) (nit)
> OLD: at multiple levels, so, when when ...
> NEW: at multiple levels, so, when ...
Done in author's version.
> (3) (nit)
> OLD: This section describes packet formats and procedures for DPLPMTUD using UDP Options ..
> NEW: This document describes packet formats and procedures for DPLPMTUD using UDP Options ..

We changed to:

    The packet formats and procedures for DPLPMTUD using UDP Options are 
described in this document.

> * Section 4:
>
> (1) ".. as noted in bullet 2 of Section 2 in [RFC8899]": I checked that section but failed to see the relevant part to which this text refers to.
  Section /2/3/
> (2) You may change "token" to "nonce" to align with the udp-options I-D

Yes, good idea. Also to align:

/Section 6 of I-D.ietf-tsvwg-udp-options"/Section 5.11 of 
I-D.ietf-tsvwg-udp-options"/

> (3) (nit) s/to reception of a previously received REQ Option/to a received REQ Option

Reworded.

> (4) (nit) s/reception of a specific received probe/reception of a specific probe
/Reception of a RES Option confirms that a
         specific probe has been received by the remote UDP
         Options receiver./
> (5) "The initial value of the four byte token field SHOULD... ": not sure why "initial" is mentioned here. I would reword this to require that each nonce value is randomly generated.

This I wonder - if really this is necessary that all probes carry a 
random nonce, in the past we have managed with sequentially numbered 
probes - initialised with a hard to guess value (RFC9085 gives one 
example of a random port field)? You may wish to explain more, but for 
the moment I have replaced this by:

/The value of the four byte nonce field SHOULD be initialised to a 
randomised value/

> (6) (nit) s/A probe to confirm the path can support the BASE_PLPMTU see Section 5.1.4 of [RFC8899])/A probe to confirm the path can support the BASE_PLPMTU (Section 5.1.4 of [RFC8899]).
Done
>
> (7) Section 4.2.4 "Sending Packet Probes that include Application Data" says the following:
>
>     The method can be designed to only use probes that are formed of a
>     UDP datagram that includes application data (which could be
>     applications control information), padded to the required size and
>     include a RES Option.  This implements "Probing using padding data",
>     and avoids having to retransmit application data when a probe fails.
>
> There is a disconnect between the first sentence and the second one.

Yes - this wasn't really finished. The idea was to be simple, but allow 
people to

use application keep alives etc as probes in implementations in future, 
that may be

complicated - but would be more efficient for black hole detection.

I propose to restructure like this:

   <section title="Processing Probe Packets that do not include 
Application Data">
       <t>
       A simple implementation of the method might be designed
       to only probe packets formed of a UDP datagram that include no
       application data. Each probe packet is padded to the required
       probe size and including a RES Option. This implements
        "Probing using padding data", and avoids having to retransmit
       application data when a probe fails.
       In this use, the probe packets do not form a part of the end-to-end
       transport data and a receiver does not deliver them to the upper 
layer protocol.
       </t>
  </section>

<section title="Processing Probe Packets that include Application Data">
       <t>
       An implmentation always uses the format in the previous section
       when DPLPMTUD searches to increase the PLPMTU.</t>
       <t>
           An alternative format is permitted for a probe that confirm
       connectivity or that validates the path.
           These probes are permitted to carry application data.
       (The data is permitted because these probes perform blackhole 
detection
       and will therefore usually have a higher probability of successful
       transmission, similar to other packets sent by the upper layer 
protocol.)
        Section 4.1 of <xref target="RFC8899"></xref> provides a 
discussion of
     the merits and demerits of including application data. For example, 
this
     reduces the need to send additional datagrams.
     </t>
     <t> The probe could utilise
     a control message format defined by the upper layer protocol that 
does not need to
     be delivered reliably. The RES and REQ Options need to be
     included by the sending upper layer protocol and the values of 
nonces need to be coordinated
     with values used for other DPLPMTUD probe packets.
     The DPLPMTUD method tracks the transmission and reception of these 
probe packets.
     Probes with this format form a part of the end-to-end
     transport data and a receiver needs to deliver the RES and REQ 
Options to the
     upper layer protocol.</t>
</section>


> * Section 7: I would a mention about nonce guards for off-path attacks.
It does.
> Thank you.
>
> Cheers,
> Med

The above will be in the next revision, please let us know if anything 
else we should consider,

Best wishes,

Gorry

>> -----Message d'origine-----
>> De : I-D-Announce <[e-mail]> De la part de internet-
>> [e-mail]
>> Envoyé : jeudi 25 novembre 2021 16:42
>> À : [e-mail]
>> Cc : [e-mail]
>> Objet : I-D Action: draft-ietf-tsvwg-udp-options-dplpmtud-02.txt
>>
>>
>> A New Internet-Draft is available from the on-line Internet-Drafts
>> directories.
>> This draft is a work item of the Transport Area Working Group WG of the
>> IETF.
>>
>>          Title           : Datagram PLPMTUD for UDP Options
>>          Authors         : Godred Fairhurst
>>                            Tom Jones
>> 	Filename        : draft-ietf-tsvwg-udp-options-dplpmtud-02.txt
>> 	Pages           : 11
>> 	Date            : 2021-11-25
>>
>> Abstract:
>>     This document specifies how a UDP Options sender implements Datagram
>>     Packetization Layer Path Maximum Transmission Unit Discovery
>>     (DPLPMTUD) as a robust method for Path Maximum Transmission Unit
>>     discovery.  This method uses the UDP Options packetization layer.  It
>>     allows a datagram application to discover the largest size of
>>     datagram that can be sent across a specific network path.
>>
>>
>> The IETF datatracker status page for this draft is:
>> https://datatracker.ietf.org/doc/draft-ietf-tsvwg-udp-options-dplpmtud/
>>
>> There is also an htmlized version available at:
>> https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-udp-options-
>> dplpmtud-02
>>
>> A diff from the previous version is available at:
>> https://www.ietf.org/rfcdiff?url2=draft-ietf-tsvwg-udp-options-dplpmtud-02
>>
>>
>> Internet-Drafts are also available by anonymous FTP at:
>> ftp://ftp.ietf.org/internet-drafts/
>>
>>
>> _______________________________________________
>> I-D-Announce mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/i-d-announce
>> Internet-Draft directories: http://www.ietf.org/shadow.html or
>> ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> _________________________________________________________________________________________________________________________
>
> Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
>
> This message and its attachments may contain confidential or privileged information that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and delete this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
> Thank you.