Subject: Re: [babel] Work to do (IHU TLV AE 0)

From: Denis Ovsienko <[email-masked]>
Date: Wed, 04 Apr 2018 01:20:21 +0100

Hello all.

---- On Fri, 30 Mar 2018 15:59:09 +0100 David Schinazi<[email-masked]> wrote ---- 
 > Taking a step back and thinking about the security properties here,
 > I don't see a security issue with the text "A Unicast Hello carrying a given seqno should normally be sent to just one neighbour".
 > The conceptual property of unicast hellos is that the seqno is from a different pool as the multicast seqno.
 > That means that I MUST treat them separately when I receive them to avoid mixing up cost estimations,
 > however as a sender I can very well send the same unicast seqno to all my neighbors if I so choose.
 > As such it is not a problem to send Unicast Hellos to the multicast address (even though I don't see a reason to do so).
 > The attack that Juliusz described was where Eve takes an unicast Hello from Alice destined for Bob and sends it to Damian,
 > in that case the problem arises because Damian will check the timestamp/packet counter from the Alice-Damian relationship
 > and get a seqno from the Alice-Bob relationship.

Yes, that's what I meant. One minor detail does not look correct at the end: authenticity relation is one-way (from Alice to whom it may concern). The good news is that "belt and braces" approach does not require a 100% exact problem statement so it should be fine (you are welcome to prove this wrong) both to cover the destination address by the integrity check _and_ to make the Address field in the IHU TLV mandatory.

As a side comment, one thing that your description makes easier to notice is as follows. Given a [strictly increasing, per-interface] TS/PC number with no gaps between the values, some of the values may be spent on Tx multicast and the others -- on Tx unicast. From the point of view of a multicast-only or unicast-only receiving speaker, the number will remain strictly increasing but there will be gaps between the values. Which is going to work as originally intended in both the old and the new sections of 7298-bis -- the added complexity of Hello seqno tracking does not spill into the TS/PC number tracking. Right?

 > The attack stems from the fact that packets can be replayed with a falsified destination address.
 > The simplest fix is to have the destination address as part of the inputs to the HMAC function.

Yes.

 > Here is a proposal: we replace the current construct where the IPv6 source address is written into the HMAC field before HMAC
 > with a different construct akin to the TCP pseudo-header: we set the HMAC field to all zeroes and prepend the source and
 > destination IP addresses to the Babel payload before computing the HMAC. This is simpler and does not require us to place requirements
 > on the size of the HMAC output.

Yes. RFC 7298 specifies the overlay construct for consistency reasons (i.e. the intent was to do things differently only if there was a good reason for that).

-- 

    Denis Ovsienko

---

From: David Schinazi <[email-masked]>
Date: Tue, 03 Apr 2018 17:29:15 -0700

> On Apr 3, 2018, at 17:20, Denis Ovsienko <[email-masked]> wrote:
> 

I am opposed to making the IHU TLV address mandatory, as it increases packet size.
Adding the destination address to the inputs to the HMAC does not increase the number of bytes transmitted.

> As a side comment, one thing that your description makes easier to notice is as follows. Given a [strictly increasing, per-interface] TS/PC number with no gaps between the values, some of the value…

Gaps are expected in the presence of packet loss, as long as TS/PC doesn't wrap around too quickly we should be fine.
Hello seqno gaps impact the cost computation, TS/PC gaps should not impact anything.

David