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

[[e-mail]]

Hi Gorry,

Thank you for the clarification. 

Please see inline.

Cheers,
Med

> -----Message d'origine-----
> De : Gorry Fairhurst <[e-mail]>
> Envoyé : lundi 13 décembre 2021 11:38
> À : BOUCADAIR Mohamed INNOV/NET <[e-mail]>
> Cc : [e-mail]
> Objet : Re: [tsvwg] I-D Action: draft-ietf-tsvwg-udp-options-dplpmtud-
> 02.txt
> 
> 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.
> 

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