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

[Gorry Fairhurst <[e-mail]>]

On 09/12/2021 14:00, [e-mail] wrote:
> Hi Gorry,
>
> Please see inline.
>
> Cheers,
> Med
>
See below marked GF2,
>> -----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.
GF2, I had and now included.
>>> * 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.

GF2, Well I see the sender generating a sequence of probes... probably 
not many per RTT, and each carries a RES option and the nonce. An 
off-path attacker will find it hard to guess a random nonce.

Probes need to be indentifiable uniquely in the case of path reordering 
or (unlikely) duplication. I'm suggesting successive probes could be 
numbered sequentially, to achieve this - but you could also use a PN 
sequence or whatever means to achieve uniqueness. I'm not sure I 
understand the issue?


>
> (RFC9085 gives one example of a
>
> [Med] I guess you meant 8085.
GF2, yes.
>
>> 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
I think the port used by UDP is up to the app/upper layer using UDP, so 
we don't need to discuss this - but we don't just rely on source port 
randomisation for protection.
>> 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?
GF2, it was REQ - my typp.
>
> . This implements
>>          "Probing using padding data"
> [Med] Please add a pointer to Section 4.1 of RFC8899.
GF2, added that ref.
>
> , 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"
GF2, done.
>>         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
>>
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.
>
-- 
G. Fairhurst, School of Engineering