idnits 2.17.1 draft-smith-encrypted-traffic-management-05.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 date (May 12, 2016) is 2905 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 2818 (Obsoleted by RFC 9110) Summary: 1 error (**), 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 May 12, 2016 5 Expires: November 13, 2016 7 Network management of encrypted traffic 8 draft-smith-encrypted-traffic-management-05 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 November 13, 2016. 33 Copyright Notice 35 Copyright (c) 2016 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 2. Network management functions . . . . . . . . . . . . . . . . 3 53 3. Persisting traffic management without breaching encryption . 3 54 3.1. Providing hints to and from the network . . . . . . . . . 3 55 3.1.1. DiffServ Code Points (DSCP) . . . . . . . . . . . . . 3 56 3.1.2. Explicit Congestion Notification (ECN) . . . . . . . 4 57 3.1.3. Multiprotocol Label Switching (MPLS) . . . . . . . . 4 58 3.1.4. Substrate Protocol for User Datagrams (SPUD) . . . . 5 59 3.1.5. Mobile throughput Guidance . . . . . . . . . . . . . 5 60 3.1.6. Port Control Protocol Flowdata options . . . . . . . 5 61 3.1.7. IPv6 Flow label . . . . . . . . . . . . . . . . . . . 5 62 3.1.8. DISCUSS . . . . . . . . . . . . . . . . . . . . . . . 6 63 3.1.9. Active Queue Management . . . . . . . . . . . . . . . 6 64 3.1.10. Congestion Exposure . . . . . . . . . . . . . . . . . 6 65 3.2. Inferred flow information . . . . . . . . . . . . . . . . 6 66 3.2.1. Heuristics . . . . . . . . . . . . . . . . . . . . . 6 67 3.3. Co-operation on congestion control . . . . . . . . . . . 7 68 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 69 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 70 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 71 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 72 7.1. Normative References . . . . . . . . . . . . . . . . . . 7 73 7.2. Informative References . . . . . . . . . . . . . . . . . 8 74 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9 76 1. Introduction 78 Networks utilise various management techniques to ensure efficient 79 throughput, congestion management, anti-SPAM and security measures. 80 Historically these functions have utilised visibility of the Internet 81 application layer. 83 This visibility is rapidly diminishing - encrypted Internet traffic 84 is expected to continue its upward trend, driven by increased privacy 85 awareness, uptake by popular services, and advocacy from the [IAB], 86 [RFC7258] and W3C [TAG] . 88 [IAB], [RFC7258] and [mm-effect-encrypt] recognise that network 89 management functions may be impacted by encryption, and that 90 solutions to persist these management functions must not threaten 91 user security or privacy. Such solutions can ensure the benefits of 92 encryption do not degrade network efficiency. 94 This document lists such solutions, and points to evolving IETF work 95 addressing the problem. 97 1.1. Document structure 99 This document refers to network management functions that may be 100 hindered by traffic encryption, as described in [mm-effect-encrypt] 102 It then describes the technical details of existing options to fully 103 or partially persist these functions under encryption. The guidance 104 includes existing techniques as well as ongoing IETF work in this 105 area.'Encryption' in this document typically refers to HTTP over TLS 106 [RFC2818]; other forms of encryption are noted where applicable. 108 Finally, a summary is provided of ongoing IETF work which is 109 investigating how network operators, origin servers and clients may 110 co-operate in efficient traffic delivery without the need for 111 pervasive network monitoring. 113 The legal, political and commercial aspects of network management are 114 recgnised but not covered in this technical document. 116 2. Network management functions 118 Please refer to 'Network Service Provider Monitoring' in 119 [mm-effect-encrypt] 121 3. Persisting traffic management without breaching encryption 123 This section involves utilisation of 'Application-based Flow 124 Information Visible to a Network', [mm-effect-encrypt]. 126 3.1. Providing hints to and from the network 128 The following protocols aim to support a secure and privacy-aware 129 dialogue between client, server and the network elements. These 130 hints can allow information item exchange between the endpoints and 131 the network, to assist queuing mechanisms and traffic pacing that 132 accounts for network congestion and variable connection strength. 133 These relate to the cooperative path to endpoint signalling as 134 discussed at the IAB SEMI [SEMI] and MaRNEW [MaRNEW] workshops, with 135 the network following a more clearly-defined role in encrypted 136 traffic delivery. 138 3.1.1. DiffServ Code Points (DSCP) 140 Data packets may be flagged with a traffic class (class of service). 141 Network operators may honour a DiffServ classification [RFC2474] 142 entering their network, or may choose to override it (since it is 143 potentially open to abuse by a service provider that classifies all 144 its content as high priority). The purpose is to help manage traffic 145 and congestion in the network. 147 This requires the content provider to flag data packets. This is 148 extra work for the provider, and it has potential for abuse if a 149 content provider simply flags all packets with high priorities. The 150 network would need to know which flags to trust and which to 151 override. The use of DiffServ within the operator network is 152 beneficial where the operator determines the class of service itself; 153 but where content is encrypted then heuristics would be needed to 154 predict the traffic type entering the network. HTTP/2 allows several 155 streams to be multiplexed over a single TCP connection. This means 156 that if a provider decides to send Web pages, videos, chat etc. as 157 individual streams over the same connection, then DiffServ would be 158 useless as it would apply to the TCP/IP connection as a whole. 159 However it may be more efficient for such Web providers to serve each 160 content type from separate, dedicated servers - this will become 161 clearer as HTTP/2 deployments are tuned for optimal delivery. 163 3.1.2. Explicit Congestion Notification (ECN) 165 Explicit Congestion Notification [RFC6138] routers can exchange 166 congestion notification headers to ECN compliant endpoints. This is 167 in preference to inferring congestion from dropped packets (e.g. in 168 TCP). The purpose is to help manage traffic and congestion in the 169 network. 171 This solution is required to be implemented at network and service 172 provider. The service provider will utilise the ECN to reduce 173 throughput until it is notified that congestion has eased. 175 As with DiffServ, operators may not trust an external entity to mark 176 packets in a fair/consistent manner. 178 3.1.3. Multiprotocol Label Switching (MPLS) 180 On entering an MPLS-compliant network [RFC3031], IP packets are 181 flagged with a 'Forward Equivalence Class' (FEC). This allows the 182 network to make packet-forwarding decisions according to their 183 latency requirements. MPLS routers within the network parse and act 184 upon the FEC value. The FEC is set according to the source IP 185 address and port. The purpose is to help managing traffic and 186 congestion in the network. This requires deployment of an MPLS 187 'backbone' with label-aware switches/ routers. 189 An up-to-date correspondence table between Websites (or service sites 190 in general) and server IP address must be created. Then, the 191 category(s) of traffic have to be consistently mapped to a set of 192 MPLS labels ,which entails a significant effort to setup and 193 maintain. 195 Note: MPLS can specify how OSI Layer 3 (IP layer) traffic can be 196 routed over Layer 2 (Data Link); DiffServ only operates over Layer 3. 197 DiffServ is potentially a less complex integration as it is applied 198 at the network edge servers only. 200 3.1.4. Substrate Protocol for User Datagrams (SPUD) 202 SPUD [SPUD] is a prototype to research how network devices on the 203 path between endpoints can share information to improve a flow. The 204 network involvement is outside of the end-to-end context, to minimise 205 any privacy or security breach. The initial prototype involves 206 grouping UDP packets into an explicit 'tube', however support of 207 additional transport layers (such as TCP) will also be investigated. 209 3.1.5. Mobile throughput Guidance 211 Mobile Throughput Guidance In-band Signalling [MTG] is a draft 212 proposal to allows the network to inform the server endpoint as to 213 what bandwidth the TCP connection can reasonably expect. This allows 214 the server to adapt their throughput pacing based on dynamic network 215 conditions, which can assist mechanisms such as Adaptive Bitrate 216 Streaming and TCP congestion control. 218 3.1.6. Port Control Protocol Flowdata options 220 PCP Flowdata options [PCPFD] defines a mechanism for a host to signal 221 flow characteristics to the network, and the network to signal its 222 ability to accommodate that flow back to the host. This allows 223 certain network flows to receive service that is differentiated from 224 other network flows, and may be used to establish flow priority 225 before connection establishment. PCP Flowdata operates at IPv4/IPv6 226 level. 228 3.1.7. IPv6 Flow label 230 IPv6 includes a flow label header field. [RFC6438] details how this 231 may be used to identify flows for load balancing and multipath 232 routing, which may be of particular use for application-layer 233 encrypted traffic. The flow label field is part of the main header, 234 which means it is not subject to the disadvantages of extension 235 headers (namely their risk of being dropped by intermediary routers). 236 The flow label may also be exposed as part of the outer IP packet in 237 an IP tunnel, thus providing network flow information without 238 compromising the payload. 240 3.1.8. DISCUSS 242 Differentiated prIorities and Status Code-points Using Stun 243 Signalling [DISCUSS] describes a mechanism for information exchange 244 between an application and the network, viable only for UDP. As such 245 it can be considered in the same bracket as SPUD 247 3.1.9. Active Queue Management 249 The IETF Active Queue Management and Packet Scheduling WG [AQM] works 250 on algorithms to manage network queues, with the aim of reducing 251 packet delay and taming aggressive/misbehaving flows. This includes 252 allowing flow sources to control their sending rates to avoid 253 unnecessary losses (e.g. with [RFC6138]). 255 3.1.10. Congestion Exposure 257 The Congestion Exposure WG [CONEX] makes congestion markings (based 258 on congestion experienced in the flow) available to the network via 259 IP headers, in order to drive capacity efficiency. The WG made an 260 IPv6 binding before the group concluded, however it is feasible for 261 the congestion exposure markings to also be transported by another 262 mechanism, such as SPUD. 264 3.2. Inferred flow information 266 3.2.1. Heuristics 268 Heuristics can be used to map given input data to particular 269 conclusions via some heuristic reasoning. Examples of input data to 270 this reasoning include IP destination address, TCP destination port, 271 server name from SNI, and typical traffic patterns (e.g. occurrence 272 of IP packets and TCP segments over time). The accuracy of 273 heuristics depends on whether the observed traffic originates from a 274 source delivering a single service, or a blend of services. In many 275 scenarios, this makes it possible to directly classify the traffic 276 related to a specific server/service even when the traffic is fully 277 encrypted. 279 If the server/service is co-located on an infrastructure with other 280 services that shares the same IP-address, the encrypted traffic 281 cannot be directly classified. However, commercial traffic 282 classifiers today typically apply heuristic methods, using traffic 283 pattern matching algorithms to be able to identify the traffic. As 284 an example, classifier products are able to identify popular VoIP 285 services using heuristic methods although the traffic is encrypted 286 and mostly peer-to-peer. 288 3.3. Co-operation on congestion control 290 One idea from the IAB 'Managing Radio Networks in an Encrypted World' 291 workshop [MaRNEW] was that of better co-operation between 3GPP mobile 292 networks and Internet services on congestion management. . 3GPP 293 networks are concerned with ensuring that all devices attached to a 294 particular cell receive a fair share of radio resources. This is 295 critical, since these resources are constrained to various licenced 296 spectrum bands, and volatile due to signal strength variation/cell 297 handover/interference etc. The resource sharing process occurs 298 independently to TCP congestion management performed between the 299 client and server connected via the mobile network: the result is 300 that TCP may wrongly infer congestion and react accordingly, or 301 attempt to accelerate throughput without consideration of the 302 available radio resources. Therefore the notion is to investigate 303 co-operation between radio and TCP congestion controls to better 304 manage connection throughput. 306 4. Acknowledgements 308 The editor would like to thank the GSMA Web Working Group for their 309 contributions, in particular to the technical solutions and network 310 management functions; the contributions via the SAAG mailing list 311 (Panos Kampanakis, Brian Carpenter); and Kathleen Moriarty and Al 312 Morton for their guidance in aligning this draft with 313 [mm-effect-encrypt] 315 5. IANA Considerations 317 There are no IANA considerations. 319 6. Security Considerations 321 The intention of this document is to consider how to persist network 322 management of encrypted traffic, without breaching user privacy or 323 end-to-end security. In particular this document does not recommend 324 any approach that intercepts or modifies client-server Transport 325 Layer Security. 327 7. References 329 7.1. Normative References 331 [RFC2474] Nichols, K., "Definition of the Differentiated Services 332 Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, 333 Dec 1998. 335 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 337 [RFC3031] Rosen, E., "Multiprotocol Label Switching Architecture", 338 RFC 3031, Jan 2001. 340 [RFC6138] Ramakrishnan, K., "The Addition of Explicit Congestion 341 Notification (ECN) to IP", RFC 6138, Sep 2001. 343 [RFC6438] Carpenter, B. and S. Amante, "Using the IPv6 Flow Label 344 for Equal Cost Multipath Routing and Link Aggregation in 345 Tunnels", RFC 6438, 2011. 347 [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an 348 Attack", BCP 188, RFC 7258, May 2014. 350 7.2. Informative References 352 [AQM] IETF, "Active Queue Management and Packet Scheduling (IETF 353 WG)", 2016, . 355 [CONEX] IETF, "Congestion Exposure (concluded IETF WG)", 2015, 356 . 358 [DISCUSS] Cisco, "Differentiated prIorities and Status Code-points 359 Using Stun Signalling", 2015, 360 . 363 [IAB] IAB, "IAB statement on Internet confidentiality", n.d., 364 . 367 [MaRNEW] IAB and GSMA, "Managing Radio Networks in an Encrypted 368 World (MaRNEW)", 2015, 369 . 371 [mm-effect-encrypt] 372 IETF, "Effect of Ubiquitous Encryption", n.d., 373 . 376 [MTG] IETF, "Mobile Throughput Guidance Inband Signaling 377 Protocol", n.d., . 380 [PCPFD] Cisco, "PCP Flowdata option", 2013, 381 . 383 [SEMI] IAB, "IAB workshop, 'Stack Evolution in a Middlebox 384 Internet'", n.d., 385 . 387 [SPUD] IETF, "Substrate Protocol for User Datagrams", n.d., 388 . 391 [TAG] W3C, "Securing the Web", n.d., . 394 Author's Address 396 Kevin Smith 397 Vodafone Group 399 Email: kevin.smith@vodafone.com