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

[Gregory Mirsky <[e-mail]>]

Hi Manav, et. al,
I think that authors had not considered impact of the proposal on defined in RFC 6428 RDI functionality. Perhaps you’ll call support of the RDI “broken implementation”. But that’s OK.

                Regards,
                                Greg

From: Manav Bhatia [mailto:[e-mail]]
Sent: Tuesday, February 24, 2015 4:35 PM
To: Gregory Mirsky
Cc: Jeffrey Haas; [e-mail]
Subject: Re: New BFD Authentication Optimization draft draft-mahesh-bfd-authentication-00

Hi Greg,

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! :-)

Cheers, Manav

On Wed, Feb 25, 2015 at 6:02 AM, Gregory Mirsky <[e-mail]<mailto:[e-mail]>> wrote:
Hi Manav,
what evidence authors have to state:
“What we have proposed here requires no change to the current hardware based implementations.”
Had you performed a poll? Would you kindly share the results?

                Regards,
                                Greg

From: Rtg-bfd [mailto:[e-mail]<mailto:[e-mail]>] On Behalf Of Manav Bhatia
Sent: Tuesday, February 24, 2015 3:05 PM
To: Jeffrey Haas
Cc: [e-mail]<mailto:[e-mail]>
Subject: Re: New BFD Authentication Optimization draft draft-mahesh-bfd-authentication-00

Hi Jeff,

I am not sure how easy is it to do this for HW based implementations where you would be required to cache the last good packet heard from all sessions.

What we have proposed here requires no change to the current hardware based implementations.

Cheers, Manav

On Wed, Feb 25, 2015 at 2:43 AM, Jeffrey Haas <[e-mail]<mailto:[e-mail]>> wrote:
On Fri, Feb 13, 2015 at 10:31:43AM -0800, Ashesh Mishra wrote:
> Hi BFD Experts,
> The 00 version of BFD Authentication Optimization draft is now online:
> https://datatracker.ietf.org/doc/draft-mahesh-bfd-authentication/
> The draft describes method for selectively authenticating certain BFD frames to avoid computational overhead.

I have perhaps a rather basic question which I'd been thinking on since it
was said this draft may be coming:

Is there any reason we couldn't simply use the non-meticulous versions of
the keyed authentication and rely on caching?

Essentially, in stable state BFD packets will be the same thing over and
over again.  As long as the sequence number isn't increased, knowing that a
given packet has passed authentication previously is sufficient if it's the
same packet.

Given how small BFD packets are, cache the entire packet?  Is the memory at
that level of preciousness in the hardware implementations?

Basically, in RFC 5880, section 6.8.6, at the procedural component that says
"MUST be authenticated", once this step has completed for this sequence
number and caching is determined to be okay, store the packet.  When the
sequence number is seen a second time and the authentication contents are
the same, simply compare the bytes of the packet to the cache.

I suspect I'm about to get a very strong reality check here. :-)

-- Jeff