Network Working Group B. Sarikaya Internet-Draft L. Xue Intended status: Informational Huawei Expires: November 4, 2014 May 3, 2014 Host Identification Problem in Service Function Chaining Use Cases draft-sarikaya-sfc-address-sharing-in-sfc-00.txt Abstract The purpose of this document is to present host identification problem due to the address and prefix sharing in service function chaining. We have identified this problem in the use cases of the parental control service and offloading service in home networks and also some use cases in mobile networks. 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 November 4, 2014. Copyright Notice Copyright (c) 2014 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 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. Sarikaya & Xue Expires November 4, 2014 [Page 1] Internet-Draft Address Sharing in SFC May 2014 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 3 3. Service Function Execution . . . . . . . . . . . . . . . . . 3 4. Issue Description . . . . . . . . . . . . . . . . . . . . . . 4 4.1. Parental Control Use Case . . . . . . . . . . . . . . . . 4 4.2. Traffic Offload Use Case . . . . . . . . . . . . . . . . 5 4.3. Mobile Network Use Cases . . . . . . . . . . . . . . . . 5 5. Possible Solution Approaches . . . . . . . . . . . . . . . . 6 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 7. Security Considerations . . . . . . . . . . . . . . . . . . . 6 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 9.1. Normative References . . . . . . . . . . . . . . . . . . 7 9.2. Informative References . . . . . . . . . . . . . . . . . 7 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 1. Introduction The use cases described in this document belong to service function chaining (SFC) area [I-D.liu-sfc-use-cases], [I-D.haeffner-sfc-use-case-mobility]. Service functions like Parental Control, Traffic Offloader, Web Proxy, Load Balancer, etc. can be executed in a chained fashion. The order of execution of each function is controlled by an abstract entity called Service Chaining Enforcement Points (SCEP) [I-D.beliveau-sfc-architecture]. Each service function is directly connected to an SCEP. Traffic policy control, such as Parental Control Function and Traffic Offloader are commonly used by operators to enable flexible service to the customers. The architecture we assume is shown in Figure 1. It is a typical home network architecture. Address sharing/host identification issue comes up if the residential gateway (RG) is a NAT box in IPv4 or a single prefix is assigned to the RG in DHCPv6-Prefix Delegation in IPv6 [I-D.boucadair-intarea-host-identifier-scenarios]. Multiple hosts are sharing the same public IPv4 address or single IPv6 prefix. In a related document, [I-D.boucadair-sfc-design-analysis], the issue of host id or subscriber id being part of Service Function Chaining header is discussed. This discussion is motivated by the same reason as we have in this document: address and prefix sharing in service function chaining. Sarikaya & Xue Expires November 4, 2014 [Page 2] Internet-Draft Address Sharing in SFC May 2014 Some earlier solution approaches to the host identification problem are analysed in [RFC6967]. It is not clear if those approaches can also be used in the service function chaining use cases. 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. Service Function Execution We assume a service function chaining architecture similar to [I-D.beliveau-sfc-architecture]. In its simplified form, possibly suitable in home networks, the service chain enforcement point is also the ingress router or edge router, e.g. Broadband Network Gateway. In this case parental control function and all other functions are directly connected to SCEP. There is an egress router that routes traffic to the edge router, see Figure 1. Parental control service function is needed to filter the traffic from the Internet for certain content. Home users connect to the Internet after getting their address from RG. In case of NAT at the RG, all outgoing traffic carries the same address for all users, i.e. RG address for its WAN interface. In case RG is assigned a single prefix, all outgoing IPv6 packets contain the same prefix. Encrypted web traffic (https) represents a very significant part of Web traffic and is likely to become the main or even the only method to carry Web data over the Internet. Service functions MUST be able to decrypt such encrypted traffic, e.g. using Secure Socket Layer (SSL) [SD326]. In case of address sharing/host identification, being able to decrypt encrypted data becomes a requirement in order to be able to access the URL and user information to filter. However this issue is out of scope. With data services rapidly increasing, the traditional cellular network becomes the bottleneck in providing mobile services mainly because of the increasing bandwidth demand. Operators are trying to offload the data traffic from the mobile subscribers to the broadband network. Traffic offloader service function is needed in the broadband access network for this purpose. One common broadband access network for offload is home network. Traffic offloader service function decides on each flow/service coming from the hosts at home if they should be routed to the broadband network, i.e. offloaded or they should be sent to the packet data network gateway fo the mobile network. Sarikaya & Xue Expires November 4, 2014 [Page 3] Internet-Draft Address Sharing in SFC May 2014 +----------------+ +-----------------+ +-----------------+ Service Function |Parental Control| |Traffic Offloader| |Other Functions | Chain +----------------+ +-----------------+ +-----------------+ \ / --------------------------------------------- --+- +----+ \ / --+- / \ |Rout| +-------------+ / \ +-------------+ | Home || ed |----| Edge Router |-----|Network | --- | Router | | Network|| RG | +-------------+ | | | (Egress) | \ / +----+ \ / +-------------+ ---- ---- | --+- / \ |Internet| | | \ / ---- Figure 1: Service Chaining in Home Network 4. Issue Description It is important to note that 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 [I-D.boucadair-intarea-host-identifier-scenarios]. 4.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. Parental control service should send the packet back to SCEP to be forwarded to the home network [SD326]. Parental control function receives next packet from the recorded URL. Now it needs to decide to filter it or not. Filtering for specific host should depend on the source address, i.e. the address of the host that is being subject to the parental control in IPv4 or the prefix of the host that is being subject to the parental control in IPv6. In case of NAT'ed RG, all incoming packets from one RG contain the same address, i.e. WAN interface address of RG. In case of IPv6 with prefix sharing, all incoming packets contain the same prefix. In order to do the parental control on the incoming traffic, parental control service function needs to identify each host. A typical host Sarikaya & Xue Expires November 4, 2014 [Page 4] Internet-Draft Address Sharing in SFC May 2014 identity is its IP address in broadband network. In Figure 1, RG knows identifiers of each host in the home network. Edge router needs to identify the host so that it can inform the service functions and set the proper service chain. Edge router MUST set host identifier state in the service functions that need it, e.g. 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 control enforcement point. 4.2. Traffic Offload Use Case Traffic offloader service function works on each flow/service and decides if it should be offloaded to the broadband network or sent back to the mobile network. In this scenario, the broadband network MUST obtain the subscriber subscription 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 source address of the subscriber needs to be known on the edge router. In case of NAT'ed RG, all the host's information is lost, this introduces a major challenge on how to obtain host identification to decide to offload the traffic or not. 4.3. Mobile Network Use Cases Many service functions (SF) can be executed in different combinations in a mobile network as Figure 2 which is adopted from [I-D.haeffner-sfc-use-case-mobility] shows. Placement of NAT function plays an important role if it is used. If NAT function is collocated with P-GW as in [TR23.975] then all service functions like SF1 through SF9 can only see P-GW Gi interface address as the source address from all UEs. Individual host addresses can not be found. 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. Sarikaya & Xue Expires November 4, 2014 [Page 5] Internet-Draft Address Sharing in SFC May 2014 | +---(S)Gi-LAN -----------+ | | | | | +---[SF1]-[SF3]-[SF5]-- | | / | [UE]---[eNB]===[S-GW]===[P-GW+NAT]------[SF2]-[SF4]-[SF6]-- | \ | | +---[SF7]-[SF8]-[SF9]-- | Figure 2: Service Chaining in Mobile Network 5. Possible Solution Approaches A two step solution approach can be taken. In the first step the gateway gets to know the host identifiers. In mobile network Figure 2 this is already the case. The next step is signals the host identifiers to the service function that needs them like parental control, load balancer, etc. A simple UDP application can be developed for the first step. The client, in this case NAT'ed RG can send the host identifier to the server, the gateway. The same protocol can be used for the second step, this time the gateway becomes the client and the service function is the server. For the second step, a protocol similar to GI-DS-Lite is recommended in which a Context Identifier (CID) is used to multiplex flows in the tunnel between the gateway and the service function and the service function uses CID as the host identifier [I-D.boucadair-sfc-design-analysis]. Another solution approach for the second step is to define a host identifier field in SFC header and this field can be optional. However in order to accomodate the prefix sharing case, this field should be 128 bits not 64 bits as stated in [I-D.boucadair-sfc-design-analysis]. 6. IANA Considerations This document makes no request to IANA. 7. Security Considerations Any security considerations arising from Service Function Chaining use cases are TBD. Sarikaya & Xue Expires November 4, 2014 [Page 6] Internet-Draft Address Sharing in SFC May 2014 8. Acknowledgements TBD. 9. References 9.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address Translator (NAT) Terminology and Considerations", RFC 2663, August 1999. [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic Host Configuration Protocol (DHCP) version 6", RFC 3633, December 2003. [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers", RFC 6146, April 2011. [TS29.212] "3GPP TS29.212, Policy and Charging Control (PCC) over Gx/ Sd reference point", December 2011. 9.2. Informative References [I-D.beliveau-sfc-architecture] Beliveau, A., "Service Function Chaining Architecture", draft-beliveau-sfc-architecture-00 (work in progress), October 2013. [I-D.boucadair-intarea-host-identifier-scenarios] Boucadair, M., Binet, D., Durel, S., Chatras, B., Reddy, T., Williams, B., Sarikaya, B., and L. Xue, "Host Identification: Use Cases", draft-boucadair-intarea-host- identifier-scenarios-05 (work in progress), April 2014. [I-D.boucadair-sfc-design-analysis] Boucadair, M., Jacquenet, C., Parker, R., and L. Dunbar, "Service Function Chaining: Design Considerations, Analysis & Recommendations", draft-boucadair-sfc-design- analysis-02 (work in progress), February 2014. Sarikaya & Xue Expires November 4, 2014 [Page 7] Internet-Draft Address Sharing in SFC May 2014 [I-D.haeffner-sfc-use-case-mobility] Haeffner, W., Napper, J., Stiemerling, M., and D. Lopez, "Service Function Chaining Use Cases in Mobile Networks", draft-haeffner-sfc-use-case-mobility-01 (work in progress), February 2014. [I-D.liu-sfc-use-cases] Will, W., Li, H., Huang, O., Boucadair, M., Leymann, N., Cao, Z., Qiong, Q., and C. Pham, "Service Function Chaining (SFC) Use Cases", draft-liu-sfc-use-cases-05 (work in progress), April 2014. [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, June 2013. [SD326] BBF, , "Flexible Service Chaining", January 2014. [TR23.975] "3GPP TR23.975, IPv6 Migration Guidelines", June 2011. Authors' Addresses Behcet Sarikaya Huawei 5340 Legacy Dr. Plano, TX 75024 Email: sarikaya@ieee.org Li Xue Huawei NO.156 Beiqing Rd. Z-park, Shi-Chuang-Ke-Ji-Shi-Fan-Yuan, Beijing, HaiDian District 100095 China Email: xueli@huawei.com Sarikaya & Xue Expires November 4, 2014 [Page 8]