MAC Authentication for the Babel Routing Protocol
Note: This ballot was opened for revision 08 and is now closed.
Alvaro Retana No Objection
Erik Kline No Objection
[[ 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
Martin Duke No Objection
Nits: - sec 184.108.40.206 please clarify if the challenge request 300ms limit is per neighbor or per sending node (220.127.116.11 says per neighbor for challenge reply; I suspect it’s the same?) - sec 7. “...this sort of resource attacks less effective...” s/attacks/attack”
Roman Danyliw (was Discuss) No Objection
Thanks for addressing my DISCUSS points.
Warren Kumari No Objection
Éric Vyncke No Objection
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>.
(Martin Vigoureux; former steering group member) Yes
(Alexey Melnikov; former steering group member) No Objection
Please mention RFC2104 in section 2 when HMAC is mentioned for the first time.
(Alissa Cooper; former steering group member) No Objection
(Barry Leiba; former steering group member) No Objection
(Benjamin Kaduk; former steering group member) (was Discuss) No Objection
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.
(Deborah Brungard; former steering group member) No Objection
(Mirja Kühlewind; former steering group member) (was Discuss) No Objection
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?
(Suresh Krishnan; former steering group member) No Objection