Re: [babel] Comments about rfc7298bis

[Denis Ovsienko <[e-mail]>]

---- On Sun, 13 May 2018 14:56:19 +0100 Juliusz Chroboczek  wrote ---- 
>> 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: Hello, Update(X), TS/PC=42 
> 
>The packet is captured by C. At this point, A and B simultaneously reboot 
>and loose their ANM state. 
> 
>C spoofing A: Hello, Update(X), TS/PC=42 
> 
>Since B has lost its ANM state, it accepts this packet as authentic, and 
>learns a spoofed route to X through A. At which point, an (authentic) 
>Hello/IHU exchange happens: 
> 
>B: Hello, TS/PC=57 
>A: Hello, IHU(B, TS/PC=57), TS/PC=43 
> 
>B's cost to A becomes finite, and the replayed route is installed. 
> 
>Note that I'm not sure that this is a serious attack -- C has managed to 
>get B to route through A, it has not managed to redirect traffic through 
>itself. 

Makes sense. The root causes are the same as before -- only the packets with relevant IHU TLVs can be tested for freshness and the main protocol instance actions Update before establishing a 2-way relation with a neighbour.

>> 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, 
> 
>If we assume that the ANM table is persistent, then a lot of things become 
>much easier. Another solution would be to assume that all nodes have 

It seems to me it would make sense to recommend a persistent ANM table only if the implementer can do it safely, because trying to write to disk something that changes a few times a second may actually break things on a sudden power cycle. It should do its job even as a purely run-time structure.

>real-time clocks, and require that TS/PC carries a timestamp that's no 
>more than 20 seconds in the past. 

That's exactly what RFC 7183 defines, but the issue is synchronous offline clocks are either expensive, or unavailable for obvious practical reasons. 7298-bis is supposed to achieve the same effect with TSPCMaxRTT and only requires the clocks to be monotonic. The idea is roughly similar to the RTT Babel extension.

>However, I think a more general fix is possible -- the attack above is due 
>to B accepting a (spoofed) packet from A although it has no recent ANM 
>state for A. 

Not quite, but almost there. As far as I see it, the missing design point is to let only Hello TLVs in before seeing a packet with a proven fresh IHU TLV. This way the replayed packets _before_ the IHU will not affect the main protocol instance. As a consequence, any speaker will be able to discard its ANM table on shutdown safely.

Once again, for this to work the outgoing TS/PC number must be strictly increasing across the lifetime of a speaker, as explained before. This also gets rid of the replayed Updates _after_ authentic IHUs as the freshness proof will actually work. And this is doable in spite of sudden and frequent reboots.

Do you see what I mean?

-- 

    Denis Ovsienko