Subject: AD review of draft-ietf-bfd-intervals

From: "Adrian Farrel" <[email-masked]>
Date: Fri, 8 Aug 2014 20:02:07 +0100

Hello,

If you considered that Jeff helped find the line between "exact" and
"pedantic" then you may rest assured that I have crossed it (in one
direction or the other).

This is my usual AD review of your document to advance the publication
request. It is a short document (Hooray!) and is perfectly clear.
Nevertheless, I have picked a few holes for style and clarity. Please
feel free to dispute these points with me if you like. Until then, or
until I see a revised version of the document, I have placed the I-D
in "Revised I-D Needed" state.

Thanks for your work,
Adrian

===

It seems to me that the main benefit in this work is to improve the 
chances of interoperability between hardware implementations that need
to select a hard-wired subset of interval values at build time.  There
are two points arising from this:

- You should recommend that implementations that can do so, should 
  support a superset of the values identified here, and suggest that
  implementations try to support a considerably more flexible set of
  values to facilitate operator control of the responsiveness and
  scalability of BFD.

- You should observe that not all implementations of BFD are intended
  to interoperate. This may be particularly true for certain hardware
  implementations (e.g., BFD for MPLS-TP and BFD for Ethernet LAG).
  This *might* have an impact on whether every implementation has to
  support every value in the set. Whether or not is does have an impact
  could usefully be commented in the document.

---

The Abstract might benefit from one line saying what an "interval value"
is. Something like,

   "BFD requires that messages are transmitted at well-known intervals
    and provides a way to negotiate the interval used by BFD peers."

---

I only see one use of RFC 2119 language. Section 3 has 

   In technical terms the requirement is as follows: a BFD
   implementation SHOULD support all values in the set of Common
   interval values which are equal to or larger than the fastest, i.e.
   lowest, interval the particular BFD implementation supports.

Maybe you don't actually need uppercase "SHOULD" and then you could 
drop the "Requirements Language" paragraph. 

---

Section 1

   number of BFD sessions in increasing.

s/in/is/

---

Section 3

   This document is not adding new requirements with respect to how
   exact a timer value must be implemented.

I think you don't mean "the precision with which a timer value must be 
implemented", but if you do, please change to say that. Otherwise, I
suggest

   This document is not adding new requirements with respect to how
   a timer value must be implemented.

---

Section 3

   How is the "Common interval set" used exactly?  In the example above,
   vendor "A" has a fastest interval of 10msec and thus would be
   required to support all intervals in the common set that are equal or
   larger than 10msec, i.e. it would support 10msec, 20msec, 50msec,
   100msec, 1sec.  Vendor "B" has a fastest interval of 20msec and thus
   would need to support 20msec, 50msec, 100msec and 1sec.  As long as
   this requirement is met for the common set of values, then both
   vendor "A" and "B" are free to support additional values outside of
   the common set.

I disagree! In the example you have used, implementation "A" will try to
set up the session with 10msec and implementation "B" will support that
interval because it is in the set.

I think that, to give the example meaning you need to have "A" initially
suggest a value that is not in the set, for example 15msec. Then "B" 
will respond with 20msec and that value will be chosen because it is in
the set.

---

Section 5

This is rally to check with you. Can influencing the interval value used
by a BFD session be used as part of an attack? For example, can forcing 
the transmission time to be slower make it harder to detect naughtiness?
And can forcing the interval to be faster help cause DoS? If so, does
limiting the set of available values make attacks easier?

---

From: Jeffrey Haas <[email-masked]>
Date: Mon, 11 Aug 2014 13:27:36 -0400

Adrian,

On Fri, Aug 08, 2014 at 08:02:07PM +0100, Adrian Farrel wrote:
> to select a hard-wired subset of interval values at build time.

A non-obvious property is that it additionally helps software
implementations as well.  BFD scaling tends to be a matter of both sessions
and the relevant timers.  By providing a common timer set, it may be
possible to supplement the logic in software implementations to better
multiplex sessions.

Such points were left out of the document simply because it's endlessly easy
to justify common intervals. :-)

>  There

I'm unclear on the benefit of such text.  This document roughly says "here's
the minimum".  You're essentially saying "but do better if you can!"  That
seems implied.

>   could usefully be commented in the document.

I'm also unclear on why this would be the case.  BFD "interoperates"
perfectly fine as long as you can configure at least one interval set both
sides are willing to respect.  If you observation is that a given pair of
implementations must have at least one set of intervals they're willing to
use - again that seems implied.

> limiting the set of available values make attacks easier?

BFD is incredibly good at being used to say "this has gone down" and is
often implemented just with that edge transition in mind.  In order to
maliciously manipulate the timers in question, it would be necessary to have
a full man-in-the-middle that is capable of actively attacking at BFD
speeds.  If you're to that point, you should have turned on authentication
in the first place.  In such an event, you're already vulnerable to the
slow-down attack courtesy of cryptography.

I believe the case is academic and useful for beer discussion. :-)

Now... S-BFD may be a different matter.

