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

[Juliusz Chroboczek <[e-mail]>]

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

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

> 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