Re: Security aspects with S-BFD

[Jeffrey Haas <[e-mail]>]

Manav,

On Thu, Nov 07, 2013 at 04:48:47PM +0000, Bhatia, Manav (Manav) wrote:
> 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.

It would be good to see some discussion from the S-BFD authors regarding
light-weight state for authentication.  In other words, just enough to
verify crypto sequence numbers.

One challenge that immediately comes to mind is that since the sessions are
completely stateless, this means the reflector really can't know if the
initiator rebooted or not, especially if the initiator is foolish enough to
have the same discriminator.

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

Protecting the Initiator is good.  But ...

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

This continues to be my primary concern about the security for this feature.
In the absence of *any* state, it's very difficult to have a low-work filter
that protects the Reflector against cryptographic work attacks.

Also, as best I understand several of the potential use cases for this
feature, every S-BFD node may end up being a Reflector in some of those
cases.

To take a post-WG session comment to heart, this feature does have several
resemblances to simply using IP Ping.  This means that several of the
security considerations associated with ICMP attacks (rate limiting, etc.)
are likely applicable.

> Cheers, Manav

-- Jeff