-- Jeff

---

From: Marc Binderberger <[email-masked]>
Date: Tue, 12 Aug 2014 00:34:39 -0700

Hello Adrian,

I see Jeff has already replied, which reminds me I should focus on this email 
thread as well.

> are two points arising from this:

correct.

>   values to facilitate operator control of the responsiveness and

we actually mention 2 times - in the abstract and in section 3 that 
implementations are not restricted to the Common Interval set and can add 
more supported intervals. I don't think I have to encourage vendors here. If 
"more is better" depends on the scenario, e.g. for last-mile-copper-to-IP 
devices to residential customers the 100msec + 1sec may be all that is 
needed. Core/Access router vendors will likely support more values than we 
list in the draft, to offer flexibility for the customers.

>   could usefully be commented in the document.

you lost me here. You don't mean that BFD for MPLS-TP does not talk to BFD 
for LAG? I would think it is obvious that trying this combination is outside 
what any document talks about.
Also the document is informational and we talk about a "SHOULD" when it comes 
to support the Common Interval set. Plus we have the rule that every 
implementation can defines it's own fastest interval and everything in the 
Common set that is faster does not need to be supported. So the fact that you 
can implement only a subset is "clear" I think. Our interest is to encourage 
implementors to go with the full set instead of "cherry picking", thus we 
haven't been more explicit.

But I'm still not sure I understand your comment, so my reply may be 
completely "off" :-)

>     and provides a way to negotiate the interval used by BFD peers."

Ah I see, we jumped immediately in the middle of the topic. Good idea, let me 
add this.

> drop the "Requirements Language" paragraph. 

oh, indeed. Hmm, I think this SHOULD remained as this is the core of the 
draft: we encourage implementors to implement the full set of Common values 
(*), otherwise the effect of this draft would be reduced as the chances to 
find an agree-able interval are reduced. Thus the "official" language. I 
personally would like to keep it.

(*: full set from the fastest interval the implementation suports)

>    number of BFD sessions in increasing.

sorry for the mistake and Merci! Fixed.

> implemented", but if you do, please change to say that. Otherwise, I

Ah yes, "precision" is a better fit for what we want to say. Thanks, 
correcting it.

> interval because it is in the set.

I disagree :-) Section 3 says this

In other words we allow for an implementor to define the fastest interval 
that the platform should support and ask to implement all Common Interval 
values that are equal/larger than this fastest value.

It comes from the original draft when we wanted to define mandatory 
requirements. We have soften the draft since then but it still serves the 
purpose to define how to deviate from the Common set: you may drop the very 
fast values. Not every hardware implementation will support 3.3msec and 
3.3/10/20 msec is hard or even impossible for software-based BFD.

> limiting the set of available values make attacks easier?

okay, the sentence in section 5 is short I admit :-) But this draft is not 
introducing any new mechanism how to negotiate the interval; it only shows 
how the mechanism of RFC5880 can be used to build a negotiation-sequence.
We do not force faster intervals, the adjustment is to slower intervals when 
the negotiation fails.
There is a risk - although I don't see an attack vector - with the fact that 
the final interval may be slower than the initial request, i.e.you don't get 
the service requested. What the draft contributes is it helps to find a 
common interval and sessions go up where otherwise they may stay down.

Regards, Marc

---

From: Marc Binderberger <[email-masked]>
Date: Tue, 12 Aug 2014 00:43:11 -0700

Hello Jeff,

> I believe the case is academic and useful for beer discussion. :-)

and fortunately US and UK are in agreement that the "correct" metric is a 
pint ;-)

> Now... S-BFD may be a different matter.

What potential problem do you see?  Actually for S-BFD I would have thought 
we don't have the interval problem as the reflector just reflects. It will 
introduce some minimum interval it can handle but otherwise all it does is 
introducing jitter. There are no timers on the reflector.

And for the initiator, well, it's the same node, so it should support the 
same intervals for Rx detect timer that it supports for Tx (?).

Regards, Marc

---

From: Jeffrey Haas <[email-masked]>
Date: Tue, 12 Aug 2014 11:44:16 -0400

Marc,

> same intervals for Rx detect timer that it supports for Tx (?).

The distinction has less to do with the intervals (S-BFD has DoS-like
security considerations that are still highest on my list of concerns) than
it does with expected use case.

In regular BFD, we're often most interested in hearing that the session has
gone down.  It's partially why the slower negotiation isn't that big a deal.

In S-BFD, a big portion of the use case is the *up* transition.  Doing a
connectivity check prior to using a negotiated segment routed path, for
example.  In such cases, attacks that slow down the negotiated session,
especially given that they are much more likely to be multi-hop, are far
more interesting and a bit less academic.

-- Jeff

---

From: "Nobo Akiya (nobo)" <[email-masked]>
Date: Tue, 12 Aug 2014 16:57:36 +0000

Hi Marc, Adrian,

> common interval and sessions go up where otherwise they may stay down.

