idnits 2.17.1 draft-mm-wg-effect-encrypt-08.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 1213: '... implementations MUST support the Serv...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 10, 2017) is 2603 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'SACM' is mentioned on line 1191, but not defined == Outdated reference: A later version (-13) exists of draft-ietf-ippm-6man-pdm-option-08 == Outdated reference: A later version (-11) exists of draft-ietf-mile-iodef-guidance-07 -- Obsolete informational reference (is this intentional?): RFC 2326 (Obsoleted by RFC 7826) -- 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) Summary: 1 error (**), 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 3 Internet-Draft Dell EMC 4 Intended status: Informational A. Morton 5 Expires: September 11, 2017 AT&T Labs 6 March 10, 2017 8 Effect of Pervasive Encryption 9 draft-mm-wg-effect-encrypt-08 11 Abstract 13 Increased use of encryption impacts operations for security and 14 network management causing a shift in how these functions are 15 performed. In some cases, new methods to both monitor and protect 16 data will evolve. In other cases, the ability to monitor and 17 troubleshoot could be eliminated. This draft includes a collection 18 of current security and network management functions that may be 19 impacted by the shift to increased use of encryption. This draft 20 does not attempt to solve these problems, but rather document the 21 current state to assist in the development of alternate options to 22 achieve the intended purpose of the documented practices. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on September 11, 2017. 41 Copyright Notice 43 Copyright (c) 2017 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. Network Service Provider Monitoring . . . . . . . . . . . . . 5 60 2.1. Middlebox Monitoring . . . . . . . . . . . . . . . . . . 5 61 2.1.1. Load Balancers . . . . . . . . . . . . . . . . . . . 5 62 2.1.2. Traffic Analysis Fingerprinting . . . . . . . . . . . 6 63 2.1.3. Traffic Surveys . . . . . . . . . . . . . . . . . . . 6 64 2.1.4. Deep Packet Inspection (DPI) . . . . . . . . . . . . 7 65 2.1.5. Connection to Proxy for Compression . . . . . . . . . 8 66 2.1.6. Mobility Middlebox Content Filtering . . . . . . . . 8 67 2.1.7. Access and Policy Enforcement . . . . . . . . . . . . 9 68 2.2. Network Monitoring for Performance Management and 69 Troubleshooting . . . . . . . . . . . . . . . . . . . . . 11 70 3. Encryption in Hosting SP Environments . . . . . . . . . . . . 11 71 3.1. Management Access Security . . . . . . . . . . . . . . . 12 72 3.1.1. Customer Access Monitoring . . . . . . . . . . . . . 12 73 3.1.2. Application SP Content Monitoring . . . . . . . . . . 13 74 3.2. Hosted Applications . . . . . . . . . . . . . . . . . . . 14 75 3.2.1. Monitoring needs for Managed Applications . . . . . . 15 76 3.2.2. Mail Service Providers . . . . . . . . . . . . . . . 15 77 3.3. Data Storage . . . . . . . . . . . . . . . . . . . . . . 16 78 3.3.1. Host-level Encryption . . . . . . . . . . . . . . . . 16 79 3.3.2. Disk Encryption, Data at Rest . . . . . . . . . . . . 17 80 3.3.3. Cross Data Center Replication Services . . . . . . . 17 81 4. Encryption for Enterprises . . . . . . . . . . . . . . . . . 18 82 4.1. Monitoring Needs of the Enterprise . . . . . . . . . . . 18 83 4.1.1. Security Monitoring in the Enterprise . . . . . . . . 18 84 4.1.2. Application Performance Monitoring in the Enterprise 19 85 4.1.3. Enterprise Network Diagnostics and Troubleshooting . 20 86 4.2. Techniques for Monitoring Internet Session Traffic . . . 21 87 5. Security Monitoring for Specific Attack Types . . . . . . . . 23 88 5.1. Mail Abuse and SPAM . . . . . . . . . . . . . . . . . . . 23 89 5.2. Denial of Service . . . . . . . . . . . . . . . . . . . . 24 90 5.3. Phishing . . . . . . . . . . . . . . . . . . . . . . . . 24 91 5.4. Botnets . . . . . . . . . . . . . . . . . . . . . . . . . 25 92 5.5. Malware . . . . . . . . . . . . . . . . . . . . . . . . . 25 93 5.6. Spoofed Source IP Address Protection . . . . . . . . . . 25 94 5.7. Further work . . . . . . . . . . . . . . . . . . . . . . 26 95 6. Application-based Flow Information Visible to a Network . . . 26 96 6.1. TLS Server Name Indication . . . . . . . . . . . . . . . 26 97 6.2. Application Layer Protocol Negotiation (ALPN) . . . . . . 26 98 6.3. Content Length, BitRate and Pacing . . . . . . . . . . . 27 99 7. Response to Increased Encryption and Looking Forward . . . . 27 100 8. Security Considerations . . . . . . . . . . . . . . . . . . . 28 101 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 102 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 28 103 11. Appendix: Impact on Mobility Network Optimizations and New 104 Services . . . . . . . . . . . . . . . . . . . . . . . . . . 28 105 11.1. Effect of Encypted ACKs . . . . . . . . . . . . . . . . 29 106 11.2. Effect of Encrypted Transport Headers . . . . . . . . . 30 107 11.3. Effect of Encryption on New Services . . . . . . . . . . 30 108 11.4. Effect of Encryption on Mobile Network Evolution . . . . 31 109 12. Informative References . . . . . . . . . . . . . . . . . . . 32 110 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 37 112 1. Introduction 114 In response to pervasive monitoring revelations and the IETF 115 consensus that Pervasive Monitoring is an Attack [RFC7258], efforts 116 are underway to increase encryption of Internet traffic. Session 117 encryption helps to prevent both passive and active attacks on 118 transport protocols; more on pervasive monitoring can be found in the 119 Confidentiality in the Face of Pervasive Surveillance: A Threat Model 120 and Problem Statement [RFC7624]. The Internet Architecture Board 121 (IAB) released a statement advocating for increased use of encryption 122 in November 2014. Views on acceptable encryption have also shifted 123 and are documented in "Opportunistic Security" (OS) [RFC7435], where 124 cleartext sessions should be upgraded to unauthenticated session 125 encryption, rather than no encryption. OS encourages upgrading from 126 cleartext, but cannot require or guarantee such upgrades. Once OS is 127 used, it allows for an upgrade to authenticated encryption. These 128 efforts are necessary to improve end user's expectation of privacy, 129 making pervasive monitoring cost prohibitive. Active attacks are 130 still possible on sessions where unauthenticated sessions are in use. 131 The push for ubiquitous encryption via OS is specific to improving 132 privacy for everyday users of the Internet. 134 Although there is a push for OS, there is also work being done to 135 improve implementation development and configuration flaws of TLS and 136 DTLS sessions to prevent active attacks used to monitor or intercept 137 session data. The (UTA) working group is in process of publishing 138 documentation to improve the security of TLS and DTLS sessions. They 139 have documented the known attack vectors in [RFC7457] and have 140 documented Best Practices for TLS and DTLS in [RFC7525] and have 141 other documents in the queue. 143 Estimates for session encryption from spring 2015 approximate that 144 about 30% of web sites have session encryption enabled, according to 145 the Electronic Frontier Foundation [EFF]. The Mozilla Foundation 146 maintains statistics on SSL/TLS usage and as of March 2015, 64% of 147 HTTP transactions are encrypted. Enterprise networks such as EMC 148 observe that about 78% of outbound employee traffic was encrypted in 149 June 2014. Although the actual number of sites may only be around 150 30%, they include some of the most visited sites on the Internet for 151 corporate users. 153 In addition to encrypted web site access (HTTP over TLS), there are 154 other well-deployed application level transport encryption efforts 155 such as mail transfer agent (MTA)-to-MTA session encryption transport 156 for email (SMTP over TLS) and gateway-to-gateway for instant 157 messaging (XMPP over TLS). Although this does provide protection 158 from transport layer attacks, the servers could be a point of 159 vulnerability if user-to-user encryption is not provided for these 160 messaging protocols. User-to-user content encryption schemes, such 161 as S/MIME and PGP for email and encryption (e.g. Off-the-Record 162 (OTR)) for Extensible Messaging and Presence Protocol (XMPP) are used 163 by those interested to protect their data as it crosses intermediary 164 servers, preventing the vulnerability described by providing an end- 165 to-end solution. User-to-user schemes are under review and 166 additional options will emerge to ease the configuration 167 requirements, making this type of option more accessible to non- 168 technical users interested in protecting their privacy. 170 Increased use of encryption (either opportunistic or authenticated) 171 will impact operations for security and network management, causing a 172 shift in how these functions are performed. In some cases new 173 methods to monitor and protect data will evolve, for other cases the 174 need may be eliminated. This draft includes a collection of current 175 security and network management functions that may be impacted by 176 this shift to increased use of encryption. This draft does not 177 attempt to solve these problems, but rather document the current 178 state to assist in the development of alternate options to achieve 179 the intended purpose of the documented practices. 181 In this document we consider several different forms of service 182 providers, so we distinguish between them with adjectives. For 183 example, network service providers (or network operators) provide IP- 184 packet transport primarily, though they may bundle other services 185 with packet transport. Alternatively, application service providers 186 primarily offer systems that participate as an end-point in 187 communications with the application user, and hosting service 188 providers lease computing, storage, and communications systems in 189 datacenters. In practice, many companies perform two or more service 190 provider roles, but may be historically associated with one. 192 2. Network Service Provider Monitoring 194 Network Service Providers (SP) are responding to encryption on the 195 Internet, some helping to increase the use of encryption and others 196 preventing its use. Network SPs for this definition include the 197 backbone Internet Service providers as well as those providing 198 infrastructure at scale for core Internet use (hosted infrastructure 199 and services such as email). 201 Following the Snowden revelations, application service providers 202 responded by encrypting traffic between their data centers to prevent 203 passive monitoring from taking place unbeknownst to the providers 204 (Yahoo, Google, etc.). Large mail service providers also began to 205 encrypt session transport to hosted mail services. This had an 206 immediate impact to help protect the privacy of users data, but 207 created a problem for network operators. They could no longer gain 208 access to session streams resulting in actions by several to regain 209 their operational practices that previously depended on cleartext 210 data sessions. 212 The EFF reported [EFF2014] several network service providers taking 213 steps to prevent the use of SMTP over TLS by breaking STARTTLS 214 (section 3.2 of [RFC7525]), preventing the negotiation process 215 resulting in fallback to the use of clear text. The use of 216 encryption prevents middle boxes from performing functions that range 217 from some methods of load balancing to monitoring for attacks or 218 enabling "lawful intercept", such that described in [ETSI101331] and 219 [CALEA] in the US. These practices are representative of the 220 struggles administrators have with changes in their ability to 221 monitor and manage traffic. 223 2.1. Middlebox Monitoring 225 Network service providers use various monitoring techniques for 226 security and operational purposes. The following subsections detail 227 the purpose of each type of monitoring and what protocol fields are 228 used to accomplish the task. 230 2.1.1. Load Balancers 232 Some network architectures need to share significant traffic load 233 among a pool of parallel systems, to achieve the needed capacity. 234 Load Balancer devices (a form of middlebox) provide the traffic- 235 sharing function, according to pre-defined rules. A general rule for 236 many load balancers requires that all packets comprising an 237 individual flow should to be routed to the same system in the load 238 balancer's pool. The definition of a flow will be based on a 239 combination of header fields, often as many as five for 5-tuple flows 240 (including addresses and ports for source and destination, and one 241 additional field such as the DSCP or other priority marking). 242 Encryption that conceals or replaces the original IP header and/or 243 transport header with modified addresses or ports may result in a set 244 of flows being treated as one for load balancing purposes, which 245 could cause uneven traffic load levels in the pool and unnecessary 246 congestion when capacity limits are approached. 248 2.1.2. Traffic Analysis Fingerprinting 250 Fingerprinting is used in traffic analysis and monitoring to identify 251 traffic streams that match certain patterns. This technique may be 252 used with clear text or encrypted sessions. Some Distributed Denial 253 of Service (DDoS) prevention techniques at the Network SP level rely 254 on the ability to fingerprint traffic in order to mitigate the effect 255 of this type of attack. Thus, fingerprinting may be an aspect of an 256 attack or part of attack countermeasures. 258 The first/obvious trigger for DDoS mitigation is uncharacteristic 259 traffic volume and/or congestion at various points associated with 260 the attackee's communications. One approach to mitigate such an 261 attack involves distinguishing attacker traffic from legitimate user 262 traffic through analysis. The ability to examine layers and payloads 263 above transport provides a new range of filtering opportunities at 264 each layer in the clear. Fewer layers are in the clear means reduced 265 filtering opportunities to mitigate attacks. 267 Traffic analysis fingerprinting could also be used on web traffic to 268 perform passive monitoring and invade privacy. 270 For example, browser fingerprints are comprised of many 271 characteristics, including User Agent, HTTP Accept headers, browser 272 plug-in details, screen size and color details, system fonts and time 273 zone. A monitoring system could easily identify a specific browser, 274 and by correlating other information, identify a specific user. 276 2.1.3. Traffic Surveys 278 Internet traffic surveys are useful in many well-intentioned 279 pursuits, such as CAIDA data [CAIDA] and SP network design and 280 optimization. Tracking the trends in Internet traffic growth, from 281 earlier peer-to-peer communication to the extensive adoption of 282 unicast video streaming applications, has required a view of traffic 283 composition and reports with acceptable accuracy. As application 284 designers and network operators both continue to seek optimizations, 285 the role of traffic surveys from passive monitoring grows in 286 importance. 288 Passive monitoring makes inferences about observed traffic using the 289 maximal information available, and is subject to inaccuracies 290 stemming from incomplete sampling (of packets in a stream) or loss 291 due to monitoring system overload. When encryption conceals more 292 layers in each packet, reliance on pattern inferences and other 293 heuristics grows, and accuracy suffers. For example, the traffic 294 patterns between server and browser are dependent on browser supplier 295 and version, even when the sessions use the same server application 296 (e.g., web e-mail access). It remains to be seen whether more 297 complex inferences can be mastered to produce the same monitoring 298 accuracy. 300 2.1.4. Deep Packet Inspection (DPI) 302 The features and efficiency of some Internet services can be 303 augmented through analysis of user flows and the applications they 304 provide. For example, network caching of popular content at a 305 location close to the requesting user can improve delivery efficiency 306 (both in terms of lower request response times and reduced use of 307 International Internet links when content is remotely located), and 308 authorized parties use DPI in combination with content distribution 309 networks to determine if they can intervene effectively. Web proxies 310 are widely used [WebCache], and caching is supported by the recent 311 update of "Hypertext Transfer Protocol (HTTP/1.1): Caching" in 312 [RFC7234]. Encryption of packet contents at a given protocol layer 313 usually makes DPI processing of that layer and higher layers 314 impossible. 316 Data transfer capacity resources in cellular radio networks tend to 317 be more constrained than in fixed networks. This is a result of 318 variance in radio signal strength as a user moves around a cell, the 319 rapid ingress and egress of connections as users hand-off between 320 adjacent cells, and temporary congestion at a cell. Mobile networks 321 alleviate this by queuing traffic according to its required bandwidth 322 and acceptable latency: for example, a user is unlikely to notice a 323 20ms delay when receiving a simple Web page or email, or an instant 324 message response, but will very likely notice a re-buffering pause in 325 a video playback or a VoIP call de-jitter buffer. Ideally, the 326 scheduler manages the queue so that each user has an acceptable 327 experience as conditions vary, but the traffic type has been required 328 to be known to date. Application and transport layer encryption make 329 the traffic type detection less accurate, and affect queue 330 management. 332 2.1.5. Connection to Proxy for Compression 334 In contrast to DPI, various applications exist to provide data 335 compression in order to conserve the life of the user's mobile data 336 plan and optimize delivery over the mobile link. The compression 337 proxy access can be built into a specific user level application, 338 such as a browser, or it can be available to all applications using a 339 system level application. The primary method is for the mobile 340 application to connect to a centralized server as a proxy, with the 341 data channel between the client application and the server using 342 compression to minimize bandwidth utilization. The effectiveness of 343 such systems depends on the server having access to unencrypted data 344 flows. As the percentage of connections using encryption increases, 345 these data compression services will be rendered less effective, or 346 worse, they will adopt undesirable security practices in order to 347 gain access to the unencrypted data flows. 349 2.1.6. Mobility Middlebox Content Filtering 351 Service Providers may, from time to time, be requested by law 352 enforcement agencies to block access to particular sites such as 353 online betting and gambling, or access to dating sites. Content 354 Filtering can also happen at the endpoints or at the edge of 355 enterprise networks. This section is intended to merely document 356 this current practice by operators and the effects of encryption on 357 the practice. 359 Content filtering in the mobile network usually occurs in the core 360 network. A proxy is installed which analyses the transport metadata 361 of the content users are viewing and either filters content based on 362 a blacklist of sites or based on the user's pre-defined profile (e.g. 363 for age sensitive content). Although filtering can be done by many 364 methods one common method occurs when a DNS lookup of a hostname in a 365 URL which appears on a government or recognized block-list( [RFC7858] 366 aims to address this). The subsequent requests to that domain will 367 be re-routed to a proxy which checks whether the full URL matches a 368 blocked URL on the list, and will return a 404 if a match is found. 369 All other requests should complete. 371 See the Appendix for more information on "Encryption Impact on 372 Mobility Network Optimizations and New Services". 374 2.1.6.1. Parental Controls 376 Another form of content filtering is called parental control, where 377 some users are deliberately denied access to age-sensitive content as 378 a feature to the service subscriber. Some sites involve a mixture of 379 universal and age-sensitive content and filtering software. In these 380 cases, more granular (application layer) metadata may be used to 381 analyze and block traffic, which will not work on encrypted content. 383 2.1.6.2. HTTP Redirection 385 There are cases (beyond parental control) when a mobile network 386 service provider needs to redirect customer requests for content: 388 1. The mobile network service provider is performing the accounting 389 and billing for the content provider, and the customer has not 390 (yet) purchased the requested content. 392 2. Further contenty may not be allowed as the customer has reached 393 their usage limit and needs to purchase additional data service. 395 Currently, the mobile network service provider redirects the customer 396 using HTTP redirect to a page which educates the customer on the 397 reason for the blockage and provide steps to proceed. Once the 398 content is encrypted, the Mobile carrier loses the option to redirect 399 the traffic leaving the option to block the customer's request and 400 cause a bad customer experience untill the blocking reason can be 401 conveyed by some other means. The customer may need to call customer 402 care to find out the reason, both an inconvenience to the customer 403 and additional overhead to the mobile network service provider. 405 2.1.7. Access and Policy Enforcement 407 2.1.7.1. Server load balancing 409 Where network load balancers have been configured to route according 410 to application-layer semantics, an encrypted payload is effectively 411 invisible. This has resulted in practices of intercepting TLS in 412 front of load balancers to regain that visibility, but at a cost to 413 security and privacy. 415 2.1.7.2. Network Access 417 Approved access to a network is a prerequisite to requests for 418 Internet traffic - hence network access, including any authentication 419 and authorization, is not impacted by encryption. 421 Cellular networks often sell tariffs that allow free-data access to 422 certain sites, known as 'zero rating'. A session to visit such a 423 site incurs no additional cost or data usage to the user. This 424 feature may be impacted if encryption hides the details of the 425 content domain from the network. This topic and related material are 426 described further in the Appendix. 428 2.1.7.3. Regulation and policy enforcement 430 Mobile networks (and usually ISPs) operate under the regulations of 431 their licensing government authority. These regulations include 432 Lawful Intercept, adherence to Codes of Practice on content 433 filtering, and application of court order filters. 435 These functions are impacted by encryption, typically by allowing a 436 less granular means of implementation. The enforcement of any Net 437 Neutrality regulations is unlikely to be affected by content being 438 encrypted. The IETF's Policy on Wiretapping can be found in 439 [RFC2804], which does not support wiretapping in standards. 441 2.1.7.4. Application Layer Gateways 443 The policy of some mobile network service providers to deploy 444 Application Layer Gateways (ALG). Section 2.9 of [RFC2663] describes 445 the role of ALG and their interaction with NAT and/or the application 446 payload. ALG are deployed to provide connectivity across Network 447 Address Translators (NAT), Firewalls, and/or Load Balancers for 448 specific applications the mobile network providers choose to support. 449 One example is a video application that uses the Real Time Session 450 Protocol (RTSP) [RFC2326] primary stream as a means to identify 451 related Real Time Protocol/Real Time Control Protocol (RTP/RTCP) 452 [RFC3550] flows at set-up. The ALG relies on the 5-tuple flow 453 information derived from RTSP to provision NAT or other middle boxes 454 and provide connectivity. Implementations vary, and two examples 455 follow: 457 1. Parse the content of the RTSP stream and identify the 5-tuple of 458 the supporting streams as they are being negotiated. 460 2. Intercept and modify the 5-tuple information of the supporting 461 media streams as they are being negotiated on the RTSP stream, 462 which is more intrusive to the media streams. 464 2.1.7.5. HTTP Header Enrichment 466 HTTP header enrichment (see section 3.2.1 of [RFC7230]) has been a 467 mechanism for the mobile carrier to provide "allowed" (Non-Customer 468 Proprietary Network Information) subscriber information to third 469 parties or other internal systems [Enrich]. Third parties can in 470 turn provide customized service, or use it to bill the customer or 471 allow/block selective content. This header-enrichment method is also 472 used within the mobile network service provider to pass information 473 internally between sub-systems, thus keeping the internal systems 474 loosely-coupled. With encryption, the mobile network service 475 provider loses the capability to include any information in the 476 content itself. 478 2.2. Network Monitoring for Performance Management and Troubleshooting 480 Similar to DPI, the performance of some services can be more 481 efficiently managed and repaired when information on user 482 transactions is available to the service provider. It may be 483 possible to continue such monitoring activities without clear text 484 access to the application layers of interest, but inaccuracy will 485 increase and efficiency of repair activities will decrease. For 486 example, an application protocol error or failure would be opaque to 487 network troubleshooters when transport encryption is applied, making 488 root cause location more difficult and therefore increasing the time- 489 to-repair. Repair time directly reduces the availability of the 490 service, and availability is a key metric for Service Level 491 Agreements and subscription rebates. Also, there may be more cases 492 of user communication failures when the additional encryption 493 processes are introduced, leading to more customer service contacts 494 and (at the same time) less information available to network 495 operations repair teams. 497 With the growing use of WebSockets [RFC6455], many forms of 498 communications (from isochronous/real-time to bulk/elastic file 499 transfer) will take place over HTTP port 80 or port 443, so only the 500 messages and higher-layer data will make application differentiation 501 possible. If the monitoring systems sees only "HTTP port 443", it 502 cannot distinguish application streams that would benefit from 503 priority queueing from others that would not. 505 3. Encryption in Hosting SP Environments 507 Hosted environments have had varied requirements in the past for 508 encryption, with many businesses choosing to use these services 509 primarily for data and applications that are not business or privacy 510 sensitive. A shift prior to the revelations on surveillance/passive 511 monitoring began where businesses were asking for hosted environments 512 to provide higher levels of security so that additional applications 513 and service could be hosted externally. Businesses understanding the 514 threats of monitoring in hosted environments only increased that 515 pressure to provide more secure access and session encryption to 516 protect the management of hosted environments as well as for the data 517 and applications. 519 3.1. Management Access Security 521 Hosted environments may have multiple levels of management access, 522 where some may be strictly for the Hosting SP (infrastructure that 523 may be shared among customers) and some may be accessed by a specific 524 customer for application management. In some cases, there are 525 multiple levels of hosting service providers, further complicating 526 the security of management infrastructure and the associated 527 requirements. 529 Hosting service provider management access is typically segregated 530 from other traffic with a control channel and may or may not be 531 encrypted depending upon the isolation characteristics of the 532 management session. Customer access may be through a dedicated 533 connection, but discussion for that connection method is out-of- 534 scope. 536 3.1.1. Customer Access Monitoring 538 Hosted applications that allow some level of customer management 539 access may also require monitoring by the hosting service provider. 540 The monitoring needs could include access control restrictions such 541 as authentication, authorization, and accounting for filtering and 542 firewall rules to ensure they are continuously met. Customer access 543 may occur on multiple levels, including user-level and administrative 544 access. The hosting service provider may need to monitor access 545 either through session monitoring or log evaluation to ensure 546 security service level agreements (SLA) for access management are 547 met. The use of session encryption to access hosted environments 548 limits access restrictions to the metadata described below. 549 Monitoring and filtering may occur at an: 551 2-tuple IP-level with source and destination IP addresses alone, or 553 5-tuple IP and protocol-level with source IP address, destination IP 554 address, protocol number, source port number, and destination port 555 number. 557 Session encryption at the application level, TLS for example, 558 currently allows access to the 5-tuple. IP-level encryption, such as 559 IPsec in tunnel mode prevents access to the 5-tuple and may limit the 560 ability to restrict traffic via filtering techniques. This shift may 561 not impact all hosting service provider solutions as alternate 562 controls may be used to authenticate sessions or access may require 563 that clients access such services by first connecting to the 564 organization before accessing the hosted application. Shifts in 565 access may be required to maintain equivalent access control 566 management. Logs may also be used for monitoring access control 567 restrictions are met, but would be limited to the data that could be 568 observed due to encryption at the point of log generation. Log 569 analysis is out of scope for this document. 571 3.1.2. Application SP Content Monitoring 573 The following observations apply to any IT organization that is 574 responsible for delivering services, whether to third-parties, for 575 example as a web based service, or to internal customers in an 576 enterprise, e.g. a data processing system that forms a part of the 577 enterprise's business. 579 Organizations responsible for the operation of a data center have 580 many processes which access the contents of IP packets (passive 581 methods of measurement, as defined in [RFC7799]). These processes 582 are typically for service assurance or security purposes and form an 583 integral and mission-critical part of data center operations. 585 Examples include: 587 - Network Performance Monitoring/Application Performance 588 Monitoring 590 - Intrusion defense/prevention systems 592 - Malware detection 594 - Fraud Monitoring 596 - Application DDOS protection 598 - Cyber-attack investigation 600 - Proof of regulatory compliance 602 Many application service providers simply terminate sessions to/from 603 the Internet at the edge of the data center in the form of SSL/TLS 604 offload in the load balancer. Not only does this reduce the load on 605 application servers, it simplifies the processes listed above. 607 However, in some situations, encryption deeper in the data center may 608 be necessary to protect personal information or in order to meet 609 industry regulations, e.g. those set out by the Payment Card Industry 610 (PCI). In such situations, various methods can be used to allow 611 trusted service assurance and security processes to access 612 unencrypted data. These include SSL/TLS decryption in dedicated 613 units, which then forward packets to trusted tools, or by real-time 614 or post-capture decryption in the tools themselves. 616 Data center operators may also maintain packet recordings in order to 617 be able to investigate attacks, breach of internal processes, etc. 618 In some industries, organizations may be legally required to maintain 619 such information for compliance purposes. Investigations of this 620 nature require access to the unencrypted contents of the packet. 622 Application Service Providers may offer content-level monitoring 623 options to detect intellectual property leakage, or other attacks. 624 The use of session encryption will prevent Data Leakage Protection 625 (DLP) used on the session streams from accessing content to search on 626 keywords or phases to detect such leakage. DLP is often used to 627 prevent the leakage of Personally Identifiable Information (PII) as 628 well as financial account information, Personal Health Information 629 (PHI), and Payment Card Information (PCI). If session encryption is 630 terminated at a gateway prior to accessing these services, DLP on 631 session data can still be performed. The decision of where to 632 terminate encryption to hosted environments will be a risk decision 633 made between the application service provider and customer 634 organization according to their priorities. DLP can be performed at 635 the server for the hosted application and on an end users system in 636 an organization as alternate or additional monitoring points of 637 content, however this is not frequently done in a service provider 638 environment. 640 Secure overlay networks (for example, VXLAN) may be used in multi- 641 tenancy scenarios to provide isolation assurance and thwart some 642 active attacks. Section 7 of [RFC7348] describes some of the 643 security issues possible when deploying VXLAN on Layer 2 networks. 644 Rogue endpoints can join the multicast groups that carry broadcast 645 traffic, for example. Tunneled traffic on VXLAN can be secured by 646 using IPsec, but this adds the requirement for authentication 647 infrastructure and may reduce packet transfer performance. 648 Deployment of data path acceleration technologies can help to 649 mitigate the performance issues, but they also bring more complex 650 networking and management. 652 3.2. Hosted Applications 654 Organizations are increasingly using hosted applications rather than 655 in house solutions that require maintenance of equipment and 656 software. Examples include Enterprise Resource Planning (ERP) 657 solutions, payroll service, time and attendance, travel and expense 658 reporting among others. Organizations may require some level of 659 management access to these hosted applications and will typically 660 require session encryption or a dedicated channel for this activity. 662 In other cases, hosted applications may be fully managed by a hosting 663 service provider with service level agreement expectations for 664 availability and performance as well as for security functions 665 including malware detection. 667 3.2.1. Monitoring needs for Managed Applications 669 Performance, availability, and other aspects of a SLA are often 670 collected through passive monitoring. For example: 672 o Availability: ability to establish connections with hosts to 673 access applications, and discern the difference between network or 674 host-related causes of unavailability. 676 o Performance: ability to complete transactions within a target 677 response time, and discern the difference between network or host- 678 related causes of excess response time. 680 Here, as with all passive monitoring, the accuracy of inferences are 681 dependent on the cleartext information available, and encryption 682 would tend to reduce the information and therefore, the accuracy of 683 each inference. Passive measurement of some metrics will be 684 impossible with encryption that prevents inferring packet 685 correspondence across multiple observation points, such as for packet 686 loss metrics. 688 3.2.2. Mail Service Providers 690 Mail (application) service providers vary in what services they 691 offer. Options may include a fully hosted solution where mail is 692 stored external to an organization's environment on mail service 693 provider equipment or the service offering may be limited to monitor 694 incoming mail to remove SPAM [Section 5.1], malware [Section 5.6], 695 and phishing attacks [Section 5.3] before mail is directed to the 696 organization's equipment. In both of these cases, content of the 697 messages and headers is monitored to detect SPAM, malware, phishing, 698 and other messages that may be considered an attack. 700 STARTTLS ought have zero effect on anti-SPAM efforts for SMTP 701 traffic. Anti-SPAM services could easily be performed on an SMTP 702 gateway, eliminating the need for TLS decryption services. 704 Many efforts are emerging to improve user-to-user encryption to 705 protect end user's privacy. There are no clear front runners with 706 efforts ranging from proprietary to open source ones like "Dark 707 Mail". 709 3.3. Data Storage 711 Numerous service offerings exist that provide hosted storage 712 solutions. This section describes the various offerings and details 713 the monitoring for each type of service and how encryption may impact 714 the operational and security monitoring performed. 716 Trends in data storage encryption for hosted environments include a 717 range of options. The following list is intentionally high-level to 718 describe the types of encryption used in coordination with data 719 storage that may be hosted remotely, meaning the storage is 720 physically located in an external data center requiring transport 721 over the Internet. Options for monitoring will vary with both 722 approaches from what may be done today. 724 3.3.1. Host-level Encryption 726 For higher security and/or privacy of data and applications, options 727 that provide end-to-end encryption of the data from the users desktop 728 or server to the storage platform may be preferred. With this 729 description, host level encryption includes any solution that 730 encrypts data at the object level, not transport level. Encryption 731 of data may be performed with libraries on the system or at the 732 application level, which includes file encryption services via a file 733 manager. Host-level encryption is useful when data storage is 734 hosted, or scenarios when storage location is determined based on 735 capacity or based on a set of parameters to automate decisions. This 736 could mean that large data sets accessed infrequently could be sent 737 to an off-site storage platform at an external hosting service, data 738 accessed frequently may be stored locally, or the decision could be 739 based on the transaction type. Host-level encryption is grouped 740 separately for the purpose of this document as the monitoring needs 741 as this data can be stored in multiple locations including off-site 742 remote storage platforms. If session encryption is used, the 743 protocol is likely to be TLS. 745 3.3.1.1. Monitoring for Hosted Storage 747 The general monitoring needs of hosted storage solutions that use 748 host-level (object) encryption is described in this subsection. 749 Solutions might include backup services and external storage 750 services, such as those that burst data that exceeds internal limits 751 on occasion to external storage platforms operated by a third party. 753 Monitoring of data flows to hosted storage solutions is performed for 754 security and operational purposes. The security monitoring may be to 755 detect anomalies in the data flows that could include changes to 756 destination, the amount of data transferred, or alterations in the 757 size and frequency of flows. Operational considerations include 758 capacity and availability monitoring. 760 3.3.2. Disk Encryption, Data at Rest 762 There are multiple ways to achieve full disk encryption for stored 763 data. Encryption may be performed on data to be stored while in 764 transit close to the storage media with solutions like Controller 765 Based Encryption (CBE) or in the drive system with Self-Encrypting 766 Drives (SED). Session encryption is typically coupled with 767 encryption of these data at rest (DAR) solutions to also protect data 768 in transit. Transport encryption is likely via TLS. 770 3.3.2.1. Monitoring Session Flows for DAR Solutions 772 The general monitoring needs for transport of data to storage 773 platforms, where object level encryption is performed close to or on 774 the storage platform are similar to those described in the section on 775 Monitoring for Hosted Storage. The primary difference for these 776 solutions is the possible exposure of sensitive information, which 777 could include privacy related data, financial information, or 778 intellectual property if session encryption via TLS is not deployed. 779 Session encryption is typically used with these solutions, but that 780 decision would be based on a risk assessment. There are use cases 781 where DAR or disk-level encryption is required. Examples include 782 preventing exposure of data if physical disks are stolen or lost. 784 3.3.3. Cross Data Center Replication Services 786 Storage services also include data replication which may occur 787 between data centers and may leverage Internet connections to tunnel 788 traffic. The traffic may use iSCSI [RFC7143] or FC/IP [RFC7146] 789 encapsulated in IPsec. Either transport or tunnel mode may be used 790 for IPsec depending upon the termination points of the IPsec session, 791 if it is from the storage platform itself or from a gateway device at 792 the edge of the data center respectively. 794 3.3.3.1. Monitoring Of IPSec for Data Replication Services 796 The general monitoring needs for data replication are described in 797 this subsection. 799 Monitoring of data flows between data centers may be performed for 800 security and operational purposes and would typically concentrate 801 more on the operational needs since these flows are essentially 802 virtual private networks (VPN) between data centers. Operational 803 considerations include capacity and availability monitoring. The 804 security monitoring may be to detect anomalies in the data flows, 805 similar to what was described in the "Monitoring for Hosted Storage 806 Section". 808 4. Encryption for Enterprises 810 Encryption of network traffic within the private enterprise is a 811 growing trend, particularly in industries with audit and regulatory 812 requirements. Some enterprise internal networks are almost 813 completely TLS and/or IPsec encrypted. 815 For each type of monitoring, different techniques and access to parts 816 of the data stream are part of current practice. As we transition to 817 an increased use of encryption, alternate methods of monitoring for 818 operational purposes may be necessary to reduce the need to break 819 encryption and thus privacy of users (other policies may apply in 820 some enterprise settings). 822 4.1. Monitoring Needs of the Enterprise 824 Large corporate enterprises are the owners of the platforms, data, 825 and network infrastructure that provide critical business services to 826 their user communities. As such, these enterprises are responsible 827 for all aspects of the performance, availability, security, and 828 quality of experience for all user sessions. These responsibilities 829 break down into three basic areas: 831 1. Security Monitoring and Control 833 2. Application Performance Monitoring and Reporting 835 3. Network Diagnostics and Troubleshooting 837 In each of the above areas, technical support teams utilize 838 collection, monitoring, and diagnostic systems. Some organizations 839 currently use attack methods such as replicated TLS server RSA 840 private keys to decrypt passively monitored copies of encrypted TLS 841 packet streams. 843 For an enterprise to avoid costly application down time and deliver 844 expected levels of performance, protection, and availability, some 845 forms of traffic analysis sometimes including examination of packet 846 payloads are currently used. 848 4.1.1. Security Monitoring in the Enterprise 850 Enterprise users are subject to the policies of their organization 851 and the jurisdictions in which the enterprise operates. As such, 852 proxies may be in use to: 854 1. intercept outbound session traffic to monitor for intellectual 855 property leakage (by users or more likely these days through 856 malware and trojans), 858 2. detect viruses/malware entering the network via email or web 859 traffic, 861 3. detect malware/Trojans in action, possibly connecting to remote 862 hosts, 864 4. detect attacks (Cross site scripting and other common web related 865 attacks), 867 5. track misuse and abuse by employees, 869 6. restrict the types of protocols permitted to/from the entire 870 corporate environment, 872 7. detect and defend against Internet DDoS attacks, including both 873 volumetric and layer 7 attacks. 875 A significant portion of malware hides its activity within TLS or 876 other encrypted protocols. This includes lateral movement, Command 877 and Control, and Data Exfiltration. Detecting these functions are 878 important to effective monitoring and mitigation of malicious 879 traffic, not limited to malware. 881 4.1.2. Application Performance Monitoring in the Enterprise 883 There are two main goals of monitoring: 885 1. Assess traffic volume on a per-application basis, for billing, 886 capacity planning, optimization of geographical location for 887 servers or proxies, and other needs. 889 2. Assess performance in terms of application response time and user 890 perceived response time. 892 Network-based Application Performance Monitoring tracks application 893 response time by user and by URL, which is the information that the 894 application owners and the lines of business need. Content Delivery 895 Networks (CDNs) add complexity in determining the ultimate endpoint 896 destination. By their very nature, such information is obscured by 897 CDNs and encrypted protocols -- adding a new challenge for 898 troubleshooting network and application problems. URL identification 899 allows the application support team to do granular, code level 900 troubleshooting at multiple tiers of an application. 902 New methodologies to monitor user perceived response time and to 903 separate network from server time are evolving. For example, the 904 IPv6 Destination Option Header (DOH) implementation of Performance 905 and Diagnostic Metrics (PDM) will provide this 906 [I-D.ietf-ippm-6man-pdm-option]. Using PDM with IPSec Encapsulating 907 Security Payload (ESP) Transport Mode requires placement of the PDM 908 DOH within the ESP encrypted payload to avoid leaking timing and 909 sequence number information that could be useful to an attacker. Use 910 of PDM DOH also may introduce some security weaknesses, including a 911 timing attack, as described in Section 7 of 912 [I-D.ietf-ippm-6man-pdm-option]. For these and other reasons, 913 [I-D.ietf-ippm-6man-pdm-option] requires that the PDM DOH option be 914 explicitly turned on by administrative action in each host where this 915 measurement feature will be used. 917 4.1.3. Enterprise Network Diagnostics and Troubleshooting 919 One primary key to network troubleshooting is the ability to follow a 920 transaction through the various tiers of an application in order to 921 isolate the fault domain. A variety of factors relating to the 922 structure of the modern data center and the modern multi-tiered 923 application have made it difficult to follow a transaction in network 924 traces without the ability to examine some of the packet payload. 925 Alternate methods, such as log analysis need improvement to fill this 926 gap. 928 4.1.3.1. NAT 930 Content Delivery Networks (CDNs) and NATs obscure the ultimate 931 endpoint designation. Troubleshooting a problem for a specific end 932 user requires finding information such as the IP address and other 933 identifying information so that their problem can be resolved in a 934 timely manner. 936 NAT is also frequently used by lower layers of the data center 937 infrastructure. Firewalls, Load Balancers, Web Servers, App Servers, 938 and Middleware servers all regularly NAT the source IP of packets. 939 Combine this with the fact that users are often allocated randomly by 940 load balancers to all these devices, the network troubleshooter is 941 often left with very few options in today's environment due to poor 942 logging implementations in applications. As such, network 943 troubleshooting is used to trace packets at a particular layer, 944 decrypt them, and look at the payload to find a user session. 946 This kind of bulk packet capture and bulk decryption is frequently 947 used when troubleshooting a large and complex application. Endpoints 948 typically don't have the capacity to handle this level of network 949 packet capture, so out-of-band networks of robust packet brokers and 950 network sniffers that use techniques such as copies of TLS RSA 951 private keys accomplish this task today. 953 4.1.3.2. TCP Pipelining/Session Multiplexing 955 TCP Pipelining/Session Multiplexing used mainly by middle boxes today 956 allow for multiple end user sessions to share the same TCP 957 connection. Today's network troubleshooter often relies upon session 958 decryption to tell which packet belongs to which end user as the logs 959 are currently inadequate for the analysis needed. 961 With the advent of HTTP2, session multiplexing will be used 962 ubiquitously, both on the Internet and in the private data center. 964 4.1.3.3. HTTP Service Calls 966 When an application server makes an HTTP service call to back end 967 services on behalf of a user session, it uses a completely different 968 URL and a completely different TCP connection. Troubleshooting via 969 network trace involves matching up the user request with the HTTP 970 service call. Some organizations do this today by decrypting the TLS 971 packet and inspecting the payload. Logging has not been adequate for 972 their purposes. 974 4.1.3.4. Application Layer Data 976 Many applications use text formats such as XML to transport data or 977 application level information. When transaction failures occur and 978 the logs are inadequate to determine the cause, network and 979 application teams work together, each having a different view of the 980 transaction failure. Using this troubleshooting method, the network 981 packet is correlated with the actual problem experienced by an 982 application to find a root cause. The inability to access the 983 payload prevents this method of troubleshooting. 985 4.2. Techniques for Monitoring Internet Session Traffic 987 Corporate networks commonly monitor outbound session traffic to 988 detect or prevent attacks as well as to guarantee service level 989 expectations. In some cases, alternate options are available when 990 encryption is in use, but techniques like that of data leakage 991 prevention tools at a proxy would not be possible if encrypted 992 traffic can not be intercepted, encouraging alternate options such as 993 performing these functions at the edge. 995 Data leakage detection prevention (DLP) tools intercept traffic at 996 the Internet gateway or proxy services with the ability to man-in- 997 the-middle (MiTM) encrypted session traffic (HTTP/TLS). These tools 998 may use key words important to the enterprise including business 999 sensitive information such as trade secrets, financial data, 1000 personally identifiable information (PII), or personal health 1001 information (PHI). Various techniques are used to intercept HTTP/TLS 1002 sessions for DLP and other purposes, and are described in 1003 "Summarizing Known Attacks on TLS and DTLS" [RFC7457]. Note: many 1004 corporate policies allow access to personal financial and other sites 1005 for users without interception. 1007 Monitoring traffic patterns for anomalous behavior such as increased 1008 flows of traffic that could be bursty at odd times or flows to 1009 unusual destinations (small or large amounts of traffic). This 1010 traffic may or may not be encrypted and various methods of encryption 1011 or just obfuscation may be used. 1013 Restrictions on traffic to approved sites: Web proxies are sometimes 1014 used to filter traffic, allowing only access to well-known sites 1015 found to be legitimate and free of malware on last check by a proxy 1016 service company. This type of restriction is usually not noticeable 1017 in a corporate setting, but may be to those in research who are 1018 unable to access colleague's individual sites or new web sites that 1019 have not yet been screened. In situations where new sites are 1020 required for access, they can typically be added after notification 1021 by the user or proxy log alerts and review. Home mail account access 1022 may be blocked in corporate settings to prevent another vector for 1023 malware to enter as well as for intellectual property to leak out of 1024 the network. This method remains functional with increased use of 1025 encryption and may be more effective at preventing malware from 1026 entering the network. Web proxy solutions monitor and potentially 1027 restrict access based on the destination URL or the DNS name. A 1028 complete URL may be used in cases where access restrictions vary for 1029 content on a particular site or for the sites hosted on a particular 1030 server. 1032 Desktop DLP tools are used in some corporate environments as well. 1033 Since these tools reside on the desktop, they can intercept traffic 1034 before it is encrypted and may provide a continued method of 1035 monitoring intellectual property leakage from the desktop to the 1036 Internet or attached devices. 1038 DLP tools can also be deployed by Network Service providers, as they 1039 have the vantage point of monitoring all traffic paired with 1040 destinations off the enterprise network. This makes an effective 1041 solution for enterprises that allow "bring-your-own" devices when the 1042 traffic is not encrypted and devices that do not fit the desktop 1043 category, but are used on corporate networks nonetheless. 1045 Enterprises may wish to reduce the traffic on their Internet access 1046 facilities by monitoring requests for within-policy content and 1047 caching it. In this case, repeated requests for Internet content 1048 spawned by URLs in e-mail trade newsletters or other sources can be 1049 served within the enterprise network. Gradual deployment of end to 1050 end encryption would tend to reduce the cacheable content over time, 1051 owing to concealment of critical headers and payloads. Many forms of 1052 enterprise performance management and optimization based on 1053 monitoring (DPI) would suffer the same fate. 1055 5. Security Monitoring for Specific Attack Types 1057 Effective incident response today requires collaboration at Internet 1058 scale. This section will only focus on efforts of collaboration at 1059 Internet scale that are dedicated to specific attack types. They may 1060 require new monitoring and detection techniques in an increasingly 1061 encrypted Internet. As mentioned previously, some service providers 1062 have been interfering with STARTTLS to prevent session encryption to 1063 be able to perform functions they are used to (injecting ads, 1064 monitoring, etc.). By detailing the current monitoring methods used 1065 for attack detection and response, this information can be used to 1066 devise new monitoring methods that will be effective in the changed 1067 Internet via collaboration and innovation. 1069 5.1. Mail Abuse and SPAM 1071 The largest operational effort to prevent mail abuse is through the 1072 Messaging, Malware, Mobile Anti-Abuse Working Group (M3AAWG)[M3AAWG]. 1073 Mail abuse is combated directly with mail administrators who can shut 1074 down or stop continued mail abuse originating from large scale 1075 providers that participate in using the Abuse Reporting Format (ARF) 1076 agents standardized in the IETF [RFC5965], [RFC6430], [RFC6590], 1077 [RFC6591], [RFC6650], [RFC6651], and [RFC6652]. The ARF agent 1078 directly reports abuse messages to the appropriate service provider 1079 who can take action to stop or mitigate the abuse. Since this 1080 technique uses the actual message, the use of SMTP over TLS between 1081 mail gateways will not effect its usefulness. As mentioned 1082 previously, SMTP over TLS only protects data while in transit and the 1083 messages may be exposed on mail servers or mail gateways if a user- 1084 to-user encryption method is not used. Current user-to-user message 1085 encryption methods on email (S/MIME and PGP) do not encrypt the email 1086 header information used by ARF and the service provider operators in 1087 their abuse mitigation efforts. 1089 5.2. Denial of Service 1091 Response to Denial of Service (DoS) attacks are typically coordinated 1092 by the SP community with a few key vendors who have tools to assist 1093 in the mitigation efforts. Traffic patterns are determined from each 1094 DoS attack to stop or rate limit the traffic flows with patterns 1095 unique to that DoS attack. 1097 Data types used in monitoring traffic for DDoS are described in the 1098 DDoS Open Threat Signaling (DOTS) working group documents in 1099 development. 1101 Data types used in DDoS attacks have been detailed in the IODEF 1102 Guidance draft [I-D.ietf-mile-iodef-guidance], Appendix A.2, with the 1103 help of several members of the service provider community. The 1104 examples provided are intended to help identify the useful data in 1105 detecting and mitigating these attacks independent of the transport 1106 and protocol descriptions in the drafts. 1108 5.3. Phishing 1110 Investigations and response to phishing attacks follow well-known 1111 patterns, requiring access to specific fields in email headers as 1112 well as content from the body of the message. When reporting 1113 phishing attacks, the recipient has access to each field as well as 1114 the body to make content reporting possible, even when end-to-end 1115 encryption is used. The email header information is useful to 1116 identify the mail servers and accounts used to generate or relay the 1117 attack messages in order to take the appropriate actions. The 1118 content of the message often contains an embedded attack that may be 1119 in an infected file or may be a link that results in the download of 1120 malware to the users system. 1122 Administrators often find it helpful to use header information to 1123 track down similar message in their mail queue or users inboxes to 1124 prevent further infection. Combinations of To:, From:, Subject:, 1125 Received: from header information might be used for this purpose. 1126 Administrators may also search for document attachments of the same 1127 name, size, or containing a file with a matching hash to a known 1128 phishing attack. Administrators might also add URLs contained in 1129 messages to block lists locally or this may also be done by browser 1130 vendors through larger scales efforts like that of the Anti-Phishing 1131 Working Group (APWG). 1133 A full list of the fields used in phishing attack incident response 1134 can be found in RFC5901. Future plans to increase privacy 1135 protections may limit some of these capabilities if some email header 1136 fields are encrypted, such as To:, From:, and Subject: header fields. 1138 This does not mean that those fields should not be encrypted, only 1139 that we should be aware of how they are currently used. Alternate 1140 options to detect and prevent phishing attacks may be needed. More 1141 recent examples of data exchanged in spear phishing attacks has been 1142 detailed in the IODEF Guidance draft [I-D.ietf-mile-iodef-guidance], 1143 Appendix A.3. 1145 5.4. Botnets 1147 Botnet detection and mitigation is complex and may involve hundreds 1148 or thousands of hosts with numerous Command and Control (C&C) 1149 servers. The techniques and data used to monitor and detect each may 1150 vary. Connections to C&C servers are typically encrypted, therefore 1151 a move to an increasingly encrypted Internet may not affect the 1152 detection and sharing methods used. 1154 5.5. Malware 1156 Malware monitoring and detection techniques vary. As mentioned in 1157 the enterprise section, malware monitoring may occur at gateways to 1158 the organization analyzing email and web traffic. These services can 1159 also be provided by service providers, changing the scale and 1160 location of this type of monitoring. Additionally, incident 1161 responders may identify attributes unique to types of malware to help 1162 track down instances by their communication patterns on the Internet 1163 or by alterations to hosts and servers. 1165 Data types used in malware investigations have been summarized in an 1166 example of the IODEF Guidance draft [I-D.ietf-mile-iodef-guidance], 1167 Appendix A.1. 1169 5.6. Spoofed Source IP Address Protection 1171 The IETF has reacted to spoofed source IP address-based attacks, 1172 recommending the use of network ingress filtering [RFC2827] and the 1173 unicast Reverse Path Forwarding (uRPF) mechanism [RFC2504]. But uRPF 1174 suffers from limitations regarding its granularity: a malicious node 1175 can still use a spoofed IP address included inside the prefix 1176 assigned to its link. The Source Address Validation Improvements 1177 (SAVI) mechanisms try to solve this issue. Basically, a SAVI 1178 mechanism is based on the monitoring of a specific address 1179 assignment/management protocol (e.g., SLAAC [RFC4682], SEND 1180 [RFC3791], DHCPv4/v6 [RFC2131][RFC3315]) and, according to this 1181 monitoring, set-up a filtering policy allowing only the IP flows with 1182 a correct source IP address (i.e., any packet with a source IP 1183 address, from a node not owning it, is dropped). The encryption of 1184 parts of the address assignment/management protocols, critical for 1185 SAVI mechanisms, can result in a dysfunction of the SAVI mechanisms. 1187 5.7. Further work 1189 Although incident response work will continue, new methods to prevent 1190 system compromise through security automation and continuous 1191 monitoring [SACM] may provide alternate approaches where system 1192 security is maintained as a preventative measure. 1194 6. Application-based Flow Information Visible to a Network 1196 This section describes specific techniques used in monitoring 1197 applications that may apply to various network types. 1199 6.1. TLS Server Name Indication 1201 When initiating the TLS handshake, the Client may provide an 1202 extension field (server_name) which indicates the server to which it 1203 is attempting a secure connection. TLS SNI was standardized in 2003 1204 to enable servers to present the "correct TLS certificate" to clients 1205 in a deployment of multiple virtual servers hosted by the same server 1206 infrastructure and IP-address. Although this is an optional 1207 extension, it is today supported by all modern browsers, web servers 1208 and developer libraries. It should be noted that HTTP/2 introduces 1209 the Alt-SVC method for upgrading the connection from HTTP/1 to either 1210 unencrypted or encrypted HTTP/2. If the initial HTTP/1 request is 1211 unencrypted, the destination alternate service name can be identified 1212 before the communication is potentially upgraded to encrypted HTTP/2 1213 transport. HTTP/2 implementations MUST support the Server Name 1214 Indication (SNI) extension. 1216 This information is only visible if the client is populating the 1217 Server Name Indication extension. This need not be done, but may be 1218 done as per TLS standard. Therefore, even if existing network 1219 filters look out for seeing a Server Name Indication extension, they 1220 may not find one. The per-domain nature of SNI may not reveal the 1221 specific service or media type being accessed, especially where the 1222 domain is of a provider offering a range of email, video, Web pages 1223 etc. For example, certain blog or social network feeds may be deemed 1224 'adult content', but the Server Name Indication will only indicate 1225 the server domain rather than a URL path. 1227 6.2. Application Layer Protocol Negotiation (ALPN) 1229 ALPN is a TLS extension which may be used to indicate the application 1230 protocol within the TLS session. This is likely to be of more value 1231 to the network where it indicates a protocol dedicated to a 1232 particular traffic type (such as video streaming) rather than a 1233 multi-use protocol. ALPN is used as part of HTTP/2 'h2', but will 1234 not indicate the traffic types which may make up streams within an 1235 HTTP/2 multiplex. 1237 6.3. Content Length, BitRate and Pacing 1239 The content length of encrypted traffic is effectively the same as 1240 the cleartext. Although block ciphers utilise padding this makes a 1241 negligible difference. Bitrate and pacing are generally application 1242 specific, and do not change much when the content is encrypted. 1243 Multiplexed formats (such as HTTP/2 and QUIC) may however incorporate 1244 several application streams over one connection, which makes the 1245 bitrate/pacing no longer application-specific. 1247 7. Response to Increased Encryption and Looking Forward 1249 In the best case scenario, engineers and other innovators would work 1250 to solve the problems at hand in new ways rather than prevent the use 1251 of encryption. It will take time to devise alternate approaches to 1252 achieve similar goals. 1254 There has already been documented cases of service providers 1255 preventing STARTTLS [NoEncrypt] to prevent session encryption 1256 negotiation on some session to inject a super cookie. 1258 National surveillance programs have a clear need for monitoring 1259 terrorism [JNSLP] as do Internet security practitioners monitoring 1260 for criminal activities. Governments vary on their balance between 1261 their need for monitoring versus the protection of user privacy, 1262 data, and assets. Those that favor unencrypted access to data ignore 1263 the real need to protect users identity, financial transactions and 1264 intellectual property, which requires security and encryption to 1265 prevent crime. A clear understanding of technology, encryption, and 1266 monitoring needs will aid in the development of solutions to 1267 appropriately balance the need of privacy. As this understanding 1268 increases, hopefully the discussions will improve and this draft is 1269 meant to help further the discussion. 1271 Terrorists and criminals have been using encryption for many years. 1272 The current push to increase encryption is aimed at increasing users 1273 privacy. There is already protection in place for purchases, 1274 financial transactions, systems management infrastructure, and 1275 intellectual property although this too can be improved. The 1276 Opportunistic Security (OS) [RFC7435] efforts aim to increase the 1277 costs of monitoring through the use of encryption that can be subject 1278 to active attacks, but make passive monitoring broadly cost 1279 prohibitive. This is meant to restrict monitoring to sessions where 1280 there is reason to have suspicion. 1282 Open questions: As the use of encryption increases, does passive 1283 monitoring become limited to metadata analysis? What metadata should 1284 be left in protocols as they evolve to also protect users privacy? 1285 Can we make changes to protocols and message exchanges to alter the 1286 current monitoring needs at least for operations and security 1287 practitioners? 1289 Options are on the technology horizon that could help to end the 1290 struggle between the need to monitor by operators, security teams, 1291 and nations and those seeking to protect users privacy if they come 1292 to fruition. The solutions are very interesting, but are at least 1293 several years out and include homomorphic encrypt, functional 1294 encryption, and filterable decryption [homomorphic]. This technology 1295 will allow for searching and pattern matching on encrypted data, but 1296 is still several years out. 1298 8. Security Considerations 1300 There are no additional security considerations as this is a summary 1301 and does not include a new protocol or functionality. 1303 9. IANA Considerations 1305 This memo makes no requests of IANA. 1307 10. Acknowledgements 1309 Thanks to our reviewers, Natasha Rooney, Kevin Smith, Ashutosh Dutta, 1310 Brandon Williams, Jean-Michel Combes, Nalini Elkins, Paul Barrett, 1311 and Stephen Farrell for their editorial and content suggestions. 1312 Surya K. Kovvali provided material for the Appendix. 1314 11. Appendix: Impact on Mobility Network Optimizations and New Services 1316 This Appendix considers the effects of transport level encryption on 1317 existing forms of mobile network optimization techniques, as well as 1318 potential new services. The material in this Appendix assumes 1319 familiarity with mobile network concepts, specifications, and 1320 architectures. Readers who need additional background should start 1321 with the 3GPP's web pages on various topics of interest[Web3GPP], 1322 especially the article on LTE. 3GPP provides a mapping between their 1323 expanding technologies and the different series of technical 1324 specifications [Map3GPP]. 3GPP also has a canonical specification of 1325 their vocabulary, definitions, and acronyms [Vocab], as does the RFC 1326 Editor for abbreviations [RFCEdit]. 1328 11.1. Effect of Encypted ACKs 1330 The stream of TCP ACKs that flow from a receiver of a byte stream 1331 using TCP for reliability, flow-control, and NAT/firewall transversal 1332 is called an ACK stream. The ACKs contain segment numbers that 1333 confirm successful transmission and their RTT, or indicate packet 1334 loss (duplicate ACKs). If this view of progress of stream transfer 1335 is lost, then the mobile network has greatly reduced ability to 1336 monitor transport layer performance. When the ACK stream is 1337 encrypted, it prevents the following mobile network features from 1338 operating: 1340 a. Measurement of Network Segment (Sector, eNodeB (eNB) etc.) 1341 characterization KPIs (Retransmissions, packet drops, Sector 1342 Utilization Level etc.), estimation of User/Service KQIs at 1343 network edges for circuit emulation (CEM), and mitigation 1344 methods. The active services per user and per sector are not 1345 visible to a server that only services Internet Access Point 1346 Names (APN), and thus could not perform mitigation functions 1347 based on network segment view. 1349 b. Retransmissions by trusted proxies at network edges that improve 1350 live transmission over long delay, capacity-varying networks. 1352 c. Content replication near the network edge (for example live 1353 video, DRM protected content) to maximize QOE. Replicating every 1354 stream through the transit network increases backhaul cost for 1355 live TV. 1357 d. Ability to deploy trusted proxies that reduce control round-trip 1358 time (RTT) between the TCP transmitter and receiver. The RTT 1359 determines how quickly a user's attempt to cancel a video is 1360 recognized (how quickly the traffic is stopped, thus keeping un- 1361 wanted video packets from entering the radio scheduler queue). 1363 e. Trusted proxy with low RTT determines the responsiveness of TCP 1364 flow control, and enables faster adaptation in a delay & capacity 1365 varying network due to user mobility. Low RTT permits use of a 1366 smaller send window, which makes the flow control loop more 1367 responsive to changing mobile network conditions. 1369 f. Opportunistic RAN-Aware pacing, acceleration, and deferral of 1370 high volume content such as video or software updates. 1372 11.2. Effect of Encrypted Transport Headers 1374 When the Transport Header is encrypted, it prevents the following 1375 mobile network features from operating: 1377 a. Application-type-aware network edge (middlebox) that could 1378 control pacing, limit simultaneous HD videos, prioritize active 1379 videos against new videos, etc. 1381 b. For the Access Network Discovery and Selection Function (3GPP- 1382 ANDSF), it Impedes content-aware network selection for steering 1383 users or specific flows to appropriate Networks. 1385 c. For Self Organizing Networks (3GPP SON) - intelligent SON 1386 workflows such as content-ware MLB (Mobility Load Balancing) 1388 d. For User Plane Congestion Management (3GPP UPCON) - ability to 1389 understand content and manage network during congestion. 1390 Mitigating techniques such as deferred download, off-peak 1391 acceleration, and outbound roamers. 1393 e. Reduces the benefits IP/DSCP-based transit network delivery 1394 optimizations; since the multiple applications are multiplexed 1395 within the same 5-tuple transport connection, the DSCP markings 1396 would not correspond to an application flow. 1398 f. Advance notification for dense data usages - If the application 1399 types are visible, transit network element could warn (ahead of 1400 usage) that the requested service consumes user plan limits, and 1401 transmission could be terminated. Without such visibility the 1402 network might have to continue the operation and stop the 1403 operation after the limit, because partially loaded content 1404 wastes resources and may not be usable by the client thus 1405 increasing customer complaints. Content publisher will not know 1406 user-service plans, and Network Edge would not know data transfer 1407 lengths before large object is requested. 1409 11.3. Effect of Encryption on New Services 1411 This section describes some new mobile services and how they might be 1412 affected with transport encryption: 1414 1. Flow-based charging allowing zero-rated and monetized traffic; 1415 for example operators may charge nothing, or charge based on 1416 domain/URLs. 1418 2. Content/Application based Prioritization of Over-the-Top (OTT) 1419 services - each application-type or service has different 1420 delay/loss/throughput expectations, and each type of stream will 1421 be unknown to an edge device if encrypted; this impedes dynamic- 1422 QoS adaptation. 1424 3. Rich Communication Services (3GPP-RCS) using different Quality 1425 Class Indicators (QCIs in LTE) - Operators offer different QoS 1426 classes for value-added services. The QCI type is visible in RAN 1427 control plane and invisible in user plane, thus the QCI cannot be 1428 set properly when the application -type is unknown. 1430 4. Enhanced Multimedia Broadcast/Multicast Services (3GPP eMBMS) - 1431 trusted edge proxies facilitate delivering same stream to 1432 different users, using either unicast or multicast depending on 1433 channel conditions to the user. 1435 5. Transport level protection is unnecessary for already protected 1436 content (such as content with Digital Rights Management, DRM). 1437 It prevents multi-user replication, and tandem encryption stages 1438 increase required processing cycles. 1440 11.4. Effect of Encryption on Mobile Network Evolution 1442 The transport header encryption prevents trusted transit proxies. It 1443 may be that the benefits of such proxies could be achieved by end to 1444 end client & server optimizations and distribution using CDNs, plus 1445 the ability to continue connections across different access 1446 technologies (across dynamic user IP addresses). The following 1447 aspects need to be considered in this approach: 1449 1. In a wireless mobile network, the delay and channel capacity per 1450 user and sector varies due to coverage, contention, user 1451 mobility, and scheduling balances fairness, capacity and service 1452 QoE. If most users are at the cell edge, the controller cannot 1453 use more complex QAM, thus reducing total cell capacity; 1454 similarly if a UMTS edge is serving some number of CS-Voice 1455 Calls, the remaining capacity for packet services is reduced. 1457 2. Inbound Roamers: Mobile wireless networks service in-bound 1458 roamers (Users of Operator A in a foreign operator Network B) by 1459 backhauling their traffic though Operator B's network to Operator 1460 A's Network and then serving through the P-Gateway (PGW), General 1461 GPRS Support Node (GGSN), Content Distribution Network (CDN) 1462 etc., of Operator A (User's Home Operator). Increasing window 1463 sizes to compensate for the path RTT will have the limitations 1464 outlined earlier for TCP. 1466 3. Outbound Roamers: Similar to inbound roamers, users accessing 1467 different Core/Content network, for example domains not serviced 1468 via local CDNs are carried through operator network via different 1469 APN or GW to remote networks which increases path RTT & control 1470 loop. 1472 4. Issues in deploying CDNs in RAN: Decreasing Client-Server control 1473 loop requires deploying CDNs/Cloud functions that terminate 1474 encryption closer to the edge. In Cellular RAN, the user IP 1475 traffic is encapsulated into GPSR Tunneling Protocol-User Plane 1476 (GTP-U in UMTS and LTE) tunnels to handle user mobility; the 1477 tunnels terminate in APN/GGSN/PGW that are in central locations. 1478 One user's traffic may flow through one or more APN's (for 1479 example Internet APN, Roaming APN for Operator X, Video-Service 1480 APN, OnDeckAPN etc.). The scope of operator private IP addresses 1481 may be limited to specific APN. Since CDNs generally operate on 1482 user IP flows, deploying them would require enhancing them with 1483 tunnel translation, etc., tunnel management functions. 1485 5. While CDNs that de-encrypt flows or split-connection proxy 1486 (similar to split-tcp) could be deployed closer to the edges to 1487 reduce control loop RTT, with transport header encryption, such 1488 CDNs perform optimization functions only for partner client 1489 flows; thus content from Small-Medium Businesses (SMBs) would not 1490 get such CDN benefits. 1492 6. Mobile Edge Computing (MEC) initiative to push latency sensitive 1493 functions to the edge of the network; for example a trusted proxy 1494 could facilitate services between two devices in RAN without 1495 requiring content flow through the WebServer. 1497 12. Informative References 1499 [CAIDA] "CAIDA [http://www.caida.org/data/overview/]". 1501 [CALEA] Pub. L. No. 103-414, 108 Stat. 4279, codified at 47 USC 1502 1001-1010, "Communications Assistance for Law Enforcement 1503 Act (CALEA)". 1505 [EFF] "Electronic Frontier Foundation https://www.eff.org/". 1507 [EFF2014] "EFF Report on STARTTLS Downgrade Attacks 1508 https://www.eff.org/deeplinks/2014/11/starttls-downgrade- 1509 attacks". 1511 [Enrich] Narseo Vallina-Rodriguez, et al., , "Header Enrichment or 1512 ISP Enrichment? Emerging Privacy Threats in Mobile 1513 Networks, Hot Middlebox'15, August 17-21 2015, London, 1514 United Kingdom", 2015. 1516 [ETSI101331] 1517 ETSI TS 101 331 V1.1.1 (2001-08), "Telecommunications 1518 security; Lawful Interception (LI); Requirements of Law 1519 Enforcement Agencies", August 2001. 1521 [homomorphic] 1522 Volume 20, 2013, Pages 502-509, Complex Adaptive Systems, 1523 "Homomorphic Encryption 1524 http://www.sciencedirect.com/science/article/pii/ 1525 S1877050913011101". 1527 [I-D.ietf-ippm-6man-pdm-option] 1528 Elkins, N., Hamilton, R., and m. mackermann@bcbsm.com, 1529 "IPv6 Performance and Diagnostic Metrics (PDM) Destination 1530 Option", draft-ietf-ippm-6man-pdm-option-08 (work in 1531 progress), February 2017. 1533 [I-D.ietf-mile-iodef-guidance] 1534 Kampanakis, P. and M. Suzuki, "IODEF Usage Guidance", 1535 draft-ietf-mile-iodef-guidance-07 (work in progress), 1536 November 2016. 1538 [JNSLP] Surveillance, Vol. 8 No. 3, "10 Standards for Oversight 1539 and Transparency of National Intelligence Services 1540 http://jnslp.com/". 1542 [M3AAWG] "Messaging, Malware, Mobile Anti-Abuse Working Group 1543 (M3AAWG) https://www.maawg.org/". 1545 [Map3GPP] http://www.3gpp.org/technologies, "Mapping between 1546 technologies and specifications". 1548 [NoEncrypt] 1549 "ISPs Removing their Customers EMail Encryption 1550 https://www.eff.org/deeplinks/2014/11/starttls-downgrade- 1551 attacks/". 1553 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 1554 RFC 2131, DOI 10.17487/RFC2131, March 1997, 1555 . 1557 [RFC2326] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time 1558 Streaming Protocol (RTSP)", RFC 2326, 1559 DOI 10.17487/RFC2326, April 1998, 1560 . 1562 [RFC2504] Guttman, E., Leong, L., and G. Malkin, "Users' Security 1563 Handbook", FYI 34, RFC 2504, DOI 10.17487/RFC2504, 1564 February 1999, . 1566 [RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address 1567 Translator (NAT) Terminology and Considerations", 1568 RFC 2663, DOI 10.17487/RFC2663, August 1999, 1569 . 1571 [RFC2804] IAB and IESG, "IETF Policy on Wiretapping", RFC 2804, 1572 DOI 10.17487/RFC2804, May 2000, 1573 . 1575 [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: 1576 Defeating Denial of Service Attacks which employ IP Source 1577 Address Spoofing", BCP 38, RFC 2827, DOI 10.17487/RFC2827, 1578 May 2000, . 1580 [RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, 1581 C., and M. Carney, "Dynamic Host Configuration Protocol 1582 for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July 1583 2003, . 1585 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 1586 Jacobson, "RTP: A Transport Protocol for Real-Time 1587 Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, 1588 July 2003, . 1590 [RFC3791] Olvera, C., Nesser, P., and , "Survey of IPv4 Addresses in 1591 Currently Deployed IETF Routing Area Standards Track and 1592 Experimental Documents", RFC 3791, DOI 10.17487/RFC3791, 1593 June 2004, . 1595 [RFC4682] Nechamkin, E. and J-F. Mule, "Multimedia Terminal Adapter 1596 (MTA) Management Information Base for PacketCable- and 1597 IPCablecom-Compliant Devices", RFC 4682, 1598 DOI 10.17487/RFC4682, December 2006, 1599 . 1601 [RFC5965] Shafranovich, Y., Levine, J., and M. Kucherawy, "An 1602 Extensible Format for Email Feedback Reports", RFC 5965, 1603 DOI 10.17487/RFC5965, August 2010, 1604 . 1606 [RFC6430] Li, K. and B. Leiba, "Email Feedback Report Type Value: 1607 not-spam", RFC 6430, DOI 10.17487/RFC6430, November 2011, 1608 . 1610 [RFC6455] Fette, I. and A. Melnikov, "The WebSocket Protocol", 1611 RFC 6455, DOI 10.17487/RFC6455, December 2011, 1612 . 1614 [RFC6590] Falk, J., Ed. and M. Kucherawy, Ed., "Redaction of 1615 Potentially Sensitive Data from Mail Abuse Reports", 1616 RFC 6590, DOI 10.17487/RFC6590, April 2012, 1617 . 1619 [RFC6591] Fontana, H., "Authentication Failure Reporting Using the 1620 Abuse Reporting Format", RFC 6591, DOI 10.17487/RFC6591, 1621 April 2012, . 1623 [RFC6650] Falk, J. and M. Kucherawy, Ed., "Creation and Use of Email 1624 Feedback Reports: An Applicability Statement for the Abuse 1625 Reporting Format (ARF)", RFC 6650, DOI 10.17487/RFC6650, 1626 June 2012, . 1628 [RFC6651] Kucherawy, M., "Extensions to DomainKeys Identified Mail 1629 (DKIM) for Failure Reporting", RFC 6651, 1630 DOI 10.17487/RFC6651, June 2012, 1631 . 1633 [RFC6652] Kitterman, S., "Sender Policy Framework (SPF) 1634 Authentication Failure Reporting Using the Abuse Reporting 1635 Format", RFC 6652, DOI 10.17487/RFC6652, June 2012, 1636 . 1638 [RFC7143] Chadalapaka, M., Satran, J., Meth, K., and D. Black, 1639 "Internet Small Computer System Interface (iSCSI) Protocol 1640 (Consolidated)", RFC 7143, DOI 10.17487/RFC7143, April 1641 2014, . 1643 [RFC7146] Black, D. and P. Koning, "Securing Block Storage Protocols 1644 over IP: RFC 3723 Requirements Update for IPsec v3", 1645 RFC 7146, DOI 10.17487/RFC7146, April 2014, 1646 . 1648 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 1649 Protocol (HTTP/1.1): Message Syntax and Routing", 1650 RFC 7230, DOI 10.17487/RFC7230, June 2014, 1651 . 1653 [RFC7234] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, 1654 Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching", 1655 RFC 7234, DOI 10.17487/RFC7234, June 2014, 1656 . 1658 [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an 1659 Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May 1660 2014, . 1662 [RFC7348] Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger, 1663 L., Sridhar, T., Bursell, M., and C. Wright, "Virtual 1664 eXtensible Local Area Network (VXLAN): A Framework for 1665 Overlaying Virtualized Layer 2 Networks over Layer 3 1666 Networks", RFC 7348, DOI 10.17487/RFC7348, August 2014, 1667 . 1669 [RFC7435] Dukhovni, V., "Opportunistic Security: Some Protection 1670 Most of the Time", RFC 7435, DOI 10.17487/RFC7435, 1671 December 2014, . 1673 [RFC7457] Sheffer, Y., Holz, R., and P. Saint-Andre, "Summarizing 1674 Known Attacks on Transport Layer Security (TLS) and 1675 Datagram TLS (DTLS)", RFC 7457, DOI 10.17487/RFC7457, 1676 February 2015, . 1678 [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, 1679 "Recommendations for Secure Use of Transport Layer 1680 Security (TLS) and Datagram Transport Layer Security 1681 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 1682 2015, . 1684 [RFC7624] Barnes, R., Schneier, B., Jennings, C., Hardie, T., 1685 Trammell, B., Huitema, C., and D. Borkmann, 1686 "Confidentiality in the Face of Pervasive Surveillance: A 1687 Threat Model and Problem Statement", RFC 7624, 1688 DOI 10.17487/RFC7624, August 2015, 1689 . 1691 [RFC7799] Morton, A., "Active and Passive Metrics and Methods (with 1692 Hybrid Types In-Between)", RFC 7799, DOI 10.17487/RFC7799, 1693 May 2016, . 1695 [RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., 1696 and P. Hoffman, "Specification for DNS over Transport 1697 Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May 1698 2016, . 1700 [RFCEdit] https://www.rfc-editor.org/materials/abbrev.expansion.txt, 1701 "RFC Editor Abbreviation List". 1703 [Vocab] https://portal.3gpp.org/desktopmodules/Specifications/ 1704 SpecificationDetails.aspx?specificationId=558, "3GPP TR 1705 21.905 V13.1.0 (2016-06) Vocabulary for 3GPP 1706 Specifications". 1708 [Web3GPP] http://www.3gpp.org/technologies/95-keywords-acronyms, 1709 "3GPP Web pages on specific topics of interest". 1711 [WebCache] 1712 Xing Xu, et al., , "Investigating Transparent Web Proxies 1713 in Cellular Networks, Passive and Active Measurement 1714 Conference (PAM)", 2015. 1716 Authors' Addresses 1718 Kathleen Moriarty 1719 Dell EMC 1720 176 South St 1721 Hopkinton, MA 1722 USA 1724 Phone: +1 1725 Email: Kathleen.Moriarty@dell.com 1727 Al Morton 1728 AT&T Labs 1729 200 Laurel Avenue South 1730 Middletown,, NJ 07748 1731 USA 1733 Phone: +1 732 420 1571 1734 Fax: +1 732 368 1192 1735 Email: acmorton@att.com 1736 URI: http://home.comcast.net/~acmacm/