idnits 2.17.1 draft-you-encrypted-traffic-management-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 : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (October 19, 2015) is 3110 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-04) exists of draft-flinck-mobile-throughput-guidance-03 == Outdated reference: A later version (-25) exists of draft-mm-wg-effect-encrypt-02 Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. You 3 Internet-Draft C. Xiong 4 Intended status: Informational Huawei 5 Expires: April 21, 2016 October 19, 2015 7 The Effect of Encrypted Traffic on the QoS Mechanisms in Cellular 8 Networks 9 draft-you-encrypted-traffic-management-00 11 Abstract 13 This document provides a detailed description of the QoS mechanisms 14 of the 3GPP network and why encrypted IP traffic makes current QoS 15 management mechanisms almost useless. Finally, we propose some ideas 16 to solve this conflict to allow QoS mechanisms to be applied to 17 encrypted IP traffic whilst maintaining the confidentiality of the IP 18 traffic. 20 Requirements Language 22 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 23 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 24 document are to be interpreted as described in [RFC2119]. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on April 21, 2016. 43 Copyright Notice 45 Copyright (c) 2015 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 61 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 2.1. Abbreviations and acronyms . . . . . . . . . . . . . . . 3 63 2.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 4 64 3. The Influence of Encryption on the QoS Management . . . . . . 4 65 3.1. IPsec/VPN Tunnel-based IP Layer Encryption Effect . . . . 5 66 3.2. IMS/SIP Session Service Encryption Effect . . . . . . . . 6 67 3.3. HTTP Encryption Effect . . . . . . . . . . . . . . . . . 6 68 4. Potential Co-operative Information between Application and 69 Network . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 70 4.1. Application to Network . . . . . . . . . . . . . . . . . 7 71 4.2. Network to Application . . . . . . . . . . . . . . . . . 8 72 5. Potential Bandwidth Optimization Methods . . . . . . . . . . 8 73 5.1. Intelligent Heuristic Method . . . . . . . . . . . . . . 8 74 5.2. Legacy Protocol Extension . . . . . . . . . . . . . . . . 9 75 5.3. New Substrate Protocol . . . . . . . . . . . . . . . . . 9 76 6. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 10 77 7. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 10 78 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 79 8.1. Normative References . . . . . . . . . . . . . . . . . . 10 80 8.2. Informative References . . . . . . . . . . . . . . . . . 10 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 83 1. Introduction 85 Encryption of internet traffic is to prevent pervasive monitoring and 86 protect customer privacy. Historically, Secure Sockets Layer (SSL) / 87 Transport Layer Security (TLS) were earlier used in financial 88 services to encrypt a subset of Internet traffic, especially 89 financial transactions. However, the shift away from unencrypted 90 traffic towards encrypted traffic is accelerating in recent years 91 [I-D.mm-wg-effect-encrypt] due to concerns about privacy. Google 92 offered end-to-end encryption for Gmail since 2010, and switched all 93 searches over to HTTPS in 2013. YouTube traffic is carried via HTTPS 94 (or QUIC) since 2014. Also, the Snowden revelations [RFC7258] 95 [RFC7624] seem to cause an upward surge in encrypted traffic. A 96 large number of operators began requiring encryption for all XMPP 97 traffic in May 2014 [XMPP]. 99 However, the prevalence of encryption impacts current network 100 services, such as policy control, load balancing, etc. The network 101 services may be less efficient or totally unavailable in the case of 102 fully encrypted traffic. QoS handling is the most important part of 103 the 3GPP radio resource management. 3GPP networks have limited radio 104 and transmission resources and need to strictly schedule the 105 utilization of radio and transmit resources using different 106 granularity of bearers to provide and ensure Quality of Service (QoS) 107 for the IP traffic. Different bearers with different QoS parameters 108 will provide different QoS handling for the IP flows on each bearer. 109 Different IP flows can share the same bearer; IP flows on the same 110 bearer will receive the same QoS handling of the 3GPP network. With 111 this binding mechanism, the 3GPP network can provide any IP flow with 112 its required QoS handling. Therefore, the 3GPP network firstly needs 113 to know the IP flow information and its QoS requirements. If this 114 information is unknown, possibly as a result of encryption applied to 115 the IP flow, the 3GPP network will discard this IP flow or handle the 116 IP flow with default QoS. 118 2. Terminology 120 2.1. Abbreviations and acronyms 122 AF: Application Function 124 ARP: Allocation and retention priority 126 EPS: Evolved packet System 128 IMS: IP Multimedia Subsystem 130 PCRF: Policy and Charging Rules Function 132 QCI: QoS Class Identifier 134 QoS: Quality of Service 136 SDF: Service Data Flow 138 SIP: Session Initiation Protocol 140 SLA: Service-Level Agreement 142 URL: Uniform/Universal Resource Locator 144 2.2. Definitions 146 This section contains definitions for terms used frequently 147 throughout this document. However, many additional definitions can 148 be found in [3GPP 23.203] 150 ARP: The Allocation and Retention Priority for the service data 151 flow consisting of the priority level, the pre-emption capability 152 and the pre-emption vulnerability. 154 IP CAN bearer: An IP transmission path of defined capacity, delay 155 and bit error rate, etc. 157 GBR bearer: An IP CAN bearer with reserved (guaranteed) bitrate 158 resources. 160 Non-GBR bearer: An IP CAN bearer with no reserved (guaranteed) 161 bitrate resources. 163 QoS class identifier: A scalar that is used as a reference to a 164 specific packet forwarding behavior (e.g. packet loss rate, packet 165 delay budget) to be provided to a SDF. 167 QoS: It contains the QoS class identifier and the data rate for a 168 service data flow. 170 Service data flow: An aggregate set of packet flows that matches a 171 service data flow template. 173 Service data flow template: The set of service data flow filters 174 that contains a set of packet flow header parameter values/ranges 175 used to identify one or more of the packet flows. 177 3. The Influence of Encryption on the QoS Management 179 EPS provides different levels of QoS guarantee for IP services. Any 180 IP service can be identified by one or more Service Data Flows (SDFs) 181 of the transfer data. A SDF can be identified by one or more IP Flow 182 Filters, and a SDF is transferred through an EPS bearer. By 183 implementing the QoS of EPS bearer, it can realize the QoS of SDF, 184 and realize the QoS of IP services. The EPS bearer is one type of 185 logical transport channel between the UE to Packet Gateway (PGW). 187 In general, if the cellular network cannot know the SDF of one IP 188 service in advance or the content type of the transmission data and 189 its QoS requirements, the SDF of the IP service is usually mapped to 190 the Default Bearer with the Default QoS or is mapped to a poor ARP 191 (Allocation and retention priority) dedicated EPS (Evolved packet 192 System) Bearer with default QCI or is discarded because of the 193 unknown service information of the SDF based on the predefined 194 operators rules. 196 Through our analysis of impacted services in the case of encrypted 197 traffic, we find that the impacted services can be categorized into 198 three types based on the level of dependence to content visibility: 200 A: Low-level dependence 202 A service that is low-level dependent on the content visibility 203 means the service can be effective providing with flow type (e.g. 204 stream ID) rather than parsing the content itself. The typical 205 services of low-level dependence are IPsec/VPN tunnel, load 206 balancing, etc. 208 B: Middle-level dependence 210 A service that is middle-level dependent on the content visibility 211 means the service can be effective providing with access metadata 212 (e.g. domain name, URI) besides flow type rather than parsing the 213 content itself entirely. Through the metadata different access 214 features can be distinguished, thus appropriate actions could be 215 enforced based on these features. For example, illegal websites 216 can be filtered. The typical services of middle-level dependence 217 are IMS/SIP service, parental controls, etc. 219 C: High-level dependence 221 A service that is high-level dependent on the content visibility 222 means the service can be effective requiring analysis of content 223 itself, even interaction procedure. The typical services of high- 224 level dependence are web acceleration, video caching, which 225 usually requires user access behavior and detailed video content 226 (e.g. encoding format). In the case of encrypted traffic, this 227 kind of service will not be available. 229 3.1. IPsec/VPN Tunnel-based IP Layer Encryption Effect 231 In this case, the internal real port number is invisible to cellular 232 network and the tunnel-based IP traffic is usually mapped to the 233 Default Bearer with Default QoS or to a dedicated EPS bearer with 234 poor ARP and the same default QCI. If the VPN is from a big 235 customer, the special tunnel-based IP traffics are mapped to a 236 special dedicated EPS bearer with special QoS according the 237 predefined rules and SLA (Service-Level Agreement). This might 238 result in more dedicated EPS bearers with different QoS used to 239 transport the different tunneled-IP traffic with different QoS 240 requirements. 242 3.2. IMS/SIP Session Service Encryption Effect 244 The cellular network can beforehand obtain the IP 5-tuple information 245 of SDF of the voice, video and data parts and the content type of 246 each SDF during the Offer/Answer signalling interaction if the 247 signalling connection between the IMS/SIP UA (User Agent) and IMS/SIP 248 server is plaintext without encryption. Alternatively, the IMS/SIP 249 Server or the AF (Application Function) in the server can actively 250 tell the cellular network via the Rx interface to the PCRF (Policy 251 and Charging Rule Function) [3GPP 23.203] all the voice, video and 252 data SDF information even when the signalling connection is 253 encrypted. Even if the transmission of voice, video media above the 254 transport layer is encrypted, such as using SRTP (Secure Real-time 255 Transport Protocol), the cellular network can realize SDF detection 256 and further can guarantee the SDF with the correct ARP and QoS 257 control because the IP Flow information is known by the cellular 258 network beforehand. 260 If the cellular network cannot obtain prior SDF information on the 261 voice, video and data part of the session because the signalling 262 connection is encrypted and the server/AF does not provide the SDF 263 information, if the voice and video use different IP flows, the 264 cellular network still can identify the SDF type through using 265 intelligent heuristic algorithms which can identify the difference 266 content type by the transmission span of two successive packets, 267 packet size and other information. After the cellular network 268 identifies the SDF information of voice, video and other (data) 269 parts, the cellular network can realize the corresponding QoS control 270 and ARP and ensure the whole session's QoS. 272 3.3. HTTP Encryption Effect 274 Currently HTTP 1.1 is the most widely used service/application 275 protocol and it is expected to be widely replaced by HTTP 2 in the 276 near future. HTTP supports transport of various types of data in a 277 single TCP connection. Due to a single TCP connection corresponding 278 to a single SDF, and different types of data and services are 279 transmitted on the same TCP connection, the result is traditional 280 SDF-based mapping SDFs transmitting different types of content/data 281 to different EPS Bearers with different QoS and ARP no longer works 282 well or is applicable for the cellular network. Instead, cellular 283 network operators evolve and adopt new types of QoS-related 284 acceleration technologies to realize and improve the user's 285 experience. Therefore, Mobile CDN technology, Mobile Video 286 Optimization technology, Mobile Web Optimization, Anti-Virus, Anti- 287 Spoofing, Parent Control technology and all kinds of value-added 288 technologies emerge and are widely used. These technologies can 289 reduce the transport cost of cellular network and at the same time 290 can greatly improve mobile user video and web browsing experience. 292 When HTTP2 and HTTP1.1 use TLS to encrypt the TCP connection, the 293 widely used Web acceleration and value-added technologies no longer 294 work well. The usual result is the HTTPS connection is mapped to the 295 Default Bearer with Default QoS or dedicated EPS bearer with default 296 QCI and poor ARP. Therefore, there is no guarantee for the different 297 services provided by HTTPS websites. One exception is if there is a 298 SLA/cooperation agreement, then the cellular network can map the TCP 299 connection of the HTTPS website to a dedicated EPS bearer with 300 special QoS, then the QoS for the HTTS website may be improve 301 respectively with the special dedicated EPS Bearer and the specific 302 QoS. 304 4. Potential Co-operative Information between Application and Network 306 4.1. Application to Network 308 A SDF is mapped to a specific QoS EPS Bearer, and SDFs associated 309 with different IP services can be mapped to the same EPS Bearer with 310 the same QoS parameters (namely QCI (QoS Class Identifier) and ARP 311 (Allocation and retention priority)) [PCC]. 313 So application could provide the service level (i.e. per SDF) QoS 314 parameters such as QCI and APR to indicate how certain service/ 315 application traffic shall be treated in the operator's network. For 316 example, given that the categories in table 1 map to GBR and non-GBR 317 resources, with a priority level, it seems cleaner to reveal just the 318 resource type and priority. This also seems possible to encode in a 319 space similar to the QCI. 321 Table 1: Standardized QCI characteristics 322 +------+----------------+-----------------+ 323 | QCI | Resource Type | Priority Level | 324 +------+----------------+-----------------+ 325 | 1 | | 2 | 326 +------+ +-----------------+ 327 | 2 | | 4 | 328 +------+ +-----------------+ 329 | 3 | | 3 | 330 +------+ GBR +-----------------+ 331 | 4 | | 5 | 332 +------+ +-----------------+ 333 | 65 | | 0.7 | 334 +------+ +-----------------+ 335 | 66 | | 2 | 336 +------+----------------+-----------------+ 337 | 5 | | 1 | 338 +------+ +-----------------+ 339 | 6 | | 6 | 340 +------+ +-----------------+ 341 | 7 | | 7 | 342 +------+ +-----------------+ 343 | 8 | Non-GBR | 8 | 344 +------+ +-----------------+ 345 | 9 | | 9 | 346 +------+ +-----------------+ 347 | 69 | | 0.5 | 348 +------+ +-----------------+ 349 | 70 | | 5.5 | 350 +------+----------------+-----------------+ 352 4.2. Network to Application 354 The network could provide the application with the real time 355 information about the throughput estimated to be available at the 356 radio downlink interface between a UE and the base station the UE 357 connects to, which is discussed in 358 [I-D.flinck-mobile-throughput-guidance]. 360 5. Potential Bandwidth Optimization Methods 362 5.1. Intelligent Heuristic Method 364 By collection and convergence of the information of packet interval, 365 packet size, port number, protocol type etc, the intelligent 366 heuristic algorithm can guess correctly some the types of the content 367 of the packet transmission as mentioned in previous chapter of IMS/ 368 SIP session type communication. 370 This method can be implemented in the mostly widely deployed Apache 371 and or nginx HTTP Server package without destroying any current 372 protocols. This method requires the OTT to deploy the modified 373 Apache/nginx HTTP Server and an intelligent heuristic algorithm 374 running in the cellular network to identify the dynamically changed 375 content type of the encrypted HTTPS connection. 377 5.2. Legacy Protocol Extension 379 Regarding to the low-level dependence services, existing protocols 380 could be extended in order to carry flow type, for example, enhancing 381 TLS header. 383 A new TCP option to identify the encrypted content type has certain 384 feasibility, but it may have problems when passing through some 385 existing middleboxes. 387 For DSCP method, it requires OTTs to set the right DSCP field of 388 outer IP packet corresponding to different content types in the 389 encrypted TLS connection. But the DSCP value may be modified by the 390 routers from the OTT to the cellular network. 392 5.3. New Substrate Protocol 394 New substrate protocols over existing transport layers, such as UDP, 395 TCP, are considered to carry flow information in order to make 396 middle-level dependence service effective. 398 Developing UDP-based substrate protocols to enable transport 399 evolution is a hot topic in IETF recently. The QUIC protocol from 400 Google falls into this space; however, QUIC is not aiming to solve 401 the encrypted traffic management. One major issue with UDP-based 402 substrate is middleboxes may block UDP or limit rate. SPUD-like 403 [I-D.hildebrand-spud-prototype] UDP-based substrate could be a 404 potential method to allow traffic management while using transport 405 protocols. How middleboxes trust the information exposed by the 406 endpoints should be considered. 408 However today's Internet is full of middleboxes that may interfere 409 with the information sent in IP packets and TCP segments. "Is it 410 still possible to extend TCP?" [ExtendTCP] shows the limitation 411 imposed on TCP extensions by middleboxes behaviors, such as TCP 412 options removed or updated, the source and destination port numbers 413 translated by NATs. Though we can still extend TCP to support 414 middle-level dependence services, extensions are very constrained as 415 it needs to take into account middleboxes behaviors. 417 6. Conclusion 419 In this draft the importance of QoS in the cellular network service 420 is discussed and the basic QoS management concept in the EPS system 421 is described. Regarding to the low/middle-level dependence services, 422 the challenges for potential traffic management methods for encrypted 423 traffic are analyzed. Furthermore, possible IETF standardization 424 work (i.e. legacy protocol extensions and new substrates) is explored 425 in order to solve the conflict between user privacy and traffic 426 management. 428 7. Acknowledgement 430 The editors would like to thank Ted Hardie and Dan Druta for their 431 useful comments. 433 8. References 435 8.1. Normative References 437 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 438 Requirement Levels", BCP 14, RFC 2119, 439 DOI 10.17487/RFC2119, March 1997, 440 . 442 [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an 443 Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May 444 2014, . 446 [RFC7624] Barnes, R., Schneier, B., Jennings, C., Hardie, T., 447 Trammell, B., Huitema, C., and D. Borkmann, 448 "Confidentiality in the Face of Pervasive Surveillance: A 449 Threat Model and Problem Statement", RFC 7624, 450 DOI 10.17487/RFC7624, August 2015, 451 . 453 8.2. Informative References 455 [ExtendTCP] 456 Honda, M., Nishida, Y., Raiciu, C., Greenhalgh, A., 457 Handley, M., and H. Tokuda, "Is it Still Possible to 458 Extend TCP", IMC'11 Page(s): 2-4, November 2011. 460 [I-D.flinck-mobile-throughput-guidance] 461 Jain, A., Terzis, A., Flinck, H., Sprecher, N., 462 Swaminathan, S., and K. Smith, "Mobile Throughput Guidance 463 Inband Signaling Protocol", draft-flinck-mobile- 464 throughput-guidance-03 (work in progress), September 2015. 466 [I-D.hildebrand-spud-prototype] 467 Hildebrand, J. and B. Trammell, "Substrate Protocol for 468 User Datagrams (SPUD) Prototype", draft-hildebrand-spud- 469 prototype-03 (work in progress), March 2015. 471 [I-D.mm-wg-effect-encrypt] 472 Moriarty, K. and A. Morton, "Effect of Ubiquitous 473 Encryption", draft-mm-wg-effect-encrypt-02 (work in 474 progress), July 2015. 476 [PCC] "3GPP TS 23.203, "Policy and charging control 477 architecture"", 2015. 479 [XMPP] ""XMPP switches on mandatory encryption" 480 (http://lwn.net/Articles/599647/)", May 2014. 482 Authors' Addresses 484 Jianjie You 485 Huawei 486 101 Software Avenue, Yuhuatai District 487 Nanjing, 210012 488 China 490 Email: youjianjie@huawei.com 492 Chunshan Xiong 493 Huawei 494 No.3, Xin-Xi Rd., Haidian District 495 Beijing, 100085 496 China 498 Email: sam.xiongchunshan@huawei.com