Summary: Has enough positions to pass.
Thanks for addressing my DISCUSS points.
Nits: - sec 188.8.131.52 please clarify if the challenge request 300ms limit is per neighbor or per sending node (184.108.40.206 says per neighbor for challenge reply; I suspect it’s the same?) - sec 7. “...this sort of resource attacks less effective...” s/attacks/attack”
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.
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?
Please mention RFC2104 in section 2 when HMAC is mentioned for the first time.
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>.