Subject: Security aspects with S-BFD

From: "Bhatia, Manav (Manav)" <[email-masked]>
Date: Thu, 7 Nov 2013 16:48:47 +0000

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

---

From: Glen Kent <[email-masked]>
Date: Fri, 8 Nov 2013 22:53:52 +0530

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) <
[email-masked]> wrote:

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

---

From: Santosh P K <[email-masked]>
Date: Fri, 8 Nov 2013 17:38:19 +0000

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: [email-masked] [mailto:[email-masked]] On Behalf Of Glen Kent
Sent: Friday, November 08, 2013 10:54 PM
To: Bhatia, Manav (Manav)
Cc: [email-masked]
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) <[email-masked]<mailto:[email-masked]>> wrote:
Hi,

Benefits of this scheme.

Cheers, Manav

---

From: Jeffrey Haas <[email-masked]>
Date: Tue, 12 Nov 2013 16:00:53 -0500

Manav,

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

> 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 packe…

Protecting the Initiator is good.  But ...

> 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 employ…

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

---

From: "Nobo Akiya (nobo)" <[email-masked]>
Date: Tue, 12 Nov 2013 21:41:39 +0000

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: [email-masked] [mailto:[email-masked]] On
> Behalf Of Jeffrey Haas
> Sent: Tuesday, November 12, 2013 4:01 PM
> (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.
> >
> 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.
> 
> 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.
> 
> security considerations associated with ICMP attacks (rate limiting, etc.) are
> likely applicable.
> 
> > Cheers, Manav
> 
> -- Jeff