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

[Gorry Fairhurst <[e-mail]>]

On 09/12/2021 15:23, [e-mail] wrote:
> Re-,
>
> Please see inline.
>
> Cheers,
> Med
>
>> -----Message d'origine-----
>> De : Gorry Fairhurst <[e-mail]>
>> Envoyé : jeudi 9 décembre 2021 15:48
>> À : BOUCADAIR Mohamed INNOV/NET <[e-mail]>
>> Cc : [e-mail]
>> 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.

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