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

[Manav Bhatia <[e-mail]>]

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]
> 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]] *On Behalf Of *Manav
> Bhatia
> *Sent:* Tuesday, February 24, 2015 3:05 PM
> *To:* Jeffrey Haas
> *Cc:* [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]> 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
>
>
>