Subject: [babel] Minor clarification to HMAC

From: Juliusz Chroboczek <[email-masked]>
Date: Fri, 28 Jun 2019 15:21:55 +0200

Dear all,

Sawssen and Étienne (in copy of this mail) are currently working on
cleaning up and completing the reference implementation of draft-...-hmac.
We have just realised that the draft is not quite clear on two points.

The draft says that a neighbour entry MUST NOT be created before HMAC is
verified (Section 4.3 first bullet).

It later says that a neighbour entry "might need to be created" when
a challenge is sent, and "may need to be created" when a challenge is
received.  However, it does not say whether it is legal to create an entry
earlier.

I would therefore like to kindly request the permission of the group and
the chairs to add the following between the first and second bullet points
of Section 4.3:

  * A neighbour entry for the sender of the packet MAY be created at this
    stage.  (Alternatively, an implementation MAY delay the creation of
    a neighbour entry until a challenge request or reply is received.)

This clarification does not invalidate any implementations, it just makes
the intent of the draft authors more explicit.

-- Juliusz

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Fri, 28 Jun 2019 13:34:44 +0000

> It later says that a neighbour entry "might need to be created" when a
> challenge is sent, and "may need to be created" when a challenge is
> I would therefore like to kindly request the permission of the group and the
> chairs to add the following between the first and second bullet points of
> Section 4.3:
> 
> This clarification does not invalidate any implementations, it just makes the
> intent of the draft authors more explicit.

+1
I think this is a good change.
Barbara

---

From: Toke Høiland-Jørgensen <[email-masked]>
Date: Fri, 28 Jun 2019 16:01:16 +0200

+1

-Toke

---

From: Markus Stenberg <[email-masked]>
Date: Fri, 28 Jun 2019 17:17:21 +0300

In terms of security properties, notably resource exhaustion/contention, I am bit leery of creating entry before validity of remote party is actually verified (= challenge response received). I prefer the old text. I am not quite sure why the second 'may need to be created' is there..

I guess naive implementation would just remember specific nonces it has sent/freceived, but for new peers you can also just use e.g. nonce that contains timestamp (+ peer address (+- something))[1], which allows challenge sender to remain stateless until challenge responder proves they have the key.

So -1 from me. (Yes, I do wear my tinfoil hat even during summer.)

Cheers,

-Markus

[1] extra stuff is mostly for replay protection purposes, but I am not sure if it is a threat or not in this case. I have just cycled 140km, sue me.

> On 28.06.2019, at 16.21, Juliusz Chroboczek <[email-masked]> wrote:
> 
> Dear all,
> 
> _______________________________________________
> babel mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/babel
>

---

From: David Schinazi <[email-masked]>
Date: Fri, 28 Jun 2019 10:45:50 -0700

When a node detects a new neighbour (by receiving a multicast hello), it
sends a challenge.
I can imagine several ways to implement this:
- create the neighbor entry at this point
- have a separate table of pending challenges
- come up with a clever stateless scheme involving cookies (maybe?)
But how the node handles the challenge is an implementation matter.
A rate-limiting and anti-DoS mechanism can be added to all of these.

Therefore, I support adding this MAY, because it gives implementors leeway.

David

On Fri, Jun 28, 2019 at 7:17 AM Markus Stenberg <[email-masked]>
wrote:

> In terms of security properties, notably resource exhaustion/contention, I
> am bit leery of creating entry before validity of remote party is actually
> verified (= challenge response received). I prefer the old text. I am not
> quite sure why the second 'may need to be created' is there..
>
> I guess naive implementation would just remember specific nonces it has
> sent/freceived, but for new peers you can also just use e.g. nonce that
> contains timestamp (+ peer address (+- something))[1], which allows
> challenge sender to remain stateless until challenge responder proves they
> have the key.
>
> [1] extra stuff is mostly for replay protection purposes, but I am not
> sure if it is a threat or not in this case. I have just cycled 140km, sue
> me.
>

---

From: Mahesh Jethanandani <[email-masked]>
Date: Fri, 28 Jun 2019 10:57:56 -0700

To me this sounds much like a SYN flood attack in TCP, where TCP resources were allocated before the ACK came back. And TCP had to come back to clarify this, rather than leave it as a implementation level detail.

If we agree that a MAY should be allowed, I would like to see some guidance given on some implementation choices including the fact that a separate table of pending challenges should be kept to prevent an attack. 

Thanks.

Mahesh Jethanandani
[email-masked]

