Re: New BFD Authentication Optimization draft draft-mahesh-bfd-authentication-00

[Jeffrey Haas <[e-mail]>]

Manav,

On Wed, Feb 25, 2015 at 06:05:18AM +0530, Manav Bhatia wrote:
> It requires no changes on the RX side. I concede that it does require some
> changes on the TX side.
> 
> If somebody tells me that this requires changes on the RX side as well,
> then that vendor's implementation is broken! :-)

Thinking about this a bit further, I think this is partially a matter that
authentication transitions are "under-specified" in RFC 5880.  

Basically, if you have authentication enabled on your session as a receiver,
and you don't see a packet coming in that you're expecting to be
authenticated, you'd probably just ignore it.

What I believe you're saying in that first sentence almost sounds like
you're saying that the receiver should just trust the auth bit. :-)  I
suspect you don't mean that.

My observation is that implementations likely have additional rules about
when they expect to receive authenticated packets.  This could be modeled as
a state variable for the general packet reception rules, an overlay on the
BFD FSM, whatever.  There's expectations that must be kept in sync.

The proposal in the draft as written are a bit vague as to when things can
turn on, turn off the authentication bit.  I think in fairness to the WG to
evaluate the proposal more fully, those details should be described in more
detail.

As an aside, I've made a few inquiries as to the caching suggestion I had
made previously.  It seems at least one implementation is already doing some
of that work.  I'm awaiting more details before pursuing that direction
further.

--  Jeff