Optimizing BFD Authentication

Abstract

This document describes an optimization to BFD Authentication as described in Section 6.7 of BFD RFC 5880. This document updates RFC 5880.¶

1. Introduction

Authenticating every BFD [RFC5880] control packet with a Simple Password, or with a MD5 Message-Digest Algorithm [RFC1321] , or Secure Hash Algorithm (SHA-1) algorithms is a computationally intensive process. This makes 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 described in Finding Collisions in the Full SHA-1 [SHA-1-attack1] and New Collision Search for SHA-1 [SHA-1-attack2] raise concerns about their remaining useful lifetime as outlined in Updated Security Considerations for the MD5 Message-Digest and the HMAC-MD5 Algorithm [RFC6151] and Security Considerations for the SHA-0 and SHA-1 Message-Digest Algorithm [RFC6194]. 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 control packets that signal a state change, a demand mode change (to D bit) or a poll sequence change (P or F bit change) in a BFD control packet be categorized as a significant change. This document also proposes that all BFD control packets which signal a significant change MUST be authenticated if the session's bfd.AuthType is non-zero. Other BFD control packets MAY be transmitted and received without the A bit set.¶

Most packets that are transmitted and received have no state change associated with them. Limiting authentication to packets that affect a BFD session state allows more sessions to be supported with this optimized method of authentication. Moreover, most BFD control packets that signal a significant 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 BFD control packet without a significant change be authenticated occasionally. The interval of the BFD control packets without a significant change 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 [RFC5880]. Section 3 goes into the details of the new Authentication Type.¶

2. Authentication Mode

The cryptographic authentication mechanisms specified in BFD [RFC5880] 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 Type 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 packets need to be authenticated, and authenticate only those packets. Rest of the packets can be transmitted and received without authentication. For example, the two ends can be configured such that BFD control packets that indicate a significant change should be authenticated and enable authentication on those packets only. If the two ends have previously been configured as such, but at least one side decides not to authenticate a significant change packet, then the BFD session will fail to come up.¶

This proposal outlines which BFD control packets need to be authenticated (carry the A-bit), and which packets can be transmitted or received without authentication enabled. A BFD control packet that fails authentication is discarded, or a BFD control packet that was supposed to be authenticated, but was not, e.g. a significant change packet, is discarded. However, there is no change to the state machine for BFD, as the decision of a significant change is still decided by how many valid consecutive packets were received, authenticated or otherwise.¶

The following table summarizes when the A bit should be set. The table should be read with the column indicating the BFD state the receiver is currently in, and the row indicating the BFD state the receiver might transition to based on the BFD control packet received. The interesection of the two indicates whether the received BFD control packet should have the A bit set (Auth), no authentication is needed (NULL), most packets are NULL AUTH (Select) or the state transition is not applicable. The BFD state refers to the states in BFD state machine described in Section 6.2 of BFD [RFC5880].¶

       Read   : On state change from <column> to <row>
       Auth   : Authenticate BFD control packet
       NULL   : No Authentication. Use NULL AUTH Type.
       n/a    : Invalid state transition.
       Select : Most packets NULL AUTH. Selective (periodic)
                packets authenticated.
      +--------+--------+--------+--------+
      |        | DOWN   | INIT   | UP     |
      +--------+--------+--------+--------+
      | DOWN   |  NULL  |  Auth  |  Auth  |
      +--------+--------+--------+--------+
      | INIT   |  Auth  |  NULL  |  n/a   |
      +--------+--------+--------+--------+
      | UP     |  Auth  |  Auth  | Select |
      +--------+--------+--------+--------+

If P or F bit changes value, the BFD control packet MUST be authenticated. If the D bit changes value, the BFD control packet MUST be authenticated.¶

All packets already carry the sequence number. The NULL AUTH packets MUST contain the Type specified in Section 3. This enables a monotonically increasing sequence number to be carried in each packet, and prevents man-in-the-middle from capturing and replaying the same packet again. Since all packets still carry a sequence number, the logic for sequence number maintenance remains unchanged from BFD [RFC5880]. If at a later time, a different scheme is adopted for changing sequence number, e.g. Secure BFD Sequence Numbers [I-D.ietf-bfd-secure-sequence-numbers], this method can use the updated scheme without any impact.¶

Most packets transmitted on a BFD session are BFD UP packets. Authenticating a small subset of these packets, for example, a detect multiplier number of packets per configured interval, significantly reduces the computational demand for the system while maintaining security of the session across the configured interval. A minimum of Detect Multiplier packets MUST be transmitted per configured interval. This ensures that the BFD session should see at least one authenticated packet during that interval.¶

3. NULL Auth Type

This section describes a new Authentication Type as:¶

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |   Auth Type   |   Auth Len    |  Auth Key ID  |   Reserved    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                        Sequence Number                        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

where:¶

Auth Type: The Authentication Type, which in this case is TBD (NULL, to be assigned by IANA)¶

Auth Len: The length of the NULL Auth Type, in bytes i.e. 8 bytes¶

Auth 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 (bfd.XmitAuthSeq) as defined in BFD [RFC5880], or secure sequence numbers as defined in Secure BFD Sequence Numbers [I-D.ietf-bfd-secure-sequence-numbers].¶

The NULL Auth Type must be used for all packets that are not authenticated. This protects against replay-attacks by allowing the session to maintain an incrementing sequence number for all packets (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.¶

6. References