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

[Juliusz Chroboczek <[e-mail]>]

Dear Mirja,

Thank you for your review.

(Please be aware that I cannot check my work mail until Thursday, please
copy the list if you desire a timely response.)

> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------

> I would like to quickly discuss the following approach taken in section
> 4.3.1.1:

[...]

> there might be a better approach than static rate-limiting given this is
> a request-response mechanism.  [...] 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 well.
> for further guidance.

First of all, what we're trying to avoid here is an attacker causing the
current node to generate unbounded amounts of traffic.  With static rate
limiting, we guarantee that an attacker can cause at most n/0.3 packets
per second to be sent, where n is the number of distinct source addresses
in the attacker's collection of captured packets.  No such guarantee
exists if the rate limiting is made dynamic.

Second, in normal usage the challenge/response mechanism is used when
establishing state with a new neighbour.  No RTT information is likely to
be available at that early stage.  Thus, your suggestion would cause a 30s
delay whenever a challenge reply is lost.

> Further Appendix A (Incremental deployment and key rotation) contains
> normative language and therefore should probably be moved into the body
> of the document.

Is that a hard requirement?  It makes sense to me to separate operational
requirements from the description of the protocol.

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

The "updates" was removed in -05 at the request of Martin Vigoureux.

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

I want it to be easily readable by people who are not interested in the
specifics of Babel, as this makes it more likely that it will be reviewed
by competent security specialists.  (In addition, since this protocol was
designed to solve some of the issues described in RFC 6039, I have some
hope that it will come to the attention of the OSPF community.)

Thanks again,

-- Juliusz