idnits 2.17.1 draft-sfc-serviceid-header-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (November 14, 2018) is 1962 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 293, but not defined ** Downref: Normative reference to an Informational RFC: RFC 7665 == Outdated reference: A later version (-18) exists of draft-ietf-bess-nsh-bgp-control-plane-04 == Outdated reference: A later version (-09) exists of draft-ietf-sfc-use-case-mobility-08 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 M. Boucadair 3 Internet-Draft Orange 4 Intended status: Standards Track D. von Hugo 5 Expires: May 18, 2019 Deutsche Telekom 6 B. Sarikaya 7 Denpel Informatique 8 November 14, 2018 10 Service Function Chaining: Subscriber and Policy Identification 11 Variable-Length Network Service Header (NSH) Context Headers 12 draft-sfc-serviceid-header-02 14 Abstract 16 This document discusses how to inform Service Functions about 17 subscriber- and service-related information for the sake of policy 18 enforcement and appropriate service function chaining operations. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at https://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on May 18, 2019. 37 Copyright Notice 39 Copyright (c) 2018 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (https://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 3 56 3. Subscriber Identification NSH Variable-Length Context Header 4 57 4. Policy Identification NSH Variable-Length Context Headers . . 5 58 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 59 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 60 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 61 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 62 8.1. Normative References . . . . . . . . . . . . . . . . . . 7 63 8.2. Informative References . . . . . . . . . . . . . . . . . 8 64 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 66 1. Introduction 68 This document discusses how to inform Service Functions (SFs) about 69 subscriber- and service-related information when required for the 70 sake of policy enforcement within a single administrative domain. 71 Particularly, subscriber-related information may be required to 72 enforce subscriber-specific SFC-based traffic policies. 73 Nevertheless, the information carried in packets may not be 74 sufficient to unambiguously identify a subscriber. This document 75 fills this void by specifying a new Network Service Header (NSH) 76 [RFC8300] context header to convey and disseminate such information. 78 Also, the enforcement of SFC-based differentiated traffic policies 79 may be inferred by QoS considerations. Typically, QoS information 80 may serve as an input to classification of the Service Function Path 81 (SFP) for path computation, establishment, and selection. 82 Furthermore, the dynamic structuring of service function chains and 83 their subsequent enforcement may be conditioned by QoS requirements 84 that will affect SF instance identification, location, and 85 sequencing. Hence, the need to supply a policy identifier to 86 upstream SFs to appropriately meet the service requirements. 88 SFs and SF Forwarders (SFFs) involved in a service chain have to 89 contribute to the respective service policy (QoS, for example) 90 requirements characterized by low transmission delay between each 91 other, by exposing a high availability of resources to process 92 function tasks, or by redundancy provided by stand-by machines for 93 seamless execution continuation in case of failures. These 94 requirements may be satisfied by means of control protocols, but in 95 some contexts, (e.g., in networks where resources are very much 96 constrained), carrying QoS-related information directly in packets 97 may improve the overall SFC operation instead of relying upon the 98 potential complexity or adding overhead introduced by some SFC 99 control plane features. This information is typically included as 100 metadata in the NSH as the SFC encapsulation to provide the SFP 101 identification. 103 The context information defined in this document can be applicable in 104 the context of mobile networks (typically, in the 3GPP defined (S)Gi 105 Interface) [I-D.ietf-sfc-use-case-mobility]. Because of the 106 widespread use of private addressing in those networks, if SFs to be 107 invoked are located after a NAT function (that can reside in the 108 Packet Data Network (PDN) Gateway (PGW) or in a distinct node), the 109 identification based on the internal IP address is not anymore 110 possible once the NAT has been crossed. As such, means to allow 111 passing the internal information may optimise packet traversal within 112 an SFC-enabled mobile network domain. Furthermore, some SFs that are 113 not enabled on the PGW may require a subscriber identifier to 114 properly operate. 116 This document does not make any assumption about the structure of 117 subscriber or policy identifiers; each such identifier is treated as 118 an opaque value by the SFC operations and protocols. The semantics 119 and validation of these identifiers are up to the control plane used 120 for SFC. Expectations to SFC control plane protocols are laid down, 121 e.g., in [RFC8459], but specifications of SFC control plane 122 functionalities are also discussed in, for example, 123 [I-D.ietf-bess-nsh-bgp-control-plane], 124 [I-D.wu-pce-traffic-steering-sfc], or [I-D.maglione-sfc-nsh-radius]. 126 The use cases considered in this document assume the NSH is used 127 exclusively within a single administrative domain. 129 This document adheres to the architecture defined in [RFC7665]. This 130 document assumes the reader is familiar with [RFC8300]. 132 2. Conventions and Terminology 134 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 135 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 136 "OPTIONAL" in this document are to be interpreted as described in BCP 137 14 [RFC2119][RFC8174] when, and only when, they appear in all 138 capitals, as shown here. 140 The reader should be familiar with the terms defined in [RFC7665]. 142 3. Subscriber Identification NSH Variable-Length Context Header 144 Subscriber Identifier is defined as an optional variable-length NSH 145 context header. Its structure is shown in Figure 1. 147 The subscriber identifier is used to convey an identifier already 148 assigned by the service provider to uniquely identify a subscriber. 149 This header conveys an opaque subscriber Identifier that can be used 150 by the service functions to enforce per-subscriber policies. 152 The classifier and SFC-aware SFs MAY be instructed via a control 153 interface to inject or strip a subscriber identifier context header. 154 Also, the data to be injected in such header SHOULD be configured to 155 nodes authorized to inject such headers. Typically, a node can be 156 instructed to insert such data following a type/set scheme (e.g., 157 node X should inject subscriber ID type Y). Other schemes may be 158 envisaged. 160 Failures to inject such headers SHOULD be logged locally while a 161 notification alarm MAY be sent to a Control Element. The details of 162 sending notification alarms (i.e., the parameters affecting the 163 transmission of the notification alarms depend on the information in 164 the context header such as frequency, thresholds, and content in the 165 alarm (full header, header ID, timestamp), etc.) SHOULD be 166 configurable by the control plane. 168 This document adheres to the recommendations in [RFC8300] for 169 handling the context headers at both ingress and egress SFC boundary 170 nodes. That is, to strip such context headers. Revealing any 171 personal and subscriber-related information to third parties is 172 avoided by design to prevent privacy breaches in terms of user 173 tracking. 175 SFC-aware SFs and proxies MAY be instructed to strip a subscriber 176 identifier context header from the packet or to pass the data to the 177 next SF in the service chain after processing the content of the 178 context headers. If no instruction is provided, the default behavior 179 is to maintain such context headers so that the information can be 180 passed to next SFC-aware hops. 182 SFC-aware SFs MAY be instructed via the control plane about the 183 validation checks to run on the content of these context headers 184 (e.g., accept only some lengths) and the behavior to adopt. For 185 example, SFC-aware SFs may be instructed to ignore the context 186 header, to remove the context header from the packet, etc. 187 Nevertheless, this specification does not require nor preclude such 188 additional validation checks. These validation checks are 189 deployment-specific. If validation checks fail on a subscriber 190 identifier context header, an SFC-aware SF MUST ignore that context 191 header. The event SHOULD be logged locally while a notification 192 alarm MAY be sent to a Control Element if the SFC-aware SF is 193 instructed to do so. 195 Multiple subscriber Identifier context TLVs MAY be present in the NSH 196 each carrying a distinct opaque value but all pointing to the same 197 subscriber. When multiple subscriber Identifier context TLVs are 198 present and an SF is instructed to strip the subscriber Identifier 199 context header, that SF has to remove all subscriber Identifier 200 context TLVs. 202 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 203 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 204 | Metadata Class | Type |U| Length | 205 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 206 | | 207 ~ Subscriber Identifier ~ 208 | | 209 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 211 Figure 1: Subscriber Identifier Variable-Length Context Header 213 The description of the fields is as follows: 215 o Metadata Class: MUST be set to 0x0 [RFC8300]. 217 o Type: TBD1 (See Section 5) 219 o Subscriber Identifier: Carries an opaque subscriber identifier. 221 4. Policy Identification NSH Variable-Length Context Headers 223 Dedicated service-specific performance identifier is defined to 224 differentiate between services requiring specific treatment to 225 exhibit a performance characterized by, e.g., ultra-low latency (ULL) 226 or ultra-high reliability (UHR). Other policies can be considered 227 when instantiating a service function chain within an SFC-enabled 228 domain. They are contained in the Policy Identifier context header. 230 The policy identifier is inserted in an NSH packet so that upstream 231 SFC-aware nodes can make use of the information for proper 232 distributed SFC path selection, SF instance selection, or policy 233 selection at SFs. 235 Thus, the policy identifier allows for the distributed enforcement of 236 a per-service policy such as a service function path to only include 237 specific SFs instances. Details of this process are implementation- 238 specific. For illustration purposes, an SFF may retrieve the details 239 of usable SFs based upon the corresponding policy identifier. 240 Typical criteria for instantiating specific SFs include location, 241 performance, or proximity considerations. For the particular case of 242 UHR services, the stand-by operation of back-up capacity or the 243 deployment of multiple SF instances may be requested. 245 Policy identifier is defined as optional variable length context 246 header. Its structure is shown in Figure 2. 248 Similar control plane considerations as those discussed in Section 3 249 are to be followed. 251 Multiple policy identifier context headers MAY be present in the NSH; 252 each carrying a distinct opaque value but all are pointing to 253 policies that need to be enforced for a flow. It is up to the 254 control plane to ensure that these policies are not conflicting. 255 When such conflict is detected by an SFC-aware node, the default 256 behavior of the node is to discard the packet and send a notification 257 alarm to a Control Element. 259 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 260 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 261 | Metadata Class | Type |U| Length | 262 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 263 | | 264 ~ Policy Identifier ~ 265 | | 266 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 268 Figure 2: Policy Identifier Variable-Length Context Header 270 The description of the fields is as follows: 272 o Metadata Class: MUST be set to 0x0 [RFC8300]. 274 o Type: TBD2 (See Section 5) 276 o Policy Identifier: Represents an opaque value pointing to specific 277 policy to be enforced. The structure and semantic of this filed 278 is deployment-specific. 280 5. IANA Considerations 282 This document requests IANA to assign the following types from the 283 "NSH IETF- Assigned Optional Variable-Length Metadata Types" (0x0000 284 IETF Base NSH MD Class) registry available at: 286 https://www.iana.org/assignments/nsh/nsh.xhtml#optional-variable- 287 length-metadata-types. 289 +-------+-----------------------+----------------+ 290 | Value | Description | Reference | 291 +-------+-----------------------+----------------+ 292 | TBD1 | Subscriber Identifier | [ThisDocument] | 293 | TBD2 | Policy Identifier | [ThisDocument] | 294 +-------+-----------------------+----------------+ 296 6. Security Considerations 298 Data plane SFC-related security considerations, including privacy, 299 are discussed in [RFC7665] and [RFC8300]. 301 Nodes that are involved in an SFC-enabled domain are assumed to be 302 trusted ([RFC8300]). Means to check that only authorized nodes are 303 solicited when a packet is crossing an SFC-enabled domain. 305 An SF maintaining logs for operational reasons MUST NOT log the 306 content of subscriber identifier context header received in NSH 307 packets if the SF does not use the content of that header for its 308 operation. 310 7. Acknowledgements 312 Comments from Joel Halpern on a previous version and by Carlos 313 Bernardos are appreciated. Contributions and review by Christian 314 Jacquenet, Danny Lachos, Debashish Purkayastha, Christian Esteve 315 Rothenberg, and Kyle Larose are thankfully acknowledged. 317 8. References 319 8.1. Normative References 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 [RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function 327 Chaining (SFC) Architecture", RFC 7665, 328 DOI 10.17487/RFC7665, October 2015, 329 . 331 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 332 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 333 May 2017, . 335 [RFC8300] Quinn, P., Ed., Elzur, U., Ed., and C. Pignataro, Ed., 336 "Network Service Header (NSH)", RFC 8300, 337 DOI 10.17487/RFC8300, January 2018, 338 . 340 8.2. Informative References 342 [I-D.ietf-bess-nsh-bgp-control-plane] 343 Farrel, A., Drake, J., Rosen, E., Uttaro, J., and L. 344 Jalil, "BGP Control Plane for NSH SFC", draft-ietf-bess- 345 nsh-bgp-control-plane-04 (work in progress), July 2018. 347 [I-D.ietf-sfc-use-case-mobility] 348 Napper, J., Stiemerling, M., Lopez, D., and J. Uttaro, 349 "Service Function Chaining Use Cases in Mobile Networks", 350 draft-ietf-sfc-use-case-mobility-08 (work in progress), 351 May 2018. 353 [I-D.maglione-sfc-nsh-radius] 354 Maglione, R., Trueba, G., and C. Pignataro, "RADIUS 355 Attributes for NSH", draft-maglione-sfc-nsh-radius-01 356 (work in progress), October 2016. 358 [I-D.wu-pce-traffic-steering-sfc] 359 Wu, Q., Dhody, D., Boucadair, M., Jacquenet, C., and J. 360 Tantsura, "PCEP Extensions for Service Function Chaining 361 (SFC)", draft-wu-pce-traffic-steering-sfc-12 (work in 362 progress), June 2017. 364 [RFC8459] Dolson, D., Homma, S., Lopez, D., and M. Boucadair, 365 "Hierarchical Service Function Chaining (hSFC)", RFC 8459, 366 DOI 10.17487/RFC8459, September 2018, 367 . 369 Authors' Addresses 371 Mohamed Boucadair 372 Orange 373 Rennes 3500 374 France 376 Email: mohamed.boucadair@orange.com 377 Dirk von Hugo 378 Deutsche Telekom 379 Deutsche-Telekom-Allee 7 380 D-64295 Darmstadt 381 Germany 383 Email: Dirk.von-Hugo@telekom.de 385 Behcet Sarikaya 386 Denpel Informatique 388 Email: sarikaya@ieee.org