Re: [babel] Paul Wouters' Discuss on draft-ietf-babel-rtt-extension-05: (with DISCUSS and COMMENT)

[Paul Wouters <[e-mail]>]

On Feb 13, 2024, at 14:00, Juliusz Chroboczek <[e-mail]> wrote:
> 
> 
>> 
>> I agree with Shivan's concern about privacy here. Perhaps something more can be
>> said in the document? Maybe a Privacy Considerations section? Should a client
>> using a VPN add some random range delay for privacy? Should it just say/act
>> with something very slow to "opt out" of this entirely
> 
> A router can opt out of the mechanism entirely, simply by not sending the
> timestamp sub-TLV in its Hello and IHU TLVs.  This will cause neighbouring
> routers will fall back to RFC 8966 operation for route selection.
> A router may even switch at any time from sending timestamps to omitting
> them, for example if a previously stationary router becomes mobile and
> therefore wishes to conceal its location.
> 
> The current implementations are not vulnerable to the attack, since they
> use RTT information in order to penalise participating routers: RTT
> information is used to identify far-away routers, in order to avoid
> sending traffic through them.  In ten years, we have not come across
> a network topology where we would want to do the opposite.
> 
> The Security Consideration currently says:
> 
>    However, having access to accurate timestamps could allow an attacker
>    to determine the physical location of a node, which might be
>    undesirable in some deployments.
> 
> If you wand us to be more explicit, I can replace it with the following:
> 
>    However, having access to accurate timestamps could allow an attacker
>    to determine the physical location of a node, which might be
>    considered confidential in some deployments.  Such nodes might avoid
>    disclosure of location information by not including timestamp sub-TLVs
>    in the TLVs that they send.
> 
> Would that satisfy you?

Yes, thanks.

> 
>> I'm also worried about malicious clients sending pre-emptive IHUs and lying
>> about the RTT, and thus making themselves the preferred gateway.
> 
> There are easier ways to achieve that in the Babel protocol, please see
> Section 6 of RFC 8966.

Okay so this isn’t a great concern then.

Thanks,

Paul

> 
>> This could be avoided by adding a random COOKIE in the RTT timer
>> request. Is there a reason why not to take this extra security step?
> 
> A malicious router has much easier ways to redirect traffic to itself.
> That's why we recommend using RFC 8968, which uses random nonces and
> cryptographic signatures, and that has been proved safe.  (Full
> disclosure: pen and paper proof, not automated verification.)
> 
> -- Juliusz