idnits 2.17.1 draft-mirmin-bfd-extended-02.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 (October 10, 2019) is 1660 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 BFD Working Group G. Mirsky 3 Internet-Draft X. Min 4 Intended status: Standards Track ZTE Corp. 5 Expires: April 12, 2020 October 10, 2019 7 Extended Bidirectional Forwarding Detection 8 draft-mirmin-bfd-extended-02 10 Abstract 12 This document describes a mechanism to extend the capabilities of 13 Bidirectional Forwarding Detection (BFD). These extensions enable 14 BFD to measure performance metrics like packet loss and packet delay. 15 Also, a method to perform lightweight on-demand authentication is 16 defined in this specification. 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at https://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on April 12, 2020. 35 Copyright Notice 37 Copyright (c) 2019 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (https://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 53 2. Conventions used in this document . . . . . . . . . . . . . . 3 54 2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 55 2.2. Requirements Language . . . . . . . . . . . . . . . . . . 3 56 3. Extended BFD Control Message . . . . . . . . . . . . . . . . 3 57 3.1. Extended BFD Capability Negotiation . . . . . . . . . . . 5 58 3.2. Padding TLV . . . . . . . . . . . . . . . . . . . . . . . 6 59 3.3. Diagnostic TLV . . . . . . . . . . . . . . . . . . . . . 7 60 3.4. Performance Measurement with Extended BFD Control Message 8 61 3.5. Lightweight Authentication . . . . . . . . . . . . . . . 9 62 3.5.1. Lightweight Authentication Mode Negotiation . . . . . 10 63 3.5.2. Using Lightweight Authentication . . . . . . . . . . 11 64 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 65 4.1. Extended BFD Message Types . . . . . . . . . . . . . . . 12 66 4.2. Lightweight Authentication Modes . . . . . . . . . . . . 13 67 4.3. Return Codes . . . . . . . . . . . . . . . . . . . . . . 14 68 5. Security Considerations . . . . . . . . . . . . . . . . . . . 14 69 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 70 6.1. Normative References . . . . . . . . . . . . . . . . . . 15 71 6.2. Informative References . . . . . . . . . . . . . . . . . 15 72 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 15 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 75 1. Introduction 77 [RFC5880] has provided the base specification of Bidirectional 78 Detection (BFD) as the light-weight mechanism to monitor a path 79 continuity between two systems and detect a failure in the data- 80 plane. Since its introduction, BFD has been broadly deployed. There 81 were several attempts to introduce new capabilities in the protocol, 82 some more successful than others. One of the significant obstacles 83 to extending BFD capabilities may be seen in the compact format of 84 the BFD control message. This document introduces an Extended BFD 85 control message and describes the use of the new format for new BFD 86 capabilities. 88 The Extended BFD protocol may be seen as the Operations, 89 Administration, and Maintenance (OAM) protocol that provides both 90 Fault Management (FM) Performance Monitoring (PM) OAM functions. In 91 some networks, for example in a Deterministic Networking (DetNet) 92 domain [I-D.ietf-detnet-architecture], it is easier to ensure that a 93 test packet of a single OAM protocol is fate-sharing with data 94 packets rather than map several FM amd PM OAM protocols to that 95 DetNet data flow. 97 2. Conventions used in this document 99 2.1. Terminology 101 BFD: Bidirectional Forwarding Detection 103 G-ACh Generic Associated Channel 105 HMAC Hashed Message Authentication Code 107 MTU Maximum Transmission Unit 109 PMTUD Path MTU Discovery 111 PMTUM Path MTU Monitoring 113 p2p: Point-to-Point 115 TLV Type, Length, Value 117 OAM Operations, Administration, and Maintenance 119 FM Fault Management 121 PM Performance Monitoring 123 DetNet Deterministic Networking 125 2.2. Requirements Language 127 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 128 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 129 "OPTIONAL" in this document are to be interpreted as described in BCP 130 14 [RFC2119] [RFC8174] when, and only when, they appear in all 131 capitals, as shown here. 133 3. Extended BFD Control Message 134 0 1 2 3 135 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 136 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 137 | | 138 | BFD Control Message | 139 | | 140 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 141 | Guard Word | 142 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 143 | | 144 ~ TLVs ~ 145 | | 146 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 148 Figure 1: Extended BFD Control Message Format 150 where fields are defined as the following: 152 o BFD control message as defined [RFC5880]. 154 o Guard word - four octets long field to identify the role of the 155 BFD system - sender or responder. 157 o TLVs - variable-length field that contains commands and/or data 158 encoded as type-length-value (TLV). 160 If an Extended BFD control message is encapsulated in IP/UDP, the 161 value of the Total Length in the IP header includes the length of the 162 Extended BFD control message while the value of the Length field of 163 the BFD control message equals the value as defined in [RFC5880]. If 164 an Extended BFD control message is to be used over Generic Associated 165 Channel (G-ACh), e.g., [RFC6428] new code point for G-ACh may be 166 allocated. 168 Figure 2 displays the generic TLV format. 170 0 1 2 3 171 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 172 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 173 | Type | Length | 174 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 175 ~ Value ~ 176 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 178 Figure 2: General Type-Length-Value Encoding 180 where fields are defined as the following: 182 o Type - two octets long field that defines the encoding of the 183 Value field 185 o Length - two octets long field equals length on the Value field in 186 octets. 188 o Value - depends on the Type. 190 TLVs may be included within other TLVs, in which case the former TLVs 191 are referred to as sub-TLVs. Sub-TLVs have independent types. 193 3.1. Extended BFD Capability Negotiation 195 A BFD system also referred to as a node in this document, that 196 supports Extended BFD first MUST discover whether other nodes in the 197 given BFD session support the Extended BFD. The node MUST send 198 Extended BFD control message initiating the Poll Sequence as defined 199 in [RFC5880]. If the remote system fails to respond with the 200 Extended BFD control message and the Final flag set, then the 201 initiator node MUST conclude that the BFD peer does not support the 202 use of the Extended BFD control messages. 204 The first Extended BFD control message initiating the Poll Sequence 205 SHOULD include the Capability TLV that lists capabilities that may be 206 used at some time during the lifetime of the BFD session. The format 207 of the Capability TLV and the capabilities that use the Extended BFD 208 control message are presented in Figure 3. 210 0 1 2 3 211 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 212 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 213 | Type = Capability | Length | 214 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 215 | L | D | M | Authentication ... | Reserved ... 216 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 218 Figure 3: Capability TLV Format 220 where fields are defined as the following: 222 o Type - TBA1 allocated by IANA in Section 4 224 o Length - two octets long field equals length on the Capability 225 field in octets. The value of the Length field MUST be a multiple 226 of 4. 228 o Loss - two bits size field. The least significant of two bits is 229 set if the node is capable of measuring packet loss using 230 periodically transmitted Extended BFD control message. The most 231 significant of two bits is set if the node is capable of measuring 232 packet loss using the Poll Sequence with Extended BFD control 233 message. 235 o Delay - two bits size field. The least significant of two bits is 236 set if the node is capable of measuring packet delay using 237 periodically transmitted Extended BFD control message. The most 238 significant of two bits is set if the node is capable of measuring 239 packet delay using the Poll Sequence with Extended BFD control 240 message. 242 o MTU - two bits size field. Set if the node is capable of using 243 the Extended BFD control message in Path MTU Discovery (PMTUD). 244 or PMTU Monitoring (PMTUM). The least significant of two bits is 245 set if the node is capable of PMTUD/PMTUM using periodically 246 transmitted Extended BFD control message. The most significant of 247 two bits is set if the node is capable of PMTUD/PMTUM using the 248 Poll Sequence with Extended BFD control message. 250 o (Lightweight) Authentication - variable-length field. The 251 Authentication field is used by a BFD system to advertise its 252 lightweight authentication capabilities. The format and the use 253 of the Authentication field are defined in Section 3.5.1. 255 o Reserved - MUST be zeroed on transmission and ignored on receipt. 256 The Reserved field is zero-padded to align the length of the 257 Capability TLV to a 4-octet boundary. 259 The remote BFD node that supports this specification MUST respond to 260 the Capability TLV with the Extended BFD control message that 261 includes the Capability TLV listing capabilities the responder 262 supports. The responder MUST set the Final flag in the Extended BFD 263 control message. 265 3.2. Padding TLV 267 Padding TLV MAY be used to generate Extended BFD control packets of 268 the desired length. 270 0 1 2 3 271 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 272 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 273 | Type = Padding | Length | 274 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 275 | | 276 ~ Padding ~ 277 | | 278 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 280 Figure 4: Padding TLV Format 282 where fields are defined as the following: 284 o Type - TBA1 allocated by IANA in Section 4 286 o Length - two octets long field equals length on the Padding field 287 in octets. 289 o Padding - variable-length field. MUST be zeroed on transmit and 290 ignored on receipt. 292 Padding TLV MAY be used to generate Extended BFD Control packets of 293 different lengths. That capability is necessary to perform PMTUD, 294 PMTUM, and measure synthetic packet loss and/or packet delay. When 295 Padding TLV is used in combination with one of performance 296 measurement messages carried in Performance Metric TLVs as defined in 297 Section 3.4, Padding TLV MUST follow the Performance Metric TLV. 299 Padding TLV MAY be used in PMTUM as part of periodically sent 300 Extended BFD Control messages. In this case, the number of 301 consecuitive messages that include Padding TLV MUST be not lesser 302 than Detect Multiplier to ensure that the remote BFD peer will detect 303 loss of messages with the Padding TLV. Also, Padding TLV MAY be 304 present in an Extended BFD Control message with the Poll flag set. 305 If the remote BFD peer that supports this specification receives an 306 Extended BFD Control message with Padding TLV, it MUST include the 307 Padding TLV with the Padding field of the same length as in the 308 received packet and set the Final flag. 310 3.3. Diagnostic TLV 312 Diagnostic TLV MAY be used to characterize the result of the last 313 requested operation. 315 0 1 2 3 316 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 317 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 318 | Type = Diagnostic | Length | 319 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 320 | Return Code | Reserved | 321 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 323 Figure 5: Diagnostic TLV Format 325 where fields are defined as the following: 327 o Type - TBA6 allocated by IANA in Section 4. 329 o Length - MUST be set to four. 331 o Return Code - eight bits-long field. The responding BFD system 332 can set it to one of the values defined in Section 4.3. 334 o Reserved - 24 bits-long field. MUST be zeroed on transmit and 335 ignored on receipt. 337 3.4. Performance Measurement with Extended BFD Control Message 339 Loss measurement, delay measurement, and loss/delay measurement 340 messages can be used in the Extended BFD control message to support 341 one-way and round-trip measurements. All the messages are 342 encapsulated as TLVs with Type values allocated by IANA, Section 4. 344 The sender MAY use the Performance Metric TLV (presented in Figure 6) 345 to measure performance metrics and obtain the measurement report from 346 the receiver. 348 0 1 2 3 349 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 350 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 351 | Type = Performance Metric | Length | 352 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 353 | Loss Measurement Message, | 354 ~ Delay Measurement Mesage, or ~ 355 | Combined Loss/Delay Measurement Message | 356 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 358 Figure 6: Performance Metric TLV Format 360 where fields are defined as the following: 362 o Type - TBA3 through TBA5 allocated by IANA in Section 4 as 363 follows: 365 * TBA3 - Loss Measurement Type; 367 * TBA4 - Delay Measurement Type; 369 * TBA5 - Combined Loss/Delay Measurement Type 371 o Length - two octets long field equals length on the Metric sub- 372 TLVs field in octets. The value of the Length field MUST be a 373 multiple of 4. 375 o Value - various performance metrics measured either directly or 376 using synthetic methods accordingly using the messages defined in 377 Sections 3.1 through 3.3 [RFC6374]. 379 To perform one-way loss and/or delay measurement, the BFD node MAY 380 periodically transmit the Extended BFD message with one of the TLVs 381 listed above in Asynchronous mode. To perform synthetic loss 382 measurement, the sender MUST monotonically increment the counter of 383 transmitted test packets. When using Performance Metric TLV for 384 synthetic measurement an Extended BFD Control message MAY also 385 include Padding TLV. In that case, the Padding TLV MUST immediately 386 follow Performance Metric TLV. Also, direct-mode loss measurement, 387 as described in [RFC6374], is supported. Procedures to negotiate and 388 manipulate transmission intervals defined in Sections 6.8.2 and 6.8.3 389 in [RFC5880] SHOULD be used to control the performance impact of 390 using the Extended BFD for performance measurement in the particular 391 BFD session. 393 To measure the round-trip loss and/or delay metrics the BFD node 394 transmits the Extended BFD control message with the Performance 395 Metric TLV with the Poll flag set. Before the transmission of the 396 Extended BFD control message with the Performance Metric TLV, the 397 receiver MUST clear the Poll flag and set the Final flag. 399 3.5. Lightweight Authentication 401 Using BFD without any security measures, for example, by exchanging 402 BFD control packets without authentication, increases the risk of an 403 attack, especially over multiple nodes. Thus, using BFD without 404 security measures may cause false positive as well as false negative 405 defect detection situations. In the former, an attacker may spoof 406 BFD control packets pretending to be a remote peer and can thus view 407 the BFD session operation even though the real path had failed. In 408 the latter, the attacker may spoof altered BFD control message 409 indicating that the BFD session is un-operational even though the 410 path and the remote BFD peer operate normally. 412 BFD technology[RFC5880] includes optional authentication protection 413 of BFD control packets to minimize the chances of attacks in a 414 networking system. However, at least some of the supported 415 authentication protocols do not provide sufficient protection in 416 modern networks. Also, current BFD technology requires 417 authentication of each and every BFD control packet. Such an 418 authentication requirement can put a computational burden on 419 networking devices, especially in the Asynchronous mode, at least 420 because authenticating each BFD control packet can require 421 substantial computing resources to support packet exchange at high 422 rates. 424 This specification defines a lightweight on-demand mode of 425 authentication for a BFD session. The lightweight authentication is 426 an optional mode that can be used when the BFD Authentication 427 [RFC5880] is not in use (bfd.AuthType is zero). The mechanism 428 includes negotiation (Section 3.5.1) and on-demand authentication 429 (Section 3.5.2) phases. During the former, BFD peers advertise 430 supported authentication capabilities and independently select the 431 commonly supported mode of the authentication. In the authentication 432 phase, each BFD system transmits, at certain events and periodically, 433 authenticated BFD control packets in Poll Sequence. 435 3.5.1. Lightweight Authentication Mode Negotiation 437 Figure 7 displays the format of the Authentication field that is part 438 of the Capability Encoding: 440 0 1 2 3 441 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 442 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 443 | Len | AuthL | Authentication Mode ... 444 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 446 Figure 7: Lightweight Authentication Capability Field Format 448 where fields are defined as the following: 450 o Len (Length) - four-bits long field. The value of the Length 451 field is equal to the length of the Authentication field, 452 including the Length, in octets. 454 o AuthL (Authentication Length) - four bits size field. The value 455 of the field is, in four octets long words, the longest 456 authentication signature the BFD system is capable of supporting 457 for any of the methods advertised in the AuthMode field. 459 o Authentication Mode - variable-length field. It is a bit-coded 460 field that a BFD system uses to list modes of lightweight 461 authentication it supports. 463 A BFD system uses Capability TLV, defined in Section 3.1, to discover 464 the commonly supported mode of the Lightweight Authentication. The 465 system sets the values in the Authentication field according to 466 properly reflect its authentication capabilities. The BFD system 467 transmits the Extended BFD control packet with Capability TLV as the 468 first in a Poll Sequence. The remote BFD system that supports this 469 specification receives the Extended BFD control packet with the 470 advertised Lightweight Authentication modes and stores information 471 locally. The system responds with the advertisement of its 472 Lightweight Authentication capabilities in the Extended BFD control 473 packet with the Final flag set. Each BFD system uses local and 474 received information about Lightweight Authentication capabilities to 475 deduce the commonly supported modes and selects from that set the one 476 that uses the strongest authentication with the longest signature. 477 If the common set is empty, i.e., none of supported by one BFD system 478 authentication method is supported by another, an implementation MUST 479 reflect this in its operational state and SHOULD notify an operator. 481 3.5.2. Using Lightweight Authentication 483 After BFD peers select an authentication mode for using in 484 Lightweight Authentication each BFD system MUST use it to 485 authenticate each Extended BFD control packet transmitted as part of 486 a Poll Sequence using Lightweight Authentication TLV presented in 487 Figure 8. 489 0 1 2 3 490 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 491 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 492 |Type=Lightweight Authentication| Length | 493 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 494 | | 495 ~ HMAC ~ 496 | | 497 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 499 Figure 8: Lightweight Authentication TLV Format 501 where fields are defined as the following: 503 o Type - TBA8 allocated by IANA in Section 4 504 o Length - two octets long field equals length on the HMAC (Hashed 505 Message Authentication Code) field in octets. The value of the 506 Length field MUST be a multiple of 4. 508 o HMAC - the hash value calculated on the entire preceding Extended 509 BFD control packet data. 511 The Lightweight Authentication TLV MUST be the last TLV in an 512 Extended BFD control packet. Padding TLV (Section 3.2) MAY be used 513 to align the length of the Extended BFD control packet, excluding the 514 Lightweight Authentication TLV, at multiple of 16 boundary. 516 The BFD system that receives the Extended BFD control packet with the 517 Lightweight Authentication TLV MUST first validate the 518 .authentication by calculating the hash over the Extended BFD control 519 packet. If the validation succeeds, the receiver MUST transmit the 520 Extended BFD control packet with the Final flag set and the value of 521 the Return code field in Diagnostic TLV set to None value (Table 5). 522 If the validation of the lightweight authentication fails, then the 523 BFD system MUST transmit the Extended BFD control packet with the 524 Final flag set and the value of the Return Code field of the 525 Diagnostic TLV set to Lightweight Authentication failed value 526 (Table 5). The BFD system MUST have a control policy that defines 527 actions when the system receives the Lightweight Authentication 528 failed return code. 530 4. IANA Considerations 532 4.1. Extended BFD Message Types 534 IANA is requested to create the Extended BFD Message Types registry. 535 All code points in the range 1 through 32759 in this registry shall 536 be allocated according to the "IETF Review" procedure as specified in 537 [RFC8126]. Code points in the range 32760 through 65279 in this 538 registry shall be allocated according to the "First Come First 539 Served" procedure as specified in [RFC8126]. Remaining code points 540 are allocated according to Table 1: 542 +---------------+-------------------------+-------------------------+ 543 | Value | Description | Reference | 544 +---------------+-------------------------+-------------------------+ 545 | 0 | Reserved | This document | 546 | 1- 32767 | Mandatory TLV, | IETF Review | 547 | | unassigned | | 548 | 32768 - 65279 | Optional TLV, | First Come First Served | 549 | | unassigned | | 550 | 65280 - 65519 | Experimental | This document | 551 | 65520 - 65534 | Private Use | This document | 552 | 65535 | Reserved | This document | 553 +---------------+-------------------------+-------------------------+ 555 Table 1: Extended BFD Type Registry 557 This document defines the following new values in Extended BFD Type 558 registry: 560 +-------+---------------------------------+---------------+ 561 | Value | Description | Reference | 562 +-------+---------------------------------+---------------+ 563 | TBA1 | Padding | This document | 564 | TBA2 | Capability | This document | 565 | TBA3 | Loss Measurement | This document | 566 | TBA4 | Delay Measurement | This document | 567 | TBA5 | Combined Loss/Delay Measurement | This document | 568 | TBA6 | Diagnostic | This document | 569 | TBA8 | Lightweight Authentication | This document | 570 +-------+---------------------------------+---------------+ 572 Table 2: Extended BFD Types 574 4.2. Lightweight Authentication Modes 576 IANA is requested to create a Lightweight Authentication Modes 577 registry. All code points in this registry shall be allocated 578 according to the "IETF Review" procedure as specified in [RFC8126]. 580 This document defines the following new values in the Lightweight 581 Authentication Modes registry: 583 +--------------+-------+------------------------+---------------+ 584 | Bit Position | Value | Description | Reference | 585 +--------------+-------+------------------------+---------------+ 586 | 0 | 0x1 | Keyed SHA-1 | This document | 587 | 1 | 0x2 | Meticulous Keyed SHA-1 | This document | 588 | 2 | 0x4 | SHA-256 | This document | 589 +--------------+-------+------------------------+---------------+ 591 Table 3: Lightweight Authentication Modes 593 4.3. Return Codes 595 IANA is requested to create the Extended BFD Return Codes registry. 596 All code points in the range 1 through 250 in this registry shall be 597 allocated according to the "IETF Review" procedure as specified in 598 [RFC8126]. Remaining code points are allocated according to Table 4: 600 +---------+--------------+---------------+ 601 | Value | Description | Reference | 602 +---------+--------------+---------------+ 603 | 0 | Reserved | This document | 604 | 1- 250 | Unassigned | IETF Review | 605 | 251-253 | Experimental | This document | 606 | 254 | Private Use | This document | 607 | 255 | Reserved | This document | 608 +---------+--------------+---------------+ 610 Table 4: Extended BFD Return Codes Registry 612 This document defines the following new values in Extended BFD Return 613 Codes registry: 615 +-------+-------------------------------------+---------------+ 616 | Value | Description | Reference | 617 +-------+-------------------------------------+---------------+ 618 | 0 | None | This document | 619 | 1 | One or more TLVs was not understood | This document | 620 | 2 | Lightweight Authentication failed | This document | 621 +-------+-------------------------------------+---------------+ 623 Table 5: Extended BFD Return Codes 625 5. Security Considerations 627 This document does not introduce new security aspects but inherits 628 all security considerations from [RFC5880], [RFC6428], and [RFC6374]. 630 6. References 632 6.1. Normative References 634 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 635 Requirement Levels", BCP 14, RFC 2119, 636 DOI 10.17487/RFC2119, March 1997, 637 . 639 [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 640 (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010, 641 . 643 [RFC6374] Frost, D. and S. Bryant, "Packet Loss and Delay 644 Measurement for MPLS Networks", RFC 6374, 645 DOI 10.17487/RFC6374, September 2011, 646 . 648 [RFC6428] Allan, D., Ed., Swallow, G., Ed., and J. Drake, Ed., 649 "Proactive Connectivity Verification, Continuity Check, 650 and Remote Defect Indication for the MPLS Transport 651 Profile", RFC 6428, DOI 10.17487/RFC6428, November 2011, 652 . 654 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 655 Writing an IANA Considerations Section in RFCs", BCP 26, 656 RFC 8126, DOI 10.17487/RFC8126, June 2017, 657 . 659 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 660 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 661 May 2017, . 663 6.2. Informative References 665 [I-D.ietf-detnet-architecture] 666 Finn, N., Thubert, P., Varga, B., and J. Farkas, 667 "Deterministic Networking Architecture", draft-ietf- 668 detnet-architecture-13 (work in progress), May 2019. 670 Appendix A. Acknowledgements 672 TBD 674 Authors' Addresses 676 Greg Mirsky 677 ZTE Corp. 679 Email: gregimirsky@gmail.com 681 Xiao Min 682 ZTE Corp. 684 Email: xiao.min2@zte.com.cn