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
   "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

Comment (2019-10-17)
Thanks for addressing my DISCUSS points.

Benjamin Kaduk (was Discuss) No Objection

Comment (2019-08-22)
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.




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>.

Ignas Bagdonas No Record

Adam Roach No Record

Magnus Westerlund No Record