Subject: Re: [babel] delay/replay attack on RFC 7298 mechanism

From: Denis Ovsienko <[email-masked]>
Date: Sun, 07 Aug 2016 18:15:33 +0100

Hello group.

I've been thinking about possible solutions for a while and it seems to me there is at least one particular bit that can be improved, please see below.

---- On Thu, 14 Jul 2016 13:18:11 +0100 Denis Ovsienko wrote ---- 
>[...] 
>>This behaviour depends on two current design points: 
>>1. The authentication mechanism is only concerned if the packets were originally produced by a legitimate router, came in order and were not modified. As long as those conditions are met, the delay between any input packets may be any amount of time. 
>>2. The main protocol body takes any IHU as a recent response to a recent Hello as it is currently impossible to relate an IHU to a particular Hello (Hellos do have 16-bit sequence numbers but IHUs don't). The RTT metric Babel extension seems to be close to this problem/solution space, as well as the TLVs that include a nonce number to correlate the request and response. 
>> 
> 
>I have considered the problem for some more time. A possible solution to this could be: 
>1. To add a "your last seen TS/PC" sub-TLV to each IHU TLV on sending. 
>2. To check that the sub-TLV stands for a reasonably recent point in time on receiving. 
>3. To consider if any other replayed TLVs would be actionable without the requirement of a verified two-way neighbourship. 

As far as my interpretations of RFC 6126 (bis) go, a Babel protocol instance makes every neighbour through the following (roughly) states:

(Hello received) -> (IHU received) -> (will respond to AckReq with Ack, will process Update, will respond with Update to RouteReq and SeqnoReq)

This lacks handling of timeouts, but the idea should be clear: until there is a two-way exchange with a neighbour, only Hello and IHU may be actioned. If this understanding is correct, the coupling between Hello and IHU as mentioned above should provide a protection from the described attack.

This coupling may be done on the base of the existing Hello Seqno field, which at the moment looks like 16 bit worth of nonce. In this case the Seqno will have to be echoed back in an IHU. The least disruptive way of this would be a sub-TLV in the IHU TLV. The return nonce (Seqno) would then provide a proof of freshness.

Alternatively, the two-way exchange of a nonce could be done using the existing AckReq+Ack TLVs. In this case an AckReq would have to accompany each Hello and an Ack would have to accompany each IHU. But it seems to me the additional TLV management would make this a worse option.

In either case, having the neighbour state machine in the specification seems to be a good idea, even just as an illustration. For example, OSPF and BGP specs have FSMs as a part of the normative spec and those can be mapped into the code in a straightforward way. If we have a consensus on this, I could prepare a diagram for 6126-bis.

>4. To revise Section 5.1 of RFC 7298 thoroughly to accommodate those changes. 
> 
>It would be nice to produce a simple measure of "freshness" like MAX_HELLO_TIMESTAMP_DIFF in RFC 7183 without the dependency on a pre-synchronised time, which in practice tends to depend on working routing. This chicken-and-egg situation should be avoided. 
> 
>Would anybody be interested to discuss this during the working group meeting? I could pull a couple slides together. 

-- 
 Denis Ovsienko