idnits 2.17.1 draft-smith-encrypted-traffic-management-03.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 both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 212: '...TTP/2 implementations MUST support the...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (September 2, 2015) is 3159 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 2818 (Obsoleted by RFC 9110) ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) Summary: 3 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group K. Smith 3 Internet-Draft Vodafone Group 4 Intended status: Informational September 2, 2015 5 Expires: March 5, 2016 7 Network management of encrypted traffic 8 draft-smith-encrypted-traffic-management-03 10 Abstract 12 Encrypted Internet traffic may pose traffic management challenges to 13 network operators. This document recommends approaches to help 14 manage encrypted traffic, without breaching user privacy or security. 16 Status of This Memo 18 This Internet-Draft is submitted in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF). Note that other groups may also distribute 23 working documents as Internet-Drafts. The list of current Internet- 24 Drafts is at http://datatracker.ietf.org/drafts/current/. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 This Internet-Draft will expire on March 5, 2016. 33 Copyright Notice 35 Copyright (c) 2015 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents 40 (http://trustee.ietf.org/license-info) in effect on the date of 41 publication of this document. Please review these documents 42 carefully, as they describe your rights and restrictions with respect 43 to this document. Code Components extracted from this document must 44 include Simplified BSD License text as described in Section 4.e of 45 the Trust Legal Provisions and are provided without warranty as 46 described in the Simplified BSD License. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 51 1.1. Document structure . . . . . . . . . . . . . . . . . . . 3 52 1.2. Security protocols . . . . . . . . . . . . . . . . . . . 3 53 2. Network management functions . . . . . . . . . . . . . . . . 3 54 2.1. Queuing . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2.2. Server load balancing . . . . . . . . . . . . . . . . . . 4 56 2.3. Intrusion detection . . . . . . . . . . . . . . . . . . . 4 57 2.4. Policy enforcement . . . . . . . . . . . . . . . . . . . 4 58 2.5. SPAM and malware filtering . . . . . . . . . . . . . . . 4 59 3. Flow information visible to a network . . . . . . . . . . . . 4 60 3.1. IP 5-tuple . . . . . . . . . . . . . . . . . . . . . . . 4 61 3.2. TLS Server Name Indication . . . . . . . . . . . . . . . 5 62 3.3. Application Layer Protocol Negotiation (ALPN) . . . . . . 5 63 4. Inferred flow information . . . . . . . . . . . . . . . . . . 6 64 4.1. Heuristics . . . . . . . . . . . . . . . . . . . . . . . 6 65 5. Providing hints to and from the network . . . . . . . . . . . 6 66 5.1. DiffServ Code Points (DSCP) . . . . . . . . . . . . . . . 6 67 5.2. Explicit Congestion Notification . . . . . . . . . . . . 7 68 5.3. Multi Protocol Label Switching . . . . . . . . . . . . . 7 69 5.4. Substrate Protocol for User Datagrams (SPUD) . . . . . . 8 70 5.5. Mobile throughput Guidance . . . . . . . . . . . . . . . 8 71 5.6. Port Control Protocol Flowdata options . . . . . . . . . 8 72 5.7. IPv6 Flow label . . . . . . . . . . . . . . . . . . . . . 8 73 5.8. DISCUSS . . . . . . . . . . . . . . . . . . . . . . . . . 8 74 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 75 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 76 8. Security Considerations . . . . . . . . . . . . . . . . . . . 9 77 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 78 9.1. Normative References . . . . . . . . . . . . . . . . . . 9 79 9.2. Informative References . . . . . . . . . . . . . . . . . 9 80 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 10 82 1. Introduction 84 Networks utilise various management techniques to ensure efficient 85 throughput, congestion management, anti-SPAM and security measures. 86 Historically these functions have utilised visibility of the Internet 87 application layer. 89 This visibility is rapidly diminishing - encrypted Internet traffic 90 is expected to continue its upward trend, driven by increased privacy 91 awareness, uptake by popular services, and advocacy from the [IAB], 92 [RFC7258] and W3C [TAG] . 94 [IAB], [RFC7258] and [mm-effect-encrypt] recognise that network 95 management functions are impacted by encryption, and that solutions 96 are needed to persist them - as long as they do not threaten privacy. 97 These solutions would ensure the benefits of encryption do not 98 degrade network efficiency. 100 This document lists such solutions, and points to evolving IETF work 101 addressing the problem. 103 1.1. Document structure 105 This document describes the network management functions that are 106 likely to be hindered by traffic encryption. 108 It then describes the technical details of existing options to fully 109 or partially persist these functions under encryption. 'Encryption' 110 in this document typically refers to HTTP over TLS [RFC2818]; other 111 forms of encryption are noted where applicable. 113 Finally, a summary is provided of ongoing IETF work which is 114 investigating how middleboxes along the network path can improve 115 encrypted traffic delivery - again without breaching user privacy or 116 security. 118 The legal, political and commercial aspects of network management are 119 recgnised but not covered in this technical document. 121 1.2. Security protocols 123 The following IETF protocols are considered in this document: TLS 124 [RFC5246] , IPsec [RFC4301] and the ongoing transport layer security 125 work of [TCPINC]. 127 2. Network management functions 129 Editor's note: Part or all of this section may be removed where there 130 is duplication with any updated version of [mm-effect-encrypt] 132 2.1. Queuing 134 Traffic flowing through a network may be queued for delivery. This 135 is important at an access network where network conditions can change 136 rapidly - such as a cellular radio access network. To account for 137 congestion, the network will categorise content requests according to 138 the latency and bandwidth required to deliver that content type. 139 These combinations run from high-latency, low bandwidth (Email), 140 medium latency, medium bandwidth (Web pages), low latency high 141 bandwidth (video streaming), and many others including voice calls, 142 texts, WebRTC and VoIP. A well-managed network will triage between 143 these content types and deliver from each queue in bursts, to ensure 144 no user experiences a disrupted service. 146 2.2. Server load balancing 148 Where network load balancers have been configured to route according 149 to application-layer semantics, an encrypted payload is effectively 150 invisible.This has resulted in practices of intercepting TLS in front 151 of load balancers to regain that visibility, but at a cost to 152 security and privacy. 154 2.3. Intrusion detection 156 Networks will monitor traffic stream behaviours to identify likely 157 Denial of Service attacks. Tools exist at each network layer to 158 detect and mitigate these, including application layer detection. 160 2.4. Policy enforcement 162 Approved access to a network is a prerequisite to requests for 163 Internet traffic - hence network access, including any authentication 164 and authorisation, is not impacted by traffic encryption. 166 Cellular networks often sell tariffs that allow free-data access to 167 certain sites, known as 'zero rating'. A session to visit such a 168 site incurs no additional cost or data usage to the user. 170 Note: this section deliberately does not go into detail on the 171 ramifications of encryption as regards government regulation. These 172 regulations include Lawful Intercept, adherence to Codes of Practice 173 on content filtering, application of court order filters. However it 174 is clear that these functions are impacted by encryption, typically 175 by allowing a less granular means of implementation. The enforcement 176 of any Net Neutrality regulations is unlikely to be affected by 177 content being encrypted. 179 2.5. SPAM and malware filtering 181 This has typically required full access to application data to filter 182 various keywords, fraudulent headers and virus attachments. 184 3. Flow information visible to a network 186 3.1. IP 5-tuple 188 This indicates source and destination IP addresses/ports and the 189 transport protocol. This information is available during TLS, TCP- 190 layer encryption (except ports), and IP-layer encryption (IPSec); 191 although it may be obscured in Tunnel mode IPSec. 193 This allows network management at a coarse IP-source level, which 194 makes it of limited value where the origin server supports a blend of 195 service types. 197 3.2. TLS Server Name Indication 199 When initiating the TLS handshake, the Client may provide an 200 extension field (server_name) which indicates the server to which it 201 is attempting a secure connection. TLS SNI was standardized in 2003 202 to enable servers to present the "correct TLS certificate" to clients 203 in a deployment of multiple virtual servers hosted by the same server 204 infrastructure and IP-address. Although this is an optional 205 extension, it is today supported by all modern browsers, web servers 206 and developer libraries. Notable exceptions are Android 2.2 and 207 Internet Explorer 6 on Windows XP. It should be noted that HTTP/2 208 introduces the Alt-SVC method for upgrading the connection from 209 HTTP/1 to either unencrypted or encrypted HTTP/2. If the initial 210 HTTP/1 request is unencrypted, the destination alternate service name 211 can be identified before the communication is potentially upgraded to 212 encrypted HTTP/2 transport. HTTP/2 implementations MUST support the 213 Server Name Indication (SNI) extension. 215 This information is only visible if the client is populating the 216 Server Name Indication extension. This need not be done, but may be 217 done as per TLS standard. Therefore, even if existing network 218 filters look out for seeing a Server Name Indication extension, they 219 may not find one. The per-domain nature of SNI may not reveal the 220 specific service or media type being accessed, especially where the 221 domain is of a provider offering a range of email, video, Web pages 222 etc. For example, certain blog or social network feeds may be deemed 223 'adult content', but the Server Name Indication will only indicate 224 the server domain rather than a URL path to be blocked. 226 3.3. Application Layer Protocol Negotiation (ALPN) 228 ALPN is a TLS extension which may be used to indicate the application 229 protocol within the TLS session. This is likely to be of more value 230 to the network where it indicates a protocol dedicated to a 231 particular traffic type (such as video streaming) rather than a 232 multi-use protocol. ALPN is used as part of HTTP/2 'h2', but will 233 not indicate the traffic types which may make up streams within an 234 HTTP/2 multiplex. 236 4. Inferred flow information 238 4.1. Heuristics 240 Heuristics can be used to map given input data to particular 241 conclusions via some heuristic reasoning. Examples of input data to 242 this reasoning include IP destination address, TCP destination port, 243 server name from SNI, and typical traffic patterns (e.g. occurrence 244 of IP packets and TCP segments over time). The accuracy of 245 heuristics depends on whether the observed traffic originates from a 246 source delivering a single service, or a blend of services. In many 247 scenarios, this makes it possible to directly classify the traffic 248 related to a specific server/service even when the traffic is fully 249 encrypted. 251 If the server/service is co-located on an infrastructure with other 252 services that shares the same IP-address, the encrypted traffic 253 cannot be directly classified. However, commercial traffic 254 classifiers today typically apply heuristic methods, using traffic 255 pattern matching algorithms to be able to identify the traffic. As 256 an example, classifier products are able to identify popular VoIP 257 services using heuristic methods although the traffic is encrypted 258 and mostly peer-to-peer. 260 5. Providing hints to and from the network 262 The following protocols aim to support a secure and privacy-aware 263 dialogue between client, server and the network elements. These 264 hints can allow information item exchange between the endpoints and 265 the network, to assist queuing mechanisms and traffic pacing that 266 accounts for network congestion and variable connection strength. 267 These relate to the cooperative path to endpoint signalling as 268 discussed at the IAB SEMI workshop [SEMI], with the network following 269 a more clearly-defined role in encrypted traffic delivery. 271 5.1. DiffServ Code Points (DSCP) 273 Data packets are flagged with a traffic class (class of service). 274 Network operators may honour a DiffServ classification entering their 275 network, or may choose to override it (since it is potentially open 276 to abuse by a service provider that classifies all its content as 277 high priority). The purpose is to help manage traffic and congestion 278 in the network. 280 This requires the content provider to flag data packets. This is 281 extra work for the provider, and it has potential for abuse if a 282 content provider simply flags all packets with high priorities. The 283 network would need to know which flags to trust and which to 284 override. The use of DiffServ within the operator network is 285 beneficial where the operator determines the class of service itself; 286 but where content is encrypted then heuristics would be needed to 287 predict the traffic type entering the network. HTTP/2 allows several 288 streams to be multiplexed over a single TCP connection. This means 289 that if a provider decides to send Web pages, videos, chat etc. as 290 individual streams over the same connection, then DiffServ would be 291 useless as it would apply to the TCP/IP connection as a whole. 292 However it may be more efficient for such Web providers to serve each 293 content type from separate, dedicated servers - this will become 294 clearer as HTTP/2 deployments are tuned for optimal delivery. 296 5.2. Explicit Congestion Notification 298 Explicit Congestion Notification (ECN) routers can exchange 299 congestion notification headers to ECN compliant endpoints. This is 300 in preference to inferring congestion from dropped packets (e.g. in 301 TCP). The purpose is to help manage traffic and congestion in the 302 network. 304 This solution is required to be implemented at network and service 305 provider. The service provider will utilise the ECN to reduce 306 throughput until it is notified that congestion has eased. 308 As with DiffServ, operators may not trust an external entity to mark 309 packets in a fair/consistent manner. 311 5.3. Multi Protocol Label Switching 313 On entering an MPLS-compliant network, IP packets are flagged with a 314 'Forward Equivalence Class' (FEC). This allows the network to make 315 packet-forwarding decisions according to their latency requirements. 316 MPLS routers within the network parse and act upon the FEC value. 317 The FEC is set according to the source IP address and port. The 318 purpose is to help managing traffic and congestion in the network. 319 This requires deployment of an MPLS 'backbone' with label-aware 320 switches/ routers. 322 An up-to-date correspondence table between Websites (or service sites 323 in general) and server IP address must be created. Then, the 324 category(s) of traffic have to be consistently mapped to a set of 325 MPLS labels ,which entails a significant effort to setup and 326 maintain. 328 Note: MPLS can specify how OSI Layer 3 (IP layer) traffic can be 329 routed over Layer 2 (Data Link); DiffServ only operates over Layer 3. 330 DiffServ is potentially a less complex integration as it is applied 331 at the network edge servers only. 333 5.4. Substrate Protocol for User Datagrams (SPUD) 335 SPUD [SPUD] is a prototype to research how network devices on the 336 path between endpoints can share information to improve a flow. The 337 network involvement is outside of the end-to-end context, to minimise 338 any privacy or security breach. The initial prototype involves 339 grouping UDP packets into an explicit 'tube', however support of 340 additional transport layers (such as TCP) will also be investigated. 342 5.5. Mobile throughput Guidance 344 Mobile Throughput Guidance In-band Signalling [MTG] is a draft 345 proposal to allows the network to inform the server endpoint as to 346 what bandwidth the TCP connection can reasonably expect. This allows 347 the server to adapt their throughput pacing based on dynamic network 348 conditions, which can assist mechanisms such as Adaptive Bitrate 349 Streaming and TCP congestion control. 351 5.6. Port Control Protocol Flowdata options 353 PCP Flowdata options [PCPFD] defines a mechanism for a host to signal 354 flow characteristics to the network, and the network to signal its 355 ability to accommodate that flow back to the host. This allows 356 certain network flows to receive service that is differentiated from 357 other network flows, and may be used to establish flow priority 358 before connection establishment. PCP Flowdata operates at IPv4/IPv6 359 level. 361 5.7. IPv6 Flow label 363 IPv6 includes a flow label header field. [RFC6438] details how this 364 may be used to identify flows for load balancing and multipath 365 routing, which may be of particular use for application-layer 366 encrypted traffic. The flow label field is part of the main header, 367 which means it is not subject to the disadvantages of extension 368 headers (namely their risk of being dropped by intermediary routers). 369 The flow label may also be exposed as part of the outer IP packet in 370 an IP tunnel, thus providing network flow information without 371 compromising the payload. 373 5.8. DISCUSS 375 Differentiated prIorities and Status Code-points Using Stun 376 Signalling [DISCUSS] describes a mechanism for information exchange 377 between an application and the network, viable only for UDP. As such 378 it can be considered in the same bracket as SPUD 380 6. Acknowledgements 382 The editor would like to thank the GSMA Web Working Group for their 383 contributions, in particular to the technical solutions and network 384 management functions, as well as contributions via the SAAG mailing 385 list (Panos Kampanakis, Brian Carpenter) 387 7. IANA Considerations 389 There are no IANA consideraions. 391 8. Security Considerations 393 The intention of this document is to consider how to persist network 394 management of encrypted traffic, without breaching user privacy or 395 end-to-end security. In particular this document does not recommend 396 any approach that intercepts or modifies client-server Transport 397 Layer Security. 399 9. References 401 9.1. Normative References 403 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 405 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 406 Internet Protocol", RFC 4301, December 2005. 408 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 409 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 411 [RFC6438] Carpenter, B. and S. Amante, "Using the IPv6 Flow Label 412 for Equal Cost Multipath Routing and Link Aggregation in 413 Tunnels", RFC 6438, 2011. 415 [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an 416 Attack", BCP 188, RFC 7258, May 2014. 418 9.2. Informative References 420 [DISCUSS] Cisco, "Differentiated prIorities and Status Code-points 421 Using Stun Signalling", 2015, 422 . 425 [IAB] IAB, "IAB statement on Internet confidentiality", n.d., 426 . 429 [mm-effect-encrypt] 430 IETF, "Effect of Ubiquitous Encryption", n.d., 431 . 434 [MTG] IETF, "Mobile Throughput Guidance Inband Signaling 435 Protocol", n.d., . 438 [PCPFD] Cisco, "PCP Flowdata option", 2013, 439 . 441 [SEMI] IAB, "IAB workshop, 'Stack Evolution in a Middlebox 442 Internet'", n.d., 443 . 445 [SPUD] IETF, "Substrate Protocol for User Datagrams", n.d., 446 . 449 [TAG] W3C, "Securing the Web", n.d., . 452 [TCPINC] IETF, "TCP Increased Security", n.d., 453 . 455 Author's Address 457 Kevin Smith 458 Vodafone Group 460 Email: kevin.smith@vodafone.com