Re: [babel] Comments about rfc7298bis

[Denis Ovsienko <[e-mail]>]

---- On Mon, 07 May 2018 15:24:45 +0100 Juliusz Chroboczek  wrote ---- 
>> Regarding your recent concerns about 7298-bis data items not fitting 
>> into output packets, the task of fitting protocol data items into 
>> a packet buffer is neither new nor really difficult. 
> 
>I think got it, sorry for being so slow. Contrary to what I believed, 
>7298bis only requires TS/PC sub-TLVs to be included in existing IHUs. It 
>does not require a full set of TS/PC sub-TLVs to be included in every 

You get this part right. IHUs appear in outgoing packets anyway. On an interface configured for authentication all IHUs start to have a TS/PC sub-TLV because an IHU is a reaction to a Hello, and only authentic Hellos make it in, thus the ANM table has a received TS/PC number to send back in every IHU.

>packet. See Section 5.4 point 4 -- it only requires rejecting packets if 
>there's no sub-TLV in a matching IHU. On the other hand, if a packet does 

Not quite. Section 5.4 item 4 means: if there are any IHU TLVs that are going to be actioned by the main protocol instance and do not quote a *fresh* *enough* TS/PC number of the incoming interface, discard the packet.

>not include a matching IHU, then it is accepted as soon as the TS/PC TLV 
>(not sub-TLV) is good. 

Correct.

>Is that right, Denis? 

Not exactly there yet, but I am glad to confirm this is much closer. Thank you for studying the details, Juliusz.

>If so, then I'd like to understand why this is safe. Intuitively, I'd say 
>that by allowing packets without a matching TS/PC sub-TLV, replay attacks 
>might still be possible. Now, the MUST in Section 3.4.3 of 6126bis 
>should mitigate most such attacks, but I'm still a little worried. 
> 
>Denis, can you please point me where you explain why accepting packets 
>with no matching TS/PC is safe? 

Let me try to answer this as far as I understand the question. If that is not what you mean, please ask again.

The new guard specifically triggers on stale (i.e. not proven fresh) IHUs and lets the timers do eventual handling of any related protocol structures. This is not completely and immediately safe, but it looks good enough. Specifically, it is still possible to intercept packets sent by a speaker, wait until it goes off the air and replay the packets soon enough for them to be accepted and processed normally (no more than once each packet). But the key difference is, in 7298-bis the time window for this spoofing is now limited and under control with TSPCMaxRTT. This is very close to MAX_HELLO_TIMESTAMP_DIFF and MAX_TC_TIMESTAMP_DIFF from RFC 7183, but without the need for all speakers to have synchronized clocks.

This 2-way TS/PC check is better than 1-way but not as good as 3-way. However, my understanding is, for multicast protocol exchange 2-way is as far as it can scale (i.e. hundreds of neighbours on a single segment would have a hard time trying to maintain O(n**2) 3-way unicast exchanges).

Do you see any ways for this to go wrong?

-- 

    Denis Ovsienko