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

[Ashesh Mishra <[e-mail]>]

Greg, Jeff, et. al,
There's three implementations to consider here: hardware-only, software-only, and software state-machine with HW assist for Tx/Rx. 
HARDWARE-ONLY:The proposed method may not be best suited to such implementations (or rather, will not be easily accepted by engineers working on hardware-only implementations). At least in the sense that there will need to be major changes to the state-machine in HW (I have known this to not excite devs working on the HW programming). Non-meticulous auth with full frame caching can work, but requires even more rework to the HW logic (while providing, more or less, the same security as the proposed method). 
SOFTWARE-ONLY: The best scenario for this proposal. Getting any decent BFD detection timeout with scale in a software implementation is challenging (I must have lost at least five of years of my lifespan in the 12 months that I spent worrying about BFD stability in software). Adding auth to the mix is just plain cruel to the developers. Fewer frames to authenticate will go a long way in convincing software BFD implementers to add auth support. 
SOFTWARE-STATE-MACHINE-WITH-HW-TX-RX-ASSIST:This one is also a good candidate for this proposal. Since the state machine is in SW, the authentication can be handled in software (auth frames in the proposal are not very time sensitive). The only change needed in HW is to punt the auth frames to the software engine. 


Since there's been a lot of discussion, here's the summary of the idea and proposed changes so far:- Authenticate all frames that are meant to trigger a change in BFD state (the first few DOWN frames to support RDI, all INIT frames, P-F sequence frames)- To detect man-in-the-middle attacks while the session state is UP, generate an auth UP frame once every X seconds (10 seconds?). This way, no MITM attack will go un-detected for longer than n*X seconds (n is the detect multiplier for auth-UP frames ... it may/may-not be same as the common BFD detect multiplier).
BR,Ashesh
From: [e-mail]
To: [e-mail]
Subject: RE: New BFD Authentication Optimization draft draft-mahesh-bfd-authentication-00
Date: Wed, 25 Feb 2015 01:02:54 +0000
CC: [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]> 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