idnits 2.17.1 draft-sarikaya-sfc-hostid-serviceheader-05.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 : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 20, 2017) is 2469 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) ** Downref: Normative reference to an Informational draft: draft-ietf-sfc-control-plane (ref. 'I-D.ietf-sfc-control-plane') == Outdated reference: A later version (-28) exists of draft-ietf-sfc-nsh-16 ** Downref: Normative reference to an Informational RFC: RFC 7665 == Outdated reference: A later version (-09) exists of draft-ietf-sfc-use-case-mobility-07 == Outdated reference: A later version (-04) exists of draft-napper-sfc-nsh-broadband-allocation-03 == Outdated reference: A later version (-04) exists of draft-quinn-sfc-nsh-tlv-03 Summary: 2 errors (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Boucadair 3 Internet-Draft Orange 4 Intended status: Standards Track D. von Hugo 5 Expires: January 21, 2018 Telekom Innovation Laboratories 6 B. Sarikaya 7 Huawei 8 July 20, 2017 10 Service Function Chaining Service, Subscriber and Host Identification 11 Use Cases and Metadata 12 draft-sarikaya-sfc-hostid-serviceheader-05.txt 14 Abstract 16 This document discusses considerations related to passing service-, 17 host- and subscriber-related information to upstream Service 18 Functions for the sake of policy enforcement and appropriate SFC- 19 inferred forwarding. Once the information is consumed by SFC-aware 20 elements of an SFC-enabled domain, the information is stripped from 21 packets so that privacy-sensitive information is not leaked outside 22 an SFC-enabled 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 http://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 January 21, 2018. 41 Copyright Notice 43 Copyright (c) 2017 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 (http://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 . . . . . . . . . . . . . . . . 6 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. Host and Subscriber Identification SFC Meta Data . . . . . . 7 67 5. Slice and Service Identification SFC Meta Data . . . . . . . 10 68 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 69 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 70 8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 13 71 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 72 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 73 10.1. Normative References . . . . . . . . . . . . . . . . . . 14 74 10.2. Informative References . . . . . . . . . . . . . . . . . 15 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 77 1. Introduction 79 This document focuses on aspects related to passing service-, host- 80 and subscriber-related information to upstream Service Functions 81 (SFs) when required for the sake of policy enforcement. Indeed, 82 subscriber-related information may be needed for upstream SFs when 83 per-subscriber policies are to be enforced upstream in the network 84 while the information conveyed by the original packets does not allow 85 for uniquely identifying a host or a subscriber. 87 In addition further service- and policy-specific information 88 regarding handling of packet flows according to agreed quality and 89 performance requests - such as denoted by Quality of Service (QoS) or 90 Quality of Experience (QoE) parameters - may be needed, e.g. for 91 prioritization of packet forwarding with respect to latency demands 92 or required high reliability. Such features would ask for preferred 93 assignment of specific network function locations during construction 94 of a constrained service function path (SFP), and for computation of 95 a concrete Rendered Service Path (RSP) i.e. the actual sequence of 96 SFs and SF Forwarders (SFFs), e.g. by a service classification 97 function according to [RFC7665], which can be executed as described 98 in [I-D.ietf-sfc-control-plane] and [I-D.ietf-sfc-nsh]. SFs and SFFs 99 involved honor their part of the service or slice ID contained 100 assurance contract by being e.g. characterized by low transmission 101 delay between each other, by exposing a high availability of 102 resources to process function tasks, or by redundancy provided by 103 stand-by machines for seamless execution continuation in case of 104 failures. These requirements may be satisfied by means of control 105 protocols, but there might be some value to convey such signal to 106 SFC-aware nodes in data packets to simplify state that would be 107 required to check whether a packet is to be granted a given service. 109 This document adheres to the architecture defined in [RFC7665]. This 110 document assumes the reader is familiar with [RFC7665] and 111 [I-D.ietf-sfc-control-plane]. 113 Host-related information may be required to implement services such 114 as, but not limited to, traffic policy control, or parental control 115 and traffic offload that are commonly used by operators to enable 116 added value services to their customers in typical network 117 architectures [I-D.liu-sfc-use-cases]. 119 Another typical example is the applicability of service chaining in 120 the context of mobile networks (typically, in the 3GPP defined (S)Gi 121 Interface) [I-D.ietf-sfc-use-case-mobility]. Because of the 122 widespread use of private addressing in those networks, if advanced 123 SFs to be invoked are located after a NAT device (that can reside in 124 the Packet Data Network (PDN) Gateway (PGW) or in a distinct 125 operator-specific node), the identification based on the internal IP 126 address is not anymore possible once the NAT has been crossed. As 127 such, means to allow passing the internal information may ease the 128 operation of an SFC-enabled domain. Furthermore, some SFs that are 129 not enabled on the PGW may require a subscriber identifier e.g., 130 International Mobile Subscriber Identity (IMSI), to execute their 131 function. Other use cases that suffer from identification problems 132 further are discussed in [RFC7620]. 134 Because both a host and subscriber identifiers may be required in 135 some scenarios, this document defines two objects that allow carrying 136 this information. 138 Unless the information contained within such host and subscriber 139 identifiers already allows for deriving service specific requirements 140 (e.g. of services to which the hosts are subscribed to or which the 141 subscribers are expected to consume according to their contract) and 142 which may impact the choice of optimum specific service function 143 locations (placement and service function path constrains) then also 144 additional service or slice identifiers will be required. 146 Service-related information may be required to ensure specific 147 service quality and performance such as granted low latency or 148 extreme high reliability as, e.g., demanded for future 'tactile 149 internet' applications or eHealth and industry control as typical 150 examples for expected vertical use cases to be deployed in the 151 framework of logically separated network slices. Due to the high 152 variability and broad range of the new services expected for beyond 153 2020 we do not see that level of complexity covered within a QoS/DSCP 154 (QoS-Class - Identifier AVP) as proposed in 155 [I-D.napper-sfc-nsh-broadband-allocation]. 157 This document does not make any assumption about the structure of 158 host and service identifiers; each information is treated as an 159 opaque value. The meaning and validation of each of these 160 identifiers can be the responsibility of the control plane 161 [I-D.ietf-sfc-control-plane]. 163 Host-related and/or subscriber-related information is stripped from 164 packets exiting an SFC-enabled domain so that privacy-sensitive 165 information is not leaked outside the domain. See Section 8 for more 166 discussion on privacy. 168 Within this document, only identification issues for the sake of 169 services in a local administrative domain are discussed. Global 170 identification issues are out of scope. 172 2. Conventions and Terminology 174 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 175 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 176 document are to be interpreted as described in RFC 2119 [RFC2119]. 178 The reader should be familiar with the terms defined in [RFC7665]. 180 3. Problem Space and Sample Use Cases 182 Enforcing Policies based on an internal IP address: 184 Because of the address sharing, implicit CPE/UE identification that 185 relies on the source IP address cannot be implemented within the 186 administrative domain because the same IP address is shared among 187 various connected devices (CPE for the fixed case or UE for the 188 mobile case). In the meantime, policies are something provisioned 189 based on the internal IP address assigned to those devices. Means to 190 pass the internal IP address beyond an address sharing device for the 191 sake of per-host or per-subscriber policy enforcement is needed in 192 some SFC deployments. 194 Also, stable identifiers such as MAC address, IMSI can be passed. 196 Enforcing Policies based on a subscriber identifier: 198 In case some deployments may require per-subscriber policies, a means 199 is required to pass subscriber ID to those upstream SFs which are 200 responsible for or rely on policy enforcement. 202 Enforcing Policies based on a service specific identifier: 204 In case a specific set of services and applications, e.g. which all 205 are characterized by same QoS/QoE requirements (laid down e.g. in 206 terms of corresponding policies) and the service function chains want 207 to reflect this behavior by assigning a specific SFC (or virtual 208 network slice) to them, deployments may require a per-service/slice 209 identifier and a means to pass such identifier to those upstream SFs 210 which are responsible for or rely on policy enforcement. 212 Below we present some use cases where problems related to enforcing 213 policies based on subscriber and/or host identities and those based 214 on service and/or slice identifiers currently cannot be achieved in 215 service function chaining. It is important to note that subscriber 216 and host identification due to address and prefix sharing is not 217 specific to the service function chaining. This problem occurs in 218 many other use cases as discussed in [RFC7620]. 220 3.1. Parental Control Use Case 222 Parental control service function searches each packet for certain 223 content, e.g. destination addresses corresponding to certain URL like 224 www.thisbizarresite.com. Parental control function should keep this 225 information (URL and source IP address) in its cache so that all 226 subsequent packets can be filtered for certain users from the Web 227 server [WT317]. 229 Parental control function receives next packet from the recorded URL. 230 Enforcing the parental control policies may depend on the internal IP 231 address, i.e., the address of the host that is being subject to the 232 parental control. Parental control function must be able to identify 233 incoming traffic to be filtered, e.g. specific URL information. All 234 other traffic is not subject to filtering. Parental control function 235 filters all traffic coming from indicated URL only for the specific 236 hosts identified by the service logic. 238 For the virtual CPE case, the access node will receive privately- 239 addressed packets. Because private addresses are overlapping between 240 several subscribers, the internal IP address will need to be copied 241 into a dedicated field (Host ID context) so that upstream function 242 responsible for Parental Control can process the packets 243 appropriately. Furthermore, the subscriber identifier may also be 244 required for authorization purposes. 246 3.2. Traffic Offload Use Case 248 Traffic offload service function works on each flow/service 249 originated from mobile terminal and decides if it should be offloaded 250 to the broadband network or sent back to the mobile network. In this 251 use case policy enforcement is based on the subscriber identifier. 252 The broadband network must obtain the subscription profile from the 253 mobile network and decide if the traffic coming from this subscriber 254 needs to be offloaded or not. If offloading is needed, this usually 255 means that the subscriber identifier needs to be known on the SFC- 256 aware forwarders. 258 3.3. Mobile Network Use Cases 260 Many SFs can be executed in different combinations in a mobile 261 network [I-D.ietf-sfc-use-case-mobility]. Placement of NAT function 262 plays an important role if it is used. 264 If NAT function is collocated with P-GW as in [TR23.975] or is 265 located right after the P-GW then all service functions located 266 upstream can only see the translated address as the source address 267 from all User Equipments (UEs). Internal IP address-related part of 268 their policy set won't be able to execute their service logic. As a 269 consequence, means to pass the internal IP address (i.e., the 270 original one before executing the NAT function) through the service 271 chain may be needed. 273 Note that the same problem occurs in case IPv6 is being used by UEs 274 but UEs need to communicate with an external legacy server which is 275 IPv4-only. This can be made possible with NAT64 as described in 276 [RFC6146]. NAT64 uses IPv4 address on its outgoing interface which 277 is shared by all UEs. So in the case of NAT64 host identification 278 also becomes an issue in service chaining. 280 [I-D.ietf-sfc-use-case-mobility] identifies the following 281 information: 283 o Charging ID 285 o Subscriber ID 287 o GGSN or PGW IP address 289 o Serving Gateway Support Node (SGSN) or SGW IP address 290 o International Mobile Equipment Identity (IMEI) 292 o International Mobile Subscriber Identity (IMSI) 294 o Mobile Subscriber ISDN Number (MSISDN) 296 o UE IP address 298 Several other use cases where support of traffic classification with 299 respect to service chain selection to achieve efficient and flexible 300 mobile service steering are described in [TR22.808]. A set of 301 potential solutions are proposed and discussed in [TR23.718] where 302 partly the SFC approach for traffic steering and use of NSH for 303 traffic classification are already referenced. 305 3.4. Extreme Low Latency Service Use Cases 307 Extreme or ultra-low latency Use Case as foreseen for so-called '5G' 308 system of next generation (not only) mobile networks, e.g. by 3GPP 309 [TR22.862] requires specific architectural and protocol 310 characteristics to allow for rapid execution and low transmission 311 delay of packets within services as for example medical, industrial, 312 or vehicular applications. This can be granted by forwarding all 313 packets via the shortest paths only and/or via the service functions 314 granting lowest processing delay. 316 3.5. High Reliability Applications Use Cases 318 Another set of use cases within the critical communications family 319 demands for very (or ultra-) high reliability of services as defined 320 by 3GPP in [TR22.862] by 'High Reliable communication services are 321 characterized by the service layer need of committed QoS targets and 322 its possibility to act upon an expected change of the network 323 fulfillment of the QoS targets.' This can be granted by forwarding 324 all packets via the most reliable and secure paths only. 326 4. Host and Subscriber Identification SFC Meta Data 328 Host Identifier and Subscriber Identifier are defined as optional 329 variable length context headers. Their structure is shown in 330 Figure 1 and Figure 2, respectively. Host Identifier context header 331 may convey an internal IP address, VLAN or MAC address. 333 While the subscriber identifier itself is used to convey an 334 identifier already assigned by the service provider to uniquely 335 identify a subscriber or an information that is required to enforce a 336 per-subscriber policy, the structure of the identifier is deployment- 337 specific. Typically, this header may convey the IMSI, opaque 338 subscriber Identifier, etc. 340 The classifier and SFC-aware Service Functions MAY be instructed via 341 a control interface to inject or strip a host identifier and/or 342 subscriber identifier context headers. Also, the data to be injected 343 in such header SHOULD be configured to nodes authorized to inject 344 such headers. Failures to inject such headers SHOULD be logged 345 locally while a notification alarm MAY be sent to a Control Element. 346 The level of sending notification alarms SHOULD be configurable by 347 the control plane. 349 The control plane SHOULD instruct Ingress Border Nodes about the 350 behavior to follow when receiving Host ID and/or Subscriber ID 351 context headers from external SFC-enabled domain. If no instruction 352 is provided, the default behavior is to strip such context headers 353 when received from external SFC-enabled domain. 355 The control plane SHOULD instruct Egress Border Nodes about the 356 behavior to follow for processing packets conveying Host ID and/or 357 Subscriber ID context headers. If no instruction is provided, the 358 default behavior is to strip such context headers before sending the 359 packets outside an SFC-enabled domain. 361 SFC-aware SFs and Proxies that are not acting as SFC border nodes MAY 362 be instructed to strip a host ID and/or subscriber ID from the packet 363 or to pass the data to the next SF in the chain after consuming the 364 content of the headers. If no instruction is provided, the default 365 behavior is to maintain such context headers so that the information 366 can be passed to next SFC-aware hops. 368 SFC-aware functions MAY be instructed via the control plane about the 369 validation checks to follow on the content of these context headers 370 (e.g., accept only some lengths, accept some subtypes) and the 371 behavior to follow. For example, SFC-aware nodes may be instructed 372 to ignore the context header, to remove the context header from the 373 packet, etc. Nevertheless, this specification does not require nor 374 preclude such additional validation checks. These validation checks 375 are deployment-specific. If validation checks fail on a context 376 header, an SFC-aware node ignores that context header. The event 377 SHOULD be logged locally while a notification alarm MAY be sent to a 378 control element if the SFC-aware node is instructed to do so. 380 Only one Host Identifier context header MUST be present in the SFC 381 header. 383 Multiple subscriber Identifier context headers MAY be present in the 384 SFC header each conveying a distinct sub-type. 386 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 387 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 388 | Metadata Class |C| Type |R| Len | 389 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 390 | | 391 ~ Host Identifier ~ 392 | | 393 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 395 Figure 1: Host Identifier Metadata 397 The description of the fields is as follows: 399 Metadata Class: is assigned the value of 0x0 [I-D.quinn-sfc-nsh-tlv]. 401 Type: TBD1 403 Host Identifier: Can be IPv4 or IPv6 address, IPv6 prefix, a subset 404 of IP address/prefix, a MAC address, or any deployment-specific 405 identifier. It could also be in Root NAI format containing arbitrary 406 number of characters [TS23.003]. 408 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 409 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 410 | Metadata Class |C| Type |R| Len | 411 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 412 | SubT | | 413 +-+-+-+-+-+-+-+-+ 414 ~ Subscriber Identifier ~ 415 | | 416 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 418 Figure 2: Subscriber Identifier Metadata 420 The description of the fields is as follows: 422 Metadata Class: is assigned the value of 0x0. 424 Type: TBD2 426 SubT field of 8 bits indicates the sub-type of the information 427 conveyed in the "Subscriber Identifier" field. The following values 428 are defined: 430 o 0x00: Opaque value 432 o 0x01: Charging ID. The structure of this ID is deployment- 433 specific. 435 o 0x02: Subscriber ID. The structure of this ID is deployment- 436 specific. 438 o 0x03: GGSN or PGW IP address/prefix 440 o 0x04: Serving Gateway Support Node (SGSN) or SGW IP address/prefix 442 o 0x05: International Mobile Equipment Identity (IMEI) 444 o 0x06: International Mobile Subscriber Identity (IMSI) 446 o 0x07: Mobile Subscriber ISDN Number (MSISDN) 448 o 0x08: UE IP address 450 Subscriber Identifier: Conveys an opaque subscriber identifier or an 451 identifier that corresponds to the sub-type. 453 5. Slice and Service Identification SFC Meta Data 455 Dedicated service- and slice specific performance Identifiers are 456 defined to differentiate between services requiring specific 457 treatment to exhibit a performance characterized by e.g. ultra-low 458 latency (ULL) or ultra-high reliability (UHR). These parameters are 459 related to slice and service identifiers and (among potentially 460 others) are contained and transported within the service Identifier. 461 The service Identifier thus allows for enforcement of a per service 462 policy such as a service classification function to only consider 463 dedicated service functions during service function path 464 construction. Details of this process are implementation specific, 465 for illustration the classifier may retrieve via the corresponding 466 service or slice ID from a data base of the details of usable service 467 functions. Exemplary characteristics of specific service function 468 instantiations may be location or distance from service session 469 endpoints or processing speed in case of ULL. For UHR the stand-by 470 operation of back-up capacity or a redundant deployment of service 471 function instantiations may be requested for all service functions 472 selectable by the classifier when applying for a service denoted by 473 this ID. In other words the classifier uses this kind of information 474 to decide about the set of SFFs to invoke to honor the latency or 475 reliability requirement (e.g., compute an RSP or insert a pointer to 476 be shared with involved SFFs). 478 Slice and Service Identifier are defined as optional variable length 479 context headers. Their structure is shown in Figure 3 and Figure 4, 480 respectively. Service/Slice Identifier context header may convey a 481 user or service provider defined unique identity which can be 482 described by an opaque value. Use of IP Address or prefix, VLAN or 483 MAC address here are for further consideration. 485 The service requirements in terms of e.g. but not limited to 486 parameters as maximum latency or minimum outrage probability are to 487 be specified by service providers and not in scope of this document. 489 General considerations as mentioned above for Host - and Subscriber 490 ID correspondingly apply here (see Section 4). 492 Only one Slice Identifier context header MUST be present in the SFC 493 header. 495 Multiple Service Identifier context headers MAY be present in the SFC 496 header each conveying a distinct sub-type. 498 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 499 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 500 | Metadata Class |C| Type |R| Len | 501 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 502 | | 503 ~ Slice Identifier ~ 504 | | 505 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 507 Figure 3: Slice Identifier Metadata 509 The description of the fields is as follows: 511 Metadata Class: is assigned the value of 0x0. 513 Type: TBD3 515 Slice Identifier: The structure of the identifier is deployment- 516 specific. This field carries an identifier that uniquely identifies 517 a slice within a network, e.g. it could be an opaque value with an 518 arbitrary number of characters. 520 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 521 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 522 | Metadata Class |C| Type |R| Len | 523 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 524 | SubT | | 525 +-+-+-+-+-+-+-+-+ 526 ~ Service Identifier ~ 527 | | 528 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 530 Figure 4: Service Identifier Metadata 532 [NOTE: The structure of the service ID TLV is to be further 533 discussed, particularly to assess why it is not sufficient to convey 534 an ID rather than a type and an ID.] 536 The description of the fields is as follows: 538 Metadata Class: is assigned the value of 0x0. 540 Type: TBD4 542 SubT field of 8 bits indicates the sub-type of the information 543 conveyed in the "Service Identifier" field. The following values are 544 defined: 546 o 0x00: Opaque value 548 o 0x01: Ultra-low latency ID. The structure of this ID is service 549 deployment-specific. 551 o 0x02: Ultra-high reliability ID. The structure of this ID is 552 service deployment-specific. 554 o 0x03: Slice Identifier. The structure of this ID is service 555 deployment-specific. 557 o 0x04 - 0x08: reserved 559 Service Identifier: Can be any deployment-specific identifier. It 560 could also be an opaque value with an arbitrary number of characters. 561 The Service ID could represent a specific service performance 562 characteristic reflected in the SubT field, but also denote a default 563 basic (best effort) service without specifically defined 564 requirements. 566 6. IANA Considerations 568 Type values TBD1, TBD2, TBD3 and TBD4 are to be assigned by IANA in 569 the Service Function Chaining Metadata Class value 0x0 type space. 571 7. Security Considerations 573 Data plane SFC-related security considerations are discussed in 574 [RFC7665]. Control plane SFC-related security considerations are 575 discussed in [I-D.ietf-sfc-control-plane]. 577 Security considerations that are related to the host identifier are 578 discussed in [RFC6967]. 580 A misbehaving node can inject host/subscriber Identifiers to disturb 581 the service offered to some host or subscribers. Also, a misbehaving 582 node can inject host/subscriber identifiers as an attempt to be 583 granted access to some services. To prevent such misbehavior, only 584 trusted nodes MUST be able to inject such context headers. Nodes 585 that are involved in a SFC-enabled domain must be trusted. Means to 586 check that only authorized nodes are solicited when a packet is 587 crossing an SFC-enabled domain. 589 8. Privacy Considerations 591 The metadata defined in this document for host and subscriber 592 identifiers may reveal private information about the host and/or the 593 subscriber. Some privacy-related considerations for Internet 594 Protocols are discussed in [RFC6973]. In the light of these privacy 595 considerations, it is important to state that the host and subscriber 596 metadata must not be exposed outside the operator's domain 597 [I-D.ietf-sfc-control-plane]. 599 The information conveyed in host and/or subscriber identifiers is 600 already known to an administrative entity managing an SFC-enabled 601 domain. Some of that information is already conveyed in the original 602 packets from a host (e.g., internal IP address) while other 603 information is collected from various sources (e.g., GTP tunnel, line 604 identifier, etc.). Conveying such sensitive information in packets 605 may expose subscribers' sensitive data to entities that are not 606 allowed to receive such information. Misconfiguring SFC egress nodes 607 is a threat that may have negative impacts on privacy (e.g., some 608 operational networks leak the MSISDN outside). Operators must ensure 609 their SFC-enabled domain is appropriately configured so that any 610 privacy-related information is not exposed outside the trusted 611 administrative domain. 613 Some use cases that rely upon the solution defined in this document 614 may disclose some additional privacy-related information (e.g., a 615 host identifier of a terminal within a customer premises for the 616 parental control case). It is assumed that this information is 617 provided upon approval from a subscriber. For example, a customer 618 may provide the information as part of its service management 619 interface or as part of explicit subscription form. As a common 620 recommendation for deployment relying on SFC header, a CPE MUST NOT 621 leak non-authorized information to the service provider by means of 622 an SFC header. Note, the use cases discussed in this document assume 623 the service header is used exclusively within the service 624 administrative domain. CPEs are not required to be SFC-aware. 626 9. Acknowledgements 628 Comments from Joel Halpern on a previous version are appreciated. 630 This work has been partially performed in the framework of the EU- 631 funded H2020-ICT-2014-2 project 5G NORMA. Contributions of the 632 project partners are gratefully acknowledged. The project consortium 633 is not liable for any use that may be made of any of the information 634 contained therein. 636 10. References 638 10.1. Normative References 640 [I-D.ietf-sfc-control-plane] 641 Boucadair, M., "Service Function Chaining (SFC) Control 642 Plane Components & Requirements", draft-ietf-sfc-control- 643 plane-08 (work in progress), October 2016. 645 [I-D.ietf-sfc-nsh] 646 Quinn, P., Elzur, U., and C. Pignataro, "Network Service 647 Header (NSH)", draft-ietf-sfc-nsh-16 (work in progress), 648 July 2017. 650 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 651 Requirement Levels", BCP 14, RFC 2119, 652 DOI 10.17487/RFC2119, March 1997, 653 . 655 [RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function 656 Chaining (SFC) Architecture", RFC 7665, 657 DOI 10.17487/RFC7665, October 2015, 658 . 660 10.2. Informative References 662 [I-D.ietf-sfc-use-case-mobility] 663 Haeffner, W., Napper, J., Stiemerling, M., Lopez, D., and 664 J. Uttaro, "Service Function Chaining Use Cases in Mobile 665 Networks", draft-ietf-sfc-use-case-mobility-07 (work in 666 progress), October 2016. 668 [I-D.liu-sfc-use-cases] 669 Will, W., Li, H., Huang, O., Boucadair, M., Leymann, N., 670 Qiao, F., Qiong, Q., Pham, C., Huang, C., Zhu, J., and P. 671 He, "Service Function Chaining (SFC) General Use Cases", 672 draft-liu-sfc-use-cases-08 (work in progress), September 673 2014. 675 [I-D.napper-sfc-nsh-broadband-allocation] 676 Napper, J., Kumar, S., Muley, P., Henderickx, W., and M. 677 Boucadair, "NSH Context Header Allocation -- Broadband", 678 draft-napper-sfc-nsh-broadband-allocation-03 (work in 679 progress), July 2017. 681 [I-D.quinn-sfc-nsh-tlv] 682 Quinn, P., Elzur, U., and S. Majee, "Network Service 683 Header TLVs", draft-quinn-sfc-nsh-tlv-03 (work in 684 progress), April 2017. 686 [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful 687 NAT64: Network Address and Protocol Translation from IPv6 688 Clients to IPv4 Servers", RFC 6146, DOI 10.17487/RFC6146, 689 April 2011, . 691 [RFC6967] Boucadair, M., Touch, J., Levis, P., and R. Penno, 692 "Analysis of Potential Solutions for Revealing a Host 693 Identifier (HOST_ID) in Shared Address Deployments", 694 RFC 6967, DOI 10.17487/RFC6967, June 2013, 695 . 697 [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., 698 Morris, J., Hansen, M., and R. Smith, "Privacy 699 Considerations for Internet Protocols", RFC 6973, 700 DOI 10.17487/RFC6973, July 2013, 701 . 703 [RFC7620] Boucadair, M., Ed., Chatras, B., Reddy, T., Williams, B., 704 and B. Sarikaya, "Scenarios with Host Identification 705 Complications", RFC 7620, DOI 10.17487/RFC7620, August 706 2015, . 708 [TR22.808] 709 "3GPP TR22.808, Technical Specification Group Services and 710 System Aspects; Study on flexible mobile service 711 steering", 2015. 713 [TR22.862] 714 "3GPP TR22.862, Feasibility Study on New Markets and 715 Technology Enablers - Critical Communications; Stage 1 716 (Release 14)", 2015. 718 [TR23.718] 719 "3GPP TR23.718, Technical Specification Group Services and 720 System Aspects; Architecture enhancement for flexible 721 mobile service steering", 2015. 723 [TR23.975] 724 "3GPP TR23.975, IPv6 Migration Guidelines", June 2011. 726 [TS23.003] 727 "3GPP TS23.003, Technical Specification Group Core Network 728 and Terminals; Numbering, addressing and identification", 729 2015. 731 [TS29.212] 732 "3GPP TS29.212, Policy and Charging Control (PCC) over Gx/ 733 Sd reference point", December 2011. 735 [WT317] BBF, "Network Enhanced Residential Gateway", August 2015. 737 Authors' Addresses 739 Mohamed Boucadair 740 Orange 741 Rennes 3500, France 743 Email: mohamed.boucadair@orange.com 745 Dirk von Hugo 746 Telekom Innovation Laboratories 747 Deutsche-Telekom-Allee 7 748 D-64295 Darmstadt 749 Germany 751 Email: Dirk.von-Hugo@telekom.de 752 Behcet Sarikaya 753 Huawei 754 5340 Legacy Dr. 755 Plano, TX 75024 757 Email: sarikaya@ieee.org