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

From: <[email-masked]>
Date: Thu, 6 Jan 2022 08:25:09 +0000

Hi Gorry,

Thank you for the clarification. 

Please see inline.

Cheers,
Med

> -----Message d'origine-----
> De : Gorry Fairhurst <[email-masked]>
> Envoyé : lundi 13 décembre 2021 11:38
> À : BOUCADAIR Mohamed INNOV/NET <[email-masked]>
> Cc : [email-masked]
> Objet : Re: [tsvwg] I-D Action: draft-ietf-tsvwg-udp-options-dplpmtud-
> 02.txt
> 
> On 09/12/2021 15:23, [email-masked] wrote:
> > Re-,
> >
> > Please see inline.
> >
> > Cheers,
> > Med
> >
> >> -----Message d'origine-----
> >> De : Gorry Fairhurst <[email-masked]> Envoyé : jeudi 9 décembre
> >> 2021 15:48 À : BOUCADAIR Mohamed INNOV/NET
> >> <[email-masked]> Cc : [email-masked] Objet : Re: I-D
> >> Action: draft-ietf-tsvwg-udp-options-dplpmtud-02.txt
> >>
> >>
> > [snip]
> >>>> 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.
> > [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.
> 
> 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.
> 

[Med] The attack I had in mind is a misbehaving node that is on-path for a first probe query from a sender. That misbehaving node can then easily guess the nonce for subsequent probes from that sender even if these probes are not transiting via the misbehaving node (off-path attack).

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

[Med] ACK.

_________________________________________________________________________________________________________________________

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: "[email-masked]" <[email-masked]>
Date: Thu, 6 Jan 2022 07:26:21 -0800

Hi, all,

AFAICT, it’s a mistake to try to expect security from a mechanism not expressly intended to deliver that.

It’s also a mistake to force the use of “random” values to imply security; randomness is not readily available at the speeds needed in most systems (e.g., True RNGs inside ARM processors operate at roughly 10 Kbps (https://developer.arm.com/documentation/100976/0000/Introduction/Features <https://developer.arm.com/documentation/100976/0000/Introduction/Features>), which would limit this approach for DPLPMTUD to just over 300 packets/sec.

As Gorry noted, for off-path issues, an arbitrary starting point is probably more than sufficient; that should never be referred to as ‘random’.

Joe

—
Joe Touch, temporal epistemologist
www.strayalpha.com

> On Jan 6, 2022, at 12:25 AM, [email-masked] wrote:
> 
>> ...
>>

---

From: "Black, David" <[email-masked]>
Date: Thu, 6 Jan 2022 15:32:32 +0000

The crucial property to be achieved is that an attacker can't predict the values used, and I'll agree to disagree with Joe on whether/how to use the word "security" to describe that property.

That property is definitely implied by "random"… so, if a different word is used, additional text is in order to indicate that the values are unpredictable to an external observer.

Thanks, --David

From: tsvwg <[email-masked]> On Behalf Of [email-masked]
Sent: Thursday, January 6, 2022 10:26 AM
To: [email-masked]
Cc: Gorry Fairhurst; [email-masked]
Subject: Re: [tsvwg] I-D Action: draft-ietf-tsvwg-udp-options-dplpmtud-02.txt

[EXTERNAL EMAIL]
Hi, all,

It’s also a mistake to force the use of “random” values to imply security; randomness is not readily available at the speeds needed in most systems (e.g., True RNGs inside ARM processors operate at roughly 10 Kbps (https://developer.arm.com/documentation/100976/0000/Introduction/Features [developer.arm.com]<https://urldefense.com/v3/__https:/developer.arm.com/documentation/100976/0000/Introduction/Features__;!!LpKI!y41EgyHqgDKN7WvhMs2j3TEykDf3CWPpfrbb3qLHn1gLZv0vrLbg0vn-J2OE0l69$>), which would limit this approach for DPLPMTUD to just over 300 packets/sec.

Joe

—
Joe Touch, temporal epistemologist
www.strayalpha.com [strayalpha.com]<https://urldefense.com/v3/__http:/www.strayalpha.com__;!!LpKI!y41EgyHqgDKN7WvhMs2j3TEykDf3CWPpfrbb3qLHn1gLZv0vrLbg0vn-JwM5TFKC$>

On Jan 6, 2022, at 12:25 AM, [email-masked]<mailto:[email-masked]> wrote:

...

---

From: "[email-masked]" <[email-masked]>
Date: Thu, 6 Jan 2022 07:38:59 -0800

FWIW, IMO, if you want to expect security, you should use security.

DPLPMTUD is not a security mechanism. It is on that point that I think using the term ’security’ for anything part of that mechanism is a mistake.

Note that no other part of UDP has this property except the true security options (ENCR/AUTH) - nor should it.

Joe

—

> On Jan 6, 2022, at 7:32 AM, Black, David <[email-masked]> wrote:
> 
> From: tsvwg <[email-masked] <mailto:[email-masked]>> On Behalf Of [email-masked] <mailto:[email-masked]>
> To: [email-masked] <mailto:[email-masked]>
> Cc: Gorry Fairhurst; [email-masked] <mailto:[email-masked]>
> It’s also a mistake to force the use of “random” values to imply security; randomness is not readily available at the speeds needed in most systems (e.g., True RNGs inside ARM processors operate at roughly 10 Kbps (https://developer.arm.com/documentation/100976/0000/Introduction/Features [developer.arm.com] <https://urldefense.com/v3/__https:/developer.arm.com/documentation/100976/0000/Introduction/Features__;!!LpKI!y41EgyHqgDKN7WvhMs2j3TEykDf3CWPpfrbb3qLHn1gLZv0vrLbg0vn-J2OE0l69$>), which would limit this approach for DPLPMTUD to just over 300 packets/sec.
>  
> www.strayalpha.com [strayalpha.com] <https://urldefense.com/v3/__http:/www.strayalpha.com__;!!LpKI!y41EgyHqgDKN7WvhMs2j3TEykDf3CWPpfrbb3qLHn1gLZv0vrLbg0vn-JwM5TFKC$>
> 
> 
> On Jan 6, 2022, at 12:25 AM, [email-masked] <mailto:[email-masked]> wrote:
>  
> ...
>

---

From: Gorry Fairhurst <[email-masked]>
Date: Thu, 6 Jan 2022 16:29:47 +0000

On 06/01/2022 15:38, [email-masked] wrote:
> DPLPMTUD is not a security mechanism. It is on that point that I think 
> using the term ’security’ for anything part of that mechanism is a 
> mistake.
>
> Note that no other part of UDP has this property except the true 
> security options (ENCR/AUTH) - nor should it.
>
> Joe
>
> —
> www.strayalpha.com <http://www.strayalpha.com>

Yes,  I agree with what you say.  A sequentiually numbered packet could 
allow probe packets to be forged in some cases, with an impact similar 
to other on-path attacks againt probe packets.It is anyway true that 
on-path attackers could drop/modify probe packets to seek to decrease 
the PMTU, or to modify probe packets in an attempt to blackhole traffic. 
I think we should note both of these things in the security 
consideratons, but if this is a real design consideration. A better 
design could use a security method (such as QUIC, IPsec or whatever 
witrh DPLPMTUD above that).

Joe - there is a related thought:

The UDP Options draft uses the work "nonce" for the 4B value used in 
this REQ/RES exchange, but the protocol doesn't need this to be a random 
nonce. I think it would be clearer in both drafts use the work "token" 
for the four byte value.

Could we change /nonce/token/ in section 6 of your draft to avoid 
implying this field has a particular formatted value? We could then make 
the same change for dplpmtud for udpo.

Gorry

Gorry

>> The crucial property to be achieved is that an attacker can't predict 
>> the values used, and I'll agree to disagree with Joe on whether/how 
>> to use the word "security" to describe that property.
>> That property is definitely implied by "random"… so, if a different 
>> word is used, additional text is in order to indicate that the values 
>> are unpredictable to an external observer.
>> Thanks, --David
>> *From:*tsvwg <[email-masked]>*On Behalf [email-masked]
>> *Sent:*Thursday, January 6, 2022 10:26 AM
>> *To:[email-masked]
>> *Cc:*Gorry Fairhurst;[email-masked]
>> *Subject:*Re: [tsvwg] I-D Action: 
>> draft-ietf-tsvwg-udp-options-dplpmtud-02.txt
>>
>> [EXTERNAL EMAIL]
>>
>> Hi, all,
>> It’s also a mistake to force the use of “random” values to imply 
>> security; randomness is not readily available at the speeds needed in 
>> most systems (e.g., True RNGs inside ARM processors operate at 
>> roughly 10 Kbps 
>> (https://developer.arm.com/documentation/100976/0000/Introduction/Features 
>> [developer.arm.com] 
>> <https://urldefense.com/v3/__https:/developer.arm.com/documentation/100976/0000/Introduction/Features__;!!LpKI!y41EgyHqgDKN7WvhMs2j3TEykDf3CWPpfrbb3qLHn1gLZv0vrLbg0vn-J2OE0l69$>), 
>> which would limit this approach for DPLPMTUD to just over 300 
>> packets/sec.
>> As Gorry noted, for off-path issues, an arbitrary starting point is 
>> probably more than sufficient; that should never be referred to as 
>> ‘random’.
>> Joe
>> —
>> www.strayalpha.com [strayalpha.com] 
>> <https://urldefense.com/v3/__http:/www.strayalpha.com__;!!LpKI!y41EgyHqgDKN7WvhMs2j3TEykDf3CWPpfrbb3qLHn1gLZv0vrLbg0vn-JwM5TFKC$>
>>
>>
>>     On Jan 6, 2022, at 12:25 AM,[email-masked]:
>>
>>         ...
>>

---

From: "Black, David" <[email-masked]>
Date: Thu, 6 Jan 2022 16:33:26 +0000

Joe,

> FWIW, IMO, if you want to expect security, you should use security.
And my opinion differs … and that difference of opinion doesn't matter here.

This is about robustness to potential interference from an off-line entity.  What matters is to state the property – values are unpredictable to an external observer

Thanks, --David

From: [email-masked] <[email-masked]>
Sent: Thursday, January 6, 2022 10:39 AM
To: Black, David
Cc: [email-masked]; Gorry Fairhurst; [email-masked]
Subject: Re: [tsvwg] I-D Action: draft-ietf-tsvwg-udp-options-dplpmtud-02.txt

[EXTERNAL EMAIL]

Joe

—
Joe Touch, temporal epistemologist
www.strayalpha.com [strayalpha.com]<https://urldefense.com/v3/__http:/www.strayalpha.com__;!!LpKI!xR5AFxpNY9Rxr0Oe7xCsoVx0Cq2tT7wwIdzFeaWD7m31Jh0jr5yf6xXruvrRPBAE$>

On Jan 6, 2022, at 7:32 AM, Black, David <[email-masked]<mailto:[email-masked]>> wrote:

Thanks, --David

From: tsvwg <[email-masked]<mailto:[email-masked]>> On Behalf Of [email-masked]<mailto:[email-masked]>
Sent: Thursday, January 6, 2022 10:26 AM
To: [email-masked]<mailto:[email-masked]>
Cc: Gorry Fairhurst; [email-masked]<mailto:[email-masked]>
Subject: Re: [tsvwg] I-D Action: draft-ietf-tsvwg-udp-options-dplpmtud-02.txt

[EXTERNAL EMAIL]
Hi, all,

Joe

—

...

---

From: Joe Touch <[email-masked]>
Date: Thu, 6 Jan 2022 08:45:02 -0800

> On Jan 6, 2022, at 8:33 AM, Black, David <[email-masked]> wrote:
> 
> 
> Joe,
>  
> This is about robustness to potential interference from an off-line entity. 

Only if you expect that from a protocol that hasn’t deployed security.  I don’t make that mistake.

> What matters is to state the property – values are unpredictable to an external observer

If that is what you want, encrypt.  But you can also achieve the end result (defeat spoofing) via authentication without using unpredictable values. 

My point is that this is trying to create security out of obscurity, which is inherently flawed.

We cannot expect to make every aspect of a nonencrypted, nonauthenticated protocol secure without using encryption or authentication.

Joe

---

From: Joe Touch <[email-masked]>
Date: Thu, 6 Jan 2022 08:47:14 -0800

Certainly.  I’m still plowing through the literally hundred or so messages of the option update discussion, trying to untangle what’s interdependent vs OBE, FYI.

This one is easy to roll in now, though.

Joe

> On Jan 6, 2022, at 8:30 AM, Gorry Fairhurst <[email-masked]> wrote:
> 
> The UDP Options draft uses the work "nonce" for the 4B value used in this REQ/RES exchange, but the protocol doesn't need this to be a random nonce. I think it would be clearer in both drafts use the work "token" for the four byte value. 
> 
> Could we change /nonce/token/ in section 6 of your draft to avoid implying this field has a particular formatted value? We could then make the same change for dplpmtud for udpo.
> 
> Gorry
>

---

From: <[email-masked]>
Date: Fri, 7 Jan 2022 10:08:17 +0000

Hi Joe, all,

Please see inline.

Cheers,
Med

De : Joe Touch <[email-masked]>
Envoyé : jeudi 6 janvier 2022 17:45
À : Black, David <[email-masked]>
Cc : BOUCADAIR Mohamed INNOV/NET <[email-masked]>; Gorry Fairhurst <[email-masked]>; [email-masked]
Objet : Re: [tsvwg] I-D Action: draft-ietf-tsvwg-udp-options-dplpmtud-02.txt

On Jan 6, 2022, at 8:33 AM, Black, David <[email-masked]<mailto:[email-masked]>> wrote:

Joe,

If that is what you want, encrypt.
[Med] You can  … but for off-path attacks, this can be fixed without encryption. That’s the same reason we have the following for ISNs, for example, in draft-ietf-tcpm-rfc793bis:

           The Initial Sequence Number.  The first sequence number used
           on a connection, (either ISS or IRS).  Selected in a way that
           is unique within a given period of time and is unpredictable
           to attackers.

That’s consistent with the reco in rfc3552#section-3.5

   However, designers are expected to give more weight to

   attacks which can be mounted by off-path attackers as well as on-path

   ones.

and also documents such as draft-irtf-pearg-numeric-ids-generation.

---

From: "[email-masked]" <[email-masked]>
Date: Fri, 7 Jan 2022 07:15:07 -0800

Med,

...
>            is unique within a given period of time and is unpredictable

I raised concerns with that text before. It exceeds the advise on which it is derived, notably RFC 6528 - which only provides an algorithm example, i.e., IF you are going to use such an algorithm, here’s one to use. It claims to update RFC793 but only in providing an *example* algorithm. Note the number of caveats about all aspects of this algorithm in the preceding text. 

>    attacks which can be mounted by off-path attackers as well as on-path

That RFC describes how to write security considerations sections, not specifically advise to designers (which is why this is just discussion text rather than stated as a normative recommendation).

> and also documents such as draft-irtf-pearg-numeric-ids-generation.  

That is an IRTF doc, not IETF.

Although I agree that this issue has been represented in other documents, it has consistently been noted as per RFC 6528:

   Good sequence numbers are not a replacement for cryptographic
   authentication, such as that provided by IPsec [RFC4301 <https://datatracker.ietf.org/doc/html/rfc4301>] or the TCP
   Authentication Option (TCP-AO) [RFC5925 <https://datatracker.ietf.org/doc/html/rfc5925>].