RE: Security aspects with S-BFD

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

Hi Jeff, Manav, Santosh, Glen, et al,

An interesting aspect was brought up during internal discussions. Leaving aside DoS aspect, S-BFD itself provides slight increase in security, as single hi-jacked packet (w/ down state) can no longer taken down a session. i.e. at initiator, it's getting the response packets that keeps session up. Although flip-flop of received states can raise alarm in initiator implementations, it doesn't translate to automatic down.

Regarding the DoS [to reflector session] aspect, IMO, what you described appear to provide reasonable security to progress the solution, i.e. authentication itself and in combination with ACL filters. For further security [w/ real sequencing], yes I agree that small table maintenance by reflector session will be required, but opens up list of issues to consider in implementations (not necessary in protocols). Perhaps this portion can be described in base appendix.

-Nobo

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On
> Behalf Of Jeffrey Haas
> Sent: Tuesday, November 12, 2013 4:01 PM
> To: Bhatia, Manav (Manav)
> Cc: [e-mail]
> Subject: Re: Security aspects with S-BFD
> 
> 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