Subject: Comments on BFD base spec

From: "Vishwas Manral" <[email-masked]>
Date: Thu, 4 Sep 2008 19:03:46 +0530

Hi,

I just looked at the BFD base spec and had some security related
comments based on the work we have done in IPsec and IGP's.

1. I would prefer the term MD5 hash instead of MD5 checksum.
2. In my view the document should not talk about all the cryptographic
modes. As you may have noticed we have been trying to remove the
cryptographic algorithms to use by a protocol out of the base spec. As
time progresses and with more CPU and research more vulnerabilities
are found, the algorithms can the be continuously be changed without
affecting the base spec. We did this in IPsec and the RFC4835 for the
same is present.
3. "   It may be desirable to enable or disable authentication on a session
   without disturbing the session state.

   One possible approach is to build an implementation such that
   authentication is configured, but not considered "in use" until the
   first packet containing a matching authentication section is received
   (providing the necessary synchronization.)   "

This is a serious security threat in my view. If we allow a session to
come up without the authentication even when authentication is
enabled. This beats the very purpose of authentication.

4. "   In order to avoid security risks, implementations using this method
   should only allow the authentication state to be changed once without
   some form of intervention (so that authentication cannot be turned on
   and off repeatedly simply based on the receipt of BFD Control packets
   from remote systems.)"

This is a serious DoS risk. A malicious guy could send packets with
different authentication methods and after that a valid guy may not be
able to enable authentication, thus prohibiting an adjacency to come
up.

5. I guess we should specify the difference in security got because of
the Meticulous MD5 and Keyed MD5, now that we have 2 modes. The
difference is that a Replay attack is possible till the next sequence
number packet is got in the Keyed MD5 mode.

6. When we state "      For Keyed MD5, bfd.XmitAuthSeq MAY be
incremented in a circular
      fashion (when treated as an unsigned 32 bit value.)" it is a problem.

 How do we know sequence number y < x is actually circular or not. I
guess we need to allow it in the range only from say 0xFFFFFFFF -
0xFFFF to 0xFFFF range and not otherwise.

7. Key Id field is also helpful for KeyRollover also prevents DoS
attacks. By having a Key Id, we can first allow the reception of the
new Key Id as well as old and then send new Key Id one at a time. If
we do not have this, the receiver will have to check against all valid
Keys for the MD5 hash.

8. Being a new protocol, I would have prefered we used HMAC-SHA1 as
the protocol, or even HMAC-MD5 rather than MD5 or SHA-1. MD5
especially is not recommended to be used at all any more by the IETF
itself.

9. I also had a doubts about how to distinguish multiple sessions
between the same peers. I know it is called application dependent, but
we do not have an application opaque dependent field to convey the
same in the packet.

10. I guess one other advantage of simple password is to check against
misconfiguration. It is another level of checking, though like its
mentioned there is no security aspect to it.

11. Also for minimum interoperability, at least one authetication
mechanism should be made a SHOULD. Otherwise for an implementer all
the modes need to be supported.

12. An issue we need to consider when having short hellos is the
frequency of hellos we get and the time criticality of the same. A
simple DoS attack can be to send random packets saying that there is
authentication and processing the packet may require a lot of CPU
effort. This can also bring all the sessions down (if valid packets
are not able to be processed).

This issue is more critical in BFD than any other protocol owing to
the short durations and faster detection times expected of it. This
needs to be taken care of.

Thanks,
Vishwas