| Internet-Draft | Application of BFD in Interconnection Au | October 2024 |
| Hu, et al. | Expires 19 April 2025 | [Page] |
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.¶
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 (c) 2024 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 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.¶
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.¶
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.¶
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.¶
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.¶
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.¶
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.¶
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.¶
## 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.¶
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].¶
[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.¶
These extensions to BFD do not add any new security issues to the existing protocol.¶