Pls see tagged Rajeev>

thanks
~Rajeev

From: Mahesh Jethanandani 
<[email protected]<mailto:[email protected]>>
Date: Wednesday, November 25, 2015 at 9:34 AM
To: Rajeev Nair <[email protected]<mailto:[email protected]>>
Cc: "Reshad Rahman (rrahman)" <[email protected]<mailto:[email protected]>>, 
"[email protected]<mailto:[email protected]>" 
<[email protected]<mailto:[email protected]>>, 
"[email protected]<mailto:[email protected]>"
 
<[email protected]<mailto:[email protected]>>
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) 
<[email protected]<mailto:[email protected]>> 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 <[email protected]<mailto:[email protected]>> on 
behalf of "Reshad Rahman (rrahman)" 
<[email protected]<mailto:[email protected]>>
Date: Friday, November 20, 2015 at 4:03 AM
To: "[email protected]<mailto:[email protected]>" 
<[email protected]<mailto:[email protected]>>, 
"[email protected]<mailto:[email protected]>"
 
<[email protected]<mailto:[email protected]>>
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
[email protected]<mailto:[email protected]>





Reply via email to