Subject: Some comments on BFD Authentication ..

From: "Bhatia, Manav \(Manav\)" <[email-masked]>
Date: Sat, 1 Nov 2008 00:16:50 +0530

Hi,

I was reading draft-ietf-bfd-base-08.txt and have some comments.

(a) Sections 6.7.3 and 6.7.4 describe how keyed MD5 and SHA1 can be used
for BFD authentication - I think there is some ambiguity there.

It states that the Auth Key/Checksum field (btw this field is a really
not a "checksum" per se) must be filled with the key that is being used
to compute the MD5/SHA1 hash. So what happens if the key size is less
than the hash size? Do we repeat the key till it fills the hash size or
do we fill the remaining octets with 0 before we compute the MD5/SHA1
hash? This is important and needs to be clearly spelled out as it can
cause interop issues.

An easier and a cleaner approach would be to fill the authentication
data fields (the Auth Key/Checksum field) with either zeroes or a well
known constant. NIST recommends filling it with a well-known non-zero
constant and that's the approach that we've been following in the recent
IGP security related drafts (eg. draft-ietf-isis-hmac-sha-06).

(b) One of the comments that we received during the GEN-ART review for
ISIS crypto draft was that 1 octet for a Key ID looked to restrictive.
Applying the same logic here, can we increase the size of the Key ID
field to at least 2 octets?

(c) If you are specifying the cryptographic algorithm details in the
Auth Type (MD5, SHA1, etc) then the Auth Len is redundant and can be
simply done away with. One always knows that if the Auth Type is 2-3
then the size would be 24, etc.

(d) Why don't we add a generic (crypto-algo independent) authentication
type (say type 6) in this document? The sender just fills the Key ID,
the authentication data fields with the hash/digest, and the auth len
with the size of the digest. The BFD neighbor upon receiving this packet
would do a lookup in its local database using the key ID carried in the
packet and determine the auth algo and the secret key associated with it
to verify the packet. This way anybody intercepting the BFD packets
cannot determine the crypto algorithm being used between the two BFD
speakers. This, I've been given to understand, increases the security by
an order of magnitude. It also allows folks to use "non-standard"
algorithms as that information isn't carried in the BFD packets. Last
but not the least, we don't need to request IANA for a code point or a
new RFC to be published, each time a new cryptographic algorithm is
introduced.

We could also have a meticulous generic crypto auth type (type 7?).

(e) Any specific reason why we're not using the HMAC constructs?

(f) A small nit - can we rename the "Auth Key/Checksum" field to a
simple "Authentication Data" field, as the former is not entirely
correct.

Cheers, Manav

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