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
