Optimizing BFD
AuthenticationVMwareUSAmjethanandani@gmail.comSES Networksmishra.ashesh@gmail.comCiena Corporation3939 N 1st StreetSan JoseCA95134USAankurpsaxena@gmail.comNokiaBangaloreIndiamanav.bhatia@nokia.comThis document describes an optimization to BFD Authentication as
described in Section 6.7 of BFD RFC5880.The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in BCP 14 when, and only
when, they appear in all capitals, as shown here.Authenticating every BFD packet with a
Simple Password, or with a MD5 Message-Digest
Algorithm , or Secure Hash Algorithm (SHA-1) algorithms is
computationally intensive process, making it difficult if not impossible
to authenticate every packet - particularly at faster rates. Also, the
recent escalating series of attacks on MD5 and SHA-1 raise concerns
about their remaining useful lifetime as outlined in Updated Security Considerations for the MD5
Message-Digest and the HMAC-MD5 Algorithm and Security Considerations for the SHA-0 and SHA-1
Message-Digest Algorithm . If replaced by stronger algorithms,
the computational overhead, will make the task of authenticating every
packet even more difficult to achieve.This document proposes that only BFD frames that signal a state
change in BFD be authenticated. Rest of the frames can be transmitted
and received without authentication enabled. Most frames that are
transmitted and received have no state change associated with them.
Limiting authentication to frames that affect a BFD session state allows
more sessions to be supported for authentication. Moreover, most BFD
frames that signal a state change are generally transmitted at a slower
interval of 1s leaving enough time to compute the hash. To detect a Man
In the Middle (MITM) attack, it is also proposed that a non-state change
frame be authenticated occasionally. The interval of this non-state
change frame can be configured depending on the detect multiplier and
the capability of the system. As an example, this could be equal to the
detect multiplier number of packets.The rest of the document is structured as follows. Section 2 talks
about the changes to authentication mode as described in BFD. Section 3 goes into the details of the new
Authentication TLV.The cryptographic authentication mechanisms specified in BFD describes enabling and disabling of
authentication as a one time operation. As a security precaution, it
mentions that authentication state be allowed to change at most once.
Once enabled, every packet must have Authentication Bit set and the
associated Authentication TLV appended. In addition, it states that an
implementation SHOULD NOT allow the authentication state to be changed
based on the receipt of a BFD Control packet.This document proposes that the authentication mode be modified to be
enabled on demand. Instead of authenticating every packet, BFD peers are
configured for which frames need to be authenticated, and authenticate
only those frames. Rest of the frames can be transmitted and received
without authentication. For example, the two ends can be configured such
that BFD frames that indicate a state change should be authenticated and
enable authentication on those frames only. If the two ends have
previously been configured as such, but at least one side decides not to
authenticate a state change frame, then the BFD session will fail to
come up.This proposal outlines which frames need to be authenticated (carry
the A-bit), and which frames can be transmitted or received without
authentication enabled. A frame that fails authentication is discarded,
or a frame that was supposed to be authenticated, but was not, e.g. a
state-change frame, is discarded. However, there is no change to the
state machine for BFD, as the decision of a state change is still
decided by how many valid consecutive frames were received,
authenticated or otherwise.The state changes for which authentication is being suggested
include:All frames already carry the sequence number. The NULL AUTH frames
MUST contain the TLV specified in Section 3. This enables a
monotonically increasing sequence number to be carried in each frame,
and prevents man-in-the-middle from capturing and replaying the same
frame again. Since all frames still carry a sequence number, the logic
for sequence number maintenance remains unchanged from . If at a later time, a different scheme is adopted
for changing sequence number, this method can use the updated scheme
without any impact.Most frames transmitted on a BFD session are BFD CC UP frames.
Authenticating a small subset of these frames, for example, a detect
multiplier number of packets per configured period, significantly
reduces the computational demand for the system while maintaining
security of the session across the configured authentication periods. A
minimum of Detect Multiplier packets MUST be transmitted per configured
periodic authentication interval. This ensures that the BFD session
should see at least one authenticated packet during that interval.This section describes a new Authentication TLV as: where:Auth Type: The Authentication Type, which in this case is TBD (NULL
Auth TLV, to be assigned by IANA)Auth Len: The length of the NULL Auth TLV, in bytes i.e. 8 bytesAuth Key ID: The authentication key ID in use for this packet. Must
be set to zero.Reserved: This byte MUST be set to zero on transmit and ignored on
receive.Sequence Number: The sequence number for this packet. Implementation
may use sequence numbers as defined in , or
secure sequence numbers as defined in .The NULL Auth TLV must be used for all frames that are not
authenticated. This protects against replay-attacks by allowing the
session to maintain an incrementing sequence number for all frames
(authenticated and un-authenticated).In the future, if a new scheme is adopted for changing the sequence
number, this method can adopt the new scheme without any impact.This document requests an update to the registry titled "BFD
Authentication Types". IANA is requested to to assign a new BFD Auth
Type for "NULL Auth TLV" (see Section 3).Note to RFC Editor: this section may be removed on publication as an
RFC.The approach described in this document enhances the ability to
authentication a BFD session by taking away the onerous requirement that
every frame be authenticated. By authenticating frames that affect the
state of the session, the security of the BFD session is maintained. As
such this document does not change the security considerations for
BFD.Finding Collisions in the Full SHA-1New Collision Search for SHA-1