Re: Security aspects with S-BFD

[Glen Kent <[e-mail]>]

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