MAC authentication for the Babel routing protocol
Summary: Has a DISCUSS. Has enough positions to pass once DISCUSS positions are resolved.
Mirja Kühlewind Discuss
Discuss (2019-08-07 for -08)
I would like to quickly discuss the following approach taken in section 22.214.171.124: "Since a challenge may be prompted by a packet replayed by an attacker, a node MUST impose a rate limitation to the challenges it sends; the limit SHOULD default to one challenge request every 300ms, and MAY be configurable." While it is important to limit challenge messages here, there might be a better approach than static rate-limiting given this is a request-response mechanism. Usually the approach is to only allow for one outstanding request (without reply) and apply some kind of loss detect/termination rule. In your case the easiest approach would be when the 30 sec timer is expired, or if the RTT is known (or can be estimated) then a value of e.g. 3xRTT could be appropriate as well. Please consider this alternative approach. Maybe also see RFC8085 for further guidance. Further Appendix A (Incremental deployment and key rotation) contains normative language and therefore should probably be moved into the body of the document.
Comment (2019-08-07 for -08)
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?
Martin Vigoureux Yes
Deborah Brungard No Objection
Alissa Cooper No Objection
Roman Danyliw (was Discuss) No Objection
Thanks for addressing my DISCUSS points.
Benjamin Kaduk (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.
Suresh Krishnan No Objection
Warren Kumari No Objection
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>.