Application of BFD in Network Device Interconnection Authentication
Internet-Draft draft-hu-bfd-network-device-authentication-00
Ting Hu, Ed.
State Grid Corporation of China
Chengxin Road
Nanjing
China
huting3@sgepri.sgcc.com.cn
Qin Li
State Grid Corporation of China
liqin@sgepri.sgcc.com.cn
Xin. Huang
State Grid Corporation of China
huangxin@sgepri.sgcc.com.cn
Xiaofei. Zhang
State Grid Corporation of China
zhangxiaofei@sgepri.sgcc.com.cn
Xiaoyang. He
State Grid Corporation of China
hexiaoyang2@sgepri.sgcc.com.cn
16 October 2024
General
BFD
Internet-Draft
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.
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.
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.
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.
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.
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.
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.
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.
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.
BFD control packet format

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].
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.
Security Considerations
These extensions to BFD do not add any new security issues to the existing protocol.
Normative References
[RFC5880]

Bidirectional Forwarding Detection (BFD)
D. Katz
D. Ward
June 2010
RFC 5880
DOI 10.17487/RFC5880
[RFC2119]

Key words for use in RFCs to Indicate Requirement Levels
S. Bradner
March 1997
BCP 14
RFC 2119
DOI 10.17487/RFC2119
[RFC8174]

Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words
B. Leiba
May 2017
BCP 14
RFC 8174
DOI 10.17487/RFC8174
[RFC5881]

Bidirectional Forwarding Detection (BFD) for IPv4 and IPv6 (Single Hop)
D. Katz
D. Ward
June 2010
RFC 5881
DOI 10.17487/RFC5881