idnits 2.17.1
draft-smith-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 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 203: '...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 (May 08, 2015) is 3268 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 May 08, 2015
5 Expires: November 9, 2015
7 Network management of encrypted traffic
8 draft-smith-encrypted-traffic-management-00
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 9, 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. Intrusion detection . . . . . . . . . . . . . . . . . . . 4
56 2.3. Policy enforcement . . . . . . . . . . . . . . . . . . . 4
57 2.4. SPAM and malware filtering . . . . . . . . . . . . . . . 4
58 3. Flow information visible to a network . . . . . . . . . . . . 4
59 3.1. IP 5-tuple . . . . . . . . . . . . . . . . . . . . . . . 4
60 3.2. TLS Server Name Indication . . . . . . . . . . . . . . . 5
61 3.3. Application Layer Protocol Negotiation (ALPN) . . . . . . 5
62 3.4. DiffServ Code Points (DSCP) . . . . . . . . . . . . . . . 5
63 3.5. Explicit Congestion Notification . . . . . . . . . . . . 6
64 3.6. Multi Protocol Label Switching . . . . . . . . . . . . . 6
65 4. Inferred flow information . . . . . . . . . . . . . . . . . . 7
66 4.1. Heuristics . . . . . . . . . . . . . . . . . . . . . . . 7
67 5. Providing hints to and from the network . . . . . . . . . . . 7
68 5.1. Substrate Protocol for User Datagrams (SPUD) . . . . . . 7
69 5.2. Mobile throughput Guidance . . . . . . . . . . . . . . . 8
70 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8
71 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
72 8. Security Considerations . . . . . . . . . . . . . . . . . . . 8
73 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
74 9.1. Normative References . . . . . . . . . . . . . . . . . . 8
75 9.2. Informative References . . . . . . . . . . . . . . . . . 9
76 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9
78 1. Introduction
80 Networks utilise various management techniques to ensure efficient
81 throughput, congestion management, anti-SPAM and security measures.
82 Historically these functions have utilised visibility of the Internet
83 application layer.
85 This visibility is rapidly diminishing - encrypted Internet traffic
86 is expected to continue its upward trend, driven by increased privacy
87 awareness, uptake by popular services, and advocacy from the [IAB],
88 [RFC7258] and W3C [TAG] .
90 [IAB], [RFC7258] and [mm-effect-encrypt] recognise that network
91 management functions are impacted by encryption, and that solutions
92 are needed to persist them - as long as they do not threaten privacy.
93 These solutions would ensure the benefits of encryption do not
94 degrade network efficiency.
96 This document lists such solutions, and points to evolving IETF work
97 addressing the problem.
99 1.1. Document structure
101 This document describes the network management functions that are
102 likely to be hindered by traffic encryption.
104 It then describes the technical details of existing options to fully
105 or partially persist these functions under encryption. 'Encryption'
106 in this document typically refers to HTTP over TLS [RFC2818]; other
107 forms of encryption are noted where applicable.
109 Finally, a summary is provided of ongoing IETF work which is
110 investigating how middleboxes along the network path can improve
111 encrypted traffic delivery - again without breaching user privacy or
112 security.
114 The legal, political and commercial aspects of network management are
115 recgnised but not covered in this technical document.
117 1.2. Security protocols
119 The following IETF protocols are considered in this document: TLS
120 [RFC5246] , IPsec [RFC4301] and the ongoing transport layer security
121 work of [TCPINC].
123 2. Network management functions
125 Editor's note: Part or all of this section may be removed where there
126 is duplication with any updated version of [mm-effect-encrypt]
128 2.1. Queuing
130 Traffic flowing through a network may be queued for delivery. This
131 is important at an access network where network conditions can change
132 rapidly - such as a cellular radio access network. To account for
133 congestion, the network will categorise content requests according to
134 the latency and bandwidth required to deliver that content type.
135 These combinations run from high-latency, low bandwidth (Email),
136 medium latency, medium bandwidth (Web pages), low latency high
137 bandwidth (video streaming), and many others including voice calls,
138 texts, WebRTC and VoIP. A well-managed network will triage between
139 these content types and deliver from each queue in bursts, to ensure
140 no user experiences a disrupted service.
142 2.2. Intrusion detection
144 Networks will monitor traffic stream behaviours to identify likely
145 Denial of Service attacks. Tools exist at each network layer to
146 detect and mitigate these, including application layer detection.
148 2.3. Policy enforcement
150 Approved access to a network is a prerequisite to requests for
151 Internet traffic - hence network access, including any authentication
152 and authorisation, is not impacted by traffic encryption.
154 Cellular networks often sell tariffs that allow free-data access to
155 certain sites, known as 'zero rating'. A session to visit such a
156 site incurs no additional cost or data usage to the user. Such 'zero
157 rating
159 Note: this section deliberately does not go into detail on the
160 ramifications of encryption as regards government regulation. These
161 regulations include 'Lawful Intercept', adherence to Codes of
162 Practice on content filtering, application of court order filters.
163 However it is clear that these functions are impacted by encryption,
164 typically by allowing a less granular means of implementation. The
165 enforcement of any Net Neutrality regulations is unlikely to be
166 affected by content being encrypted.
168 2.4. SPAM and malware filtering
170 This has typically required Deep Packet Inspection to filter various
171 keywords, fraudulent headers and virus attachments.
173 3. Flow information visible to a network
175 3.1. IP 5-tuple
177 This indicates source and destination IP addresses/ports and the
178 transport protocol. This information is available during TLS, TCP-
179 layer encryption (except ports), and IP-layer encryption (IPSec);
180 although it may be obscured in Tunnel mode IPSec.
182 This allows network management at a coarse IP-source level, which
183 makes it of limited value where the origin server supports a blend of
184 service types.
186 Obscured from network by: IPSec Tunnel Mode
188 3.2. TLS Server Name Indication
190 When initiating the TLS handshake, the Client may provide an
191 extension field (server_name) which indicates the server to which it
192 is attempting a secure connection. TLS SNI was standardized in 2003
193 to enable servers to present the "correct TLS certificate" to clients
194 in a deployment of multiple virtual servers hosted by the same server
195 infrastructure and IP-address. Although this is an optional
196 extension, it is today supported by all modern browsers, web servers
197 and developer libraries. Notable exceptions are Android 2.2 and
198 Internet Explorer 6 on Windows XP. It should be noted that HTTP/2
199 introduces the Alt-SVC method for upgrading the connection from
200 HTTP/1 to either unencrypted or encrypted HTTP/2. If the initial
201 HTTP/1 request is unencrypted, the destination alternate service name
202 can be identified before the communication is potentially upgraded to
203 encrypted HTTP/2 transport. HTTP/2 implementations MUST support the
204 Server Name Indication (SNI) extension.
206 Limitation: This information is only visible if the client is
207 populating the Server Name Indication extension. This need not be
208 done, but may be done as per TLS standard. Therefore, even if
209 existing network filters look out for seeing a Server Name Indication
210 extension, they may not find one. The per-domain nature of SNI may
211 not reveal the specific service or media type being accessed,
212 especially where the domain is of a provider offering a range of
213 email, video, Web pages etc. For example, certain blog or social
214 network feeds may be deemed 'adult content', but the Server Name
215 Indication will only indicate the server domain rather than a URL
216 path to be blocked.
218 Obscured from network by: not providing the SNI, IPSec
220 3.3. Application Layer Protocol Negotiation (ALPN)
222 ALPN is a TLS extenion which may be used to indicate the application
223 protocol within the TLS session. This is likely to be of more value
224 to the network where it indicates a protocol dedicated to a
225 particular traffic type (such as video streaming) rather than a
226 multi-use protocol. ALPN is used as part of HTTP/2 'h2', but will
227 not indicate the traffic types which may make up streams within an
228 HTTP/2 multiplex.
230 3.4. DiffServ Code Points (DSCP)
232 Data packets are flagged with a traffic class (class of service).
233 Network operators may honour a DiffServ classification entering their
234 network, or may choose to override it (since it is potentially open
235 to abuse by a service provider that classifies all its content as
236 high priority). The purpose is to help manage traffic and congestion
237 in the network.
239 Limitations: This requires the content provider to flag data packets.
240 This is extra work for the provider, and it has potential for abuse
241 if a content provider simply flags all packets with high priorities.
242 The network would need to know which flags to trust and which to
243 override. The use of DiffServ within the operator network is
244 beneficial where the operator determines the class of service itself;
245 but where content is encrypted then heuristics would be needed to
246 predict the traffic type entering the network. HTTP/2 allows several
247 streams to be multiplexed over a single TCP connection. This means
248 that if a provider decides to send Web pages, videos, chat etc. as
249 individual streams over the same connection, then DiffServ would be
250 useless as it would apply to the TCP/IP connection as a whole.
251 However it may be more efficient for such Web providers to serve each
252 content type from separate, dedicated servers - this will become
253 clearer as HTTP/2 deployments are tuned for optimal delivery.
255 3.5. Explicit Congestion Notification
257 Explicit Congestion Notification (ECN) routers can exchange
258 congestion notification headers to ECN compliant endpoints. This is
259 in preference to inferring congestion from dropped packets (e.g. in
260 TCP). The purpose is to help manage traffic and congestion in the
261 network.
263 This solution is required to be implemented at network and service
264 provider. The service provider will utilise the ECN to reduce
265 throughput until it is notified that congestion has eased.
267 Limitation: As with DiffServ, operators may not trust an external
268 entity to mark packets in a fair/consistent manner.
270 3.6. Multi Protocol Label Switching
272 Description: on entering an MPLS-compliant network, IP packets are
273 flagged with a 'Forward Equivalence Class' (FEC). This allows the
274 network to make packet-forwarding decisions according to their
275 latency requirements. MPLS routers within the network parse and act
276 upon the FEC value. The FEC is set according to the source IP
277 address and port. The purpose is to help managing traffic and
278 congestion in the network. This requires deployment of an MPLS
279 'backbone' with label-aware switches/ routers.
281 Limitations: an up-to-date correspondence table between Websites and
282 server IP address must be created. Then, the category(s) of traffic
283 have to be consistently mapped to a set of MPLS labels ,which entails
284 a significant effort to setup and maintain.
286 Note: MPLS can specify how OSI Layer 3 (IP layer) traffic can be
287 routed over Layer 2 (Data Link); DiffServ only operates over Layer 3.
288 DiffServ is potentially a less complex integration as it is applied
289 at the network edge servers only.
291 4. Inferred flow information
293 4.1. Heuristics
295 Heuristics can be used to map given input data to particular
296 conclusions via some heuristic reasoning. Examples of input data to
297 this reasoning include IP destination address, TCP destination port,
298 server name from SNI, typical traffic pattern (e.g. occurrence of IP
299 packets and TCP segments over time). The accuracy of heuristics
300 depends on whether the observed traffic originates from a source
301 delivering a single service, or a blend of services. In many
302 scenarios, this makes it possible to directly classify the traffic
303 related to a specific server/service even when the traffic is fully
304 encrypted.
306 If the server/service is co-located on an infrastructure with other
307 services that shares the same IP-address, the encrypted traffic
308 cannot be directly classified. However, commercial traffic
309 classifiers today typically apply heuristic methods, using traffic
310 pattern matching algorithms to be able to identify the traffic. As
311 an example, classifier products are able to identify popular VoIP
312 services using heuristic methods although the traffic is encrypted
313 and mostly peer-to-peer.
315 5. Providing hints to and from the network
317 The following draft protocols aim to support a secure and privacy-
318 aware dialogue between client, server and a network middlebox. This
319 follows the cooperative path to endpoint signalling as discussed at
320 the IAB SEMI workshop [SEMI], with the network following a more
321 clearly-defined role in encrypted traffic delivery. These hints can
322 allow information item exchange between the endpoints and the
323 network, to assist queuing mechanisms and traffic pacing that
324 accounts for network congestion and variable connection strength.
326 5.1. Substrate Protocol for User Datagrams (SPUD)
328 SPUD [SPUD] allows network devices on the path between endpoints to
329 participate explicitly in a 'tube' of grouped UDP packets. The
330 network involvement is outside of the end-to-end context, to minimise
331 any privacy or security breach. The initial prototype is based on
332 UDP packets but will investigate the support of additional transport
333 layers (such as TCP).
335 5.2. Mobile throughput Guidance
337 Mobile Throughput Guidance In-band Signalling [MTG] allows the
338 network to inform the server endpoint as to what bandwidth the TCP
339 connection can reasonably expect. This allows the server to adapt
340 their throughput pacing based on dynamic network conditions, which
341 can assist mechanisms such as Adaptive Bitrate Streaming and TCP
342 congestion control.
344 6. Acknowledgements
346 The editor would like to thank the GSMA Web Working Group for their
347 contributions, in particular to the technical solutions and network
348 management functions.
350 7. IANA Considerations
352 There are no IANA consideraions.
354 8. Security Considerations
356 The intention of this document is to consider how to persist network
357 management of encrypted traffic, without breaching user privacy or
358 end-to-end security. In particular this document does not recommend
359 any approach that intercepts or modifies client-server Transport
360 Layer Security.
362 9. References
364 9.1. Normative References
366 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
368 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the
369 Internet Protocol", RFC 4301, December 2005.
371 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
372 (TLS) Protocol Version 1.2", RFC 5246, August 2008.
374 [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an
375 Attack", BCP 188, RFC 7258, May 2014.
377 9.2. Informative References
379 [IAB] IAB, "IAB statement on Internet confidentiality", n.d.,
380 .
383 [MTG] IETF, "Mobile Throughput Guidance Inband Signaling
384 Protocol", n.d., .
387 [SEMI] IAB, "IAB workshop, 'Stack Evolution in a Middlebox
388 Internet'", n.d.,
389 .
391 [SPUD] IETF, "Substrate Protocol for User Datagrams", n.d.,
392 .
395 [TAG] W3C, "Securing the Web", n.d., .
398 [TCPINC] IETF, "TCP Increased Security", n.d.,
399 .
401 [mm-effect-encrypt]
402 IETF, "Effect of Ubiquitous Encryption", n.d.,
403 .
406 Author's Address
408 Kevin Smith
409 Vodafone Group
411 Email: kevin.smith@vodafone.com