Network Working Group B. Sarikaya Internet-Draft Huawei Intended status: Standards Track D. von Hugo Expires: March 12, 2016 Telekom Innovation Laboratories M. Boucadair Orange September 9, 2015 Service Function Chaining (SFC): Subscriber and Host Identification Considerations draft-sarikaya-sfc-hostid-serviceheader-00.txt Abstract This document discusses considerations related to passing host- and subscriber-related information to upstream Service Functions for the sake of policy enforcement and appropriate SFC-inferred forwarding. Once the information is consumed by SFC-aware functional elements, the information is stripped from packets so that privacy-sensitive information is not leaked outside an SFC-enabled domain. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on March 12, 2016. Copyright Notice Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents Sarikaya, et al. Expires March 12, 2016 [Page 1] Internet-Draft Subscriber and Hostid in SFC September 2015 carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 3 3. Problem Space and Sample Use Cases . . . . . . . . . . . . . 3 3.1. Parental Control Use Case . . . . . . . . . . . . . . . . 4 3.2. Traffic Offload Use Case . . . . . . . . . . . . . . . . 5 3.3. Mobile Network Use Cases . . . . . . . . . . . . . . . . 5 4. Host and Subscriber Identification SFC Meta Data . . . . . . 5 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 8 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 9.1. Normative References . . . . . . . . . . . . . . . . . . 9 9.2. Informative References . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 1. Introduction This document adheres to the architecture defined in [I-D.ietf-sfc-architecture]. This document assumes the reader is familiar with [I-D.ietf-sfc-architecture] and [I-D.ww-sfc-control-plane]. This document focuses on aspects related to passing host- and subscriber-related information to upstream SFs when required for the sake of policy enforcement. Indeed, subscriber-related information may be needed for upstream service functions (SFs) when per- subscriber policies are to be enforced upstream in the network while the information conveyed by the original packets does not allow for uniquely identifying a host or a subscriber. Host-related information may be required to implement services such as Traffic policy control, or Parental Control Function and Traffic Offload that are commonly used by operators to enable advanced services to the customers used in typical home network architectures [I-D.liu-sfc-use-cases]. Another typical example is the applicability of service chaining in the context of mobile networks (typically, in the 3GPP defined (S)Gi Interface) [I-D.ietf-sfc-use-case-mobility]. Because of the Sarikaya, et al. Expires March 12, 2016 [Page 2] Internet-Draft Subscriber and Hostid in SFC September 2015 widespread use of private addressing in those networks, if advanced SFs to be invoked are located after a NAT device (that can reside in the PGW or in a distinct operator-specific node), the identification based on the internal IP address is not anymore possible once the NAT has been crossed. For this reason, means to allow passing the internal information may ease the operation of an SFC-enabled domain. Furthermore, some SFs that are not enabled on the PGW may require a subscriber identifier e.g., International Mobile Subscriber Identity (IMSI) to execute their function. Other use cases that suffer from identification problems are discussed in [RFC7620]. Because both a host and subscriber Identifiers may be required in some scenarios, this document defines two objects that allow carrying this information. This document does not make any assumption about the structure of these identifiers; each information is treated as an opaque value. The meaning and validation of each of these identifiers can be the responsibility of the control plane [I-D.ww-sfc-control-plane]. Once the host-related and/or subscriber-related information is consumed by SFC-aware functional elements, the information is stripped from packets so that privacy-sensitive information is not leaked outside an SFC-enabled domain. See Section 7 for more discussion on privacy. Within this document, only identification issues for the sake of services in a local administrative domain are discussed. Global identification issues are out of scope. 2. Conventions and Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. 3. Problem Space and Sample Use Cases Enforcing Policies based on internal IP address: Because of the address sharing, implicit CPE/UE identification that relies on the source IP address cannot be implemented within the administrative domain because the same IP address is shared among various connected devices (CPE for the fixed case or UE for the mobile case). In the meantime, policies are something provisioned based on the internal IP address assigned to those devices. Means to pass the internal IP address beyond an address sharing device for the Sarikaya, et al. Expires March 12, 2016 [Page 3] Internet-Draft Subscriber and Hostid in SFC September 2015 sake of per-host or per-subscriber policy enforcement is needed in some SFC deployments. Also, stable identifiers such as MAC address, IMSI can be passed. Enforcing Policies based on a subscriber identifier: In case some deployments may require per-subscriber policies, a means is required to pass subscriber ID to those upstream SFs which are responsible for or rely on policy enforcement. Below we present some use cases where problems related to enforcing policies based on subscriber and/or host identities cannot be achieved in service function chaining. It is important to note that subscriber and host identification due to address and prefix sharing is not specific to the service function chaining. This problem occurs in many other use cases as discussed in [RFC7620]. 3.1. Parental Control Use Case Parental control service function searches each packet for certain content, e.g. destination addresses corresponding to certain URL like www.thisbizarresite.com. Parental control function should keep this information (URL and source IP address) in its cache so that all subsequent packets can be filtered for certain users from the Web server [WT317]. Parental control function receives next packet from the recorded URL. Enforcing the parental control policies may depend on the internal IP address, i.e., the address of the host that is being subject to the parental control. Parental control function must be able to identify incoming traffic to be filtered, e.g. specific URL information. All other traffic is not subject to filtering. Parental control function filters all traffic coming from indicated URL only for the specific hosts identified by the service logic. For the virtual CPE case, the access node will receive privately- addressed packets. Because private addresses are overlapping between several subscribers, the internal IP address will need to be copied into a dedicated field (Host ID context) so that upstream function responsible for Parental Control can process the packets appropriately. Furthermore, the subscriber identifier may also be required for authorization purposes. Sarikaya, et al. Expires March 12, 2016 [Page 4] Internet-Draft Subscriber and Hostid in SFC September 2015 3.2. Traffic Offload Use Case Traffic offload service function works on each flow/service originated from mobile terminal and decides if it should be offloaded to the broadband network or sent back to the mobile network. In this use case policy enforcement is based on the subscriber identifier. The broadband network must obtain the subscription profile from the mobile network and decide if the traffic coming from this subscriber needs to be offloaded or not. If offloading is needed, this usually means that the subscriber identifier needs to be known on the SFC- aware forwarders. 3.3. Mobile Network Use Cases Many service functions (SF) can be executed in different combinations in a mobile network [I-D.ietf-sfc-use-case-mobility]. Placement of NAT function plays an important role if it is used. If NAT function is collocated with P-GW as in [TR23.975] or is located right after the P-GW then all service functions located upstream can only see the translated address as the source address from all User Equipments (UEs). Internal IP address-related part of their policy set won't be able to execute their service logic. As a consequence, means to pass the internal IP address (i.e., the original one before executing the NAT function) through the service chain may be needed. Note that the same problem occurs in case IPv6 is being used by UEs but UEs need to communicate with an external legacy server which is IPv4-only. This can be made possible with NAT64 as described in [RFC6146]. NAT64 uses IPv4 address on its outgoing interface which is shared by all UEs. So in the case of NAT64 host identification also becomes an issue in service chaining. 4. Host and Subscriber Identification SFC Meta Data Host Identifier and Subscriber Identifier are defined as optional variable length context headers as defined in [I-D.ietf-sfc-nsh]. Their structure is shown in Figure 1 and Figure 2, respectively. Host Identifier context header may convey an internal IP address, VLAN or MAC address. While the subscriber identifier itself is used to convey an identifier already assigned by the service provider to uniquely identify a subscriber, the structure of the identifier is deployment- specific. Typically, this header may convey the IMSI, opaque subscriber Identifier, etc. Sarikaya, et al. Expires March 12, 2016 [Page 5] Internet-Draft Subscriber and Hostid in SFC September 2015 The classifier and SFC-aware Service Functions MAY be instructed via a control interface to inject or strip a host identifier and/or subscriber identifier context headers. Also, the data to be injected in such header SHOULD be configured to nodes authorized to inject such headers. Failures to inject such headers SHOULD be logged locally while a notification alarm MAY be sent to a Control Element. The level of sending notification alarms SHOULD be configurable by the control plane. The control plane SHOULD instruct Ingress Border Nodes about the behavior to follow when receiving Host ID and/or Subscriber ID context headers from external SFC-enabled domain. If no instruction is provided, the default behavior is to strip such context headers when received from external SFC-enabled domain. The control plane SHOULD instruct Egress Border Nodes about the behavior to follow for processing packets conveying Host ID and/or Subscriber ID context headers. If no instruction is provided, the default behavior is to strip such context headers before sending the packets outside an SFC-enabled domain. SFC-aware SFs and Proxies that are not acting as SFC border nodes MAY be instructed to strip a host ID and/or subscriber ID from the packet or to pass the data to the next SF in the chain after consuming the content of the headers. If no instruction is provided, the default behavior is to maintain such context headers so that the information can be passed to next SFC-aware hops. SFC-aware functions MAY be instructed via the control plane about the validation checks to follow on the content of these context headers (e.g., accept only some lengths) and the behavior to follow. For example, SFC-aware nodes may be instructed to ignore the context header, to remove the context header from the packet, etc. Nevertheless, this specification does not require nor preclude such additional validation checks. These validation checks are deployment-specific. If validation checks fail on a context header, an SFC-aware node ignores that context header. The event SHOULD be logged locally while a notification alarm may be sent to a control element if the SFC-aware node is instructed to do so. Only one Host Identifier context header MUST be present in the SFC header. Only one subscriber Identifier context header MUST be present in the SFC header. Sarikaya, et al. Expires March 12, 2016 [Page 6] Internet-Draft Subscriber and Hostid in SFC September 2015 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TLV Class |C| Type |R|R|R| Len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Host Identifier ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1: Host Identifier Metadata The description of the fields is as follows: The fields TLV Class, etc. are defined in [I-D.ietf-sfc-nsh] Host Identifier: Can be IPv4 or IPv6 address, IPv6 prefix, a subset of IP address/prefix, a MAC address, or any deployment-specific identifier. It could also be in Root NAI format containing arbitrary number of characters [TS23.003]. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TLV Class |C| Type |R|R|R| Len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Subscriber Identifier ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2: Subscriber Identifier Metadata The description of the fields is as follows: The fields TLV Class, etc. are defined in [I-D.ietf-sfc-nsh] Subscriber Identifier: Conveys an opaque subscriber identifier. 5. IANA Considerations To be completed. 6. Security Considerations Data plane SFC-related security considerations are discussed in [I-D.ietf-sfc-architecture]. Control plane SFC-related security considerations are discussed in [I-D.ww-sfc-control-plane]. Sarikaya, et al. Expires March 12, 2016 [Page 7] Internet-Draft Subscriber and Hostid in SFC September 2015 Security considerations that are related to the host identifier are discussed in [RFC6967]. A misbehaving node can inject host/subscriber Identifiers to disturb the service offered to some host or subscribers. Also, a misbehaving node can inject host/subscriber identifiers as an attempt to be granted access to some services. To prevent such misbehavior, only trusted nodes MUST be able to inject such context headers. Nodes that are involved in a SFC-enabled domain must be trusted. Means to check that only authorized nodes are solicited when a packet is crossing an SFC-enabled domain. 7. Privacy Considerations The metadata defined in this document for host and subscriber identifiers may reveal private information about the host and/or the subscriber. Some privacy-related considerations for Internet Protocols are discussed in [RFC6973]. In the light of these privacy considerations, it is important to state that the host and subscriber metadata must not be exposed outside the operator's domain [I-D.ww-sfc-control-plane]. The information conveyed in host and/or subscriber identifiers is already known to an administrative entity managing an SFC-enabled domain. Some of that information is already conveyed in the original packets from a host (e.g., internal IP address) while other information is collected from various sources (e.g., GTP tunnel, line identifier, etc.). Conveying such sensitive information in packets may expose subscribers' sensitive data to entities that are not allowed to receive such information. Misconfiguring SFC egress nodes is a threat that may have negative impacts on privacy (e.g., some operational networks leak the MSISDN outside). Operators must ensure their SFC-enabled domain is appropriately configured so that any privacy-related information is not exposed a domain. Some use cases that rely upon the solution defined in this document may disclose some additional privacy-related information (e.g., a host identifier of a terminal within a customer premises for the parental control case). It is assumed that this information is provided upon approval from a subscriber. For example, a customer may provide the information as part of its service management interface or as part of explicit subscription form. As a common recommendation for deployment relying on SFC header, a CPE MUST NOT leak non-authorized information to the service provider by means of an SFC header. Note, the use cases discussed in this document assume the service header is used exclusively within the service administrative domain. CPEs are not required to be SFC-aware. Sarikaya, et al. Expires March 12, 2016 [Page 8] Internet-Draft Subscriber and Hostid in SFC September 2015 8. Acknowledgements TBD. 9. References 9.1. Normative References [I-D.ietf-sfc-nsh] Quinn, P. and U. Elzur, "Network Service Header", draft- ietf-sfc-nsh-01 (work in progress), July 2015. [I-D.ww-sfc-control-plane] Li, H., Wu, Q., Boucadair, M., Jacquenet, C., Haeffner, W., Lee, S., Parker, R., Dunbar, L., Malis, A., Halpern, J., Reddy, T., and P. Patil, "Service Function Chaining (SFC) Control Plane Components & Requirements", draft-ww- sfc-control-plane-06 (work in progress), June 2015. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . 9.2. Informative References [I-D.ietf-sfc-architecture] Halpern, J. and C. Pignataro, "Service Function Chaining (SFC) Architecture", draft-ietf-sfc-architecture-11 (work in progress), July 2015. [I-D.ietf-sfc-use-case-mobility] Haeffner, W., Napper, J., Stiemerling, M., Lopez, D., and J. Uttaro, "Service Function Chaining Use Cases in Mobile Networks", draft-ietf-sfc-use-case-mobility-04 (work in progress), July 2015. [I-D.liu-sfc-use-cases] Will, W., Li, H., Huang, O., Boucadair, M., Leymann, N., Qiao, F., Qiong, Q., Pham, C., Huang, C., Zhu, J., and P. He, "Service Function Chaining (SFC) General Use Cases", draft-liu-sfc-use-cases-08 (work in progress), September 2014. [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers", RFC 6146, DOI 10.17487/RFC6146, April 2011, . Sarikaya, et al. Expires March 12, 2016 [Page 9] Internet-Draft Subscriber and Hostid in SFC September 2015 [RFC6967] Boucadair, M., Touch, J., Levis, P., and R. Penno, "Analysis of Potential Solutions for Revealing a Host Identifier (HOST_ID) in Shared Address Deployments", RFC 6967, DOI 10.17487/RFC6967, June 2013, . [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., Morris, J., Hansen, M., and R. Smith, "Privacy Considerations for Internet Protocols", RFC 6973, DOI 10.17487/RFC6973, July 2013, . [RFC7620] Boucadair, M., Ed., Chatras, B., Reddy, T., Williams, B., and B. Sarikaya, "Scenarios with Host Identification Complications", RFC 7620, DOI 10.17487/RFC7620, August 2015, . [TR23.975] "3GPP TR23.975, IPv6 Migration Guidelines", June 2011. [TS23.003] "3GPP TS23.003, Technical Specification Group Core Network and Terminals; Numbering, addressing and identification", 2015. [TS29.212] "3GPP TS29.212, Policy and Charging Control (PCC) over Gx/ Sd reference point", December 2011. [WT317] BBF, , "Network Enhanced Residential Gateway", August 2015. Authors' Addresses Behcet Sarikaya Huawei 5340 Legacy Dr. Plano, TX 75024 Email: sarikaya@ieee.org Sarikaya, et al. Expires March 12, 2016 [Page 10] Internet-Draft Subscriber and Hostid in SFC September 2015 Dirk von Hugo Telekom Innovation Laboratories Deutsche-Telekom-Allee 7 D-64295 Darmstadt Germany Email: Dirk.von-Hugo@telekom.de Mohamed Boucadair Orange Rennes 3500, France Email: mohamed.boucadair@orange.com Sarikaya, et al. Expires March 12, 2016 [Page 11]