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

[Jeffrey Haas <[e-mail]>]

Rajeev,

On Thu, Nov 26, 2015 at 05:35:31AM +0000, Rajeev G Nair (rajeenai) wrote:
> Questions:-
> Q1) Doesn't acceptance of non-auth packets dictates state of the session (e.g. Keep it still up UP) ?
> 
> There are a few aspects of the proposal that mitigate such a situation. The scenario you are describing is that the session has actually gone down but non-auth packets keep it up.
> 
> 
> - The authenticated packet that brings the session down would have to be trapped and dropped by MiM.
> 
> Rajeev> What happens when the router indeed got disconnected from each other(a legitimate failure BFD is supposed to detect), but MiM can talk to both ? I think here you are assuming they can always talk.

This is a valid scenario.  What would likely be a proper mitigation for this
is some criteria that says 1:N packets that otherwise do not *require*
authentication MUST have authentication.  What is N?   Good question for
debate.

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.
It's deployed to assist other things.  At some point, even if BFD is "up",
the service it is protecting will decide it is down, unless it too has been
subverted.  Clearly this is a "defense in depth" situation, and
cryptographic protection of the other service is an expectation.  It's just
normally those other services aren't exchanging packets to be encrypted in
the millisecond rate range.

> 
> Not really. The whole idea behind the proposal is that state transitions are significant in BFD, come at a slower interval and should be authenticated. Most other packets are liveliness check packets, and their authentication is not significant. They come at a fast interval (the defined interval), inundate the authentication capability of the system, but do not affect the state of the session, other than when they are dropped. Intentional or unintentional dropping of packets indicates a problem, but their authentication does not convey any more information.
> 
> Rajeev > IMO, liveliness pkts are as important as other packet.
> 
> Even if MiM was to take over a session, it can at best replay a few of the UP packets till it hits the next set of occasional authenticated UP packet or it hits a authenticated state transition packet. At that point it gets exposed.
> 
> Rajeev > Again, this approach breaks BFD failure detection interval guarantee. MiM can theoretically delay the failure detection.
> 
> Preserving the authentication system for state transition packet and occasional UP packets allows one to scale not only the number of BFD sessions, but also allows us to introduce a stronger form of authentication.
> 
> Rajeev > I completely understand, this may relieve CPU burden. What I am worried about the effectiveness of authentication. To me, if requirement for authentication is relaxed for a subset of packets, BFD session itself is not authenticated. I am not saying there are no use cases for this, but draft needs to call it out.

Please recall that one of the valid scenarios for authenticated BFD is
non-meticulous authentication.  In those scenarios, the same attacks are
possible.  Meticulous authentication is intended to address this, but as you
note in the absence of the cryptographic operation on each packet it is
possible to keep the session up.

For me, this has been the main point of observation with the optimized
process: Is it better than non-meticulous mode?  I think so, since it does
still allow for sequence numbers to be incremented, helping to ensure that
there is some protection against passive replay.  

The interesting question is whether simply using non-meticulous mode and
providing a procedure to set expectations for how long the same sequence
number is expected to be used provides most of the same help?

-- Jeff