idnits 2.17.1 draft-ietf-sfc-serviceid-header-14.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 (December 11, 2020) is 1232 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) == Missing Reference: 'ThisDocument' is mentioned on line 401, but not defined ** Downref: Normative reference to an Informational RFC: RFC 7665 == Outdated reference: A later version (-13) exists of draft-ietf-intarea-tunnels-10 == Outdated reference: A later version (-09) exists of draft-ietf-sfc-nsh-integrity-01 Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SFC B. Sarikaya 3 Internet-Draft 4 Intended status: Standards Track D. von Hugo 5 Expires: June 14, 2021 Deutsche Telekom 6 M. Boucadair 7 Orange 8 December 11, 2020 10 Service Function Chaining: Subscriber and Performance Policy 11 Identification Variable-Length Network Service Header (NSH) Context 12 Headers 13 draft-ietf-sfc-serviceid-header-14 15 Abstract 17 This document defines two Variable-Length Context Headers that can be 18 carried in the Network Service Header: the Subscriber and Performance 19 Policy Identifiers. These Context Headers are used to inform Service 20 Functions of subscriber- and performance-related information for the 21 sake of policy enforcement and appropriate service function chaining 22 operations. The structure of each Context Header, and their use and 23 processing by NSH-aware nodes, are described. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at https://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on June 14, 2021. 42 Copyright Notice 44 Copyright (c) 2020 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (https://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 4 61 3. Subscriber Identification NSH Variable-Length Context Header 4 62 4. Performance Policy Identification NSH Variable-Length Context 63 Headers . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 64 5. MTU Considerations . . . . . . . . . . . . . . . . . . . . . 8 65 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 66 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 67 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 68 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 69 9.1. Normative References . . . . . . . . . . . . . . . . . . 11 70 9.2. Informative References . . . . . . . . . . . . . . . . . 12 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 73 1. Introduction 75 This document discusses how to inform Service Functions (SFs) 76 [RFC7665] about subscriber and service policy information, when 77 required for the sake of policy enforcement within a single 78 administrative domain. In particular, subscriber-related information 79 may be required to enforce subscriber-specific SFC-based traffic 80 policies. However, the information carried in packets may not be 81 sufficient to unambiguously identify a subscriber. This document 82 fills this void by specifying a new Network Service Header (NSH) 83 [RFC8300] Context Header to convey and disseminate such information 84 within the boundaries of a single administrative domain. As 85 discussed in Section 3, the use of obfuscated and non-persistent 86 identifiers is recommended. 88 Also, traffic steering by means of SFC may be driven, for example, by 89 QoS (Quality of Service) considerations. Typically, QoS information 90 may serve as an input for the computation, establishment, and 91 selection of the Service Function Path (SFP). Furthermore, the 92 dynamic structuring of service function chains and their subsequent 93 SFPs may be conditioned by QoS requirements that will affect SF 94 instance(s) identification, location, and sequencing. Hence, the 95 need arises to provide downstream SFs with a performance policy 96 identifier in order for them to appropriately meet the QoS service 97 requirements. This document also specifies a new NSH Context Header 98 (Section 4) to convey such policy identifiers. 100 The context information defined in this document can be applicable in 101 the context of mobile networks (particularly, in the 3GPP defined 102 (S)Gi Interface) [I-D.ietf-sfc-use-case-mobility]. Typically, 103 because of the widespread use of private IPv4 addresses in those 104 networks, if the SFs to be invoked are located after a NAT function, 105 the identification based on the internal IPv4 address is not possible 106 once the NAT has been crossed. NAT functionality can reside in a 107 distinct node. For a 4G 3GPP network, that node can be the Packet 108 Data Network (PDN) Gateway (PGW) as specified in [TS23401]. For a 5G 109 3GPP network, it can be the User Plane Function (UPF) facing the 110 external Data Network (DN) [TS23501]. As such, a mechanism to pass 111 the internal information past the NAT boundary may optimise packet 112 traversal within an SFC-enabled mobile network domain. Furthermore, 113 some SFs that are not enabled on the PGW/UPF may require a subscriber 114 identifier to properly operate (see, for example, those listed in 115 [RFC8371]). It is outside the scope of this document to include a 116 comprehensive list of deployments which may make use of the Context 117 Headers defined in the document. 119 Since subscriber identifiers are distinct from those used to identify 120 a performance policy and given that multiple policies may be 121 associated with a single subscriber within a service function chain, 122 these identifiers are carried in distinct Context Headers rather than 123 multiplexing them in one single Context Header. This approach avoids 124 a requirement for additional internal structure in the Context 125 Headers to specify whether an identifier refers to a subscriber or to 126 a policy. 128 This document does not make any assumption about the structure of 129 subscriber or performance policy identifiers; each such identifier is 130 treated as an opaque value. The semantics and validation of these 131 identifiers are policies local to each SFC-enabled domain. This 132 document focuses on the data plane behaviour. Control plane 133 considerations are out of the scope. 135 This document adheres to the SFC data plane architecture defined in 136 [RFC7665]. This document assumes the reader is familiar with 137 [RFC8300]. 139 This document assumes the NSH is used exclusively within a single 140 administrative domain. This document follows the recommendations in 141 [RFC8300] for handling the Context Headers at both ingress and egress 142 SFC boundary nodes (i.e., to strip the entire NSH, including Context 143 Headers). Revealing any subscriber-related information to parties 144 outside the SFC-enabled domain is avoided by design. Accordingly, 145 the scope for privacy breaches and user tracking is limited to within 146 the SFC-enabled domain where the NSH is used. It is assumed that 147 appropriate mechanisms to monitor and audit an SFC-enabled domain to 148 detect misbehavior and to deter misuse are in place. 150 MTU considerations are discussed in Section 5. 152 2. Conventions and Terminology 154 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 155 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 156 "OPTIONAL" in this document are to be interpreted as described in BCP 157 14 [RFC2119][RFC8174] when, and only when, they appear in all 158 capitals, as shown here. 160 The reader should be familiar with the terms defined in [RFC7665]. 162 SFC Control Element refers to a logical entity that instructs one or 163 more SFC data plane functional elements on how to process packets 164 within an SFC-enabled domain. 166 3. Subscriber Identification NSH Variable-Length Context Header 168 Subscriber Identifier is defined as an optional variable-length NSH 169 Context Header. Its structure is shown in Figure 1. 171 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 172 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 173 | Metadata Class | Type |U| Length | 174 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 175 | | 176 ~ Subscriber Identifier ~ 177 | | 178 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 180 Figure 1: Subscriber Identifier Variable-Length Context Header 182 The description of the fields is as follows: 184 o Metadata Class: MUST be set to 0x0 [RFC8300]. 186 o Type: TBD1 (See Section 6). 188 o U bit: Unassigned bit (see Section 2.5.1 of [RFC8300]). 190 o Length: Indicates the length of the Subscriber Identifier, in 191 bytes (see Section 2.5.1 of [RFC8300]). 193 o Subscriber Identifier: Carries an opaque local identifier that is 194 assigned to a subscriber by a network operator. 196 While this document does not specify an internal structure for 197 these identifiers, it also does not provide any cryptographic 198 protection for them; any internal structure to the identifier 199 values chosen will thus be visible on the wire if no secure 200 transport encapsulation is used. Accordingly, in alignment with 201 Section 8.2.2 of [RFC8300], identifier values SHOULD be 202 obfuscated. 204 The Subscriber Identifier Context Header is used by service functions 205 to enforce per-subscriber policies (e.g., resource quota, customized 206 filtering profile, accounting). To that aim, network operators may 207 rely on identifiers that are generated from those used in legacy 208 deployments (e.g., Section 3.3 of [I-D.ietf-sfc-use-case-mobility]). 209 Alternatively, network operators may use identifiers that are 210 associated with customized policy profiles that are preconfigured on 211 SFs using an out of band mechanism. Such mechanism can be used to 212 rotate the identifiers allowing thus for better unlinkability 213 (Section 3.2 of [RFC6973]). Such alternative methods may be 214 suboptimal (e.g., scalability issues induced by maintaining and 215 processing finer granular profiles) or inadequate to provide some 216 per-subscriber policies. The assessment of whether a method for 217 defining a subscriber identifier provides the required functionality 218 and whether it is compatible with the capabilities of the SFs to the 219 intended performance level, is deployment specific. 221 The classifier and NSH-aware SFs MAY inject a Subscriber Identifier 222 Context Header as a function of a local policy. This local policy 223 should indicate the SFP(s) for which the Subscriber Identifier 224 Context Header will be added. In order to prevent interoperability 225 issues, the type and format of the identifiers to be injected in a 226 Subscriber Identifier Context Header should be configured to nodes 227 authorized to inject and consume such headers. For example, a node 228 can be instructed to insert such data following a type/set scheme 229 (e.g., node X should inject subscriber ID type Y). Other schemes may 230 be envisaged. 232 Failures to inject such headers should be logged locally while a 233 notification alarm may be sent to a Control Element. The details of 234 sending notification alarms (i.e., the parameters affecting the 235 transmission of the notification alarms) might depend on the nature 236 of the information in the Context Header. Parameters for sending 237 alarms, such as frequency, thresholds, and content of the alarm, 238 should be configurable. 240 The default behavior of intermediary NSH-aware nodes is to preserve 241 Subscriber Identifier Context Headers (i.e., the information can be 242 passed to next hop NSH-aware nodes), but local policy may require an 243 intermediary NSH-aware node to strip a Subscriber Identifier Context 244 Header after processing it. 246 NSH-aware SFs MUST ignore Context Headers carrying unknown subscriber 247 identifiers. 249 Local policies at NSH-aware SFs may require running additional 250 validation checks on the content of these Context Headers (e.g., 251 accept only some lengths or types). These policies may also indicate 252 the behavior to be followed by an NSH-aware SF if the validation 253 checks fail (e.g., remove the Context Header from the packet). These 254 additional validation checks are deployment-specific. If validation 255 checks fail on a Subscriber Identifier Context Header, an NSH-aware 256 SF MUST ignore that Context Header. The event should be logged 257 locally while a notification alarm may be sent to a Control Element 258 if the NSH-aware SF is instructed to do so. For example, an SF will 259 discard Subscriber Identifier Context Headers conveying identifiers 260 in all formats different from the one the SF is instructed to expect. 262 Multiple Subscriber Identifier Context Headers MAY be present in the 263 NSH, each carrying a distinct opaque value but all pointing to the 264 same subscriber. This may be required, e.g., by policy enforcement 265 mechanisms in a mobile network where some SFs rely on IP addresses as 266 subscriber Identifiers, while others use non-IP specific identifiers 267 such as those listed in [RFC8371] and Section 3.3.2 of 268 [I-D.ietf-sfc-use-case-mobility]. When multiple subscriber 269 identifier Context Headers are present and an SF is instructed to 270 strip the Subscriber Identifier Context Header, that SF MUST remove 271 all Subscriber Identifier Context Headers. 273 4. Performance Policy Identification NSH Variable-Length Context 274 Headers 276 Dedicated service-specific performance identifiers are defined to 277 differentiate between services that require specific treatment in 278 order to exhibit a performance characterized by, e.g., ultra-low 279 latency (ULL) or ultra-high reliability (UHR). Other policies can be 280 considered when instantiating a service function chain within an SFC- 281 enabled domain. They are conveyed in the Performance Policy 282 Identifier Context Header. 284 The Performance Policy Identifier Context Header is inserted in an 285 NSH packet so that downstream NSH-aware nodes can make use of the 286 performance information for proper distributed SFC path selection, SF 287 instance selection, or policy selection at SFs. Note that the use of 288 the Performance Policy Identifier is not helpful if the path 289 computation is centralized and a strict SFP is presented as local 290 policy to SF Forwarders (SFFs). 292 The Performance Policy Identifier allows for the distributed 293 enforcement of a per-service policy such as requiring a service 294 function path to only include specific SFs instances (e.g., SFs 295 located within the same DC or those that are exposing the shortest 296 delay from an SFF). Details of this process are implementation- 297 specific. For illustration purposes, an SFF may retrieve the details 298 of usable SFs based upon the corresponding performance policy 299 identifier. Typical criteria for instantiating specific SFs include 300 location, performance, or proximity considerations. For the 301 particular case of UHR services, the stand-by operation of back-up 302 capacity or the presence of SFs deployed in multiple instances may be 303 requested. 305 In an environment characterised by frequent changes of link and path 306 behaviour, for example due to variable load or availability caused by 307 propagation conditions on a wireless link, the SFP may have to be 308 adapted dynamically by on-the-move SFC path and SF instance 309 selection. 311 Performance Policy Identifier is defined as an optional variable 312 length Context Header. Its structure is shown in Figure 2. 314 The default behavior of intermediary NSH-aware nodes is to preserve 315 such Context Headers (i.e., the information can be passed to next hop 316 NSH-aware nodes), but local policy may require an intermediary NSH- 317 aware node to strip one after processing it. 319 Multiple Performance Policy Identifier Context Headers MAY be present 320 in the NSH, each carrying an opaque value for a distinct policy that 321 need to be enforced for a flow. Supplying conflicting policies may 322 complicate the SFP computation and SF instance location. 323 Corresponding rules to detect conflicting policies may be provided as 324 a local policy to the NSH-aware nodes. When such conflict is 325 detected by an NSH-aware node, the default behavior of the node is to 326 discard the packet and send a notification alarm to a Control 327 Element. 329 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 330 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 331 | Metadata Class | Type |U| Length | 332 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 333 | | 334 ~ Performance Policy Identifier ~ 335 | | 336 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 338 Figure 2: Performance Policy Identifier Variable-Length Context 339 Header 341 The description of the fields is as follows: 343 o Metadata Class: MUST be set to 0x0 [RFC8300]. 345 o Type: TBD2 (See Section 6). 347 o U bit: Unassigned bit (see Section 2.5.1 of [RFC8300]). 349 o Length: Indicates the length of the Performance Policy Identifier, 350 in bytes (see Section 2.5.1 of [RFC8300]). 352 o Performance Policy Identifier: Represents an opaque value pointing 353 to specific performance policy to be enforced. The structure and 354 semantics of this field are deployment-specific. 356 5. MTU Considerations 358 As discussed in Section 5.6 of [RFC7665], the SFC architecture 359 prescribes that additional information be added to packets to: 361 o Identify SFPs: this is typically the NSH Base Header (Section 2.2 362 of [RFC8300]) and Service Path Header (Section 2.3 of [RFC8300]). 364 o Carry metadata such those defined in Sections 3 and 4. 366 o Steer the traffic along the SFPs: transport encapsulation. 368 This added information increases the size of the packet to be carried 369 along an SFP. 371 Aligned with Section 5 of [RFC8300], it is RECOMMENDED for network 372 operators to increase the underlying MTU so that NSH traffic is 373 forwarded within an SFC-enabled domain without fragmentation. The 374 available underlying MTU should be taken into account by network 375 operators when providing SFs with the required Context Headers to be 376 injected per SFP and the size of the data to be carried in these 377 Context Headers. 379 If the underlying MTU cannot be increased to accommodate the NSH 380 overhead, network operators may rely upon a transport encapsulation 381 protocol with the required fragmentation handling. The impact of 382 activating such feature on SFFs should be carefully assessed by 383 network operators (Section 5.6 of [RFC7665]). 385 When dealing with MTU issues, network operators should consider the 386 limitations of various transport encapsulations such as those 387 discussed in [I-D.ietf-intarea-tunnels]. 389 6. IANA Considerations 391 This document requests IANA to assign the following types from the 392 "NSH IETF- Assigned Optional Variable-Length Metadata Types" (0x0000 393 IETF Base NSH MD Class) registry available at: 394 https://www.iana.org/assignments/nsh/nsh.xhtml#optional-variable- 395 length-metadata-types. 397 +-------+-------------------------------+----------------+ 398 | Value | Description | Reference | 399 +-------+-------------------------------+----------------+ 400 | TBD1 | Subscriber Identifier | [ThisDocument] | 401 | TBD2 | Performance Policy Identifier | [ThisDocument] | 402 +-------+-------------------------------+----------------+ 404 7. Security Considerations 406 Data plane SFC-related security considerations, including privacy, 407 are discussed in Section 6 of [RFC7665] and Section 8 of [RFC8300]. 408 In particular, Section 8.2.2 of [RFC8300] states that attached 409 metadata (i.e., Context Headers) should be limited to that necessary 410 for correct operation of the SFP. That section indicates that 411 metadata considerations that operators can take into account when 412 using NSH are discussed in [RFC8165]. 414 As specified in [RFC8300], means to prevent leaking privacy-related 415 information outside an SFC-enabled domain are natively supported by 416 the NSH given that the last SFF of an SFP will systematically remove 417 the NSH (and therefore the identifiers defined in this specification) 418 before forwarding a packet exiting the SFP. 420 Nodes that are involved in an SFC-enabled domain are assumed to be 421 trusted (Section 1.1 of [RFC8300]). Means to check that only 422 authorized nodes are traversed when a packet is crossing an SFC- 423 enabled domain are out of scope of this document. 425 Both Subscriber Identifier and Performance Policy Context Headers 426 carry opaque data. This identifier is locally assigned by a network 427 provider and can be generated from some of the information that is 428 already conveyed in the original packets from a host (e.g., internal 429 IP address) or other information that is collected from various 430 sources within an SFC-enabled domain (e.g., line identifier). The 431 structure of the identifiers conveyed in these Context Headers is 432 communicated only to entitled NSH-aware nodes. Nevertheless, some 433 structures may be easily inferred from the headers if trivial 434 structures are used (e.g., IP addresses). As persistent identifiers 435 facilitate tracking over time, the use of indirect and non-persistent 436 identification is thus RECOMMENDED. 438 Moreover, the presence of multiple Subscriber Identifier Context 439 Headers in the same NSH allows a misbehaving node from within the 440 SFC-enabled domain to bind these identifiers to the same subscriber. 441 This can be used to track that subscriber more effectively. The use 442 of non persistent (e.g., regularly randomized) identifiers as well as 443 the removal of the Subscriber Identifier Context Headers from the NSH 444 by the last SF making use of such headers soften this issue (see 445 "data minimization" discussed in Section 3 of [RFC8165]). Such 446 behavior is especially strongly recommended, in case no encryption is 447 enabled. 449 A misbehaving node from within the SFC-enabled domain may alter the 450 content of Subscriber Identifier and Performance Policy Context 451 Headers which may lead to service disruption. Such attack is not 452 unique to the Context Headers defined in this document; measures 453 discussed in Section 8 of [RFC8300] are to be followed. A mechanism 454 for NSH integrity is specified in [I-D.ietf-sfc-nsh-integrity]. 456 If no secure transport encapsulation is enabled, the use of trivial 457 subscriber identifier structures together with the presence of 458 specific SFs in a service function chain may reveal sensitive 459 information to every on-path device. Also operational staff in teams 460 managing these devices could gain access to such user privacy 461 affecting data. Such disclosure can be a violation of legal 462 requirements because such information should be available to very few 463 network operator personnel. Furthermore, access to subscriber data 464 usually requires specific access privilege levels. To maintain that 465 protection, an SF keeping operational logs should not log the content 466 of a Subscriber and Performance Policy Context Headers unless the SF 467 actually uses the content of these headers for its operation. As 468 discussed in Section 8.2.2 of [RFC8300], subscriber-identifying 469 information should be obfuscated and, if an operator deems 470 cryptographic integrity protection needed, security features in the 471 transport encapsulation protocol (such as IPsec) must be used. A 472 mechanism for encrypting sensitive NSH data is specified in 474 [I-D.ietf-sfc-nsh-integrity]. This mechanism can be considered by 475 network operators when enhanced SF-to-SF security protection of NSH 476 metadata is required (e.g., protect against compromised SFFs). 478 Some events are logged locally with notification alerts sent by NSH- 479 aware nodes to a Control Element. These events SHOULD be rate 480 limited. 482 8. Acknowledgements 484 Comments from Joel Halpern on a previous version and by Carlos 485 Bernardos are appreciated. 487 Contributions and review by Christian Jacquenet, Danny Lachos, 488 Debashish Purkayastha, Christian Esteve Rothenberg, Kyle Larose, 489 Donald Eastlake, Qin Wu, Shunsuke Homma, and Greg Mirsky are 490 thankfully acknowledged. 492 Many thanks to Robert Sparks for the secdir review. 494 Thanks to Barry Leiba, Erik Kline, Eric Vyncke, Robert Wilton, and 495 Magnus Westerlund for the IESG review. 497 Special thanks to Benjamin Kaduk for the careful review and 498 suggestions that enhanced this specification. 500 9. References 502 9.1. Normative References 504 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 505 Requirement Levels", BCP 14, RFC 2119, 506 DOI 10.17487/RFC2119, March 1997, 507 . 509 [RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function 510 Chaining (SFC) Architecture", RFC 7665, 511 DOI 10.17487/RFC7665, October 2015, 512 . 514 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 515 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 516 May 2017, . 518 [RFC8300] Quinn, P., Ed., Elzur, U., Ed., and C. Pignataro, Ed., 519 "Network Service Header (NSH)", RFC 8300, 520 DOI 10.17487/RFC8300, January 2018, 521 . 523 9.2. Informative References 525 [I-D.ietf-intarea-tunnels] 526 Touch, J. and M. Townsley, "IP Tunnels in the Internet 527 Architecture", draft-ietf-intarea-tunnels-10 (work in 528 progress), September 2019. 530 [I-D.ietf-sfc-nsh-integrity] 531 Boucadair, M., Reddy.K, T., and D. Wing, "Integrity 532 Protection for the Network Service Header (NSH) and 533 Encryption of Sensitive Context Headers", draft-ietf-sfc- 534 nsh-integrity-01 (work in progress), November 2020. 536 [I-D.ietf-sfc-use-case-mobility] 537 Haeffner, W., Napper, J., Stiemerling, M., Lopez, D., and 538 J. Uttaro, "Service Function Chaining Use Cases in Mobile 539 Networks", draft-ietf-sfc-use-case-mobility-09 (work in 540 progress), January 2019. 542 [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., 543 Morris, J., Hansen, M., and R. Smith, "Privacy 544 Considerations for Internet Protocols", RFC 6973, 545 DOI 10.17487/RFC6973, July 2013, 546 . 548 [RFC8165] Hardie, T., "Design Considerations for Metadata 549 Insertion", RFC 8165, DOI 10.17487/RFC8165, May 2017, 550 . 552 [RFC8371] Perkins, C. and V. Devarapalli, "Mobile Node Identifier 553 Types for MIPv6", RFC 8371, DOI 10.17487/RFC8371, July 554 2018, . 556 [TS23401] 3GPP 23.401 16.5.0, "General Packet Radio Service (GPRS) 557 enhancements for Evolved Universal Terrestrial Radio 558 Access Network (E-UTRAN) access,", December 2019. 560 [TS23501] 3GPP 23.501 16.3.0, "System architecture for the 5G System 561 (5GS),", December 2019. 563 Authors' Addresses 565 Behcet Sarikaya 567 Email: sarikaya@ieee.org 568 Dirk von Hugo 569 Deutsche Telekom 570 Deutsche-Telekom-Allee 9 571 D-64295 Darmstadt 572 Germany 574 Email: Dirk.von-Hugo@telekom.de 576 Mohamed Boucadair 577 Orange 578 Rennes 3500 579 France 581 Email: mohamed.boucadair@orange.com