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

["Rajeev G Nair (rajeenai)" <[e-mail]>]

Pls see tagged Rajeev>

thanks
~Rajeev

From: Mahesh Jethanandani <[e-mail]<mailto:[e-mail]>>
Date: Wednesday, November 25, 2015 at 9:34 AM
To: Rajeev Nair <[e-mail]<mailto:[e-mail]>>
Cc: "Reshad Rahman (rrahman)" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Subject: Re: Request for WG adoption of draft-mahesh-bfd-authentication

Rajeev,

See comments inline.

On Nov 24, 2015, at 8:42 PM, Rajeev G Nair (rajeenai) <[e-mail]<mailto:[e-mail]>> wrote:

Jeff & Reshad,

 Read through the document. Interesting concept.

Here is my understanding:-
 1) Current scheme. Both switches are configured to use same auth. Currently, no packets will be accepted unless all received pkts match with configured auth.
 2) Proposal is to come up with a scheme to authenticate only a subset of packets (those signaling a state change as mentioned).

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.

- The sequence number of the subsequent UP packets would have to correspond to the next expected sequence number.
- The occasional authentication of three UP packet would have to pass the test by MiM.


Q2) These non-auth packets are not protected from MiM attacks, right?

See above.


Q3) Doesn't mixing authenticated & non-authenticated packed make proposed scheme equivalent to non-authenticated mode ? I mean, unless every packet is authenticated, isn't benefit of bfd-auth nullified ?

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.



thanks
~Rajeev

From: Rtg-bfd <[e-mail]<mailto:[e-mail]>> on behalf of "Reshad Rahman (rrahman)" <[e-mail]<mailto:[e-mail]>>
Date: Friday, November 20, 2015 at 4:03 AM
To: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Subject: Request for WG adoption of draft-mahesh-bfd-authentication

BFD WG members,

Please indicate to the WG mailing list whether you would support or not support BFD WG adoption of the following document.

https://datatracker.ietf.org/doc/draft-mahesh-bfd-authentication/

Authors, as was mentioned at IETF94, you should get your proposal reviewed by the security group.

Regards,
Jeff & Reshad.

Mahesh Jethanandani
[e-mail]<mailto:[e-mail]>