idnits 2.17.1
draft-mm-wg-effect-encrypt-21.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 (February 19, 2018) is 2257 days in the past. Is this
intentional?
Checking references for intended status: Informational
----------------------------------------------------------------------------
== Outdated reference: A later version (-25) exists of
draft-ietf-dots-use-cases-09
== Outdated reference: A later version (-09) exists of
draft-ietf-tls-sni-encryption-00
== Outdated reference: A later version (-06) exists of
draft-mglt-nvo3-geneve-security-requirements-02
-- Obsolete informational reference (is this intentional?): RFC 3315
(Obsoleted by RFC 8415)
-- Obsolete informational reference (is this intentional?): RFC 7230
(Obsoleted by RFC 9110, RFC 9112)
-- Obsolete informational reference (is this intentional?): RFC 7234
(Obsoleted by RFC 9111)
-- Obsolete informational reference (is this intentional?): RFC 7525
(Obsoleted by RFC 9325)
-- Obsolete informational reference (is this intentional?): RFC 7540
(Obsoleted by RFC 9113)
Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 6 comments (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
2 Network Working Group K. Moriarty, Ed.
3 Internet-Draft Dell EMC
4 Intended status: Informational A. Morton, Ed.
5 Expires: August 23, 2018 AT&T Labs
6 February 19, 2018
8 Effects of Pervasive Encryption on Operators
9 draft-mm-wg-effect-encrypt-21
11 Abstract
13 Pervasive Monitoring (PM) attacks on the privacy of Internet users
14 are of serious concern to both the user and the operator communities.
15 RFC7258 discussed the critical need to protect users' privacy when
16 developing IETF specifications and also recognized making networks
17 unmanageable to mitigate PM is not an acceptable outcome; an
18 appropriate balance is needed. This document discusses current
19 security and network operations and management practices that may be
20 impacted by the shift to increased use of encryption to help guide
21 protocol development in support of manageable and secure networks.
23 Status of This Memo
25 This Internet-Draft is submitted in full conformance with the
26 provisions of BCP 78 and BCP 79.
28 Internet-Drafts are working documents of the Internet Engineering
29 Task Force (IETF). Note that other groups may also distribute
30 working documents as Internet-Drafts. The list of current Internet-
31 Drafts is at https://datatracker.ietf.org/drafts/current/.
33 Internet-Drafts are draft documents valid for a maximum of six months
34 and may be updated, replaced, or obsoleted by other documents at any
35 time. It is inappropriate to use Internet-Drafts as reference
36 material or to cite them other than as "work in progress."
38 This Internet-Draft will expire on August 23, 2018.
40 Copyright Notice
42 Copyright (c) 2018 IETF Trust and the persons identified as the
43 document authors. All rights reserved.
45 This document is subject to BCP 78 and the IETF Trust's Legal
46 Provisions Relating to IETF Documents
47 (https://trustee.ietf.org/license-info) in effect on the date of
48 publication of this document. Please review these documents
49 carefully, as they describe your rights and restrictions with respect
50 to this document. Code Components extracted from this document must
51 include Simplified BSD License text as described in Section 4.e of
52 the Trust Legal Provisions and are provided without warranty as
53 described in the Simplified BSD License.
55 Table of Contents
57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
58 1.1. Additional Background on Encryption Changes . . . . . . . 4
59 1.2. Examples of Attempts to Preserve Functions . . . . . . . 6
60 2. Network Service Provider Monitoring . . . . . . . . . . . . . 7
61 2.1. Passive Monitoring . . . . . . . . . . . . . . . . . . . 8
62 2.1.1. Traffic Surveys . . . . . . . . . . . . . . . . . . . 8
63 2.1.2. Troubleshooting . . . . . . . . . . . . . . . . . . . 8
64 2.1.3. Traffic Analysis Fingerprinting . . . . . . . . . . . 11
65 2.2. Traffic Optimization and Management . . . . . . . . . . . 12
66 2.2.1. Load Balancers . . . . . . . . . . . . . . . . . . . 12
67 2.2.2. Differential Treatment based on Deep Packet
68 Inspection (DPI) . . . . . . . . . . . . . . . . . . 14
69 2.2.3. Network Congestion Management . . . . . . . . . . . . 15
70 2.2.4. Performance-enhancing Proxies . . . . . . . . . . . . 15
71 2.2.5. Caching and Content Replication Near the Network Edge 16
72 2.2.6. Content Compression . . . . . . . . . . . . . . . . . 17
73 2.2.7. Service Function Chaining . . . . . . . . . . . . . . 17
74 2.3. Content Filtering, Network Access, and Accounting . . . . 18
75 2.3.1. Content Filtering . . . . . . . . . . . . . . . . . . 18
76 2.3.2. Network Access and Data Usage . . . . . . . . . . . . 19
77 2.3.3. Application Layer Gateways . . . . . . . . . . . . . 20
78 2.3.4. HTTP Header Insertion . . . . . . . . . . . . . . . . 21
79 3. Encryption in Hosting and Application SP Environments . . . . 21
80 3.1. Management Access Security . . . . . . . . . . . . . . . 22
81 3.1.1. Customer Access Monitoring . . . . . . . . . . . . . 22
82 3.1.2. SP Content Monitoring of Applications . . . . . . . . 23
83 3.2. Hosted Applications . . . . . . . . . . . . . . . . . . . 25
84 3.2.1. Monitoring Managed Applications . . . . . . . . . . . 25
85 3.2.2. Mail Service Providers . . . . . . . . . . . . . . . 26
86 3.3. Data Storage . . . . . . . . . . . . . . . . . . . . . . 26
87 3.3.1. Object-level Encryption . . . . . . . . . . . . . . . 27
88 3.3.2. Disk Encryption, Data at Rest . . . . . . . . . . . . 28
89 3.3.3. Cross Data Center Replication Services . . . . . . . 28
90 4. Encryption for Enterprises . . . . . . . . . . . . . . . . . 29
91 4.1. Monitoring Practices of the Enterprise . . . . . . . . . 29
92 4.1.1. Security Monitoring in the Enterprise . . . . . . . . 30
93 4.1.2. Application Performance Monitoring in the Enterprise 31
94 4.1.3. Enterprise Network Diagnostics and Troubleshooting . 31
95 4.2. Techniques for Monitoring Internet Session Traffic . . . 33
96 5. Security Monitoring for Specific Attack Types . . . . . . . . 35
97 5.1. Mail Abuse and spam . . . . . . . . . . . . . . . . . . . 35
98 5.2. Denial of Service . . . . . . . . . . . . . . . . . . . . 36
99 5.3. Phishing . . . . . . . . . . . . . . . . . . . . . . . . 36
100 5.4. Botnets . . . . . . . . . . . . . . . . . . . . . . . . . 37
101 5.5. Malware . . . . . . . . . . . . . . . . . . . . . . . . . 37
102 5.6. Spoofed Source IP Address Protection . . . . . . . . . . 38
103 5.7. Further work . . . . . . . . . . . . . . . . . . . . . . 38
104 6. Application-based Flow Information Visible to a Network . . . 38
105 6.1. IP Flow Information Export . . . . . . . . . . . . . . . 38
106 6.2. TLS Server Name Indication . . . . . . . . . . . . . . . 39
107 6.3. Application Layer Protocol Negotiation (ALPN) . . . . . . 40
108 6.4. Content Length, BitRate and Pacing . . . . . . . . . . . 40
109 7. Effect of Encryption on Mobile Network Evolution . . . . . . 40
110 8. Response to Increased Encryption and Looking Forward . . . . 41
111 9. Security Considerations . . . . . . . . . . . . . . . . . . . 42
112 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 42
113 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 42
114 12. Informative References . . . . . . . . . . . . . . . . . . . 42
115 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 50
117 1. Introduction
119 In response to pervasive monitoring revelations and the IETF
120 consensus that Pervasive Monitoring is an Attack [RFC7258], efforts
121 are underway to increase encryption of Internet traffic. Pervasive
122 Monitoring (PM) is of serious concern to users, operators, and
123 application providers. RFC7258 discussed the critical need to
124 protect users' privacy when developing IETF specifications and also
125 recognized that making networks unmanageable to mitigate PM is not an
126 acceptable outcome, but rather that an appropriate balance would
127 emerge over time.
129 This document describes practices currently used by network operators
130 to manage, operate, and secure their networks and how those practices
131 may be impacted by a shift to increased use of encryption. It
132 provides network operators' perspectives about the motivations and
133 objectives of those practices as well as effects anticipated by
134 operators as use of encryption increases. It is a summary of
135 concerns of the operational community as they transition to managing
136 networks with less visibility. The document does not endorse the use
137 of the practices described herein. Nor does it aim to provide a
138 comprehensive treatment of the effects of current practices, some of
139 which have been considered controversial from a technical or business
140 perspective or contradictory to previous IETF statements (e.g.,
141 [RFC1958], [RFC1984], [RFC2804]). The informational documents
142 consider the end to end (e2e) architectural principle to be a guiding
143 principle for the development of Internet protocols [RFC2775]
144 [RFC3724] [RFC7754].
146 This document aims to help IETF participants understand network
147 operators' perspectives about the impact of pervasive encryption,
148 both opportunistic and strong end-to-end encryption, on operational
149 practices. The goal is to help inform future protocol development to
150 ensure that operational impact is part of the conversation. Perhaps,
151 new methods could be developed to accomplish some of the goals of
152 current practices despite changes in the extent to which cleartext
153 will be available to network operators (including methods that rely
154 on network endpoints where applicable). Discussion of current
155 practices and the potential future changes is provided as a
156 prerequisite to potential future cross-industry and cross-layer work
157 to support the ongoing evolution towards a functional Internet with
158 pervasive encryption.
160 Traditional network management, planning, security operations, and
161 performance optimization have been developed in an Internet where a
162 large majority of data traffic flows without encryption. While
163 unencrypted traffic has made information that aids operations and
164 troubleshooting at all layers accessible, it has also made pervasive
165 monitoring by unseen parties possible. With broad support and
166 increased awareness of the need to consider privacy in all aspects
167 across the Internet, it is important to catalog existing management,
168 operational, and security practices that have depended upon the
169 availability of cleartext to function and to explore if critical
170 operational practices can be met by less invasive means.
172 This document refers to several different forms of service providers,
173 distinguished with adjectives. For example, network service
174 providers (or network operators) provide IP-packet transport
175 primarily, though they may bundle other services with packet
176 transport. Alternatively, application service providers primarily
177 offer systems that participate as an end-point in communications with
178 the application user, and hosting service providers lease computing,
179 storage, and communications systems in datacenters. In practice,
180 many companies perform two or more service provider roles, but may be
181 historically associated with one.
183 This document includes a sampling of current practices and does not
184 attempt to describe every nuance. Some sections cover technologies
185 used over a broad spectrum of devices and use cases.
187 1.1. Additional Background on Encryption Changes
189 Pervasive encryption in this document refers to all types of session
190 encryption including Transport Layer Security (TLS), IP security
191 (IPsec), TCPcrypt [TCPcrypt], QUIC [QUIC] and others that are
192 increasing in deployment usage. It is well understood that session
193 encryption helps to prevent both passive and active attacks on
194 transport protocols; more on pervasive monitoring can be found in
195 Confidentiality in the Face of Pervasive Surveillance: A Threat Model
196 and Problem Statement [RFC7624]. Active attacks have long been a
197 motivation for increased encryption, and preventing pervassive
198 monitoring became a focus just a few years ago. As such, the
199 Internet Architecture Board (IAB) released a statement advocating for
200 increased use of encryption in November 2014. Perspectives on
201 encryption paradigms have shifted over time from always requiring
202 unbreakable session encryption to allowing for risk profiles that
203 include breakable session encryption since the latter is more easily
204 deployed than the former and is preferable to no encryption at all.
206 One such shift is documented in "Opportunistic Security" (OS)
207 [RFC7435], which suggests that when use of authenticated encryption
208 is not possible, cleartext sessions should be upgraded to
209 unauthenticated session encryption, rather than no encryption. OS
210 encourages upgrading from cleartext, but cannot require or guarantee
211 such upgrades. Once OS is used, it allows for an evolution to
212 authenticated encryption. These efforts are necessary to improve end
213 user's expectation of privacy, making pervasive monitoring cost
214 prohibitive. With OS in use, active attacks are still possible on
215 unauthenticated sessions. OS has been implemented as NULL
216 Authentication with IPsec [RFC7619] and there are a number of
217 infrastructure use cases such as server to server encryption where
218 this mode is deployed. While OS is helpful in reducing pervassive
219 monitoring by increasing the cost to monitor, it is recognized that
220 risk profiles for some applications require authenticated and secure
221 session encryption as well to prevent active attacks. IPsec, and
222 other session encryption protocols, with authentication has many
223 useful applications and usage has increased for infrastructure
224 applications such as for virtual private networks between data
225 centers. OS as well as other protocol developments, like the
226 Automated Certificate Management Environment (ACME), have increased
227 the usage of session encryption on the Internet.
229 Risk profiles vary and so do the types of session encryption
230 deployed. To understand the scope of changes in visibility a few
231 examples are highlighted. Work continues to improve the
232 implementation, development and configuration of TLS and DTLS
233 sessions to prevent active attacks used to monitor or intercept
234 session data. The changes from TLS 1.2 to 1.3 enhance the security
235 of TLS, while hiding more of the session negotiation and providing
236 less visibility on the wire. The Using TLS in Applications (UTA)
237 working group has been publishing documentation to improve the
238 security of TLS and DTLS sessions. They have documented the known
239 attack vectors in [RFC7457] and have documented Best Practices for
240 TLS and DTLS in [RFC7525] and have other documents in the queue. The
241 recommendations from these documents were built upon for TLS 1.3 to
242 provide a more inherently secure end-to-end protocol.
244 In addition to encrypted web site access (HTTP over TLS), there are
245 other well-deployed application level transport encryption efforts
246 such as mail transfer agent (MTA)-to-MTA session encryption transport
247 for email (SMTP over TLS) and gateway-to-gateway for instant
248 messaging (Extensible Messaging and Presence Protocol (XMPP) over
249 TLS). Although this does provide protection from transport layer
250 attacks, the servers could be a point of vulnerability if user-to-
251 user encryption is not provided for these messaging protocols. User-
252 to-user content encryption schemes, such as S/MIME and PGP for email
253 and Off-the-Record (OTR) encryption for XMPP are used by those
254 interested to protect their data as it crosses intermediary servers,
255 preventing transport layer attacks by providing an end-to-end
256 solution. User-to-user schemes are under review and additional
257 options will emerge to ease the configuration requirements, making
258 this type of option more accessible to non-technical users interested
259 in protecting their privacy.
261 Increased use of encryption, either opportunistic or authenticated,
262 at the transport, network or application layer, impacts how networks
263 are operated, managed, and secured. In some cases, new methods to
264 operate, manage, and secure networks will evolve in response. In
265 other cases, currently available capabilities for monitoring or
266 troubleshooting networks could become unavailable. This document
267 lists a collection of functions currently employed by network
268 operators that may be impacted by the shift to increased use of
269 encryption. This draft does not attempt to specify responses or
270 solutions to these impacts, but rather documents the current state.
272 1.2. Examples of Attempts to Preserve Functions
274 Following the Snowden [Snowden] revelations, application service
275 providers responded by encrypting traffic between their data centers
276 (IPsec) to prevent passive monitoring from taking place unbeknownst
277 to them (Yahoo, Google, etc.). Infrastructure traffic carried over
278 the public Internet has been encrypted for some time, this change for
279 universal encryption was specific to their private backbones. Large
280 mail service providers also began to encrypt session transport (TLS)
281 to hosted mail services. This and other increases in the use of
282 encryption had the immediate effect of providing confidentiality and
283 integrity for protected data, but created a problem for some network
284 management functions. Operators could no longer gain access to some
285 session streams resulting in actions by several to regain their
286 operational practices that previously depended on cleartext data
287 sessions.
289 The EFF reported [EFF2014] several network service providers using a
290 downgrade attack to prevent the use of SMTP over TLS by breaking
291 STARTTLS (section 3.2 of [RFC7525]), essentially preventing the
292 negotiation process resulting in fallback to the use of clear text.
293 There has already been documented cases of service providers
294 preventing STARTTLS to prevent session encryption negotiation on some
295 session to inject a super cookie to enable tracking of users for
296 advertisers, also considered an attack. These serves as examples of
297 undesirable behavior that could be prevented through upfront
298 discussions in protocol work for operators and protocol designers to
299 understand the implications of such actions. In other cases, some
300 service providers and enterprises have relied on middleboxes having
301 access to clear text for the purposes of load balancing, monitoring
302 for attack traffic, meeting regulatory requirements, or for other
303 purposes. The implications for enterprises, who own the data on
304 their networks is very differnt from service providers who may be
305 accessing content that violates privacy considerations.
306 Additionally, service provider equipment is designed for accessing
307 only the headers exposed for the data-link, network, and transport
308 layers. Delving deeper into packets is possible, but there is
309 typically a high degree of accuracy from the header information and
310 packet sizes when limited to header information from these three
311 layers. Service providers also have the option of adding routing
312 overlay protocols to traffic. These middlebox implementations,
313 whether performing functions considered legitimate by the IETF or
314 not, have been impacted by increases in encrypted traffic. Only
315 methods keeping with the goal of balancing network management and PM
316 mitigation in [RFC7258] should be considered in solution work
317 resulting from this document.
319 It is well known that national surveillance programs monitor traffic
320 [JNSLP] [RFC2804] [RFC7258] monitor for criminal activities.
321 Governments vary on their balance between monitoring versus the
322 protection of user privacy, data, and assets. Those that favor
323 unencrypted access to data ignore the real need to protect users'
324 identity, financial transactions and intellectual property, which
325 requires security and encryption to prevent crime. A clear
326 understanding of technology, encryption, and monitoring goals will
327 aid in the development of solutions as work continues towards finding
328 an appropriate balance allowing for management while protecting users
329 privacy with strong encryption solutions.
331 2. Network Service Provider Monitoring
333 Network Service Providers (SP) for this definition include the
334 backbone Internet Service providers as well as those providing
335 infrastructure at scale for core Internet use (hosted infrastructure
336 and services such as email).
338 Network service providers use various techniques to operate, manage,
339 and secure their networks. The following subsections detail the
340 purpose of several techniques and which protocol fields are used to
341 accomplish each task. In response to increased encryption of these
342 fields, some network service providers may be tempted to undertake
343 undesirable security practices in order to gain access to the fields
344 in unencrypted data flows. To avoid this situation, new methods
345 could be developed to accomplish the same goals without service
346 providers having the ability to see session data.
348 2.1. Passive Monitoring
350 2.1.1. Traffic Surveys
352 Internet traffic surveys are useful in many pursuits, such as input
353 for Center for Applied Internet Data Analysis (CAIDA) studies
354 [CAIDA], network planning and optimization. Tracking the trends in
355 Internet traffic growth, from earlier peer-to-peer communication to
356 the extensive adoption of unicast video streaming applications, has
357 relied on a view of traffic composition with a particular level of
358 assumed accuracy, based on access to cleartext by those conducting
359 the surveys.
361 Passive monitoring makes inferences about observed traffic using the
362 maximal information available, and is subject to inaccuracies
363 stemming from incomplete sampling (of packets in a stream) or loss
364 due to monitoring system overload. When encryption conceals more
365 layers in each packet, reliance on pattern inferences and other
366 heuristics grows, and accuracy suffers. For example, the traffic
367 patterns between server and browser are dependent on browser supplier
368 and version, even when the sessions use the same server application
369 (e.g., web e-mail access). It remains to be seen whether more
370 complex inferences can be mastered to produce the same monitoring
371 accuracy.
373 2.1.2. Troubleshooting
375 Network operators use protocol-dissecting analyzers when responding
376 to customer problems, to identify the presence of attack traffic, and
377 to identify root causes of the problem such as misconfiguration. In
378 limited cases, packet captures may also be used when a customer
379 approves of access to their packets or provides packet captures close
380 to the endpoint. The protocol dissection is generally limited to
381 supporting protocols (e.g., DNS, DHCP), network and transport (e.g.,
382 IP, TCP), and some higher layer protocols (e.g., RTP, RTCP).
383 Troubleshooting will move closer to the endpoint with increased
384 encryption and adjustments in practices to effectively troubleshoot
385 using a 5-tuple may require education. Packet loss investigations,
386 and those where access is limited to a 2-tuple (IPsec tunnel mode),
387 rely on network and transport layer headers taken at the endpoint.
388 In this case, captures on intermediate nodes are not reliable as
389 there are far too many cases of aggregate interfaces and alternate
390 paths in service provider networks.
392 Network operators are often the first ones called upon to investigate
393 application problems (e.g., "my HD video is choppy"). When
394 diagnosing a customer problem, the starting point may be a particular
395 application that isn't working. The ability to identify the problem
396 application's traffic is important and packet capture is often used
397 for this purpose; IP address filtering is not useful for applications
398 using content delivery networks (CDNs) or cloud providers. After
399 identifying the traffic, an operator may analyze the traffic
400 characteristics and routing of the traffic.
402 For example, by investigating packet loss (from TCP sequence and
403 acknowledgement numbers), round-trip-time (from TCP timestamp options
404 or application-layer transactions, e.g., DNS or HTTP response time),
405 TCP receive-window size, packet corruption (from checksum
406 verification), inefficient fragmentation, or application-layer
407 problems, the operator can narrow the problem to a portion of the
408 network, server overload, client or server misconfiguration, etc.
409 Network operators may also be able to identify the presence of attack
410 traffic as not conforming to the application the user claims to be
411 using. In many instances, the exposed packet header is sufficient
412 for this type of troubleshooting.
414 One way of quickly excluding the network as the bottleneck during
415 troubleshooting is to check whether the speed is limited by the
416 endpoints. For example, the connection speed might instead be
417 limited by suboptimal TCP options, the sender's congestion window,
418 the sender temporarily running out of data to send, the sender
419 waiting for the receiver to send another request, or the receiver
420 closing the receive window. All this information can be derived from
421 the cleartext TCP header.
423 Packet captures and protocol-dissecting analyzers have been important
424 tools. Automated monitoring has also been used to proactively
425 identify poor network conditions, leading to maintenance and network
426 upgrades before user experience declines. For example, findings of
427 loss and jitter in VoIP traffic can be a predictor of future customer
428 dissatisfaction (supported by metadata from the RTP/RTCP protocol )
429 [RFC3550], or increases in DNS response time can generally make
430 interactive web browsing appear sluggish. But to detect such
431 problems, the application or service stream must first be
432 distinguished from others.
434 When increased encryption is used, operators lose a source of data
435 that may be used to debug user issues. For example, IPsec obscures
436 TCP and RTP header information, while TLS and SRTP do not. Because
437 of this, application server operators using increased encryption
438 might be called upon more frequently to assist with debugging and
439 troubleshooting, and thus may want to consider what tools can be put
440 in the hands of their clients or network operators.
442 Further, the performance of some services can be more efficiently
443 managed and repaired when information on user transactions is
444 available to the service provider. It may be possible to continue
445 such monitoring activities without clear text access to the
446 application layers of interest, but inaccuracy will increase and
447 efficiency of repair activities will decrease. For example, an
448 application protocol error or failure would be opaque to network
449 troubleshooters when transport encryption is applied, making root
450 cause location more difficult and therefore increasing the time-to-
451 repair. Repair time directly reduces the availability of the
452 service, and most network operators have made availability a key
453 metric in their Service Level Agreements and/or subscription rebates.
454 Also, there may be more cases of user communication failures when the
455 additional encryption processes are introduced (e.g., key management
456 at large scale), leading to more customer service contacts and (at
457 the same time) less information available to network operations
458 repair teams.
460 In mobile networks, knowledge about TCP's stream transfer progress
461 (by observing ACKs, retransmissions, packet drops, and the Sector
462 Utilization Level etc.) is further used to measure the performance of
463 Network Segments (Sector, eNodeB (eNB) etc.). This information is
464 used as Key Performance Indicators (KPIs) and for the estimation of
465 User/Service Key Quality Indicators at network edges for circuit
466 emulation (CEM) as well as input for mitigation methods. If the
467 make-up of active services per user and per sector are not visible to
468 a server that provides Internet Access Point Names (APN), it cannot
469 perform mitigation functions based on network segment view.
471 It is important to note that the push for encryption by application
472 providers has been motivated by the application of the described
473 techniques. Although network operators have noted performance
474 improvements with network-based optimization or enhancement of user
475 traffic (otherwise, deployment would not have occurred), application
476 providers have likewise noted some degraded performance and/or user
477 experience, and such cases may result in additional operator
478 troubleshooting. Further, encrypted application streams might avoid
479 outdated optimization or enhancement techniques, where they exist.
481 A gap exists for vendors where built-in diagnostics and
482 serviceability is not adequate to provide detailed logging and
483 debugging capabilities that, when possible, can access cleartext
484 network parameters. In addition to traditional logging and debugging
485 methods, packet tracing and inspection along the service path
486 provides operators the visibility to continue to diagnose problems
487 reported both internally and by their customers. Logging of service
488 path upon exit for routing overlay protocols will assist with policy
489 management and troubleshooting capabilities for traffic flows on
490 encrypted networks. Protocol trace logging and protocol data unit
491 (PDU) logging should also be considered to improve visibility to
492 monitor and troubleshoot application level traffic. Additional work
493 on this gap would assist network operators to better troubleshoot and
494 manage networks with increasing amounts of encrypted traffic.
496 2.1.3. Traffic Analysis Fingerprinting
498 Fingerprinting is used in traffic analysis and monitoring to identify
499 traffic streams that match certain patterns. This technique can be
500 used with both clear text or encrypted sessions. Some Distributed
501 Denial of Service (DDoS) prevention techniques at the network
502 provider level rely on the ability to fingerprint traffic in order to
503 mitigate the effect of this type of attack. Thus, fingerprinting may
504 be an aspect of an attack or part of attack countermeasures.
506 A common, early trigger for DDoS mitigation includes observing
507 uncharacteristic traffic volumes or sources; congestion; or
508 degradation of a given network or service. One approach to mitigate
509 such an attack involves distinguishing attacker traffic from
510 legitimate user traffic. The ability to examine layers and payloads
511 above transport provides an increased range of filtering
512 opportunities at each layer in the clear. If fewer layers are in the
513 clear, this means that there are reduced filtering opportunities
514 available to mitigate attacks. However, fingerprinting is still
515 possible.
517 Passive monitoring of network traffic can lead to invasion of privacy
518 by external actors at the endpoints of the monitored traffic.
519 Encryption of traffic end-to-end is one method to obfuscate some of
520 the potentially identifying information. For example, browser
521 fingerprints are comprised of many characteristics, including User
522 Agent, HTTP Accept headers, browser plug-in details, screen size and
523 color details, system fonts and time zone. A monitoring system could
524 easily identify a specific browser, and by correlating other
525 information, identify a specific user.
527 2.2. Traffic Optimization and Management
529 2.2.1. Load Balancers
531 A standalone load balancer is a function one can take off the shelf,
532 place in front of a pool of servers, configure appropriately, and it
533 will balance the traffic load among servers in the pool. This is a
534 typical setup for load balancers. Standalone load balancers rely on
535 the plainly observable information in the packets they are forwarding
536 and rely on industry-accepted standards in interpreting the plainly
537 observable information. Typically, this is a 5-tuple of the
538 connection. This type of configuration terminates TLS sessions at
539 the load balancer, making it the end point instead of the server.
540 Standalone load balancers are considered middleboxes, but are an
541 integral part of server infrastructure that scales.
543 In contrast, an integrated load balancer is developed to be an
544 integral part of the service provided by the server pool behind that
545 load balancer. These load balancers can communicate state with their
546 pool of servers to better route flows to the appropriate servers.
547 They rely on non-standard system-specific information and operational
548 knowledge shared between the load balancer and its servers.
550 Both standalone and integrated load balancers can be deployed in
551 pools for redundancy and load sharing. For high availability, it is
552 important that when packets belonging to a flow start to arrive at a
553 different load balancer in the load balancer pool, the packets
554 continue to be forwarded to the original server in the server pool.
555 The importance of this requirement increases as the chances of such
556 load balancer change event increases.
558 Mobile operators deploy integrated load balancers to assist with
559 maintaining connection state as devices migrate. With the
560 proliferation of mobile connected devices, there is an acute need for
561 connection-oriented protocols that maintain connections after a
562 network migration by an endpoint. This connection persistence
563 provides an additional challenge for multi-homed anycast-based
564 services typically employed by large content owners and Content
565 Distribution Networks (CDNs). The challenge is that a migration to a
566 different network in the middle of the connection greatly increases
567 the chances of the packets routed to a different anycast point-of-
568 presence (POP) due to the new network's different connectivity and
569 Internet peering arrangements. The load balancer in the new POP,
570 potentially thousands of miles away, will not have information about
571 the new flow and would not be able to route it back to the original
572 POP.
574 To help with the endpoint network migration challenges, anycast
575 service operations are likely to employ integrated load balancers
576 that, in cooperation with their pool servers, are able to ensure that
577 client-to-server packets contain some additional identification in
578 plainly-observable parts of the packets (in addition to the 5-tuple).
579 As noted in Section 2 of [RFC7258], careful consideration in protocol
580 design to mitigate PM is important, while ensuring manageability of
581 the network.
583 Current protocols, such as TCP, allow the development of stateless
584 integrated load balancers by availing such load balancers of
585 additional plain text information in client-to-server packets. In
586 case of TCP, such information can be encoded by having server-
587 generated sequence numbers (that are ACK'd by the client), segment
588 values, lengths of the packet sent, etc. The use of some of these
589 mechanisms for load balancing negates some of the security
590 assumptions associated with those primitives (e.g., that an off-path
591 attacker guessing valid sequence numbers for a flow is hard).
592 Another possibility is a dedicated mechanism for storing load
593 balancer state, such as QUIC's proposed connection ID to provide
594 visibility to the load balancer. An identifier could be used for
595 tracking purposes, but this may provide an option that is an
596 improvement from bolting it on to an unrelated transport signal.
597 This method allows for tight control by one of the endpoints and can
598 be rotated to avoid roving client linkability: in other words, being
599 a specific, separate signal, it can be governed in a way that is
600 finely targeted at that specific use-case.
602 Some integrated load balancers have the ability to use additional
603 plainly observable information even for today's protocols that are
604 not network migration tolerant. This additional information allows
605 for improved availability and scaleability of the load balancing
606 operation. For example, BGP reconvergence can cause a flow to switch
607 anycast POPs even without a network change by any endpoint.
608 Additionally, a system that is able to encode the identity of the
609 pool server in plain text information available in each incoming
610 packet is able to provide stateless load balancing. This ability
611 confers great reliability and scaleability advantages even if the
612 flow remains in a single POP, because the load balancing system is
613 not required to keep state of each flow. Even more importantly,
614 there's no requirement to continuously synchronize such state among
615 the pool of load balancers. An integrated load balancer repurposing
616 limited existing bits in transport flow state must maintain and
617 synchronize per-flow state occasionally: using the sequence number as
618 a cookie only works for so long given that there aren't that many
619 bits available to divide across a pool of machines.
621 Mobile operators apply Self Organizing Networks (3GPP SON) for
622 intelligent workflows such as content-aware MLB (Mobility Load
623 Balancing). Where network load balancers have been configured to
624 route according to application-layer semantics, an encrypted payload
625 is effectively invisible. This has resulted in practices of
626 intercepting TLS in front of load balancers to regain that
627 visibility, but at a cost to security and privacy.
629 In future Network Function Virtualization (NFV) architectures, load
630 balancing functions are likely to be more prevalent (deployed at
631 locations throughout operators' networks). NFV environments will
632 require some type of identifier (IPv6 flow identifiers, the proposed
633 QUIC connection ID, etc.) for managing traffic using encrypted
634 tunnels. The shift to increased encryption will have an impact to
635 visibility of flow information and will require adjustments to
636 perform similar load balancing functions within an NFV.
638 2.2.2. Differential Treatment based on Deep Packet Inspection (DPI)
640 Data transfer capacity resources in cellular radio networks tend to
641 be more constrained than in fixed networks. This is a result of
642 variance in radio signal strength as a user moves around a cell, the
643 rapid ingress and egress of connections as users hand off between
644 adjacent cells, and temporary congestion at a cell. Mobile networks
645 alleviate this by queuing traffic according to its required bandwidth
646 and acceptable latency: for example, a user is unlikely to notice a
647 20ms delay when receiving a simple Web page or email, or an instant
648 message response, but will very likely notice a re-buffering pause in
649 a video playback or a VoIP call de-jitter buffer. Ideally, the
650 scheduler manages the queue so that each user has an acceptable
651 experience as conditions vary, but inferences of the traffic type
652 have been used to make bearer assignments and set scheduler priority.
654 Deep Packet Inspection (DPI) allows identification of applications
655 based on payload signatures, in contrast to trusting well-known port
656 numbers. Application and transport layer encryption make the traffic
657 type estimation more complex and less accurate, and therefore it may
658 not be effectual to use this information as input for queue
659 management. With the use of WebSockets [RFC6455], for example, many
660 forms of communications (from isochronous/real-time to bulk/elastic
661 file transfer) will take place over HTTP port 80 or port 443, so only
662 the messages and higher-layer data will make application
663 differentiation possible. If the monitoring system sees only "HTTP
664 port 443", it cannot distinguish application streams that would
665 benefit from priority queueing from others that would not.
667 Mobile networks especially rely on content/application based
668 prioritization of Over-the-Top (OTT) services - each application-type
669 or service has different delay/loss/throughput expectations, and each
670 type of stream will be unknown to an edge device if encrypted; this
671 impedes dynamic-QoS adaptation. An alternate way to achieve
672 encrypted application separation is possible when the User Equipment
673 (UE) requests a dedicated bearer for the specific application stream
674 (known by the UE), using a mechanism such as the one described in
675 Section 6.5 of 3GPP TS 24.301 [TS3GPP]. The UE's request includes
676 the Quality Class Indicator (QCI) appropriate for each application,
677 based on their different delay/loss/throughput expectations.
678 However, UE requests for dedicated bearers and QCI may not be
679 supported at the subscriber's service level, or in all mobile
680 networks.
682 These effects and potential alternative solutions have been discussed
683 at the accord BoF [ACCORD] at IETF95.
685 This section does not consider traffic discrimination by service
686 providers related to NetNeutrality, where traffic may be favored
687 according to the service provider preference as opposed to the user's
688 preference. These use cases are considered out-of-scope for this
689 document as contreversial practices.
691 2.2.3. Network Congestion Management
693 For User Plane Congestion Management (3GPP UPCON) [UPCON], the
694 ability to understand content and manage networks during periods of
695 congestion is the focus of this 3GPP work item. Mitigating
696 techniques such as deferred download, off-peak acceleration, and
697 outbound roamers are a few examples of the areas explored in the
698 associated 3GPP documents. The documents describe the issues, the
699 data utilized in managing congestion, and make policy
700 recommendations.
702 2.2.4. Performance-enhancing Proxies
704 Performance-enhancing TCP proxies may perform local retransmission at
705 the network edge; this also applies to mobile networks. In TCP,
706 duplicated ACKs are detected and potentially concealed when the proxy
707 retransmits a segment that was lost on the mobile link without
708 involvement of the far end (see section 2.1.1 of [RFC3135] and
709 section 3.5 of [I-D.dolson-plus-middlebox-benefits]).
711 This optimization at network edges measurably improves real-time
712 transmission over long delay Internet paths or networks with large
713 capacity-variation (such as mobile/cellular networks). However, such
714 optimizations can also cause problems with performance, for example
715 if the characteristics of some packet streams begin to vary
716 significantly from those considered in the proxy design.
718 In general, performance-enhancing proxies have a lower Round-Trip
719 Time (RTT) to the client and therefore determine the responsiveness
720 of flow control. A lower RTT makes the flow control loop more
721 responsive to changes in the mobile network conditions and enables
722 faster adaptation in a delay and capacity varying network due to user
723 mobility.
725 Further, service-provider-operated proxies are used to reduce the
726 control delay between the sender and a receiver on a mobile network
727 where resources are limited. The RTT determines how quickly a user's
728 attempt to cancel a video is recognized and therefore how quickly the
729 traffic is stopped, thus keeping un-wanted video packets from
730 entering the radio scheduler queue. If impacted by encryption,
731 performance enhancing proxies could make use of routing overlay
732 protocols to accomplish the same task, but this results in additional
733 overhead.
735 An application-type-aware network edge (middlebox) can further
736 control pacing, limit simultaneous HD videos, or prioritize active
737 videos against new videos, etc. Services at this more granular level
738 are limited with the use of encryption.
740 2.2.5. Caching and Content Replication Near the Network Edge
742 The features and efficiency of some Internet services can be
743 augmented through analysis of user flows and the applications they
744 provide. For example, network caching of popular content at a
745 location close to the requesting user can improve delivery efficiency
746 (both in terms of lower request response times and reduced use of
747 International Internet links when content is remotely located), and
748 authorized parties acting on their behalf use DPI in combination with
749 content distribution networks to determine if they can intervene
750 effectively. Encryption of packet contents at a given protocol layer
751 usually makes DPI processing of that layer and higher layers
752 impossible. That being said, it should be noted that some content
753 providers prevent caching to control content delivery through the use
754 of encrypted end-to-end sessions. CDNs vary in their deployment
755 options of end-to-end encryption. The business risk of losing
756 control of content is a motivation outside of privacy and pervasive
757 monitoring that are driving end-to-end encryption for these content
758 providers.
760 It should be noted that caching was first supported in [RFC1945] and
761 continued in the recent update of "Hypertext Transfer Protocol
762 (HTTP/1.1): Caching" in [RFC7234].
764 Content replication in caches (for example live video, Digital Rights
765 Management (DRM) protected content) is used to most efficiently
766 utilize the available limited bandwidth and thereby maximize the
767 user's Quality of Experience (QoE). Especially in mobile networks,
768 duplicating every stream through the transit network increases
769 backhaul cost for live TV. The Enhanced Multimedia Broadcast/
770 Multicast Services (3GPP eMBMS) utilizes trusted edge proxies to
771 facilitate delivering the same stream to different users, using
772 either unicast or multicast depending on channel conditions to the
773 user. There are on-going efforts to support multicast inside carrier
774 networks while preserving end-to-end security: Automatic Multicast
775 Tunneling (AMT), for instance, allows CDNs to deliver a single
776 (potentially encrypted) copy of a live stream to a carrier network
777 over the public internet and for the carrier to then distribute that
778 live stream as efficiently as possible within its own network using
779 multicast.
781 Alternate approaches are in the early phase of being explored to
782 allow caching of encrypted content. These solutions require
783 cooperation from content owners and fall outside the scope of what is
784 covered in this document. Content delegation allows for replication
785 with possible benefits, but any form of delegation has the potential
786 to affect the expectation of client-server confidentiality.
788 2.2.6. Content Compression
790 In addition to caching, various applications exist to provide data
791 compression in order to conserve the life of the user's mobile data
792 plan or make delivery over the mobile link more efficient. The
793 compression proxy access can be built into a specific user level
794 application, such as a browser, or it can be available to all
795 applications using a system level application. The primary method is
796 for the mobile application to connect to a centralized server as a
797 transparent proxy (user does not opt-in), with the data channel
798 between the client application and the server using compression to
799 minimize bandwidth utilization. The effectiveness of such systems
800 depends on the server having access to unencrypted data flows.
802 Aggregated data stream content compression that spans objects and
803 data sources that can be treated as part of a unified compression
804 scheme (e.g., through the use of a shared segment store) is often
805 effective at providing data offload when there is a network element
806 close to the receiver that has access to see all the content.
808 2.2.7. Service Function Chaining
810 There is work in progress to specify protocols that permit Service
811 Function Chaining (SFC). SFC is the ordered steering and application
812 of traffic in order to provide optimizations, and a Classifier
813 [RFC7665] performs this function. If the classifier's visibility is
814 reduced from a 5-tuple to a 2-tuple, or if information above the
815 transport layer becomes unaccessible, then the SFC Classifier will
816 not be able to perform its job and the service functions of the path
817 may be adversely affected.
819 There are also mechanisms provided to protect security and privacy.
820 In the SFC case, the layer below a network service header can be
821 protected with session encryption. A goal is protecting end-user
822 data, while retaining the intended functions of RFC7665 at the same time.
825 2.3. Content Filtering, Network Access, and Accounting
827 Mobile Networks and many ISPs operate under the regulations of their
828 licensing government authority. These regulations include Lawful
829 Intercept, adherence to Codes of Practice on content filtering, and
830 application of court order filters. Such regulations assume network
831 access to provide content filtering and accounting, as discussed
832 below. As previously stated, the intent of this document is to
833 document existing practices; the development of IETF protocols
834 follows the guiding principles of [RFC1984] and [RFC2804] and
835 explicitly do not support tools and methods that could be used for
836 wiretapping and censorship.
838 2.3.1. Content Filtering
840 There are numerous reasons why service providers might block content:
841 to comply with requests from law enforcement or regulatory
842 authorities, to effectuate parental controls, to enforce content-
843 based billing, or for other reasons, possibly considered
844 inappropriate by some. See RFC7754 [RFC7754] for a survey of
845 Internet filtering techniques and motivations and the IAB consensus
846 on those mechanisms. This section is intended to document a
847 selection of current content blocking practices by operators and the
848 effects of encryption on those practices. Content blocking may also
849 happen at endpoints or at the edge of enterprise networks, but those
850 are not addressed in this section.
852 In a mobile network content filtering usually occurs in the core
853 network. With other networks, content filtering could occur in the
854 core network or at the edge. A proxy is installed which analyses the
855 transport metadata of the content users are viewing and either
856 filters content based on a blacklist of sites or based on the user's
857 pre-defined profile (e.g. for age sensitive content). Although
858 filtering can be done by many methods, one commonly used method
859 involves a trigger based on the proxy identifying a DNS lookup of a
860 host name in a URL which appears on a blacklist being used by the
861 operator. The subsequent requests to that domain will be re-routed
862 to a proxy which checks whether the full URL matches a blocked URL on
863 the list, and will return a 404 if a match is found. All other
864 requests should complete. This technique does not work in situations
865 where DNS traffic is encrypted (e.g., by employing [RFC7858] ). This
866 method is also used by other types of network providers enabling
867 traffic inspection, but not modification.
869 Content filtering via a proxy can also utilize an intercepting
870 certificate where the client's session is terminated at the proxy
871 enabling for cleartext inspection of the traffic. A new session is
872 created from the intercepting device to the client's destination;
873 this is an opt-in strategy for the client, where the endpoint is
874 configured to trust the intercepting certificate. Changes to TLSv1.3
875 do not impact this more invasive method of interception, that has the
876 potential to expose every HTTPS session to an active man in the
877 middle (MitM).
879 Another form of content filtering is called parental control, where
880 some users are deliberately denied access to age-sensitive content as
881 a feature to the service subscriber. Some sites involve a mixture of
882 universal and age-sensitive content and filtering software. In these
883 cases, more granular (application layer) metadata may be used to
884 analyze and block traffic. Methods that accessed cleartext
885 application-layer metadata no longer work when sessions are
886 encrypted. This type of granular filtering could occur at the
887 endpoint or as a proxy service. However, the lack of ability to
888 efficiently manage endpoints as a service reduces providers' ability
889 to offer parental control.
891 2.3.2. Network Access and Data Usage
893 Approved access to a network is a prerequisite to requests for
894 Internet traffic.
896 However, there are cases (beyond parental control) when a network
897 service provider currently redirects customer requests for content
898 (affecting content accessibility):
900 1. The network service provider is performing the accounting and
901 billing for the content provider, and the customer has not (yet)
902 purchased the requested content.
904 2. Further content may not be allowed as the customer has reached
905 their usage limit and needs to purchase additional data service,
906 which is the usual billing approach in mobile networks.
908 Currently, some network service providers redirect the customer using
909 HTTP redirect to a captive portal page that explains to those
910 customers the reason for the blockage and the steps to proceed.
911 [RFC6108] describes one viable web notification system. When the
912 HTTP headers and content are encrypted, this appropriately prevents
913 mobile carriers from intercepting the traffic and performing an HTTP
914 redirect. As a result, some mobile carriers block customer's
915 encrypted requests, which is a far less optimal customer experience
916 because the blocking reason must be conveyed by some other means.
917 The customer may need to call customer care to find out the reason
918 and/or resolve the issue, possibly extending the time needed to
919 restore their network access. While there are well deployed
920 alternate SMS-based solutions that do not involve out of
921 specification protocol interception, this is still an unsolved
922 problem for non-SMS users.
924 Further, when the requested service is about to consume the remainder
925 of the user's plan limits, the transmission could be terminated and
926 advance notifications may be sent to the user by their service
927 provider to warn the user ahead of the exhausted plan. If web
928 content is encrypted, the network provider cannot know the data
929 transfer size at request time. Lacking this visibility of the
930 application type and content size, the network would continue the
931 transmission and stop the transfer when the limit was reached. A
932 partial transfer may not be usable by the client wasting both network
933 and user resources, possibly leading to customer complaints. The
934 content provider does not know user's service plans or current usage,
935 and cannot warn the user of plan exhaustion.
937 In addition, mobile network operator often sell tariffs that allow
938 free-data access to certain sites, known as 'zero rating'. A session
939 to visit such a site incurs no additional cost or data usage to the
940 user. For some implementations, zero rating is impacted if
941 encryption hides the details of the content domain from the network.
943 2.3.3. Application Layer Gateways
945 Application Layer Gateways (ALG) assist applications to set
946 connectivity across Network Address Translators (NAT), Firewalls,
947 and/or Load Balancers for specific applications running across mobile
948 networks. Section 2.9 of [RFC2663] describes the role of ALGs and
949 their interaction with NAT and/or application payloads. ALG are
950 deployed with an aim to improve connectivity. However, it is an IETF
951 Best Common Practice recommendation that ALGs for UDP-based protocols
952 should be turned off [RFC4787].
954 One example of an ALG in current use is aimed at video applications
955 that use the Real Time Session Protocol (RTSP) [RFC7826] primary
956 stream as a means to identify related Real Time Protocol/Real Time
957 Control Protocol (RTP/RTCP) [RFC3550] flows at set-up. The ALG in
958 this case relies on the 5-tuple flow information derived from RTSP to
959 provision NAT or other middleboxes and provide connectivity.
960 Implementations vary, and two examples follow:
962 1. Parse the content of the RTSP stream and identify the 5-tuple of
963 the supporting streams as they are being negotiated.
965 2. Intercept and modify the 5-tuple information of the supporting
966 media streams as they are being negotiated on the RTSP stream,
967 which is more intrusive to the media streams.
969 When RTSP stream content is encrypted, the 5-tuple information within
970 the payload is not visible to these ALG implementations, and
971 therefore they cannot provision their associated middelboxes with
972 that information.
974 The deployment of IPv6 may well reduce the need for NAT, and the
975 corresponding requirement for Application Layer Gateways.
977 2.3.4. HTTP Header Insertion
979 Some mobile carriers use HTTP header insertion (see section 3.2.1 of
980 [RFC7230]) to provide information about their customers to third
981 parties or to their own internal systems [Enrich]. Third parties use
982 the inserted information for analytics, customization, advertising,
983 cross-site tracking of users, to bill the customer, or to selectively
984 allow or block content. HTTP header insertion is also used to pass
985 information internally between a mobile service provider's sub-
986 systems, thus keeping the internal systems loosely coupled. When
987 HTTP connections are encrypted to protect users privacy, mobile
988 network service providers cannot insert headers to accomplish the,
989 sometimes considered controversial, functions above.
991 Guidance from the Internet Architecture Board has been provided in
992 RFC8165 [RFC8165] on Design Considerations for Metadata Insertion.
993 The guidance asserts that designs that share metadata only by
994 explicit actions at the host are preferable to designs in which
995 middleboxes insert metadata. Alternate notification methods that
996 follow this and other guidance would be helpful to mobile carriers.
998 3. Encryption in Hosting and Application SP Environments
1000 Hosted environments have had varied requirements in the past for
1001 encryption, with many businesses choosing to use these services
1002 primarily for data and applications that are not business or privacy
1003 sensitive. A shift prior to the revelations on surveillance/passive
1004 monitoring began where businesses were asking for hosted environments
1005 to provide higher levels of security so that additional applications
1006 and service could be hosted externally. Businesses understanding the
1007 threats of monitoring in hosted environments increased that pressure
1008 to provide more secure access and session encryption to protect the
1009 management of hosted environments as well as for the data and
1010 applications.
1012 3.1. Management Access Security
1014 Hosted environments may have multiple levels of management access,
1015 where some may be strictly for the Hosting SP (infrastructure that
1016 may be shared among customers) and some may be accessed by a specific
1017 customer for application management. In some cases, there are
1018 multiple levels of hosting service providers, further complicating
1019 the security of management infrastructure and the associated
1020 requirements.
1022 Hosting service provider management access is typically segregated
1023 from other traffic with a control channel and may or may not be
1024 encrypted depending upon the isolation characteristics of the
1025 management session. Customer access may be through a dedicated
1026 connection, but discussion for that connection method is out-of-scope
1027 for this document.
1029 In overlay networks (e.g. VXLAN, Geneve, etc.) that are used to
1030 provide hosted services, management access for a customer to support
1031 application management may depend upon the security mechanisms
1032 available as part of that overlay network. While overlay network
1033 data encapsulations may be used to indicate the desired isolation,
1034 this is not sufficient to prevent deliberate attacks that are aware
1035 of the use of the overlay network.
1036 [I-D.mglt-nvo3-geneve-security-requirements] describes requirements
1037 to handle attacks. It is possible to use an overlay header in
1038 combination with IPsec or other encrypted traffic sessions, but this
1039 adds the requirement for authentication infrastructure and may reduce
1040 packet transfer performance. The use of an overlay header may also
1041 be deployed as a mechanism to manage encrypted traffic streams on the
1042 network by network service providers. Additional extension
1043 mechanisms to provide integrity and/or privacy protections are being
1044 investigated for overlay encapsulations. Section 7 of [RFC7348]
1045 describes some of the security issues possible when deploying VXLAN
1046 on Layer 2 networks. Rogue endpoints can join the multicast groups
1047 that carry broadcast traffic, for example.
1049 3.1.1. Customer Access Monitoring
1051 Hosted applications that allow some level of customer management
1052 access may also require monitoring by the hosting service provider.
1053 Monitoring could include access control restrictions such as
1054 authentication, authorization, and accounting for filtering and
1055 firewall rules to ensure they are continuously met. Customer access
1056 may occur on multiple levels, including user-level and administrative
1057 access. The hosting service provider may need to monitor access
1058 either through session monitoring or log evaluation to ensure
1059 security service level agreements (SLA) for access management are
1060 met. The use of session encryption to access hosted environments
1061 limits access restrictions to the metadata described below.
1062 Monitoring and filtering may occur at an:
1064 2-tuple IP-level with source and destination IP addresses alone, or
1066 5-tuple IP and protocol-level with source IP address, destination IP
1067 address, protocol number, source port number, and destination port
1068 number.
1070 Session encryption at the application level, TLS for example,
1071 currently allows access to the 5-tuple. IP-level encryption, such as
1072 IPsec in tunnel mode prevents access to the original 5-tuple and may
1073 limit the ability to restrict traffic via filtering techniques. This
1074 shift may not impact all hosting service provider solutions as
1075 alternate controls may be used to authenticate sessions or access may
1076 require that clients access such services by first connecting to the
1077 organization before accessing the hosted application. Shifts in
1078 access may be required to maintain equivalent access control
1079 management. Logs may also be used for monitoring that access control
1080 restrictions are met, but would be limited to the data that could be
1081 observed due to encryption at the point of log generation. Log
1082 analysis is out of scope for this document.
1084 3.1.2. SP Content Monitoring of Applications
1086 The following observations apply to any IT organization that is
1087 responsible for delivering services, whether to third-parties, for
1088 example as a web based service, or to internal customers in an
1089 enterprise, e.g. a data processing system that forms a part of the
1090 enterprise's business.
1092 Organizations responsible for the operation of a data center have
1093 many processes which access the contents of IP packets (passive
1094 methods of measurement, as defined in [RFC7799]). These processes
1095 are typically for service assurance or security purposes as part of
1096 their data center operations.
1098 Examples include:
1100 - Network Performance Monitoring/Application Performance
1101 Monitoring
1102 - Intrusion defense/prevention systems
1104 - Malware detection
1106 - Fraud Monitoring
1108 - Application DDOS protection
1110 - Cyber-attack investigation
1112 - Proof of regulatory compliance
1114 - Data Leakage Prevention
1116 Many application service providers simply terminate sessions to/from
1117 the Internet at the edge of the data center in the form of SSL/TLS
1118 offload in the load balancer. Not only does this reduce the load on
1119 application servers, it simplifies the processes to enable monitoring
1120 of the session content.
1122 However, in some situations, encryption deeper in the data center may
1123 be necessary to protect personal information or in order to meet
1124 industry regulations, e.g. those set out by the Payment Card Industry
1125 (PCI). In such situations, various methods have been used to allow
1126 service assurance and security processes to access unencrypted data.
1127 These include SSL/TLS decryption in dedicated units, which then
1128 forward packets to SP-controlled tools, or by real-time or post-
1129 capture decryption in the tools themselves. The use of tools that
1130 perform SSL/TLS decryption are impacted by the increased use of
1131 encryption that prevents interception.
1133 Data center operators may also maintain packet recordings in order to
1134 be able to investigate attacks, breach of internal processes, etc.
1135 In some industries, organizations may be legally required to maintain
1136 such information for compliance purposes. Investigations of this
1137 nature have used access to the unencrypted contents of the packet.
1138 Alternate methods to investigate attacks or breach of process will
1139 rely on endpoint information, such as logs. As previously noted,
1140 logs often lack complete information, and this is seen as a concern
1141 resulting in some relying on session access for additional
1142 information.
1144 Application Service Providers may offer content-level monitoring
1145 options to detect intellectual property leakage, or other attacks.
1146 In service provider environments where Data Loss Prevention (DLP) has
1147 been implemented on the basis of the service provider having
1148 cleartext access to session streams, the use of encrypted streams
1149 prevents these implementations from conducting content searches for
1150 the keywords or phrases configured in the DLP system. DLP is often
1151 used to prevent the leakage of Personally Identifiable Information
1152 (PII) as well as financial account information, Personal Health
1153 Information (PHI), and Payment Card Information (PCI). If session
1154 encryption is terminated at a gateway prior to accessing these
1155 services, DLP on session data can still be performed. The decision
1156 of where to terminate encryption to hosted environments will be a
1157 risk decision made between the application service provider and
1158 customer organization according to their priorities. DLP can be
1159 performed at the server for the hosted application and on an end
1160 user's system in an organization as alternate or additional
1161 monitoring points of content; however, this is not frequently done in
1162 a service provider environment.
1164 Application service providers, by their very nature, control the
1165 application endpoint. As such, much of the information gleaned from
1166 sessions are still available on that endpoint. However, when a gap
1167 exists in the application's logging and debugging capabilities, this
1168 has led the application service provider to access data-in-transport
1169 for monitoring and debugging.
1171 3.2. Hosted Applications
1173 Organizations are increasingly using hosted applications rather than
1174 in-house solutions that require maintenance of equipment and
1175 software. Examples include Enterprise Resource Planning (ERP)
1176 solutions, payroll service, time and attendance, travel and expense
1177 reporting among others. Organizations may require some level of
1178 management access to these hosted applications and will typically
1179 require session encryption or a dedicated channel for this activity.
1181 In other cases, hosted applications may be fully managed by a hosting
1182 service provider with service level agreement expectations for
1183 availability and performance as well as for security functions
1184 including malware detection. Due to the sensitive nature of these
1185 hosted environments, the use of encryption is already prevalent. Any
1186 impact may be similar to an enterprise with tools being used inside
1187 of the hosted environment to monitor traffic. Additional concerns
1188 were not reported in the call for contributions.
1190 3.2.1. Monitoring Managed Applications
1192 Performance, availability, and other aspects of a SLA are often
1193 collected through passive monitoring. For example:
1195 o Availability: ability to establish connections with hosts to
1196 access applications, and discern the difference between network or
1197 host-related causes of unavailability.
1199 o Performance: ability to complete transactions within a target
1200 response time, and discern the difference between network or host-
1201 related causes of excess response time.
1203 Here, as with all passive monitoring, the accuracy of inferences are
1204 dependent on the cleartext information available, and encryption
1205 would tend to reduce the information and therefore, the accuracy of
1206 each inference. Passive measurement of some metrics will be
1207 impossible with encryption that prevents inferring packet
1208 correspondence across multiple observation points, such as for packet
1209 loss metrics.
1211 Application logging currently lacks detail sufficient to make
1212 accurate inferences in an environment with increased encryption, and
1213 so this constitutes a gap for passive performance monitoring (which
1214 could be closed if log details are enhanced in the future).
1216 3.2.2. Mail Service Providers
1218 Mail (application) service providers vary in what services they
1219 offer. Options may include a fully hosted solution where mail is
1220 stored external to an organization's environment on mail service
1221 provider equipment or the service offering may be limited to monitor
1222 incoming mail to remove spam [Section 5.1], malware [Section 5.6],
1223 and phishing attacks [Section 5.3] before mail is directed to the
1224 organization's equipment. In both of these cases, content of the
1225 messages and headers is monitored to detect spam, malware, phishing,
1226 and other messages that may be considered an attack.
1228 STARTTLS should have zero effect on anti-spam efforts for SMTP
1229 traffic. Anti-spam services could easily be performed on an SMTP
1230 gateway, eliminating the need for TLS decryption services. The
1231 impact to anti-spam service providers should be limited to a change
1232 in tools, where middleboxes were deployed to perform these functions.
1234 Many efforts are emerging to improve user-to-user encryption,
1235 including promotion of PGP and newer efforts such as Dark Mail
1236 [DarkMail]. Of course, content-based spam filtering will not be
1237 possible on encrypted content.
1239 3.3. Data Storage
1241 Numerous service offerings exist that provide hosted storage
1242 solutions. This section describes the various offerings and details
1243 the monitoring for each type of service and how encryption may impact
1244 the operational and security monitoring performed.
1246 Trends in data storage encryption for hosted environments include a
1247 range of options. The following list is intentionally high-level to
1248 describe the types of encryption used in coordination with data
1249 storage that may be hosted remotely, meaning the storage is
1250 physically located in an external data center requiring transport
1251 over the Internet. Options for monitoring will vary with each
1252 encryption approach described below. In most cases, solutions have
1253 been identified to provide encryption while ensuring management
1254 capabilities were maintained through logging or other means.
1256 3.3.1. Object-level Encryption
1258 For higher security and/or privacy of data and applications, options
1259 that provide end-to-end encryption of the data from the user's
1260 desktop or server to the storage platform may be preferred. This
1261 description includes any solution that encrypts data at the object
1262 level, not transport level. Encryption of data may be performed with
1263 libraries on the system or at the application level, which includes
1264 file encryption services via a file manager. Object-level encryption
1265 is useful when data storage is hosted, or scenarios when the storage
1266 location is determined based on capacity or based on a set of
1267 parameters to automate decisions. This could mean that large data
1268 sets accessed infrequently could be sent to an off-site storage
1269 platform at an external hosting service, data accessed frequently may
1270 be stored locally, or the decision could be based on the transaction
1271 type. Object-level encryption is grouped separately for the purpose
1272 of this document since data may be stored in multiple locations
1273 including off-site remote storage platforms. If session encryption
1274 is also used, the protocol is likely to be TLS.
1276 Impacts to monitoring may include access to content inspection for
1277 data leakage prevention and similar technologies, depending on their
1278 placement in the network.
1280 3.3.1.1. Monitoring for Hosted Storage
1282 Monitoring of hosted storage solutions that use host-level (object)
1283 encryption is described in this subsection. Host-level encryption
1284 can be employed for backup services, and occasionally for external
1285 storage services (operated by a third party) when internal storage
1286 limits are exceeded.
1288 Monitoring of data flows to hosted storage solutions is performed for
1289 security and operational purposes. The security monitoring may be to
1290 detect anomalies in the data flows that could include changes to
1291 destination, the amount of data transferred, or alterations in the
1292 size and frequency of flows. Operational considerations include
1293 capacity and availability monitoring.
1295 3.3.2. Disk Encryption, Data at Rest
1297 There are multiple ways to achieve full disk encryption for stored
1298 data. Encryption may be performed on data to be stored while in
1299 transit close to the storage media with solutions like Controller
1300 Based Encryption (CBE) or in the drive system with Self-Encrypting
1301 Drives (SED). Session encryption is typically coupled with
1302 encryption of these data at rest (DAR) solutions to also protect data
1303 in transit. Transport encryption is likely via TLS.
1305 3.3.2.1. Monitoring Session Flows for Data at Rest (DAR) Solutions
1307 Monitoring for transport of data to storage platforms, where object
1308 level encryption is performed close to or on the storage platform are
1309 similar to those described in the section on Monitoring for Hosted
1310 Storage. The primary difference for these solutions is the possible
1311 exposure of sensitive information, which could include privacy
1312 related data, financial information, or intellectual property if
1313 session encryption via TLS is not deployed. Session encryption is
1314 typically used with these solutions, but that decision would be based
1315 on a risk assessment. There are use cases where DAR or disk-level
1316 encryption is required. Examples include preventing exposure of data
1317 if physical disks are stolen or lost. In the case where TLS is in
1318 use, monitoring and the exposure of data is limited to a 5-tuple.
1320 3.3.3. Cross Data Center Replication Services
1322 Storage services also include data replication which may occur
1323 between data centers and may leverage Internet connections to tunnel
1324 traffic. The traffic may use iSCSI [RFC7143] or FC/IP [RFC7146]
1325 encapsulated in IPsec. Either transport or tunnel mode may be used
1326 for IPsec depending upon the termination points of the IPsec session,
1327 if it is from the storage platform itself or from a gateway device at
1328 the edge of the data center respectively.
1330 3.3.3.1. Monitoring Of IPsec for Data Replication Services
1332 Monitoring of data flows between data centers (for data replication)
1333 may be performed for security and operational purposes and would
1334 typically concentrate more on operational aspects since these flows
1335 are essentially virtual private networks (VPN) between data centers.
1336 Operational considerations include capacity and availability
1337 monitoring. The security monitoring may be to detect anomalies in
1338 the data flows, similar to what was described in the "Monitoring for
1339 Hosted Storage Section". If IPsec tunnel mode is in use, monitoring
1340 is limited to a 2-tuple, or with transport mode, a 5-tuple.
1342 4. Encryption for Enterprises
1344 Encryption of network traffic within the private enterprise is a
1345 growing trend, particularly in industries with audit and regulatory
1346 requirements. Some enterprise internal networks are almost
1347 completely TLS and/or IPsec encrypted.
1349 For each type of monitoring, different techniques and access to parts
1350 of the data stream are part of current practice. As we transition to
1351 an increased use of encryption, alternate methods of monitoring for
1352 operational purposes may be necessary to reduce the practice of
1353 breaking encryption (other policies may apply in some enterprise
1354 settings).
1356 4.1. Monitoring Practices of the Enterprise
1358 Large corporate enterprises are the owners of the platforms, data,
1359 and network infrastructure that provide critical business services to
1360 their user communities. As such, these enterprises are responsible
1361 for all aspects of the performance, availability, security, and
1362 quality of experience for all user sessions. Users typically sign
1363 agreements acknowledging that they are subject to monitoring while
1364 operating on corporate networks. Subsections of 4. Encryption for
1365 Enterprises may discuss techniques that access data beyond the data-
1366 link, network, and transport level headers typically used in SP
1367 networks since the corporate enterprise owns the data. These
1368 responsibilities break down into three basic areas:
1370 1. Security Monitoring and Control
1372 2. Application Performance Monitoring and Reporting
1374 3. Network Diagnostics and Troubleshooting
1376 In each of the above areas, technical support teams utilize
1377 collection, monitoring, and diagnostic systems. Some organizations
1378 currently use attack methods such as replicated TLS server RSA
1379 private keys to decrypt passively monitored copies of encrypted TLS
1380 packet streams.
1382 For an enterprise to avoid costly application down time and deliver
1383 expected levels of performance, protection, and availability, some
1384 forms of traffic analysis, sometimes including examination of packet
1385 payloads, are currently used.
1387 4.1.1. Security Monitoring in the Enterprise
1389 Enterprise users are subject to the policies of their organization
1390 and the jurisdictions in which the enterprise operates. As such,
1391 proxies may be in use to:
1393 1. intercept outbound session traffic to monitor for intellectual
1394 property leakage (by users, malware, and trojans),
1396 2. detect viruses/malware entering the network via email or web
1397 traffic,
1399 3. detect malware/Trojans in action, possibly connecting to remote
1400 hosts,
1402 4. detect attacks (Cross site scripting and other common web related
1403 attacks),
1405 5. track misuse and abuse by employees,
1407 6. restrict the types of protocols permitted to/from the entire
1408 corporate environment,
1410 7. detect and defend against Internet DDoS attacks, including both
1411 volumetric and layer 7 attacks.
1413 A significant portion of malware hides its activity within TLS or
1414 other encryption protocols. This includes lateral movement, Command
1415 and Control, and Data Exfiltration.
1417 The impact to a fully encrypted internal network would include cost
1418 and possible loss of detection capabilities associated with the
1419 transformation of the network architecture and tools for monitoring.
1420 The capabilities of detection through traffic fingerprinting, logs,
1421 host-level transaction monitoring, and flow analysis would vary
1422 depening on access to a 2-tuple or 5-tuple in the network as well.
1424 Security monitoring in the enterprise may also be performed at the
1425 endpoint with numerous current solutions that mitigate the same
1426 problems as some of the above mentioned solutions. Since the
1427 software agents operate on the device, they are able to monitor
1428 traffic before it is encrypted, monitor for behavior changes, and
1429 lock down devices to use only the expected set of applications.
1430 Session encryption does not affect these solutions. Some might argue
1431 that scaling is an issue in the enterprise, but some large
1432 enterprises have used these tools effectively.
1434 Use of Bring-your-own-device (BYOD) policies within organizations may
1435 limit the scope of monitoring permited with these alternate
1436 solutions. Network endpoint assessment (NEA) or the use of virtual
1437 hosts could help to bridge the monitoring gap.
1439 4.1.2. Application Performance Monitoring in the Enterprise
1441 There are two main goals of monitoring:
1443 1. Assess traffic volume on a per-application basis, for billing,
1444 capacity planning, optimization of geographical location for
1445 servers or proxies, and other goals.
1447 2. Assess performance in terms of application response time and user
1448 perceived response time.
1450 Network-based Application Performance Monitoring tracks application
1451 response time by user and by URL, which is the information that the
1452 application owners and the lines of business request. Content
1453 Delivery Networks (CDNs) add complexity in determining the ultimate
1454 endpoint destination. By their very nature, such information is
1455 obscured by CDNs and encrypted protocols -- adding a new challenge
1456 for troubleshooting network and application problems. URL
1457 identification allows the application support team to do granular,
1458 code level troubleshooting at multiple tiers of an application.
1460 New methodologies to monitor user perceived response time and to
1461 separate network from server time are evolving. For example, the
1462 IPv6 Destination Option Header (DOH) implementation of Performance
1463 and Diagnostic Metrics (PDM) will provide this [RFC8250]. Using PDM
1464 with IPsec Encapsulating Security Payload (ESP) Transport Mode
1465 requires placement of the PDM DOH within the ESP encrypted payload to
1466 avoid leaking timing and sequence number information that could be
1467 useful to an attacker. Use of PDM DOH also may introduce some
1468 security weaknesses, including a timing attack, as described in
1469 Section 7 of [RFC8250]. For these and other reasons, [RFC8250]
1470 requires that the PDM DOH option be explicitly turned on by
1471 administrative action in each host where this measurement feature
1472 will be used.
1474 4.1.3. Enterprise Network Diagnostics and Troubleshooting
1476 One primary key to network troubleshooting is the ability to follow a
1477 transaction through the various tiers of an application in order to
1478 isolate the fault domain. A variety of factors relating to the
1479 structure of the modern data center and multi-tiered application have
1480 made it difficult to follow a transaction in network traces without
1481 the ability to examine some of the packet payload. Alternate
1482 methods, such as log analysis need improvement to fill this gap.
1484 4.1.3.1. Address Sharing (NAT)
1486 Content Delivery Networks (CDNs) and NATs and Network Address and
1487 Port Translators (NAPT) obscure the ultimate endpoint designation
1488 (See [RFC6269] for types of address sharing and a list of issues).
1489 Troubleshooting a problem for a specific end user requires finding
1490 information such as the IP address and other identifying information
1491 so that their problem can be resolved in a timely manner.
1493 NAT is also frequently used by lower layers of the data center
1494 infrastructure. Firewalls, Load Balancers, Web Servers, App Servers,
1495 and Middleware servers all regularly NAT the source IP of packets.
1496 Combine this with the fact that users are often allocated randomly by
1497 load balancers to all these devices, the network troubleshooter is
1498 often left with very few options in today's environment due to poor
1499 logging implementations in applications. As such, network
1500 troubleshooting is used to trace packets at a particular layer,
1501 decrypt them, and look at the payload to find a user session.
1503 This kind of bulk packet capture and bulk decryption is frequently
1504 used when troubleshooting a large and complex application. Endpoints
1505 typically don't have the capacity to handle this level of network
1506 packet capture, so out-of-band networks of robust packet brokers and
1507 network sniffers that use techniques such as copies of TLS RSA
1508 private keys accomplish this task today.
1510 4.1.3.2. TCP Pipelining/Session Multiplexing
1512 TCP pipelining/session multiplexing used mainly by middleboxes today
1513 allows for multiple end user sessions to share the same TCP
1514 connection. This raises several points of interest with an increased
1515 use of encryption. TCP session multiplexing should still be possible
1516 when TLS or TCPcrypt is in use since the TCP header information is
1517 exposed leaving the 5-tuple accessible. The use of TCP session
1518 multiplexing of an IP layer encyption, e.g. IPsec, that only exposes
1519 a 2-tuple would not be possible. Troubleshooting capabilities with
1520 encrypted sessions from the middlebox may limit troubleshooting to
1521 the use of logs from the end points performing the TCP multiplexing
1522 or from the middleboxes prior to any additional encryption that may
1523 be added to tunnel the TCP multiplexed traffic.
1525 Increased use of HTTP/2 will likely further increase the prevalence
1526 of session multiplexing, both on the Internet and in the private data
1527 center. HTTP pipelining requires both the client and server to
1528 participate; visibility of packets once encrypted will hide the use
1529 of HTTP pipelining for any monitoring that takes place outside of the
1530 endpoint or proxy solution. Since HTTP pipelining is between a
1531 client and server, logging capabilities may require improvement in
1532 some servers and clients for debugging purposes if this is not
1533 already possible. Visibility for middleboxes includes anything
1534 exposed by TLS and the 5-tuple.
1536 4.1.3.3. HTTP Service Calls
1538 When an application server makes an HTTP service call to back end
1539 services on behalf of a user session, it uses a completely different
1540 URL and a completely different TCP connection. Troubleshooting via
1541 network trace involves matching up the user request with the HTTP
1542 service call. Some organizations do this today by decrypting the TLS
1543 packet and inspecting the payload. Logging has not been adequate for
1544 their purposes.
1546 4.1.3.4. Application Layer Data
1548 Many applications use text formats such as XML to transport data or
1549 application level information. When transaction failures occur and
1550 the logs are inadequate to determine the cause, network and
1551 application teams work together, each having a different view of the
1552 transaction failure. Using this troubleshooting method, the network
1553 packet is correlated with the actual problem experienced by an
1554 application to find a root cause. The inability to access the
1555 payload prevents this method of troubleshooting.
1557 4.2. Techniques for Monitoring Internet Session Traffic
1559 Corporate networks commonly monitor outbound session traffic to
1560 detect or prevent attacks as well as to guarantee service level
1561 expectations. In some cases, alternate options are available when
1562 encryption is in use, but techniques like that of data leakage
1563 prevention tools at a proxy would not be possible if encrypted
1564 traffic cannot be intercepted, encouraging alternate options such as
1565 performing these functions at the endpoint.
1567 Some DLP tools intercept traffic at the Internet gateway or proxy
1568 services with the ability to man-in-the-middle (MiTM) encrypted
1569 session traffic (HTTP/TLS). These tools may monitor for key words
1570 important to the enterprise including business sensitive information
1571 such as trade secrets, financial data, personally identifiable
1572 information (PII), or personal health information (PHI). Various
1573 techniques are used to intercept HTTP/TLS sessions for DLP and other
1574 purposes, and can be misused as described in "Summarizing Known
1575 Attacks on TLS and DTLS" [RFC7457] Section 2.8. Note: many corporate
1576 policies allow access to personal financial and other sites for users
1577 without interception. Another option is to terminate a TLS session
1578 prior to the point where monitoring is performed.
1580 Monitoring traffic patterns for anomalous behavior such as increased
1581 flows of traffic that could be bursty at odd times or flows to
1582 unusual destinations (small or large amounts of traffic) is common.
1583 This traffic may or may not be encrypted and various methods of
1584 encryption or just obfuscation may be used.
1586 Web proxies are sometimes used to filter traffic, allowing only
1587 access to well-known sites found to be legitimate and free of malware
1588 on last check by a proxy service company. This type of restriction
1589 is usually not noticeable in a corporate setting as the typical
1590 corporate user does not access sites that are not well-known to these
1591 tools, but may be noticeable to those in research who are unable to
1592 access colleague's individual sites or new web sites that have not
1593 yet been screened. In situations where new sites are required for
1594 access, they can typically be added after notification by the user or
1595 proxy log alerts and review. Home mail account access may be blocked
1596 in corporate settings to prevent another vector for malware to enter
1597 as well as for intellectual property to leak out of the network.
1598 This method remains functional with increased use of encryption and
1599 may be more effective at preventing malware from entering the
1600 network. Web proxy solutions monitor and potentially restrict access
1601 based on the destination URL or the DNS name. A complete URL may be
1602 used in cases where access restrictions vary for content on a
1603 particular site or for the sites hosted on a particular server.
1605 Desktop DLP tools are used in some corporate environments as well.
1606 Since these tools reside on the desktop, they can intercept traffic
1607 before it is encrypted and may provide a continued method of
1608 monitoring intellectual property leakage from the desktop to the
1609 Internet or attached devices.
1611 DLP tools can also be deployed by Network Service providers, as they
1612 have the vantage point of monitoring all traffic paired with
1613 destinations off the enterprise network. This makes an effective
1614 solution for enterprises that allow "bring-your-own" devices when the
1615 traffic is not encrypted, and for devices outside the desktop
1616 category (such as mobile phones) that are used on corporate networks
1617 nonetheless.
1619 Enterprises may wish to reduce the traffic on their Internet access
1620 facilities by monitoring requests for within-policy content and
1621 caching it. In this case, repeated requests for Internet content
1622 spawned by URLs in e-mail trade newsletters or other sources can be
1623 served within the enterprise network. Gradual deployment of end to
1624 end encryption would tend to reduce the cacheable content over time,
1625 owing to concealment of critical headers and payloads. Many forms of
1626 enterprise performance management may be similarly affected. It
1627 should be noted that transparent caching is considered an anti-
1628 pattern.
1630 5. Security Monitoring for Specific Attack Types
1632 Effective incident response today requires collaboration at Internet
1633 scale. This section will only focus on efforts of collaboration at
1634 Internet scale that are dedicated to specific attack types. They may
1635 require new monitoring and detection techniques in an increasingly
1636 encrypted Internet. As mentioned previously, some service providers
1637 have been interfering with STARTTLS to prevent session encryption to
1638 be able to perform functions they are used to (injecting ads,
1639 monitoring, etc.). By detailing the current monitoring methods used
1640 for attack detection and response, this information can be used to
1641 devise new monitoring methods that will be effective in the changed
1642 Internet via collaboration and innovation.
1644 Changes to improve encryption or to deploy OS methods have little
1645 impact on the detection of malicious actors. Malicious actors have
1646 had access to strong encryption for quite some time. Incident
1647 responders, in many cases, have developed techniques to locate
1648 malicious traffic within encrypted sessions. The following section
1649 will note some examples where detection and mitigation of such
1650 traffic has been successful.
1652 5.1. Mail Abuse and spam
1654 The largest operational effort to prevent mail abuse is through the
1655 Messaging, Malware, Mobile Anti-Abuse Working Group (M3AAWG)[M3AAWG].
1656 Mail abuse is combatted directly with mail administrators who can
1657 shut down or stop continued mail abuse originating from large scale
1658 providers that participate in using the Abuse Reporting Format (ARF)
1659 agents standardized in the IETF [RFC5965], [RFC6430], [RFC6590],
1660 [RFC6591], [RFC6650], [RFC6651], and [RFC6652]. The ARF agent
1661 directly reports abuse messages to the appropriate service provider
1662 who can take action to stop or mitigate the abuse. Since this
1663 technique uses the actual message, the use of SMTP over TLS between
1664 mail gateways will not affect its usefulness. As mentioned
1665 previously, SMTP over TLS only protects data while in transit and the
1666 messages may be exposed on mail servers or mail gateways if a user-
1667 to-user encryption method is not used. Current user-to-user message
1668 encryption methods on email (S/MIME and PGP) do not encrypt the email
1669 header information used by ARF and the service provider operators in
1670 their abuse mitigation efforts.
1672 Another effort, Domain-based Message Authentication, Reporting, and
1673 Conformance (DMARC) [RFC7489] is a mechanism for policy distribution
1674 that enables increasingly strict handling of messages that fail
1675 authentication checks, ranging from no action, through altered
1676 delivery, up to message rejection.
1678 5.2. Denial of Service
1680 Response to Denial of Service (DoS) attacks are typically coordinated
1681 by the SP community with a few key vendors who have tools to assist
1682 in the mitigation efforts. Traffic patterns are determined from each
1683 DoS attack to stop or rate limit the traffic flows with patterns
1684 unique to that DoS attack.
1686 Data types used in monitoring traffic for DDoS are described in the
1687 DDoS Open Threat Signaling (DOTS) [DOTS] working group documents in
1688 development. The impact of encryption can be understood from their
1689 documented use cases[I-D.ietf-dots-use-cases].
1691 Data types used in DDoS attacks have been detailed in the IODEF
1692 Guidance draft [RFC8274], Appendix A.2, with the help of several
1693 members of the service provider community. The examples provided are
1694 intended to help identify the useful data in detecting and mitigating
1695 these attacks independent of the transport and protocol descriptions
1696 in the drafts.
1698 5.3. Phishing
1700 Investigations and response to phishing attacks follow well-known
1701 patterns, requiring access to specific fields in email headers as
1702 well as content from the body of the message. When reporting
1703 phishing attacks, the recipient has access to each field as well as
1704 the body to make content reporting possible, even when end-to-end
1705 encryption is used. The email header information is useful to
1706 identify the mail servers and accounts used to generate or relay the
1707 attack messages in order to take the appropriate actions. The
1708 content of the message often contains an embedded attack that may be
1709 in an infected file or may be a link that results in the download of
1710 malware to the user's system.
1712 Administrators often find it helpful to use header information to
1713 track down similar message in their mail queue or users inboxes to
1714 prevent further infection. Combinations of To:, From:, Subject:,
1715 Received: from header information might be used for this purpose.
1716 Administrators may also search for document attachments of the same
1717 name, size, or containing a file with a matching hash to a known
1718 phishing attack. Administrators might also add URLs contained in
1719 messages to block lists locally or this may also be done by browser
1720 vendors through larger scales efforts like that of the Anti-Phishing
1721 Working Group (APWG). See the Coordinating Attack Response at
1722 Internet Scale (CARIS) workshop Report [RFC8073] for additional
1723 information and pointers to the APWG's efforts on anti- phishing.
1725 A full list of the fields used in phishing attack incident response
1726 can be found in RFC5901. Future plans to increase privacy
1727 protections may limit some of these capabilities if some email header
1728 fields are encrypted, such as To:, From:, and Subject: header fields.
1729 This does not mean that those fields should not be encrypted, only
1730 that we should be aware of how they are currently used.
1732 Some products protect users from phishing by maintaining lists of
1733 known phishing domains (such as misspelled bank names) and blocking
1734 access. This can be done by observing DNS, clear-text HTTP, or
1735 server name indication (SNI) in TLS, in addition to analyzing email.
1736 Alternate options to detect and prevent phishing attacks may be
1737 needed. More recent examples of data exchanged in spear phishing
1738 attacks has been detailed in the IODEF Guidance draft [RFC8274],
1739 Appendix A.3.
1741 5.4. Botnets
1743 Botnet detection and mitigation is complex as botnets may involve
1744 hundreds or thousands of hosts with numerous Command and Control
1745 (C&C) servers. The techniques and data used to monitor and detect
1746 each may vary. Connections to C&C servers are typically encrypted,
1747 therefore a move to an increasingly encrypted Internet may not affect
1748 the detection and sharing methods used.
1750 5.5. Malware
1752 Malware monitoring and detection techniques vary. As mentioned in
1753 the enterprise section, malware monitoring may occur at gateways to
1754 the organization analyzing email and web traffic. These services can
1755 also be provided by service providers, changing the scale and
1756 location of this type of monitoring. Additionally, incident
1757 responders may identify attributes unique to types of malware to help
1758 track down instances by their communication patterns on the Internet
1759 or by alterations to hosts and servers.
1761 Data types used in malware investigations have been summarized in an
1762 example of the IODEF Guidance draft [RFC8274], Appendix A.1.
1764 5.6. Spoofed Source IP Address Protection
1766 The IETF has reacted to spoofed source IP address-based attacks,
1767 recommending the use of network ingress filtering BCP 38 [RFC2827]
1768 and the unicast Reverse Path Forwarding (uRPF) mechanism [RFC2504].
1769 But uRPF suffers from limitations regarding its granularity: a
1770 malicious node can still use a spoofed IP address included inside the
1771 prefix assigned to its link. The Source Address Validation
1772 Improvements (SAVI) mechanisms try to solve this issue. Basically, a
1773 SAVI mechanism is based on the monitoring of a specific address
1774 assignment/management protocol (e.g., SLAAC [RFC4862], SEND
1775 [RFC3971], DHCPv4/v6 [RFC2131][RFC3315]) and, according to this
1776 monitoring, set-up a filtering policy allowing only the IP flows with
1777 a correct source IP address (i.e., any packet with a source IP
1778 address, from a node not owning it, is dropped). The encryption of
1779 parts of the address assignment/management protocols, critical for
1780 SAVI mechanisms, can result in a dysfunction of the SAVI mechanisms.
1782 5.7. Further work
1784 Although incident response work will continue, new methods to prevent
1785 system compromise through security automation and continuous
1786 monitoring [SACM] may provide alternate approaches where system
1787 security is maintained as a preventative measure.
1789 6. Application-based Flow Information Visible to a Network
1791 This section describes specific techniques used in monitoring
1792 applications that is visible to the network if a 5-tuple is exposed
1793 and as such can potentially be used an input future network
1794 management approaches. It also includes an overview of IPFIX, a
1795 flow-based protocol used to export information about network flows.
1797 6.1. IP Flow Information Export
1799 Many of the accounting, monitoring and measurement tasks described in
1800 this document, especially Section 2.3.2, Section 3.1.1,
1801 Section 4.1.3, Section 4.2, and Section 5.2 use the IPFIX protocol
1802 [RFC7011] for export and storage of the monitored information. IPFIX
1803 evolved from the widely-deployed NetFlow protocol [RFC3954], which
1804 exports information about flows identified by 5-tuple. While NetFlow
1805 was largely concerned with exporting per-flow byte and packet counts
1806 for accounting purposes, IPFIX's extensible information model
1807 [RFC7012] provides a variety of Information Elements (IEs)
1808 [IPFIX-IANA] for representing information above and below the
1809 traditional network layer flow information. Enterprise-specific IEs
1810 allow exporter vendors to define their own non-standard IEs, as well,
1811 and many of these are driven by header and payload inspection at the
1812 metering process.
1814 While the deployment of encryption has no direct effect on the use of
1815 IPFIX, certain defined IEs may become unavailable when the metering
1816 process observing the traffic cannot decrypt formerly cleartext
1817 information. For example, HTTPS renders HTTP header analysis
1818 impossible, so IEs derived from the header (e.g. httpContentType,
1819 httpUserAgent) cannot be exported.
1821 The collection of IPFIX data itself, of course, provides a point of
1822 centralization for potentially business- and privacy-critical
1823 information. The IPFIX File Format specification [RFC5655]
1824 recommends encryption for this data at rest, and the IP Flow
1825 Anonymization specification [RFC6235] defines a metadata format for
1826 describing the anonymization functions applied to an IPFIX dataset,
1827 if anonymization is employed for data sharing of IPFIX information
1828 between enterprises or network operators.
1830 6.2. TLS Server Name Indication
1832 When initiating the TLS handshake, the Client may provide an
1833 extension field (server_name) which indicates the server to which it
1834 is attempting a secure connection. TLS SNI was standardized in 2003
1835 to enable servers to present the "correct TLS certificate" to clients
1836 in a deployment of multiple virtual servers hosted by the same server
1837 infrastructure and IP-address. Although this is an optional
1838 extension, it is today supported by all modern browsers, web servers
1839 and developer libraries. Akamai [Nygren] reports that many of their
1840 customer see client TLS SNI usage over 99%. It should be noted that
1841 HTTP/2 introduces the Alt-SVC method for upgrading the connection
1842 from HTTP/1 to either unencrypted or encrypted HTTP/2. If the
1843 initial HTTP/1 request is unencrypted, the destination alternate
1844 service name can be identified before the communication is
1845 potentially upgraded to encrypted HTTP/2 transport. HTTP/2 requires
1846 the TLS implementation to support the Server Name Indication (SNI)
1847 extension (see section 9.2 of [RFC7540]). It is also worth noting
1848 that [RFC7838] "allows an origin server to nominate additional means
1849 of interacting with it on the network", while [RFC8164] allows for a
1850 URI to be accessed with HTTP/2 and TLS using Opportunistic Security
1851 (on an experimental basis).
1853 This information is only available if the client populates the Server
1854 Name Indication extension. Doing so is an optional part of the TLS
1855 standard and as stated above this has been implemented by all major
1856 browsers. Due to its optional nature, though, existing network
1857 filters that examine a TLS ClientHello for a SNI extension cannot
1858 expect to always find one. The SNI Encryption in TLS Through
1859 Tunneling [I-D.ietf-tls-sni-encryption] draft has been adopted by the
1860 TLS working group, which provides solutions to encrypt SNI. As such,
1861 there will be an option to encrypt SNI in future versions of TLS.
1862 The per-domain nature of SNI may not reveal the specific service or
1863 media type being accessed, especially where the domain is of a
1864 provider offering a range of email, video, Web pages etc. For
1865 example, certain blog or social network feeds may be deemed 'adult
1866 content', but the Server Name Indication will only indicate the
1867 server domain rather than a URL path.
1869 There are additional issues for identification of content using SNI:
1870 [RFC7540] includes connection coalesing,
1871 [I-D.ietf-httpbis-origin-frame] defines the ORIGIN frame, and the
1872 [I-D.bishop-httpbis-http2-additional-certs] proposal will increase
1873 the difficulty of passive monitoring.
1875 6.3. Application Layer Protocol Negotiation (ALPN)
1877 ALPN is a TLS extension which may be used to indicate the application
1878 protocol within the TLS session. This is likely to be of more value
1879 to the network where it indicates a protocol dedicated to a
1880 particular traffic type (such as video streaming) rather than a
1881 multi-use protocol. ALPN is used as part of HTTP/2 'h2', but will
1882 not indicate the traffic types which may make up streams within an
1883 HTTP/2 multiplex. ALPN is sent clear text in the ClientHello and the
1884 server returns it in Encrypted Extensions in TLS 1.3.
1886 6.4. Content Length, BitRate and Pacing
1888 The content length of encrypted traffic is effectively the same as
1889 that of the cleartext. Although block ciphers utilise padding, this
1890 makes a negligible difference. Bitrate and pacing are generally
1891 application specific, and do not change much when the content is
1892 encrypted. Multiplexed formats (such as HTTP/2 and QUIC) may however incorporate several application
1894 streams over one connection, which makes the bitrate/pacing no longer
1895 application-specific. Also, packet padding is available in HTTP/2,
1896 TLS 1.3, and many other protocols. Traffic analysis is made more
1897 difficult by such countermeasures.
1899 7. Effect of Encryption on Mobile Network Evolution
1901 Transport header encryption prevents the use of transit proxies in
1902 center of the network and the use of some edge proxies by preventing
1903 the proxies from taking action on the stream. It may be that the
1904 benefits of such proxies could be achieved by end-to-end client and
1905 server optimizations, distribution using CDNs, plus the ability to
1906 continue connections across different access technologies (across
1907 dynamic user IP addresses). The following aspects should be
1908 considered in this approach:
1910 1. In a wireless mobile network, the delay and channel capacity per
1911 user and sector varies due to coverage, contention, user
1912 mobility, scheduling balances fairness, capacity, and service
1913 QoE. If most users are at the cell edge, the controller cannot
1914 use more complex QAM, thus reducing total cell capacity;
1915 similarly if a UMTS edge is serving some number of CS-Voice
1916 Calls, the remaining capacity for packet services is reduced.
1918 2. Mobile wireless networks service in-bound roamers (Users of
1919 Operator A in a foreign operator Network B) by backhauling their
1920 traffic though Operator B's network to Operator A's Network and
1921 then serving through the P-Gateway (PGW), General GPRS Support
1922 Node (GGSN), Content Distribution Network (CDN) etc., of Operator
1923 A (User's Home Operator). Increasing window sizes to compensate
1924 for the path RTT will have the limitations outlined earlier for
1925 TCP. The outbound roamer scenario has a similar TCP performance
1926 impact.
1928 3. Issues in deploying CDNs in Radio Access Networks (RAN) include
1929 decreasing client-server control loop that requires deploying
1930 CDNs/Cloud functions that terminate encryption closer to the
1931 edge. In Cellular RAN, the user IP traffic is encapsulated into
1932 General Packet Radio Service (GPRS) Tunneling Protocol-User Plane
1933 (GTP-U in UMTS and LTE) tunnels to handle user mobility; the
1934 tunnels terminate in APN/GGSN/PGW that are in central locations.
1935 One user's traffic may flow through one or more APN's (for
1936 example Internet APN, Roaming APN for Operator X, Video-Service
1937 APN, OnDeckAPN etc.). The scope of operator private IP addresses
1938 may be limited to specific APNs. Since CDNs generally operate on
1939 user IP flows, deploying them would require enhancing them with
1940 tunnel translation, tunnel management functions etc..
1942 4. While CDNs that de-encrypt flows or split-connection proxy
1943 (similar to split-tcp) could be deployed closer to the edges to
1944 reduce control loop RTT, with transport header encryption, such
1945 CDNs perform optimization functions only for partner client
1946 flows. Therefore, content from some Small-Medium Businesses
1947 (SMBs) would not get such CDN benefits.
1949 8. Response to Increased Encryption and Looking Forward
1951 As stated in [RFC7258], "an appropriate balance (between network
1952 management and PM mitigations) will emerge over time as real
1953 instances of this tension are considered." Numerous operators made
1954 it clear in their response to this document that they fully support
1955 strong encryption and providing privacy for end users, this is a
1956 common goal. Operators recognize not all the practices documented
1957 need to be supported going forward, either because of the risk to end
1958 user privacy or alternate technologies and tools have already
1959 emerged. This document is intended to support network engineers and
1960 other innovators to work toward solving network and security
1961 management problems with protocol designers and application
1962 developers in new ways that facilitate adoption of strong encryption
1963 rather than preventing the use of encryption. By having the
1964 discussions on network and security management practices with
1965 application developers and protocol designers, each side of the
1966 debate can understand each others goals, work toward alternate
1967 solutions, and disband with practices that should no longer be
1968 supported. A goal of this document is to assist the IETF to
1969 understand some of the current practices so as to identify new work
1970 items for IETF-related use cases which can help facilitate the
1971 adoption of strong session encryption and support network and
1972 security management.
1974 9. Security Considerations
1976 There are no additional security considerations as this is a summary
1977 and does not include a new protocol or functionality.
1979 10. IANA Considerations
1981 This memo makes no requests of IANA.
1983 11. Acknowledgements
1985 Thanks to our reviewers, Natasha Rooney, Kevin Smith, Ashutosh Dutta,
1986 Brandon Williams, Jean-Michel Combes, Nalini Elkins, Paul Barrett,
1987 Badri Subramanyan, Igor Lubashev, Suresh Krishnan, Dave Dolson,
1988 Mohamed Boucadair, Stephen Farrell, Warren Kumari, Alia Atlas, Roman
1989 Danyliw, Mirja Kuhlewind, Ines Robles, Joe Clarke, and Kyle Rose for
1990 their editorial and content suggestions. Surya K. Kovvali provided
1991 material for section 7. Chris Morrow and Nik Teague provided reviews
1992 and updates specific to the DoS fingerprinting text. Brian Trammell
1993 provided the IPFIX text.
1995 12. Informative References
1997 [ACCORD] "Acord BoF IETF95
1998 https://www.ietf.org/proceedings/95/accord.html".
2000 [CAIDA] "CAIDA *Anonymized Internet Traces*
2001 [http://www.caida.org/data/overview/ and
2002 http://www.caida.org/data/passive/
2003 passive_2016_dataset.xml]".
2005 [DarkMail]
2006 "The Dark Mail Technical Aliance https://darkmail.info/".
2008 [DOTS] https://datatracker.ietf.org/wg/dots/charter/, "DDoS Open
2009 Threat Signaling IETF Working Group".
2011 [EFF2014] "EFF Report on STARTTLS Downgrade Attacks
2012 https://www.eff.org/deeplinks/2014/11/
2013 starttls-downgrade-attacks".
2015 [Enrich] Narseo Vallina-Rodriguez, et al., "Header Enrichment or
2016 ISP Enrichment? Emerging Privacy Threats in Mobile
2017 Networks, Hot Middlebox'15, August 17-21 2015, London,
2018 United Kingdom", 2015.
2020 [I-D.bishop-httpbis-http2-additional-certs]
2021 Bishop, M., Sullivan, N., and M. Thomson, "Secondary
2022 Certificate Authentication in HTTP/2", draft-bishop-
2023 httpbis-http2-additional-certs-05 (work in progress),
2024 October 2017.
2026 [I-D.dolson-plus-middlebox-benefits]
2027 Dolson, D., Snellman, J., Boucadair, M., and C. Jacquenet,
2028 "Beneficial Functions of Middleboxes", draft-dolson-plus-
2029 middlebox-benefits-03 (work in progress), March 2017.
2031 [I-D.ietf-dots-use-cases]
2032 Dobbins, R., Migault, D., Fouant, S., Moskowitz, R.,
2033 Teague, N., Xia, L., and K. Nishizuka, "Use cases for DDoS
2034 Open Threat Signaling", draft-ietf-dots-use-cases-09 (work
2035 in progress), November 2017.
2037 [I-D.ietf-httpbis-origin-frame]
2038 Nottingham, M. and E. Nygren, "The ORIGIN HTTP/2 Frame",
2039 draft-ietf-httpbis-origin-frame-06 (work in progress),
2040 January 2018.
2042 [I-D.ietf-tls-sni-encryption]
2043 Huitema, C. and E. Rescorla, "SNI Encryption in TLS
2044 Through Tunneling", draft-ietf-tls-sni-encryption-00 (work
2045 in progress), August 2017.
2047 [I-D.mglt-nvo3-geneve-security-requirements]
2048 Migault, D., Boutros, S., Wing, D., and S. Krishnan,
2049 "Geneve Protocol Security Requirements", draft-mglt-nvo3-
2050 geneve-security-requirements-02 (work in progress),
2051 January 2018.
2053 [IPFIX-IANA]
2054 "IP Flow Information Export (IPFIX) Entities
2055 https://www.iana.org/assignments/ipfix/".
2057 [JNSLP] Surveillance, Vol. 8 No. 3, "10 Standards for Oversight
2058 and Transparency of National Intelligence Services
2059 http://jnslp.com/".
2061 [M3AAWG] "Messaging, Malware, Mobile Anti-Abuse Working Group
2062 (M3AAWG) https://www.maawg.org/".
2064 [Nygren] https://blogs.akamai.com/2017/03/ reaching-toward-
2065 universal-tls-sni.html, "Erik Nygren, personal reference".
2067 [QUIC] https://datatracker.ietf.org/wg/quic/charter/, "QUIC
2068 (quic)".
2070 [RFC1945] Berners-Lee, T., Fielding, R., and H. Frystyk, "Hypertext
2071 Transfer Protocol -- HTTP/1.0", RFC 1945,
2072 DOI 10.17487/RFC1945, May 1996,
2073 .
2075 [RFC1958] Carpenter, B., Ed., "Architectural Principles of the
2076 Internet", RFC 1958, DOI 10.17487/RFC1958, June 1996,
2077 .
2079 [RFC1984] IAB and IESG, "IAB and IESG Statement on Cryptographic
2080 Technology and the Internet", BCP 200, RFC 1984,
2081 DOI 10.17487/RFC1984, August 1996,
2082 .
2084 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol",
2085 RFC 2131, DOI 10.17487/RFC2131, March 1997,
2086 .
2088 [RFC2504] Guttman, E., Leong, L., and G. Malkin, "Users' Security
2089 Handbook", FYI 34, RFC 2504, DOI 10.17487/RFC2504,
2090 February 1999, .
2092 [RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address
2093 Translator (NAT) Terminology and Considerations",
2094 RFC 2663, DOI 10.17487/RFC2663, August 1999,
2095 .
2097 [RFC2775] Carpenter, B., "Internet Transparency", RFC 2775,
2098 DOI 10.17487/RFC2775, February 2000,
2099 .
2101 [RFC2804] IAB and IESG, "IETF Policy on Wiretapping", RFC 2804,
2102 DOI 10.17487/RFC2804, May 2000,
2103 .
2105 [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering:
2106 Defeating Denial of Service Attacks which employ IP Source
2107 Address Spoofing", BCP 38, RFC 2827, DOI 10.17487/RFC2827,
2108 May 2000, .
2110 [RFC3135] Border, J., Kojo, M., Griner, J., Montenegro, G., and Z.
2111 Shelby, "Performance Enhancing Proxies Intended to
2112 Mitigate Link-Related Degradations", RFC 3135,
2113 DOI 10.17487/RFC3135, June 2001,
2114 .
2116 [RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins,
2117 C., and M. Carney, "Dynamic Host Configuration Protocol
2118 for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July
2119 2003, .
2121 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
2122 Jacobson, "RTP: A Transport Protocol for Real-Time
2123 Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550,
2124 July 2003, .
2126 [RFC3724] Kempf, J., Ed., Austein, R., Ed., and IAB, "The Rise of
2127 the Middle and the Future of End-to-End: Reflections on
2128 the Evolution of the Internet Architecture", RFC 3724,
2129 DOI 10.17487/RFC3724, March 2004,
2130 .
2132 [RFC3954] Claise, B., Ed., "Cisco Systems NetFlow Services Export
2133 Version 9", RFC 3954, DOI 10.17487/RFC3954, October 2004,
2134 .
2136 [RFC3971] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander,
2137 "SEcure Neighbor Discovery (SEND)", RFC 3971,
2138 DOI 10.17487/RFC3971, March 2005,
2139 .
2141 [RFC4787] Audet, F., Ed. and C. Jennings, "Network Address
2142 Translation (NAT) Behavioral Requirements for Unicast
2143 UDP", BCP 127, RFC 4787, DOI 10.17487/RFC4787, January
2144 2007, .
2146 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
2147 Address Autoconfiguration", RFC 4862,
2148 DOI 10.17487/RFC4862, September 2007,
2149 .
2151 [RFC5655] Trammell, B., Boschi, E., Mark, L., Zseby, T., and A.
2152 Wagner, "Specification of the IP Flow Information Export
2153 (IPFIX) File Format", RFC 5655, DOI 10.17487/RFC5655,
2154 October 2009, .
2156 [RFC5965] Shafranovich, Y., Levine, J., and M. Kucherawy, "An
2157 Extensible Format for Email Feedback Reports", RFC 5965,
2158 DOI 10.17487/RFC5965, August 2010,
2159 .
2161 [RFC6108] Chung, C., Kasyanov, A., Livingood, J., Mody, N., and B.
2162 Van Lieu, "Comcast's Web Notification System Design",
2163 RFC 6108, DOI 10.17487/RFC6108, February 2011,
2164 .
2166 [RFC6235] Boschi, E. and B. Trammell, "IP Flow Anonymization
2167 Support", RFC 6235, DOI 10.17487/RFC6235, May 2011,
2168 .
2170 [RFC6269] Ford, M., Ed., Boucadair, M., Durand, A., Levis, P., and
2171 P. Roberts, "Issues with IP Address Sharing", RFC 6269,
2172 DOI 10.17487/RFC6269, June 2011,
2173 .
2175 [RFC6430] Li, K. and B. Leiba, "Email Feedback Report Type Value:
2176 not-spam", RFC 6430, DOI 10.17487/RFC6430, November 2011,
2177 .
2179 [RFC6455] Fette, I. and A. Melnikov, "The WebSocket Protocol",
2180 RFC 6455, DOI 10.17487/RFC6455, December 2011,
2181 .
2183 [RFC6590] Falk, J., Ed. and M. Kucherawy, Ed., "Redaction of
2184 Potentially Sensitive Data from Mail Abuse Reports",
2185 RFC 6590, DOI 10.17487/RFC6590, April 2012,
2186 .
2188 [RFC6591] Fontana, H., "Authentication Failure Reporting Using the
2189 Abuse Reporting Format", RFC 6591, DOI 10.17487/RFC6591,
2190 April 2012, .
2192 [RFC6650] Falk, J. and M. Kucherawy, Ed., "Creation and Use of Email
2193 Feedback Reports: An Applicability Statement for the Abuse
2194 Reporting Format (ARF)", RFC 6650, DOI 10.17487/RFC6650,
2195 June 2012, .
2197 [RFC6651] Kucherawy, M., "Extensions to DomainKeys Identified Mail
2198 (DKIM) for Failure Reporting", RFC 6651,
2199 DOI 10.17487/RFC6651, June 2012,
2200 .
2202 [RFC6652] Kitterman, S., "Sender Policy Framework (SPF)
2203 Authentication Failure Reporting Using the Abuse Reporting
2204 Format", RFC 6652, DOI 10.17487/RFC6652, June 2012,
2205 .
2207 [RFC7011] Claise, B., Ed., Trammell, B., Ed., and P. Aitken,
2208 "Specification of the IP Flow Information Export (IPFIX)
2209 Protocol for the Exchange of Flow Information", STD 77,
2210 RFC 7011, DOI 10.17487/RFC7011, September 2013,
2211 .
2213 [RFC7012] Claise, B., Ed. and B. Trammell, Ed., "Information Model
2214 for IP Flow Information Export (IPFIX)", RFC 7012,
2215 DOI 10.17487/RFC7012, September 2013,
2216 .
2218 [RFC7143] Chadalapaka, M., Satran, J., Meth, K., and D. Black,
2219 "Internet Small Computer System Interface (iSCSI) Protocol
2220 (Consolidated)", RFC 7143, DOI 10.17487/RFC7143, April
2221 2014, .
2223 [RFC7146] Black, D. and P. Koning, "Securing Block Storage Protocols
2224 over IP: RFC 3723 Requirements Update for IPsec v3",
2225 RFC 7146, DOI 10.17487/RFC7146, April 2014,
2226 .
2228 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
2229 Protocol (HTTP/1.1): Message Syntax and Routing",
2230 RFC 7230, DOI 10.17487/RFC7230, June 2014,
2231 .
2233 [RFC7234] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
2234 Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching",
2235 RFC 7234, DOI 10.17487/RFC7234, June 2014,
2236 .
2238 [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an
2239 Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May
2240 2014, .
2242 [RFC7348] Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger,
2243 L., Sridhar, T., Bursell, M., and C. Wright, "Virtual
2244 eXtensible Local Area Network (VXLAN): A Framework for
2245 Overlaying Virtualized Layer 2 Networks over Layer 3
2246 Networks", RFC 7348, DOI 10.17487/RFC7348, August 2014,
2247 .
2249 [RFC7435] Dukhovni, V., "Opportunistic Security: Some Protection
2250 Most of the Time", RFC 7435, DOI 10.17487/RFC7435,
2251 December 2014, .
2253 [RFC7457] Sheffer, Y., Holz, R., and P. Saint-Andre, "Summarizing
2254 Known Attacks on Transport Layer Security (TLS) and
2255 Datagram TLS (DTLS)", RFC 7457, DOI 10.17487/RFC7457,
2256 February 2015, .
2258 [RFC7489] Kucherawy, M., Ed. and E. Zwicky, Ed., "Domain-based
2259 Message Authentication, Reporting, and Conformance
2260 (DMARC)", RFC 7489, DOI 10.17487/RFC7489, March 2015,
2261 .
2263 [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre,
2264 "Recommendations for Secure Use of Transport Layer
2265 Security (TLS) and Datagram Transport Layer Security
2266 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May
2267 2015, .
2269 [RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext
2270 Transfer Protocol Version 2 (HTTP/2)", RFC 7540,
2271 DOI 10.17487/RFC7540, May 2015,
2272 .
2274 [RFC7619] Smyslov, V. and P. Wouters, "The NULL Authentication
2275 Method in the Internet Key Exchange Protocol Version 2
2276 (IKEv2)", RFC 7619, DOI 10.17487/RFC7619, August 2015,
2277 .
2279 [RFC7624] Barnes, R., Schneier, B., Jennings, C., Hardie, T.,
2280 Trammell, B., Huitema, C., and D. Borkmann,
2281 "Confidentiality in the Face of Pervasive Surveillance: A
2282 Threat Model and Problem Statement", RFC 7624,
2283 DOI 10.17487/RFC7624, August 2015,
2284 .
2286 [RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function
2287 Chaining (SFC) Architecture", RFC 7665,
2288 DOI 10.17487/RFC7665, October 2015,
2289 .
2291 [RFC7754] Barnes, R., Cooper, A., Kolkman, O., Thaler, D., and E.
2292 Nordmark, "Technical Considerations for Internet Service
2293 Blocking and Filtering", RFC 7754, DOI 10.17487/RFC7754,
2294 March 2016, .
2296 [RFC7799] Morton, A., "Active and Passive Metrics and Methods (with
2297 Hybrid Types In-Between)", RFC 7799, DOI 10.17487/RFC7799,
2298 May 2016, .
2300 [RFC7826] Schulzrinne, H., Rao, A., Lanphier, R., Westerlund, M.,
2301 and M. Stiemerling, Ed., "Real-Time Streaming Protocol
2302 Version 2.0", RFC 7826, DOI 10.17487/RFC7826, December
2303 2016, .
2305 [RFC7838] Nottingham, M., McManus, P., and J. Reschke, "HTTP
2306 Alternative Services", RFC 7838, DOI 10.17487/RFC7838,
2307 April 2016, .
2309 [RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D.,
2310 and P. Hoffman, "Specification for DNS over Transport
2311 Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May
2312 2016, .
2314 [RFC8073] Moriarty, K. and M. Ford, "Coordinating Attack Response at
2315 Internet Scale (CARIS) Workshop Report", RFC 8073,
2316 DOI 10.17487/RFC8073, March 2017,
2317 .
2319 [RFC8164] Nottingham, M. and M. Thomson, "Opportunistic Security for
2320 HTTP/2", RFC 8164, DOI 10.17487/RFC8164, May 2017,
2321 .
2323 [RFC8165] Hardie, T., "Design Considerations for Metadata
2324 Insertion", RFC 8165, DOI 10.17487/RFC8165, May 2017,
2325 .
2327 [RFC8250] Elkins, N., Hamilton, R., and M. Ackermann, "IPv6
2328 Performance and Diagnostic Metrics (PDM) Destination
2329 Option", RFC 8250, DOI 10.17487/RFC8250, September 2017,
2330 .
2332 [RFC8274] Kampanakis, P. and M. Suzuki, "Incident Object Description
2333 Exchange Format Usage Guidance", RFC 8274,
2334 DOI 10.17487/RFC8274, November 2017,
2335 .
2337 [SACM] https://datatracker.ietf.org/wg/sacm/charter/, "Security
2338 Automation and Continuous Monitoring (sacm) IETF Working
2339 Group".
2341 [Snowden] http://www.jjsylvia.com/bigdatacourse/wp-
2342 content/uploads/2016/04/p14-verble-1.pdf, "The NSA and
2343 Edward Snowden: Surveillance In The 21st Century", 2014.
2345 [TCPcrypt]
2346 https://datatracker.ietf.org/wg/tcpinc/charter/,
2347 "TCPcrypt".
2349 [TS3GPP] "3GPP TS 24.301, "Non-Access-Stratum (NAS) protocol for
2350 Evolved Packet System (EPS); Stage 3"", 2017.
2352 [UPCON] 3GPP, "User Plane Congestion Management
2353 http://www.3gpp.org/DynaReport/
2354 FeatureOrStudyItemFile-570029.htm", 2014.
2356 Authors' Addresses
2358 Kathleen Moriarty (editor)
2359 Dell EMC
2360 176 South St
2361 Hopkinton, MA
2362 USA
2364 Phone: +1
2365 Email: Kathleen.Moriarty@dell.com
2366 Al Morton (editor)
2367 AT&T Labs
2368 200 Laurel Avenue South
2369 Middletown,, NJ 07748
2370 USA
2372 Phone: +1 732 420 1571
2373 Fax: +1 732 368 1192
2374 Email: acmorton@att.com