BFD T. Hu, Ed. Internet-Draft Q. Li Intended status: Standards Track X. Huang Expires: 19 April 2025 X. Zhang X. He State Grid Corporation of China 16 October 2024 Application of BFD in Network Device Interconnection Authentication draft-hu-bfd-network-device-authentication-00 Abstract This document extends an interface association mechanism based on BFD, which forms a network device interconnection authentication scheme. It triggers the interface down when the authentication fails, ensuring the security of the connected devices. 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 19 April 2025. Copyright Notice Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. Hu, et al. Expires 19 April 2025 [Page 1] Internet-Draft Application of BFD in Interconnection Au October 2024 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 Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. BFD For Network Devices Interconnection Authentication . . . 4 4. Interface Link Control Association . . . . . . . . . . . . . 4 5. Packet Formats . . . . . . . . . . . . . . . . . . . . . . . 5 5.1. Authentication Section Format . . . . . . . . . . . . . . 6 6. Security Considerations . . . . . . . . . . . . . . . . . . . 6 7. Normative References . . . . . . . . . . . . . . . . . . . . 6 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 1. Introduction During network O&M, network accessed of unauthenticated network devices may happen with the situations such as improperly operating, device upgrade or replacement. Such unauthenticated device access could pose risks to the network. To avoid such risks, a technology is required to check and verify the connected network devices to ensure a secure access behavior. Bidirectional Forwarding Detection (BFD)[RFC5880] provides low- overhead, short-duration detection of failures in the path between adjacent forwarding engines. [RFC5880] defines that the BFD Control packet may include an optional Authentication Section, and this part can be used to carry all necessary information to allow the receiving system determines the validity of its received packets, based on the authentication type in use. This document extends an BFD authentication based associated behavior mechanism on interfaces of a network device. In this way, network devices interconnection authentication scheme is achieved. It triggers the interface down when the authentication fails to isolate risky access, ensuring the security of the network. Hu, et al. Expires 19 April 2025 [Page 2] Internet-Draft Application of BFD in Interconnection Au October 2024 1.1. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "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. 2. Motivation When an unauthenticated device was wrongly accessed to the network by accidental, the running network may face risks such as data leakage, link interruption, or even network breakdown, this risks are unbearable to those significant networks which carrying real-time services of production and control, marketing or trading. To avoid such risks, a check and verification mechanism is required to ensure the access security of network devices. If accession of a network device is authenticated by the object point, and only after the authentication has been confirmed that the business communication between the two ends is allowed, otherwise, no traffic can be delivered to the target device, then a secured authentication interconnection is qualified. This kind of authentication for network devices requires a technology with the following capability: 1.It supports secure network connectivity detection capability, and it is applicable to network interconnection protection in both LAN and WAN scenarios. 2.It supports the capability of associating behaviors between connectivity detection and interfaces link state decision, to control whether traffic on the specific interfaces can be accessed or not. 3.It supports fast state recovery capability. Once authentication of a attempting device is succussed, the associated interface can be recovered to normal work automatically. 4.It supports higher frequency detection capability. The detection period is recommended to be millisecond-level, which can depress the impact of network attacks minimally, for example, isolating virus spreading in milliseconds. 5.It should be well adapted with existing packet-based network (including LSWs, routers, and WLAN APs), which can be achieved by extending or upgrading of current systems software so as to avoid extra hardware investment. Hu, et al. Expires 19 April 2025 [Page 3] Internet-Draft Application of BFD in Interconnection Au October 2024 To sum up, the BFD can meet all these capability and requirements. The access control of network devices can be achieved by using the authenticated detection supported by BFD with its association to the interfaces link control mechanism. 3. BFD For Network Devices Interconnection Authentication The network device interconnection authentication case only considers the single-hop scenario. Therefore, all BFD Control packets for the session MUST be sent with a Time to Live (TTL) or Hop Limit value of 255. All received BFD Control packets that are demultiplexed to the session MUST be discarded if the received TTL or Hop Limit is not equal to 255[RFC5881]. BFD supports two working modes: echo packet mode and control packet mode. In the network device interconnection authentication case, the two network devices need to authenticate each other, which can not be achieved by echo packet mode. Therefore, the control packet should be used for bidirectional authentication. [RFC5880] defines that the system may take either an Active role or a Passive role in session initialization. In the network device interconnection authentication case, both the two network devices of a BFD session should take the active role at the same time, and initiate the authentication from each side. BFD has two operating modes that may be selected, Asynchronous mode and Demand mode. In the network device interconnection authentication case, BFD should operates in asynchronous mode. After a BFD session is established, periodic packet detection must be enabled on both sides to prevent the connection from being replaced by unauthenticated devices. 4. Interface Link Control Association This section defines the interface link control association for BFD to ensure a secure access behavior.The procedure is as follows: If BFD with authentication is configured on both sides of the interconnected network device interfaces and the authentication succeeds, the BFD session status changes from Down to Up, and the protocol status of the interface remains Up. If a device detects that the BFD keepalive timer expires or the BFD configuration on the peer is modified, the associated interface protocol status on the device should be Down immediately. Hu, et al. Expires 19 April 2025 [Page 4] Internet-Draft Application of BFD in Interconnection Au October 2024 If BFD with authentication is configured on both sides of the interconnected network device interfaces and the authentication fails, or if the BFD with authentication is configured on only one side of the interconnected device interfaces, the BFD session initiation fails. The network device with authenticated BFD configured should wait N (N equal to 1-300) seconds and then the associated interface protocol status on the network device should be Down. If the configuration on the peer is modified, and the BFD session can be re-initiated. After the authentication succeeds, the BFD session status changes from DOWN to UP, and the associated interface protocol status also should be changed from DOWN to UP. 5. Packet Formats ## BFD control packet format This section describes the recommended values of BFD control packet fields in the network device interconnection authentication case. [RFC5880] defines BFD control packet format which is shown in figure1. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Vers | Diag |Sta|P|F|C|A|D|M| Detect Mult | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | My Discriminator | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Your Discriminator | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Desired Min TX Interval | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Required Min RX Interval | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Required Min Echo RX Interval | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1: BFD control packet format A(Authentication Present): In this document, the value should be set to 1 in the initialization phase. In the keepalive phase, the value of this field on the peer end is not checked. D(Demand): In this document, it should be set to 0, indicating the asynchronous mode. Hu, et al. Expires 19 April 2025 [Page 5] Internet-Draft Application of BFD in Interconnection Au October 2024 M(Multipoint): In this document, it should be set to 0. Point-to- multipoint scenario is not considered. Required Min Echo RX Interval: This document does not involve the echo packet mode. this field should set to 0. The other fields of BFD control packet comply with [RFC5880]. 5.1. Authentication Section Format [RFC5880] defines 5 types of Authentication section, the detail can be seen in clause 4.4 of [RFC5880] . This document recommends Meticulous Keyed SHA1 Authentication section as it has the highest security. 6. Security Considerations These extensions to BFD do not add any new security issues to the existing protocol. 7. Normative References [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC5881] Katz, D. and D. Ward, "Bidirectional Forwarding Detection (BFD) for IPv4 and IPv6 (Single Hop)", RFC 5881, DOI 10.17487/RFC5881, June 2010, . Authors' Addresses Ting Hu (editor) State Grid Corporation of China Chengxin Road Nanjing China Email: huting3@sgepri.sgcc.com.cn Hu, et al. Expires 19 April 2025 [Page 6] Internet-Draft Application of BFD in Interconnection Au October 2024 Qin Li State Grid Corporation of China Email: liqin@sgepri.sgcc.com.cn Xin. Huang State Grid Corporation of China Email: huangxin@sgepri.sgcc.com.cn Xiaofei. Zhang State Grid Corporation of China Email: zhangxiaofei@sgepri.sgcc.com.cn Xiaoyang. He State Grid Corporation of China Email: hexiaoyang2@sgepri.sgcc.com.cn Hu, et al. Expires 19 April 2025 [Page 7]