RE: Security aspects with S-BFD

["Nobo Akiya (nobo)" <[e-mail]>]

Hi Manav,

> -----Original Message-----
> From: Bhatia, Manav (Manav) [mailto:[e-mail]]
> Sent: Sunday, March 09, 2014 7:35 PM
> To: Nobo Akiya (nobo); MALLIK MUDIGONDA (mmudigon); [e-mail]
> Subject: RE: Security aspects with S-BFD
> 
> I agree with Nobo here. I don't think binding BFD with a timing protocol is a
> good idea.

Glad to hear that!

> 
> > I think this is a general topic (i.e. applicable to both BFD and S-BFD) that
> > should continue to be discussed, and certainly would like to hear more
> from BFD and KARP experts.
> 
> And pray what is that? What would you like to hear more about?

I was hoping to see more on discussions around suggestions made by section 6 of draft-ietf-karp-bfd-analysis-01 (for BFD and/or S-BFD), particularly usage of time in place of sequence number. That will be beneficial for one to make a call on embracing the suggestions.

-Nobo

> 
> Cheers, Manav
> 
> From: Rtg-bfd [mailto:[e-mail]] On Behalf Of Nobo Akiya
> (nobo)
> Sent: Friday, March 07, 2014 9:46 PM
> To: MALLIK MUDIGONDA (mmudigon); [e-mail]
> Subject: RE: Security aspects with S-BFD
> 
> Good to see this discussion continuing (thank Mallik!).
> 
> I'm a bit skeptical of creating a hard dependency from BFD/S-BFD to time
> synchronization protocol. Meaning, if we do this, malfunctions in the time
> synchronization protocol or even time drift can take down all BFD/S-BFD
> sessions, causing instabilities in the network.
> 
> I think this is a general topic (i.e. applicable to both BFD and S-BFD) that
> should continue to be discussed, and certainly would like to hear more from
> BFD and KARP experts.
> 
> To progress S-BFD base draft, my vote would be to go with suggestion by
> Manav (below) for the time being.
> 
> -Nobo
> 
> From: Rtg-bfd [mailto:[e-mail]] On Behalf Of MALLIK
> MUDIGONDA (mmudigon)
> Sent: Friday, March 07, 2014 7:39 AM
> To: [e-mail]
> Subject: Re: Security aspects with S-BFD
> 
> Hi,
> 
> As mentioned in  draft-ietf-karp-bfd-analysis-01 section 6, if we use UTC
> time for Sequence numbers (assuming Initiator and reflector are time
> synchronized), then we can mitigate the problem of DOS and Replay attacks
> at reflectors. Please share your thoughts.
> 
> Thanks
> 
> Regards
> Mallik
> 
> From: <Bhatia>, "Manav (Manav)" <[e-mail]>
> Date: Thursday 7 November 2013 10:18 PM
> To: "[e-mail]" <[e-mail]>
> Subject: Security aspects with S-BFD
> 
> Hi,
> 
> S-BFD describes the reflector sessions which raises interesting security
> considerations.
> 
> Since the reflector sessions are stateless (that's one of the biggest
> advantages) it's impossible for the reflector to keep track of the sequence
> number that its heard from its peers. This means, that the reflector is
> susceptible to both inter-session and intra-session replay attacks. We had a
> discussion internally amongst the co-authors and had the following
> proposal that we wanted to vet before the WG members.
> 
> Would like to hear the WGs opinion on this.
> 
> 1. The Initiator picks up a crypto sequence number depending upon the
> authentication mode that its using (meticulous or non meticulous). It sends
> a packet to the Reflector with this seq num.
> 
> 2. The reflector maintains no session state and hence does not look at the
> crypto sequence number before accepting the packet. It looks at the Key ID
> (draft-ietf-bfd-generic-crypto-auth-05) in the incoming packet (or it can do it
> based on its own database where it maps the neighbor to the key iD) and
> verifies the authentication data. If everything looks good, it processes the
> packet.
> 
> 3. When responding the Reflector needs to compute the Authentication
> data. It uses the same sequence number that it received in the S-BFD packet
> that it is responding to. It knows the Key ID, and thus the SA. It computes
> the authentication data and sends the S-BFD packet out.
> 
> 4. The Initiator receives the response from the Reflector. It only accepts the
> S-BFD packet if it either comes with the same sequence number as it had
> sent or its within the window that it finds acceptable (described in detail in
> Sec 3.4 of draft-ietf-bfd-generic-crypto-auth-05)
> 
> Benefits of this scheme.
> 
> 1. Reflectors continue to remain stateless despite using security.
> 
> 2. Reflectors are not susceptible to replay attacks as they always respond to
> S-BFD packets irrespective of the sequence number carried.
> 
> 3. An attacker cannot forge packets from the Reflector since the Initiator
> will only accept S-BFD packets that come with the sequence number that it
> had originally used when sending the S-BFD packet.
> 
> Drawbacks of this scheme.
> 
> 1. Reflectors are susceptible to DoS attacks since they respond to all
> incoming S-BFD packets. This gets worse when cryptography is used as the
> work load drastically increases as security is employed.
> 
> Cheers, Manav
> 
>