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

["[e-mail]" <[e-mail]>]

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

—
Joe Touch, temporal epistemologist
www.strayalpha.com

> On Jan 6, 2022, at 7:32 AM, Black, David <[e-mail]> wrote:
> 
> 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 <[e-mail] <mailto:[e-mail]>> On Behalf Of [e-mail] <mailto:[e-mail]>
> Sent: Thursday, January 6, 2022 10:26 AM
> To: [e-mail] <mailto:[e-mail]>
> Cc: Gorry Fairhurst; [e-mail] <mailto:[e-mail]>
> Subject: Re: [tsvwg] I-D Action: draft-ietf-tsvwg-udp-options-dplpmtud-02.txt
>  
> [EXTERNAL EMAIL] 
> 
> 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 [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
>  
> —
> 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, [e-mail] <mailto:[e-mail]> wrote:
>  
> ...
> 
> 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.