> On Jun 28, 2019, at 10:45 AM, David Schinazi <[email-masked]> wrote:
> 
> When a node detects a new neighbour (by receiving a multicast hello), it sends a challenge.
>> On Fri, Jun 28, 2019 at 7:17 AM Markus Stenberg <[email-masked]> wrote:

---

From: Juliusz Chroboczek <[email-masked]>
Date: Sat, 29 Jun 2019 11:41:38 +0200

> In terms of security properties, notably resource exhaustion/contention,
> I am bit leery of creating entry before validity of remote party is
> actually verified (= challenge response received). I prefer the old
> text.

I initially thought like you, but Sawssen and Étienne convinced me that
creating the entry late does not add any security.

Suppose that the packet passes HMAC.  Then one of the possible cases is
possible:

  - the neighbour entry already exists;
  - the neighbour entry doesn't exist, and we're going to send a challenge.

In the first case, the point is moot.  In the second case, we're going to
create a neighbour entry anyway, so we might as well create it immediately.

(Note that the data structures of the protocol are conceptual, not
prescriptive -- an implementation is allowed e.g. to use an "incomplete
neighbour" data structure that is smaller than a full neighbour structure
for holding uncompleted challenges, as long as the effect is identical to
what is described in the protocol.

> I am not quite sure why the second 'may need to be created' is there..

I was hoping nobody would notice ;-)

For the challenge to be successful, the neighbour entry must exist --
there's no way we could have sent a challenge if no neighbour entry
exists.  (It could be the case of course that the challenge reply is an
attack, and no neighbour entry exists, so the implementation must still
check for the existence of the neighbour entry.)  I didn't want to mention
that right now, in order to limit the amount of confusion.

> challenge sender to remain stateless until challenge responder proves
> they have the key.

Yes.  The protocol is designed to make it possible to encode a cookie in
the Nonce (that's why Nonces can be as much as 192 octets long).  However,
the draft does not specify how to implement it with cookies, so the point
is somewhat moot.

(Note that even with cookies, you still need to rate-limit challenges.
A global challenge counter should be enough, but I haven't given it any
serious thought.  Which is why I won't attempt to specify the cookie
variant of the protocol in this revision of the protocol.)

> So -1 from me. (Yes, I do wear my tinfoil hat even during summer.)

Please reconsider in light of the above.

-- Juliusz

---

From: Juliusz Chroboczek <[email-masked]>
Date: Sat, 29 Jun 2019 11:52:01 +0200

> To me this sounds much like a SYN flood attack in TCP, where TCP resources were
> allocated before the ACK came back. And TCP had to come back to clarify this,
> rather than leave it as a implementation level detail.

RFC 4987.  The issues are similar, the same defenses apply, but there is
one significant difference.

The very first thing that happens is that the HMAC is verified.  No state
is created if the HMAC fails (Section 4.3, first bullet).  What is more,
the HMAC includes a pseudo-header (Section 4.1), so a packet can only be
replayed by spoofing the source address it was originally sent from.

Since neighbour entries are indexed by source address, the amount of state
an attacker can create is limited by the number of different source
addresses in his collection of previously captured packets.  What is more,
everytime the network undergoes key rotation, all of the captured packets
are invalidated.

So an easy defense is to roll over the keys often enough so that the
attacker can only create a bounded amount of state.

> If we agree that a MAY should be allowed, I would like to see some guidance
> given on some implementation choices including the fact that a separate table
> of pending challenges should be kept to prevent an attack. 

Please check the last two paragraphs of Section 6 (Security Considerations),
and let me know if you think I should add something there.

-- Juliusz

---

From: Markus Stenberg <[email-masked]>
Date: Sat, 29 Jun 2019 12:53:15 +0300

> On 29 Jun 2019, at 12.41, Juliusz Chroboczek <[email-masked]> wrote:

Is there some mechanism in place that prevents replay of historic packets? As the HMAC key itself does not change over time, storing (large amounts of) historic payloads with valid HMAC  is not hard.

Tthe value is bit questionable GIVEN router ID is stable, but if it is not, there is actually potential attack vector here.. RFC6126bis suggests even random router ids as valid strategy and does not mandate their storage.
(Also given large domain, it might be possible to gather more routers’ sent packets than there is space in neighbor table in limited implementations.)

Still -1.

Cheers,

-Markus

---

From: Juliusz Chroboczek <[email-masked]>
Date: Sat, 29 Jun 2019 12:14:05 +0200

> Is there some mechanism in place that prevents replay of historic
> packets? As the HMAC key itself does not change over time, storing
> (large amounts of) historic payloads with valid HMAC is not hard.
> Tthe value is bit questionable GIVEN router ID is stable, but if it is
> not, there is actually potential attack vector here..

It's not the router ID, it's the link-local IP address.  In order to
create /n/ neighbour entries, an attacker needs to have captured correctly
signed packets with /n/ distinct source IPs.  (That's per interface.  If
an attacker is able to spoof packets on multiple interfaces, then the
situation becomes worse.)

(I'm tempted to follow Mahesh's advice, and rewrite the last two
paragraphs of the Security Considerations section with reference to
RFC 4987.  Advice?)

-- Juliusz

---

From: Markus Stenberg <[email-masked]>
Date: Sat, 29 Jun 2019 13:22:34 +0300

I think I am being dense (I haven’t looked at the protocol in awhile), but 

a) babel-hmac does not have even reference to link-local address, and
b) 6126bis states it is used only to index remote entries

