idnits 2.17.1 draft-mmm-rtgwg-integrated-oam-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (29 March 2021) is 1122 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 RTGWG Working Group G. Mirsky 3 Internet-Draft X. Min 4 Intended status: Standards Track ZTE Corp. 5 Expires: 30 September 2021 G. Mishra 6 Verizon Inc. 7 29 March 2021 9 Integrated Operation, Administration, and Maintenance 10 draft-mmm-rtgwg-integrated-oam-01 12 Abstract 14 This document describes the Integrated Operation, Administration, and 15 Maintenance (IntOAM) protocol. IntOAM is based on the lightweight 16 capabilities of Bidirectional Forwarding Detection defined in RFC 17 5880 Bidirectional Forwarding Detection, and the RFC 6374 Packet Loss 18 and Delay Measurement for MPLS Networks to measure performance 19 metrics like packet loss and packet delay. Also, a method to perform 20 lightweight on-demand authentication is defined in this 21 specification. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at https://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on 30 September 2021. 40 Copyright Notice 42 Copyright (c) 2021 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 47 license-info) in effect on the date of publication of this document. 48 Please review these documents carefully, as they describe your rights 49 and restrictions with respect to this document. Code Components 50 extracted from this document must include Simplified BSD License text 51 as described in Section 4.e of the Trust Legal Provisions and are 52 provided without warranty as described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 2. Conventions used in this document . . . . . . . . . . . . . . 3 58 2.1. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2.2. Requirements Language . . . . . . . . . . . . . . . . . . 3 60 3. Integrated OAM Control Message . . . . . . . . . . . . . . . 3 61 4. Theory of Operation . . . . . . . . . . . . . . . . . . . . . 6 62 4.1. Use of Discriminators . . . . . . . . . . . . . . . . . . 6 63 4.2. Modes of IntOAM . . . . . . . . . . . . . . . . . . . . . 7 64 4.3. Echo Function . . . . . . . . . . . . . . . . . . . . . . 7 65 5. Using TLVs in the IntOAM . . . . . . . . . . . . . . . . . . 7 66 5.1. Integrated OAM Capability Negotiation . . . . . . . . . . 7 67 5.1.1. Timer Negotiation for Performance Monitoring . . . . 9 68 5.2. Padding TLV . . . . . . . . . . . . . . . . . . . . . . . 10 69 5.3. Diagnostic TLV . . . . . . . . . . . . . . . . . . . . . 11 70 5.4. Performance Measurement with IntOAM Control Message . . . 12 71 5.5. Lightweight Authentication . . . . . . . . . . . . . . . 13 72 5.5.1. Lightweight Authentication Mode Negotiation . . . . . 14 73 5.5.2. Using Lightweight Authentication . . . . . . . . . . 15 74 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 75 6.1. IntOAM Message Types . . . . . . . . . . . . . . . . . . 16 76 6.2. Lightweight Authentication Modes . . . . . . . . . . . . 17 77 6.3. Return Codes . . . . . . . . . . . . . . . . . . . . . . 18 78 7. Security Considerations . . . . . . . . . . . . . . . . . . . 18 79 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19 80 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 81 9.1. Normative References . . . . . . . . . . . . . . . . . . 19 82 9.2. Informative References . . . . . . . . . . . . . . . . . 19 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 85 1. Introduction 87 [RFC5880] has provided the base specification of Bidirectional 88 Forwarding Detection (BFD) as the light-weight mechanism to monitor a 89 path continuity between two systems and detect a failure in the data- 90 plane. Since its introduction, BFD has been broadly deployed. There 91 were several attempts to introduce new capabilities in the protocol, 92 some more successful than others. One of the obstacles to extending 93 BFD capabilities may be seen in the compact format of the BFD control 94 message. This document introduces the Integrated Operation, 95 Administration, and Maintenance (IntOAM) protocol based on BFD's 96 lightweight capabilities. It uses informational elements defined in 98 [RFC6374] to measure various performance metrics, e.g., synthetic 99 packet loss or packet delay. Combination of both Fault Management 100 (FM) Performance Monitoring (PM) OAM functions in the IntOAM protocol 101 is beneficial in some networks. For example, in a Deterministic 102 Networking (DetNet) domain [RFC8655], it is easier to ensure that an 103 IntOAM's test packet is fate-sharing with data packets rather than 104 mapping several FM and PM OAM protocols to that DetNet data flow. 106 2. Conventions used in this document 108 2.1. Acronyms 110 BFD: Bidirectional Forwarding Detection 112 G-ACh Generic Associated Channel 114 IntOAM Integrated OAM 116 HMAC Hashed Message Authentication Code 118 MTU Maximum Transmission Unit 120 PMTUD Path MTU Discovery 122 PMTUM Path MTU Monitoring 124 p2p: Point-to-Point 126 TLV Type, Length, Value 128 OAM Operations, Administration, and Maintenance 130 FM Fault Management 132 PM Performance Monitoring 134 DetNet Deterministic Networking 136 2.2. Requirements Language 138 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 139 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 140 "OPTIONAL" in this document are to be interpreted as described in BCP 141 14 [RFC2119] [RFC8174] when, and only when, they appear in all 142 capitals, as shown here. 144 3. Integrated OAM Control Message 145 0 1 2 3 146 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 147 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 148 | V | Diag |Sta|P|F|D|M| Reserved | 149 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 150 | Detect Mult | Length | 151 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 152 | My Discriminator | 153 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 154 | Your Discriminator | 155 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 156 | Desired Min TX Interval | 157 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 158 | Required Min RX Interval | 159 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 160 | Required Min Echo RX Interval | 161 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 162 | | 163 ~ TLVs (variable) ~ 164 | | 165 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 167 Figure 1: Integrated OAM Control Message Format 169 where fields are defined as the following: 171 * Version (V) - two-bit field. The definition of the field, its 172 interpretation, use in the protocol operation, and assigned values 173 are as defined in [RFC5880] for the Version field. 175 * Diagnostic (Diag) - five-bit field. The definition of the field, 176 its interpretation, use in the protocol operation, and assigned 177 values are as defined in [RFC5880] for the Diagnostic field. 179 * Status (Sta) - two-bit field. The definition of the field, its 180 interpretation, use in the protocol operation, and assigned values 181 are as defined in [RFC5880] for the Status field. 183 * Poll (P) - one-bit field The definition of the field, its 184 interpretation, use in the protocol operation, and assigned values 185 are as defined in [RFC5880] for the Poll field. 187 * Final (F) - one-bit field. The definition of the field, its 188 interpretation, use in the protocol operation, and assigned values 189 are as defined in [RFC5880] for the Final field. 191 * Demand (D) - one-bit field. The definition of the field, its 192 interpretation, use in the protocol operation, and assigned values 193 are as defined in [RFC5880] for the Demand field. 195 * Multipoint (M) - one-bit field. The definition of the field, its 196 interpretation, and its use in the protocol operation are as 197 defined in [RFC5880] for the Multipoint field. 199 * Reserved - seventeen-bit field that can be defined in the future. 200 It MUST be zeroed on transmission and ignored on receipt. 202 * Detect Mult - two-octet field. The definition of the field, its 203 interpretation, and its use in the protocol operation are as 204 defined in [RFC5880] for the Detect Mult field. 206 * Length - two-octet field equal to the length of the IntOAM Control 207 message in octets. 209 * My Discriminator - four-octet field. The definition of the field, 210 its interpretation, use in the protocol operation, and assigned 211 values are as defined in [RFC5880] for the My Discriminator field. 213 * Your Discriminator - four-octet field. The definition of the 214 field, its interpretation, and its use in the protocol operation 215 are as defined in [RFC5880] for the Your Discriminator field. 217 * Desired Min TX Interval - four-octet field. The definition of the 218 field, its interpretation, and its use in the protocol operation 219 are as defined in [RFC5880] for the Desired Min TX Interval field. 220 Additional use cases for the Desired Min TX Interval field 221 described in Section 5.1.1. 223 * Required Min RX Interval - four-octet field. The definition of 224 the field, its interpretation, and its use in the protocol 225 operation are as defined in [RFC5880] for the Required Min RX 226 Interval field. Additional use cases for the Required Min RX 227 Interval field described in Section 5.1.1. 229 * Required Min Echo RX Interval - four-octet field. [Ed.note: In 230 BFD, as I understand, it serves several purposes - indicate 231 support of Echo (zero value - non-support), and throttle rate the 232 remote will send its Echo. But that only works if the Echo can be 233 sent when the session is Up. There's now a proposal to send Echo 234 regardless of the state of a session. Hence the question - is it 235 still a good use of four bytes?] 237 * TLVs - is a variable-length field that contains commands and/or 238 data encoded as type-length-value (TLV) shown in Figure 2. 240 TLV is a variable-length field. Multiple TLVs MAY be placed in an 241 IntOAM Control message. Additional TLVs may be enclosed within a 242 given TLV, subject to the semantics of the (outer) TLV in question. 243 If more than one TLV is to be included, the value of the Type field 244 of the outmost outer TLV MUST be set to Multiple TLVs Used (TBA0), as 245 assigned by IANA according to Section 6.1. Figure 2 displays the TLV 246 format in an IntOAM protocol. 248 0 1 2 3 249 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 250 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 251 | Type | Reserved | Length | 252 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 253 ~ Value ~ 254 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 256 Figure 2: General Type-Length-Value Encoding 258 where fields are defined as the following: 260 * Type - one-octet field that characterizes the interpretation of 261 the Value field. Type values are allocated according to 262 Section 6.1. 264 * Reserved - one-octet field. The value of the Type field 265 determines its interpretation and encoding. 267 * Length - two-octet field equal to the length of the Value field in 268 octets. 270 * Value - a variable-length field. The value of the Type field 271 determines its interpretation and encoding. 273 4. Theory of Operation 275 [Ed.note: Should the document reference Asynchronous and Demand modes 276 in RFC 5880?] 278 4.1. Use of Discriminators 280 A discriminator is defined in the IntOAM as an unsigned 32-bit long 281 integer that identifies a particular IntOAM session. An IntOAM 282 system MAY locally assign a discriminator for the given IntOAM 283 session. Also, a discriminator MAY be distributed by the control 284 plane or management plane. 286 In a point-to-point (p2p) IntOAM session, the value of the Your 287 Discriminator field is used to demultiplex IntOAM sessions. An 288 IntOAM system has to learn the value of discriminator that the remote 289 IntOAM system associates with the IntOAM session between these two 290 systems. The IntOAM system MAY use a three-way handshake mechanism 291 to learn of discriminator of the remote system. Besides, the control 292 or management plane MAY be used to associate discriminator values 293 with the specific IntOAM session. In other scenarios, e.g., point- 294 to-multipoint (p2mp) IntOAM session, the Your Discriminator's value 295 could be left undefined for some nodes. In that case, such a node 296 uses the My Discriminator field's value in combination with 297 information that identifies the sender of the IntOAM Control message 298 and the path identifier. 300 4.2. Modes of IntOAM 302 IntOAM has two operational modes that provide for proactive defect 303 detection in a network- Asynchronous and Demand. An IntOAM 304 implementation MUST be capable of operating in either of them. In 305 the Asynchronous mode, an IntOAM system periodically transmits IntOAM 306 Control messages. When an IntOAM system is in the Demand mode, it 307 does not periodically transmit IntOAM Control messages. An IntOAM 308 system in the Demand mode MAY transmit a Control message as a part of 309 the Poll sequence. A system MAY be set into the Demand mode at any 310 time during the IntOAM session. 312 4.3. Echo Function 314 The Echo function in IntOAM can be used in networks when an operator 315 has ensured that the sender's test packet will first reach the 316 intended target before being returned to the sender. The target node 317 is not required to support IntOAM as the IntOAM packet is expected to 318 be looped back by the data plane without the need to inspect the test 319 packet itself. The IntOAM Control message and IntOAM TLVs MAY be 320 used as the test packet by the IntOAM Echo function. 322 5. Using TLVs in the IntOAM 324 5.1. Integrated OAM Capability Negotiation 326 An IntOAM system, also referred to as a node in this document, that 327 supports IntOAM first MUST discover the extent to which other nodes 328 in the given session support the Integrated OAM. The node MUST send 329 an IntOAM Control message initiating the Poll Sequence as defined in 330 [RFC5880]. If the remote system fails to respond with the IntOAM 331 Control message and the Final flag set, then the initiator node MUST 332 conclude that the peer does not support the use of the IntOAM Control 333 messages. 335 The first IntOAM Control message initiating the Poll Sequence SHOULD 336 include the Capability TLV that lists capabilities that may be used 337 at some time during the lifetime of the IntOAM session. Until the 338 node negotiated the use of PM capabilities of the IntOAM, the node 339 MUST NOT include any TLVs in the IntOAM Control message, other than 340 the Capability TLV. The format of the Capability TLV is presented in 341 Figure 3. 343 0 1 2 3 344 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 345 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 346 | Capability | Reserved | Length | 347 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 348 | L | D | M | Unassigned | 349 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 350 | Authentication ... | Padding ... 351 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 353 Figure 3: Capability TLV Format 355 where fields are defined as the following: 357 * Capability - one-octet field. Its value (TBA2) allocated by IANA 358 in Section 6 360 * Reserved - one-octet field. It MUST be zeroed on the transmit and 361 ignored on the receipt. 363 * Length - two-octet field. The value equals length on the 364 Capability TLV in octets. The value of the Length field MUST be a 365 multiple of 4. 367 * Loss - two-bit field. The least significant of the two bits is 368 set if the node can measure packet loss using a periodically 369 transmitted IntOAM control message. The most significant of the 370 two bits is set if the node is capable of measuring packet loss 371 using the Poll Sequence with IntOAM Control message. 373 * Delay - two-bit field. The least significant of the two bits is 374 set if the node can measure packet delay using a periodically 375 transmitted IntOAM control message. The most significant of the 376 two bits is set if the node is capable of measuring packet delay 377 using the Poll Sequence with IntOAM Control message. 379 * MTU - two-bits field. Set if the node is capable of using the 380 IntOAM Control message in Path MTU Discovery (PMTUD). or PMTU 381 Monitoring (PMTUM). The least significant of the two bits is set 382 if the node can perform PMTUD/PMTUM using periodically transmitted 383 IntOAM control message. The most significant of the two bits is 384 set if the node is capable of PMTUD/PMTUM using the Poll Sequence 385 with IntOAM Control message. 387 * Unassigned - 26-bit field. It MUST be zeroed on transmission and 388 ignored on receipt 390 * (Lightweight) Authentication - variable-length field. An IntOAM 391 system uses the Authentication field for advertising its 392 lightweight authentication capabilities. The format and the use 393 of the Authentication field are defined in Section 5.5.1. 395 * Padding - variable-length field. It MUST be zeroed on 396 transmission and ignored on receipt. The Padding field aligns the 397 length of the Capability TLV to a four-octet boundary. 399 The remote IntOAM node that supports this specification MUST respond 400 to the Capability TLV with the IntOAM Control message, includeding 401 the Capability TLV listing capabilities the responder supports. The 402 responder MUST set the Final flag in the IntOAM Control message. 404 5.1.1. Timer Negotiation for Performance Monitoring 406 IntOAM allows for the negotiation of time intervals at which an 407 IntOAM system transmits and receives IntOAM Control packets. That 408 equally applies to packets used for performance monitoring, whether 409 it measures packet delay or packet loss, using TLVs defined in 410 Section 5.4. An IntOAM system sets its timer values in an IntOAM 411 Control packet that includes the Capabilities TLV. The negotiation 412 process is similar to the one described in [RFC5880]. A local IntOAM 413 system advertises its shortest interval for transmitting IntOAM 414 packets to measure the indicated metrics and the shortest interval 415 that is it capable of receiving PM IntOAM packets. Suppose a system 416 does not support the given metric measurement, i.e., packet loss or 417 packet delay. In that case, it MUST set the value of the Required 418 Min RX Interval to zero when transmitting the IntOAM Control message 419 with the Capability TLV. If an IntOAM system does not support one of 420 the modes, periodic or on-demand, for the given performance metric, 421 it MUST zero the appropriate bit in the field that describes the 422 metric. The timer values apply to all PM modes that have their 423 respective bits set in the Capacity TLV. If an operator wants to use 424 a different time intervals for different performance metrics 425 measurements, then separate Poll sequences with the Capabilities TLV 426 included MAY be used. Thus IntOAM allows negotiating different time 427 intervals for packet loss and packet delay measurements. 429 5.2. Padding TLV 431 Padding TLV MAY be used to generate IntOAM Control messages of the 432 desired length. 434 0 1 2 3 435 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 436 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 437 | Padding | Reserved | Length | 438 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 439 | | 440 ~ Padding ~ 441 | | 442 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 444 Figure 4: Padding TLV Format 446 where fields are defined as the following: 448 * Padding - one-octet field. Its value (TBA1) allocated by IANA in 449 Section 6 451 * Reserved - one-octet field. MUST be zeroed on the transmit and 452 ignored on the receipt. 454 * Length - two-octet field equals length on the Padding TLV in 455 octets. The value of the Length field MUST be a multiple of 4. 457 * Padding - variable-length field. It MUST be zeroed on transmit 458 and ignored on receipt. 460 Padding TLV MAY be used to generate IntOAM Control messages of 461 different lengths. That capability is necessary to perform PMTUD, 462 PMTUM, and measure synthetic packet loss and/or packet delay. When 463 Padding TLV is used in combination with one of the performance 464 measurement messages carried in Performance Metric TLVs as defined in 465 Section 5.4, Padding TLV MUST follow the Performance Metric TLV. 467 Padding TLV MAY be used in PMTUM as part of periodically sent IntOAM 468 Control messages. In this case, the number of consecutive messages 469 that include Padding TLV MUST be not lesser than Detect Multiplier to 470 ensure that the remote IntOAM peer will detect loss of messages with 471 the Padding TLV. Also, Padding TLV MAY be present in an IntOAM 472 Control message with the Poll flag set. If the remote IntOAM peer 473 that supports this specification receives an IntOAM Control message 474 with Padding TLV, it MUST include the Padding TLV with the Padding 475 field of the same length as in the received packet and set the Final 476 flag. 478 5.3. Diagnostic TLV 480 Diagnostic TLV MAY be used to characterize the result of the last 481 requested operation. 483 0 1 2 3 484 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 485 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 486 | Diagnostic | Reserved | Length | 487 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 488 | Return Code | Reserved | 489 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 491 Figure 5: Diagnostic TLV Format 493 where fields are defined as the following: 495 * Diagnostic - one-octet field.Its value (TBA6) allocated by IANA in 496 Section 6. 498 * Reserved - one-octet field. MUST be zeroed on the transmit and 499 ignored on the receipt. 501 * Length - tw-octet field. Its value MUST be set to eight. 503 * Return Code - eight-bit field. The responding IntOAM system can 504 set it to one of the values defined in Section 6.3. 506 * Reserved - 24 bits-long field. MUST be zeroed on transmit and 507 ignored on receipt. 509 5.4. Performance Measurement with IntOAM Control Message 511 Loss measurement, delay measurement, and loss/delay measurement 512 messages can be used in the IntOAM Control message to obtain 513 respective one-way and round-trip metrics. All the messages are 514 encapsulated as TLVs with Type values allocated by IANA, Section 6. 516 The sender MAY use the Performance Metric TLV (presented in Figure 6) 517 to measure performance metrics and obtain the measurement report from 518 the receiver. 520 0 1 2 3 521 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 522 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 523 | Perf. Metric | Reserved | Length | 524 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 525 | Loss Measurement Message, | 526 ~ Delay Measurement Message, or ~ 527 | Combined Loss/Delay Measurement Message | 528 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 530 Figure 6: Performance Metric TLV Format 532 where fields are defined as the following: 534 * Performance Metric - one-octet field. Valid vaues are TBA3 535 through TBA5 allocated by IANA in Section 6 as follows: 537 - TBA3 - Loss Measurement Type; 539 - TBA4 - Delay Measurement Type; 541 - TBA5 - Combined Loss/Delay Measurement Type 543 * Reserved - one-octet field. MUST be zeroed on the transmit and 544 ignored on the receipt. 546 * Length - two-octet field equals length on the Performance Metric 547 TLV in octets. The value of the Length field MUST be a multiple 548 of 4. 550 * Value - various performance metrics measured either directly or 551 using synthetic methods accordingly using the messages defined in 552 Sections 3.1 through 3.3 [RFC6374]. 554 To perform one-way loss and/or delay measurement, the IntOAM node MAY 555 periodically transmit the IntOAM message with one of the TLVs listed 556 above in Asynchronous mode. To perform synthetic loss measurement, 557 the sender MUST monotonically increment the counter of transmitted 558 test packets. When using Performance Metric TLV for synthetic 559 measurement, an IntOAM Control message MAY also include Padding TLV. 560 In that case, the Padding TLV MUST immediately follow Performance 561 Metric TLV. Also, direct-mode loss measurement, as described in 562 [RFC6374], is supported. Procedures to negotiate and manipulate 563 transmission intervals defined in Sections 6.8.2 and 6.8.3 in 564 [RFC5880] SHOULD be used to control the performance impact of using 565 the IntOAM for performance measurement in the particular IntOAM 566 session. 568 To measure the round-trip loss and/or delay metrics, an IntOAM node 569 transmits the IntOAM Control message with the Performance Metric TLV 570 with the Poll flag set. Before transmitting the IntOAM Control 571 message with the Performance Metric TLV, the receiver MUST clear the 572 Poll flag and set the Final flag. 574 5.5. Lightweight Authentication 576 Using IntOAM without any security measures, such as exchanging IntOAM 577 Control messages without authentication, increases the risk of an 578 attack, especially over multiple nodes. Thus, using IntOAM without 579 security measures may cause false positive or false negative defect 580 detection situations. In the former, an attacker may spoof IntOAM 581 Control messages pretending to be a remote peer and can thus view the 582 IntOAM session operation even though the real path had failed. In 583 the latter, the attacker may spoof an altered IntOAM control message 584 indicating that the IntOAM session is un-operational even though the 585 path and the remote IntOAM peer operate normally. 587 BFD [RFC5880] allows for optional authentication protection of BFD 588 Control messages to minimize the chances of attacks in a networking 589 system. However, at least some of the supported authentication 590 protocols do not provide sufficient protection in modern networks. 591 Also, the current BFD technology requires authentication of each BFD 592 Control message. Such an authentication requirement can put a 593 computational burden on networking devices, especially in the 594 Asynchronous mode, at least because authenticating each BFD Control 595 message can require substantial computing resources to support packet 596 exchange at high rates. 598 This specification defines a lightweight on-demand mode of 599 authentication for an IntOAM session. The lightweight authentication 600 is an optional mode. The mechanism includes negotiation 601 (Section 5.5.1) and on-demand authentication (Section 5.5.2) phases. 603 During the former, IntOAM peers advertise supported authentication 604 capabilities and independently select the commonly supported mode of 605 the authentication. In the authentication phase, each IntOAM system 606 transmits, at certain events or periodically, authenticated IntOAM 607 Control messages in Poll Sequence. 609 5.5.1. Lightweight Authentication Mode Negotiation 611 Figure 7 displays the format of the Authentication field that is part 612 of the Capability Encoding: 614 0 1 2 3 615 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 616 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 617 | Len | AuthL | Authentication Mode ... 618 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 620 Figure 7: Lightweight Authentication Capability Field Format 622 where fields are defined as the following: 624 * Len (Length) - four-bit field. The value of the Length field is 625 equal to the length of the Authentication field, including the 626 Length, in octets. 628 * AuthL (Authentication Length) - four-bit field. The value of the 629 field is, in four octets long words, the longest authentication 630 signature the IntOAM system is capable of supporting for any of 631 the methods advertised in the AuthMode field. 633 * Authentication Mode - variable-length field. It is a bit-coded 634 field that an IntOAM system uses to list modes of lightweight 635 authentication it supports. 637 An IntOAM system uses Capability TLV, defined in Section 5.1, to 638 discover the commonly supported mode of the Lightweight 639 Authentication. The system sets the values in the Authentication 640 field according to properly reflect its authentication capabilities. 641 The IntOAM system transmits the IntOAM Control message with 642 Capability TLV as the first in a Poll Sequence. The remote IntOAM 643 system that supports this specification receives the IntOAM Control 644 message with the advertised Lightweight Authentication modes and 645 stores information locally. The system responds with the 646 advertisement of its Lightweight Authentication capabilities in the 647 IntOAM Control message with the Final flag set. Each IntOAM system 648 uses local and received information about Lightweight Authentication 649 capabilities to deduce the commonly supported modes and selects from 650 that set to use the strongest authentication with the longest 651 signature. If the common set is empty, i.e., none of supported by 652 one IntOAM system authentication method is supported by another, an 653 implementation MUST reflect this in its operational state and SHOULD 654 notify an operator. 656 5.5.2. Using Lightweight Authentication 658 After IntOAM peers select an authentication mode for use in 659 Lightweight Authentication each IntOAM system MUST use it to 660 authenticate each IntOAM Control message transmitted as part of a 661 Poll Sequence using Lightweight Authentication TLV presented in 662 Figure 8. 664 0 1 2 3 665 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 666 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 667 | Authentication| Reserved | Length | 668 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 669 | | 670 ~ HMAC ~ 671 | | 672 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 674 Figure 8: Lightweight Authentication TLV Format 676 where fields are defined as the following: 678 * Lightweight Authentication - one-octet field.It value (TBA8) 679 allocated by IANA in Section 6 681 * Reserved - one-octet field. MUST be zeroed on the transmit and 682 ignored on the receipt. 684 * Length - two-octet long field. The value equals length on the 685 Lightweight Authentication TLV field in octets. The value of the 686 Length field MUST be a multiple of 4. 688 * HMAC (Hashed Message Authentication Code) - variable-length field. 689 The value is the hash value calculated on the entire preceding 690 IntOAM Control message data. 692 The Lightweight Authentication TLV MUST be the last in an IntOAM 693 Control message. Padding TLV (Section 5.2) MAY be used to align the 694 length of the IntOAM Control message, excluding the Lightweight 695 Authentication TLV, at multiple of 16 boundary. 697 The IntOAM system that receives the IntOAM Control message with the 698 Lightweight Authentication TLV MUST first validate the 699 .authentication by calculating the hash over the IntOAM Control 700 message. If the validation succeeds, the receiver MUST transmit the 701 IntOAM Control message with the Final flag set and the value of the 702 Return code field in Diagnostic TLV set to None value (Table 5). If 703 the validation of the lightweight authentication fails, then the 704 IntOAM system MUST transmit the IntOAM Control message with the Final 705 flag set and the value of the Return Code field of the Diagnostic TLV 706 set to Lightweight Authentication failed value (Table 5). The IntOAM 707 system MUST have a control policy that defines actions when the 708 system receives the Lightweight Authentication failed return code. 710 6. IANA Considerations 712 6.1. IntOAM Message Types 714 IANA is requested to create the IntOAM TLV Type registry. All code 715 points in the range 1 through 175 in this registry shall be allocated 716 according to the "IETF Review" procedure specified in [RFC8126]. 717 Code points in the range 176 through 239 in this registry shall be 718 allocated according to the "First Come First Served" procedure 719 specified in [RFC8126]. The remaining code points are allocated 720 according to Table 1: 722 +===========+==============+===============+ 723 | Value | Description | Reference | 724 +===========+==============+===============+ 725 | 0 | Reserved | This document | 726 +-----------+--------------+---------------+ 727 | 1- 175 | Unassigned | This document | 728 +-----------+--------------+---------------+ 729 | 176 - 239 | Unassigned | This document | 730 +-----------+--------------+---------------+ 731 | 240 - 251 | Experimental | This document | 732 +-----------+--------------+---------------+ 733 | 252 - 254 | Private Use | This document | 734 +-----------+--------------+---------------+ 735 | 255 | Reserved | This document | 736 +-----------+--------------+---------------+ 738 Table 1: IntOAM Type Registry 740 This document defines the following new values in IntOAM Type 741 registry: 743 +=======+=================================+===============+ 744 | Value | Description | Reference | 745 +=======+=================================+===============+ 746 | TBA0 | Multiple TLVs Used | This document | 747 +-------+---------------------------------+---------------+ 748 | TBA1 | Padding | This document | 749 +-------+---------------------------------+---------------+ 750 | TBA2 | Capability | This document | 751 +-------+---------------------------------+---------------+ 752 | TBA3 | Loss Measurement | This document | 753 +-------+---------------------------------+---------------+ 754 | TBA4 | Delay Measurement | This document | 755 +-------+---------------------------------+---------------+ 756 | TBA5 | Combined Loss/Delay Measurement | This document | 757 +-------+---------------------------------+---------------+ 758 | TBA6 | Diagnostic | This document | 759 +-------+---------------------------------+---------------+ 760 | TBA8 | Lightweight Authentication | This document | 761 +-------+---------------------------------+---------------+ 763 Table 2: IntOAM Types 765 6.2. Lightweight Authentication Modes 767 IANA is requested to create a Lightweight Authentication Modes 768 registry. All code points in this registry shall be allocated 769 according to the "IETF Review" procedure as specified in [RFC8126]. 771 This document defines the following new values in the Lightweight 772 Authentication Modes registry: 774 +==============+=======+========================+===============+ 775 | Bit Position | Value | Description | Reference | 776 +==============+=======+========================+===============+ 777 | 0 | 0x1 | Keyed SHA-1 | This document | 778 +--------------+-------+------------------------+---------------+ 779 | 1 | 0x2 | Meticulous Keyed SHA-1 | This document | 780 +--------------+-------+------------------------+---------------+ 781 | 2 | 0x4 | SHA-256 | This document | 782 +--------------+-------+------------------------+---------------+ 784 Table 3: Lightweight Authentication Modes 786 6.3. Return Codes 788 IANA is requested to create the IntOAM Return Codes registry. All 789 code points in the range 1 through 250 in this registry shall be 790 allocated according to the "IETF Review" procedure as specified in 791 [RFC8126]. The remaining code points are allocated according to 792 Table 4: 794 +=========+==============+===============+ 795 | Value | Description | Reference | 796 +=========+==============+===============+ 797 | 0 | Reserved | This document | 798 +---------+--------------+---------------+ 799 | 1- 250 | Unassigned | IETF Review | 800 +---------+--------------+---------------+ 801 | 251-253 | Experimental | This document | 802 +---------+--------------+---------------+ 803 | 254 | Private Use | This document | 804 +---------+--------------+---------------+ 805 | 255 | Reserved | This document | 806 +---------+--------------+---------------+ 808 Table 4: IntOAM Return Codes Registry 810 This document defines the following new values in IntOAM Return Codes 811 registry: 813 +=======+=====================================+===============+ 814 | Value | Description | Reference | 815 +=======+=====================================+===============+ 816 | 0 | None | This document | 817 +-------+-------------------------------------+---------------+ 818 | 1 | One or more TLVs was not understood | This document | 819 +-------+-------------------------------------+---------------+ 820 | 2 | Lightweight Authentication failed | This document | 821 +-------+-------------------------------------+---------------+ 823 Table 5: IntOAM Return Codes 825 7. Security Considerations 827 The same security considerations as those described in [RFC5880], 828 [RFC6374], and [RFC8562]. apply to this document. Additionally, 829 implementations that use distribution of discriminators over the 830 control or management plane MUST use secure channels to protect 831 systems from an infinite number of IntOAM sessions being created. 833 In some environments, an IntoOAM session can be instantiated using a 834 bootstrapping mechanism supported by the control or management plane. 835 As a result, the three-way handshaking mechanism between IntOAM 836 systems is bypassed. That could cause the situation where one of the 837 systems uses overaggressive transmission intervals that are not 838 acceptable to the remote IntOAM system. As a result, IntOAM Control 839 messages could be dropped, and the remote IntOAM system concludes the 840 IntOAM session failed. The environment that does not use the three- 841 way handshake mechanism to instantiate an IntOAM session MUST support 842 means to balance resources used by the IntOAM. 844 8. Acknowledgements 846 TBD 848 9. References 850 9.1. Normative References 852 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 853 Requirement Levels", BCP 14, RFC 2119, 854 DOI 10.17487/RFC2119, March 1997, 855 . 857 [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 858 (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010, 859 . 861 [RFC6374] Frost, D. and S. Bryant, "Packet Loss and Delay 862 Measurement for MPLS Networks", RFC 6374, 863 DOI 10.17487/RFC6374, September 2011, 864 . 866 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 867 Writing an IANA Considerations Section in RFCs", BCP 26, 868 RFC 8126, DOI 10.17487/RFC8126, June 2017, 869 . 871 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 872 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 873 May 2017, . 875 [RFC8562] Katz, D., Ward, D., Pallagatti, S., Ed., and G. Mirsky, 876 Ed., "Bidirectional Forwarding Detection (BFD) for 877 Multipoint Networks", RFC 8562, DOI 10.17487/RFC8562, 878 April 2019, . 880 9.2. Informative References 882 [RFC8655] Finn, N., Thubert, P., Varga, B., and J. Farkas, 883 "Deterministic Networking Architecture", RFC 8655, 884 DOI 10.17487/RFC8655, October 2019, 885 . 887 Authors' Addresses 889 Greg Mirsky 890 ZTE Corp. 892 Email: gregimirsky@gmail.com, gregory.mirsky@ztetx.com 894 Xiao Min 895 ZTE Corp. 897 Email: xiao.min2@zte.com.cn 899 Gyan Mishra 900 Verizon Inc. 902 Email: gyan.s.mishra@verizon.com