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

["Gunter van de Velde (Nokia)" <[e-mail]>]

Hi Paul,

Please find the diff:
https://author-tools.ietf.org/diff?doc_1=draft-ietf-babel-rtt-extension-05&doc_2=draft-ietf-babel-rtt-extension-06

Based upon your feedback the document has been enhanced/updated.
Are there any remaining showstoppers from your side?

G/

-----Original Message-----
From: iesg <[e-mail]> On Behalf Of Paul Wouters
Sent: Tuesday, February 13, 2024 11:05 PM
To: Juliusz Chroboczek <[e-mail]>
Cc: The IESG <[e-mail]>; [e-mail]; [e-mail]; [e-mail]; Donald Eastlake <[e-mail]>
Subject: Re: Paul Wouters' Discuss on draft-ietf-babel-rtt-extension-05: (with DISCUSS and COMMENT)

[You don't often get email from paul.wouters=[e-mail]. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ]

CAUTION: This is an external email. Please be very careful when clicking links or opening attachments. See the URL nok.it/ext for additional information.



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