idnits 2.17.1 draft-jiang-intarea-conet-gap-analysis-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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (May 9, 2014) is 3640 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) -- Obsolete informational reference (is this intentional?): RFC 2629 (Obsoleted by RFC 7749) -- Obsolete informational reference (is this intentional?): RFC 2818 (Obsoleted by RFC 9110) Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force S. Jiang 3 Internet-Draft Huawei Technologies Co., Ltd 4 Intended status: Informational R. Zhang 5 Expires: November 10, 2014 China Telecom 6 May 9, 2014 8 COllaborative NETwork (CONET) Gap Analysis 9 draft-jiang-intarea-conet-gap-analysis-00 11 Abstract 13 In order to efficiently distinguish ICPs' traffic, a new network 14 operation model - COllaborative NETwork is proposed. The traffic 15 recognization is based on traffic of ICPs' products actively carries 16 collaborative identifiers that both ISPs and ICPs reach consensus in 17 a coordination way. This document analyzes the tecnical gap between 18 the current network functions and required network capability to 19 support COllaborative NETwork. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on November 10, 2014. 38 Copyright Notice 40 Copyright (c) 2014 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 This document may contain material from IETF Documents or IETF 54 Contributions published or made publicly available before November 55 10, 2008. The person(s) controlling the copyright in some of this 56 material may not have granted the IETF Trust the right to allow 57 modifications of such material outside the IETF Standards Process. 58 Without obtaining an adequate license from the person(s) controlling 59 the copyright in such materials, this document may not be modified 60 outside the IETF Standards Process, and derivative works of it may 61 not be created outside the IETF Standards Process, except to format 62 it for publication as an RFC or to translate it into languages other 63 than English. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 68 2. Overview of Technical Consideratins . . . . . . . . . . . . . 3 69 3. Traffic Identifiers . . . . . . . . . . . . . . . . . . . . . 3 70 4. Collaboration between ICPs and ISPs . . . . . . . . . . . . . 5 71 5. Identifying Traffics between End Users and Network . . . . . 7 72 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 73 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 74 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 75 9. Change log [RFC Editor: Please remove] . . . . . . . . . . . 8 76 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 77 10.1. Normative References . . . . . . . . . . . . . . . . . . 8 78 10.2. Informative References . . . . . . . . . . . . . . . . . 9 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 81 1. Introduction 83 While the Internet traffic is continually growing, more and more 84 Internet Content Providers (ICPs) realize the essentiality and 85 advantages to cooperate with Internet Service Providers (ISPs). In 86 order to serve their users better, ICPs raise an emerging requirement 87 that the traffic of their products needs to be treated differently, 88 both in traffic handling process and traffic accounting process. 89 [I-D.fan-intarea-conet-ps-uc] has described such requirement and use 90 cases in details. 92 The biggest technical challenge that network operators have to face 93 is to distinguish the traffic in a finer granularity. Nowadays, DPI 94 (Deep Packet Inspection) or DFI (Deep Flow Inspection) devices have 95 been widely used in identifying application information of the 96 traffic flows. However, they are expensive for both operational cost 97 and time consumption. They are not be able to interact with real- 98 time network operations. A better approach would be traffic of ICPs' 99 products carries traffic identifiers that the network entities of 100 ISPs can easily recognise. The traffic identifers must be consistent 101 in collaboration between ISPs and ICPs. This approach is called 102 COllaborative NETwork (CONET) in this document. 104 This document analyzes the technical gap between the current network 105 functions and required network capability to support CONET. 107 2. Overview of Technical Consideratins 109 Overall, there are three technical aspects that need to be considered 110 in CONET, listed below. This section gives analysis to each aspects. 112 o A traffic identifier. 114 o An ICP notify/negotiate traffic identifiers and the desired 115 processing way regarding to both traffic handling and traffic 116 accounting with an ISP. The policies of traffic processing need 117 to be propagated and network entities need to be configured 118 correspondently within an ISP network. 120 o An end user host or application notify/negotiate their traffic 121 identifiers to/with network. 123 Note: the application-level communication between ICP servers and 124 their client applications on end user hosts, including dynamically 125 deciding the traffic identifier that end user hosts may embed in 126 packets, is out of scope. This document focuses on the network and 127 transport layers only. 129 3. Traffic Identifiers 131 The precondition that a traffic flow can be differentiately handling 132 is that it can recognized by the network entities. In this document, 133 the character in data packet that is used to distinguish a traffic 134 flow or a type/category of traffic flow is called traffic identifier. 135 There are a few requirements for traffic identifiers: 137 o Traffic identifiers must be stable, at least for a lifetime of 138 flow. 140 o Traffic identifiers should be easy to be inspectd by network 141 entities. 143 o Traffic identifiers should accurately distinguish traffic flow or 144 a type/category of traffic flow. 146 o Traffic identifiers must be trustable and protected against any 147 tampers occuring during transportation. 149 o Some traffic identifiers may be convergencable in order to reduce 150 the management complexity on stateful records/policies. 152 o Some traffic identifiers may dynamically decide in the run time. 153 Its decision may involve dynamic involve ISPs, ICPs and end user 154 devices. 156 o Some traffic identifiers may not be set by the traffic initiators. 157 A intermediate node, for example a CPE or an igress router, may 158 remark or set new traffic identifier based on its traffic 159 recognition. 161 o Some traffic identifiers may be meaningful cross administrative 162 boundaries. 164 [I-D.fan-intarea-conet-ps-uc] analyzes two current used traffic 165 identifiers: application-level characteristic information used by DPI 166 and IP addresses of ICP servers. Each of them has a few issues, 167 summaried as below: 169 o Application-level characteristic information used by DPI. 170 Accuracy of application identification cannot be guaranteed. The 171 ability highly depends on vendors. The computing resource 172 consumption is very high. Furthermore, the usage of TLS [RFC5246] 173 and HTTPS [RFC2818] is increasing the difficulties of DPI. 175 o IP addresses of ICP servers. More granular traffic handling 176 cannot be satisfied because a single server may hold multiple 177 services that need to be distinguished. Cache/CDN uses different 178 IP addresses, which may be also shared with other ICPs. 180 There are also other traffic identifiers or components that may 181 compose traffic identifiers: 183 o IP addresses of end user devices. They are nature identifers that 184 can distinguish the communication node. However, one end user 185 node would have many traffics. CONET requires to recognite only 186 these traffics associated with certain ICPs. So, only IP 187 addresses of end user devices are not suffient. Furthermore, many 188 end user devices may be assigned private IPv4 addresses. These 189 addresses are replaced by pulic IPv4 addresses after Network 190 Address Translator (NAT, [RFC3022]). 192 o Port numbers. They are useful to distinguish flows/services from 193 the same node. However, it cannot be used to identify network 194 traffics independently. It must be used together with identifiers 195 that distinguish nodes. 197 o Flow labels [RFC6437]. It is only available in IPv6 traffic. It 198 is changed for every flow. Like port numbers, flow labels cannot 199 be used to identify network traffics independently. Normally, it 200 is used as triple-tuple with source and destination address. 201 Because it is encoded in the IPv6 fixed header, it is easier to 202 recognite than port numbers. However, another disadvantage of 203 flow label is that it is not protected, particularly, there is no 204 mechanism to validate its integrity. 206 o DiffServ Field (Differentiated Services Field, [RFC2474]). It was 207 defined to identify the differentiated services that network 208 should apply on the packets. It is the explicit result for 209 network entities to apply different handling policies accordingly. 210 However, the precondition DiffServ field can be used is that there 211 is strong trust relatioship between the nodes that set DiffServ 212 Field and network entities. 214 Each of the abovementioned traffic identifiers has there own suitable 215 scenarios and limitations. New traffic identifiers may be difined in 216 the future. 218 For many scenarios, the combination of abovementioned traffic 219 identifiers may be used. The 5-tuple (source IP address, destination 220 IP address, source port number, destination port number, IP protocol 221 number) is the most common used traffic identifier to identify a flow 222 accurately in IP layer. However, 5-tuple itself is not tighty 223 assicated with upper-layer applications or contents. There are 224 mapping gaps to use 5-tuple to identify traffics relevant to a 225 certain ICP or its certain services. Another issue of 5-tuple is it 226 is not convergencable. Managing numerous 5-tuple may be a big burden 227 for ISPs. Furthermore, the existing of NATs change the 5-tuple of 228 traffic in the way. Consequently, the traffic identifiers assoicated 229 with IPv4 addresses have to very complicated management issues. 231 4. Collaboration between ICPs and ISPs 233 Firstly, an ICP need to reach consistent with an ISP on traffic 234 identifiers, which network would recognite the ICP traffic 235 accordingly. 237 Then, the ICP notify the specific traffic identifiers, which may have 238 multiple categories, and the desired policies associated with each 239 traffic categories, to the ISP. Then the ISP network can apply these 240 policies when actual traffics happen. 242 The notification process between ICPs and ISPs should be dynamical 243 through a protocol/interface. In 3GPP mobile network, Rx interface 244 [Rx-3GPP] has been defined to allow interaction between ICPs and ISPs 245 using Diameter [RFC6733], and AF-Application-identifier AVP has also 246 been defined to indicate the particular service that the AF 247 (Application Function) service session belongs to. This information 248 may be used by the PCRF (Policy and Charging Rule Function) to 249 differentiate QoS for different application services. 251 However, currently few ICPs have support Diameter protocol. 252 Considering ICP is more familiar with XML based protocol, 3GPP is 253 working on the solutions for an XML based protocol (e.g. SOAP, 254 Restful HTTP, etc.) over Rx interface between the AF and the PCRF 255 [XML_AF_PCRF]. 257 With in an ISP network, Traffic management policy must be propagated 258 to network entities that actually handle traffics. In 3GPP mobile 259 network, Gx interface [Gx-3GPP] has been defined to enable PCRF 260 autonomically configures matching rules regarding to a certain 261 traffic on GGSN/P-GW. 263 BroadBand Forum has also defined the Broadband Policy Control 264 Framework [BPCF] that meets the similar function of Rx and Gx 265 interfaces in the fixed broadband networks. 267 This model has two limitations as below: 269 1. Some ICPs may have one server address, but with different sub- 270 content behind that server address. Because current PCRF only 271 focus on 5-tuple traffic description, it may be difficult to 272 support fine-grained traffic identification. 274 2. Because of lacking involvement from end user devices/ 275 applications, user clients will be difficult to be identified if 276 they are behind NAT (they have NATed IPv4 addresses). Even by 277 correlating the authentication process which could send user 278 information to PCRF, it will still make the whole process very 279 complicated. 281 Another major issue is that this model is ISP-orientied. ICP 282 traffics commonly cross multiple ISP networks. Hence, an ICP may 283 have to work with multiple ISPs independently. The traffic handling 284 across different administration domain may be different, giving the 285 possibility that different ISPs may use different traffic identifiers 286 and different policies. When there was a traffic issue, such as high 287 latency or packet lost, it may be a challenge for the ICP to find out 288 which network has problem. 290 5. Identifying Traffics between End Users and Network 292 Recognition of the traffic from ICP servers to end users may not be 293 very difficult giving the natural convergency. However, when an end 294 user host or application initiates traffic towards ICP contents, 295 particularly some contents may be obtained cache/CDN deployed in the 296 network, it is needed for the end user host or application actively 297 notifiying its traffic to the network. 299 The traffic identifiers used by end user host or application: 301 o may be authorised and assigned by the ICPs after application-level 302 authentication or out-of-band authentication. Then, these traffic 303 identifiers would be carried by packets. 305 o may be dynamically decided by the negotiation between the end user 306 host or application and the network. Out-of-band controlling 307 policies, including network authentication and authorization, may 308 also be notified/negotiated together. 310 o may just describe the traffic characters, and leave the network to 311 recognite them, then mapped into other traffic identifiers that 312 meaningful and explicit within the network. 314 There are many exisiting protocols that may be extended to realize 315 the out-of-band controlling mechanism. However, these exisiting 316 protocols was designed to serve their own purposes and scenarios. 317 Defining a new dedicated protocol may also be an opinion. 319 o Resource ReSerVation Protocol (RSVP, [RFC2205]) is a resource 320 reservation setup protocol. However, so far, that is mainly used 321 among network entities. Next Steps in Signaling (NSIS, [RFC4080]) 322 provides duplicated function as RSVP. It is not widely deployed. 324 o Dynamic Host Configuration Protocol ([RFC2131], [RFC3315]) was 325 designed to provide information, including assigning host IP 326 address, from network to hosts. It is a one-way information 327 provisioning protocol. It does not provide authentication and 328 information protection function. 330 o Radius [RFC2865] and Diameter [RFC6733] provides an 331 Authentication, Authorization and Accounting for network access. 333 Currently, there is no many in-band mechanisms, in which traffic 334 identifier that the end user devices/applications set up is carried 335 within packets. In-band mechanisms is able to traverse 336 administration domains, and it is possible the traffic gets identical 337 handling. The precondition of in-band mechanisms is that the 338 integrity of traffic identifiers can be validated by network 339 entities. 341 6. Security Considerations 343 A trust relationship should be established among end users, ICPs and 344 ISPs. The authentication and authorization for end user access 345 should be as easy as possible. OAUTH protocol [RFC6749] & OpenID 346 [OpenID] may be adopted. 348 Traffic identifiers with packets should be protocted against any 349 tampers occuring during transportation. 351 The protocol that used to notify/negotiate their traffic identifiers 352 to/with network should be protected. 354 7. IANA Considerations 356 This document includes no request to IANA. 358 8. Acknowledgements 360 Valuable comments were received from Peng Fan, Farooq Bari, Weihua 361 Qiao and Hui Deng. 363 This document was produced using the xml2rfc tool [RFC2629]. 365 9. Change log [RFC Editor: Please remove] 367 draft-jiang-intarea-conet-gap-analysis-00: original version, 368 2014-05-09. 370 10. References 372 10.1. Normative References 374 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 375 2131, March 1997. 377 [RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. 378 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 379 Functional Specification", RFC 2205, September 1997. 381 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 382 "Definition of the Differentiated Services Field (DS 383 Field) in the IPv4 and IPv6 Headers", RFC 2474, December 384 1998. 386 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, 387 "Remote Authentication Dial In User Service (RADIUS)", RFC 388 2865, June 2000. 390 [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network 391 Address Translator (Traditional NAT)", RFC 3022, January 392 2001. 394 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 395 and M. Carney, "Dynamic Host Configuration Protocol for 396 IPv6 (DHCPv6)", RFC 3315, July 2003. 398 [RFC4080] Hancock, R., Karagiannis, G., Loughney, J., and S. Van den 399 Bosch, "Next Steps in Signaling (NSIS): Framework", RFC 400 4080, June 2005. 402 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 403 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 405 [RFC6437] Amante, S., Carpenter, B., Jiang, S., and J. Rajahalme, 406 "IPv6 Flow Label Specification", RFC 6437, November 2011. 408 [RFC6733] Fajardo, V., Arkko, J., Loughney, J., and G. Zorn, 409 "Diameter Base Protocol", RFC 6733, October 2012. 411 [RFC6749] Hardt, D., "The OAuth 2.0 Authorization Framework", RFC 412 6749, October 2012. 414 10.2. Informative References 416 [BPCF] BroadBand Forum Technical Report 134, "Broadband Policy 417 Control Framework", July 2012. 419 [Gx-3GPP] 3GPP Work Item 13029, "Gx reference point for Policy and 420 Charging Control", July 2008. 422 [I-D.fan-intarea-conet-ps-uc] 423 Fan, P. and H. Deng, "CONET (Collaborative Network) 424 Problem Statement and Use Cases", draft-fan-intarea-conet- 425 ps-uc-00 (work in progress), March 2014. 427 [OpenID] OpenID Foundation, "OpenID Authentication 2.0 - Final", 428 December 2007, . 430 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 431 June 1999. 433 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 435 [Rx-3GPP] 3GPP Technical Specification 29.214, "Policy and charging 436 control over Rx reference point", July 2008. 438 [XML_AF_PCRF] 439 3GPP Technical Report 29.817, "Study on eXtensible Markup 440 Language (XML) based access of the Application Function 441 (AF) to the Policy and Charging Rules Function (PCRF)", 442 March 2014. 444 Authors' Addresses 446 Sheng Jiang 447 Huawei Technologies Co., Ltd 448 Q14, Huawei Campus, No.156 Beiqing Road 449 Hai-Dian District, Beijing, 100095 450 P.R. China 452 Email: jiangsheng@huawei.com 454 Rong Zhang 455 China Telecom 456 No.109 Zhongshandadao avenue 457 Guangzhou 510630 458 China 460 Email: zhangr@gsta.com