Application of BFD in Network Device Interconnection Authentication
draft-hu-bfd-network-device-authentication-00

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,
              <https://www.rfc-editor.org/info/rfc5880>.

   [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>.

   [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>.

   [RFC5881]  Katz, D. and D. Ward, "Bidirectional Forwarding Detection
              (BFD) for IPv4 and IPv6 (Single Hop)", RFC 5881,
              DOI 10.17487/RFC5881, June 2010,
              <https://www.rfc-editor.org/info/rfc5881>.

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]