Network Working Group M. Boucadair
Internet-Draft Orange
Intended status: Standards Track D. von Hugo
Expires: December 3, 2016 Telekom Innovation Laboratories
B. Sarikaya
Huawei
June 1, 2016
Service Function Chaining (SFC): Subscriber and Host Identification
Considerations
draft-sarikaya-sfc-hostid-serviceheader-02.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 elements of an SFC-
enabled domain, 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 December 3, 2016.
Copyright Notice
Copyright (c) 2016 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
Boucadair, et al. Expires December 3, 2016 [Page 1]
Internet-Draft Subscriber and Hostid in SFC June 2016
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.
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 . . . . . . 6
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
6. Security Considerations . . . . . . . . . . . . . . . . . . . 8
7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 9
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
9.1. Normative References . . . . . . . . . . . . . . . . . . 10
9.2. Informative References . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
1. Introduction
This document focuses on aspects related to passing host- and
subscriber-related information to upstream Service Functions (SFs)
when required for the sake of policy enforcement. Indeed,
subscriber-related information may be needed for upstream 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.
This document adheres to the architecture defined in [RFC7665]. This
document assumes the reader is familiar with [RFC7665] and
[I-D.ietf-sfc-control-plane].
Host-related information may be required to implement services such
as, but not limited to, traffic policy control, or parental control
and traffic offload that are commonly used by operators to enable
added value services to their customers in typical 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
Boucadair, et al. Expires December 3, 2016 [Page 2]
Internet-Draft Subscriber and Hostid in SFC June 2016
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 Packet Data Network (PDN) Gateway (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. As
such, 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
further 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
host 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.ietf-sfc-control-plane].
Host-related and/or subscriber-related information is stripped from
packets exiting an SFC-enabled domain so that privacy-sensitive
information is not leaked outside the 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].
The reader should be familiar with the terms defined in [RFC7665].
3. Problem Space and Sample Use Cases
Enforcing Policies based on an 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
Boucadair, et al. Expires December 3, 2016 [Page 3]
Internet-Draft Subscriber and Hostid in SFC June 2016
pass the internal IP address beyond an address sharing device for the
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.
Boucadair, et al. Expires December 3, 2016 [Page 4]
Internet-Draft Subscriber and Hostid in SFC June 2016
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 SFs 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.
[I-D.ietf-sfc-use-case-mobility] identifies the following
information:
o Charging ID
o Subscriber ID
o GGSN or PGW IP address
o Serving Gateway Support Node (SGSN) or SGW IP address
o International Mobile Equipment Identity (IMEI)
o International Mobile Subscriber Identity (IMSI)
Boucadair, et al. Expires December 3, 2016 [Page 5]
Internet-Draft Subscriber and Hostid in SFC June 2016
o Mobile Subscriber ISDN Number (MSISDN)
o UE IP address
4. Host and Subscriber Identification SFC Meta Data
Host Identifier and Subscriber Identifier are defined as optional
variable length context headers. 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 or an information that is required to enforce a
per-subscriber policy, the structure of the identifier is deployment-
specific. Typically, this header may convey the IMSI, opaque
subscriber Identifier, etc.
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
Boucadair, et al. Expires December 3, 2016 [Page 6]
Internet-Draft Subscriber and Hostid in SFC June 2016
(e.g., accept only some lengths, accept some subtypes) 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.
Multiple subscriber Identifier context headers MAY be present in the
SFC header each conveying a distinct sub-type.
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SubT | |
+-+-+-+-+-+-+-+-+
~ Subscriber Identifier ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Subscriber Identifier Metadata
Boucadair, et al. Expires December 3, 2016 [Page 7]
Internet-Draft Subscriber and Hostid in SFC June 2016
The description of the fields is as follows:
The fields TLV Class, etc. are defined in [I-D.ietf-sfc-nsh]
SubT field of 8 bits indicates the sub-type of the information
conveyed in the "Subscriber Identifier" field. The following values
are defined:
o 0x00: Opaque value
o 0x01: Charging ID. The structure of this ID is deployment-
specific.
o 0x02: Subscriber ID. The structure of this ID is deployment-
specific.
o 0x03: GGSN or PGW IP address/prefix
o 0x04: Serving Gateway Support Node (SGSN) or SGW IP address/prefix
o 0x05: International Mobile Equipment Identity (IMEI)
o 0x06: International Mobile Subscriber Identity (IMSI)
o 0x07: Mobile Subscriber ISDN Number (MSISDN)
o 0x08: UE IP address
Subscriber Identifier: Conveys an opaque subscriber identifier or an
identifier that corresponds to the sub-type.
5. IANA Considerations
To be completed.
6. Security Considerations
Data plane SFC-related security considerations are discussed in
[RFC7665]. Control plane SFC-related security considerations are
discussed in [I-D.ietf-sfc-control-plane].
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
Boucadair, et al. Expires December 3, 2016 [Page 8]
Internet-Draft Subscriber and Hostid in SFC June 2016
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.ietf-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.
8. Acknowledgements
Comments from Joel Halpern are appreciated.
Boucadair, et al. Expires December 3, 2016 [Page 9]
Internet-Draft Subscriber and Hostid in SFC June 2016
9. References
9.1. Normative References
[I-D.ietf-sfc-control-plane]
Boucadair, M., "Service Function Chaining (SFC) Control
Plane Components & Requirements", draft-ietf-sfc-control-
plane-06 (work in progress), May 2016.
[I-D.ietf-sfc-nsh]
Quinn, P. and U. Elzur, "Network Service Header", draft-
ietf-sfc-nsh-05 (work in progress), May 2016.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
[RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function
Chaining (SFC) Architecture", RFC 7665,
DOI 10.17487/RFC7665, October 2015,
<http://www.rfc-editor.org/info/rfc7665>.
9.2. Informative References
[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-06 (work in
progress), April 2016.
[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.
[I-D.quinn-sfc-nsh-tlv]
Quinn, P., Elzur, U., Majee, S., and J. Halpern, "Network
Service Header TLVs", draft-quinn-sfc-nsh-tlv-01 (work in
progress), April 2016.
[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, <http://www.rfc-editor.org/info/rfc6146>.
Boucadair, et al. Expires December 3, 2016 [Page 10]
Internet-Draft Subscriber and Hostid in SFC June 2016
[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,
<http://www.rfc-editor.org/info/rfc6967>.
[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,
<http://www.rfc-editor.org/info/rfc6973>.
[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, <http://www.rfc-editor.org/info/rfc7620>.
[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
Mohamed Boucadair
Orange
Rennes 3500, France
Email: mohamed.boucadair@orange.com
Dirk von Hugo
Telekom Innovation Laboratories
Deutsche-Telekom-Allee 7
D-64295 Darmstadt
Germany
Email: Dirk.von-Hugo@telekom.de
Boucadair, et al. Expires December 3, 2016 [Page 11]
Internet-Draft Subscriber and Hostid in SFC June 2016
Behcet Sarikaya
Huawei
5340 Legacy Dr.
Plano, TX 75024
Email: sarikaya@ieee.org
Boucadair, et al. Expires December 3, 2016 [Page 12]