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

[[e-mail]]

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

_________________________________________________________________________________________________________________________

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.