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

From: Mirja Kühlewind via Datatracker <[email-masked]>
Date: Wed, 07 Aug 2019 05:18:00 -0700

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?

---

From: Juliusz Chroboczek <[email-masked]>
Date: Wed, 07 Aug 2019 15:49:31 +0200

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

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

[...]

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

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

> 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

---

From: Mirja Kuehlewind <[email-masked]>
Date: Wed, 7 Aug 2019 16:11:28 +0200

Hi Juliusz,

Please see below.

> On 7. Aug 2019, at 15:49, Juliusz Chroboczek <[email-masked]> wrote:
> 
> Dear Mirja,
> 

You can also use a different timer e.g. 300s which would also ensure that a challenge is not send more often than 300s (expect in the case where you got a challenge reply but in case you are not talking to an attacker and usually not need to send another challenge request immediately). 

Implementation wise there is actually not much difference. You send a challenge and set a timer. Only that you could cancel the timer if a reply is received.

However, in any case I find 300ms rather low. RFC8085 recommends basically one active message (in case you have a response-reply pattern) or not more than one message every 3 seconds.

> requirements from the description of the protocol.

Actually not sure but I would say common practice. Usually you have tis separation but having different sections with meaningful titles.

> hope that it will come to the attention of the OSPF community.)

I understand the argument for readability, however, in the IETF we have put a strong focus on not specifying insecure protocols anymore and therefore it would make a lot of sense to see this part of the protocol as an essential part and not as an extension only. It’s about encouraging people to implement it.

Mirja

---

From: Juliusz Chroboczek <[email-masked]>
Date: Wed, 07 Aug 2019 16:26:00 +0200

> You can also use a different timer e.g. 300s which would also ensure
> that a challenge is not send more often than 300s (expect in the case
> where you got a challenge reply but in case you are not talking to an
> attacker and usually not need to send another challenge request immediately).

If the challenge reply is lost, then the challenge needs to be resent.  It
would not be acceptable to cause a 5 min blackhole after a single packet
loss.

> However, in any case I find 300ms rather low. RFC8085 recommends
> basically one active message (in case you have a response-reply pattern)
> or not more than one message every 3 seconds.

This would mean creating a 3 second blackhole after a single packet loss.

I'll expand on that further in my reply to your review of 6126bis, but
I believe that RFC 8085 speaks about UDP traffic across the Internet.
Babel is a link-local protocol -- there are no intermediary nodes to
congest.

Mirja, if the RFC 8085 limit is to be enforced for link-local protocols,
then OSPF cannot possibly work.

-- Juliusz

---

From: Mirja Kuehlewind <[email-masked]>
Date: Wed, 7 Aug 2019 17:21:41 +0200

Hi Juliusz,

See below.

> On 7. Aug 2019, at 16:26, Juliusz Chroboczek <[email-masked]> wrote:
> 

Why 5 mins? If the challenge needs to be retransmitted, then the mechanism for retransmitting seems to be missing in the draft or what do I miss?

Mirja

---

From: Juliusz Chroboczek <[email-masked]>
Date: Wed, 07 Aug 2019 17:41:05 +0200

> Why 5 mins?

You're suggesting 300s in the excerpt cited above.

> If the challenge needs to be retransmitted, then the mechanism for
> retransmitting seems to be missing in the draft or what do I miss?

A -> B: Challenge
B -> A: Challenge reply gets lost

B -> multicast group: normal control packet

(At B, the control packet fails the index test (5th bullet point in 4.3).)

A -> B: Challenge

-- Juliusz

---

From: Mirja Kuehlewind <[email-masked]>
Date: Wed, 7 Aug 2019 17:50:55 +0200

Hi,

Inline.

> On 7. Aug 2019, at 17:41, Juliusz Chroboczek <[email-masked]> wrote:
> 

Sorry I mean 300ms… (one important letter).
> B -> multicast group: normal control packet

But this is usually send every 4 seconds or so…? So the important but seem that these two values fit together.

> (At B, the control packet fails the index test (5th bullet point in 4.3).)

I wouldn’t call this a retransmission but rather a new Challenge… anyway that’s just naming…

Mirja

---

From: Juliusz Chroboczek <[email-masked]>
Date: Wed, 07 Aug 2019 18:16:24 +0200

> Sorry I mean 300ms… (one important letter).

Ah, ok.  I think I undestand what you mean now.

> But this is usually send every 4 seconds or so…?

Not necessarily.  The timers are configurable, and there can be multiple
packets sent over a single hello interval (e.g. when the routing table
doesn't fit in a single packet).  The rate limiting here is going to limit
how fast we can acquire new neighbours in the presence of packet loss.
The value 300ms was chosen as being a compromise between the amount of
traffic an attacker can cause with replayed packets, and the hard limit it
imposes on neighbour acquisition in the presence of packet loss.

This has nothing to do with congestion control, Mirja, it's solely about
resistance to DoS.  In normal operation (with no evil attacker replaying
massive numbers of packets and in the absence of packet loss), there's
going to be just two challenge/reply exchanges (one in each direction) for
every neighbour acquisition.  This implies that there is no opportunity
to establish RTT state, and no useful opportunity to reset timers when
a reply is received.

-- Juliusz

---

From: Mirja Kuehlewind <[email-masked]>
Date: Wed, 7 Aug 2019 18:54:15 +0200

Hi Juliusz,

Okay, if I understand you correctly what you want is actually to limit “failed” challenge requests only (where no reply is received or the reply is not valid). Correct? I think then you should specify it this way. Further if the goal is to not run into the rate limit if a single packet is lost, then that is also possible with a token-bucket-like approach, e.g. allow 3 non-confirmed challenges per 10s (or even larger values depending in the expected loss rate). This would make more sense to me as that avoids the dependency on the hello interval.

Mirja

> On 7. Aug 2019, at 18:16, Juliusz Chroboczek <[email-masked]> wrote:
>