Re: [babel] Roman Danyliw's Discuss on draft-ietf-babel-hmac-08: (with DISCUSS and COMMENT)

[Juliusz Chroboczek <[e-mail]>]

> Ah, I see it now in Section 4.3 Thanks for the pointer.  This text
> explains the issues of around keys processing.  I couldn't explicitly
> find text explaining when multiple HMAC TLVs should be sent.  Where
> should I be looking?

Section 5 (key rotation), formerly Appendix A:

   In order to perform key rotation, the new key is added to all the
   nodes; once this is done, both the old and the new key are sent in
   all packets, and packets are accepted if they are properly signed by
   either of the keys.  At that point, the old key is removed.

>> I'm leaving this sentence as is -- after trying it out, I don't think that
>> mentioning the small amount of state caused by reception of a UDP packet
>> (an ND entry) is informative.

> I'm not tracking.  "Whatsoever" is an absolute statement.  By all means
> caveat the sentence by saying no local Babel state (or something to that
> effect).

Done.

>>> (8) Section 1.  Per the “spoof of a malformed packet”, how would an
>>> HMAC address this?  Even assuming that a node discards the message
>>> without processing if the HMAC is bad, this would still be a problem
>>> from a malicious peer.

>> Please explain.

> The initial situation I had in mind was if there was a compromised Babel
> node.  It will have the key to produce a valid HMAC on the crafted
> packet to cause the peer Babel node to process the packet.

Yes, this protocol assumes that only honest nodes know the secret key.  We
make no guarantees, not even of any kind, if you've lost your keys.

> Another situation which would not involve a malicious Babel node with
> the key is a node running a buggy Babel implementation.  Imagine this
> implementation has some kind of (buffer overflow) vulnerability in the
> routines which parses the packet payload to find the HMAC TLV.  In the
> worst circumstance, this could hypothetically compromise the Babel node
> even before the code to verified HMAC and choose to discard the packet
> or not is made.

Yes, it could.

That is the reason why HMAC keys sit in the packet trailer rather than in
the packet body: you may use a simplified parser that is only able to
parse the packet trailer.  This parser does not modify any global state,
it does not modify the packet (there's no need to clear the MAC before
recomputing it), and it just returns one bit of information.  You are
expected to vet this specialised parser very carefully, or even run it
out-of-process.

This was debated by the WG; however, once both Toke (BIRD) and Weronika
and Clara (babeld) had implemented parsing the packet trailer, we agreed
that this approach makes the implementation much simpler and less
error-prone.

-- Juliusz