idnits 2.17.1 draft-smith-encrypted-traffic-management-02.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 214: '...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 (June 10, 2015) is 3236 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 June 10, 2015 5 Expires: December 12, 2015 7 Network management of encrypted traffic 8 draft-smith-encrypted-traffic-management-02 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 December 12, 2015. 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 . . . . . . . . . . . . . . . . . . . . . . . 5 61 3.2. TLS Server Name Indication . . . . . . . . . . . . . . . 5 62 3.3. Application Layer Protocol Negotiation (ALPN) . . . . . . 6 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) . . . . . . . . . . . . . . . 7 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 . . . . . . . . . . . . . . . . . . . . . . . . . 9 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 . . . . . . . . . . . . . . . . . 10 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. Such 'zero 169 rating 171 Note: this section deliberately does not go into detail on the 172 ramifications of encryption as regards government regulation. These 173 regulations include 'Lawful Intercept', adherence to Codes of 174 Practice on content filtering, application of court order filters. 175 However it is clear that these functions are impacted by encryption, 176 typically by allowing a less granular means of implementation. The 177 enforcement of any Net Neutrality regulations is unlikely to be 178 affected by content being encrypted. 180 2.5. SPAM and malware filtering 182 This has typically required Deep Packet Inspection to filter various 183 keywords, fraudulent headers and virus attachments. 185 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 Obscured from network by: IPSec Tunnel Mode 199 3.2. TLS Server Name Indication 201 When initiating the TLS handshake, the Client may provide an 202 extension field (server_name) which indicates the server to which it 203 is attempting a secure connection. TLS SNI was standardized in 2003 204 to enable servers to present the "correct TLS certificate" to clients 205 in a deployment of multiple virtual servers hosted by the same server 206 infrastructure and IP-address. Although this is an optional 207 extension, it is today supported by all modern browsers, web servers 208 and developer libraries. Notable exceptions are Android 2.2 and 209 Internet Explorer 6 on Windows XP. It should be noted that HTTP/2 210 introduces the Alt-SVC method for upgrading the connection from 211 HTTP/1 to either unencrypted or encrypted HTTP/2. If the initial 212 HTTP/1 request is unencrypted, the destination alternate service name 213 can be identified before the communication is potentially upgraded to 214 encrypted HTTP/2 transport. HTTP/2 implementations MUST support the 215 Server Name Indication (SNI) extension. 217 Limitation: This information is only visible if the client is 218 populating the Server Name Indication extension. This need not be 219 done, but may be done as per TLS standard. Therefore, even if 220 existing network filters look out for seeing a Server Name Indication 221 extension, they may not find one. The per-domain nature of SNI may 222 not reveal the specific service or media type being accessed, 223 especially where the domain is of a provider offering a range of 224 email, video, Web pages etc. For example, certain blog or social 225 network feeds may be deemed 'adult content', but the Server Name 226 Indication will only indicate the server domain rather than a URL 227 path to be blocked. 229 Obscured from network by: not providing the SNI, IPSec 231 3.3. Application Layer Protocol Negotiation (ALPN) 233 ALPN is a TLS extension which may be used to indicate the application 234 protocol within the TLS session. This is likely to be of more value 235 to the network where it indicates a protocol dedicated to a 236 particular traffic type (such as video streaming) rather than a 237 multi-use protocol. ALPN is used as part of HTTP/2 'h2', but will 238 not indicate the traffic types which may make up streams within an 239 HTTP/2 multiplex. 241 4. Inferred flow information 243 4.1. Heuristics 245 Heuristics can be used to map given input data to particular 246 conclusions via some heuristic reasoning. Examples of input data to 247 this reasoning include IP destination address, TCP destination port, 248 server name from SNI, typical traffic pattern (e.g. occurrence of IP 249 packets and TCP segments over time). The accuracy of heuristics 250 depends on whether the observed traffic originates from a source 251 delivering a single service, or a blend of services. In many 252 scenarios, this makes it possible to directly classify the traffic 253 related to a specific server/service even when the traffic is fully 254 encrypted. 256 If the server/service is co-located on an infrastructure with other 257 services that shares the same IP-address, the encrypted traffic 258 cannot be directly classified. However, commercial traffic 259 classifiers today typically apply heuristic methods, using traffic 260 pattern matching algorithms to be able to identify the traffic. As 261 an example, classifier products are able to identify popular VoIP 262 services using heuristic methods although the traffic is encrypted 263 and mostly peer-to-peer. 265 5. Providing hints to and from the network 267 The following protocols aim to support a secure and privacy-aware 268 dialogue between client, server and a network middlebox. These hints 269 can allow information item exchange between the endpoints and the 270 network, to assist queuing mechanisms and traffic pacing that 271 accounts for network congestion and variable connection strength. 272 These relate to the cooperative path to endpoint signalling as 273 discussed at the IAB SEMI workshop [SEMI], with the network following 274 a more clearly-defined role in encrypted traffic delivery. 276 5.1. DiffServ Code Points (DSCP) 278 Data packets are flagged with a traffic class (class of service). 279 Network operators may honour a DiffServ classification entering their 280 network, or may choose to override it (since it is potentially open 281 to abuse by a service provider that classifies all its content as 282 high priority). The purpose is to help manage traffic and congestion 283 in the network. 285 Limitations: This requires the content provider to flag data packets. 286 This is extra work for the provider, and it has potential for abuse 287 if a content provider simply flags all packets with high priorities. 288 The network would need to know which flags to trust and which to 289 override. The use of DiffServ within the operator network is 290 beneficial where the operator determines the class of service itself; 291 but where content is encrypted then heuristics would be needed to 292 predict the traffic type entering the network. HTTP/2 allows several 293 streams to be multiplexed over a single TCP connection. This means 294 that if a provider decides to send Web pages, videos, chat etc. as 295 individual streams over the same connection, then DiffServ would be 296 useless as it would apply to the TCP/IP connection as a whole. 297 However it may be more efficient for such Web providers to serve each 298 content type from separate, dedicated servers - this will become 299 clearer as HTTP/2 deployments are tuned for optimal delivery. 301 5.2. Explicit Congestion Notification 303 Explicit Congestion Notification (ECN) routers can exchange 304 congestion notification headers to ECN compliant endpoints. This is 305 in preference to inferring congestion from dropped packets (e.g. in 306 TCP). The purpose is to help manage traffic and congestion in the 307 network. 309 This solution is required to be implemented at network and service 310 provider. The service provider will utilise the ECN to reduce 311 throughput until it is notified that congestion has eased. 313 Limitation: As with DiffServ, operators may not trust an external 314 entity to mark packets in a fair/consistent manner. 316 5.3. Multi Protocol Label Switching 318 Description: on entering an MPLS-compliant network, IP packets are 319 flagged with a 'Forward Equivalence Class' (FEC). This allows the 320 network to make packet-forwarding decisions according to their 321 latency requirements. MPLS routers within the network parse and act 322 upon the FEC value. The FEC is set according to the source IP 323 address and port. The purpose is to help managing traffic and 324 congestion in the network. This requires deployment of an MPLS 325 'backbone' with label-aware switches/ routers. 327 Limitations: an up-to-date correspondence table between Websites and 328 server IP address must be created. Then, the category(s) of traffic 329 have to be consistently mapped to a set of MPLS labels ,which entails 330 a significant effort to setup and maintain. 332 Note: MPLS can specify how OSI Layer 3 (IP layer) traffic can be 333 routed over Layer 2 (Data Link); DiffServ only operates over Layer 3. 334 DiffServ is potentially a less complex integration as it is applied 335 at the network edge servers only. 337 5.4. Substrate Protocol for User Datagrams (SPUD) 339 SPUD [SPUD] allows network devices on the path between endpoints to 340 participate explicitly in a 'tube' of grouped UDP packets. The 341 network involvement is outside of the end-to-end context, to minimise 342 any privacy or security breach. The initial prototype is based on 343 UDP packets but will investigate the support of additional transport 344 layers (such as TCP). 346 5.5. Mobile throughput Guidance 348 Mobile Throughput Guidance In-band Signalling [MTG] allows the 349 network to inform the server endpoint as to what bandwidth the TCP 350 connection can reasonably expect. This allows the server to adapt 351 their throughput pacing based on dynamic network conditions, which 352 can assist mechanisms such as Adaptive Bitrate Streaming and TCP 353 congestion control. 355 5.6. Port Control Protocol Flowdata options 357 PCP Flowdata options [PCPFD] defines a mechanism for a host to signal 358 flow characteristics to the network, and the network to signal its 359 ability to accommodate that flow back to the host. This allows 360 certain network flows can to receive service that is differentiated 361 from other network flows, and may be used to establish flow priority 362 before connection establishment. PCP Flowdata operates at IPv4 /IPv6 363 level. 365 5.7. IPv6 Flow label 367 IPv6 includes a flow label header field. [RFC6438] details how this 368 may be used to identify flows for load balancing and multipath 369 routing, which may be of particular use for application-layer 370 encrypted traffic. The flow label field is part of the main header, 371 which means it is not subject to the disadvantages of extension 372 headers (namely their risk of being dropped by intermediary routers). 373 The flow label may also be exposed as part of the outer IP packet in 374 an IP tunnel, thus providing network flow information without 375 compromising the payload. 377 5.8. DISCUSS 379 Differentiated prIorities and Status Code-points Using Stun 380 Signalling [DISCUSS] describes a mechanism for information exchange 381 between an application and the network, viable only for UDP. As such 382 it can be considered in the same bracket as SPUD 384 6. Acknowledgements 386 The editor would like to thank the GSMA Web Working Group for their 387 contributions, in particular to the technical solutions and network 388 management functions, as well as contributions via the SAAG mailing 389 list (Panos Kampanakis, Brian Carpenter) 391 7. IANA Considerations 393 There are no IANA consideraions. 395 8. Security Considerations 397 The intention of this document is to consider how to persist network 398 management of encrypted traffic, without breaching user privacy or 399 end-to-end security. In particular this document does not recommend 400 any approach that intercepts or modifies client-server Transport 401 Layer Security. 403 9. References 405 9.1. Normative References 407 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 409 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 410 Internet Protocol", RFC 4301, December 2005. 412 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 413 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 415 [RFC6438] Carpenter, B. and S. Amante, "Using the IPv6 Flow Label 416 for Equal Cost Multipath Routing and Link Aggregation in 417 Tunnels", RFC 6438, 2011. 419 [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an 420 Attack", BCP 188, RFC 7258, May 2014. 422 9.2. Informative References 424 [DISCUSS] Cisco, "Differentiated prIorities and Status Code-points 425 Using Stun Signalling", 2015, 426 . 429 [IAB] IAB, "IAB statement on Internet confidentiality", n.d., 430 . 433 [MTG] IETF, "Mobile Throughput Guidance Inband Signaling 434 Protocol", n.d., . 437 [PCPFD] Cisco, "PCP Flowdata option", 2013, 438 . 440 [SEMI] IAB, "IAB workshop, 'Stack Evolution in a Middlebox 441 Internet'", n.d., 442 . 444 [SPUD] IETF, "Substrate Protocol for User Datagrams", n.d., 445 . 448 [TAG] W3C, "Securing the Web", n.d., . 451 [TCPINC] IETF, "TCP Increased Security", n.d., 452 . 454 [mm-effect-encrypt] 455 IETF, "Effect of Ubiquitous Encryption", n.d., 456 . 459 Author's Address 461 Kevin Smith 462 Vodafone Group 464 Email: kevin.smith@vodafone.com