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

[Mahesh Jethanandani <[e-mail]>]

Rajeev,

See comments inline.

> On Nov 24, 2015, at 8:42 PM, Rajeev G Nair (rajeenai) <[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.
- 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.

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.

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.

> 
> 
> 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/ <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]