Doesn’t this mean that by forging the link-local addresses (which are not included in HMAC) and then replaying valid HMAC packets you can fill table as you want if this consideration is relaxed?

-Markus

> On 29 Jun 2019, at 13.14, Juliusz Chroboczek <[email-masked]> wrote:
>

---

From: Juliusz Chroboczek <[email-masked]>
Date: Sat, 29 Jun 2019 12:37:34 +0200

> I think I am being dense (I haven’t looked at the protocol in awhile),

Perhaps we're not undestanding each other.  Let's work it out.

> a) babel-hmac does not have even reference to link-local address, and

Section 4.1:

   First, the node builds a pseudo-header that will participate in HMAC
   computation but will not be sent.
   [...]
   Src address   The source IP address of the packet.

RFC 6126bis Section 4:

   A Babel packet MUST be silently ignored unless its source address is
   either a link-local IPv6 address or an IPv4 address belonging to the
   local network, and its source port is the well-known Babel port.

> Doesn’t this mean that by forging the link-local addresses (which are
> not included in HMAC)

They are included in HMAC computation, see citation from 4.1 above.

> and then replaying valid HMAC packets you can fill table as you want if
> this consideration is relaxed?

I don't think that's the case.  (And if you're right, then it's a serious
flaw indeed.)

-- Juliusz

---

From: Markus Stenberg <[email-masked]>
Date: Sat, 29 Jun 2019 13:40:37 +0300

> On 29 Jun 2019, at 13.37, Juliusz Chroboczek <[email-masked]> wrote:

Ah ok, I didn’t read it through again (just did some searching), so that’s correct. Non-issue for most part.

> I don't think that's the case.  (And if you're right, then it's a serious

So at most you can have # of network size spurious replayed neighbour table entries. No idea how limited implementations might behave with that (e.g. fixed neighbour table size in a largish network with same HMAC key), but I think that given security consideration text it is fine then as long as the behavior is mentioned somewhere.

-Markus

---

From: Juliusz Chroboczek <[email-masked]>
Date: Sat, 29 Jun 2019 12:54:05 +0200

> So at most you can have # of network size spurious replayed neighbour
> table entries.

Right.  We're hoping that implementations don't change their link-local IP
addresses too often, i.e. that (genuine) link-locals are reasonably stable.

> No idea how limited implementations might behave with that (e.g. fixed
> neighbour table size in a largish network with same HMAC key),

I'll add a note to the Security Considerations that implementations want
to ensure that they fail gracefully when the neighbour table overflows
(i.e. that they fail to establish any new adjacencies rather than
crashing.)

> I think that given security consideration text it is fine then as long
> as the behavior is mentioned somewhere.

Are you retracting your -1?

-- Juliusz

---

From: Markus Stenberg <[email-masked]>
Date: Sat, 29 Jun 2019 14:01:42 +0300

> On 29 Jun 2019, at 13.54, Juliusz Chroboczek <[email-masked]> wrote:

Well, I assume routers don’t really want to be private (some wifi nodes change macs frequently for privacy purposes).

> Are you retracting your -1?

Yes, given the s.c. text is sensible. 

-Markus

---

From: Mahesh Jethanandani <[email-masked]>
Date: Sun, 30 Jun 2019 05:21:12 +0100

> On Jun 29, 2019, at 11:14 AM, Juliusz Chroboczek <[email-masked]> wrote:
> 

Yes, I think it would be helpful.

Thanks.

Mahesh Jethanandani
[email-masked]