--- 1/draft-ietf-bfd-optimizing-authentication-09.txt 2020-07-13 12:14:25.395200707 -0700 +++ 2/draft-ietf-bfd-optimizing-authentication-10.txt 2020-07-13 12:14:25.415201214 -0700 @@ -1,278 +1,323 @@ Network Working Group M. Jethanandani -Internet-Draft VMware -Intended status: Standards Track A. Mishra -Expires: June 11, 2020 SES Networks - A. Saxena +Internet-Draft Kloud Services +Updates: 5880 (if approved) A. Mishra +Intended status: Standards Track SES Networks +Expires: January 14, 2021 A. Saxena Ciena Corporation M. Bhatia Nokia - December 9, 2019 + July 13, 2020 Optimizing BFD Authentication - draft-ietf-bfd-optimizing-authentication-09 + draft-ietf-bfd-optimizing-authentication-10 Abstract This document describes an optimization to BFD Authentication as - described in Section 6.7 of BFD RFC5880. - -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. + 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 June 11, 2020. + This Internet-Draft will expire on January 14, 2021. Copyright Notice - Copyright (c) 2019 IETF Trust and the persons identified as the + Copyright (c) 2020 IETF Trust and the persons identified as the document authors. All rights reserved. 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 . . . . . . . . . . . . . . . . . . . . . 3 - 3. NULL Auth TLV . . . . . . . . . . . . . . . . . . . . . . . . 4 - 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 - 5. Security Considerations . . . . . . . . . . . . . . . . . . . 6 - 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 - 6.1. Normative References . . . . . . . . . . . . . . . . . . 6 - 6.2. Informative References . . . . . . . . . . . . . . . . . 6 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 + 3. NULL Auth Type . . . . . . . . . . . . . . . . . . . . . . . 6 + 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 + 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] packet with a Simple Password, or with a MD5 Message-Digest Algorithm [RFC1321] , 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 [SHA-1-attack1] [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. + 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 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. + This document proposes that only BFD 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 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 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 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 [RFC5880]. Section 3 goes into the details of the new Authentication - TLV. + 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]. + + o Detect Multiplier + + o Detection Time + + +--------------+----------------------------------------------------+ + | Term | Meaning | + +--------------+----------------------------------------------------+ + | significant | State change, a demand model change (to D bit) or | + | change | a poll sequence change (P or F bit). | + | configured | configured authentication periodic interval | + | interval | | + +--------------+----------------------------------------------------+ 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 TLV appended. In addition, it states that + 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 frames need to be authenticated, and - authenticate only those frames. Rest of the frames can be + 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 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. + two ends can be configured such that BFD 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 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 + This proposal outlines which packets need to be authenticated (carry + the A-bit), and which packets 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. + not, e.g. a significant change frame, 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 state changes for which authentication is being suggested - include: + 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 packet received. The + interesection of the two indicates whether the received 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. Read : On state change from to Auth : Authenticate frame - NULL : No Authentication. Use NULL AUTH TLV. + NULL : No Authentication. Use NULL AUTH Type. n/a : Invalid state transition. - Select : Most frames NULL AUTH. Selective (periodic) - frames authenticated. - +--------+--------+--------+--------+--------+--------+ - | | DOWN | INIT | UP | POLL | DEMAND | - +--------+--------+--------+--------+--------+--------+ - | DOWN | NULL | Auth | Auth | Auth | Auth | - +--------+--------+--------+--------+--------+--------+ - | INIT | Auth | NULL | Auth | Auth | Auth | - +--------+--------+--------+--------+--------+--------+ - | UP | Auth | n/a | Select | Auth | Auth | - +--------+--------+--------+--------+--------+--------+ - | POLL | Auth | n/a | Auth | Auth | Auth | - +--------+--------+--------+--------+--------+--------+ - | DEMAND | Auth | Auth | Auth | Auth | Auth | - +--------+--------+--------+--------+--------+--------+ + Select : Most packets NULL AUTH. Selective (periodic) + packets authenticated. + +--------+--------+--------+--------+------------+ + | | DOWN | INIT | UP | ADMIN DOWN | + +--------+--------+--------+--------+------------+ + | DOWN | NULL | Auth | Auth | NULL | + +--------+--------+--------+--------+------------+ + | INIT | Auth | NULL | n/a | n/a | + +--------+--------+--------+--------+------------+ + | UP | Auth | Auth | Select | n/a | + +--------+--------+--------+--------+------------+ + | ADMIN | NULL | Auth | Auth | NULL | + +--------+--------+--------+--------+------------+ Optimized Authentication Map - All frames already carry the sequence number. The NULL AUTH frames - MUST contain the TLV specified in Section 3. This enables a + If P or F bit changes value, the packet MUST be authenticated. If + the D bit changes value, the 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 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 + frame 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, this method can use the updated scheme - without any impact. + 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 frames transmitted on a BFD session are BFD CC UP frames. - Authenticating a small subset of these frames, for example, a detect + 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 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. -3. NULL Auth TLV +3. NULL Auth Type - This section describes a new Authentication TLV as: + 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - NULL Auth TLV + NULL Auth Type where: - Auth Type: The Authentication Type, which in this case is TBD (NULL - Auth TLV, to be assigned by IANA) + 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 TLV, in bytes i.e. 8 bytes + 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 as defined in [RFC5880], or secure sequence - numbers as defined in [I-D.ietf-bfd-secure-sequence-numbers]. + 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 TLV must be used for all frames that are not + 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 frames + 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. 4. IANA Considerations 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). + 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 - 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. + 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", draft-ietf-bfd- - secure-sequence-numbers-04 (work in progress), August - 2019. + secure-sequence-numbers-05 (work in progress), February + 2020. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . + [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection + (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010, + . + [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . 6.2. Informative References [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, DOI 10.17487/RFC1321, April 1992, . - [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection - (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010, - . - [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, . [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, . @@ -280,21 +325,21 @@ 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 - VMware + Kloud Services USA Email: mjethanandani@gmail.com Ashesh Mishra SES Networks Email: mishra.ashesh@gmail.com Ankur Saxena