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

From: Denis Ovsienko <[email-masked]>
Date: Tue, 12 Jul 2016 18:21:47 +0100

Hello all.

Let me try to describe what seems to be a flaw in RFC 7298 mechanism.

For example, there are two routers: Ra, which advertises network Na, and Rb, which advertises network Nb. The keys have been provisioned and the security associations configured. The two routers authenticate each other and everything works as it should.

Ra sends: Hello(Ra), IHU(Rb), Update(Na), TS/PC, HMAC
Rb sends: Hello(Rb), IHU(Ra), Update(Nb), TS/PC, HMAC

Now an adversary takes a control over the link such that Ra's Babel packets reach Rb, but Rb's Babel packets don't reach Ra. Soon Ra times its neighbour entry for Rb out.

Ra sends: Hello(Ra), Update(Na), TS/PC, HMAC
Rb sends: Hello(Rb), IHU(Ra), Update(Nb), TS/PC, HMAC

Now if the adversary not just discards Babel packets from Rb to Ra but records them for a while (1 hour, for instance), replaying these recorded packets towards Ra after Rb gives up and leaves would trick Ra to believe Rb is on the other end again and is advertising Nb as before:

Ra sends: Hello(Ra), IHU(Rb), Update(Na), TS/PC, HMAC
"Rb" sends: Hello(Rb), IHU(Ra), Update(Nb), TS/PC, HMAC

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.

RFC 4593 terms for this would be "overclaiming" for the action and "usurpation" for the consequence. I have not tested this attack on wire and would be glad to stand corrected, but if it works the way I see it now this flaw will have to be addressed.

-- 
    Denis Ovsienko

---

From: Denis Ovsienko <[email-masked]>
Date: Thu, 14 Jul 2016 13:18:11 +0100

[...]
>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 d…

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.
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