RTGWG Working Group G. Mirsky Internet-Draft Ericsson Intended status: Standards Track X. Min Expires: 14 May 2023 ZTE Corp. G. Mishra Verizon Inc. 10 November 2022 Integrated Operation, Administration, and Maintenance draft-mmm-rtgwg-integrated-oam-02 Abstract This document describes the Integrated Operation, Administration, and Maintenance (IntOAM) protocol. IntOAM is based on the lightweight capabilities of Bidirectional Forwarding Detection defined in RFC 5880 Bidirectional Forwarding Detection, and the RFC 6374 Packet Loss and Delay Measurement for MPLS Networks to measure performance metrics like packet loss and packet delay. Also, a method to perform lightweight on-demand authentication is defined in this specification. 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 14 May 2023. Copyright Notice Copyright (c) 2022 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. Mirsky, et al. Expires 14 May 2023 [Page 1] Internet-Draft Integrated OAM November 2022 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 2. Conventions used in this document . . . . . . . . . . . . . . 3 2.1. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . 3 2.2. Requirements Language . . . . . . . . . . . . . . . . . . 3 3. Integrated OAM Control Message . . . . . . . . . . . . . . . 4 4. Theory of Operation . . . . . . . . . . . . . . . . . . . . . 7 4.1. Use of Discriminators . . . . . . . . . . . . . . . . . . 7 4.2. Modes of IntOAM . . . . . . . . . . . . . . . . . . . . . 7 4.3. Echo Function . . . . . . . . . . . . . . . . . . . . . . 7 5. Using TLVs in the IntOAM . . . . . . . . . . . . . . . . . . 8 5.1. Integrated OAM Capability Negotiation . . . . . . . . . . 8 5.1.1. Timer Negotiation for Performance Monitoring . . . . 9 5.2. Padding TLV . . . . . . . . . . . . . . . . . . . . . . . 10 5.3. Diagnostic TLV . . . . . . . . . . . . . . . . . . . . . 11 5.4. Performance Measurement with IntOAM Control Message . . . 12 5.5. Lightweight Authentication . . . . . . . . . . . . . . . 13 5.5.1. Lightweight Authentication Mode Negotiation . . . . . 14 5.5.2. Using Lightweight Authentication . . . . . . . . . . 15 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 6.1. IntOAM Message Types . . . . . . . . . . . . . . . . . . 16 6.2. Lightweight Authentication Modes . . . . . . . . . . . . 17 6.3. Return Codes . . . . . . . . . . . . . . . . . . . . . . 18 7. Security Considerations . . . . . . . . . . . . . . . . . . . 19 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 9.1. Normative References . . . . . . . . . . . . . . . . . . 19 9.2. Informative References . . . . . . . . . . . . . . . . . 20 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 1. Introduction [RFC5880] has provided the base specification of a lightweight mechanism, Bidirectional Forwarding Detection (BFD) to monitor a path continuity between two systems and detect a failure in the data plane. Since its introduction, BFD has been broadly deployed. There were several attempts to introduce new capabilities in the protocol, some more successful than others. One of the obstacles to extending BFD capabilities may be seen in the compact format of the BFD control message. This document introduces the Integrated Operation, Administration, and Maintenance (IntOAM) protocol based on BFD's Mirsky, et al. Expires 14 May 2023 [Page 2] Internet-Draft Integrated OAM November 2022 lightweight capabilities. It uses informational elements defined in [RFC6374] to measure various performance metrics, e.g., synthetic packet loss or packet delay. Combination of both Fault Management (FM) Performance Monitoring (PM) OAM functions in the IntOAM protocol is beneficial in some networks. For example, in a Deterministic Networking (DetNet) domain [RFC8655], it is easier to ensure that an IntOAM's test packet is fate-sharing with data packets rather than mapping several FM and PM OAM protocols to that DetNet data flow. 2. Conventions used in this document 2.1. Acronyms BFD: Bidirectional Forwarding Detection G-ACh Generic Associated Channel IntOAM Integrated OAM HMAC Hashed Message Authentication Code MTU Maximum Transmission Unit PMTUD Path MTU Discovery PMTUM Path MTU Monitoring p2p: Point-to-Point TLV Type, Length, Value OAM Operations, Administration, and Maintenance FM Fault Management PM Performance Monitoring DetNet Deterministic Networking 2.2. 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. Mirsky, et al. Expires 14 May 2023 [Page 3] Internet-Draft Integrated OAM November 2022 3. Integrated OAM Control Message Figure 1 displays the format of an Integrated OAM Control message. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | V | Diag |Sta|P|F|D|M| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Detect Mult | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | My Discriminator | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Your Discriminator | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Desired Min TX Interval | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Required Min RX Interval | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Required Min Echo RX Interval | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ TLVs (variable) ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1: Integrated OAM Control Message Format Where fields are defined as the following: * Version (V) - two-bit field. The definition of the field, interpretation, use in the protocol operation, and assigned values are defined in [RFC5880] for the Version field. * Diagnostic (Diag) - five-bit field. The definition of the field, interpretation, use in the protocol operation, and assigned values are defined in [RFC5880] for the Diagnostic field. * Status (Sta) - two-bit field. The definition of the field, interpretation, use in the protocol operation, and assigned values are defined in [RFC5880] for the Status field. * Poll (P) - one-bit field The definition of the field, its interpretation, use in the protocol operation, and assigned values are defined in [RFC5880] for the Poll field. Mirsky, et al. Expires 14 May 2023 [Page 4] Internet-Draft Integrated OAM November 2022 * Final (F) - one-bit field. The definition of the field, interpretation, use in the protocol operation, and assigned values are defined in [RFC5880] for the Final field. * Demand (D) - one-bit field. The definition of the field, interpretation, use in the protocol operation, and assigned values are defined in [RFC5880] for the Demand field. * Multipoint (M) - one-bit field. The definition of the field, interpretation, and use in the protocol operation are defined in [RFC5880] for the Multipoint field. * Reserved - is a seventeen-bit field that can be defined in the future. It MUST be zeroed on transmission and ignored on receipt. * Detect Mult - two-octet field. The definition of the field, interpretation, and use in the protocol operation are defined in [RFC5880] for the Detect Mult field. * Length - two-octet field equal to the length of the IntOAM Control message in octets. * My Discriminator - four-octet field. The definition of the field, interpretation, use in the protocol operation, and assigned values are defined in [RFC5880] for the My Discriminator field. * Your Discriminator - four-octet field. The definition of the field, interpretation, and use in the protocol operation are as defined in [RFC5880] for the Your Discriminator field. * Desired Min TX Interval - four-octet field. The definition of the field, interpretation, and use in the protocol operation are as defined in [RFC5880] for the Desired Min TX Interval field. Additional use cases for the Desired Min TX Interval field described in Section 5.1.1. * Required Min RX Interval - four-octet field. The field, interpretation, and use of the protocol operation are defined in [RFC5880] for the Required Min RX Interval field. Additional use cases for the Required Min RX Interval field described in Section 5.1.1. Mirsky, et al. Expires 14 May 2023 [Page 5] Internet-Draft Integrated OAM November 2022 * Required Min Echo RX Interval - four-octet field. [Ed.note: In BFD, as I understand, it serves several purposes - indicate support of Echo (zero value - non-support) and throttle rate the remote will send its Echo. But that only works if the Echo can be sent when the session is Up. There's now a proposal to send Echo regardless of the session's state. Hence, is it still a good use of four bytes?] * TLVs - is a variable-length field that contains commands and/or data encoded as type-length-value (TLV) shown in Figure 2. TLV is a variable-length field. Multiple TLVs MAY be placed in an IntOAM Control message. Additional TLVs may be enclosed within a given TLV, subject to the outer TLV's semantics. If more than one TLV is to be included, the value of the Type field of the outmost outer TLV MUST be set to Multiple TLVs Used (TBA0), as assigned by IANA according to Section 6.1. Figure 2 displays the TLV format in an IntOAM protocol. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Reserved | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Value ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2: General Type-Length-Value Encoding Where fields are defined as the following: * Type - one-octet field that characterizes the interpretation of the Value field. Type values are allocated according to Section 6.1. * Reserved - one-octet field. The value of the Type field determines its interpretation and encoding. * Length - two-octet field equal to the length of the Value field in octets. * Value - a variable-length field. The value of the Type field determines its interpretation and encoding. Mirsky, et al. Expires 14 May 2023 [Page 6] Internet-Draft Integrated OAM November 2022 4. Theory of Operation [Ed.note: Should the document reference Asynchronous and Demand modes in RFC 5880?] 4.1. Use of Discriminators A discriminator is defined in the IntOAM as an unsigned 32-bit long integer that identifies a particular IntOAM session. An IntOAM system MAY locally assign a discriminator for the given IntOAM session. Also, a discriminator MAY be distributed by the control plane or management plane. In a point-to-point (p2p) IntOAM session, the value of the Your Discriminator field is used to demultiplex IntOAM sessions. An IntOAM system has to learn the value of discriminator that the remote IntOAM system associates with the IntOAM session between these two systems. The IntOAM system MAY use a three-way handshake mechanism to learn the value of the discriminator of the remote system. Besides, the control or management plane MAY be used to associate discriminator values with the specific IntOAM session. In other scenarios, e.g., point-to-multipoint (p2mp) IntOAM session, the Your Discriminator's value could be left undefined for some nodes. In that case, such a node uses the My Discriminator field's value in combination with information that identifies the sender of the IntOAM Control message and the path identifier. 4.2. Modes of IntOAM IntOAM has two operational modes providing for proactive defect detection in a network- Asynchronous and Demand. An IntOAM implementation MUST be capable of operating in either of them. In the Asynchronous mode, an IntOAM system periodically transmits IntOAM Control messages. When an IntOAM system is in Demand mode, it does not periodically transmit IntOAM Control messages. An IntOAM system in the Demand mode MAY transmit a Control message as a part of the Poll sequence. A system MAY be set into the Demand mode at any time during the IntOAM session. 4.3. Echo Function The Echo function in IntOAM can be used in networks when an operator has ensured that the sender's test packet will reach the intended target before being returned to the sender. The target node is not required to support IntOAM as the IntOAM packet is expected to be looped back by the data plane without inspecting the test packet itself. The IntOAM Control message and IntOAM TLVs MAY be used as the test packet by the IntOAM Echo function. Mirsky, et al. Expires 14 May 2023 [Page 7] Internet-Draft Integrated OAM November 2022 5. Using TLVs in the IntOAM 5.1. Integrated OAM Capability Negotiation An IntOAM system, also referred to as a node in this document, that supports IntOAM first MUST discover the extent to which other nodes in the given session support the Integrated OAM. The node MUST send an IntOAM Control message initiating the Poll Sequence as defined in [RFC5880]. If the remote system fails to respond with the IntOAM Control message and the Final flag set, then the initiator node MUST conclude that the peer does not support using the IntOAM Control messages. The first IntOAM Control message initiating the Poll Sequence SHOULD include the Capability TLV that lists capabilities that may be used at some time during the lifetime of the IntOAM session. A node MAY include TLVs in the IntOAM Control message other than the Capability TLV once it negotiates the use of PM capabilities of the IntOAM. The format of the Capability TLV is presented in Figure 3. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Capability | Reserved | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | L | D | M | Unassigned | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Authentication ... | Padding ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3: Format of the Capability TLV Where fields are defined as the following: * Capability - one-octet field. Its value (TBA2) allocated by IANA in Section 6 * Reserved - one-octet field. It MUST be zeroed on the transmit and ignored on the receipt. * Length - two-octet field. The value equals length on the Capability TLV in octets. The value of the Length field MUST be a multiple of 4. * Loss - two-bit field. If the node can measure packet loss using a periodically transmitted IntOAM control message, then the least significant of the two bits MUST be set to 1. If the node can Mirsky, et al. Expires 14 May 2023 [Page 8] Internet-Draft Integrated OAM November 2022 measure packet loss using the Poll Sequence with IntOAM Control message, then the most significant of the two bits MUST be set to 1. * Delay - two-bit field. If the node can measure packet delay using a periodically transmitted IntOAM control message, then the least significant of the two bits MUST be set to 1. If the node can measure packet delay using the Poll Sequence with IntOAM Control message, then the most significant of the two bits MUST be set to 1. * MTU - two-bit field. Set if the node is capable of using the IntOAM Control message in Path MTU Discovery (PMTUD). or PMTU Monitoring (PMTUM). If the node can perform PMTUD/PMTUM using periodically transmitted IntOAM control messages, then the least significant of the two bits MUST be set to 1. The most significant of the two bits is set if the node is capable of PMTUD/PMTUM using the Poll Sequence with IntOAM Control message. * Unassigned - 26-bit field. It MUST be zeroed on transmission and ignored on receipt * (Lightweight) Authentication - variable-length field. An IntOAM system uses the Authentication field for advertising its lightweight authentication capabilities. The format and the use of the Authentication field are defined in Section 5.5.1. * Padding - variable-length field. The Padding field aligns the length of the Capability TLV to a four-octet boundary. It MUST be zeroed on transmission and ignored on receipt. The remote IntOAM node that supports this specification MUST respond to the Capability TLV with the IntOAM Control message, including the Capability TLV listing capabilities the responder supports. The responder MUST set the Final flag in the IntOAM Control message. 5.1.1. Timer Negotiation for Performance Monitoring IntOAM allows for the negotiation of time intervals at which an IntOAM system transmits and receives IntOAM Control packets. That equally applies to packets used for performance monitoring, whether it measures packet delay or packet loss, using TLVs defined in Section 5.4. An IntOAM system sets its timer values in an IntOAM Control packet that includes the Capabilities TLV. The negotiation process is similar to the one described in [RFC5880]. A local IntOAM system advertises its shortest interval for transmitting IntOAM packets to measure the indicated metrics and the shortest interval capable of receiving PM IntOAM packets. Suppose a system does not Mirsky, et al. Expires 14 May 2023 [Page 9] Internet-Draft Integrated OAM November 2022 support the given metric measurement, i.e., packet loss or packet delay. In that case, it MUST set the value of the Required Min RX Interval to zero when transmitting the IntOAM Control message with the Capability TLV. If an IntOAM system does not support one of the modes, periodic or on-demand, for the given performance metric, it MUST zero the appropriate bit in the field that describes the metric. The timer values apply to all PM modes with their respective bits set in the Capacity TLV. If an operator wants to use different time intervals for different performance metrics measurements, then separate Poll sequences with the Capabilities TLV included MAY be used. Thus IntOAM allows negotiating different time intervals for packet loss and packet delay measurements. 5.2. Padding TLV Padding TLV MAY be used to generate IntOAM Control messages of the desired length. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Padding | Reserved | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Padding ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 4: Padding TLV Format Figure 4 displays the Padding TLV format where fields are defined as the following: * Padding - one-octet field. Its value (TBA1) allocated by IANA in Section 6 * Reserved - one-octet field. MUST be zeroed on the transmit and ignored on the receipt. * Length - two-octet field equals length on the Padding TLV in octets. The value of the Length field MUST be a multiple of 4. * Padding - variable-length field. It MUST be zeroed on transmit and ignored on receipt. Mirsky, et al. Expires 14 May 2023 [Page 10] Internet-Draft Integrated OAM November 2022 Padding TLV MAY be used to generate IntOAM Control messages of different lengths. That capability is necessary to perform PMTUD, PMTUM, and measure synthetic packet loss and/or packet delay. When Padding TLV is used in combination with one of the performance measurement messages carried in Performance Metric TLVs as defined in Section 5.4, Padding TLV MUST follow the Performance Metric TLV. Padding TLV MAY be used in PMTUM as part of periodically sent IntOAM Control messages. In this case, the number of consecutive messages that include Padding TLV MUST be not lesser than Detect Multiplier to ensure that the remote IntOAM peer will detect the loss of messages with the Padding TLV. Also, Padding TLV MAY be present in an IntOAM Control message with the Poll flag set. If the remote IntOAM peer that supports this specification receives an IntOAM Control message with Padding TLV, it MUST include the Padding TLV with the Padding field of the same length as in the received packet and set the Final flag. 5.3. Diagnostic TLV Diagnostic TLV MAY be used to characterize the result of the last requested operation. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Diagnostic | Reserved | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Return Code | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 5: Diagnostic TLV Format Figure 5 displays the Diagnostic TLV format where fields are defined as the following: * Diagnostic - one-octet field.Its value (TBA6) allocated by IANA in Section 6. * Reserved - one-octet field. MUST be zeroed on the transmit and ignored on the receipt. * Length - two-octet field. Its value MUST be set to eight. * Return Code - eight-bit field. The responding IntOAM system MUST set it to one of the values defined in Section 6.3. Mirsky, et al. Expires 14 May 2023 [Page 11] Internet-Draft Integrated OAM November 2022 * Reserved - 24 bits-long field. MUST be zeroed on transmit and ignored on receipt. 5.4. Performance Measurement with IntOAM Control Message Loss measurement, delay measurement, and loss/delay measurement messages can be used in the IntOAM Control message to obtain respective one-way and round-trip metrics. All the messages are encapsulated as TLVs with Type values allocated by IANA, Section 6. The sender MAY use the Performance Metric TLV (presented in Figure 6) to measure performance metrics and obtain the measurement report from the receiver. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Perf. Metric | Reserved | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Loss Measurement Message, | ~ Delay Measurement Message, or ~ | Combined Loss/Delay Measurement Message | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 6: Performance Metric TLV Format Fields in the Performance Metric TLV are defined as the following: * Performance Metric - one-octet field. Valid values are TBA3 through TBA5 allocated by IANA in Section 6 as follows: - TBA3 - Loss Measurement Type; - TBA4 - Delay Measurement Type; - TBA5 - Combined Loss/Delay Measurement Type * Reserved - one-octet field. MUST be zeroed on the transmit and ignored on the receipt. * Length - two-octet field equals length on the Performance Metric TLV in octets. The value of the Length field MUST be a multiple of 4. * Value - various performance metrics measured either directly or using synthetic methods accordingly using the messages defined in Sections 3.1 through 3.3 [RFC6374]. Mirsky, et al. Expires 14 May 2023 [Page 12] Internet-Draft Integrated OAM November 2022 An IntOAM node MAY periodically transmit the IntOAM message with one of the TLVs listed above in Asynchronous mode to perform one-way loss and/or delay measurement. To perform synthetic loss measurement, the sender MUST monotonically increment the counter of transmitted test packets. When using Performance Metric TLV for synthetic measurement, an IntOAM Control message MAY include Padding TLV. In that case, the Padding TLV MUST immediately follow Performance Metric TLV. Also, direct-mode loss measurement is supported, as described in [RFC6374], Procedures to negotiate and manipulate transmission intervals defined in Sections 6.8.2 and 6.8.3 in [RFC5880] SHOULD be used to control the performance impact of using the IntOAM for performance measurement in the particular IntOAM session. An IntOAM node transmits the IntOAM Control message with the Performance Metric TLV with the Poll flag set to measure the round- trip loss and/or delay metrics, Before transmitting the IntOAM Control message with the Performance Metric TLV, the receiver MUST clear the Poll flag and set the Final flag. 5.5. Lightweight Authentication Using IntOAM without security measures, such as exchanging IntOAM Control messages without authentication, increases the risk of an attack, especially over multiple nodes. Thus, using IntOAM without security measures may cause false positive or false negative defect detection situations. In the former, an attacker may spoof IntOAM Control messages pretending to be a remote peer and can thus view the IntOAM session operation even though the real path had failed. In the latter, the attacker may spoof an altered IntOAM control message indicating that the IntOAM session is un-operational even though the path and the remote IntOAM peer operate normally. BFD [RFC5880] allows for optional authentication protection of BFD Control messages to minimize the chances of attacks in a networking system. However, some supported authentication protocols do not provide sufficient protection in modern networks. Also, the current BFD technology requires authentication of each BFD Control message. Such an authentication requirement can put a computational burden on networking devices, especially in the Asynchronous mode, at least because authenticating each BFD Control message can require substantial computing resources to support packet exchange at high rates. This specification defines a lightweight on-demand authentication mode for an IntOAM session. The lightweight authentication is an optional mode. The mechanism includes negotiation (Section 5.5.1) and on-demand authentication (Section 5.5.2) phases. During the former, IntOAM peers advertise supported authentication capabilities Mirsky, et al. Expires 14 May 2023 [Page 13] Internet-Draft Integrated OAM November 2022 and independently select the commonly supported mode of the authentication. In the authentication phase, each IntOAM system transmits, at certain events or periodically, authenticated IntOAM Control messages in Poll Sequence. 5.5.1. Lightweight Authentication Mode Negotiation 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Len | AuthL | Authentication Mode ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 7: Lightweight Authentication Capability Field Format Figure 7 displays the format of the Authentication field that is part of the Capability Encoding, where fields are defined as the following: * Len (Length) - four-bit field. The value of the Length field is equal to the length of the Authentication field, including the Length, in octets. * AuthL (Authentication Length) - four-bit field. The field's value is, in four octets long words, the longest authentication signature the IntOAM system can support for any of the methods advertised in the AuthMode field. * Authentication Mode - variable-length field. It is a bit-coded field that an IntOAM system uses to list modes of lightweight authentication it supports. Mirsky, et al. Expires 14 May 2023 [Page 14] Internet-Draft Integrated OAM November 2022 An IntOAM system uses Capability TLV, defined in Section 5.1, to discover the commonly supported mode of Lightweight Authentication. The system prpoperly sets the authentication field's values to reflect its authentication capabilities. The IntOAM system transmits the IntOAM Control message with Capability TLV as the first in a Poll Sequence. The remote IntOAM system that supports this specification receives the IntOAM Control message with the advertised Lightweight Authentication modes and stores information locally. The system responds with the advertisement of its Lightweight Authentication capabilities in the IntOAM Control message with the Final flag set. Each IntOAM system uses local and received information about Lightweight Authentication capabilities to deduce the commonly supported modes and selects from that set to use the strongest authentication with the longest signature. If the common set is empty, i.e., none of supported by one IntOAM system authentication method is supported by another, an implementation MUST reflect this in its operational state and SHOULD notify an operator. 5.5.2. Using Lightweight Authentication After IntOAM peers select an authentication mode of Lightweight Authentication, each IntOAM system MUST use that mode to authenticate each IntOAM Control message transmitted as part of a Poll Sequence using Lightweight Authentication TLV presented in Figure 8. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Authentication| Reserved | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ HMAC ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 8: Lightweight Authentication TLV Format Fields in Figure 8 are defined as the following: * Lightweight Authentication - one-octet field. Its value (TBA8) allocated by IANA in Section 6 * Reserved - one-octet field. MUST be zeroed on the transmit and ignored on the receipt. Mirsky, et al. Expires 14 May 2023 [Page 15] Internet-Draft Integrated OAM November 2022 * Length - two-octet long field. The value equals the length on the Lightweight Authentication TLV field in octets. The value of the Length field MUST be a multiple of 4. * HMAC (Hashed Message Authentication Code) - variable-length field. The value is the hash value calculated on the entire preceding IntOAM Control message data. The Lightweight Authentication TLV MUST be the last in an IntOAM Control message. Padding TLV (Section 5.2) MAY be used to align the length of the IntOAM Control message, excluding the Lightweight Authentication TLV, at a multiple of 16 boundary. The IntOAM system that receives the IntOAM Control message with the Lightweight Authentication TLV MUST first validate the .authentication by calculating the hash over the IntOAM Control message. If the validation succeeds, the receiver MUST transmit the IntOAM Control message with the Final flag set and the value of the Return code field in Diagnostic TLV set to None value (Table 5). Suppose the validation of the lightweight authentication fails. In that case, the IntOAM system MUST transmit the IntOAM Control message with the Final flag set and the value of the Return Code field of the Diagnostic TLV set to Lightweight Authentication failed value (Table 5). The IntOAM system MUST have a control policy that defines actions when the system receives the Lightweight Authentication failed return code. 6. IANA Considerations 6.1. IntOAM Message Types IANA is requested to create the IntOAM TLV Type registry. All code points in the range 1 through 175 in this registry shall be allocated according to the "IETF Review" procedure specified in [RFC8126]. Code points in the range 176 through 239 in this registry shall be allocated according to the "First Come First Served" procedure specified in [RFC8126]. The remaining code points are allocated according to Table 1: Mirsky, et al. Expires 14 May 2023 [Page 16] Internet-Draft Integrated OAM November 2022 +===========+==============+===============+ | Value | Description | Reference | +===========+==============+===============+ | 0 | Reserved | This document | +-----------+--------------+---------------+ | 1- 175 | Unassigned | This document | +-----------+--------------+---------------+ | 176 - 239 | Unassigned | This document | +-----------+--------------+---------------+ | 240 - 251 | Experimental | This document | +-----------+--------------+---------------+ | 252 - 254 | Private Use | This document | +-----------+--------------+---------------+ | 255 | Reserved | This document | +-----------+--------------+---------------+ Table 1: IntOAM Type Registry This document defines the following new values in IntOAM Type registry: +=======+=================================+===============+ | Value | Description | Reference | +=======+=================================+===============+ | TBA0 | Multiple TLVs Used | This document | +-------+---------------------------------+---------------+ | TBA1 | Padding | This document | +-------+---------------------------------+---------------+ | TBA2 | Capability | This document | +-------+---------------------------------+---------------+ | TBA3 | Loss Measurement | This document | +-------+---------------------------------+---------------+ | TBA4 | Delay Measurement | This document | +-------+---------------------------------+---------------+ | TBA5 | Combined Loss/Delay Measurement | This document | +-------+---------------------------------+---------------+ | TBA6 | Diagnostic | This document | +-------+---------------------------------+---------------+ | TBA8 | Lightweight Authentication | This document | +-------+---------------------------------+---------------+ Table 2: IntOAM Types 6.2. Lightweight Authentication Modes IANA is requested to create a Lightweight Authentication Modes registry. This registry shall allocate all code points according to the "IETF Review" procedure as specified in [RFC8126]. Mirsky, et al. Expires 14 May 2023 [Page 17] Internet-Draft Integrated OAM November 2022 This document defines the following new values in the Lightweight Authentication Modes registry: +==============+=======+========================+===============+ | Bit Position | Value | Description | Reference | +==============+=======+========================+===============+ | 0 | 0x1 | Keyed SHA-1 | This document | +--------------+-------+------------------------+---------------+ | 1 | 0x2 | Meticulous Keyed SHA-1 | This document | +--------------+-------+------------------------+---------------+ | 2 | 0x4 | SHA-256 | This document | +--------------+-------+------------------------+---------------+ Table 3: Lightweight Authentication Modes 6.3. Return Codes IANA is requested to create the IntOAM Return Codes registry. All code points in the range 1 through 250 in this registry shall be allocated according to the "IETF Review" procedure as specified in [RFC8126]. The remaining code points are allocated according to Table 4: +=========+==============+===============+ | Value | Description | Reference | +=========+==============+===============+ | 0 | Reserved | This document | +---------+--------------+---------------+ | 1- 250 | Unassigned | IETF Review | +---------+--------------+---------------+ | 251-253 | Experimental | This document | +---------+--------------+---------------+ | 254 | Private Use | This document | +---------+--------------+---------------+ | 255 | Reserved | This document | +---------+--------------+---------------+ Table 4: IntOAM Return Codes Registry This document defines the following new values in IntOAM Return Codes registry: Mirsky, et al. Expires 14 May 2023 [Page 18] Internet-Draft Integrated OAM November 2022 +=======+======================================+===============+ | Value | Description | Reference | +=======+======================================+===============+ | 0 | None | This document | +-------+--------------------------------------+---------------+ | 1 | One or more TLVs were not understood | This document | +-------+--------------------------------------+---------------+ | 2 | Lightweight Authentication failed | This document | +-------+--------------------------------------+---------------+ Table 5: IntOAM Return Codes 7. Security Considerations The same security considerations as those described in [RFC5880], [RFC6374], and [RFC8562] apply to this document. Additionally, implementations that use a distribution of discriminators over the control or management plane MUST use secure channels to protect systems from an infinite number of IntOAM sessions being created. In some environments, an IntoOAM session can be instantiated using a bootstrapping mechanism supported by the control or management plane. As a result, the three-way handshaking mechanism between IntOAM systems is bypassed. That could cause a situation where one of the systems uses overaggressive transmission intervals that are not acceptable to the remote IntOAM system. As a result, IntOAM Control messages could be dropped, and the remote IntOAM system concludes the IntOAM session failed. The environment that does not use the three- way handshake mechanism to instantiate an IntOAM session MUST support means to balance resources used by the IntOAM. 8. Acknowledgements TBD 9. References 9.1. Normative References [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, . Mirsky, et al. Expires 14 May 2023 [Page 19] Internet-Draft Integrated OAM November 2022 [RFC6374] Frost, D. and S. Bryant, "Packet Loss and Delay Measurement for MPLS Networks", RFC 6374, DOI 10.17487/RFC6374, September 2011, . [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8562] Katz, D., Ward, D., Pallagatti, S., Ed., and G. Mirsky, Ed., "Bidirectional Forwarding Detection (BFD) for Multipoint Networks", RFC 8562, DOI 10.17487/RFC8562, April 2019, . 9.2. Informative References [RFC8655] Finn, N., Thubert, P., Varga, B., and J. Farkas, "Deterministic Networking Architecture", RFC 8655, DOI 10.17487/RFC8655, October 2019, . Authors' Addresses Greg Mirsky Ericsson Email: gregimirsky@gmail.com Xiao Min ZTE Corp. Email: xiao.min2@zte.com.cn Gyan Mishra Verizon Inc. Email: gyan.s.mishra@verizon.com Mirsky, et al. Expires 14 May 2023 [Page 20]