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

["Nobo Akiya (nobo)" <[e-mail]>]

Hi Marc, Adrian,

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

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