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

[[e-mail]]

Hi Gorry, 

Please see inline. 

Cheers,
Med

> -----Message d'origine-----
> De : Gorry Fairhurst <[e-mail]>
> Envoyé : jeudi 9 décembre 2021 11:22
> À : BOUCADAIR Mohamed INNOV/NET <[e-mail]>
> Cc : [e-mail]
> Objet : Re: I-D Action: draft-ietf-tsvwg-udp-options-dplpmtud-02.txt
> 
> 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.

[Med] seems this one was missed. 

> > * 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 

[Med] If you have the initial random value close to the nonce bounds (0, 2^32 - 1), randomness does not add much because of nonce wraps around. A more efficient approach to prevent off-path attacks is to use random nonces per request. 

(RFC9085 gives one example of a

[Med] I guess you meant 8085.

> random port field)?

[Med] Random source port numbers may not be sufficient for IPv4 as the randomness can be nullified by an on-path NAT in some cases. Think about NATs that assign contiguous port set for an internal source. Having random nonces is much more efficient.  

 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

[Med] why RES is included in a probe packet? Also, why this is discussed given that the section title is about processing a received probe?

. This implements
>         "Probing using padding data"

[Med] Please add a pointer to Section 4.1 of RFC8899. 

, 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

[Med] change to "confirms"

>        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/
> >>


_________________________________________________________________________________________________________________________

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.