Re: [babel] Extension of Call for WG adoption of draft-ovsienko-babel-rfc7298bis through 2018-05-28

[Denis Ovsienko <[e-mail]>]

Hello all.

Thank you for making your reasons, let me provide a digest of the main technical points of the proposed work item.

HMAC result(s) prove a packet was not modified in transit and was send by a speaker that has the shared secret. This will require adding the packet destination address into the HMAC input in 7298-bis as discussed.

RFC 7298 specifies a simple optional way to guarantee that the per-interface outgoing TS/PC number is strictly increasing over the lifetime of a speaker. 7298-bis will need to mandate this property. This way any speaker can tell if any other speaker's sequence of packets runs strictly uphill and never repeats itself.

In addition to the above, the IHU-specific TS/PC sub-TLV and the sent TS/PC numbers table in 7298-bis make it possible to tell if an IHU proves (because the local TS/PC number also runs strictly uphill and never repeats) freshness (not just uphill but roughly at the same elevation) that does not exceed the configured threshold. This threshold is specified in real time seconds but does not require the clocks to be synchronous.

The latest technical problem Juliusz had pointed out was that the main protocol instance could change its state in response to replayed/delayed [authentic, non-duplicate, in-order] packets with Update(s) but without IHU, and then a fresh IHU could activate those old routes regardless if the speaker currently intends to advertise respective prefixes. I suggested to let only Hello and IHU TLVs through before the first freshness proof occurs.

Having thought about it for some time, it seems to me this attack could also work _after_ the freshness has been proved for the first time, it just requires a long enough time span and many enough topology changes to prepare the Update(s) to be sent before the next IHU. At the moment it seems to me to make the most sense to maintain an age timer in 7298-bis for every proof of freshness (i.e. to add a column to ANM table and to use it to tell what TLVs can reach the main protocol instance).

Although the proposed concept has slightly moved ahead of the I-D, my understanding is the job is doable and the document is an OK work item. That said, the working group makes the decision, I just need to know what specifically it is to be able to plan my further contributions.

Thanks.

-- 
    Denis Ovsienko