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

[Donald Eastlake <[e-mail]>]

Hi Roman,

Thanks for clearing your DISCUSS.

Donald
===============================
 Donald E. Eastlake 3rd   [phone] (cell)
 2386 Panoramic Circle, Apopka, FL 32703 USA
 [e-mail]

On Thu, Oct 17, 2019 at 3:11 PM Roman Danyliw <[e-mail]> wrote:
>
> Hello Juliusz!
>
> My apologizes for the long delay.  Thank you for addressing my DISCUSS points with the updated -08 and the discussion.  I've cleared my ballot.
>
> Roman
>
> > -----Original Message-----
> > From: Juliusz Chroboczek [mailto:[e-mail]]
> > Sent: Friday, August 16, 2019 6:53 PM
> > To: Roman Danyliw <[e-mail]>
> > Cc: Donald Eastlake <[e-mail]>; [e-mail]; The IESG
> > <[e-mail]>; [e-mail]; [e-mail]
> > Subject: Re: Roman Danyliw's Discuss on draft-ietf-babel-hmac-08: (with
> > DISCUSS and COMMENT)
> >
> > > 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