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

From: <[email-masked]>
Date: Wed, 8 Dec 2021 12:19:30 +0000

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) ..

(2) (nit)
OLD: at multiple levels, so, when when ...
NEW: at multiple levels, so, when ...

(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 ..

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

(2) You may change "token" to "nonce" to align with the udp-options I-D 

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

(4) (nit) s/reception of a specific received probe/reception of a specific probe

(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. 

(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]).

(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. 

* Section 7: I would a mention about nonce guards for off-path attacks.

Thank you. 

Cheers,
Med

> -----Message d'origine-----
> De : I-D-Announce <[email-masked]> De la part de internet-
> [email-masked]
> Envoyé : jeudi 25 novembre 2021 16:42
> À : [email-masked]
> Cc : [email-masked]
> 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
> [email-masked]
> 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.

---

From: Gorry Fairhurst <[email-masked]>
Date: Thu, 9 Dec 2021 10:22:26 +0000

> NEW: An upper PL (or application) ..
Done in author's version.
> NEW: at multiple levels, so, when ...
Done in author's version.
> 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.

> (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
> 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.
> Med

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

Best wishes,

Gorry

---

From: <[email-masked]>
Date: Thu, 9 Dec 2021 14:00:47 +0000

Hi Gorry, 

Please see inline. 

Cheers,
Med

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

> > (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/
> /Section 6 of I-D.ietf-tsvwg-udp-options"/Section 5.11 of I-D.ietf-tsvwg-
> udp-options"/
> 
> > (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:
> > (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
> >
>        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
>            An alternative format is permitted for a probe that confirm

[Med] change to "confirms"

>      included by the sending upper layer protocol and the values of nonces
> need to be coordinated
> >> De : I-D-Announce <[email-masked]> De la part de
> >> internet- [email-masked] Envoyé : jeudi 25 novembre 2021 16:42 À :
> >> [email-masked] Cc : [email-masked] Objet : I-D Action:
> >> draft-ietf-tsvwg-udp-options-dplpmtud-02.txt
> >>
> >>

---

From: Gorry Fairhurst <[email-masked]>
Date: Thu, 9 Dec 2021 14:48:25 +0000

> Med
See below marked GF2,
> [Med] seems this one was missed.
GF2, I had and now included.
> [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…

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?

> [Med] I guess you meant 8085.
GF2, yes.
>   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.
> [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.
> [Med] Please add a pointer to Section 4.1 of RFC8899.
GF2, added that ref.
> [Med] change to "confirms"
GF2, done.
Best wishes,

Gorry

-- 
G. Fairhurst, School of Engineering

---

From: <[email-masked]>
Date: Thu, 9 Dec 2021 15:23:45 +0000

Re-,

Please see inline. 

Cheers,
Med

> Envoyé : jeudi 9 décembre 2021 15:48
[snip]
> >> 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.

[Med] Fully agree if the nonce is always random.

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

[Med] I thought you were suggesting that a given sender will generate a nonce once, and then sequentially increment it when it has to send a REQ. I think this is suboptimal compared to generating a random nonce to uniquely identify each REQ. Sequentially incrementing the nonce may not be a good guard especially if a host sends regulars probes to check an increase of the PLPMTU (the draft says, this happens "From time to time"). 

I don't think a sequence number is needed with a 4-byte nonce.

---

From: Gorry Fairhurst <[email-masked]>
Date: Mon, 13 Dec 2021 10:37:52 +0000

On 09/12/2021 15:23, [email-masked] wrote:
> [Med] I thought you were suggesting that a given sender will generate a nonce once, and then sequentially increment it when it has to send a REQ.

GF3: I'm suggested that I think this is OK to provide off-path attack 
protection. Without knowledge of the starting value of the token/nonce, 
an attacker is statistically unable to forge a packet that  causes the 
sender to react,

An on-path attacker can see any plaintext token/nonce and could forge 
such a pacekt, however this attacker can also see the probe requests, 
and could forge an apparently valid response or ICMP PTB packet or 
selectively drop probe packets - all of which would change the sender 
state. This could potentially force a reduction in the packet size - and 
with some effort could black hole the traffic. An on-path device can 
always do this - without attacking DPLPMTUD.

>   I think this is suboptimal compared to generating a random nonce to uniquely identify each REQ. Sequentially incrementing the nonce may not be a good guard especially if a host sends regulars probes to check an increase of the PLPMTU (the draft says, this happens "From time to time").

GF3: I'm not sure this add much protection - if someone really wants 
protection from on-path attacks, then the design could use an encrypted 
probe packet contents to avoid mis-directing the search logic - (but 
still on-path devices could selectively drop). A downside is that this 
makes the implementation at the sender more complex - where it might 
need to maintain a list of currently valid nonce/tokens to accommodate 
delay and reordering by the path.

Still, the current proposal does not constraint any way to select a 
valid nonce/token for each probe, so you could still do that within the 
spec.

I may have misunderstood or have missed something else, if so, do let me 
know.

> I don't think a sequence number is needed with a 4-byte nonce.
GF3: I agree - we need tro uniguely identify probes, this can be done 
using the 4-byte field.
Gorry