MAC Authentication for the Babel Routing Protocol
RFC 8967
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
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>.