idnits 2.17.1 draft-mmm-rtgwg-integrated-oam-00.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 (February 18, 2021) is 1156 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: August 22, 2021 G. Mishra 6 Verizon Inc. 7 February 18, 2021 9 Integrated Operation, Administration, and Maintenance 10 draft-mmm-rtgwg-integrated-oam-00 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 August 22, 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 47 (https://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 58 2. Conventions used in this document . . . . . . . . . . . . . . 3 59 2.1. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . 3 60 2.2. Requirements Language . . . . . . . . . . . . . . . . . . 3 61 3. Integrated OAM Control Message . . . . . . . . . . . . . . . 4 62 4. Theory of Operation . . . . . . . . . . . . . . . . . . . . . 6 63 4.1. Use of Discriminators . . . . . . . . . . . . . . . . . . 6 64 4.2. Modes of IntOAM . . . . . . . . . . . . . . . . . . . . . 7 65 4.3. Echo Function . . . . . . . . . . . . . . . . . . . . . . 7 66 5. Using TLVs in the IntOAM . . . . . . . . . . . . . . . . . . 7 67 5.1. Integrated OAM Capability Negotiation . . . . . . . . . . 7 68 5.1.1. Timer Negotiation for Performance Monitoring . . . . 9 69 5.2. Padding TLV . . . . . . . . . . . . . . . . . . . . . . . 10 70 5.3. Diagnostic TLV . . . . . . . . . . . . . . . . . . . . . 11 71 5.4. Performance Measurement with IntOAM Control Message . . . 11 72 5.5. Lightweight Authentication . . . . . . . . . . . . . . . 13 73 5.5.1. Lightweight Authentication Mode Negotiation . . . . . 13 74 5.5.2. Using Lightweight Authentication . . . . . . . . . . 14 75 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 76 6.1. IntOAM Message Types . . . . . . . . . . . . . . . . . . 16 77 6.2. Lightweight Authentication Modes . . . . . . . . . . . . 16 78 6.3. Return Codes . . . . . . . . . . . . . . . . . . . . . . 17 79 7. Security Considerations . . . . . . . . . . . . . . . . . . . 18 80 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18 81 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 82 9.1. Normative References . . . . . . . . . . . . . . . . . . 18 83 9.2. Informative References . . . . . . . . . . . . . . . . . 19 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 86 1. Introduction 88 [RFC5880] has provided the base specification of Bidirectional 89 Forwarding Detection (BFD) as the light-weight mechanism to monitor a 90 path continuity between two systems and detect a failure in the data- 91 plane. Since its introduction, BFD has been broadly deployed. There 92 were several attempts to introduce new capabilities in the protocol, 93 some more successful than others. One of the obstacles to extending 94 BFD capabilities may be seen in the compact format of the BFD control 95 message. This document introduces the Integrated Operation, 96 Administration, and Maintenance (IntOAM) protocol based on BFD's 97 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 146 0 1 2 3 147 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 148 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 149 | V | Diag |Sta|P|F|D|M| Reserved | 150 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 151 | Detect Mult | Length | 152 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 153 | My Discriminator | 154 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 155 | Your Discriminator | 156 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 157 | Desired Min TX Interval | 158 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 159 | Required Min RX Interval | 160 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 161 | Required Min Echo RX Interval | 162 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 163 | | 164 ~ TLVs (variable) ~ 165 | | 166 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 168 Figure 1: Integrated OAM Control Message Format 170 where fields are defined as the following: 172 o Version (V) - two-bit field. The definition of the field, its 173 interpretation, use in the protocol operation, and assigned values 174 are as defined in [RFC5880] for the Version field. 176 o Diagnostic (Diag) - five-bit field. The definition of the field, 177 its interpretation, use in the protocol operation, and assigned 178 values are as defined in [RFC5880] for the Diagnostic field. 180 o Status (Sta) - two-bit field. The definition of the field, its 181 interpretation, use in the protocol operation, and assigned values 182 are as defined in [RFC5880] for the Status field. 184 o Poll (P) - one-bit field The definition of the field, its 185 interpretation, use in the protocol operation, and assigned values 186 are as defined in [RFC5880] for the Poll field. 188 o Final (F) - one-bit field. The definition of the field, its 189 interpretation, use in the protocol operation, and assigned values 190 are as defined in [RFC5880] for the Final field. 192 o Demand (D) - one-bit field. The definition of the field, its 193 interpretation, use in the protocol operation, and assigned values 194 are as defined in [RFC5880] for the Demand field. 196 o Multipoint (M) - one-bit field. The definition of the field, its 197 interpretation, and its use in the protocol operation are as 198 defined in [RFC5880] for the Multipoint field. 200 o Reserved - seventeen-bit field that can be defined in the future. 201 It MUST be zeroed on transmission and ignored on receipt. 203 o Detect Mult - two-octet field. The definition of the field, its 204 interpretation, and its use in the protocol operation are as 205 defined in [RFC5880] for the Detect Mult field. 207 o Length - two-octet field equal to the length of the IntOAM Control 208 message in octets. 210 o My Discriminator - four-octet field. The definition of the field, 211 its interpretation, use in the protocol operation, and assigned 212 values are as defined in [RFC5880] for the My Discriminator field. 214 o Your Discriminator - four-octet field. The definition of the 215 field, its interpretation, and its use in the protocol operation 216 are as defined in [RFC5880] for the Your Discriminator field. 218 o Desired Min TX Interval - four-octet field. The definition of the 219 field, its interpretation, and its use in the protocol operation 220 are as defined in [RFC5880] for the Desired Min TX Interval field. 221 Additional use cases for the Desired Min TX Interval field 222 described in Section 5.1.1. 224 o Required Min RX Interval - four-octet field. The definition of 225 the field, its interpretation, and its use in the protocol 226 operation are as defined in [RFC5880] for the Required Min RX 227 Interval field. Additional use cases for the Required Min RX 228 Interval field described in Section 5.1.1. 230 o Required Min Echo RX Interval - four-octet field. [Ed.note: In 231 BFD, as I understand, it serves several purposes - indicate 232 support of Echo (zero value - non-support), and throttle rate the 233 remote will send its Echo. But that only works if the Echo can be 234 sent when the session is Up. There's now a proposal to send Echo 235 regardless of the state of a session. Hence the question - is it 236 still a good use of four bytes?] 238 o TLVs - is a variable-length field that contains commands and/or 239 data encoded as type-length-value (TLV) shown in Figure 2. 241 TLV is a variable-length field. Multiple TLVs MAY be placed in an 242 IntOAM Control message. Additional TLVs may be enclosed within a 243 given TLV, subject to the semantics of the (outer) TLV in question. 244 If more than one TLV is to be included, the value of the Type field 245 of the outmost outer TLV MUST be set to Multiple TLVs Used (TBA0), as 246 assigned by IANA according to Section 6.1. Figure 2 displays the TLV 247 format in an IntOAM protocol. 249 0 1 2 3 250 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 251 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 252 | Type | Reserved | Length | 253 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 254 ~ Value ~ 255 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 257 Figure 2: General Type-Length-Value Encoding 259 where fields are defined as the following: 261 o Type - one-octet field that characterizes the interpretation of 262 the Value field. Type values are allocated according to 263 Section 6.1. 265 o Reserved - one-octet field. The value of the Type field 266 determines its interpretation and encoding. 268 o Length - two-octet field equal to the length of the Value field in 269 octets. 271 o Value - a variable-length field. The value of the Type field 272 determines its interpretation and encoding. 274 4. Theory of Operation 276 [Ed.note: Should the document reference Asynchronous and Demand modes 277 in RFC 5880?] 279 4.1. Use of Discriminators 281 A discriminator is defined in the IntOAM as an unsigned 32-bit long 282 integer that identifies a particular IntOAM session. An IntOAM 283 system MAY locally assign a discriminator for the given IntOAM 284 session. Also, a discriminator MAY be distributed by the control 285 plane or management plane. 287 In a point-to-point (p2p) IntOAM session, the value of the Your 288 Discriminator field is used to demultiplex IntOAM sessions. An 289 IntOAM system has to learn the value of discriminator that the remote 290 IntOAM system associates with the IntOAM session between these two 291 systems. The IntOAM system MAY use a three-way handshake mechanism 292 to learn of discriminator of the remote system. Besides, the control 293 or management plane MAY be used to associate discriminator values 294 with the specific IntOAM session. In other scenarios, e.g., point- 295 to-multipoint (p2mp) IntOAM session, the Your Discriminator's value 296 could be left undefined for some nodes. In that case, such a node 297 uses the My Discriminator field's value in combination with 298 information that identifies the sender of the IntOAM Control message 299 and the path identifier. 301 4.2. Modes of IntOAM 303 IntOAM has two operational modes that provide for proactive defect 304 detection in a network- Asynchronous and Demand. An IntOAM 305 implementation MUST be capable of operating in either of them. In 306 the Asynchronous mode, an IntOAM system periodically transmits IntOAM 307 Control messages. When an IntOAM system is in the Demand mode, it 308 does not periodically transmit IntOAM Control messages. An IntOAM 309 system in the Demand mode MAY transmit a Control message as a part of 310 the Poll sequence. A system MAY be set into the Demand mode at any 311 time during the IntOAM session. 313 4.3. Echo Function 315 The Echo function in IntOAM can be used in networks when an operator 316 has ensured that the sender's test packet will first reach the 317 intended target before being returned to the sender. The target node 318 is not required to support IntOAM as the IntOAM packet is expected to 319 be looped back by the data plane without the need to inspect the test 320 packet itself. The IntOAM Control message and IntOAM TLVs MAY be 321 used as the test packet by the IntOAM Echo function. 323 5. Using TLVs in the IntOAM 325 5.1. Integrated OAM Capability Negotiation 327 An IntOAM system, also referred to as a node in this document, that 328 supports IntOAM first MUST discover the extent to which other nodes 329 in the given session support the Integrated OAM. The node MUST send 330 an IntOAM Control message initiating the Poll Sequence as defined in 331 [RFC5880]. If the remote system fails to respond with the IntOAM 332 Control message and the Final flag set, then the initiator node MUST 333 conclude that the peer does not support the use of the IntOAM Control 334 messages. 336 The first IntOAM Control message initiating the Poll Sequence SHOULD 337 include the Capability TLV that lists capabilities that may be used 338 at some time during the lifetime of the IntOAM session. Until the 339 node negotiated the use of PM capabilities of the IntOAM, the node 340 MUST NOT include any TLVs in the IntOAM Control message, other than 341 the Capability TLV. The format of the Capability TLV is presented in 342 Figure 3. 344 0 1 2 3 345 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 346 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 347 | Capability | Reserved | Length | 348 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 349 | L | D | M | Unassigned | 350 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 351 | Authentication ... | Padding ... 352 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 354 Figure 3: Capability TLV Format 356 where fields are defined as the following: 358 o Capability - one-octet field. Its value (TBA2) allocated by IANA 359 in Section 6 361 o Reserved - one-octet field. It MUST be zeroed on the transmit and 362 ignored on the receipt. 364 o Length - two-octet field. The value equals length on the 365 Capability TLV in octets. The value of the Length field MUST be a 366 multiple of 4. 368 o Loss - two-bit field. The least significant of the two bits is 369 set if the node can measure packet loss using a periodically 370 transmitted IntOAM control message. The most significant of the 371 two bits is set if the node is capable of measuring packet loss 372 using the Poll Sequence with IntOAM Control message. 374 o Delay - two-bit field. The least significant of the two bits is 375 set if the node can measure packet delay using a periodically 376 transmitted IntOAM control message. The most significant of the 377 two bits is set if the node is capable of measuring packet delay 378 using the Poll Sequence with IntOAM Control message. 380 o MTU - two-bits field. Set if the node is capable of using the 381 IntOAM Control message in Path MTU Discovery (PMTUD). or PMTU 382 Monitoring (PMTUM). The least significant of the two bits is set 383 if the node can perform PMTUD/PMTUM using periodically transmitted 384 IntOAM control message. The most significant of the two bits is 385 set if the node is capable of PMTUD/PMTUM using the Poll Sequence 386 with IntOAM Control message. 388 o Unassigned - 26-bit field. It MUST be zeroed on transmission and 389 ignored on receipt 391 o (Lightweight) Authentication - variable-length field. An IntOAM 392 system uses the Authentication field for advertising its 393 lightweight authentication capabilities. The format and the use 394 of the Authentication field are defined in Section 5.5.1. 396 o Padding - variable-length field. It MUST be zeroed on 397 transmission and ignored on receipt. The Padding field aligns the 398 length of the Capability TLV to a four-octet boundary. 400 The remote IntOAM node that supports this specification MUST respond 401 to the Capability TLV with the IntOAM Control message, includeding 402 the Capability TLV listing capabilities the responder supports. The 403 responder MUST set the Final flag in the IntOAM Control message. 405 5.1.1. Timer Negotiation for Performance Monitoring 407 IntOAM allows for the negotiation of time intervals at which an 408 IntOAM system transmits and receives IntOAM Control packets. That 409 equally applies to packets used for performance monitoring, whether 410 it measures packet delay or packet loss, using TLVs defined in 411 Section 5.4. An IntOAM system sets its timer values in an IntOAM 412 Control packet that includes the Capabilities TLV. The negotiation 413 process is similar to the one described in [RFC5880]. A local IntOAM 414 system advertises its shortest interval for transmitting IntOAM 415 packets to measure the indicated metrics and the shortest interval 416 that is it capable of receiving PM IntOAM packets. Suppose a system 417 does not support the given metric measurement, i.e., packet loss or 418 packet delay. In that case, it MUST set the value of the Required 419 Min RX Interval to zero when transmitting the IntOAM Control message 420 with the Capability TLV. If an IntOAM system does not support one of 421 the modes, periodic or on-demand, for the given performance metric, 422 it MUST zero the appropriate bit in the field that describes the 423 metric. The timer values apply to all PM modes that have their 424 respective bits set in the Capacity TLV. If an operator wants to use 425 a different time intervals for different performance metrics 426 measurements, then separate Poll sequences with the Capabilities TLV 427 included MAY be used. Thus IntOAM allows negotiating different time 428 intervals for packet loss and packet delay measurements. 430 5.2. Padding TLV 432 Padding TLV MAY be used to generate IntOAM Control messages of the 433 desired length. 435 0 1 2 3 436 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 437 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 438 | Padding | Reserved | Length | 439 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 440 | | 441 ~ Padding ~ 442 | | 443 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 445 Figure 4: Padding TLV Format 447 where fields are defined as the following: 449 o Padding - one-octet field. Its value (TBA1) allocated by IANA in 450 Section 6 452 o Reserved - one-octet field. MUST be zeroed on the transmit and 453 ignored on the receipt. 455 o Length - two-octet field equals length on the Padding TLV in 456 octets. The value of the Length field MUST be a multiple of 4. 458 o Padding - variable-length field. It MUST be zeroed on transmit 459 and ignored on receipt. 461 Padding TLV MAY be used to generate IntOAM Control messages of 462 different lengths. That capability is necessary to perform PMTUD, 463 PMTUM, and measure synthetic packet loss and/or packet delay. When 464 Padding TLV is used in combination with one of the performance 465 measurement messages carried in Performance Metric TLVs as defined in 466 Section 5.4, Padding TLV MUST follow the Performance Metric TLV. 468 Padding TLV MAY be used in PMTUM as part of periodically sent IntOAM 469 Control messages. In this case, the number of consecutive messages 470 that include Padding TLV MUST be not lesser than Detect Multiplier to 471 ensure that the remote IntOAM peer will detect loss of messages with 472 the Padding TLV. Also, Padding TLV MAY be present in an IntOAM 473 Control message with the Poll flag set. If the remote IntOAM peer 474 that supports this specification receives an IntOAM Control message 475 with Padding TLV, it MUST include the Padding TLV with the Padding 476 field of the same length as in the received packet and set the Final 477 flag. 479 5.3. Diagnostic TLV 481 Diagnostic TLV MAY be used to characterize the result of the last 482 requested operation. 484 0 1 2 3 485 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 486 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 487 | Diagnostic | Reserved | Length | 488 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 489 | Return Code | Reserved | 490 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 492 Figure 5: Diagnostic TLV Format 494 where fields are defined as the following: 496 o Diagnostic - one-octet field.Its value (TBA6) allocated by IANA in 497 Section 6. 499 o Reserved - one-octet field. MUST be zeroed on the transmit and 500 ignored on the receipt. 502 o Length - tw-octet field. Its value MUST be set to eight. 504 o Return Code - eight-bit field. The responding IntOAM system can 505 set it to one of the values defined in Section 6.3. 507 o Reserved - 24 bits-long field. MUST be zeroed on transmit and 508 ignored on receipt. 510 5.4. Performance Measurement with IntOAM Control Message 512 Loss measurement, delay measurement, and loss/delay measurement 513 messages can be used in the IntOAM Control message to obtain 514 respective one-way and round-trip metrics. All the messages are 515 encapsulated as TLVs with Type values allocated by IANA, Section 6. 517 The sender MAY use the Performance Metric TLV (presented in Figure 6) 518 to measure performance metrics and obtain the measurement report from 519 the receiver. 521 0 1 2 3 522 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 523 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 524 | Perf. Metric | Reserved | Length | 525 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 526 | Loss Measurement Message, | 527 ~ Delay Measurement Message, or ~ 528 | Combined Loss/Delay Measurement Message | 529 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 531 Figure 6: Performance Metric TLV Format 533 where fields are defined as the following: 535 o Performance Metric - one-octet field. Valid vaues are TBA3 536 through TBA5 allocated by IANA in Section 6 as follows: 538 * TBA3 - Loss Measurement Type; 540 * TBA4 - Delay Measurement Type; 542 * TBA5 - Combined Loss/Delay Measurement Type 544 o Reserved - one-octet field. MUST be zeroed on the transmit and 545 ignored on the receipt. 547 o Length - two-octet field equals length on the Performance Metric 548 TLV in octets. The value of the Length field MUST be a multiple 549 of 4. 551 o Value - various performance metrics measured either directly or 552 using synthetic methods accordingly using the messages defined in 553 Sections 3.1 through 3.3 [RFC6374]. 555 To perform one-way loss and/or delay measurement, the IntOAM node MAY 556 periodically transmit the IntOAM message with one of the TLVs listed 557 above in Asynchronous mode. To perform synthetic loss measurement, 558 the sender MUST monotonically increment the counter of transmitted 559 test packets. When using Performance Metric TLV for synthetic 560 measurement, an IntOAM Control message MAY also include Padding TLV. 561 In that case, the Padding TLV MUST immediately follow Performance 562 Metric TLV. Also, direct-mode loss measurement, as described in 563 [RFC6374], is supported. Procedures to negotiate and manipulate 564 transmission intervals defined in Sections 6.8.2 and 6.8.3 in 565 [RFC5880] SHOULD be used to control the performance impact of using 566 the IntOAM for performance measurement in the particular IntOAM 567 session. 569 To measure the round-trip loss and/or delay metrics, an IntOAM node 570 transmits the IntOAM Control message with the Performance Metric TLV 571 with the Poll flag set. Before transmitting the IntOAM Control 572 message with the Performance Metric TLV, the receiver MUST clear the 573 Poll flag and set the Final flag. 575 5.5. Lightweight Authentication 577 Using IntOAM without any security measures, such as exchanging IntOAM 578 Control messages without authentication, increases the risk of an 579 attack, especially over multiple nodes. Thus, using IntOAM without 580 security measures may cause false positive or false negative defect 581 detection situations. In the former, an attacker may spoof IntOAM 582 Control messages pretending to be a remote peer and can thus view the 583 IntOAM session operation even though the real path had failed. In 584 the latter, the attacker may spoof an altered IntOAM control message 585 indicating that the IntOAM session is un-operational even though the 586 path and the remote IntOAM peer operate normally. 588 BFD [RFC5880] allows for optional authentication protection of BFD 589 Control messages to minimize the chances of attacks in a networking 590 system. However, at least some of the supported authentication 591 protocols do not provide sufficient protection in modern networks. 592 Also, the current BFD technology requires authentication of each BFD 593 Control message. Such an authentication requirement can put a 594 computational burden on networking devices, especially in the 595 Asynchronous mode, at least because authenticating each BFD Control 596 message can require substantial computing resources to support packet 597 exchange at high rates. 599 This specification defines a lightweight on-demand mode of 600 authentication for an IntOAM session. The lightweight authentication 601 is an optional mode. The mechanism includes negotiation 602 (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 o 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 o 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 o 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 o Lightweight Authentication - one-octet field.It value (TBA8) 679 allocated by IANA in Section 6 681 o Reserved - one-octet field. MUST be zeroed on the transmit and 682 ignored on the receipt. 684 o 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 o 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 | 1- 175 | Unassigned | This document | 727 | 176 - 239 | Unassigned | This document | 728 | 240 - 251 | Experimental | This document | 729 | 252 - 254 | Private Use | This document | 730 | 255 | Reserved | This document | 731 +-----------+--------------+---------------+ 733 Table 1: IntOAM Type Registry 735 This document defines the following new values in IntOAM Type 736 registry: 738 +-------+---------------------------------+---------------+ 739 | Value | Description | Reference | 740 +-------+---------------------------------+---------------+ 741 | TBA0 | Multiple TLVs Used | This document | 742 | TBA1 | Padding | This document | 743 | TBA2 | Capability | This document | 744 | TBA3 | Loss Measurement | This document | 745 | TBA4 | Delay Measurement | This document | 746 | TBA5 | Combined Loss/Delay Measurement | This document | 747 | TBA6 | Diagnostic | This document | 748 | TBA8 | Lightweight Authentication | This document | 749 +-------+---------------------------------+---------------+ 751 Table 2: IntOAM Types 753 6.2. Lightweight Authentication Modes 755 IANA is requested to create a Lightweight Authentication Modes 756 registry. All code points in this registry shall be allocated 757 according to the "IETF Review" procedure as specified in [RFC8126]. 759 This document defines the following new values in the Lightweight 760 Authentication Modes registry: 762 +--------------+-------+------------------------+---------------+ 763 | Bit Position | Value | Description | Reference | 764 +--------------+-------+------------------------+---------------+ 765 | 0 | 0x1 | Keyed SHA-1 | This document | 766 | 1 | 0x2 | Meticulous Keyed SHA-1 | This document | 767 | 2 | 0x4 | SHA-256 | This document | 768 +--------------+-------+------------------------+---------------+ 770 Table 3: Lightweight Authentication Modes 772 6.3. Return Codes 774 IANA is requested to create the IntOAM Return Codes registry. All 775 code points in the range 1 through 250 in this registry shall be 776 allocated according to the "IETF Review" procedure as specified in 777 [RFC8126]. The remaining code points are allocated according to 778 Table 4: 780 +---------+--------------+---------------+ 781 | Value | Description | Reference | 782 +---------+--------------+---------------+ 783 | 0 | Reserved | This document | 784 | 1- 250 | Unassigned | IETF Review | 785 | 251-253 | Experimental | This document | 786 | 254 | Private Use | This document | 787 | 255 | Reserved | This document | 788 +---------+--------------+---------------+ 790 Table 4: IntOAM Return Codes Registry 792 This document defines the following new values in IntOAM Return Codes 793 registry: 795 +-------+-------------------------------------+---------------+ 796 | Value | Description | Reference | 797 +-------+-------------------------------------+---------------+ 798 | 0 | None | This document | 799 | 1 | One or more TLVs was not understood | This document | 800 | 2 | Lightweight Authentication failed | This document | 801 +-------+-------------------------------------+---------------+ 803 Table 5: IntOAM Return Codes 805 7. Security Considerations 807 The same security considerations as those described in [RFC5880], 808 [RFC6374], and [RFC8562]. apply to this document. Additionally, 809 implementations that use distribution of discriminators over the 810 control or management plane MUST use secure channels to protect 811 systems from an infinite number of IntOAM sessions being created. 813 In some environments, an IntoOAM session can be instantiated using a 814 bootstrapping mechanism supported by the control or management plane. 815 As a result, the three-way handshaking mechanism between IntOAM 816 systems is bypassed. That could cause the situation where one of the 817 systems uses overaggressive transmission intervals that are not 818 acceptable to the remote IntOAM system. As a result, IntOAM Control 819 messages could be dropped, and the remote IntOAM system concludes the 820 IntOAM session failed. The environment that does not use the three- 821 way handshake mechanism to instantiate an IntOAM session MUST support 822 means to balance resources used by the IntOAM. 824 8. Acknowledgements 826 TBD 828 9. References 830 9.1. Normative References 832 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 833 Requirement Levels", BCP 14, RFC 2119, 834 DOI 10.17487/RFC2119, March 1997, 835 . 837 [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 838 (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010, 839 . 841 [RFC6374] Frost, D. and S. Bryant, "Packet Loss and Delay 842 Measurement for MPLS Networks", RFC 6374, 843 DOI 10.17487/RFC6374, September 2011, 844 . 846 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 847 Writing an IANA Considerations Section in RFCs", BCP 26, 848 RFC 8126, DOI 10.17487/RFC8126, June 2017, 849 . 851 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 852 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 853 May 2017, . 855 [RFC8562] Katz, D., Ward, D., Pallagatti, S., Ed., and G. Mirsky, 856 Ed., "Bidirectional Forwarding Detection (BFD) for 857 Multipoint Networks", RFC 8562, DOI 10.17487/RFC8562, 858 April 2019, . 860 9.2. Informative References 862 [RFC8655] Finn, N., Thubert, P., Varga, B., and J. Farkas, 863 "Deterministic Networking Architecture", RFC 8655, 864 DOI 10.17487/RFC8655, October 2019, 865 . 867 Authors' Addresses 869 Greg Mirsky 870 ZTE Corp. 872 Email: gregimirsky@gmail.com 874 Xiao Min 875 ZTE Corp. 877 Email: xiao.min2@zte.com.cn 879 Gyan Mishra 880 Verizon Inc. 882 Email: gyan.s.mishra@verizon.com