idnits 2.17.1 draft-ietf-sfc-multi-layer-oam-08.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 (January 19, 2021) is 1193 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-02 Summary: 0 errors (**), 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: July 23, 2021 B. Khasnabish 7 C. Wang 8 Individual contributor 9 January 19, 2021 11 Active OAM for Service Function Chains in Networks 12 draft-ietf-sfc-multi-layer-oam-08 14 Abstract 16 A set of requirements for active Operation, Administration and 17 Maintenance (OAM) of Service Function Chains (SFCs) in networks is 18 presented. Based on these requirements, an encapsulation of active 19 OAM message in SFC and a mechanism to detect and localize defects 20 described. Also, this document updates RFC 8300 in the definition of 21 O (OAM) bit in the Network Service Header (NSH) and defines how the 22 active OAM message is identified in SFC NSH. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at https://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on July 23, 2021. 41 Copyright Notice 43 Copyright (c) 2021 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (https://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 59 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 2.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 61 2.2. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . 3 62 3. Requirements for Active OAM in SFC Network . . . . . . . . . 4 63 4. Active OAM Identification in SFC NSH . . . . . . . . . . . . 5 64 5. Echo Request/Echo Reply for SFC in Networks . . . . . . . . . 7 65 5.1. Return Codes . . . . . . . . . . . . . . . . . . . . . . 9 66 5.2. Authentication in Echo Request/Reply . . . . . . . . . . 9 67 5.3. SFC Echo Request Transmission . . . . . . . . . . . . . . 9 68 5.4. SFC Echo Request Reception . . . . . . . . . . . . . . . 10 69 5.4.1. Errored TLVs TLV . . . . . . . . . . . . . . . . . . 10 70 5.5. SFC Echo Reply Transmission . . . . . . . . . . . . . . . 11 71 5.6. SFC Echo Reply Reception . . . . . . . . . . . . . . . . 12 72 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 73 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 74 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 75 8.1. SFC Active OAM Protocol . . . . . . . . . . . . . . . . . 14 76 8.2. SFC Active OAM Message Type . . . . . . . . . . . . . . . 14 77 8.3. SFC Echo Request/Echo Reply Parameters . . . . . . . . . 15 78 8.4. SFC Echo Request/Echo Reply Message Types . . . . . . . . 15 79 8.5. SFC Echo Reply Modes . . . . . . . . . . . . . . . . . . 15 80 8.6. SFC Echo Return Codes . . . . . . . . . . . . . . . . . . 16 81 8.7. SFC TLV Type . . . . . . . . . . . . . . . . . . . . . . 17 82 8.8. SFC OAM UDP Port . . . . . . . . . . . . . . . . . . . . 18 83 8.9. HMAC Type Sub-registry . . . . . . . . . . . . . . . . . 18 84 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 85 9.1. Normative References . . . . . . . . . . . . . . . . . . 19 86 9.2. Informative References . . . . . . . . . . . . . . . . . 19 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 89 1. Introduction 91 [RFC7665] defines components necessary to implement a Service 92 Function Chain (SFC). These include a classifier that performs the 93 classification of incoming packets. A Service Function Forwarder 94 (SFF) is responsible for forwarding traffic to one or more connected 95 Service Functions (SFs) according to the information carried in the 96 SFC encapsulation. SFF also handles traffic coming back from the SF 97 and transports the data packets to the next SFF. And the SFF serves 98 as a termination element of the Service Function Path (SFP). SF is 99 responsible for the specific treatment of received packets. 101 Resulting from that SFC is constructed by a number of these 102 components, there are different views from different levels of the 103 SFC. One is the SFC, an entirely abstract entity, which defines an 104 ordered set of SFs that must be applied to packets selected due to 105 classification. But SFC doesn't specify the exact mapping between 106 SFFs and SFs. Thus there exists another semi-abstract entity 107 referred to as SFP. SFP is the instantiation of the SFC in the 108 network and provides a level of indirection between the entirely 109 abstract SFC and a fully specified ordered list of SFFs and SFs 110 identities that the packet will visit when it traverses the SFC. The 111 latter entity is being referred to as Rendered Service Path (RSP). 112 The main difference between SFP and RSP is that in the former the 113 authority to select the SFF/SF has been delegated to the network. 115 This document defines how active Operation, Administration and 116 Maintenance (OAM), per [RFC7799] definition of active OAM, identified 117 in Network Service Header (NSH) SFC. The document lists requirements 118 to improve troubleshooting efficiency. It defines SFC Echo Request 119 and Echo reply that enables on-demand Continuity Check, Connectivity 120 Verification among other operations over SFC in networks addressing 121 essential SFC OAM functions identified in [RFC8924]. Also, this 122 document updates Section 2.2 of [RFC8300] in part of the definition 123 of O bit in the (NSH). 125 2. Conventions 127 2.1. Requirements Language 129 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 130 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 131 "OPTIONAL" in this document are to be interpreted as described in BCP 132 14 [RFC2119] [RFC8174] when, and only when, they appear in all 133 capitals, as shown here. 135 2.2. Acronyms 137 Unless explicitly specified in this document, active OAM in SFC and 138 SFC OAM are being used interchangeably. 140 e2e: End-to-End 142 FM: Fault Management 144 NSH: Network Service Header 145 OAM: Operations, Administration, and Maintenance 147 PRNG: Pseudorandom number generator 149 RDI: Remote Defect Indication 151 RSP: Rendered Service Path 153 SMI Structure of Management Information 155 SF: Service Function 157 SFC: Service Function Chain 159 SFF: Service Function Forwarder 161 SFP: Service Function Path 163 MAC: Message Authentication Code 165 3. Requirements for Active OAM in SFC Network 167 To perform the OAM task of fault management (FM) in an SFC, that 168 includes failure detection, defect characterization and localization, 169 this document defines the set of requirements for active OAM 170 mechanisms to be used on an SFC. 172 +---+ +---+ +---+ +---+ +---+ +---+ 173 |SF1| |SF2| |SF3| |SF4| |SF5| |SF6| 174 +---+ +---+ +---+ +---+ +---+ +---+ 175 \ / \ / \ / 176 +----------+ +----+ +----+ +----+ 177 |Classifier|-------|SFF1|---------|SFF2|--------|SFF3| 178 +----------+ +----+ +----+ +----+ 180 Figure 1: SFC reference model 182 In the example presented in Figure 1, the service SFP1 may be 183 realized through two independent RSPs, RSP1(SF1--SF3--SF5) and 184 RSP2(SF2--SF4--SF5). To perform end-to-end (e2e) FM SFC OAM: 186 REQ#1: Packets of active OAM in SFC SHOULD be fate sharing with 187 data traffic, i.e., in-band with the monitored traffic follow the 188 same RSP, in the forward direction from ingress toward egress 189 endpoint(s) of the OAM test. 191 REQ#2: SFC OAM MUST support pro-active monitoring of any element 192 in the SFC availability. 194 The egress, SFF3, in the example in Figure 1, is the entity that 195 detects the failure of the SFC. It must be able to signal the new 196 defect state to the ingress SFF1. Hence the following requirement: 198 REQ#3: SFC OAM MUST support Remote Defect Indication (RDI) 199 notification by the egress to the ingress. 201 REQ#4: SFC OAM MUST support connectivity verification. Definition 202 of the misconnection defect, entry and exit criteria are outside 203 the scope of this document. 205 Once the SFF1 detects the defect objective of OAM switches from 206 failure detection to defect characterization and localization. 208 REQ#5: SFC OAM MUST support fault localization of Loss of 209 Continuity check in the SFC. 211 REQ#6: SFC OAM MUST support tracing an SFP to realize the RSP. 213 It is practical, as presented in Figure 1, that several SFs share the 214 same SFF. In such a case, SFP1 may be realized over two RSPs, 215 RSP1(SF1--SF3--SF5) and RSP2(SF2--SF4--SF6). 217 REQ#7: SFC OAM MUST have the ability to discover and exercise all 218 available RSPs in the transport network. 220 In the process of localizing the SFC failure, separating SFC OAM 221 layers is an efficient approach. To achieve that continuity among 222 SFFs that are part of the same SFP should be verified. Once SFFs 223 reachability along the particular SFP has been confirmed, the task of 224 defect localization may focus on SF reachability verification. 225 Because reachability of SFFs has already verified, SFF local to the 226 SF may be used as a source of the test packets. 228 REQ#8: SFC OAM MUST be able to trigger on-demand FM with responses 229 being directed towards the initiator of such proxy request. 231 4. Active OAM Identification in SFC NSH 233 The interpretation of the O bit flag in the NSH header is defined in 234 [RFC8300] as: 236 O bit: Setting this bit indicates an OAM packet. 238 This document updates the definition of O bit as follows: 240 O bit: Setting this bit indicates an OAM command and/or data in 241 the NSH Context Header or packet payload 243 Active SFC OAM is defined as a combination of OAM commands and/or 244 data included in a message that immediately follows the NSH. To 245 identify the active OAM message, the value on the Next Protocol field 246 MUST be set to Active SFC OAM (TBA1) according to Section 8.1. The 247 rules of interpreting the values of O bit and the Next Protocol field 248 are as follows: 250 o O bit set, and the Next Protocol value is not one of identifying 251 active or hybrid OAM protocol (per [RFC7799] definitions), e.g., 252 defined in this specification Active SFC OAM - a Fixed-Length 253 Context Header or Variable-Length Context Header(s) contain OAM 254 command or data. and the type of payload determined by the Next 255 Protocol field; 257 o O bit set, and the Next Protocol value is one of identifying 258 active or hybrid OAM protocol - the payload that immediately 259 follows SFC NSH contains OAM command or data; 261 o O bit is clear - no OAM in a Fixed-Length Context Header or 262 Variable-Length Context Header(s) and the payload determined by 263 the value of the Next Protocol field; 265 o O bit is clear and the Next Protocol value is one of identifying 266 active or hybrid OAM protocol MUST be identified and reported as 267 the erroneous combination. An implementation MAY have control to 268 enable processing of the OAM payload. 270 From the above-listed rules follows the recommendation to avoid 271 combination of OAM in a Fixed-Length Context Header or Variable- 272 Length Context Header(s) and in the payload immediately following the 273 SFC NSH because there is no unambiguous way to identify such 274 combination using the O bit and the Next Protocol field. 276 Several active OAM protocols will be needed to address all the 277 requirements listed in Section 3. Destination UDP port number may 278 identify protocols if IP/UDP encapsulation is used. But extra IP/UDP 279 headers, especially in the case of IPv6, add noticeable overhead. 280 This document defines Active OAM Header Figure 2 to demultiplex 281 active OAM protocols on an SFC. 283 0 1 2 3 284 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 285 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 286 | V | Msg Type | Flags | Length | 287 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 288 ~ SFC Active OAM Control Packet ~ 289 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 291 Figure 2: SFC Active OAM Header 293 V - two-bit-long field indicates the current version of the SFC 294 active OAM header. The current value is 0. 296 Msg Type - six bits long field identifies OAM protocol, e.g., Echo 297 Request/Reply or Bidirectional Forwarding Detection. 299 Flags - eight bits long field carries bit flags that define 300 optional capability and thus processing of the SFC active OAM 301 control packet, e.g., optional timestamping. 303 Length - two octets long field that is the length of the SFC 304 active OAM control packet in octets. 306 5. Echo Request/Echo Reply for SFC in Networks 308 Echo Request/Reply is a well-known active OAM mechanism that is 309 extensively used to detect inconsistencies between a state in control 310 and the data planes, localize defects in the data plane. The format 311 of the Echo request/Echo reply control packet is to support ping and 312 traceroute functionality in SFC in networks Figure 3 resembles the 313 format of MPLS LSP Ping [RFC8029] with some exceptions. 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 | V | Reserved | Global Flags | 319 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 320 | Message Type | Reply mode | Return Code | Return S.code | 321 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 322 | Sender's Handle | 323 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 324 | Sequence Number | 325 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 326 ~ TLVs ~ 327 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 329 Figure 3: SFC Echo Request/Reply Format 331 The interpretation of the fields is as follows: 333 Version (V) is a two-bit-long field indicates the current version 334 of the SFC Echo Request/Reply. The current value is 0. The 335 version number is to be incremented whenever a change is made that 336 affects the ability of an implementation to parse or process 337 control packet correctly. 339 Reserved - fourteen-bit-long field. It MUST be zeroed on 340 transmission and ignored on receipt. 342 The Global Flags is a bit vector field. 344 The Message Type field reflects the type of the packet. Value 345 TBA3 identifies Echo Request and TBA4 - Echo Reply 347 The Reply Mode defines the type of the return path requested by 348 the sender of the Echo Request. 350 Return Codes and Subcodes can be used to inform the sender about 351 the result of processing its request. 353 The Sender's Handle is filled in by the sender and returned 354 unchanged by the Echo Reply receiver. The sender MAY use a 355 pseudo-random number generator (PRNG) to set the value of the 356 Sender's Handle field. The value of the Sender's Handle field 357 SHOULD NOT be changed in the course of the test session. 359 The Sequence Number is assigned by the sender and can be (for 360 example) used to detect missed replies. The value of the Sequence 361 Number field SHOULD be monotonically increasing in the course of 362 the test session. 364 0 1 2 3 365 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 366 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 367 | Type | Reserved | Length | 368 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 369 ~ Value ~ 370 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 372 Figure 4: SFC Echo Request/Reply TLV Format 374 TLV is a variable-length field. Multiple TLVs MAY be placed in an 375 SFC Echo Request/Reply packet. Additional TLVs may be enclosed 376 within a given TLV, subject to the semantics of the (outer) TLV in 377 question. If more than one TLV is to be included, the value of the 378 Type field of the outmost outer TLV MUST be set to Multiple TLVs Used 379 (TBA12), as assigned by IANA according to Section 8.7. Figure 4 380 presents the format of an SFC Echo Request/Reply TLV, where fields 381 are defined as the following: 383 Type - a one-octet-long field that characterizes the 384 interpretation of the Value field. TLVs (Type-Length-Value 385 tuples) have the two octets long Type field, two octets long 386 Length field is the length of the Value field in octets. Type 387 values allocated according to Section 8.7. 389 Reserved - one-octet-long field. The value of the Type field 390 determines its interpretation and encoding. 392 Length - two-octet-long field equal to the length of the Value 393 field in octets. 395 Value - a variable-length field. The value of the Type field 396 determines its interpretation and encoding. 398 5.1. Return Codes 400 The value of the Return Code field is set to zero by the sender of an 401 Echo Request. The receiver of said Echo Request can set it to one of 402 the values listed in Table 9 in the corresponding Echo Reply that it 403 generates. 405 5.2. Authentication in Echo Request/Reply 407 Authentication can be used to protect the integrity of the 408 information in SFC Echo Request and/or Echo Reply. In the 409 [I-D.ietf-sfc-nsh-integrity] a variable-length Context Header has 410 been defined to protect the integrity of the NSH and the payload. 411 The header can also be used for the optional encryption of the 412 sensitive metadata. MAC#1 Context Header is more suitable for the 413 integrity protection of active SFC OAM, particularly of the defined 414 in this document SFC Echo Request and Echo Reply. On the other hand, 415 using MAC#2 Context Header allows the detection of mishandling of the 416 O-bit by a transient SFC element. 418 5.3. SFC Echo Request Transmission 420 SFC Echo Request control packet MUST use the appropriate 421 encapsulation of the monitored SFP. If Network Service Header (NSH) 422 is used, Echo Request MUST set O bit, as defined in [RFC8300]. SFC 423 NSH MUST be immediately followed by the SFC Active OAM Header defined 424 in Section 4. The Message Type field's value in the SFC Active OAM 425 Header MUST be set to SFC Echo Request/Echo Reply value (TBA2) per 426 Section 8.2. 428 Value of the Reply Mode field MAY be set to: 430 o Do Not Reply (TBA5) if one-way monitoring is desired. If the Echo 431 Request is used to measure synthetic packet loss; the receiver may 432 report loss measurement results to a remote node. 434 o Reply via an IPv4/IPv6 UDP Packet (TBA6) value likely will be the 435 most used. 437 o Reply via Application Level Control Channel (TBA7) value if the 438 SFP may have bi-directional paths. 440 o Reply via Specified Path (TBA8) value to enforce the use of the 441 particular return path specified in the included TLV to verify bi- 442 directional continuity and also increase the robustness of the 443 monitoring by selecting a more stable path. 445 5.4. SFC Echo Request Reception 447 Sending an SFC Echo Request to the control plane is triggered by one 448 of the following packet processing exceptions: NSH TTL expiration, 449 NSH Service Index (SI) expiration or the receiver is the terminal SFF 450 for an SFP. 452 Firstly, if the SFC Echo Request is authenticated, the receiving SFF 453 MUST verify the authentication. If the verification fails, the 454 receiver SFF MUST send an SFC Echo Reply with the Return Code set to 455 "Authentication failed" and the Subcode set to zero. Then, the SFF 456 that has received an SFC Echo Request verifies the received packet's 457 general sanity. If the packet is not well- formed, the receiver SFF 458 SHOULD send an SFC Echo Reply with the Return Code set to "Malformed 459 Echo Request received" and the Subcode set to zero. If there are any 460 TLVs that SFF does not understand, the SFF MUST send an SFC Echo 461 Reply with the Return Code set to 2 ("One or more TLVs was not 462 understood") and set the Subcode to zero. In the latter case, the 463 SFF MAY include an Errored TLVs TLV (Section 5.4.1) that as sub-TLVs 464 contains only the misunderstood TLVs. The header field's Sender's 465 Handle, Sequence Number are not examined but are included in the SFC 466 Echo Reply message. 468 5.4.1. Errored TLVs TLV 470 If the Return Code for the Echo Reply is determined as 2 ("One or 471 more TLVs was not understood"), then the Errored TLVs TLV MAY be 472 included in an Echo Reply. The use of this TLV allows informing the 473 sender of an Echo Request of mandatory TLVs either not supported by 474 an implementation or parsed and found to be in error. 476 0 1 2 3 477 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 478 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 479 | Errored TLVs | Reserved | Length | 480 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 481 | Value | 482 . . 483 . . 484 . . 485 | | 486 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 488 Figure 5: Errored TLVs TLV 490 where 492 The Errored TLVs Type MUST be set to TBA14 Section 8.7. 494 Reserved - one-octet-long field. 496 Length - two-octet-long field equal to the length of the Value 497 field in octets. 499 The Value field contains the TLVs, encoded as sub-TLVs, that were 500 not understood or failed to be parsed correctly. 502 5.5. SFC Echo Reply Transmission 504 The Reply Mode field directs whether and how the Echo Reply message 505 should be sent. The sender of the Echo Request MAY use TLVs to 506 request that the corresponding Echo Reply is transmitted over the 507 specified path. Value TBA3 is referred to as the "Do not reply" mode 508 and suppresses transmission of Echo Reply packet. The default value 509 (TBA6) for the Reply mode field requests the responder to send the 510 Echo Reply packet out-of-band as IPv4 or IPv6 UDP packet. 512 Responder to the SFC Echo Request sends the Echo Reply over IP 513 network if the Reply mode is Reply via an IPv4/IPv6 UDP Packet. 514 Because SFC NSH does not identify the ingress of the SFP the Echo 515 Request, the source ID MUST be included in the message and used as 516 the IP destination address for IP/UDP encapsulation of the SFC Echo 517 Reply. The sender of the SFC Echo Request MUST include SFC Source 518 TLV Figure 6. 520 0 1 2 3 521 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 522 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 523 | Source ID | Reserved | Length | 524 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 525 | Value | 526 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 528 Figure 6: SFC Source TLV 530 where 532 Source ID Type is a one-octet-long field and has the value of 533 TBA13 Section 8.7. 535 Reserved - one-octet-long field. 537 Length is a two-octets-long field, and the value equals the length 538 of the Value field in octets. 540 Value field contains the IP address of the sender of the SFC OAM 541 control message, IPv4 or IPv6. 543 The UDP destination port for SFC Echo Reply TBA15 will be allocated 544 by IANA Section 8.8. 546 5.6. SFC Echo Reply Reception 548 An SFF SHOULD NOT accept SFC Echo Reply unless the received passes 549 the following checks: 551 o the received SFC Echo Reply is well-formed; 553 o it has outstanding SFC Echo Request sent from the UDP port that 554 matches destination UDP port number of the received packet; 556 o if the matching to the Echo Request found, the value of the 557 Sender's Handle n the Echo Request sent is equal to the value of 558 Sender's Handle in the Echo Reply received; 560 o if all checks passed, the SFF checks if the Sequence Number in the 561 Echo Request sent matches to the Sequence Number in the Echo Reply 562 received. 564 6. Security Considerations 566 When the integrity protection for SFC active OAM, and SFC Echo 567 Request/Reply in particular, is required, it is RECOMMENDED to use 568 one of Context Headers defined in [I-D.ietf-sfc-nsh-integrity]. 569 MAC#1 (Message Authentication Code) Context Header could be more 570 suitable for active SFC OAM because it does not require re- 571 calculation of the MAC when the value of the NSH Base Header's TTL 572 field is changed. The integrity protection for SFC active OAM can 573 also be achieved using mechanisms in the underlay data plane. For 574 example, if the underlay is an IPv6 network, IP Authentication Header 575 [RFC4302] or IP Encapsulating Security Payload Header [RFC4303] can 576 be used to provide integrity protection. Confidentiality for the SFC 577 Echo Request/Reply exchanges can be achieved using the IP 578 Encapsulating Security Payload Header [RFC4303]. Also, the security 579 needs for SFC Echo Request/Reply are similar to those of ICMP ping 580 [RFC0792], [RFC4443] and MPLS LSP ping [RFC8029]. 582 There are at least three approaches to attacking a node in the 583 overlay network using the mechanisms defined in the document. One is 584 a Denial-of-Service attack, sending an SFC Echo Request to overload 585 an element of the SFC. The second may use spoofing, hijacking, 586 replying, or otherwise tampering with SFC Echo Requests and/or 587 replies to misrepresent, alter the operator's view of the state of 588 the SFC. The third is an unauthorized source using an SFC Echo 589 Request/Reply to obtain information about the SFC and/or its 590 elements, e.g. SFF or SF. 592 It is RECOMMENDED that implementations throttle the SFC ping traffic 593 going to the control plane to mitigate potential Denial-of-Service 594 attacks. 596 Reply and spoofing attacks involving faking or replying to SFC Echo 597 Reply messages would have to match the Sender's Handle and Sequence 598 Number of an outstanding SFC Echo Request message, which is highly 599 unlikely. Thus the non-matching reply would be discarded. 601 To protect against unauthorized sources trying to obtain information 602 about the overlay and/or underlay, an implementation MAY check that 603 the source of the Echo Request is indeed part of the SFP. 605 7. Acknowledgments 607 Authors greatly appreciate thorough review and the most helpful 608 comments from Dan Wing and Dirk von Hugo. 610 8. IANA Considerations 612 8.1. SFC Active OAM Protocol 614 IANA is requested to assign a new type from the SFC Next Protocol 615 registry as follows: 617 +-------+----------------+---------------+ 618 | Value | Description | Reference | 619 +-------+----------------+---------------+ 620 | TBA1 | SFC Active OAM | This document | 621 +-------+----------------+---------------+ 623 Table 1: SFC Active OAM Protocol 625 8.2. SFC Active OAM Message Type 627 IANA is requested to create a new registry called "SFC Active OAM 628 Message Type". All code points in the range 1 through 32767 in this 629 registry shall be allocated according to the "IETF Review" procedure 630 specified in [RFC8126]. Remaining code points to be allocated 631 according to Table 2: 633 +---------------+-------------+-------------------------+ 634 | Value | Description | Reference | 635 +---------------+-------------+-------------------------+ 636 | 0 | Reserved | | 637 | 1 - 32767 | Reserved | IETF Consensus | 638 | 32768 - 65530 | Reserved | First Come First Served | 639 | 65531 - 65534 | Reserved | Private Use | 640 | 65535 | Reserved | | 641 +---------------+-------------+-------------------------+ 643 Table 2: SFC Active OAM Message Type 645 IANA is requested to assign a new type from the SFC Active OAM 646 Message Type registry as follows: 648 +-------+-----------------------------+---------------+ 649 | Value | Description | Reference | 650 +-------+-----------------------------+---------------+ 651 | TBA2 | SFC Echo Request/Echo Reply | This document | 652 +-------+-----------------------------+---------------+ 654 Table 3: SFC Echo Request/Echo Reply Type 656 8.3. SFC Echo Request/Echo Reply Parameters 658 IANA is requested to create a new SFC Echo Request/Echo Reply 659 Parameters registry. 661 8.4. SFC Echo Request/Echo Reply Message Types 663 IANA is requested to create in the SFC Echo Request/Echo Reply 664 Parameters registry the new sub-registry Message Types. All code 665 points in the range 1 through 175 in this registry shall be allocated 666 according to the "IETF Review" procedure specified in [RFC8126]. 667 Code points in the range 176 through 239 in this registry shall be 668 allocated according to the "First Come First Served" procedure 669 specified in [RFC8126]. The remaining code points are allocated 670 according to Table 4: as specified in Table 4. 672 +-----------+--------------+---------------+ 673 | Value | Description | Reference | 674 +-----------+--------------+---------------+ 675 | 0 | Reserved | This document | 676 | 1- 175 | Unassigned | This document | 677 | 176 - 239 | Unassigned | This document | 678 | 240 - 251 | Experimental | This document | 679 | 252 - 254 | Private Use | This document | 680 | 255 | Reserved | This document | 681 +-----------+--------------+---------------+ 683 Table 4: SFC Echo Request/Echo Reply Message Types 685 IANA is requested to assign values as listed in Table 5. 687 +-------+------------------+---------------+ 688 | Value | Description | Reference | 689 +-------+------------------+---------------+ 690 | TBA3 | SFC Echo Request | This document | 691 | TBA4 | SFC Echo Reply | This document | 692 +-------+------------------+---------------+ 694 Table 5: SFC Echo Request/Echo Reply Message Types Values 696 8.5. SFC Echo Reply Modes 698 IANA is requested to create in the SFC Echo Request/Echo Reply 699 Parameters registry the new sub-registry Reply Mode. All code points 700 in the range 1 through 175 in this registry shall be allocated 701 according to the "IETF Review" procedure specified in [RFC8126]. 702 Code points in the range 176 through 239 in this registry shall be 703 allocated according to the "First Come First Served" procedure 704 specified in [RFC8126]. The remaining code points are allocated 705 according to Table 6: as specified in Table 6. 707 +-----------+--------------+---------------+ 708 | Value | Description | Reference | 709 +-----------+--------------+---------------+ 710 | 0 | Reserved | This document | 711 | 1- 175 | Unassigned | This document | 712 | 176 - 239 | Unassigned | This document | 713 | 240 - 251 | Experimental | This document | 714 | 252 - 254 | Private Use | This document | 715 | 255 | Reserved | This document | 716 +-----------+--------------+---------------+ 718 Table 6: SFC Echo Reply Mode 720 All code points in the range 1 through 191 in this registry shall be 721 allocated according to the "IETF Review" procedure specified in 722 [RFC8126] and assign values as listed in Table 7. 724 +-------+-----------------------------------------------+-----------+ 725 | Value | Description | Reference | 726 +-------+-----------------------------------------------+-----------+ 727 | 0 | Reserved | | 728 | TBA5 | Do Not Reply | This docu | 729 | | | ment | 730 | TBA6 | Reply via an IPv4/IPv6 UDP Packet | This docu | 731 | | | ment | 732 | TBA7 | Reply via Application Level Control Channel | This docu | 733 | | | ment | 734 | TBA8 | Reply via Specified Path | This docu | 735 | | | ment | 736 | TBA9 | Reply via an IPv4/IPv6 UDP Packet with the | This docu | 737 | | data integrity protection | ment | 738 | TBA10 | Reply via Application Level Control Channel | This docu | 739 | | with the data integrity protection | ment | 740 | TBA11 | Reply via Specified Path with the data | This docu | 741 | | integrity protection | ment | 742 +-------+-----------------------------------------------+-----------+ 744 Table 7: SFC Echo Reply Mode Values 746 8.6. SFC Echo Return Codes 748 IANA is requested to create in the SFC Echo Request/Echo Reply 749 Parameters registry the new sub-registry Return Codes as described in 750 Table 8. 752 +---------+-------------+-------------------------+ 753 | Value | Description | Reference | 754 +---------+-------------+-------------------------+ 755 | 0-191 | Unassigned | IETF Review | 756 | 192-251 | Unassigned | First Come First Served | 757 | 252-254 | Unassigned | Private Use | 758 | 255 | Reserved | | 759 +---------+-------------+-------------------------+ 761 Table 8: SFC Echo Return Codes 763 Values defined for the Return Codes sub-registry are listed in 764 Table 9. 766 +-------+-------------------------------------------+---------------+ 767 | Value | Description | Reference | 768 +-------+-------------------------------------------+---------------+ 769 | 0 | No Return Code | This document | 770 | 1 | Malformed Echo Request received | This document | 771 | 2 | One or more of the TLVs was not | This document | 772 | | understood | | 773 | 3 | Authentication failed | This document | 774 +-------+-------------------------------------------+---------------+ 776 Table 9: SFC Echo Return Codes Values 778 8.7. SFC TLV Type 780 IANA is requested to create the SFC OAM TLV Type registry. All code 781 points in the range 1 through 175 in this registry shall be allocated 782 according to the "IETF Review" procedure specified in [RFC8126]. 783 Code points in the range 176 through 239 in this registry shall be 784 allocated according to the "First Come First Served" procedure 785 specified in [RFC8126]. The remaining code points are allocated 786 according to Table 10: 788 +-----------+--------------+---------------+ 789 | Value | Description | Reference | 790 +-----------+--------------+---------------+ 791 | 0 | Reserved | This document | 792 | 1- 175 | Unassigned | This document | 793 | 176 - 239 | Unassigned | This document | 794 | 240 - 251 | Experimental | This document | 795 | 252 - 254 | Private Use | This document | 796 | 255 | Reserved | This document | 797 +-----------+--------------+---------------+ 799 Table 10: SFC OAM TLV Type Registry 801 This document defines the following new values in SFC OAM TLV Type 802 registry: 804 +-------+--------------------+---------------+ 805 | Value | Description | Reference | 806 +-------+--------------------+---------------+ 807 | TBA12 | Multiple TLVs Used | This document | 808 | TBA13 | Source ID TLV | This document | 809 | TBA14 | Errored TLVs | This document | 810 +-------+--------------------+---------------+ 812 Table 11: SFC OAM Type Values 814 8.8. SFC OAM UDP Port 816 IANA is requested to allocate UDP port number according to 818 +--------+-------+-----------+-------------+------------+-----------+ 819 | Servic | Port | Transport | Description | Semantics | Reference | 820 | e Name | Numbe | Protocol | | Definition | | 821 | | r | | | | | 822 +--------+-------+-----------+-------------+------------+-----------+ 823 | SFC | TBA15 | UDP | SFC OAM | Section 5. | This docu | 824 | OAM | | | | 5 | ment | 825 +--------+-------+-----------+-------------+------------+-----------+ 827 Table 12: SFC OAM Port 829 8.9. HMAC Type Sub-registry 831 IANA is requested to create the HMAC Type sub-registry as part of the 832 SFC OAM TLV Type registry. All code points in the range 1 through 833 127 in this registry shall be allocated according to the "IETF 834 Review" procedure specified in [RFC8126]. Code points in the range 835 128 through 239 in this registry shall be allocated according to the 836 "First Come First Served" procedure specified in [RFC8126]. The 837 remaining code points are allocated according to Table 13: 839 +-----------+--------------+---------------+ 840 | Value | Description | Reference | 841 +-----------+--------------+---------------+ 842 | 0 | Reserved | This document | 843 | 1- 127 | Unassigned | This document | 844 | 128 - 239 | Unassigned | This document | 845 | 240 - 249 | Experimental | This document | 846 | 250 - 254 | Private Use | This document | 847 | 255 | Reserved | This document | 848 +-----------+--------------+---------------+ 850 Table 13: HMAC Type Sub-registry 852 This document defines the following new values in the HMAC Type sub- 853 registry: 855 +-------+-----------------------------+---------------+ 856 | Value | Description | Reference | 857 +-------+-----------------------------+---------------+ 858 | 1 | HMAC-SHA-256 16 octets long | This document | 859 +-------+-----------------------------+---------------+ 861 Table 14: HMAC Types 863 9. References 865 9.1. Normative References 867 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 868 Requirement Levels", BCP 14, RFC 2119, 869 DOI 10.17487/RFC2119, March 1997, 870 . 872 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 873 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 874 May 2017, . 876 [RFC8300] Quinn, P., Ed., Elzur, U., Ed., and C. Pignataro, Ed., 877 "Network Service Header (NSH)", RFC 8300, 878 DOI 10.17487/RFC8300, January 2018, 879 . 881 9.2. Informative References 883 [I-D.ietf-sfc-nsh-integrity] 884 Boucadair, M., Reddy.K, T., and D. Wing, "Integrity 885 Protection for the Network Service Header (NSH) and 886 Encryption of Sensitive Context Headers", draft-ietf-sfc- 887 nsh-integrity-02 (work in progress), January 2021. 889 [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, 890 RFC 792, DOI 10.17487/RFC0792, September 1981, 891 . 893 [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, 894 DOI 10.17487/RFC4302, December 2005, 895 . 897 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 898 RFC 4303, DOI 10.17487/RFC4303, December 2005, 899 . 901 [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet 902 Control Message Protocol (ICMPv6) for the Internet 903 Protocol Version 6 (IPv6) Specification", STD 89, 904 RFC 4443, DOI 10.17487/RFC4443, March 2006, 905 . 907 [RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function 908 Chaining (SFC) Architecture", RFC 7665, 909 DOI 10.17487/RFC7665, October 2015, 910 . 912 [RFC7799] Morton, A., "Active and Passive Metrics and Methods (with 913 Hybrid Types In-Between)", RFC 7799, DOI 10.17487/RFC7799, 914 May 2016, . 916 [RFC8029] Kompella, K., Swallow, G., Pignataro, C., Ed., Kumar, N., 917 Aldrin, S., and M. Chen, "Detecting Multiprotocol Label 918 Switched (MPLS) Data-Plane Failures", RFC 8029, 919 DOI 10.17487/RFC8029, March 2017, 920 . 922 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 923 Writing an IANA Considerations Section in RFCs", BCP 26, 924 RFC 8126, DOI 10.17487/RFC8126, June 2017, 925 . 927 [RFC8924] Aldrin, S., Pignataro, C., Ed., Kumar, N., Ed., Krishnan, 928 R., and A. Ghanwani, "Service Function Chaining (SFC) 929 Operations, Administration, and Maintenance (OAM) 930 Framework", RFC 8924, DOI 10.17487/RFC8924, October 2020, 931 . 933 Authors' Addresses 935 Greg Mirsky 936 ZTE Corp. 938 Email: gregimirsky@gmail.com 940 Wei Meng 941 ZTE Corporation 942 No.50 Software Avenue, Yuhuatai District 943 Nanjing 944 China 946 Email: meng.wei2@zte.com.cn 948 Bhumip Khasnabish 949 Individual contributor 951 Email: vumip1@gmail.com 953 Cui Wang 954 Individual contributor 956 Email: lindawangjoy@gmail.com