MAC Authentication for the Babel Routing Protocol
draft-ietf-babel-hmac-12

Note: This ballot was opened for revision 08 and is now closed.

Martin Vigoureux Yes

(Deborah Brungard) No Objection

(Alissa Cooper) No Objection

Roman Danyliw (was Discuss) No Objection

Comment (2019-10-17 for -10)
No email
send info
Thanks for addressing my DISCUSS points.

Martin Duke No Objection

Comment (2020-04-15 for -10)
Nits:

- sec 4.3.1.1 please clarify if the challenge request 300ms limit is per neighbor or per sending node (4.3.1.2 says per neighbor for challenge reply; I suspect it’s the same?)

- sec 7. “...this sort of resource attacks less effective...” s/attacks/attack”

Benjamin Kaduk (was Discuss) No Objection

Comment (2019-08-22 for -10)
Thank you for addressing my Discuss (and Comment) points!

One further note on the added text: I think that there is only mixed consensus
that PBKDF2 remains an algorithm that effectively hampers dictionary attacks,
since it's parallelizable and not memory-hard, but I don't object to listing it here.

Erik Kline No Objection

Comment (2020-08-17 for -10)
[[ comments ]]

[ section 4.3 ]

* s/worthwile/worthwhile/

[ section 5 ]

* Is another option for implementations to be in a mode where:

    - they send authenticated packets
    - they attempt to authenticate packets received
    - if a packet does not authenticate is it still accepted
    - if a packet does authenticate then the neighbor entry is updated
      to note that all future communications with that neighbor must be
      use authentication (and any unauthenticated packets from this neighbor
      are dropped and maybe logged)?

[ section 7 ]

* s/an administators/an administrator's/, I think

(Suresh Krishnan) No Objection

Warren Kumari No Objection

(Mirja Kühlewind) (was Discuss) No Objection

Comment (2019-12-20 for -10)
Thanks for addressing my discuss and sorry for my late reaction (this somehow slipped through given the on-going discussion on draft-ietf-babel-rfc6126bis)!

OLD COMMENT (for the record):

The shepherd write-up says: "This document updates the rfc6126bis draft as noted on the title page
and in the Abstract." However, that seems not to be the case...?

This brings me to a separate question I would like to ask: Why is this an extension in a separate document and not an (optional) part of rfc6126bis?

(Barry Leiba) No Objection

(Alexey Melnikov) No Objection

Comment (2019-08-07 for -08)
Please mention RFC2104 in section 2 when HMAC is mentioned for the first time.

Alvaro Retana No Objection

Éric Vyncke No Objection

Comment (2019-08-05 for -08)
Thank you for the work put into this document. Using HMAC is usually simple but this document builds a lot of negotiation around HMAC.

Regards,

-éric

== COMMENTS ==

I am a little puzzled by why HMAC keys/mechanisms are not identified to facilitate the key rollover. The used mechanism appears a little heavy on the required computing effort to compute several HMAC.

-- Section 1 --

The text about attacks on the Babel routing protocol should be better placed in the security considerations of RFC7216bis.

== NITS ==

The DTLS document use the writing <"babel" port> while here it is <Babel port>.