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

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

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