Subject: BFD Generic Cryptographic Authentication

From: "Bhatia, Manav \(Manav\)" <[email-masked]>
Date: Tue, 18 Nov 2008 22:23:29 +0530

Hi,

We have written a small draft on BFD security.

10000ft view of the draft:

o Adds two new Auth Types - Cryptographic Authentication and Meticulous
Cryptographic Authentication. These types are generic and can
be used with any authentication algorithm. We now don't need to raise a
request with IANA before providing support for any new algo in the
future. 

o Describes how BFD can use HMAC-SHA to authenticate its packets as
opposed to Keyed MD5 and plain SHA-1 that's described in the base spec.

o Changes the order of crypto sequence number check when receiving BFD
packets. Its now done before any algorithm dependent processing is done.
In the base spec the sequence number check is done *after* all the
algorithm dependent processing is over - this imo amplifies the
possibility of a DoS attack.

o Increases the Key ID space to 2 bytes and renames Auth Key/Checksum
field in the Auth Section to Authentication Data.

Abstract:

This document proposes an extension for Bidirectional Forwarding
Detection (BFD) to allow the use of any cryptographic authentication
algorithm in addition to the already documented authentication schemes,
described in the base specification.   
        
Although this document has been written specifically to introduce two
new Authentication types it describes how BFD can use Hashed Message
Authentication Code (HMAC) construct along with the Secure Hash
algorithm (SHA) [FIPS-180-3] family of cryptographic hash functions to
authenticate the control packets.  
    
The method described in this document is generic and can be used to
extend BFD to support any cryptographic hash function in the future. 

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-bhatia-bfd-crypto-auth-00.txt

Cheers, Manav

--
Manav Bhatia,
IP Division, Alcatel-Lucent,
Bangalore - India

---

From: "Tom Sanders" <[email-masked]>
Date: Fri, 21 Nov 2008 11:07:48 +0530

Manav,

I think its a step in the right direction.

> possibility of a DoS attack.

I believe this is something very fundamental in how the security ought
to be designed for the internet protocols. You dont want to compute
the hash/digest, only to later discard the packet because some other
parameter isnt what you expected it to be (in this case the sequence
number). And this becomes all the more accentuated in case of BFD as
this byte crunching may be happening in the line cards. Good catch
indeed!

You should add a section on BFD too in
draft-ietf-opsec-routing-protocols-crypto-issues-00.txt besides PIM,
as somebody else in OPSEC meet suggested the other day.

> field in the Auth Section to Authentication Data.

Thanks. I have always found the term "checksum" rather unnerving and
is at the very least, trifle misleading.

Since this memo deals exclusively with BFD authentication, shouldnt
you spend some more time detailing how the keys should be managed
(life associated with key, start time, stop time, etc) - some
recommendations on the key entropy would also help.

-- 
Toms.

---

From: "Vishwas Manral" <[email-masked]>
Date: Fri, 21 Nov 2008 09:13:09 -0800

Hi Tom,

Thanks for your encouraging comments on the draft. There are some more
interesting thoughts in my mind right now, please read below. Manav, I
think we can atleast put some of them in the draft.

> this byte crunching may be happening in the line cards. Good catch
Thanks about this. Generally speaking we would want to do the
checksum/ hash before we would do anything because unless that is
correct we do not know the sanity of the packet. However the sequence
number itself is like a security mechanism (not to the extent of the
TCP one), as not all numbers are valid. It is a good idea to do some
checks before going in for the CPU heavy hashing mechanism.

> as somebody else in OPSEC meet suggested the other day.
Yes, we can do that. BFD falls well within scope, we have not looked
at PIM yet though.

> recommendations on the key entropy would also help.
One interesting thing about BFD is that BFD packet counters are 64
bits (as unlike other control protocols BFD packets are sent
contnuously and at a very fast rate). This will lead to sequence
number rotation faster in BFD compared to other protocols.

If I was the author of BFD base spec I would make the sequence number
counter in BFD to be 64-bits and not 32-bits.

Thanks again,
Vishwas

---

From: "Tom Sanders" <[email-masked]>
Date: Sat, 22 Nov 2008 05:40:34 +0530

Vishwas,

> checks before going in for the CPU heavy hashing mechanism.

I agree.

> One interesting thing about BFD is that BFD packet counters are 64

                       ^^^^^^^^
I presume you are talking about the sequence number here and that you
really meant 32, and not 64 bits, in the above text.

Can you give some computation of the time you think it will take the
sequence number space to wrap?

-- 
Toms.

---

From: "Vishwas Manral" <[email-masked]>
Date: Fri, 21 Nov 2008 16:18:31 -0800

Hi Tom,

> really meant 32, and not 64 bits, in the above text.
No, if you check the MIB packet counters are 64 bits (which is good
foresight on the part of the MBI authors). Which means there is an
assumption that the packet counts may go higher than 32 bits.

> sequence number space to wrap?
I am sorry I have not done the computation with any real world data
and it will depend on the interval at which you send the BFD packets.
But with 1 millisecond and 10 neighbors on an interface the counters
will wrap in less than 5 days time (for meticulously Keyed sessions).

Thanks,
Vishwas

---

From: "Tom Sanders" <[email-masked]>
Date: Sat, 22 Nov 2008 06:18:25 +0530

Vishwas,

> will wrap in less than 5 days time (for meticulously Keyed sessions).

Sounds reasonable. Why dont you increase the sequence number space to
64 bits in the new authentication types that you have defined in your
draft?

-- 
Toms.

---

From: "Vishwas Manral" <[email-masked]>
Date: Fri, 21 Nov 2008 18:26:51 -0800

Hi Tom,

Thanks for the suggestion. Yes we can add that too.

Thanks again,
Vishwas

---

From: "Bhatia, Manav \(Manav\)" <[email-masked]>
Date: Sat, 22 Nov 2008 15:39:01 +0530

Hi Tom,

> I think its a step in the right direction.

[..]

> this byte crunching may be happening in the line cards. Good catch

Thanks for the review.
 
> draft-ietf-opsec-routing-protocols-crypto-issues-00.txt besides PIM,

This needs to be taken up in OPSEC and if the folks there feel that its
worth including a section on BFD then it can certainly be done. 

[..]

> (life associated with key, start time, stop time, etc) - some

We can add some text to this effect in the next cut.

> recommendations on the key entropy would also help.

Regarding the entropy we have the following text in the draft (section
2):

Care should also be taken to ensure that the selected key is
unpredictable, avoiding any keys known to be weak for the algorithm in
use. [RFC4086] contains helpful information on both key generation
techniques and cryptographic randomness. 

[RFC4086]  Eastlake, D., 3rd, Schiller, J., and S. Crocker, "Randomness
Requirements for Security", BCP 106, RFC 4086, June 2005. 

Is there something specific that you're looking at?

Cheers, Manav

---

From: "Bhatia, Manav \(Manav\)" <[email-masked]>
Date: Mon, 24 Nov 2008 10:30:42 +0530

Hi Tom,

> Sounds reasonable. Why don't you increase the sequence number space to

You don't really need to send 64 bits in the BFD packet. 

We could have an extended cryptographic sequence number (ECSN) of 64
bits, where only the low-order 32 bits are transmitted in each packet.
The high-order 32 bits would be maintained as part of the sequence
number counter by both sender and receiver, and would be included in the
computation of the authentication data to prevent replay attacks.

Cheers, Manav