idnits 2.17.1 draft-ietf-sfc-multi-layer-oam-10.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 : ---------------------------------------------------------------------------- ** There are 6 instances of too long lines in the document, the longest one being 28 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (30 March 2021) is 1116 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) == Outdated reference: A later version (-09) exists of draft-ietf-sfc-nsh-integrity-05 Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SFC WG G. Mirsky 3 Internet-Draft ZTE Corp. 4 Updates: 8300 (if approved) W. Meng 5 Intended status: Standards Track ZTE Corporation 6 Expires: 1 October 2021 B. Khasnabish 7 C. Wang 8 Individual contributor 9 30 March 2021 11 Active OAM for Service Function Chaining 12 draft-ietf-sfc-multi-layer-oam-10 14 Abstract 16 A set of requirements for active Operation, Administration, and 17 Maintenance (OAM) of Service Function Chains (SFCs) in a network is 18 presented in this document. Based on these requirements, an 19 encapsulation of active OAM messages in SFC and a mechanism to detect 20 and localize defects are described. 22 This document updates RFC 8300 in the definition of O (OAM) bit in 23 the Network Service Header (NSH) and defines how an active OAM 24 message is identified in the NSH. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at https://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on 1 October 2021. 43 Copyright Notice 45 Copyright (c) 2021 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 50 license-info) in effect on the date of publication of this document. 51 Please review these documents carefully, as they describe your rights 52 and restrictions with respect to this document. Code Components 53 extracted from this document must include Simplified BSD License text 54 as described in Section 4.e of the Trust Legal Provisions and are 55 provided without warranty as described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 2. Terminology and Conventions . . . . . . . . . . . . . . . . . 3 61 2.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 62 2.2. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . 4 63 3. Requirements for Active OAM in SFC Network . . . . . . . . . 4 64 4. Active OAM Identification in SFC NSH . . . . . . . . . . . . 6 65 5. Echo Request/Echo Reply for SFC . . . . . . . . . . . . . . . 8 66 5.1. Return Codes . . . . . . . . . . . . . . . . . . . . . . 10 67 5.2. Authentication in Echo Request/Reply . . . . . . . . . . 11 68 5.3. SFC Echo Request Transmission . . . . . . . . . . . . . . 11 69 5.4. SFC Echo Request Reception . . . . . . . . . . . . . . . 12 70 5.4.1. Errored TLVs TLV . . . . . . . . . . . . . . . . . . 12 71 5.5. SFC Echo Reply Transmission . . . . . . . . . . . . . . . 13 72 5.6. SFC Echo Reply Reception . . . . . . . . . . . . . . . . 14 73 6. Security Considerations . . . . . . . . . . . . . . . . . . . 14 74 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15 75 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 76 8.1. SFC Active OAM Protocol . . . . . . . . . . . . . . . . . 15 77 8.2. SFC Active OAM Message Type . . . . . . . . . . . . . . . 16 78 8.3. SFC Echo Request/Echo Reply Parameters . . . . . . . . . 16 79 8.4. SFC Echo Request/Echo Reply Message Types . . . . . . . . 16 80 8.5. SFC Echo Reply Modes . . . . . . . . . . . . . . . . . . 17 81 8.6. SFC Echo Return Codes . . . . . . . . . . . . . . . . . . 19 82 8.7. SFC TLV Type . . . . . . . . . . . . . . . . . . . . . . 19 83 8.8. SFC OAM UDP Port . . . . . . . . . . . . . . . . . . . . 20 84 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 85 9.1. Normative References . . . . . . . . . . . . . . . . . . 21 86 9.2. Informative References . . . . . . . . . . . . . . . . . 21 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 89 1. Introduction 91 [RFC7665] defines components necessary to implement a Service 92 Function Chain (SFC). These include: 94 1. a classifier that performs the classification of incoming packets 95 2. Service Function Forwarders (SFFs) that are responsible for 96 forwarding traffic to one or more connected Service Functions 97 (SFs) according to the information carried in the SFC service 98 encapsulation and handling traffic coming back from the SF and 99 forwarding it to the next SFF. 101 3. SFs that are responsible for the executing specific service 102 treatment on received packets. 104 There are different views from different levels of the SFC. One is 105 the SFC, an entirely abstract view, which defines an ordered set of 106 SFs that must be applied to packets selected based on classification 107 rules. But service function chain doesn't specify the exact mapping 108 between SFFs and SFs. Thus, another logical construct used in SFC is 109 a Service Function Path (SFP). According to [RFC7665], SFP is the 110 instantiation of the SFC in the network and provides a level of 111 indirection between the entirely abstract SFCs and a fully specified 112 ordered list of SFFs and SFs identities that the packet will visit 113 when it traverses the SFC. The latter entity is referred to as 114 Rendered Service Path (RSP). The main difference between SFP and RSP 115 is that the former is the logical construct, while the latter is the 116 realization of the SFP via the sequence of specific SFC elements. 118 This document defines how active Operation, Administration and 119 Maintenance (OAM), per [RFC7799] definition of active OAM, is 120 identified in Network Service Header (NSH) SFC. Following the 121 analysis of SFC OAM in [RFC8924], this document lists requirements to 122 improve troubleshooting efficiency and defect localization in SFP. 123 For that purpose, SFC Echo Request and Echo Reply are specified in 124 the document. This mechanism enables on-demand Continuity Check, 125 Connectivity Verification among other operations over SFC in 126 networks, thus providing one of the most common SFC OAM functions 127 identified in [RFC8924]. Also, this document updates Section 2.2 of 128 [RFC8300] in part of the definition of O bit in the (NSH). 130 2. Terminology and Conventions 132 The terminology defined in [RFC7665] is used extensively throughout 133 this document. A reader is expected to be familiar with it. 135 In this document, SFC OAM refers to an active OAM, as defined in 136 [RFC7799]. in an SFC architecture. 138 2.1. Requirements Language 140 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 141 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 142 "OPTIONAL" in this document are to be interpreted as described in BCP 143 14 [RFC2119] [RFC8174] when, and only when, they appear in all 144 capitals, as shown here. 146 2.2. Acronyms 148 E2E: End-to-End 150 FM: Fault Management 152 NSH: Network Service Header 154 OAM: Operations, Administration, and Maintenance 156 PRNG: Pseudorandom number generator 158 RDI: Remote Defect Indication 160 RSP: Rendered Service Path 162 SMI Structure of Management Information 164 SF: Service Function 166 SFC: Service Function Chain 168 SFF: Service Function Forwarder 170 SFP: Service Function Path 172 MAC: Message Authentication Code 174 3. Requirements for Active OAM in SFC Network 176 As discussed in [RFC8924], SFC-specific means are needed to perform 177 the OAM task of fault management (FM) in an SFC architecture, 178 including failure detection, defect characterization, and 179 localization. This document defines the set of requirements for 180 active FM OAM mechanisms to be used in an SFC architecture. 182 +---+ +---+ +---+ +---+ +---+ +---+ 183 |SF1| |SF2| |SF3| |SF4| |SF5| |SF6| 184 +---+ +---+ +---+ +---+ +---+ +---+ 185 \ / \ / \ / 186 +----------+ +----+ +----+ +----+ 187 |Classifier|-------|SFF1|---------|SFF2|--------|SFF3| 188 +----------+ +----+ +----+ +----+ 190 Figure 1: SFC Data Plane Reference Model 192 Regarding the reference model depicted in Figure 1, consider a 193 service function chain that includes three distinct service 194 functions. In this example, the SFP traverses SFF1, SFF2, and SFF3, 195 each SFF being connected to two instances of the same service 196 function. End-to-end (e2e) SFC OAM, in this example, has the 197 Classifier as the ingress of the SFC OAM domain, and SFF3 - as its 198 egress. Segment SFC OAM is always within the E2E SFC OAM domain 199 between two elements that are part of the same SFP. Following are 200 the requirements for an FM SFC OAM, whether with the E2E or segment 201 scope: 203 REQ#1: Packets of active SFC OAM in SFC SHOULD be fate sharing 204 with the monitored SFC data, in the forward direction from ingress 205 toward egress endpoint(s) of the OAM test. 207 The fate sharing, in the SFC environment, is achieved when a test 208 packet traverses the same path and receives the same treatment in the 209 transport layer as an SFC NSH packet. 211 REQ#2: SFC OAM MUST support pro-active monitoring of the 212 continuity of the SFP between any of its elements. 214 A network failure might be declared when several consecutive test 215 packets are not received within a pre-determined time. For example, 216 in the E2E SFC OAM FM case, the egress, SFF3, in the example in 217 Figure 1, could be the entity that detects the SFP's failure by 218 monitoring a flow of periodic test packets. The ingress may be 219 capable of recovering from the failure, e.g., using redundant SFC 220 elements. Thus, it is beneficial for the egress to signal the new 221 defect state to the ingress, which in this example is the Classifier. 222 Hence the following requirement: 224 REQ#3: SFC OAM MUST support Remote Defect Indication (RDI) 225 notification by the egress to the ingress. 227 REQ#4: SFC OAM MUST support connectivity verification of the SFP. 229 Definition of the misconnection defect, entry and exit criteria 230 are outside the scope of this document. 232 Once the SFF1 detects the defect, the objective of the SFC OAM 233 changes from the detection of a defect to defect characterization and 234 localization. 236 REQ#5: SFC OAM MUST support fault localization of the Loss of 237 Continuity Check within an SFP. 239 REQ#6: SFC OAM MUST support an SFP tracing to discover the RSP. 241 In the example presented in Figure 1, two distinct instances of the 242 same service function share the same SFF. In this example, the SFP 243 can be realized over several RSPs, for instance, RSP1(SF1--SF3--SF5) 244 and RSP2(SF2--SF4--SF6). Available RSPs can be discovered using the 245 trace function discussed in Section 4.3 [RFC8924]. 247 REQ#7: SFC OAM MUST have the ability to discover and exercise all 248 available RSPs in the network. 250 The SFC OAM layer model described in [RFC8924] offers an efficient 251 approach for a defect localization within a service function chain. 252 As the first step, the SFP's continuity for SFFs that are part of the 253 same SFP could be verified. After the reachability of SFFs has 254 already been verified, SFFs that serve an SF may be used as a test 255 packet source. In such a case, SFF can act as a proxy for another 256 element within the service function chain. 258 REQ#8: SFC OAM MUST be able to trigger on-demand FM with responses 259 being directed towards the initiator of such proxy request. 261 4. Active OAM Identification in SFC NSH 263 The O bit in the NSH header is defined in [RFC8300] as follows: 265 O bit: Setting this bit indicates an OAM packet. 267 This document updates that definition as follows: 269 O bit: Setting this bit indicates an OAM command and/or data in 270 the NSH Context Header or packet payload. 272 Active SFC OAM is defined as a combination of OAM commands and/or 273 data included in a message that immediately follows the NSH. To 274 identify the active OAM message, the Next Protocol field's value MUST 275 be set to Active SFC OAM (TBA1) (Section 8.1). The rules for 276 interpreting the values of O bit and the Next Protocol field are as 277 follows: 279 * O bit set and the Next Protocol value is not one of identifying 280 active or hybrid OAM protocol (per [RFC7799] definitions), e.g., 281 defined in this specification Active SFC OAM: 283 - a Fixed-Length Context Header or Variable-Length Context 284 Header(s) contain an OAM command or data. 286 - the type of payload is determined by the Next Protocol field. 288 * O bit set and the Next Protocol value is one of identifying active 289 or hybrid OAM protocol: 291 - the payload that immediately follows SFC NSH MUST contain an 292 OAM command or data. 294 * O bit is clear: 296 - no OAM in a Fixed-Length Context Header or Variable-Length 297 Context Header(s). 299 - the payload determined by the Next Protocol field's value 300 MUST be present. 302 * O bit is clear and the Next Protocol field's value identifies 303 active or hybrid OAM protocol MUST be identified and reported as 304 the erroneous combination. An implementation MAY have control to 305 enable processing of the OAM payload. 307 One conclusion from the above-listed rules of processing O bit and 308 the Next Protocol field's value is to avoid the combination of OAM in 309 an NSH Context Header (Fixed-Length or Variable-Length) and the 310 payload immediately following the SFC NSH because there is no 311 unambiguous way to identify such combination using the O bit and the 312 Next Protocol field. 314 As demonstrated in Section 4 [RFC8924] and Section 3 of this 315 document, SFC OAM is required to perform multiple tasks. Several 316 active OAM protocols could be used to address all the requirements. 317 When IP/UDP encapsulation of an SFC OAM control message is used, 318 protocols can be demultiplexed using the Destination UDP port number. 319 But extra IP/UDP headers, especially in an IPv6 network, add 320 noticeable overhead. This document defines Active OAM Header 321 (Figure 2) to demultiplex active OAM protocols on an SFC. 323 0 1 2 3 324 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 325 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 326 | V | Msg Type | Flags | Length | 327 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 328 ~ SFC Active OAM Control Packet ~ 329 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 331 Figure 2: SFC Active OAM Header 333 V - two-bit-long field indicates the current version of the SFC 334 active OAM header. The current value is 0. 336 Msg Type - six bits long field identifies OAM protocol, e.g., Echo 337 Request/Reply or Bidirectional Forwarding Detection. 339 Flags - eight bits long field carries bit flags that define 340 optional capability and thus processing of the SFC active OAM 341 control packet, e.g., optional timestamping. 343 Length - two octets long field that is the length of the SFC 344 active OAM control packet in octets. 346 5. Echo Request/Echo Reply for SFC 348 Echo Request/Reply is a well-known active OAM mechanism that is 349 extensively used to verify a path's continuity, detect 350 inconsistencies between a state in control and the data planes, and 351 localize defects in the data plane. ICMP ([RFC0792] for IPv4 and 352 [RFC4443] for IPv6 networks respectively) and [RFC8029] are examples 353 of broadly used active OAM protocols based on Echo Request/Reply 354 principle. The SFC NSH Echo Request/Reply control message format is 355 presented in Figure 3. 357 0 1 2 3 358 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 359 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 360 | V | Reserved | Global Flags | 361 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 362 | Message Type | Reply mode | Return Code |Return Subcode | 363 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 364 | Sender's Handle | 365 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 366 | Sequence Number | 367 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 368 ~ TLVs ~ 369 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 371 Figure 3: SFC Echo Request/Reply Format 373 The interpretation of the fields is as follows: 375 Version (V) is a two-bit field that indicates the current version 376 of the SFC Echo Request/Reply. The current value is 0. The 377 version number is to be incremented whenever a change is made that 378 affects the ability of an implementation to parse or process 379 control packet correctly. 381 Reserved - fourteen-bit field. It MUST be zeroed on transmission 382 and ignored on receipt. 384 The Global Flags is a two-octet bit vector field. 386 The Message Type is a one-octet field that reflects the packet 387 type. Value TBA3 identifies Echo Request and TBA4 - Echo Reply. 389 The Reply Mode is a one-octet field. It defines the type of the 390 return path requested by the sender of the Echo Request. 392 Return Codes and Subcodes are one-octet fields each. These can be 393 used to inform the sender about the result of processing its 394 request. Initial Return Code values are according to Table 1. 395 For all Return Code values defined in this document, the value of 396 the Return Subcode field MUST be set to zero. 398 The Sender's Handle is a four-octet field. It is filled in by the 399 sender of the Echo Request and returned unchanged by the Echo 400 Reply sender. The sender of the Echo Request MAY use a pseudo- 401 random number generator (PRNG) to set the value of the Sender's 402 Handle field. 404 The Sequence Number is a four-octet field. It is assigned by the 405 sender and can be (for example) used to detect missed replies. 406 The value of the Sequence Number field SHOULD be monotonically 407 increasing in the course of the test session. 409 0 1 2 3 410 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 411 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 412 | Type | Reserved | Length | 413 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 414 ~ Value ~ 415 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 417 Figure 4: SFC Echo Request/Reply TLV Format 419 TLV is a variable-length field. Multiple TLVs MAY be placed in an 420 SFC Echo Request/Reply packet. Additional TLVs may be enclosed 421 within a given TLV, subject to the semantics of the (outer) TLV in 422 question. If more than one TLV is to be included, the value of the 423 Type field of the outmost outer TLV MUST be set to Multiple TLVs Used 424 (TBA12), as assigned by IANA according to Section 8.7. Figure 4 425 presents the format of an SFC Echo Request/Reply TLV, where fields 426 are defined as the following: 428 Type - a one-octet-long field that characterizes the 429 interpretation of the Value field. Type values allocated 430 according to Section 8.7. 432 Reserved - one-octet-long field. The value of the Type field 433 determines its interpretation and encoding. 435 Length - two-octet-long field equal to the Value field's length in 436 octets. 438 Value - a variable-length field. The value of the Type field 439 determines its interpretation and encoding. 441 5.1. Return Codes 443 The value of the Return Code field is set to zero by the sender of an 444 Echo Request. The receiver of said Echo Request can set it to one of 445 the values listed in Table 1 in the corresponding Echo Reply that it 446 generates. 448 +=======+============================================+ 449 | Value | Description | 450 +=======+============================================+ 451 | 0 | No Return Code | 452 +-------+--------------------------------------------+ 453 | 1 | Malformed Echo Request received | 454 +-------+--------------------------------------------+ 455 | 2 | One or more of the TLVs was not understood | 456 +-------+--------------------------------------------+ 457 | 3 | Authentication failed | 458 +-------+--------------------------------------------+ 460 Table 1: SFC Echo Return Codes 462 5.2. Authentication in Echo Request/Reply 464 Authentication can be used to protect the integrity of the 465 information in SFC Echo Request and/or Echo Reply. In the 466 [I-D.ietf-sfc-nsh-integrity] a variable-length Context Header has 467 been defined to protect the integrity of the NSH and the payload. 468 The header can also be used for the optional encryption of the 469 sensitive metadata. MAC#1 Context Header is more suitable for the 470 integrity protection of active SFC OAM, particularly of the defined 471 in this document SFC Echo Request and Echo Reply. On the other hand, 472 using MAC#2 Context Header allows the detection of mishandling of the 473 O-bit by a transient SFC element. 475 5.3. SFC Echo Request Transmission 477 SFC Echo Request control packet MUST use the appropriate 478 encapsulation of the monitored SFP. If the NSH is used, Echo Request 479 MUST set O bit, as defined in [RFC8300]. SFC NSH MUST be immediately 480 followed by the SFC Active OAM Header defined in Section 4. The 481 Message Type field's value in the SFC Active OAM Header MUST be set 482 to SFC Echo Request/Echo Reply value (TBA2) per Section 8.2. 484 Value of the Reply Mode field MAY be set to: 486 * Do Not Reply (TBA5) if one-way monitoring is desired. If the Echo 487 Request is used to measure synthetic packet loss; the receiver may 488 report loss measurement results to a remote node. 490 * Reply via an IPv4/IPv6 UDP Packet (TBA6) value likely will be the 491 most used. 493 * Reply via Application Level Control Channel (TBA7) value if the 494 SFP may have bi-directional paths. 496 * Reply via Specified Path (TBA8) value to enforce the use of the 497 particular return path specified in the included TLV to verify bi- 498 directional continuity and also increase the robustness of the 499 monitoring by selecting a more stable path. 501 5.4. SFC Echo Request Reception 503 Sending an SFC Echo Request to the control plane is triggered by one 504 of the following packet processing exceptions: NSH TTL expiration, 505 NSH Service Index (SI) expiration or the receiver is the terminal SFF 506 for an SFP. 508 Firstly, if the SFC Echo Request is authenticated, the receiving SFF 509 MUST verify the authentication. If the verification fails, the 510 receiver SFF MUST send an SFC Echo Reply with the Return Code set to 511 "Authentication failed" and the Subcode set to zero. Then, the SFF 512 that has received an SFC Echo Request verifies the received packet's 513 general sanity. If the packet is not well-formed, the receiver SFF 514 SHOULD send an SFC Echo Reply with the Return Code set to "Malformed 515 Echo Request received" and the Subcode set to zero. If there are any 516 TLVs that SFF does not understand, the SFF MUST send an SFC Echo 517 Reply with the Return Code set to 2 ("One or more TLVs was not 518 understood") and set the Subcode to zero. In the latter case, the 519 SFF MAY include an Errored TLVs TLV (Section 5.4.1) that as sub-TLVs 520 contains only the misunderstood TLVs. The header field's Sender's 521 Handle, Sequence Number are not examined but are included in the SFC 522 Echo Reply message. 524 5.4.1. Errored TLVs TLV 526 If the Return Code for the Echo Reply is determined as 2 ("One or 527 more TLVs was not understood"), then the Errored TLVs TLV MAY be 528 included in an Echo Reply. The use of this TLV allows informing the 529 sender of an Echo Request of mandatory TLVs either not supported by 530 an implementation or parsed and found to be in error. 532 0 1 2 3 533 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 534 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 535 | Errored TLVs | Reserved | Length | 536 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 537 | Value | 538 . . 539 . . 540 . . 541 | | 542 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 543 Figure 5: Errored TLVs TLV 545 where 547 The Errored TLVs Type MUST be set to TBA14 Section 8.7. 549 Reserved - one-octet-long field. 551 Length - two-octet-long field equal to the length of the Value 552 field in octets. 554 The Value field contains the TLVs, encoded as sub-TLVs, that were 555 not understood or failed to be parsed correctly. 557 5.5. SFC Echo Reply Transmission 559 The Reply Mode field directs whether and how the Echo Reply message 560 should be sent. The sender of the Echo Request MAY use TLVs to 561 request that the corresponding Echo Reply is transmitted over the 562 specified path. Value TBA3 is referred to as the "Do not reply" mode 563 and suppresses the Echo Reply packet transmission. The default value 564 (TBA6) for the Reply mode field requests the responder to send the 565 Echo Reply packet out-of-band as IPv4 or IPv6 UDP packet. 567 Responder to the SFC Echo Request sends the Echo Reply over IP 568 network if the Reply mode is Reply via an IPv4/IPv6 UDP Packet. 569 Because SFC NSH does not identify the ingress of the SFP, the Echo 570 Request, the source ID MUST be included in the message and used as 571 the IP destination address for IP/UDP encapsulation of the SFC Echo 572 Reply. The sender of the SFC Echo Request MUST include SFC Source 573 TLV Figure 6. 575 0 1 2 3 576 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 577 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 578 | Source ID | Reserved | Length | 579 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 580 | Value | 581 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 583 Figure 6: SFC Source TLV 585 where 587 Source ID Type is a one-octet-long field and has the value of 588 TBA13 Section 8.7. 590 Reserved - one-octet-long field. 592 Length is a two-octets-long field, and the value equals the length 593 of the Value field in octets. 595 Value field contains the IP address of the sender of the SFC OAM 596 control message, IPv4 or IPv6. 598 The UDP destination port for SFC Echo Reply TBA15 will be allocated 599 by IANA Section 8.8. 601 5.6. SFC Echo Reply Reception 603 An SFF SHOULD NOT accept SFC Echo Reply unless the received passes 604 the following checks: 606 * the received SFC Echo Reply is well-formed; 608 * it has an outstanding SFC Echo Request sent from the UDP port that 609 matches destination UDP port number of the received packet; 611 * if the matching to the Echo Request found, the value of the 612 Sender's Handle n the Echo Request sent is equal to the value of 613 Sender's Handle in the Echo Reply received; 615 * if all checks passed, the SFF checks if the Sequence Number in the 616 Echo Request sent matches to the Sequence Number in the Echo Reply 617 received. 619 6. Security Considerations 621 When the integrity protection for SFC active OAM, and SFC Echo 622 Request/Reply in particular, is required, it is RECOMMENDED to use 623 one of Context Headers defined in [I-D.ietf-sfc-nsh-integrity]. 624 MAC#1 (Message Authentication Code) Context Header could be more 625 suitable for active SFC OAM because it does not require re- 626 calculation of the MAC when the value of the NSH Base Header's TTL 627 field is changed. The integrity protection for SFC active OAM can 628 also be achieved using mechanisms in the underlay data plane. For 629 example, if the underlay is an IPv6 network, IP Authentication Header 630 [RFC4302] or IP Encapsulating Security Payload Header [RFC4303] can 631 be used to provide integrity protection. Confidentiality for the SFC 632 Echo Request/Reply exchanges can be achieved using the IP 633 Encapsulating Security Payload Header [RFC4303]. Also, the security 634 needs for SFC Echo Request/Reply are similar to those of ICMP ping 635 [RFC0792], [RFC4443] and MPLS LSP ping [RFC8029]. 637 There are at least three approaches to attacking a node in the 638 overlay network using the mechanisms defined in the document. One is 639 a Denial-of-Service attack, sending an SFC Echo Request to overload 640 an element of the SFC. The second may use spoofing, hijacking, 641 replying, or otherwise tampering with SFC Echo Requests and/or 642 replies to misrepresent, alter the operator's view of the state of 643 the SFC. The third is an unauthorized source using an SFC Echo 644 Request/Reply to obtain information about the SFC and/or its 645 elements, e.g., SFF or SF. 647 It is RECOMMENDED that implementations throttle the SFC ping traffic 648 going to the control plane to mitigate potential Denial-of-Service 649 attacks. 651 Reply and spoofing attacks involving faking or replying to SFC Echo 652 Reply messages would have to match the Sender's Handle and Sequence 653 Number of an outstanding SFC Echo Request message, which is highly 654 unlikely. Thus the non-matching reply would be discarded. 656 To protect against unauthorized sources trying to obtain information 657 about the overlay and/or underlay, an implementation MAY check that 658 the source of the Echo Request is indeed part of the SFP. 660 7. Acknowledgments 662 Authors greatly appreciate thorough review and the most helpful 663 comments from Dan Wing, Dirk von Hugo, and Mohamed Boucadair. 665 8. IANA Considerations 667 8.1. SFC Active OAM Protocol 669 IANA is requested to assign a new type from the SFC Next Protocol 670 registry as follows: 672 +=======+================+===============+ 673 | Value | Description | Reference | 674 +=======+================+===============+ 675 | TBA1 | SFC Active OAM | This document | 676 +-------+----------------+---------------+ 678 Table 2: SFC Active OAM Protocol 680 8.2. SFC Active OAM Message Type 682 IANA is requested to create a new registry called "SFC Active OAM 683 Message Type". All code points in the range 1 through 32767 in this 684 registry shall be allocated according to the "IETF Review" procedure 685 specified in [RFC8126]. The remaining code points to be allocated 686 according to Table 3: 688 +===============+=============+=========================+ 689 | Value | Description | Reference | 690 +===============+=============+=========================+ 691 | 0 | Reserved | | 692 +---------------+-------------+-------------------------+ 693 | 1 - 32767 | Reserved | IETF Consensus | 694 +---------------+-------------+-------------------------+ 695 | 32768 - 65530 | Reserved | First Come First Served | 696 +---------------+-------------+-------------------------+ 697 | 65531 - 65534 | Reserved | Private Use | 698 +---------------+-------------+-------------------------+ 699 | 65535 | Reserved | | 700 +---------------+-------------+-------------------------+ 702 Table 3: SFC Active OAM Message Type 704 IANA is requested to assign a new type from the SFC Active OAM 705 Message Type registry as follows: 707 +=======+=============================+===============+ 708 | Value | Description | Reference | 709 +=======+=============================+===============+ 710 | TBA2 | SFC Echo Request/Echo Reply | This document | 711 +-------+-----------------------------+---------------+ 713 Table 4: SFC Echo Request/Echo Reply Type 715 8.3. SFC Echo Request/Echo Reply Parameters 717 IANA is requested to create a new SFC Echo Request/Echo Reply 718 Parameters registry. 720 8.4. SFC Echo Request/Echo Reply Message Types 722 IANA is requested to create in the SFC Echo Request/Echo Reply 723 Parameters registry the new sub-registry Message Types. All code 724 points in the range 1 through 175 in this registry shall be allocated 725 according to the "IETF Review" procedure specified in [RFC8126]. 726 Code points in the range 176 through 239 in this registry shall be 727 allocated according to the "First Come First Served" procedure 728 specified in [RFC8126]. The remaining code points are allocated 729 according to Table 5: as specified in Table 5. 731 +===========+==============+===============+ 732 | Value | Description | Reference | 733 +===========+==============+===============+ 734 | 0 | Reserved | This document | 735 +-----------+--------------+---------------+ 736 | 1- 175 | Unassigned | This document | 737 +-----------+--------------+---------------+ 738 | 176 - 239 | Unassigned | This document | 739 +-----------+--------------+---------------+ 740 | 240 - 251 | Experimental | This document | 741 +-----------+--------------+---------------+ 742 | 252 - 254 | Private Use | This document | 743 +-----------+--------------+---------------+ 744 | 255 | Reserved | This document | 745 +-----------+--------------+---------------+ 747 Table 5: SFC Echo Request/Echo Reply 748 Message Types 750 IANA is requested to assign values as listed in Table 6. 752 +=======+==================+===============+ 753 | Value | Description | Reference | 754 +=======+==================+===============+ 755 | TBA3 | SFC Echo Request | This document | 756 +-------+------------------+---------------+ 757 | TBA4 | SFC Echo Reply | This document | 758 +-------+------------------+---------------+ 760 Table 6: SFC Echo Request/Echo Reply 761 Message Types Values 763 8.5. SFC Echo Reply Modes 765 IANA is requested to create in the SFC Echo Request/Echo Reply 766 Parameters registry the new sub-registry Reply Mode. All code points 767 in the range 1 through 175 in this registry shall be allocated 768 according to the "IETF Review" procedure specified in [RFC8126]. 769 Code points in the range 176 through 239 in this registry shall be 770 allocated according to the "First Come First Served" procedure 771 specified in [RFC8126]. The remaining code points are allocated 772 according to Table 7: as specified in Table 7. 774 +===========+==============+===============+ 775 | Value | Description | Reference | 776 +===========+==============+===============+ 777 | 0 | Reserved | This document | 778 +-----------+--------------+---------------+ 779 | 1- 175 | Unassigned | This document | 780 +-----------+--------------+---------------+ 781 | 176 - 239 | Unassigned | This document | 782 +-----------+--------------+---------------+ 783 | 240 - 251 | Experimental | This document | 784 +-----------+--------------+---------------+ 785 | 252 - 254 | Private Use | This document | 786 +-----------+--------------+---------------+ 787 | 255 | Reserved | This document | 788 +-----------+--------------+---------------+ 790 Table 7: SFC Echo Reply Mode 792 All code points in the range 1 through 191 in this registry shall be 793 allocated according to the "IETF Review" procedure specified in 794 [RFC8126] and assign values as listed in Table 8. 796 +=======+====================================+===============+ 797 | Value | Description | Reference | 798 +=======+====================================+===============+ 799 | 0 | Reserved | | 800 +-------+------------------------------------+---------------+ 801 | TBA5 | Do Not Reply | This document | 802 +-------+------------------------------------+---------------+ 803 | TBA6 | Reply via an IPv4/IPv6 UDP Packet | This document | 804 +-------+------------------------------------+---------------+ 805 | TBA7 | Reply via Application Level | This document | 806 | | Control Channel | | 807 +-------+------------------------------------+---------------+ 808 | TBA8 | Reply via Specified Path | This document | 809 +-------+------------------------------------+---------------+ 810 | TBA9 | Reply via an IPv4/IPv6 UDP Packet | This document | 811 | | with the data integrity protection | | 812 +-------+------------------------------------+---------------+ 813 | TBA10 | Reply via Application Level | This document | 814 | | Control Channel with the data | | 815 | | integrity protection | | 816 +-------+------------------------------------+---------------+ 817 | TBA11 | Reply via Specified Path with the | This document | 818 | | data integrity protection | | 819 +-------+------------------------------------+---------------+ 821 Table 8: SFC Echo Reply Mode Values 823 8.6. SFC Echo Return Codes 825 IANA is requested to create in the SFC Echo Request/Echo Reply 826 Parameters registry the new sub-registry Return Codes as described in 827 Table 9. 829 +=========+=============+=========================+ 830 | Value | Description | Reference | 831 +=========+=============+=========================+ 832 | 0-191 | Unassigned | IETF Review | 833 +---------+-------------+-------------------------+ 834 | 192-251 | Unassigned | First Come First Served | 835 +---------+-------------+-------------------------+ 836 | 252-254 | Unassigned | Private Use | 837 +---------+-------------+-------------------------+ 838 | 255 | Reserved | | 839 +---------+-------------+-------------------------+ 841 Table 9: SFC Echo Return Codes 843 Values defined for the Return Codes sub-registry are listed in 844 Table 10. 846 +=======+=================================+===============+ 847 | Value | Description | Reference | 848 +=======+=================================+===============+ 849 | 0 | No Return Code | This document | 850 +-------+---------------------------------+---------------+ 851 | 1 | Malformed Echo Request received | This document | 852 +-------+---------------------------------+---------------+ 853 | 2 | One or more of the TLVs was not | This document | 854 | | understood | | 855 +-------+---------------------------------+---------------+ 856 | 3 | Authentication failed | This document | 857 +-------+---------------------------------+---------------+ 859 Table 10: SFC Echo Return Codes Values 861 8.7. SFC TLV Type 863 IANA is requested to create the SFC OAM TLV Type registry. All code 864 points in the range 1 through 175 in this registry shall be allocated 865 according to the "IETF Review" procedure specified in [RFC8126]. 866 Code points in the range 176 through 239 in this registry shall be 867 allocated according to the "First Come First Served" procedure 868 specified in [RFC8126]. The remaining code points are allocated 869 according to Table 11: 871 +===========+==============+===============+ 872 | Value | Description | Reference | 873 +===========+==============+===============+ 874 | 0 | Reserved | This document | 875 +-----------+--------------+---------------+ 876 | 1- 175 | Unassigned | This document | 877 +-----------+--------------+---------------+ 878 | 176 - 239 | Unassigned | This document | 879 +-----------+--------------+---------------+ 880 | 240 - 251 | Experimental | This document | 881 +-----------+--------------+---------------+ 882 | 252 - 254 | Private Use | This document | 883 +-----------+--------------+---------------+ 884 | 255 | Reserved | This document | 885 +-----------+--------------+---------------+ 887 Table 11: SFC OAM TLV Type Registry 889 This document defines the following new values in SFC OAM TLV Type 890 registry: 892 +=======+====================+===============+ 893 | Value | Description | Reference | 894 +=======+====================+===============+ 895 | TBA12 | Multiple TLVs Used | This document | 896 +-------+--------------------+---------------+ 897 | TBA13 | Source ID TLV | This document | 898 +-------+--------------------+---------------+ 899 | TBA14 | Errored TLVs | This document | 900 +-------+--------------------+---------------+ 902 Table 12: SFC OAM Type Values 904 8.8. SFC OAM UDP Port 906 IANA is requested to allocate UDP port number according to 908 +=============+============+===================+============+=====================+=============+ 909 |Service Name |Port Number |Transport Protocol |Description |Semantics Definition |Reference | 910 +=============+============+===================+============+=====================+=============+ 911 |SFC OAM |TBA15 |UDP |SFC OAM Echo|Section 5.5 |This document| 912 | | | |Reply | | | 913 +-------------+------------+-------------------+------------+---------------------+-------------+ 915 Table 13: SFC OAM Port 917 9. References 918 9.1. Normative References 920 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 921 Requirement Levels", BCP 14, RFC 2119, 922 DOI 10.17487/RFC2119, March 1997, 923 . 925 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 926 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 927 May 2017, . 929 [RFC8300] Quinn, P., Ed., Elzur, U., Ed., and C. Pignataro, Ed., 930 "Network Service Header (NSH)", RFC 8300, 931 DOI 10.17487/RFC8300, January 2018, 932 . 934 9.2. Informative References 936 [I-D.ietf-sfc-nsh-integrity] 937 Boucadair, M., Reddy, T., and D. Wing, "Integrity 938 Protection for the Network Service Header (NSH) and 939 Encryption of Sensitive Context Headers", Work in 940 Progress, Internet-Draft, draft-ietf-sfc-nsh-integrity-05, 941 23 March 2021, . 944 [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, 945 RFC 792, DOI 10.17487/RFC0792, September 1981, 946 . 948 [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, 949 DOI 10.17487/RFC4302, December 2005, 950 . 952 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 953 RFC 4303, DOI 10.17487/RFC4303, December 2005, 954 . 956 [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet 957 Control Message Protocol (ICMPv6) for the Internet 958 Protocol Version 6 (IPv6) Specification", STD 89, 959 RFC 4443, DOI 10.17487/RFC4443, March 2006, 960 . 962 [RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function 963 Chaining (SFC) Architecture", RFC 7665, 964 DOI 10.17487/RFC7665, October 2015, 965 . 967 [RFC7799] Morton, A., "Active and Passive Metrics and Methods (with 968 Hybrid Types In-Between)", RFC 7799, DOI 10.17487/RFC7799, 969 May 2016, . 971 [RFC8029] Kompella, K., Swallow, G., Pignataro, C., Ed., Kumar, N., 972 Aldrin, S., and M. Chen, "Detecting Multiprotocol Label 973 Switched (MPLS) Data-Plane Failures", RFC 8029, 974 DOI 10.17487/RFC8029, March 2017, 975 . 977 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 978 Writing an IANA Considerations Section in RFCs", BCP 26, 979 RFC 8126, DOI 10.17487/RFC8126, June 2017, 980 . 982 [RFC8924] Aldrin, S., Pignataro, C., Ed., Kumar, N., Ed., Krishnan, 983 R., and A. Ghanwani, "Service Function Chaining (SFC) 984 Operations, Administration, and Maintenance (OAM) 985 Framework", RFC 8924, DOI 10.17487/RFC8924, October 2020, 986 . 988 Authors' Addresses 990 Greg Mirsky 991 ZTE Corp. 993 Email: gregimirsky@gmail.com, gregory.mirsky@ztetx.com 995 Wei Meng 996 ZTE Corporation 997 No.50 Software Avenue, Yuhuatai District 998 Nanjing, 999 China 1001 Email: meng.wei2@zte.com.cn 1003 Bhumip Khasnabish 1004 Individual contributor 1006 Email: vumip1@gmail.com 1008 Cui Wang 1009 Individual contributor 1011 Email: lindawangjoy@gmail.com