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

[Roman Danyliw <[e-mail]>]

Hi Juliusz!

Thanks for the quick response.  Responses inline ...

> -----Original Message-----
> From: iesg [mailto:[e-mail]] On Behalf Of Juliusz Chroboczek
> Sent: Thursday, August 8, 2019 9:47 AM
> 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)
> 
> Dear Roman,
> 
> Thank you for your review.
> 
> > (1) Section 1.2.  Per “any packet accepted as authentic is the exactly
> > copy of a packet originally sent”, this text can be read two ways –
> > packet as Babel packet or as an IP packet.  I think  mean the former.
> > Recommend making this clearer as s/any packet/any Babel packet/
> 
> Done.
> 
> > (2) Section 2, Per the paragraph, “By itself, this mechanism is safe
> > against replay …”, please reiterate that for the attack by C to work:
> > A and B must have both lost state; that C is replaying packets with PC
> > previously sent by B (e.g., n+2).
> 
> Only A needs to have lost its state.  Clarified.
> 
> > (3) Section 4.1.  Per “The node takes the concatenation of the
> > pseudo-header and the packet including the packet header but excluding
> > the packet trailer (from octet 0 inclusive up to (Body Length + 4)
> > exclusive)”, as input for the HMAC.  “packet” is used to sometimes
> > mean IP packet and sometimes a Babel packet carried in an IP packet.
> 
> Clarified.

Thanks.

> > (4) Section 2.  This section suggests that “one or more HMACs can be
> > appended to the packet”.  Under what conditions would it be more than
> > one?  What happens if only some of the HMACs are valid?  Is use of the
> > same key assumed?
> 
> This section is a conceptual overview, and is optimised for easy readability.
> The exact details are given in 4.3.  I've added the paranthetical remark "(one
> per key)",

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?

> but refuse to overload this section any further.

No worries.  I'm not suggesting that.  FWIW, I think this narrative section works really well.

> > (5) Section 4.1.  The hash algorithm appears to be negotiated/set out
> > of band (rather than negotiated). The text should explicitly state that
> somewhere.
> 
> Section 3.1.

Got it.  Thanks.

> > (6) Section 6.  Per “In particular, reception of a packet with no
> > correct HMAC creates no local state whatsoever (Section 4.3)”, unless
> > this HMAC verification is happening on the NIC, this doesn’t seem
> > sufficiently precise.  The “no local state” claim is likely true only
> > as it relates to the tables data structures describes in Section 3.
> > However, the IP and DTLS stack certainly have to account for the packet.
> 
> There is no DTLS in this protocol.

Right.  Sorry about that.  I have both documents open.

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

> > ----------------------------------------------------------------------
> > COMMENT:
> > ----------------------------------------------------------------------
> 
> > (7) Section 1 enumerates a series of attacks.  These are different
> > than the ones listed in Section 6 of draft-ietf-babel-rfc6126bis and
> > Section 1 of draft-ietf-babel-dtls.  As HMAC and DTLS are mitigations
> > for attacks in draft-ietf-babel-rfc6126bis, they really should be
> harmonized.
> 
> I'll look at making this uniform between the three drafts.

Thanks for coordinating across documents.  Your call, but an alternative to making the text more uniform might be to have the HMAC and DTLS drafts just reference the core Babel drafts in some way.

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

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.

> > (9) Editorial nits:
> 
> Fixed, thanks.

Thanks.

Regards,
Roman

> -- Juliusz