I've spent some time thinking about this, but my conclusion is still the same: this document does not introduce any new security concerns. Attackers knowing or not knowing the common intervals won't result in any additional security concerns to devices implementing the common intervals. Perhaps we can expand the Security Considerations section a bit to make it more obvious on what we mean.

   This document does not introduce any additional security concerns.
   The security considerations described in the BFD documents, [RFC5880]
   and others, apply to devices implementing the BFD protocol,
   regardless of whether or not the common interval set is implemented.

 Thanks!

-Nobo

---

From: Gregory Mirsky <[email-masked]>
Date: Tue, 12 Aug 2014 17:43:36 +0000

Hi Jeff,
taking a step into pedantic camp (not the first time though).

"Doing a connectivity check prior to using a negotiated segment routed path ..."

Two notes:
*       we will do either continuity check or connectivity verification. I think that with S-BFd it will be former;
*       failure on reverse path may give us false negative unless we ensure S-BFD uses co-routed bi-directional associated OAM channel that, in forwarding direction, is co-routed with the negotiated segment routed path.

        Regards,
                Greg

-----Original Message-----
From: Jeffrey Haas [mailto:[email-masked]]
Sent: Tuesday, August 12, 2014 8:44 AM
To: Marc Binderberger
Cc: Jeffrey Haas; Adrian Farrel; [email-masked]; [email-masked]
Subject: Re: AD review of draft-ietf-bfd-intervals

Marc,

On Tue, Aug 12, 2014 at 12:43:11AM -0700, Marc Binderberger wrote:
> What potential problem do you see?  Actually for S-BFD I would have
> thought we don't have the interval problem as the reflector just
> reflects. It will introduce some minimum interval it can handle but
> otherwise all it does is introducing jitter. There are no timers on the reflector.
>
> And for the initiator, well, it's the same node, so it should support
> the same intervals for Rx detect timer that it supports for Tx (?).

The distinction has less to do with the intervals (S-BFD has DoS-like security considerations that are still highest on my list of concerns) than it does with expected use case.

In regular BFD, we're often most interested in hearing that the session has gone down.  It's partially why the slower negotiation isn't that big a deal.

In S-BFD, a big portion of the use case is the *up* transition.  Doing a connectivity check prior to using a negotiated segment routed path, for example.  In such cases, attacks that slow down the negotiated session, especially given that they are much more likely to be multi-hop, are far more interesting and a bit less academic.

-- Jeff

---

From: Jeffrey Haas <[email-masked]>
Date: Tue, 12 Aug 2014 14:07:06 -0400

> taking a step into pedantic camp (not the first time though).

Something we appreciate you for. :-)

> *       we will do either continuity check or connectivity verification. I think that with S-BFd it will be former;

Agreed and I carefully chose that wording based on prior discussions.

> *       failure on reverse path may give us false negative unless we ensure S-BFD uses co-routed bi-directional associated OAM channel that, in forwarding direction, is co-routed with the negotiate…

The SR use cases are still new enough that while this is true, this may not
be the desired check.  Presume one wants to validate a service chain where
the tested point is the ingress.  By allowing the BFD traffic to follow
through the chain to the egress, the chain is more fully exercised in the
check.

Your point, however, is taken.

Again, the point is to emphasize that the edge transition of interest is not
quite the same as regular BFD use cases and thus the timing "attack"
scenarios are potentially different.

-- Jeff

---

From: Marc Binderberger <[email-masked]>
Date: Wed, 13 Aug 2014 20:14:39 -0700

Hello Adrian,

attached the (side-by-side) changes we plan to add to a new draft version, 
based on your comments. And I hope the replies we have provided are 
satisfactory for you - otherwise we need another round of discussion ;-)

Thanks & Regards,
Marc

On Tue, 12 Aug 2014 16:57:36 +0000, Nobo Akiya (nobo) wrote:
> I've spent some time thinking about this, but my conclusion is still the 
> same: this document does not introduce any new security concerns. Attackers 
> knowing or not knowing the common intervals won't result in any additional 
> security concerns to devices implementing the common intervals. Perhaps we 
> can expand the Security Considerations section a bit to make it more 
> obvious on what we mean.
>

---

From: "Adrian Farrel" <[email-masked]>
Date: Sat, 16 Aug 2014 13:33:51 +0100

All,

Thanks for the emails putting me straight on some points.

Marc, these changes are good. Please post the I-D and we'll move on.

Cheers,
Adrian

> From: Marc Binderberger [mailto:[email-masked]]
> Sent: 14 August 2014 04:15
> To: Nobo Akiya (nobo); [email-masked]
> Cc: [email-masked]; [email-masked]; Gregory
Mirsky;
> Marc Binderberger (mbinderb)
> Subject: RE: AD review of draft-ietf-bfd-intervals
> 
> Hello Adrian,
>

---

From: Marc Binderberger <[email-masked]>
Date: Sat, 16 Aug 2014 10:59:19 -0700

Hello Adrian,

thanks. The new version -03 is available:

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-bfd-intervals/

Best regards,
Marc