RE: Security aspects with S-BFD

[Santosh P K <[e-mail]>]

Glen,
   Sequence number has a meaning at initiator. Initiator on receiving the packet from the reflector can look in to sequence number and reject/accept based on that.

Thanks
Santosh P K

From: [e-mail] [mailto:[e-mail]] On Behalf Of Glen Kent
Sent: Friday, November 08, 2013 10:54 PM
To: Bhatia, Manav (Manav)
Cc: [e-mail]
Subject: Re: Security aspects with S-BFD

This is akin to saying that sequence numbers will not be used for authenticating S-BFD packets, right? If thats how it is, then cant we simply set this to 0, and ignore it on receipt.

Glen

On Thu, Nov 7, 2013 at 10:18 PM, Bhatia, Manav (Manav) <[e-mail]<mailto:[e-mail]>> wrote:
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