Internet DRAFT - draft-xie-hiaps-hostid-in-sfc


Network Working Group                                             C. Xie
Internet-Draft                                             China Telecom
Intended status: Informational                                    W. Liu
Expires: September 4, 2015                           Huawei Technologies
                                                           March 3, 2015

  Host Identification/Address Problem in Service Function Chaining Use


   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

   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 September 4, 2015.

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
   ( 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

Xie & Liu               Expires September 4, 2015               [Page 1]
Internet-Draft           Address Sharing in SFC               March 2015

   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.  Service Function Execution  . . . . . . . . . . . . . . . . .   3
   4.  Issue Description . . . . . . . . . . . . . . . . . . . . . .   4
     4.1.  Parental Control Use Case . . . . . . . . . . . . . . . .   4
     4.2.  Traffic Offload Use Case  . . . . . . . . . . . . . . . .   5
     4.3.  Port Quota Enforcer  Use Case . . . . . . . . . . . . . .   5
     4.4.  Mobile Network Use Cases  . . . . . . . . . . . . . . . .   6
     4.5.  Home Network Applications Use Cases . . . . . . . . . . .   6
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   6
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .   6
   7.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   7
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   7
     8.1.  Normative References  . . . . . . . . . . . . . . . . . .   7
     8.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.ietf-sfc-long-lived-flow-use-cases],
   [I-D.liu-sfc-use-cases], [I-D.ietf-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 function Forwarder (SFF) [I-D.merged-sfc-architecture].  Each
   service function is directly connected to an SFF.

   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

Xie & Liu               Expires September 4, 2015               [Page 2]
Internet-Draft           Address Sharing in SFC               March 2015

   as we have in this document: address and prefix sharing in service
   function chaining.

   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",
   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.merged-sfc-architecture].  In its simplified form, possibly
   suitable in home networks, the service function forwarder 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 SFF.  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

Xie & Liu               Expires September 4, 2015               [Page 3]
Internet-Draft           Address Sharing in SFC               March 2015

   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.

            +--------+  +---------+  +---------+
    Service |Parental|  | Traffic |  |  Other  |
    Function|Control |  |Offloader|  |Functions|          ----
    Chain   +--------+  +---------+  +---------+        /      \
                 |           |             |           |Internet|
                 |           |             |           |        |
                 +-----------+-------------+            \      /
                             |                            --+-
       ----   +----+         |              ----            |
     /      \ |Rout|   +-------------+    /      \   +-------------+
    |  Home  || ed |---| Edge Router |---|Network |--|    Router   |
    | Network|| RG |   +-------------+   |        |  |   (Egress)  |
     \      / +----+                      \      /   +-------------+
       ----                                 ----

                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

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  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 SFF
   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.

Xie & Liu               Expires September 4, 2015               [Page 4]
Internet-Draft           Address Sharing in SFC               March 2015

   In order to do the parental control on the incoming traffic, parental
   control service function needs to identify each host.  A typical host
   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 function

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.  Port Quota Enforcer Use Case

   Port Control Protocol (PCP) can be used in address sharing systems
   where PCP Client requests ports to be assigned from a PCP Server
   [RFC6887].  PCP Server assigns the ports if the user quota is not

   PCP systems may employ a Port Quota Enforcer to enforce per-
   subscriber port quotas.  Port Quota Enforcers may not be collocated
   with the address sharing device.  It is usually one of the functions
   in the service chain.

   Port Quota Enforcer can not identify uniquely the host by looking at
   the source address.  It needs the source address of the subscriber in
   order to enforce the port quotas.  Such a case applies both home
   networks Figure 1 and mobile networks Figure 2.

Xie & Liu               Expires September 4, 2015               [Page 5]
Internet-Draft           Address Sharing in SFC               March 2015

4.4.  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.ietf-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.

                               |      +---(S)Gi-LAN -----------+
                               |      |                        |
                               |      |  +---[SF1]-[SF3]-[SF5]--
                               |      | /                      |
                               |        \                      |
                               |         +---[SF7]-[SF8]-[SF9]--

               Figure 2: Service Chaining in Mobile Network

4.5.  Home Network Applications Use Cases

   To be finished.

5.  IANA Considerations

   This document makes no request to IANA.

6.  Security Considerations

   This document does not define an architecture nor a protocol; as such
   it does not raise any security concern.  SFC-related security
   considerations are discussed in [I-D.merged-sfc-architecture] and
   host identifier related security considerations are discussed in

Xie & Liu               Expires September 4, 2015               [Page 6]
Internet-Draft           Address Sharing in SFC               March 2015

7.  Acknowledgements


8.  References

8.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.

              3GPP, "Policy and Charging Control (PCC); Reference
              points", 3GPP TS 29.212, September 2013.

8.2.  Informative References

              Boucadair, M., Binet, D., Durel, S., Chatras, B., Reddy,
              T., Williams, B., Sarikaya, B., Xue, L., and R. Wheeldon,
              "Scenarios with Host Identification Complications", draft-
              boucadair-intarea-host-identifier-scenarios-10 (work in
              progress), February 2015.

              Boucadair, M., Jacquenet, C., Parker, R., and L. Dunbar,
              "Service Function Chaining: Design Considerations,
              Analysis & Recommendations", draft-boucadair-sfc-design-
              analysis-03 (work in progress), October 2014.

              Krishnan, R., Ghanwani, A., Halpern, J., Kini, S., and D.
              Lopez, "SFC Long-lived Flow Use Cases", draft-ietf-sfc-
              long-lived-flow-use-cases-03 (work in progress), February

Xie & Liu               Expires September 4, 2015               [Page 7]
Internet-Draft           Address Sharing in SFC               March 2015

              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-03 (work in
              progress), January 2015.

              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

              Halpern, J. and C. Pignataro, "Service Function Chaining
              (SFC) Architecture", draft-merged-sfc-architecture-02
              (work in progress), August 2014.

   [RFC6887]  Wing, D., Cheshire, S., Boucadair, M., Penno, R., and P.
              Selkirk, "Port Control Protocol (PCP)", RFC 6887, April

   [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.

              3GPP, "IPv6 Migration Guidelines", 3GPP TR 23.975 11.0.0,
              June 2010.

Authors' Addresses

   Chongfeng Xie
   China Telecom
   Room 708 No.118, Xizhimenneidajie
   Beijing  100035


Xie & Liu               Expires September 4, 2015               [Page 8]
Internet-Draft           Address Sharing in SFC               March 2015

   Will(Shucheng) Liu
   Huawei Technologies
   Bantian, Longgang District
   Shenzhen  518129
   P.R. China


Xie & Liu               Expires September 4, 2015               [Page 9]