idnits 2.17.1 draft-sarikaya-sfc-hostid-serviceheader-07.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 (June 21, 2018) is 2136 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 532, but not defined == Unused Reference: 'RFC6146' is defined on line 626, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 7665 == Outdated reference: A later version (-11) exists of draft-ietf-sfc-hierarchical-09 == Outdated reference: A later version (-09) exists of draft-ietf-sfc-use-case-mobility-08 Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SFC B. Sarikaya 3 Internet-Draft Denpel Informatique 4 Intended status: Standards Track M. Boucadair 5 Expires: December 23, 2018 Orange 6 D. von Hugo 7 Deutsche Telekom 8 June 21, 2018 10 Service Function Chaining: Subscriber and Service Identification Use 11 Cases and Variable-Length NSH Context Headers 12 draft-sarikaya-sfc-hostid-serviceheader-07 14 Abstract 16 This document discusses how to inform Service Functions about 17 service- and subscriber-related information for the sake of policy 18 enforcement and appropriate SFC-inferred forwarding. Once the 19 information is consumed by SFC-aware elements of an SFC-enabled 20 domain, it is stripped from packets when they leave the SFC-enabled 21 domain. Thus privacy-sensitive information is not leaked outside the 22 domain. 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 December 23, 2018. 41 Copyright Notice 43 Copyright (c) 2018 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 and Terminology . . . . . . . . . . . . . . . . . 4 60 3. Problem Space and Sample Use Cases . . . . . . . . . . . . . 4 61 3.1. Parental Control Use Case . . . . . . . . . . . . . . . . 5 62 3.2. Traffic Offload Use Case . . . . . . . . . . . . . . . . 5 63 3.3. Mobile Network Use Cases . . . . . . . . . . . . . . . . 6 64 3.4. Extreme Low Latency Service Use Cases . . . . . . . . . . 7 65 3.5. High Reliability Applications Use Cases . . . . . . . . . 7 66 4. Subscriber Identification NSH Variable-Length Context Header 7 67 5. Slice and Service Identification NSH Variable-Length Context 68 Headers . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 69 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 70 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 71 8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 12 72 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 73 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 74 10.1. Normative References . . . . . . . . . . . . . . . . . . 13 75 10.2. Informative References . . . . . . . . . . . . . . . . . 13 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 78 1. Introduction 80 This document discusses how to inform Service Functions about 81 service- and subscriber-related information when required for the 82 sake of policy enforcement. Indeed, subscriber-related information 83 may be required to enforce subscriber-specific, SFC-based traffic 84 forwarding policies, since the information carried in packets may not 85 be sufficient. 87 The enforcement of SFC-based differentiated traffic forwarding 88 policies may also be inferred by QoS considerations. QoS information 89 may serve as an input to classification of SFP for path computation 90 and establishment. 92 The dynamic structuring of service function chains and their 93 subsequent enforcement may be conditioned by QoS requirements that 94 will affect SF instance identification, location and sequencing. 96 We refer here to the definition of a logical network slice as a sub- 97 network being isolated from other sub-networks using the same 98 physical infrastructure. Each of these slices are constructed to 99 provide service specific QoS requirements (such as low latency, high 100 availability, or high reliability) efficiently. 102 SFs and SF Forwarders (SFFs) involved in an SFC have to contribute to 103 the respective QoS requirements characterized by low transmission 104 delay between each other, by exposing a high availability of 105 resources to process function tasks, or by redundancy provided by 106 stand-by machines for seamless execution continuation in case of 107 failures. These requirements may be satisfied by means of control 108 protocols, but in some contexts, carrying QoS-related information in 109 packets may improve the overall SFC operation instead of relying upon 110 the potential complexity of SFC control plane features. 112 This document adheres to the architecture defined in [RFC7665]. This 113 document assumes the reader is familiar with [RFC7665] and 114 [I-D.ietf-sfc-hierarchical]. 116 Subscriber-related information may be required to implement services 117 such as, but not limited to, traffic policy control, parental 118 control, traffic offload. Such features are often provided by 119 operators as part of their service portfolio. 121 Another example is the applicability of service chaining in the 122 context of mobile networks (typically, in the 3GPP defined (S)Gi 123 Interface) [I-D.ietf-sfc-use-case-mobility]. Because of the 124 widespread use of private addressing in those networks, if advanced 125 SFs to be invoked are located after a NAT device (that can reside in 126 the Packet Data Network (PDN) Gateway (PGW) or in a distinct 127 operator-specific node), the identification based on the internal IP 128 address is not anymore possible once the NAT has been crossed. As 129 such, means to allow passing the internal information may optimise 130 packet traversal within an SFC-enabled mobile network domain. 131 Furthermore, some SFs that are not enabled on the PGW may require a 132 subscriber identifier e.g., International Mobile Subscriber Identity 133 (IMSI), to properly operate. Other use cases that suffer from 134 identification problems further are discussed in [RFC7620]. 136 Subscriber-specific information can be useful for optimized SFC 137 design and SF placement/invocation, let alone slice/VPN design and 138 operation. 140 To ensure a service specific quality and performance per use case 141 logically separated network slices will be deployed. Each one is 142 flagged by a corresponding service-related information in terms of a 143 service identifier. Examples are 'tactile internet', 'eHealth' or 144 'industry control' requiring, e.g. granted low latency or extreme 145 high reliability. 147 This document does not make any assumption about the structure of 148 service identifiers; each such service-related information is treated 149 as an opaque value by the SFC operations and protocols. The 150 semantics and validation of these identifiers are up to the control 151 plane used for SFC. Expectations to SFC control plane protocols are 152 laid down in [I-D.ietf-sfc-hierarchical]. 154 Subscriber- and service-related information is stripped from packets 155 exiting an SFC-enabled domain for the sake of privacy protection in 156 particular. See Section 8 for more discussion on privacy. 158 The use cases discussed in this document assume the NSH is used 159 exclusively within a single administrative domain. 161 2. Conventions and Terminology 163 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 164 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 165 document are to be interpreted as described in RFC 2119 [RFC2119]. 167 The reader should be familiar with the terms defined in [RFC7665]. 169 3. Problem Space and Sample Use Cases 171 Enforcing Policies based on an internal IP address: 173 Because of the address sharing, implicit CPE/UE identification 174 that relies on the source IP address cannot be implemented within 175 the administrative domain because the same global IPv4 address is 176 shared by various connected devices (CPE for the fixed case or UE 177 for the mobile case). In the meantime, policies are something 178 provisioned based on the internal IP address assigned to those 179 devices. Means to pass the internal IP address beyond an address 180 sharing device for the sake of per-subscriber policy enforcement 181 is needed in some SFC deployments. 183 Also, identifiers like a MAC address, or an IMSI may be required 184 to optimize the corresponding SFC operation. 186 Enforcing Policies based on a subscriber identifier: 188 In case some deployments may require per-subscriber policies, 189 carrying subscriber ID information may be required for the sake of 190 proper SFC operation.. 192 Enforcing Policies based on a service specific identifier: 194 SFCs can be structured according to QoS/QoE requirements that may 195 be shared by different services. In that case, service 196 identification information is required to be accessible across the 197 SFC for the sake of proper SFC operation. 199 Below we present some use cases where problems related to enforcing 200 policies based on subscriber identifiers and those based on service 201 and/or slice identifiers cannot be addressed by service function 202 chaining. It is important to note that subscriber identification 203 issues raised by address sharing environments are not specific to 204 service function chaining. 206 3.1. Parental Control Use Case 208 Parental control service function searches each packet for certain 209 content. Parental control function should have permanent access to 210 corresponding specific information (URL and source IP address), e.g. 211 in a cache, so that all packets of the corresponding flow(s) can be 212 filtered [WT317]. 214 Parental control function receives next packet from the recorded URL. 215 Enforcing the parental control policies may depend on the internal IP 216 address, i.e., the address of the subscriber's host that is being 217 subject to the parental control. Parental control function must be 218 able to identify incoming traffic to be filtered, e.g., specific URL 219 information. All other traffic is not subject to parental control 220 filtering. Parental control function filters all traffic coming from 221 the indicated URL only for the specific subscriber's hosts identified 222 by the service logic. 224 For the virtual CPE case, the access node will receive privately- 225 addressed packets. Because private IPv4 addresses are likely to 226 overlap between several subscribers, the internal private IPv4 227 address will need to be copied into a dedicated header in the NSH 228 packet so that SFs responsible for parental control can process the 229 packets appropriately. Furthermore, the subscriber identifier may 230 also be required for authorization purposes. 232 3.2. Traffic Offload Use Case 234 A traffic offload service function is invoked for each flow/service 235 originated from a mobile terminal and this SF decides whether traffic 236 should be offloaded to the broadband network or sent back to the 237 mobile network. In this use case, policy enforcement is based on the 238 subscriber identifier. The broadband network must obtain the 239 subscription profile from the mobile network and decide if the 240 traffic coming from this subscriber needs to be offloaded or not. If 241 offloading is needed, this usually means that the subscriber 242 identifier needs to be known by SFFs. 244 3.3. Mobile Network Use Cases 246 Many SFs can be executed in different combinations in a mobile 247 network [I-D.ietf-sfc-use-case-mobility]. In particular, placement 248 of NAT function (if used) plays an important role. 250 If a NAT function is collocated with P-GW as in [TR23.975] or right 251 after the P-GW (i.e. between P-GW and (S)Gi-LAN) then all service 252 functions located upstream can only see the translated IPv4 address 253 as the source address from all User Equipments (UEs). Internal IPv4 254 address-related part of their policy set won't be able to execute 255 their service logic. As a consequence, means to inform the various 256 SFs of a given chain about the IPv4 address assigned to the UE and 257 which will be translated into a global IPv4 address may be needed. 259 Note that the same problem occurs in case IPv6 is being used by UEs, 260 whenever such UEs communicate with an IPv4-only web site. In that 261 case, a NAT64 function is deployed at the P-GW. So in the case of 262 chaining NAT64 SF needs to be invoked as part of a given chain, the 263 IPv6 address used by the UE may be required for the service function 264 chain to work properly. 266 [I-D.ietf-sfc-use-case-mobility] identifies the following 267 information: 269 o Charging ID 271 o Subscriber ID 273 o GGSN or PGW IP address 275 o Serving Gateway Support Node (SGSN) or SGW IP address 277 o International Mobile Equipment Identity (IMEI) 279 o International Mobile Subscriber Identity (IMSI) 281 o Mobile Subscriber ISDN Number (MSISDN) 283 o UE IP address 285 Several other use cases where support of traffic classification with 286 respect to service chain selection to achieve efficient and flexible 287 mobile service steering are described in [TR22.808]. A set of 288 potential solutions are proposed and discussed in [TR23.718]. 290 3.4. Extreme Low Latency Service Use Cases 292 Extreme or ultra-low latency requirements may be addressed by 293 specific architectural and protocol characteristics to allow for 294 rapid execution and low transmission delay of packets. Candidate 295 services for such requirements include e-health or vehicular 296 applications. This can be granted by forwarding all packets via the 297 shortest paths only and/or via the service function instances with 298 the lowest processing delay, possibly as a function of the location 299 of the user. 301 The corresponding service function chain should be configured based 302 on the service demanding for the performance, but policies are also 303 tightly related to the subscriber, i.e. whether being entitled to 304 request the specific service. 306 3.5. High Reliability Applications Use Cases 308 Another set of use cases that require very (or ultra-) high 309 reliability of services assume committed QoS parameter values and its 310 possibility to act upon an expected change of the network fulfillment 311 of the QoS targets [TR22.862]. That means: the QoS fulfillment is 312 controlled such that in case of expected or predicted deviation a 313 countermeasure by the network is invoked, e.g. either resources for 314 that session are increased or a backup path is assigned in case no 315 improvement is possible at least the application is informed on the 316 current performance to react upon. This can be granted by forwarding 317 all packets via the most reliable and secure paths only. 319 4. Subscriber Identification NSH Variable-Length Context Header 321 Subscriber Identifier is defined as an optional variable-length NSH 322 context header. Its structure is shown in Figure 1. 324 The subscriber identifier is used to convey an identifier already 325 assigned by the service provider to uniquely identify a subscriber or 326 an information that is required to enforce per-subscriber policies, 327 the structure of the identifier being deployment-specific. 328 Typically, this header may convey the IMSI, an opaque subscriber 329 Identifier, an IP address, etc. 331 The classifier and SFC-aware Service Functions MAY be instructed via 332 a control interface to inject or strip a subscriber identifier 333 context header. Also, the data to be injected in such header SHOULD 334 be configured to nodes authorized to inject such headers. Failures 335 to inject such headers SHOULD be logged locally while a notification 336 alarm MAY be sent to a Control Element. The details of sending 337 notification alarms (i.e. the parameters affecting the transmission 338 of the notification alarms depend on the information in the context 339 header such as frequency, thresholds, and content in the alarm: full 340 header, header ID, timestamp etc.) SHOULD be configurable by the 341 control plane. 343 This document adheres to the recommendations in [RFC8300] for 344 handling the context headers at both ingress and egress SFC boundary 345 nodes. That is, to strip such context headers. 347 SFC-aware SFs and proxies MAY be instructed to strip a subscriber 348 identifier from the packet or to pass the data to the next SF in the 349 chain after processing the content of the headers. If no instruction 350 is provided, the default behavior is to maintain such context headers 351 so that the information can be passed to next SFC-aware hops. 353 SFC-aware functions MAY be instructed via the control plane about the 354 validation checks to run on the content of these context headers 355 (e.g., accept only some lengths, accept some subtypes) and the 356 behavior to adopt. For example, SFC-aware nodes may be instructed to 357 ignore the context header, to remove the context header from the 358 packet, etc. Nevertheless, this specification does not require nor 359 preclude such additional validation checks. These validation checks 360 are deployment-specific. If validation checks fail on a context 361 header, an SFC-aware node ignores that context header. The event 362 SHOULD be logged locally while a notification alarm MAY be sent to a 363 control element if the SFC-aware node is instructed to do so. 365 Multiple subscriber Identifier context TLVs MAY be present in the NSH 366 each carrying a distinct sub-type. 368 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 369 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 370 | Metadata Class | Type |U| Length | 371 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 372 | SubT | | 373 +-+-+-+-+-+-+-+-+ 374 ~ Subscriber Identifier ~ 375 | | 376 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 378 Figure 1: Subscriber Identifier Variable-Length Context Header 380 The description of the fields is as follows: 382 o Metadata Class: MUST be set to 0x0 [RFC8300]. 384 o Type: TBD1 (See Section 6) 386 o SubT field of 8 bits indicates the sub-type of the information 387 conveyed in the "Subscriber Identifier" field. The following 388 values are defined: 390 * 0x00: Opaque value 392 * 0x01: Charging ID. The structure of this ID is deployment- 393 specific. 395 * 0x02: Subscriber ID. The structure of this ID is deployment- 396 specific. 398 * 0x03: GGSN or PGW IP address/prefix 400 * 0x04: Serving Gateway Support Node (SGSN) or SGW IP address/ 401 prefix 403 * 0x05: International Mobile Equipment Identity (IMEI) 405 * 0x06: International Mobile Subscriber Identity (IMSI) 407 * 0x07: Mobile Subscriber ISDN Number (MSISDN) 409 * 0x08: UE IP address 411 o Subscriber Identifier: Carries an opaque subscriber identifier or 412 an identifier that corresponds to the sub-type. 414 5. Slice and Service Identification NSH Variable-Length Context Headers 416 Dedicated service- and slice-specific performance identifiers are 417 defined to differentiate between services requiring specific 418 treatment to exhibit a performance characterized by, e.g., ultra-low 419 latency (ULL) or ultra-high reliability (UHR). These parameters are 420 related to slice and service identifiers, among others. They are 421 contained in the service Identifier. The service Identifier thus 422 allows for the enforcement of a per service policy such as a service 423 classification function to only consider specific Service Function 424 instances during service function path establishment. Details of 425 this process are implementation- specific. For illustration 426 purposes, the classifier may retrieve the details of usable service 427 functions based upon the corresponding service or slice ID. Typical 428 criteria for instantiating specific service functions include 429 location, performance or proximity considerations. For UHR services, 430 the stand-by operation of back-up capacity or the deployment of 431 multiple service function instances may be requested. 433 In other words, the classifier uses this kind of information to 434 decide about the set of SFFs to invoke to honor the latency or 435 reliability requirement (e.g., compute an Rendered Service Path, RSP, 436 or insert a pointer to be shared with involved SFFs). 438 Slice and Service Identifiers are defined as optional variable length 439 context headers. Their structure is shown in Figure 2 and Figure 3, 440 respectively. 442 Service/Slice Identifier context header MAY convey a user or service 443 provider defined unique identity which can be described by an opaque 444 value. 446 The service requirements in terms of, e.g., maximum latency or 447 minimum outage probability are specified by service providers and are 448 out of the scope of this document. 450 Only one Slice Identifier context header (as described in Section 1) 451 MUST be present in the NSH. 453 Multiple Service Identifier context headers MAY be present in the 454 NSH; each carrying a distinct sub-type. 456 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 457 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 458 | Metadata Class | Type |U| Length | 459 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 460 | | 461 ~ Slice Identifier ~ 462 | | 463 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 465 Figure 2: Slice Identifier Variable-Length Context Header 467 The description of the fields is as follows: 469 o Metadata Class: MUST be set to 0x0 [RFC8300]. 471 o Type: TBD2 (See Section 6) 473 o Slice Identifier: The structure of the identifier is deployment- 474 specific. This field carries an identifier that uniquely 475 identifies a slice within a network, e.g. it could be an opaque 476 value with an arbitrary number of characters. 478 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 479 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 480 | Metadata Class | Type |U| Length | 481 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 482 | SubT | | 483 +-+-+-+-+-+-+-+-+ 484 ~ Service Identifier ~ 485 | | 486 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 488 Figure 3: Service Identifier Variable-Length Context Header 490 The description of the fields is as follows: 492 o Metadata Class: MUST be set to 0x0 [RFC8300]. 494 o Type: TBD3 (See Section 6) 496 o SubT: 8-bit field that carries the sub-type of the information 497 conveyed in the "Service Identifier" field. The following values 498 are defined: 500 * 0x00: Opaque value 502 * 0x01: Ultra-low latency ID. The structure of this ID is 503 service deployment-specific. 505 * 0x02: Ultra-high reliability ID. The structure of this ID is 506 service deployment-specific. 508 * 0x03: Slice Identifier. The structure of this ID is service 509 deployment-specific. 511 * 0x04 - 0x08: reserved 513 o Service Identifier: Represents a specific service performance 514 characteristic reflected in the SubT field, but also denotes a 515 default basic (best effort) service without specifically defined 516 requirements. It MAY also be an opaque value which semantic is 517 defined by the operator. 519 6. IANA Considerations 521 This document requests IANA to assign the followiing types from the 522 "NSH IETF- Assigned Optional Variable-Length Metadata Types" (0x0000 523 IETF Base NSH MD Class) registry available at: 524 https://www.iana.org/assignments/nsh/nsh.xhtml#optional-variable- 525 length-metadata-types. 527 +------+-----------------------+----------------+ 528 | C1 | C2 | | 529 +------+-----------------------+----------------+ 530 | TBD1 | Subscriber Identifier | [ThisDocument] | 531 | TBD2 | Slice Identifier | [ThisDocument] | 532 | TBD3 | Service Identifier | [ThisDocument] | 533 +------+-----------------------+----------------+ 535 7. Security Considerations 537 Data plane SFC-related security considerations are discussed in 538 [RFC7665] and [RFC8300]. 540 A misbehaving node can inject subscriber Identifiers to disturb the 541 service offered to some subscribers. Also, a misbehaving node can 542 inject subscriber identifiers as an attempt to be granted access to 543 some services. To prevent such misbehavior, only trusted nodes MUST 544 be able to inject such context headers. Nodes that are involved in a 545 SFC-enabled domain are assumed to be trusted ([RFC8300]). Means to 546 check that only authorized nodes are solicited when a packet is 547 crossing an SFC-enabled domain. 549 8. Privacy Considerations 551 The metadata defined in this document for subscriber identifiers may 552 reveal private information about the subscriber. Some privacy- 553 related considerations for Internet Protocols are discussed in 554 [RFC6973] and [RFC6967]. In the light of these privacy 555 considerations, it is important to state that the subscriber metadata 556 MUST NOT be exposed outside the operator's domain. This requirement 557 is already supported by the NSH [RFC8300]. That is, NSH is stripped 558 systematically at the egress of a service chain. 560 The information conveyed in subscriber identifiers is already known 561 to an administrative entity managing an SFC-enabled domain. Some of 562 that information is already conveyed in the original packets from a 563 host (e.g., internal IP address) while other information is collected 564 from various sources (e.g., GTP tunnel, line identifier, etc.). 565 Conveying such sensitive information in packets may expose 566 subscribers' sensitive data to entities that are not allowed to 567 receive such information. Misbehaving SFC egress nodes is a threat 568 that may have negative impacts on privacy (e.g., some operational 569 networks leak the MSISDN outside). Operators MUST ensure their SFC- 570 enabled domain is appropriately conforming to the NSH specification 571 so that any privacy-related information is not exposed outside the 572 SFC-enabled domain. 574 Some use cases that rely upon the solution defined in this document 575 may disclose some additional privacy-related information (e.g., a 576 host identifier of a terminal within a customer premises for the 577 parental control case). It is assumed that this information is 578 provided upon approval from a subscriber [RFC8165]. For example, a 579 customer may provide the information as part of its service 580 management interface or as part of explicit subscription form. 582 9. Acknowledgements 584 Comments from Joel Halpern on a previous version and by Carlos 585 Bernardos are appreciated. Contributions by Christian Jacquenet are 586 thankfully acknowledged. 588 This work has been partially performed in the framework of the EU- 589 funded H2020-ICT-2014-2 project 5G NORMA. Contributions of the 590 project partners are gratefully acknowledged. The project consortium 591 is not liable for any use that may be made of any of the information 592 contained therein. 594 10. References 596 10.1. Normative References 598 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 599 Requirement Levels", BCP 14, RFC 2119, 600 DOI 10.17487/RFC2119, March 1997, 601 . 603 [RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function 604 Chaining (SFC) Architecture", RFC 7665, 605 DOI 10.17487/RFC7665, October 2015, 606 . 608 [RFC8300] Quinn, P., Ed., Elzur, U., Ed., and C. Pignataro, Ed., 609 "Network Service Header (NSH)", RFC 8300, 610 DOI 10.17487/RFC8300, January 2018, 611 . 613 10.2. Informative References 615 [I-D.ietf-sfc-hierarchical] 616 Dolson, D., Homma, S., Lopez, D., and M. Boucadair, 617 "Hierarchical Service Function Chaining (hSFC)", draft- 618 ietf-sfc-hierarchical-09 (work in progress), June 2018. 620 [I-D.ietf-sfc-use-case-mobility] 621 Haeffner, W., Napper, J., Stiemerling, M., Lopez, D., and 622 J. Uttaro, "Service Function Chaining Use Cases in Mobile 623 Networks", draft-ietf-sfc-use-case-mobility-08 (work in 624 progress), May 2018. 626 [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful 627 NAT64: Network Address and Protocol Translation from IPv6 628 Clients to IPv4 Servers", RFC 6146, DOI 10.17487/RFC6146, 629 April 2011, . 631 [RFC6967] Boucadair, M., Touch, J., Levis, P., and R. Penno, 632 "Analysis of Potential Solutions for Revealing a Host 633 Identifier (HOST_ID) in Shared Address Deployments", 634 RFC 6967, DOI 10.17487/RFC6967, June 2013, 635 . 637 [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., 638 Morris, J., Hansen, M., and R. Smith, "Privacy 639 Considerations for Internet Protocols", RFC 6973, 640 DOI 10.17487/RFC6973, July 2013, 641 . 643 [RFC7620] Boucadair, M., Ed., Chatras, B., Reddy, T., Williams, B., 644 and B. Sarikaya, "Scenarios with Host Identification 645 Complications", RFC 7620, DOI 10.17487/RFC7620, August 646 2015, . 648 [RFC8165] Hardie, T., "Design Considerations for Metadata 649 Insertion", RFC 8165, DOI 10.17487/RFC8165, May 2017, 650 . 652 [TR22.808] 653 "3GPP TR22.808, Technical Specification Group Services and 654 System Aspects; Study on flexible mobile service 655 steering", 2015. 657 [TR22.862] 658 "3GPP TR22.862, Feasibility Study on New Markets and 659 Technology Enablers - Critical Communications; Stage 1 660 (Release 14)", 2015. 662 [TR23.718] 663 "3GPP TR23.718, Technical Specification Group Services and 664 System Aspects; Architecture enhancement for flexible 665 mobile service steering", 2015. 667 [TR23.975] 668 "3GPP TR23.975, IPv6 Migration Guidelines", June 2011. 670 [TS23.003] 671 "3GPP TS23.003, Technical Specification Group Core Network 672 and Terminals; Numbering, addressing and identification", 673 2015. 675 [TS29.212] 676 "3GPP TS29.212, Policy and Charging Control (PCC) over Gx/ 677 Sd reference point", December 2011. 679 [WT317] BBF, "Network Enhanced Residential Gateway", August 2015. 681 Authors' Addresses 683 Behcet Sarikaya 684 Denpel Informatique 686 Email: sarikaya@ieee.org 688 Mohamed Boucadair 689 Orange 690 Rennes 3500, France 692 Email: mohamed.boucadair@orange.com 694 Dirk von Hugo 695 Telekom Innovation Laboratories 696 Deutsche-Telekom-Allee 7 697 D-64295 Darmstadt 698 Germany 700 Email: Dirk.von-Hugo@telekom.de