Subject: [babel] Shepherd review of draft-ietf-babel-hmac-03

From: Donald Eastlake <[email-masked]>
Date: Sun, 24 Feb 2019 00:53:37 -0500

Hi,

Section 2, Page 4, first sentence: "for cryptographic protection" -> "for
HMAC cryptographic protection" or, if you don't want to use HMAC here,
could change to "for cryptographic protection as specified herein".
Parallel change in the following sentence.

Section 4, page 8/9, Section 4.3.1.2, page 10. I'm slightly confused about
the interaction of these sections. So, when you receive a packet with a
successful Challenge Reply, the PC and Index are stored in the Neighbor
Table entry for the sender. Then, a bit further down in Section 4, it says
to compare the received PC with the PC in the Neighbor Table and to discard
the packet if the PC in the packet is smaller or equal to it. So, if you
received a packet with a successful Challenge Reply, you would store the PC
and Index and then later find the PC in the packet and Neighbor Table to be
equal so you discard the packet, which might be OK since you have already
set the Neighbor Table fields.  But in 4.3.1.2, it clearly contemplates
putting other TLVs into the packet with the Challenge Reply, with TLVs
would get discarded. Or am I just confused?

Section 5.2. We have already argued over the packet format diagram. I guess
we will see what other levels of review say.

The various timers here (5 min to discard Neighbor Table entry (Section
4.4), 30 seconds challenge expiry timer (Section 4.3.1.1), and 300ms
challenge rate limit (Section 4.3.1.1)) should be described as configurable
with a default value of the value currently suggested.

The TLV type values have been assigned. Please replace TBDs with the IANA
values and the IANA Considerations section should start with something like
"IANA has allocated the Type values listed below for the TLVs specified in
this document". (See https://www.iana.org/assignments/babel/babel.xhtml)

The size limit of 192 for nonces should be motivated. Perhaps "to leave
some room for possible future sub-TLV inclusion".

Appendix A: Seems like somewhere in the main text body it should say that
"Implementations SHOULD be separately configurable to (1) send or not send
HMAC security TLVs and (2) process or ignore HMAC security TLVs on receipt."

Appendix B: Add after Appendix B header and before Appendix B.1 header:
"RFC-Editor: Please remove this section before publication".

Thanks,
Donald
===============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 1424 Pro Shop Court, Davenport, FL 33896 USA
 [email-masked]

---

From: Juliusz Chroboczek <[email-masked]>
Date: Sun, 24 Feb 2019 12:44:19 +0100

Thanks a lot, Donald, you make some good points.  I'll produce a new
revision ASAP.

-- Juliusz