RE: Security aspects with S-BFD

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

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<http://tools.ietf.org/html/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]<mailto:[e-mail]>>
Date: Thursday 7 November 2013 10:18 PM
To: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[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