Optimizing BFD Authentication
draft-ietf-bfd-optimizing-authentication-13
Network Working Group M. Jethanandani
Internet-Draft Kloud Services
Updates: 5880 (if approved) A. Mishra
Intended status: Standards Track SES Networks
Expires: 2 February 2022 A. Saxena
Ciena Corporation
M. Bhatia
Nokia
1 August 2021
Optimizing BFD Authentication
draft-ietf-bfd-optimizing-authentication-13
Abstract
This document describes an optimization to BFD Authentication as
described in Section 6.7 of BFD RFC 5880. This document updates RFC
5880.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 2 February 2022.
Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the
document authors. All rights reserved.
Jethanandani, et al. Expires 2 February 2022 [Page 1]
Internet-Draft BFD Authentication Optimization August 2021
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components
extracted from this document must include Simplified BSD License text
as described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
2. Authentication Mode . . . . . . . . . . . . . . . . . . . . . 4
3. NULL Auth Type . . . . . . . . . . . . . . . . . . . . . . . 6
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
5. Security Considerations . . . . . . . . . . . . . . . . . . . 7
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
6.1. Normative References . . . . . . . . . . . . . . . . . . 7
6.2. Informative References . . . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8
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.
Jethanandani, et al. Expires 2 February 2022 [Page 2]
Internet-Draft BFD Authentication Optimization August 2021
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.
1.1. Requirements Language
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 [RFC2119]
[RFC8174] when, and only when, they appear in all capitals, as shown
here.
1.2. Terminology
The following terms used in this document have been defined in BFD
[RFC5880].
* Detect Multiplier
* Detection Time
The following terms are introduced in this document.
Jethanandani, et al. Expires 2 February 2022 [Page 3]
Internet-Draft BFD Authentication Optimization August 2021
+====================+==============================================+
| Term | Meaning |
+====================+==============================================+
| significant | State change, a demand model change (to D |
| change | bit) or a poll sequence change (P or F bit). |
+--------------------+----------------------------------------------+
+--------------------+----------------------------------------------+
| configured | Interval at which BFD control packets are |
| interval | authenticated in the UP state. |
+--------------------+----------------------------------------------+
Table 1
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.
Jethanandani, et al. Expires 2 February 2022 [Page 4]
Internet-Draft BFD Authentication Optimization August 2021
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 |
+--------+--------+--------+--------+
Figure 1: Optimized Authentication Map
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
Jethanandani, et al. Expires 2 February 2022 [Page 5]
Internet-Draft BFD Authentication Optimization August 2021
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: NULL Auth Type
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.
Jethanandani, et al. Expires 2 February 2022 [Page 6]
Internet-Draft BFD Authentication Optimization August 2021
4. IANA Considerations
This document requests an update to the registry titled "BFD
Authentication Types". IANA is requested to assign a new BFD Auth
Type for "NULL" (see Section 3).
Note to RFC Editor: this section may be removed on publication as an
RFC.
5. Security Considerations
The approach described in this document enhances the ability to
authenticate a BFD session by taking away the onerous requirement
that every BFD control packet be authenticated. By authenticating
packets that affect the state of the session, the security of the BFD
session is maintained. In this mode, packets that are a significant
change but are not authenticated, are dropped by the system.
Therefore, a malicious user that tries to inject a non-authenticated
packet, e.g. with a Down state to take a session down will fail.
That combined with the proposal of using sequence number defined in
Secure BFD Sequence Numbers [I-D.ietf-bfd-secure-sequence-numbers]
further enhances the security of BFD sessions.
6. References
6.1. Normative References
[I-D.ietf-bfd-secure-sequence-numbers]
Jethanandani, M., Agarwal, S., Mishra, A., Saxena, A., and
A. DeKok, "Secure BFD Sequence Numbers", Work in Progress,
Internet-Draft, draft-ietf-bfd-secure-sequence-numbers-08,
8 March 2021, <https://www.ietf.org/archive/id/draft-ietf-
bfd-secure-sequence-numbers-08.txt>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection
(BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010,
<https://www.rfc-editor.org/info/rfc5880>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
6.2. Informative References
Jethanandani, et al. Expires 2 February 2022 [Page 7]
Internet-Draft BFD Authentication Optimization August 2021
[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
DOI 10.17487/RFC1321, April 1992,
<https://www.rfc-editor.org/info/rfc1321>.
[RFC6151] Turner, S. and L. Chen, "Updated Security Considerations
for the MD5 Message-Digest and the HMAC-MD5 Algorithms",
RFC 6151, DOI 10.17487/RFC6151, March 2011,
<https://www.rfc-editor.org/info/rfc6151>.
[RFC6194] Polk, T., Chen, L., Turner, S., and P. Hoffman, "Security
Considerations for the SHA-0 and SHA-1 Message-Digest
Algorithms", RFC 6194, DOI 10.17487/RFC6194, March 2011,
<https://www.rfc-editor.org/info/rfc6194>.
[SHA-1-attack1]
Wang, X., Yin, Y., and H. Yu, "Finding Collisions in the
Full SHA-1", 2005.
[SHA-1-attack2]
Wang, X., Yao, A., and F. Yao, "New Collision Search for
SHA-1", 2005.
Authors' Addresses
Mahesh Jethanandani
Kloud Services
United States of America
Email: mjethanandani@gmail.com
Ashesh Mishra
SES Networks
Email: mishra.ashesh@gmail.com
Ankur Saxena
Ciena Corporation
3939 N 1st Street
San Jose, CA 95134
United States of America
Email: ankurpsaxena@gmail.com
Jethanandani, et al. Expires 2 February 2022 [Page 8]
Internet-Draft BFD Authentication Optimization August 2021
Manav Bhatia
Nokia
Bangalore
India
Email: manav.bhatia@nokia.com
Jethanandani, et al. Expires 2 February 2022 [Page 9]