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

[Manav Bhatia <[e-mail]>]

Hi Rajeev,

I apologize for the delay in my responses. I have not been as regular in
catching up with my IETF mails as i should have been.


> Rajeev> I recommend, we call out this in draft. That this scheme doesn¹t
> protect against attacks & fail-over times may be affected in case of an
> attack.
>

This is a  catch-22 situation.

We had given a similar argument when we had proposed
draft-ietf-bfd-generic-crypto-auth and draft-ietf-bfd-hmac-sha.

All IGPs and FRR mechanisms depend upon BFD for their fast convergence. I
had argued many years ago on the BFD list that it was not good enough
securing IGPs with better algorithms since the lowest layer, i.e. BFD, was
still insecure. So your network was really only as secure as the weakest
link.

However, it turns out that the burden of authenticating each BFD frame,
primarily because of its frequency, destabilizes the protocol and adversely
affects its scaling to the point where its pretty much un-deployable. You
just cannot compute the SHA digests for each BFD packet. As a result the
two BFD security WG documents have still not been published as RFCs,
because we dont want to push a proposal as a standard unless we have some
degree of confidence that it is deployable and will work in the field. With
BFD, it appears that the two WG docs propose a strategy that we know will
not scale.

We then wrapped out heads around the security problem and came up with an
alternate approach where we reduce the computational burden on the routers
and provide a solution that we think is deployable and will work in 99% of
the cases. Sure, there will be a few scenarios where you're probably better
of authenticating each packet, but then that means that the security will
never be supported, since that just wouldnt scale.

One way to fix this would be to send an authenticated packet every n
seconds. The receiver can time out of it doesnt receive that in time.
However, that would still bring down your detection time to n seconds in
the worst case.

Where this draft helps you with is the following scenario:

Two routers are alive and the session is Up. An attacker spoofs a packet
declaring the session to be down. Without security, all IGPs will
reconverge and traffic shifts and all bad things will happen.

You avoid this with the security.

The scenario you describe will only work in a multi-hop BFD, because in the
single hop, i suspect the two ends will hopefully always learn when the
directly connected link goes down. Is this correct?

Cheers, Manav
>
>
> >