RFC 8404
Effects of Pervasive Encryption on Operators
Pages: 53
Informational
Informational
Part 3 of 3 – Pages 40 to 53
6. Application-Based Flow Information Visible to a Network
This section describes specific techniques used in monitoring applications that are visible to the network if a 5-tuple is exposed and as such can potentially be used as input for future network- management approaches. It also includes an overview of IP Flow Information Export (IPFIX), a flow-based protocol used to export information about network flows.6.1. IP Flow Information Export
Many of the accounting, monitoring, and measurement tasks described in this document, especially in Sections 2.3.2, 3.1.1, 4.1.3, 4.2, and 5.2, use the IPFIX protocol [RFC7011] for export and storage of the monitored information. IPFIX evolved from the widely deployed NetFlow protocol [RFC3954], which exports information about flows identified by 5-tuple. While NetFlow was largely concerned with exporting per-flow byte and packet counts for accounting purposes, IPFIX's extensible Information Model [RFC7012] provides a variety of Information Elements (IEs) [IPFIX-IANA] for representing information above and below the traditional network-layer flow information. Enterprise-specific IEs allow exporter vendors to define their own non-standard IEs as well, and many of these are driven by header and payload inspection at the Metering Process. While the deployment of encryption has no direct effect on the use of IPFIX, certain defined IEs may become unavailable when the Metering Process observing the traffic cannot decrypt former cleartext information. For example, HTTPS renders HTTP header analysis impossible, so IEs derived from the header (e.g., httpContentType, httpUserAgent) cannot be exported. The collection of IPFIX data itself, of course, provides a point of centralization for information that is potentially business and privacy critical. The IPFIX File Format specification [RFC5655] recommends encryption for this data at rest, and the IP Flow Anonymization specification [RFC6235] defines a metadata format for describing the anonymization functions applied to an IPFIX dataset, if anonymization is employed for data sharing of IPFIX information between enterprises or network operators.6.2. TLS Server Name Indication
When initiating the TLS handshake, the client may provide an extension field (server_name) that indicates the server to which it is attempting a secure connection. TLS SNI was standardized in 2003 to enable servers to present the "correct TLS certificate" to clients in a deployment of multiple virtual servers hosted by the same server
infrastructure and IP address. Although this is an optional extension, it is today supported by all modern browsers, web servers, and developer libraries. Akamai [Nygren] reports that many of their customers see client TLS SNI usage over 99%. It should be noted that HTTP/2 introduces the Alt-SVC method for upgrading the connection from HTTP/1 to either unencrypted or encrypted HTTP/2. If the initial HTTP/1 request is unencrypted, the destination alternate service name can be identified before the communication is potentially upgraded to encrypted HTTP/2 transport. HTTP/2 requires the TLS implementation to support the SNI extension (see Section 9.2 of [RFC7540]). It is also worth noting that [RFC7838] "allows an origin server to nominate additional means of interacting with it on the network", while [RFC8164] allows for a URI to be accessed with HTTP/2 and TLS using Opportunistic Security (on an experimental basis). This information is only available if the client populates the SNI extension. Doing so is an optional part of the TLS standard, and as stated above, this has been implemented by all major browsers. Due to its optional nature, though, existing network filters that examine a TLS ClientHello for an SNI extension cannot expect to always find one. "SNI Encryption in TLS Through Tunneling" [SNI-TLS] has been adopted by the TLS Working Group, which provides solutions to encrypt SNI. As such, there will be an option to encrypt SNI in future versions of TLS. The per-domain nature of SNI may not reveal the specific service or media type being accessed, especially where the domain is of a provider offering a range of email, video, web pages, etc. For example, certain blog or social network feeds may be deemed "adult content", but the SNI will only indicate the server domain rather than a URL path. There are additional issues for identification of content using SNI: [RFC7540] includes connection coalescing, [RFC8336] defines the ORIGIN frame, and the proposal outlined in [HTTP2-CERTS] will increase the difficulty of passive monitoring.6.3. Application-Layer Protocol Negotiation (ALPN)
ALPN is a TLS extension that may be used to indicate the application protocol within the TLS session. This is likely to be of more value to the network where it indicates a protocol dedicated to a particular traffic type (such as video streaming) rather than a multi-use protocol. ALPN is used as part of HTTP/2 'h2', but will not indicate the traffic types that may make up streams within an HTTP/2 multiplex. ALPN is sent cleartext in the ClientHello, and the server returns it in Encrypted Extensions in TLS 1.3.
6.4. Content Length, Bitrate, and Pacing
The content length of encrypted traffic is effectively the same as that of the cleartext. Although block ciphers utilize padding, this makes a negligible difference. Bitrate and pacing are generally application specific and do not change much when the content is encrypted. Multiplexed formats (such as HTTP/2 and QUIC [QUIC]) may, however, incorporate several application streams over one connection, which makes the bitrate/pacing no longer application specific. Also, packet padding is available in HTTP/2, TLS 1.3, and many other protocols. Traffic analysis is made more difficult by such countermeasures.7. Effect of Encryption on the Evolution of Mobile Networks
Transport header encryption prevents the use of transit proxies in the center of the network and the use of some edge proxies by preventing the proxies from taking action on the stream. It may be that the claimed benefits of such proxies could be achieved by end-to-end client and server optimizations, distribution using CDNs, plus the ability to continue connections across different access technologies (across dynamic user IP addresses). The following aspects should be considered in this approach: 1. In a wireless mobile network, the delay and channel capacity per user and sector varies due to coverage, contention, user mobility, scheduling balances fairness, capacity, and service QoE. If most users are at the cell edge, the controller cannot use more-complex Quadrature Amplitude Modulation (QAM), thus reducing total cell capacity; similarly, if a Universal Mobile Telecommunications System (UMTS) edge is serving some number of CS-Voice Calls, the remaining capacity for packet services is reduced. 2. Mobile wireless networks service inbound roamers (users of Operator A in the foreign network of Operator B) by backhauling their traffic through the network (from Operator B to Operator A) and then serving them through the P-Gateway (PGW), General Packet Radio Service (GPRS) Support Node (GGSN), CDN, etc., of Operator A (the user's home operator). Increasing window sizes to compensate for the path RTT will have the limitations outlined earlier for TCP. The outbound roamer scenario has a similar TCP performance impact. 3. Issues in deploying CDNs in Radio Access Networks (RANs) include decreasing the client-server control loop that requires deploying CDNs / Cloud functions that terminate encryption closer to the edge. In Cellular RAN, the user IP traffic is encapsulated into
GPRS Tunneling Protocol-User Plane (GTP-U in UMTS and LTE)
tunnels to handle user mobility; the tunnels terminate in
APN/GGSN/PGW that are in central locations. One user's traffic
may flow through one or more APN's (for example, Internet APN,
Roaming APN for Operator X, Video-Service APN, OnDeckAPN, etc.).
The scope of operator private IP addresses may be limited to
specific APNs. Since CDNs generally operate on user IP flows,
deploying them would require enhancing them with tunnel
translation, tunnel-management functions, etc.
4. While CDNs that decrypt flows or split connection proxies
(similar to split TCP) could be deployed closer to the edges to
reduce control-loop RTT, with transport header encryption, such
CDNs perform optimization functions only for partner client
flows. Therefore, content from some Small-Medium Businesses
(SMBs) would not get such CDN benefits.
8. Response to Increased Encryption and Looking Forward
As stated in [RFC7258], "an appropriate balance [between network
management and pervasive monitoring mitigations] will emerge over
time as real instances of this tension are considered." Numerous
operators made it clear in their response to this document that they
fully support strong encryption and providing privacy for end users;
this is a common goal. Operators recognize that not all the
practices documented need to be supported going forward, either
because of the risk to end-user privacy or because alternate
technologies and tools have already emerged. This document is
intended to support network engineers and other innovators to work
toward solving network and security management problems with protocol
designers and application developers in new ways that facilitate
adoption of strong encryption rather than preventing the use of
encryption. By having the discussions on network and security
management practices with application developers and protocol
designers, each side of the debate can understand each other's goals,
work toward alternate solutions, and disband with practices that
should no longer be supported. A goal of this document is to assist
the IETF in understanding some of the current practices so as to
identify new work items for IETF-related use cases that can
facilitate the adoption of strong session encryption and support
network and security management.
9. Security Considerations
There are no additional security considerations as this is a summary
and does not include a new protocol or functionality.
10. IANA Considerations
This document has no IANA actions.11. Informative References
[ACCORD] IETF, "Alternatives to Content Classification for Operator Resource Deployment (accord) (BOF)", IETF-95 Proceedings, April 2016, <https://www.ietf.org/proceedings/95/accord.html>. [Ben17a] Benjamin, D., "Chrome Data", Presentation before the TLS WG at IETF 100, November 2017, <https://datatracker.ietf.org/meeting/100/materials/ slides-100-tls-sessa-tls13/>. [Ben17b] Benjamin, D., "Subject: Additional TLS 1.3 results from Chrome", message to the TLS mailing list, 18 December 2017, <https://www.ietf.org/mail-archive/web/tls/current/ msg25168.html>. [CAIDA] CAIDA, "The CAIDA USCD Anonymized Internet Traces 2016 Dataset", <http://www.caida.org/data/passive/ passive_2016_dataset.xml>. [DarkMail] "Dark Mail Technical Alliance", <https://darkmail.info/>. [DDOS-USECASE] Dobbins, R., Migault, D., Fouant, S., Moskowitz, R., Teague, N., Xia, L., and K. Nishizuka, "Use cases for DDoS Open Threat Signaling", Work in Progress, draft-ietf-dots- use-cases-16, July 2018. [DOTS] IETF, "DDoS Open Threat Signaling (dots)", <https://datatracker.ietf.org/wg/dots/charter>. [EFF2014] Hoffman-Andrews, J., "ISPs Removing Their Customers' Email Encryption", November 2014, <https://www.eff.org/deeplinks/2014/11/ starttls-downgrade-attacks>. [Enrich] Narseo Vallina-Rodriguez, N., Sundaresan, S., Kreibich, C., and V. Paxson, "Header Enrichment or ISP Enrichment: Emerging Privacy Threats in Mobile Networks", Proceedings of the ACM SIGCOMM Workshop on Hot Topics in Middleboxes and Network Function Virtualization, pp. 23-30, DOI 10.1145/2785989.2786002, August 2015.
[GENEVE-REQS] Migault, D., Boutros, S., Wing, D., and S. Krishnan, "Geneve Protocol Security Requirements", Work in Progress, draft-mglt-nvo3-geneve-security-requirements-03, February 2018. [HTTP2-CERTS] Bishop, M., Sullivan, N., and M. Thomson, "Secondary Certificate Authentication in HTTP/2", Work in Progress, draft-ietf-httpbis-http2-secondary-certs-02, June 2018. [IPFIX-IANA] IANA, "IP Flow Information Export (IPFIX) Entities", <https://www.iana.org/assignments/ipfix/>. [JNSLP] Eskens, S., "10 Standards for Oversight and Transparency of National Intelligence Services", Surveillance, Vol. 8, No. 3, July 2016, <http://jnslp.com/?s=10+Standards+for+Ov ersight+and+Transparency+of+National>. [M3AAWG] M3AAWG, "Messaging, Malware and Mobile Anti-Abuse Working Group (M3AAWG)", <https://www.maawg.org/>. [MIDDLEBOXES] Dolson, D., Snellman, J., Boucadair, M., and C. Jacquenet, "An Inventory of Transport-centric Functions Provided by Middleboxes", Work in Progress, draft-dolson-transport- middlebox-03, June 2018. [Nygren] Nygren, E., "Reaching toward Universal TLS SNI", Akamai Technologies, March 2017, <https://blogs.akamai.com/2017/03/ reaching-toward-universal-tls-sni.html>. [QUIC] IETF, "QUIC (quic)", <https://datatracker.ietf.org/wg/quic/charter/>. [Res17a] Rescorla, E., "Subject: Preliminary data on Firefox TLS 1.3 Middlebox experiment", message to the TLS mailing list, 5 December 2017, <https://www.ietf.org/mail-archive/ web/tls/current/msg25091.html>. [Res17b] Rescorla, E., "Subject: More compatibility measurement results", message to the TLS mailing list, 22 December 2017, <https://www.ietf.org/mail-archive/web/tls/current/ msg25179.html>.
[RFC1945] Berners-Lee, T., Fielding, R., and H. Frystyk, "Hypertext Transfer Protocol -- HTTP/1.0", RFC 1945, DOI 10.17487/RFC1945, May 1996, <https://www.rfc-editor.org/info/rfc1945>. [RFC1958] Carpenter, B., Ed., "Architectural Principles of the Internet", RFC 1958, DOI 10.17487/RFC1958, June 1996, <https://www.rfc-editor.org/info/rfc1958>. [RFC1984] IAB and IESG, "IAB and IESG Statement on Cryptographic Technology and the Internet", BCP 200, RFC 1984, DOI 10.17487/RFC1984, August 1996, <https://www.rfc-editor.org/info/rfc1984>. [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, DOI 10.17487/RFC2131, March 1997, <https://www.rfc-editor.org/info/rfc2131>. [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, DOI 10.17487/RFC2474, December 1998, <https://www.rfc-editor.org/info/rfc2474>. [RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address Translator (NAT) Terminology and Considerations", RFC 2663, DOI 10.17487/RFC2663, August 1999, <https://www.rfc-editor.org/info/rfc2663>. [RFC2775] Carpenter, B., "Internet Transparency", RFC 2775, DOI 10.17487/RFC2775, February 2000, <https://www.rfc-editor.org/info/rfc2775>. [RFC2804] IAB and IESG, "IETF Policy on Wiretapping", RFC 2804, DOI 10.17487/RFC2804, May 2000, <https://www.rfc-editor.org/info/rfc2804>. [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing", BCP 38, RFC 2827, DOI 10.17487/RFC2827, May 2000, <https://www.rfc-editor.org/info/rfc2827>. [RFC3135] Border, J., Kojo, M., Griner, J., Montenegro, G., and Z. Shelby, "Performance Enhancing Proxies Intended to Mitigate Link-Related Degradations", RFC 3135, DOI 10.17487/RFC3135, June 2001, <https://www.rfc-editor.org/info/rfc3135>.
[RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July 2003, <https://www.rfc-editor.org/info/rfc3315>. [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, July 2003, <https://www.rfc-editor.org/info/rfc3550>. [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed Networks", BCP 84, RFC 3704, DOI 10.17487/RFC3704, March 2004, <https://www.rfc-editor.org/info/rfc3704>. [RFC3724] Kempf, J., Ed., Austein, R., Ed., and IAB, "The Rise of the Middle and the Future of End-to-End: Reflections on the Evolution of the Internet Architecture", RFC 3724, DOI 10.17487/RFC3724, March 2004, <https://www.rfc-editor.org/info/rfc3724>. [RFC3954] Claise, B., Ed., "Cisco Systems NetFlow Services Export Version 9", RFC 3954, DOI 10.17487/RFC3954, October 2004, <https://www.rfc-editor.org/info/rfc3954>. [RFC3971] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander, "SEcure Neighbor Discovery (SEND)", RFC 3971, DOI 10.17487/RFC3971, March 2005, <https://www.rfc-editor.org/info/rfc3971>. [RFC4787] Audet, F., Ed. and C. Jennings, "Network Address Translation (NAT) Behavioral Requirements for Unicast UDP", BCP 127, RFC 4787, DOI 10.17487/RFC4787, January 2007, <https://www.rfc-editor.org/info/rfc4787>. [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless Address Autoconfiguration", RFC 4862, DOI 10.17487/RFC4862, September 2007, <https://www.rfc-editor.org/info/rfc4862>. [RFC5655] Trammell, B., Boschi, E., Mark, L., Zseby, T., and A. Wagner, "Specification of the IP Flow Information Export (IPFIX) File Format", RFC 5655, DOI 10.17487/RFC5655, October 2009, <https://www.rfc-editor.org/info/rfc5655>. [RFC5965] Shafranovich, Y., Levine, J., and M. Kucherawy, "An Extensible Format for Email Feedback Reports", RFC 5965, DOI 10.17487/RFC5965, August 2010, <https://www.rfc-editor.org/info/rfc5965>.
[RFC6108] Chung, C., Kasyanov, A., Livingood, J., Mody, N., and B. Van Lieu, "Comcast's Web Notification System Design", RFC 6108, DOI 10.17487/RFC6108, February 2011, <https://www.rfc-editor.org/info/rfc6108>. [RFC6235] Boschi, E. and B. Trammell, "IP Flow Anonymization Support", RFC 6235, DOI 10.17487/RFC6235, May 2011, <https://www.rfc-editor.org/info/rfc6235>. [RFC6269] Ford, M., Ed., Boucadair, M., Durand, A., Levis, P., and P. Roberts, "Issues with IP Address Sharing", RFC 6269, DOI 10.17487/RFC6269, June 2011, <https://www.rfc-editor.org/info/rfc6269>. [RFC6430] Li, K. and B. Leiba, "Email Feedback Report Type Value: not-spam", RFC 6430, DOI 10.17487/RFC6430, November 2011, <https://www.rfc-editor.org/info/rfc6430>. [RFC6455] Fette, I. and A. Melnikov, "The WebSocket Protocol", RFC 6455, DOI 10.17487/RFC6455, December 2011, <https://www.rfc-editor.org/info/rfc6455>. [RFC6590] Falk, J., Ed. and M. Kucherawy, Ed., "Redaction of Potentially Sensitive Data from Mail Abuse Reports", RFC 6590, DOI 10.17487/RFC6590, April 2012, <https://www.rfc-editor.org/info/rfc6590>. [RFC6591] Fontana, H., "Authentication Failure Reporting Using the Abuse Reporting Format", RFC 6591, DOI 10.17487/RFC6591, April 2012, <https://www.rfc-editor.org/info/rfc6591>. [RFC6650] Falk, J. and M. Kucherawy, Ed., "Creation and Use of Email Feedback Reports: An Applicability Statement for the Abuse Reporting Format (ARF)", RFC 6650, DOI 10.17487/RFC6650, June 2012, <https://www.rfc-editor.org/info/rfc6650>. [RFC6651] Kucherawy, M., "Extensions to DomainKeys Identified Mail (DKIM) for Failure Reporting", RFC 6651, DOI 10.17487/RFC6651, June 2012, <https://www.rfc-editor.org/info/rfc6651>. [RFC6652] Kitterman, S., "Sender Policy Framework (SPF) Authentication Failure Reporting Using the Abuse Reporting Format", RFC 6652, DOI 10.17487/RFC6652, June 2012, <https://www.rfc-editor.org/info/rfc6652>.
[RFC7011] Claise, B., Ed., Trammell, B., Ed., and P. Aitken, "Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of Flow Information", STD 77, RFC 7011, DOI 10.17487/RFC7011, September 2013, <https://www.rfc-editor.org/info/rfc7011>. [RFC7012] Claise, B., Ed. and B. Trammell, Ed., "Information Model for IP Flow Information Export (IPFIX)", RFC 7012, DOI 10.17487/RFC7012, September 2013, <https://www.rfc-editor.org/info/rfc7012>. [RFC7143] Chadalapaka, M., Satran, J., Meth, K., and D. Black, "Internet Small Computer System Interface (iSCSI) Protocol (Consolidated)", RFC 7143, DOI 10.17487/RFC7143, April 2014, <https://www.rfc-editor.org/info/rfc7143>. [RFC7146] Black, D. and P. Koning, "Securing Block Storage Protocols over IP: RFC 3723 Requirements Update for IPsec v3", RFC 7146, DOI 10.17487/RFC7146, April 2014, <https://www.rfc-editor.org/info/rfc7146>. [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing", RFC 7230, DOI 10.17487/RFC7230, June 2014, <https://www.rfc-editor.org/info/rfc7230>. [RFC7234] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching", RFC 7234, DOI 10.17487/RFC7234, June 2014, <https://www.rfc-editor.org/info/rfc7234>. [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May 2014, <https://www.rfc-editor.org/info/rfc7258>. [RFC7348] Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger, L., Sridhar, T., Bursell, M., and C. Wright, "Virtual eXtensible Local Area Network (VXLAN): A Framework for Overlaying Virtualized Layer 2 Networks over Layer 3 Networks", RFC 7348, DOI 10.17487/RFC7348, August 2014, <https://www.rfc-editor.org/info/rfc7348>. [RFC7435] Dukhovni, V., "Opportunistic Security: Some Protection Most of the Time", RFC 7435, DOI 10.17487/RFC7435, December 2014, <https://www.rfc-editor.org/info/rfc7435>.
[RFC7457] Sheffer, Y., Holz, R., and P. Saint-Andre, "Summarizing Known Attacks on Transport Layer Security (TLS) and Datagram TLS (DTLS)", RFC 7457, DOI 10.17487/RFC7457, February 2015, <https://www.rfc-editor.org/info/rfc7457>. [RFC7489] Kucherawy, M., Ed. and E. Zwicky, Ed., "Domain-based Message Authentication, Reporting, and Conformance (DMARC)", RFC 7489, DOI 10.17487/RFC7489, March 2015, <https://www.rfc-editor.org/info/rfc7489>. [RFC7498] Quinn, P., Ed. and T. Nadeau, Ed., "Problem Statement for Service Function Chaining", RFC 7498, DOI 10.17487/RFC7498, April 2015, <https://www.rfc-editor.org/info/rfc7498>. [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, "Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 2015, <https://www.rfc-editor.org/info/rfc7525>. [RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext Transfer Protocol Version 2 (HTTP/2)", RFC 7540, DOI 10.17487/RFC7540, May 2015, <https://www.rfc-editor.org/info/rfc7540>. [RFC7619] Smyslov, V. and P. Wouters, "The NULL Authentication Method in the Internet Key Exchange Protocol Version 2 (IKEv2)", RFC 7619, DOI 10.17487/RFC7619, August 2015, <https://www.rfc-editor.org/info/rfc7619>. [RFC7624] Barnes, R., Schneier, B., Jennings, C., Hardie, T., Trammell, B., Huitema, C., and D. Borkmann, "Confidentiality in the Face of Pervasive Surveillance: A Threat Model and Problem Statement", RFC 7624, DOI 10.17487/RFC7624, August 2015, <https://www.rfc-editor.org/info/rfc7624>. [RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function Chaining (SFC) Architecture", RFC 7665, DOI 10.17487/RFC7665, October 2015, <https://www.rfc-editor.org/info/rfc7665>. [RFC7754] Barnes, R., Cooper, A., Kolkman, O., Thaler, D., and E. Nordmark, "Technical Considerations for Internet Service Blocking and Filtering", RFC 7754, DOI 10.17487/RFC7754, March 2016, <https://www.rfc-editor.org/info/rfc7754>.
[RFC7799] Morton, A., "Active and Passive Metrics and Methods (with Hybrid Types In-Between)", RFC 7799, DOI 10.17487/RFC7799, May 2016, <https://www.rfc-editor.org/info/rfc7799>. [RFC7826] Schulzrinne, H., Rao, A., Lanphier, R., Westerlund, M., and M. Stiemerling, Ed., "Real-Time Streaming Protocol Version 2.0", RFC 7826, DOI 10.17487/RFC7826, December 2016, <https://www.rfc-editor.org/info/rfc7826>. [RFC7838] Nottingham, M., McManus, P., and J. Reschke, "HTTP Alternative Services", RFC 7838, DOI 10.17487/RFC7838, April 2016, <https://www.rfc-editor.org/info/rfc7838>. [RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., and P. Hoffman, "Specification for DNS over Transport Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May 2016, <https://www.rfc-editor.org/info/rfc7858>. [RFC8073] Moriarty, K. and M. Ford, "Coordinating Attack Response at Internet Scale (CARIS) Workshop Report", RFC 8073, DOI 10.17487/RFC8073, March 2017, <https://www.rfc-editor.org/info/rfc8073>. [RFC8164] Nottingham, M. and M. Thomson, "Opportunistic Security for HTTP/2", RFC 8164, DOI 10.17487/RFC8164, May 2017, <https://www.rfc-editor.org/info/rfc8164>. [RFC8165] Hardie, T., "Design Considerations for Metadata Insertion", RFC 8165, DOI 10.17487/RFC8165, May 2017, <https://www.rfc-editor.org/info/rfc8165>. [RFC8250] Elkins, N., Hamilton, R., and M. Ackermann, "IPv6 Performance and Diagnostic Metrics (PDM) Destination Option", RFC 8250, DOI 10.17487/RFC8250, September 2017, <https://www.rfc-editor.org/info/rfc8250>. [RFC8274] Kampanakis, P. and M. Suzuki, "Incident Object Description Exchange Format Usage Guidance", RFC 8274, DOI 10.17487/RFC8274, November 2017, <https://www.rfc-editor.org/info/rfc8274>. [RFC8300] Quinn, P., Ed., Elzur, U., Ed., and C. Pignataro, Ed., "Network Service Header (NSH)", RFC 8300, DOI 10.17487/RFC8300, January 2018, <https://www.rfc-editor.org/info/rfc8300>.
[RFC8336] Nottingham, M. and E. Nygren, "The ORIGIN HTTP/2 Frame", RFC 8336, DOI 10.17487/RFC8336, March 2018, <https://www.rfc-editor.org/info/rfc8336>. [SACM] IETF, "Security Automation and Continuous Monitoring (sacm)", <https://datatracker.ietf.org/wg/sacm/charter/>. [SNI-TLS] Huitema, C. and E. Rescorla, "Issues and Requirements for SNI Encryption in TLS", Work in Progress, draft-ietf-tls- sni-encryption-03, May 2018. [Snowden] Verble, J., "The NSA and Edward Snowden: Surveillance in the 21st Century", SIGCAS Computer & Society, Vol. 44, No. 3, DOI 10.1145/2684097.2684101, September 2014, <http://www.jjsylvia.com/bigdatacourse/wp-content/ uploads/2016/04/p14-verble-1.pdf>. [TCPcrypt] IETF, "TCP Increased Security (tcpinc)", <https://datatracker.ietf.org/wg/tcpinc/charter>. [TS3GPP] 3GPP, "Non-Access-Stratum (NAS) protocol for Evolved Packet System (EPS); Stage 3", 3GPP TS 24.301, version 15.2.0, March 2018. [UPCON] 3GPP, "User Plane Congestion Management", 3GPP Rel-13, September 2014, <http://www.3gpp.org/DynaReport/ FeatureOrStudyItemFile-570029.htm>. [UserData] Durumeric, Z., Ma, Z., Springall, D., Barnes, R., Sullivan, N., Bursztein, E., Bailey, M., Alex Halderman, J., and V. Paxson, "The Security Impact of HTTPS Interception", Network and Distributed Systems Symposium, February 2017, <http://dx.doi.org/10.14722/ndss.2017.23456>.
Acknowledgements
Thanks to our reviewers, Natasha Rooney, Kevin Smith, Ashutosh Dutta, Brandon Williams, Jean-Michel Combes, Nalini Elkins, Paul Barrett, Badri Subramanyan, Igor Lubashev, Suresh Krishnan, Dave Dolson, Mohamed Boucadair, Stephen Farrell, Warren Kumari, Alia Atlas, Roman Danyliw, Mirja Kuehlewind, Ines Robles, Joe Clarke, Kyle Rose, Christian Huitema, and Chris Morrow for their editorial and content suggestions. Surya K. Kovvali provided material for Section 7. Chris Morrow and Nik Teague provided reviews and updates specific to the DoS fingerprinting text. Brian Trammell provided the IPFIX text.Authors' Addresses
Kathleen Moriarty (editor) Dell EMC 176 South St Hopkinton, MA United States of America Email: Kathleen.Moriarty@dell.com Al Morton (editor) AT&T Labs 200 Laurel Avenue South Middletown, NJ 07748 United States of America Phone: +1 732 420 1571 Fax: +1 732 368 1192 Email: acm@research.att.com