[babel] Mirja Kühlewind's Discuss on draft-ietf-babel-hmac-08: (with DISCUSS and COMMENT)

[Mirja Kühlewind via Datatracker <[e-mail]>]

Mirja Kühlewind has entered the following ballot position for
draft-ietf-babel-hmac-08: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-babel-hmac/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

I would like to quickly discuss the following approach taken in section 4.3.1.1:
   "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:
----------------------------------------------------------------------

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?