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

[Roman Danyliw via Datatracker <[e-mail]>]

Roman Danyliw has entered the following ballot position for
draft-ietf-babel-hmac-08: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-babel-hmac/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

A few minor clarifications needed for implementation/precision in the security
claims:

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

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

(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.  As such, the above sentence could be
interpretation as:

Option #1: HMAC(pseudo-header + the IP header + Babel packet header + Babel
packet body)

Option #2: HMAC(pseudo-header + Babel packet header + Babel packet body)

I believe it is option #2.  Please be very clear in this text.

Other items:

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

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

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


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

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

(9) Editorial nits:
-- Section 1.  “seqno” is commonly used in Babel text but it needs to be cited
of explained here on for used -- s/seqno/sequence number/

-- Section 1.2.  Editorial. s/serious effort/effort/

-- Section 3.1. Typo.  s/authentified/authenticated/

-- Section 5.3.  Typo.  s/minumum/minimum/