Re: Request for WG adoption of draft-mahesh-bfd-authentication

[Jeffrey Haas <[e-mail]>]

Rajeev,

On Thu, Dec 03, 2015 at 10:16:27PM +0000, Rajeev G Nair (rajeenai) wrote:
> >No particular offense to you or others on this point, but I must state
> >something: I've always found the idea of the attack of keeping BFD *up* to
> >be silly. :-)
> >
> >In general, BFD is used for fast-failover, but not on a stand-alone basis.
> 
> Rajeev> If authentication is compromised, fast-fail over won¹t happen,
> right?. Any delay in fast-faill over will question BFD. BFD fail-overs are
> as secure as the auth scheme used.

I agree with your analysis.

I repeat my comment.  If your attack is keeping up a given resource until
either the resource's built-in (if any) keepalive mechanism takes effect or
until an expected BFD authenticated packet is expected (not in current spec,
but we've mentioned it on-list a few times), then I think it's a pretty weak
case.

The attack would effectively to break a link to man-in-the-middle and then
keep the link up from a BFD perspective.  This might lead to loss of
service/blackholing.  But unless a similar MitM is done for each covered
service as well, it's just as likely that the covered services will note
failures.  If you're able to MitM all of the services, why would you attack
BFD?

Arguably, if you care about this scenario, the answer is to use a BFD
authentication mode that authenticates each BFD packet, as per the existing
meticulous authentication.

[Authors take note]
What this potentially argues is that we need the described behavior to be
"semi-meticulous" (or pick better words of choice).  This way the behavior
can be explicitly chosen.  This simply means new authentication code points.
Although if we're getting to the point of meticulous, non-meticulous and
semi-meticulous, perhaps the gen-auth spec should be updated to simply allow
a mode and then a cipher suite as the contents.

-- Jeff