idnits 2.17.1 draft-ao-sfc-oam-return-path-specified-09.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 (30 March 2021) is 1122 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-28) exists of draft-ietf-sfc-multi-layer-oam-09 == Outdated reference: A later version (-09) exists of draft-ietf-sfc-nsh-integrity-05 Summary: 0 errors (**), 0 flaws (~~), 3 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 Intended status: Standards Track T. Ao 5 Expires: 1 October 2021 Individual contributor 6 Z. Chen 7 China Telecom 8 G. Mishra 9 Verizon Inc. 10 30 March 2021 12 Controlled Return Path for Service Function Chain (SFC) OAM 13 draft-ao-sfc-oam-return-path-specified-09 15 Abstract 17 This document defines an extension to the Service Function Chain 18 (SFC) Operation, Administration and Maintenance (OAM) that enables 19 control of the Echo Reply return path directing it over a Reverse 20 Service Function Path. Enforcing the specific return path can be 21 used to verify the bidirectional connectivity of SFC and increase the 22 robustness of SFC OAM. 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 1 October 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 (https://trustee.ietf.org/ 48 license-info) in effect on the date of publication of this document. 49 Please review these documents carefully, as they describe your rights 50 and restrictions with respect to this document. Code Components 51 extracted from this document must include Simplified BSD License text 52 as described in Section 4.e of the Trust Legal Provisions and are 53 provided without warranty as described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 58 2. Conventions used in this document . . . . . . . . . . . . . . 3 59 2.1. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . 3 60 2.2. Requirements Language . . . . . . . . . . . . . . . . . . 3 61 3. Extension . . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 4. SFC Reply Path TLV . . . . . . . . . . . . . . . . . . . . . 4 63 5. Theory of Operation . . . . . . . . . . . . . . . . . . . . . 5 64 5.1. Bi-directional SFC Case . . . . . . . . . . . . . . . . . 6 65 6. Security Considerations . . . . . . . . . . . . . . . . . . . 6 66 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 67 7.1. SFC Return Path Type . . . . . . . . . . . . . . . . . . 6 68 7.2. New Return Codes . . . . . . . . . . . . . . . . . . . . 7 69 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 70 8.1. Normative References . . . . . . . . . . . . . . . . . . 7 71 8.2. Informative References . . . . . . . . . . . . . . . . . 8 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 74 1. Introduction 76 While Service Function Chain (SFC) Echo Request, defined in 77 [I-D.ietf-sfc-multi-layer-oam], always traverses the SFC it directed 78 to, the corresponding Echo Reply is sent over IP network 79 [I-D.ietf-sfc-multi-layer-oam]. There are scenarios when it is 80 beneficial to direct the responder to use a path other than the IP 81 network. This document extends Service Function Chain (SFC) 82 Operation, Administration and Maintenance (OAM) by enabling control 83 of the Echo Reply return path to be directed over a Reply Service 84 Function Path (SFP). Such an extension is based on the analysis of 85 SFC OAM, active OAM protocols, in particular, provided in [RFC8924]. 86 This document defines a new Type-Length-Value (TLV), Reply Service 87 Function Path TLV, for Reply via Specified Path mode of SFC Echo 88 Reply (Section 4). 90 The Reply Service Function Path TLV can provide an efficient 91 mechanism to test SFCs, such as bidirectional and hybrid SFC, as 92 defined in Section 2.2 [RFC7665]. For example, it allows an operator 93 to test both directions of the bidirectional or hybrid SFP with a 94 single SFC Echo Request/Echo Reply operation. 96 2. Conventions used in this document 98 2.1. Acronyms 100 SF - Service Function 102 SFF - Service Function Forwarder 104 SFC - Service Function Chain, an ordered set of some abstract SFs. 106 SFP - Service Function Path 108 SPI - Service Path Index 110 OAM - Operation, Administration, and Maintenance 112 MAC - Message Authentication Code 114 2.2. Requirements Language 116 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 117 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 118 "OPTIONAL" in this document are to be interpreted as described in BCP 119 14 [RFC2119] [RFC8174] when, and only when, they appear in all 120 capitals, as shown here. 122 3. Extension 124 The following reply modes had been defined in 125 [I-D.ietf-sfc-multi-layer-oam]: 127 * Do Not Reply 129 * Reply via an IPv4/IPv6 UDP Packet 131 * Reply via Application Level Control Channel 133 * Reply via Specified Path 135 The Reply via Specified Path mode is intended to enforce the use of 136 the particular return path specified in the included TLV. This mode 137 may help verify bidirectional continuity or increase SFC monitoring's 138 robustness by selecting a more stable path. In SFC's case, the 139 sender of Echo Request instructs the destination SFF to send Echo 140 Reply message along the SFP specified in the SFC Reply Path TLV, as 141 described in Section 4. 143 4. SFC Reply Path TLV 145 The SFC Reply Path TLV carries the information that sufficiently 146 identifies the return SFP that the SFC Echo Reply message is expected 147 to follow. The format of SFC Reply Path TLV is shown in Figure 1. 149 0 1 2 3 150 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 151 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 152 |SFC Reply Path | Reserved | Length | 153 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 154 | Reply Service Function Path | 155 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 157 Figure 1: SFC Reply TLV Format 159 where: 161 * Reply Path TLV Type: is a one-octet-long, indicates the TLV that 162 contains information about the SFC Reply path. 164 * Reserved - one-octet-long field. 166 * Length: is two octets long, MUST be equal to 4 168 * Reply Service Function Path is used to describe the return path 169 that an SFC Echo Reply is requested to follow. 171 The format of the Reply Service Function Path field displayed in 172 Figure 2 174 0 1 2 3 175 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 176 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 177 | Reply Service Function Path Identifier | Service Index | 178 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 180 Figure 2: Reply Service Function Path Field Format 182 where: 184 * Reply Service Function Path Identifier: SFP identifier for the 185 path that the SFC Echo Reply message is requested to be sent over. 187 * Service Index: the value for the Service Index field in the NSH of 188 the SFC Echo Reply message. 190 5. Theory of Operation 192 [RFC7110] defined mechanism to control return path for MPLS LSP Echo 193 Reply. In SFC's case, the return path is an SFP along which the SFC 194 Echo Reply message MUST be transmitted. Hence, the SFC Reply Path 195 TLV included in the SFC Echo Request message MUST sufficiently 196 identify the SFP that the sender of the Echo Request message expects 197 the receiver to use for the corresponding SFC Echo Reply. 199 When sending an Echo Request, the sender MUST set the value of Reply 200 Mode field to "Reply via Specified Path", defined in 201 [I-D.ietf-sfc-multi-layer-oam], and if the specified path is SFC 202 path, the Request MUST include SFC Reply Path TLV. The SFC Reply 203 Path TLV includes the identifier of the reverse SFP and an 204 appropriate Service Index. 206 The Message Authentication Code (MAC) Context Header that is defined 207 in [I-D.ietf-sfc-nsh-integrity] MAY be used to protect the SFC Echo 208 Request's integrity when using the SFC Return Path TLV. If the NSH 209 of the received SFC Echo Request includes the MAC Context Header, the 210 packet's authentication MUST be verified before using any data. If 211 the verification fails, the receiver MUST stop processing the SFC 212 Return Path TLV and MUST send the SFC Echo Reply with the Return 213 Codes value set to the value Authentication failed from the IANA's 214 Return Codes sub-registry of the SFC Echo Request/Echo Reply 215 Parameters registry. 217 Echo Reply is expected to be sent by the destination SFF of the SFP 218 being tested or by the SFF at which SFC TTL expires as defined 219 [RFC8300]. The processing described below equally applies to both 220 cases and is referred to as responding SFF. 222 If the Echo Request message with SFC Reply Path TLV, received by the 223 responding SFF, has Reply Mode value of "Reply via Specified Path" 224 but no SFC Reply Path TLV is present, then the responding SFF MUST 225 send Echo Reply with Return Code set to "Reply Path TLV is missing" 226 value (TBA2). If the responding SFF cannot find the requested SFP it 227 MUST send Echo Reply with Return Code set to "Reply SFP was not 228 found" (TBA3) and include the SFC Reply Path TLV from the Echo 229 Request message. 231 Suppose the SFC Echo Request receiver cannot determine whether the 232 specified return path SFP has the route to the initiator. In that 233 case, it SHOULD set the value of the Return Codes field to 234 "Unverifiable Reply Path" (TBA4). The receiver MAY drop the Echo 235 Request when it cannot determine whether SFP's return path has the 236 route to the initiator. That means, when sending Echo Request, the 237 sender SHOULD choose a proper source address according to specified 238 return path SFP to help the receiver to make the decision. 240 5.1. Bi-directional SFC Case 242 The ability to specify the return path for an Echo Reply might be 243 used in the case of bi-directional SFC. The egress SFF of the 244 forward SFP might not be co-located with a classifier of the reverse 245 SFP, and thus the egress SFF has no information about the reverse 246 path of an SFC. Because of that, even for bi-directional SFC, a 247 reverse SFP needs to be indicated in a Reply Path TLV in the Echo 248 Request message. 250 6. Security Considerations 252 Security considerations discussed in [RFC8300] apply to this 253 document. 255 The SFC Return Path extension, defined in this document, can be used 256 for potential "proxying" attacks. For example, the Echo Request 257 initiator may specify a return path with a destination different from 258 that of the initiator. Such attacks will usually not happen in an 259 SFC domain where the initiators and receivers belong to the same 260 domain, as specified in [RFC7665]. Even if the attack occurs, to 261 prevent using the SFC Return Path extension for proxying any possible 262 attacks, the return path SFP SHOULD have a path to reach the sender 263 of the Echo Request, identified in SFC Source TLV 264 [I-D.ietf-sfc-multi-layer-oam]. The MAC Context Header that is 265 defined in [I-D.ietf-sfc-nsh-integrity] MAY be used to protect the 266 integrity of the SFC Echo Request/Reply when using the SFC Return 267 Path TLV. 269 7. IANA Considerations 271 7.1. SFC Return Path Type 273 IANA is requested to assign from its SFC Echo Request/Echo Reply TLV 274 registry new type as follows: 276 +=======+======================+===============+ 277 | Value | Description | Reference | 278 +=======+======================+===============+ 279 | TBA1 | SFC Reply Path Type | This document | 280 +-------+----------------------+---------------+ 282 Table 1: SFC Return Path Type 284 7.2. New Return Codes 286 IANA is requested to assign new return codes from the SFC Echo 287 Request/Echo Reply Return Codes sub-registry of the SFC Echo Request/ 288 Echo Reply Parameters registry as defined in Table 2. 290 +=======+============================+===============+ 291 | Value | Description | Reference | 292 +=======+============================+===============+ 293 | TBA2 | Reply Path TLV is missing | This document | 294 +-------+----------------------------+---------------+ 295 | TBA3 | Reply SFP was not found | This document | 296 +-------+----------------------------+---------------+ 297 | TBA4 | Unverifiable Reply Path | This document | 298 +-------+----------------------------+---------------+ 300 Table 2: SFC Echo Reply Return Codes 302 8. References 304 8.1. Normative References 306 [I-D.ietf-sfc-multi-layer-oam] 307 Mirsky, G., Meng, W., Khasnabish, B., and C. Wang, "Active 308 OAM for Service Function Chaining", Work in Progress, 309 Internet-Draft, draft-ietf-sfc-multi-layer-oam-09, 11 310 February 2021, . 313 [I-D.ietf-sfc-nsh-integrity] 314 Boucadair, M., Reddy, T., and D. Wing, "Integrity 315 Protection for the Network Service Header (NSH) and 316 Encryption of Sensitive Context Headers", Work in 317 Progress, Internet-Draft, draft-ietf-sfc-nsh-integrity-05, 318 23 March 2021, . 321 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 322 Requirement Levels", BCP 14, RFC 2119, 323 DOI 10.17487/RFC2119, March 1997, 324 . 326 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 327 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 328 May 2017, . 330 [RFC8300] Quinn, P., Ed., Elzur, U., Ed., and C. Pignataro, Ed., 331 "Network Service Header (NSH)", RFC 8300, 332 DOI 10.17487/RFC8300, January 2018, 333 . 335 8.2. Informative References 337 [RFC7110] Chen, M., Cao, W., Ning, S., Jounay, F., and S. Delord, 338 "Return Path Specified Label Switched Path (LSP) Ping", 339 RFC 7110, DOI 10.17487/RFC7110, January 2014, 340 . 342 [RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function 343 Chaining (SFC) Architecture", RFC 7665, 344 DOI 10.17487/RFC7665, October 2015, 345 . 347 [RFC8924] Aldrin, S., Pignataro, C., Ed., Kumar, N., Ed., Krishnan, 348 R., and A. Ghanwani, "Service Function Chaining (SFC) 349 Operations, Administration, and Maintenance (OAM) 350 Framework", RFC 8924, DOI 10.17487/RFC8924, October 2020, 351 . 353 Authors' Addresses 355 Greg Mirsky 356 ZTE Corp. 358 Email: gregimirsky@gmail.com, gregory.mirsky@ztetx.com 360 Ting Ao 361 Individual contributor 362 No.889, BiBo Road 363 Shanghai 364 201203 365 China 367 Phone: +86 17721209283 368 Email: 18555817@qq.com 370 Zhonghua Chen 371 China Telecom 372 No.1835, South PuDong Road 373 Shanghai 374 201203 375 China 377 Phone: +86 18918588897 378 Email: 18918588897@189.cn 380 Gyan Mishra 381 Verizon Inc. 383 Email: gyan.s.mishra@verizon.com