idnits 2.17.1 draft-xie-hiaps-hostid-in-sfc-00.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 (March 3, 2015) is 3342 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2663' is defined on line 293, but no explicit reference was found in the text == Unused Reference: 'RFC3633' is defined on line 297, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3633 (Obsoleted by RFC 8415) == Outdated reference: A later version (-11) exists of draft-boucadair-intarea-host-identifier-scenarios-10 == Outdated reference: A later version (-09) exists of draft-ietf-sfc-use-case-mobility-03 Summary: 1 error (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group C. Xie 3 Internet-Draft China Telecom 4 Intended status: Informational W. Liu 5 Expires: September 4, 2015 Huawei Technologies 6 March 3, 2015 8 Host Identification/Address Problem in Service Function Chaining Use 9 Cases 10 draft-xie-hiaps-hostid-in-sfc-00.txt 12 Abstract 14 The purpose of this document is to present host identification 15 problem due to the address and prefix sharing in service function 16 chaining. We have identified this problem in the use cases of the 17 parental control service and offloading service in home networks and 18 also some use cases in mobile networks. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on September 4, 2015. 37 Copyright Notice 39 Copyright (c) 2015 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 3 56 3. Service Function Execution . . . . . . . . . . . . . . . . . 3 57 4. Issue Description . . . . . . . . . . . . . . . . . . . . . . 4 58 4.1. Parental Control Use Case . . . . . . . . . . . . . . . . 4 59 4.2. Traffic Offload Use Case . . . . . . . . . . . . . . . . 5 60 4.3. Port Quota Enforcer Use Case . . . . . . . . . . . . . . 5 61 4.4. Mobile Network Use Cases . . . . . . . . . . . . . . . . 6 62 4.5. Home Network Applications Use Cases . . . . . . . . . . . 6 63 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 64 6. Security Considerations . . . . . . . . . . . . . . . . . . . 6 65 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 66 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 67 8.1. Normative References . . . . . . . . . . . . . . . . . . 7 68 8.2. Informative References . . . . . . . . . . . . . . . . . 7 69 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 71 1. Introduction 73 The use cases described in this document belong to service function 74 chaining (SFC) area [I-D.ietf-sfc-long-lived-flow-use-cases], 75 [I-D.liu-sfc-use-cases], [I-D.ietf-sfc-use-case-mobility]. Service 76 functions like Parental Control, Traffic Offloader, Web Proxy, Load 77 Balancer, etc. can be executed in a chained fashion. The order of 78 execution of each function is controlled by an abstract entity called 79 Service function Forwarder (SFF) [I-D.merged-sfc-architecture]. Each 80 service function is directly connected to an SFF. 82 Traffic policy control, such as Parental Control Function and Traffic 83 Offloader are commonly used by operators to enable flexible service 84 to the customers. The architecture we assume is shown in Figure 1. 85 It is a typical home network architecture. 87 Address sharing/host identification issue comes up if the residential 88 gateway (RG) is a NAT box in IPv4 or a single prefix is assigned to 89 the RG in DHCPv6-Prefix Delegation in IPv6 90 [I-D.boucadair-intarea-host-identifier-scenarios]. Multiple hosts 91 are sharing the same public IPv4 address or single IPv6 prefix. 93 In a related document, [I-D.boucadair-sfc-design-analysis], the issue 94 of host id or subscriber id being part of Service Function Chaining 95 header is discussed. This discussion is motivated by the same reason 96 as we have in this document: address and prefix sharing in service 97 function chaining. 99 Some earlier solution approaches to the host identification problem 100 are analysed in [RFC6967]. It is not clear if those approaches can 101 also be used in the service function chaining use cases. 103 2. Conventions and Terminology 105 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 106 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 107 document are to be interpreted as described in RFC 2119 [RFC2119]. 109 3. Service Function Execution 111 We assume a service function chaining architecture similar to 112 [I-D.merged-sfc-architecture]. In its simplified form, possibly 113 suitable in home networks, the service function forwarder is also the 114 ingress router or edge router, e.g. Broadband Network Gateway. In 115 this case parental control function and all other functions are 116 directly connected to SFF. There is an egress router that routes 117 traffic to the edge router, see Figure 1. 119 Parental control service function is needed to filter the traffic 120 from the Internet for certain content. Home users connect to the 121 Internet after getting their address from RG. In case of NAT at the 122 RG, all outgoing traffic carries the same address for all users, i.e. 123 RG address for its WAN interface. In case RG is assigned a single 124 prefix, all outgoing IPv6 packets contain the same prefix. 126 Encrypted web traffic (https) represents a very significant part of 127 Web traffic and is likely to become the main or even the only method 128 to carry Web data over the Internet. Service functions MUST be able 129 to decrypt such encrypted traffic, e.g. using Secure Socket Layer 130 (SSL) [SD326]. In case of address sharing/host identification, being 131 able to decrypt encrypted data becomes a requirement in order to be 132 able to access the URL and user information to filter. However this 133 issue is out of scope. 135 With data services rapidly increasing, the traditional cellular 136 network becomes the bottleneck in providing mobile services mainly 137 because of the increasing bandwidth demand. Operators are trying to 138 offload the data traffic from the mobile subscribers to the broadband 139 network. Traffic offloader service function is needed in the 140 broadband access network for this purpose. 142 One common broadband access network for offload is home network. 143 Traffic offloader service function decides on each flow/service 144 coming from the hosts at home if they should be routed to the 145 broadband network, i.e. offloaded or they should be sent to the 146 packet data network gateway fo the mobile network. 148 +--------+ +---------+ +---------+ 149 Service |Parental| | Traffic | | Other | 150 Function|Control | |Offloader| |Functions| ---- 151 Chain +--------+ +---------+ +---------+ / \ 152 | | | |Internet| 153 | | | | | 154 +-----------+-------------+ \ / 155 | --+- 156 ---- +----+ | ---- | 157 / \ |Rout| +-------------+ / \ +-------------+ 158 | Home || ed |---| Edge Router |---|Network |--| Router | 159 | Network|| RG | +-------------+ | | | (Egress) | 160 \ / +----+ \ / +-------------+ 161 ---- ---- 163 Figure 1: Service Chaining in Home Network 165 4. Issue Description 167 It is important to note that host identification due to address and 168 prefix sharing is not specific to the service function chaining. 169 This problem occurs in many other use cases as discussed in 170 [I-D.boucadair-intarea-host-identifier-scenarios]. 172 4.1. Parental Control Use Case 174 Parental control service function searches each packet for certain 175 content, e.g. destination addresses corresponding to certain URL like 176 www.thisbizarresite.com. Parental control function should keep this 177 information (URL and source IP address) in its cache so that all 178 subsequent packets can be filtered for certain users from the Web 179 server. Parental control service should send the packet back to SFF 180 to be forwarded to the home network [SD326]. 182 Parental control function receives next packet from the recorded URL. 183 Now it needs to decide to filter it or not. Filtering for specific 184 host should depend on the source address, i.e. the address of the 185 host that is being subject to the parental control in IPv4 or the 186 prefix of the host that is being subject to the parental control in 187 IPv6. In case of NAT'ed RG, all incoming packets from one RG contain 188 the same address, i.e. WAN interface address of RG. In case of IPv6 189 with prefix sharing, all incoming packets contain the same prefix. 191 In order to do the parental control on the incoming traffic, parental 192 control service function needs to identify each host. A typical host 193 identity is its IP address in broadband network. In Figure 1, RG 194 knows identifiers of each host in the home network. Edge router 195 needs to identify the host so that it can inform the service 196 functions and set the proper service chain. 198 Edge router MUST set host identifier state in the service functions 199 that need it, e.g. parental control. Parental control function MUST 200 be able to identify incoming traffic to be filtered, e.g. specific 201 URL information. All other traffic is not subject to filtering. 202 Parental control function filters all traffic coming from indicated 203 URL only for the specific hosts identified by the service function 204 forwarder. 206 4.2. Traffic Offload Use Case 208 Traffic offloader service function works on each flow/service and 209 decides if it should be offloaded to the broadband network or sent 210 back to the mobile network. In this scenario, the broadband network 211 MUST obtain the subscriber subscription from the mobile network and 212 decide if the traffic coming from this subscriber needs to be 213 offloaded or not. If offloading is needed, this usually means that 214 the source address of the subscriber needs to be known on the edge 215 router. In case of NAT'ed RG, all the host's information is lost, 216 this introduces a major challenge on how to obtain host 217 identification to decide to offload the traffic or not. 219 4.3. Port Quota Enforcer Use Case 221 Port Control Protocol (PCP) can be used in address sharing systems 222 where PCP Client requests ports to be assigned from a PCP Server 223 [RFC6887]. PCP Server assigns the ports if the user quota is not 224 exceeded. 226 PCP systems may employ a Port Quota Enforcer to enforce per- 227 subscriber port quotas. Port Quota Enforcers may not be collocated 228 with the address sharing device. It is usually one of the functions 229 in the service chain. 231 Port Quota Enforcer can not identify uniquely the host by looking at 232 the source address. It needs the source address of the subscriber in 233 order to enforce the port quotas. Such a case applies both home 234 networks Figure 1 and mobile networks Figure 2. 236 4.4. Mobile Network Use Cases 238 Many service functions (SF) can be executed in different combinations 239 in a mobile network as Figure 2 which is adopted from 240 [I-D.ietf-sfc-use-case-mobility] shows. Placement of NAT function 241 plays an important role if it is used. 243 If NAT function is collocated with P-GW as in [TR23.975] then all 244 service functions like SF1 through SF9 can only see P-GW Gi interface 245 address as the source address from all UEs. Individual host 246 addresses can not be found. 248 Note that the same problem occurs in case IPv6 is being used by UEs 249 but UEs need to communicate with an external legacy server which is 250 IPv4-only. This can be made possible with NAT64 as described in 251 [RFC6146]. NAT64 uses IPv4 address on its outgoing interface which 252 is shared by all UEs. So in the case of NAT64 host identification 253 also becomes an issue in service chaining. 255 | +---(S)Gi-LAN -----------+ 256 | | | 257 | | +---[SF1]-[SF3]-[SF5]-- 258 | | / | 259 [UE]---[eNB]===[S-GW]===[P-GW+NAT]------[SF2]-[SF4]-[SF6]-- 260 | \ | 261 | +---[SF7]-[SF8]-[SF9]-- 262 | 264 Figure 2: Service Chaining in Mobile Network 266 4.5. Home Network Applications Use Cases 268 To be finished. 270 5. IANA Considerations 272 This document makes no request to IANA. 274 6. Security Considerations 276 This document does not define an architecture nor a protocol; as such 277 it does not raise any security concern. SFC-related security 278 considerations are discussed in [I-D.merged-sfc-architecture] and 279 host identifier related security considerations are discussed in 280 [RFC6967]. 282 7. Acknowledgements 284 TBD. 286 8. References 288 8.1. Normative References 290 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 291 Requirement Levels", BCP 14, RFC 2119, March 1997. 293 [RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address 294 Translator (NAT) Terminology and Considerations", RFC 295 2663, August 1999. 297 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 298 Host Configuration Protocol (DHCP) version 6", RFC 3633, 299 December 2003. 301 [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful 302 NAT64: Network Address and Protocol Translation from IPv6 303 Clients to IPv4 Servers", RFC 6146, April 2011. 305 [TS29.212] 306 3GPP, "Policy and Charging Control (PCC); Reference 307 points", 3GPP TS 29.212, September 2013. 309 8.2. Informative References 311 [I-D.boucadair-intarea-host-identifier-scenarios] 312 Boucadair, M., Binet, D., Durel, S., Chatras, B., Reddy, 313 T., Williams, B., Sarikaya, B., Xue, L., and R. Wheeldon, 314 "Scenarios with Host Identification Complications", draft- 315 boucadair-intarea-host-identifier-scenarios-10 (work in 316 progress), February 2015. 318 [I-D.boucadair-sfc-design-analysis] 319 Boucadair, M., Jacquenet, C., Parker, R., and L. Dunbar, 320 "Service Function Chaining: Design Considerations, 321 Analysis & Recommendations", draft-boucadair-sfc-design- 322 analysis-03 (work in progress), October 2014. 324 [I-D.ietf-sfc-long-lived-flow-use-cases] 325 Krishnan, R., Ghanwani, A., Halpern, J., Kini, S., and D. 326 Lopez, "SFC Long-lived Flow Use Cases", draft-ietf-sfc- 327 long-lived-flow-use-cases-03 (work in progress), February 328 2015. 330 [I-D.ietf-sfc-use-case-mobility] 331 Haeffner, W., Napper, J., Stiemerling, M., Lopez, D., and 332 J. Uttaro, "Service Function Chaining Use Cases in Mobile 333 Networks", draft-ietf-sfc-use-case-mobility-03 (work in 334 progress), January 2015. 336 [I-D.liu-sfc-use-cases] 337 Will, W., Li, H., Huang, O., Boucadair, M., Leymann, N., 338 Qiao, F., Qiong, Q., Pham, C., Huang, C., Zhu, J., and P. 339 He, "Service Function Chaining (SFC) General Use Cases", 340 draft-liu-sfc-use-cases-08 (work in progress), September 341 2014. 343 [I-D.merged-sfc-architecture] 344 Halpern, J. and C. Pignataro, "Service Function Chaining 345 (SFC) Architecture", draft-merged-sfc-architecture-02 346 (work in progress), August 2014. 348 [RFC6887] Wing, D., Cheshire, S., Boucadair, M., Penno, R., and P. 349 Selkirk, "Port Control Protocol (PCP)", RFC 6887, April 350 2013. 352 [RFC6967] Boucadair, M., Touch, J., Levis, P., and R. Penno, 353 "Analysis of Potential Solutions for Revealing a Host 354 Identifier (HOST_ID) in Shared Address Deployments", RFC 355 6967, June 2013. 357 [SD326] BBF, "Flexible Service Chaining", January 2014. 359 [TR23.975] 360 3GPP, "IPv6 Migration Guidelines", 3GPP TR 23.975 11.0.0, 361 June 2010. 363 Authors' Addresses 365 Chongfeng Xie 366 China Telecom 367 Room 708 No.118, Xizhimenneidajie 368 Beijing 100035 370 Email: xiechf@ctbri.com.cn 371 Will(Shucheng) Liu 372 Huawei Technologies 373 Bantian, Longgang District 374 Shenzhen 518129 375 P.R. China 377 Email: liushucheng@huawei.com