Re: [babel] Comments about rfc7298bis

[Denis Ovsienko <[e-mail]>]

---- On Thu, 10 May 2018 00:41:42 +0100 Juliusz Chroboczek  wrote ---- 
>Thanks for the explanation, that helps. I'm going to read 7183 when 
>I have time. 
> 
>> Do you see any ways for this to go wrong? 
> 
>Probably not, but I'm not quite comfortable yet. Please be patient, 
>I probably get the details wrong in the following example. 
> 
>Suppose that Chloe has captured a large number of packets previously sent 
>by alice. Alice left the network, and state relevant to Alice has expired 
>at Bob. 

(Implied: Alice reuses TS/PC numbers, Bob uses a short enough ANMTimeout.)

>Now Alice joins the network, and sends 
> 
> A: Hello, TS/PC = 42 
> 
>Now Chloe sends a replayed packet: 
> 
> C (spoofing A): Update (::/0, 0), TS/PC = 43 
> 
>Bob sees this as a route announcement from Alice, so he inserts a default 
>route in its route table. Since Alice hasn't sent an IHU yet, the link 
>cost is infinite, so the route doesn't get installed. 
> 
>Bob sends a Hello: 
> 
> B: Hello, TS/PC = 57 
> 
>and Alice sends an IHU with the correct TS/PC echo: 
> 
> A: IHU(TS/PC=57), TS/PC = 43 
> 
>the IHU gets ignored, due to the obsolete TS/PC (43), but then Alice 
>resends the IHU: 
> 
> A: IHU(TS/PC=57), TS/PC = 44 
> 
>This packet is correct, so BOB sets its txcost to something finite, and 
>bang, the route suddenly is selectable, and Bob installs the route that 
>was spoofed by Chloe. 
> 
>What am I missing? 

It looks like this attack would work they way you describe it. To spell the nuances, what 7298-bis would do on top of 7298 is detect packets with incoming IHUs that are not a fresh enough response to the local TS/PC number. Without IHUs it is only the TS/PC+HMAC check, and with reused local TS/PC number the bi-directional exchange is not actually proven. So that's a good point.

Moreover, if Bob reuses his outgoing TS/PC numbers too, it will take to power-cycle A and B at the same time, then record the exchange, and then C will be able to replay a complete (Hello+IHU+Update) protocol exchange to any of those two each time they reboot.

As far as I see after thinking about this new input for a day, the principal way to fix this would be to mandate that TS/PC number must be increasing across the lifetime of a speaker (7298-bis Section 5.1 item (a) goes away, item (c) becomes the recommended default, item (b) refines the requirements for the timestamp source).

A secondary measure would be to have a large ANMTimeout by default (since item (a) no longer applies) and to save ANM table across reboots, this way old replayed Update TLVs will be less likely to produce inactive routes in the absence of new IHU TLVs.

-- 

    Denis Ovsienko