< draft-mm-wg-effect-encrypt-12.txt   draft-mm-wg-effect-encrypt-13.txt >
Network Working Group K. Moriarty Network Working Group K. Moriarty
Internet-Draft Dell EMC Internet-Draft Dell EMC
Intended status: Informational A. Morton Intended status: Informational A. Morton
Expires: January 1, 2018 AT&T Labs Expires: April 13, 2018 AT&T Labs
June 30, 2017 October 10, 2017
Effect of Pervasive Encryption on Operators Effect of Pervasive Encryption on Operators
draft-mm-wg-effect-encrypt-12 draft-mm-wg-effect-encrypt-13
Abstract Abstract
Pervasive Monitoring (PM) attacks on the privacy of Internet users is Pervasive Monitoring (PM) attacks on the privacy of Internet users is
of serious concern to both the user and the operator communities. of serious concern to both the user and the operator communities.
RFC7258 discussed the critical need to protect users' privacy when RFC7258 discussed the critical need to protect users' privacy when
developing IETF specifications and also recognized making networks developing IETF specifications and also recognized making networks
unmanageable to mitigate PM is not an acceptable outcome, an unmanageable to mitigate PM is not an acceptable outcome, an
appropriate balance is needed. This document discusses current appropriate balance is needed. This document discusses current
security and network management practices that may be impacted by the security and network management practices that may be impacted by the
skipping to change at page 1, line 32 skipping to change at page 1, line 32
development in support of manageable, secure networks. development in support of manageable, secure networks.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 1, 2018. This Internet-Draft will expire on April 13, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
skipping to change at page 3, line 10 skipping to change at page 3, line 10
4.2. Techniques for Monitoring Internet Session Traffic . . . 28 4.2. Techniques for Monitoring Internet Session Traffic . . . 28
5. Security Monitoring for Specific Attack Types . . . . . . . . 30 5. Security Monitoring for Specific Attack Types . . . . . . . . 30
5.1. Mail Abuse and SPAM . . . . . . . . . . . . . . . . . . . 30 5.1. Mail Abuse and SPAM . . . . . . . . . . . . . . . . . . . 30
5.2. Denial of Service . . . . . . . . . . . . . . . . . . . . 31 5.2. Denial of Service . . . . . . . . . . . . . . . . . . . . 31
5.3. Phishing . . . . . . . . . . . . . . . . . . . . . . . . 31 5.3. Phishing . . . . . . . . . . . . . . . . . . . . . . . . 31
5.4. Botnets . . . . . . . . . . . . . . . . . . . . . . . . . 32 5.4. Botnets . . . . . . . . . . . . . . . . . . . . . . . . . 32
5.5. Malware . . . . . . . . . . . . . . . . . . . . . . . . . 32 5.5. Malware . . . . . . . . . . . . . . . . . . . . . . . . . 32
5.6. Spoofed Source IP Address Protection . . . . . . . . . . 32 5.6. Spoofed Source IP Address Protection . . . . . . . . . . 32
5.7. Further work . . . . . . . . . . . . . . . . . . . . . . 33 5.7. Further work . . . . . . . . . . . . . . . . . . . . . . 33
6. Application-based Flow Information Visible to a Network . . . 33 6. Application-based Flow Information Visible to a Network . . . 33
6.1. TLS Server Name Indication . . . . . . . . . . . . . . . 33 6.1. IP Flow Information Export . . . . . . . . . . . . . . . 33
6.2. Application Layer Protocol Negotiation (ALPN) . . . . . . 34 6.2. TLS Server Name Indication . . . . . . . . . . . . . . . 34
6.3. Content Length, BitRate and Pacing . . . . . . . . . . . 34 6.3. Application Layer Protocol Negotiation (ALPN) . . . . . . 34
7. Impact on Mobility Network Optimizations and New Services . . 34 6.4. Content Length, BitRate and Pacing . . . . . . . . . . . 35
7.1. Effect of Encypted ACKs . . . . . . . . . . . . . . . . . 34 7. Impact on Mobility Network Optimizations and New Services . . 35
7.2. Effect of Encrypted Transport Headers . . . . . . . . . . 35 7.1. Effect of Encypted ACKs . . . . . . . . . . . . . . . . . 35
7.2. Effect of Encrypted Transport Headers . . . . . . . . . . 36
7.3. Effect of Encryption on New or Emerging Services . . . . 36 7.3. Effect of Encryption on New or Emerging Services . . . . 36
7.4. Effect of Encryption on Mobile Network Evolution . . . . 36 7.4. Effect of Encryption on Mobile Network Evolution . . . . 37
8. Response to Increased Encryption and Looking Forward . . . . 37 8. Response to Increased Encryption and Looking Forward . . . . 38
9. Security Considerations . . . . . . . . . . . . . . . . . . . 38 9. Security Considerations . . . . . . . . . . . . . . . . . . . 39
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 38 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 39
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 38 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 39
12. Informative References . . . . . . . . . . . . . . . . . . . 38 12. Informative References . . . . . . . . . . . . . . . . . . . 39
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 44 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 46
1. Introduction 1. Introduction
In response to pervasive monitoring revelations and the IETF In response to pervasive monitoring revelations and the IETF
consensus that Pervasive Monitoring is an Attack [RFC7258], efforts consensus that Pervasive Monitoring is an Attack [RFC7258], efforts
are underway to increase encryption of Internet traffic. Pervasive are underway to increase encryption of Internet traffic. Pervasive
Monitoring (PM) is of serious concern to users, operators, and Monitoring (PM) is of serious concern to users, operators, and
application providers. RFC7258 discussed the critical need to application providers. RFC7258 discussed the critical need to
protect users' privacy when developing IETF specifications and also protect users' privacy when developing IETF specifications and also
recognized that making networks unmanageable to mitigate PM is not an recognized that making networks unmanageable to mitigate PM is not an
skipping to change at page 33, line 22 skipping to change at page 33, line 22
5.7. Further work 5.7. Further work
Although incident response work will continue, new methods to prevent Although incident response work will continue, new methods to prevent
system compromise through security automation and continuous system compromise through security automation and continuous
monitoring [SACM] may provide alternate approaches where system monitoring [SACM] may provide alternate approaches where system
security is maintained as a preventative measure. security is maintained as a preventative measure.
6. Application-based Flow Information Visible to a Network 6. Application-based Flow Information Visible to a Network
This section describes specific techniques used in monitoring This section describes specific techniques used in monitoring
applications that may apply to various network types. applications that may apply to various network types. It also
inlcudes an overview of IPFIX, a flow-based protocol used to export
information about network flows.
6.1. TLS Server Name Indication 6.1. IP Flow Information Export
Many of the accounting, monitoring and measurement tasks described in
this document, especially Section 2.3.2, Section 3.1.1,
Section 4.1.3, Section 4.2, and Section 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 formerly 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 potentially business- and privacy-critical
information. 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 When initiating the TLS handshake, the Client may provide an
extension field (server_name) which indicates the server to which it extension field (server_name) which indicates the server to which it
is attempting a secure connection. TLS SNI was standardized in 2003 is attempting a secure connection. TLS SNI was standardized in 2003
to enable servers to present the "correct TLS certificate" to clients to enable servers to present the "correct TLS certificate" to clients
in a deployment of multiple virtual servers hosted by the same server in a deployment of multiple virtual servers hosted by the same server
infrastructure and IP-address. Although this is an optional infrastructure and IP-address. Although this is an optional
extension, it is today supported by all modern browsers, web servers extension, it is today supported by all modern browsers, web servers
and developer libraries. Akamai [Nygren] reports that many of their and developer libraries. Akamai [Nygren] reports that many of their
customer see client TLS SNI usage over 99%. It should be noted that customer see client TLS SNI usage over 99%. It should be noted that
skipping to change at page 33, line 48 skipping to change at page 34, line 34
service name can be identified before the communication is service name can be identified before the communication is
potentially upgraded to encrypted HTTP/2 transport. HTTP/2 requires potentially upgraded to encrypted HTTP/2 transport. HTTP/2 requires
the TLS implementation to support the Server Name Indication (SNI) the TLS implementation to support the Server Name Indication (SNI)
extension (see section 9.2 of [RFC7540]). extension (see section 9.2 of [RFC7540]).
This information is only visible if the client is populating the This information is only visible if the client is populating the
Server Name Indication extension. This need not be done, but may be Server Name Indication extension. This need not be done, but may be
done as per TLS standard and as stated above this has been done as per TLS standard and as stated above this has been
implemented by all major browsers. Therefore, even if existing implemented by all major browsers. Therefore, even if existing
network filters look out for seeing a Server Name Indication network filters look out for seeing a Server Name Indication
extension, they may not find one. It is also possible that SNI may extension, they may not find one. The SNI Encryption in TLS Through
be encrypted in future versions of TLS, but there is no way to do Tunneling [I-D.ietf-tls-sni-encryption] draft has been adopted by the
that currently. The per-domain nature of SNI may not reveal the TLS working group, which provides soltuions to encrypt SNI. As such,
specific service or media type being accessed, especially where the there will be an option to encrypt SNI in future versions of TLS.
domain is of a provider offering a range of email, video, Web pages The per-domain nature of SNI may not reveal the specific service or
etc. For example, certain blog or social network feeds may be deemed media type being accessed, especially where the domain is of a
'adult content', but the Server Name Indication will only indicate provider offering a range of email, video, Web pages etc. For
the server domain rather than a URL path. example, certain blog or social network feeds may be deemed 'adult
content', but the Server Name Indication will only indicate the
server domain rather than a URL path.
6.2. Application Layer Protocol Negotiation (ALPN) 6.3. Application Layer Protocol Negotiation (ALPN)
ALPN is a TLS extension which may be used to indicate the application ALPN is a TLS extension which may be used to indicate the application
protocol within the TLS session. This is likely to be of more value protocol within the TLS session. This is likely to be of more value
to the network where it indicates a protocol dedicated to a to the network where it indicates a protocol dedicated to a
particular traffic type (such as video streaming) rather than 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 multi-use protocol. ALPN is used as part of HTTP/2 'h2', but will
not indicate the traffic types which may make up streams within an not indicate the traffic types which may make up streams within an
HTTP/2 multiplex. ALPN will be encrypted in TLS 1.3. HTTP/2 multiplex. ALPN will be encrypted in TLS 1.3.
6.3. Content Length, BitRate and Pacing 6.4. Content Length, BitRate and Pacing
The content length of encrypted traffic is effectively the same as The content length of encrypted traffic is effectively the same as
the cleartext. Although block ciphers utilise padding, this makes a the cleartext. Although block ciphers utilise padding, this makes a
negligible difference. Bitrate and pacing are generally application negligible difference. Bitrate and pacing are generally application
specific, and do not change much when the content is encrypted. specific, and do not change much when the content is encrypted.
Multiplexed formats (such as HTTP/2 and QUIC) may however incorporate Multiplexed formats (such as HTTP/2 and QUIC) may however incorporate
several application streams over one connection, which makes the several application streams over one connection, which makes the
bitrate/pacing no longer application-specific. bitrate/pacing no longer application-specific.
7. Impact on Mobility Network Optimizations and New Services 7. Impact on Mobility Network Optimizations and New Services
skipping to change at page 38, line 42 skipping to change at page 39, line 30
11. Acknowledgements 11. Acknowledgements
Thanks to our reviewers, Natasha Rooney, Kevin Smith, Ashutosh Dutta, Thanks to our reviewers, Natasha Rooney, Kevin Smith, Ashutosh Dutta,
Brandon Williams, Jean-Michel Combes, Nalini Elkins, Paul Barrett, Brandon Williams, Jean-Michel Combes, Nalini Elkins, Paul Barrett,
Badri Subramanyan, Igor Lubashev, Suresh Krishnan, Dave Dolson, Badri Subramanyan, Igor Lubashev, Suresh Krishnan, Dave Dolson,
Mohamed Boucadair, Stephen Farrell, Warren Kumari, Alia Atlas, Roman Mohamed Boucadair, Stephen Farrell, Warren Kumari, Alia Atlas, Roman
Danyliw, and Mirja Kuhlewind for their editorial and content Danyliw, and Mirja Kuhlewind for their editorial and content
suggestions. Surya K. Kovvali provided material for section 7. suggestions. Surya K. Kovvali provided material for section 7.
Chris Morrow and Nik Teague provided reviews and updates specific to Chris Morrow and Nik Teague provided reviews and updates specific to
the DoS fingerprinting text. the DoS fingerprinting text. Brian Trammell provided the IPFIX text.
12. Informative References 12. Informative References
[ACCORD] "Acord BoF IETF95 https://www.ietf.org/proceedings/95/ [ACCORD] "Acord BoF IETF95
accord.html". https://www.ietf.org/proceedings/95/accord.html".
[CAIDA] "CAIDA *Anonymized Internet Traces* [CAIDA] "CAIDA *Anonymized Internet Traces*
[http://www.caida.org/data/overview/ and [http://www.caida.org/data/overview/ and
http://www.caida.org/data/passive/ http://www.caida.org/data/passive/
passive_2016_dataset.xml]". passive_2016_dataset.xml]".
[DarkMail] [DarkMail]
"The Dark Mail Technical Aliance https://darkmail.info/". "The Dark Mail Technical Aliance https://darkmail.info/".
[DOTS] https://datatracker.ietf.org/wg/dots/charter/, "DDoS Open [DOTS] https://datatracker.ietf.org/wg/dots/charter/, "DDoS Open
Threat Signaling IETF Working Group". Threat Signaling IETF Working Group".
[EFF] "Electronic Frontier Foundation https://www.eff.org/". [EFF] "Electronic Frontier Foundation https://www.eff.org/".
[EFF2014] "EFF Report on STARTTLS Downgrade Attacks [EFF2014] "EFF Report on STARTTLS Downgrade Attacks
https://www.eff.org/deeplinks/2014/11/starttls-downgrade- https://www.eff.org/deeplinks/2014/11/
attacks". starttls-downgrade-attacks".
[Enrich] Narseo Vallina-Rodriguez, et al., "Header Enrichment or [Enrich] Narseo Vallina-Rodriguez, et al., "Header Enrichment or
ISP Enrichment? Emerging Privacy Threats in Mobile ISP Enrichment? Emerging Privacy Threats in Mobile
Networks, Hot Middlebox'15, August 17-21 2015, London, Networks, Hot Middlebox'15, August 17-21 2015, London,
United Kingdom", 2015. United Kingdom", 2015.
[I-D.dolson-plus-middlebox-benefits] [I-D.dolson-plus-middlebox-benefits]
Dolson, D., Snellman, J., Boucadair, M., and C. Jacquenet, Dolson, D., Snellman, J., Boucadair, M., and C. Jacquenet,
"Beneficial Functions of Middleboxes", draft-dolson-plus- "Beneficial Functions of Middleboxes", draft-dolson-plus-
middlebox-benefits-03 (work in progress), March 2017. middlebox-benefits-03 (work in progress), March 2017.
[I-D.ietf-ippm-6man-pdm-option] [I-D.ietf-ippm-6man-pdm-option]
Elkins, N., Hamilton, R., and m. mackermann@bcbsm.com, Elkins, N., Hamilton, R., and m. mackermann@bcbsm.com,
"IPv6 Performance and Diagnostic Metrics (PDM) Destination "IPv6 Performance and Diagnostic Metrics (PDM) Destination
Option", draft-ietf-ippm-6man-pdm-option-13 (work in Option", draft-ietf-ippm-6man-pdm-option-13 (work in
progress), June 2017. progress), June 2017.
[I-D.ietf-mile-iodef-guidance] [I-D.ietf-mile-iodef-guidance]
Kampanakis, P. and M. Suzuki, "IODEF Usage Guidance", Kampanakis, P. and M. Suzuki, "Incident Object Description
draft-ietf-mile-iodef-guidance-10 (work in progress), May Exchange Format Usage Guidance", draft-ietf-mile-iodef-
2017. guidance-11 (work in progress), September 2017.
[I-D.ietf-tls-sni-encryption]
Huitema, C. and E. Rescorla, "SNI Encryption in TLS
Through Tunneling", draft-ietf-tls-sni-encryption-00 (work
in progress), August 2017.
[I-D.thomson-http-bc] [I-D.thomson-http-bc]
Thomson, M., Eriksson, G., and C. Holmberg, "Caching Thomson, M., Eriksson, G., and C. Holmberg, "Caching
Secure HTTP Content using Blind Caches", draft-thomson- Secure HTTP Content using Blind Caches", draft-thomson-
http-bc-01 (work in progress), October 2016. http-bc-01 (work in progress), October 2016.
[IPFIX-IANA]
"IP Flow Information Export (IPFIX) Entities
https://www.iana.org/assignments/ipfix/".
[JNSLP] Surveillance, Vol. 8 No. 3, "10 Standards for Oversight [JNSLP] Surveillance, Vol. 8 No. 3, "10 Standards for Oversight
and Transparency of National Intelligence Services and Transparency of National Intelligence Services
http://jnslp.com/". http://jnslp.com/".
[M3AAWG] "Messaging, Malware, Mobile Anti-Abuse Working Group [M3AAWG] "Messaging, Malware, Mobile Anti-Abuse Working Group
(M3AAWG) https://www.maawg.org/". (M3AAWG) https://www.maawg.org/".
[Map3GPP] http://www.3gpp.org/technologies, "Mapping between [Map3GPP] http://www.3gpp.org/technologies, "Mapping between
technologies and specifications". technologies and specifications".
[NoEncrypt] [NoEncrypt]
"ISPs Removing their Customers EMail Encryption "ISPs Removing their Customers EMail Encryption
https://www.eff.org/deeplinks/2014/11/starttls-downgrade- https://www.eff.org/deeplinks/2014/11/
attacks/". starttls-downgrade-attacks/".
[Nygren] https://blogs.akamai.com/2017/03/ reaching-toward- [Nygren] https://blogs.akamai.com/2017/03/ reaching-toward-
universal-tls-sni.html, "Erik Nygren, personal reference". universal-tls-sni.html, "Erik Nygren, personal reference".
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", [RFC2131] Droms, R., "Dynamic Host Configuration Protocol",
RFC 2131, DOI 10.17487/RFC2131, March 1997, RFC 2131, DOI 10.17487/RFC2131, March 1997,
<http://www.rfc-editor.org/info/rfc2131>. <https://www.rfc-editor.org/info/rfc2131>.
[RFC2504] Guttman, E., Leong, L., and G. Malkin, "Users' Security [RFC2504] Guttman, E., Leong, L., and G. Malkin, "Users' Security
Handbook", FYI 34, RFC 2504, DOI 10.17487/RFC2504, Handbook", FYI 34, RFC 2504, DOI 10.17487/RFC2504,
February 1999, <http://www.rfc-editor.org/info/rfc2504>. February 1999, <https://www.rfc-editor.org/info/rfc2504>.
[RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address [RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address
Translator (NAT) Terminology and Considerations", Translator (NAT) Terminology and Considerations",
RFC 2663, DOI 10.17487/RFC2663, August 1999, RFC 2663, DOI 10.17487/RFC2663, August 1999,
<http://www.rfc-editor.org/info/rfc2663>. <https://www.rfc-editor.org/info/rfc2663>.
[RFC2775] Carpenter, B., "Internet Transparency", RFC 2775, [RFC2775] Carpenter, B., "Internet Transparency", RFC 2775,
DOI 10.17487/RFC2775, February 2000, DOI 10.17487/RFC2775, February 2000,
<http://www.rfc-editor.org/info/rfc2775>. <https://www.rfc-editor.org/info/rfc2775>.
[RFC2804] IAB and IESG, "IETF Policy on Wiretapping", RFC 2804, [RFC2804] IAB and IESG, "IETF Policy on Wiretapping", RFC 2804,
DOI 10.17487/RFC2804, May 2000, DOI 10.17487/RFC2804, May 2000,
<http://www.rfc-editor.org/info/rfc2804>. <https://www.rfc-editor.org/info/rfc2804>.
[RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering:
Defeating Denial of Service Attacks which employ IP Source Defeating Denial of Service Attacks which employ IP Source
Address Spoofing", BCP 38, RFC 2827, DOI 10.17487/RFC2827, Address Spoofing", BCP 38, RFC 2827, DOI 10.17487/RFC2827,
May 2000, <http://www.rfc-editor.org/info/rfc2827>. May 2000, <https://www.rfc-editor.org/info/rfc2827>.
[RFC3135] Border, J., Kojo, M., Griner, J., Montenegro, G., and Z. [RFC3135] Border, J., Kojo, M., Griner, J., Montenegro, G., and Z.
Shelby, "Performance Enhancing Proxies Intended to Shelby, "Performance Enhancing Proxies Intended to
Mitigate Link-Related Degradations", RFC 3135, Mitigate Link-Related Degradations", RFC 3135,
DOI 10.17487/RFC3135, June 2001, DOI 10.17487/RFC3135, June 2001,
<http://www.rfc-editor.org/info/rfc3135>. <https://www.rfc-editor.org/info/rfc3135>.
[RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, [RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins,
C., and M. Carney, "Dynamic Host Configuration Protocol C., and M. Carney, "Dynamic Host Configuration Protocol
for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July
2003, <http://www.rfc-editor.org/info/rfc3315>. 2003, <https://www.rfc-editor.org/info/rfc3315>.
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550,
July 2003, <http://www.rfc-editor.org/info/rfc3550>. July 2003, <https://www.rfc-editor.org/info/rfc3550>.
[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, [RFC3971] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander,
"SEcure Neighbor Discovery (SEND)", RFC 3971, "SEcure Neighbor Discovery (SEND)", RFC 3971,
DOI 10.17487/RFC3971, March 2005, DOI 10.17487/RFC3971, March 2005,
<http://www.rfc-editor.org/info/rfc3971>. <https://www.rfc-editor.org/info/rfc3971>.
[RFC4787] Audet, F., Ed. and C. Jennings, "Network Address [RFC4787] Audet, F., Ed. and C. Jennings, "Network Address
Translation (NAT) Behavioral Requirements for Unicast Translation (NAT) Behavioral Requirements for Unicast
UDP", BCP 127, RFC 4787, DOI 10.17487/RFC4787, January UDP", BCP 127, RFC 4787, DOI 10.17487/RFC4787, January
2007, <http://www.rfc-editor.org/info/rfc4787>. 2007, <https://www.rfc-editor.org/info/rfc4787>.
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
Address Autoconfiguration", RFC 4862, Address Autoconfiguration", RFC 4862,
DOI 10.17487/RFC4862, September 2007, DOI 10.17487/RFC4862, September 2007,
<http://www.rfc-editor.org/info/rfc4862>. <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 [RFC5965] Shafranovich, Y., Levine, J., and M. Kucherawy, "An
Extensible Format for Email Feedback Reports", RFC 5965, Extensible Format for Email Feedback Reports", RFC 5965,
DOI 10.17487/RFC5965, August 2010, DOI 10.17487/RFC5965, August 2010,
<http://www.rfc-editor.org/info/rfc5965>. <https://www.rfc-editor.org/info/rfc5965>.
[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 [RFC6269] Ford, M., Ed., Boucadair, M., Durand, A., Levis, P., and
P. Roberts, "Issues with IP Address Sharing", RFC 6269, P. Roberts, "Issues with IP Address Sharing", RFC 6269,
DOI 10.17487/RFC6269, June 2011, DOI 10.17487/RFC6269, June 2011,
<http://www.rfc-editor.org/info/rfc6269>. <https://www.rfc-editor.org/info/rfc6269>.
[RFC6430] Li, K. and B. Leiba, "Email Feedback Report Type Value: [RFC6430] Li, K. and B. Leiba, "Email Feedback Report Type Value:
not-spam", RFC 6430, DOI 10.17487/RFC6430, November 2011, not-spam", RFC 6430, DOI 10.17487/RFC6430, November 2011,
<http://www.rfc-editor.org/info/rfc6430>. <https://www.rfc-editor.org/info/rfc6430>.
[RFC6455] Fette, I. and A. Melnikov, "The WebSocket Protocol", [RFC6455] Fette, I. and A. Melnikov, "The WebSocket Protocol",
RFC 6455, DOI 10.17487/RFC6455, December 2011, RFC 6455, DOI 10.17487/RFC6455, December 2011,
<http://www.rfc-editor.org/info/rfc6455>. <https://www.rfc-editor.org/info/rfc6455>.
[RFC6590] Falk, J., Ed. and M. Kucherawy, Ed., "Redaction of [RFC6590] Falk, J., Ed. and M. Kucherawy, Ed., "Redaction of
Potentially Sensitive Data from Mail Abuse Reports", Potentially Sensitive Data from Mail Abuse Reports",
RFC 6590, DOI 10.17487/RFC6590, April 2012, RFC 6590, DOI 10.17487/RFC6590, April 2012,
<http://www.rfc-editor.org/info/rfc6590>. <https://www.rfc-editor.org/info/rfc6590>.
[RFC6591] Fontana, H., "Authentication Failure Reporting Using the [RFC6591] Fontana, H., "Authentication Failure Reporting Using the
Abuse Reporting Format", RFC 6591, DOI 10.17487/RFC6591, Abuse Reporting Format", RFC 6591, DOI 10.17487/RFC6591,
April 2012, <http://www.rfc-editor.org/info/rfc6591>. April 2012, <https://www.rfc-editor.org/info/rfc6591>.
[RFC6650] Falk, J. and M. Kucherawy, Ed., "Creation and Use of Email [RFC6650] Falk, J. and M. Kucherawy, Ed., "Creation and Use of Email
Feedback Reports: An Applicability Statement for the Abuse Feedback Reports: An Applicability Statement for the Abuse
Reporting Format (ARF)", RFC 6650, DOI 10.17487/RFC6650, Reporting Format (ARF)", RFC 6650, DOI 10.17487/RFC6650,
June 2012, <http://www.rfc-editor.org/info/rfc6650>. June 2012, <https://www.rfc-editor.org/info/rfc6650>.
[RFC6651] Kucherawy, M., "Extensions to DomainKeys Identified Mail [RFC6651] Kucherawy, M., "Extensions to DomainKeys Identified Mail
(DKIM) for Failure Reporting", RFC 6651, (DKIM) for Failure Reporting", RFC 6651,
DOI 10.17487/RFC6651, June 2012, DOI 10.17487/RFC6651, June 2012,
<http://www.rfc-editor.org/info/rfc6651>. <https://www.rfc-editor.org/info/rfc6651>.
[RFC6652] Kitterman, S., "Sender Policy Framework (SPF) [RFC6652] Kitterman, S., "Sender Policy Framework (SPF)
Authentication Failure Reporting Using the Abuse Reporting Authentication Failure Reporting Using the Abuse Reporting
Format", RFC 6652, DOI 10.17487/RFC6652, June 2012, Format", RFC 6652, DOI 10.17487/RFC6652, June 2012,
<http://www.rfc-editor.org/info/rfc6652>. <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, [RFC7143] Chadalapaka, M., Satran, J., Meth, K., and D. Black,
"Internet Small Computer System Interface (iSCSI) Protocol "Internet Small Computer System Interface (iSCSI) Protocol
(Consolidated)", RFC 7143, DOI 10.17487/RFC7143, April (Consolidated)", RFC 7143, DOI 10.17487/RFC7143, April
2014, <http://www.rfc-editor.org/info/rfc7143>. 2014, <https://www.rfc-editor.org/info/rfc7143>.
[RFC7146] Black, D. and P. Koning, "Securing Block Storage Protocols [RFC7146] Black, D. and P. Koning, "Securing Block Storage Protocols
over IP: RFC 3723 Requirements Update for IPsec v3", over IP: RFC 3723 Requirements Update for IPsec v3",
RFC 7146, DOI 10.17487/RFC7146, April 2014, RFC 7146, DOI 10.17487/RFC7146, April 2014,
<http://www.rfc-editor.org/info/rfc7146>. <https://www.rfc-editor.org/info/rfc7146>.
[RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
Protocol (HTTP/1.1): Message Syntax and Routing", Protocol (HTTP/1.1): Message Syntax and Routing",
RFC 7230, DOI 10.17487/RFC7230, June 2014, RFC 7230, DOI 10.17487/RFC7230, June 2014,
<http://www.rfc-editor.org/info/rfc7230>. <https://www.rfc-editor.org/info/rfc7230>.
[RFC7234] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, [RFC7234] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching", Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching",
RFC 7234, DOI 10.17487/RFC7234, June 2014, RFC 7234, DOI 10.17487/RFC7234, June 2014,
<http://www.rfc-editor.org/info/rfc7234>. <https://www.rfc-editor.org/info/rfc7234>.
[RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an
Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May
2014, <http://www.rfc-editor.org/info/rfc7258>. 2014, <https://www.rfc-editor.org/info/rfc7258>.
[RFC7348] Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger, [RFC7348] Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger,
L., Sridhar, T., Bursell, M., and C. Wright, "Virtual L., Sridhar, T., Bursell, M., and C. Wright, "Virtual
eXtensible Local Area Network (VXLAN): A Framework for eXtensible Local Area Network (VXLAN): A Framework for
Overlaying Virtualized Layer 2 Networks over Layer 3 Overlaying Virtualized Layer 2 Networks over Layer 3
Networks", RFC 7348, DOI 10.17487/RFC7348, August 2014, Networks", RFC 7348, DOI 10.17487/RFC7348, August 2014,
<http://www.rfc-editor.org/info/rfc7348>. <https://www.rfc-editor.org/info/rfc7348>.
[RFC7435] Dukhovni, V., "Opportunistic Security: Some Protection [RFC7435] Dukhovni, V., "Opportunistic Security: Some Protection
Most of the Time", RFC 7435, DOI 10.17487/RFC7435, Most of the Time", RFC 7435, DOI 10.17487/RFC7435,
December 2014, <http://www.rfc-editor.org/info/rfc7435>. December 2014, <https://www.rfc-editor.org/info/rfc7435>.
[RFC7457] Sheffer, Y., Holz, R., and P. Saint-Andre, "Summarizing [RFC7457] Sheffer, Y., Holz, R., and P. Saint-Andre, "Summarizing
Known Attacks on Transport Layer Security (TLS) and Known Attacks on Transport Layer Security (TLS) and
Datagram TLS (DTLS)", RFC 7457, DOI 10.17487/RFC7457, Datagram TLS (DTLS)", RFC 7457, DOI 10.17487/RFC7457,
February 2015, <http://www.rfc-editor.org/info/rfc7457>. February 2015, <https://www.rfc-editor.org/info/rfc7457>.
[RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre,
"Recommendations for Secure Use of Transport Layer "Recommendations for Secure Use of Transport Layer
Security (TLS) and Datagram Transport Layer Security Security (TLS) and Datagram Transport Layer Security
(DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May
2015, <http://www.rfc-editor.org/info/rfc7525>. 2015, <https://www.rfc-editor.org/info/rfc7525>.
[RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext [RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext
Transfer Protocol Version 2 (HTTP/2)", RFC 7540, Transfer Protocol Version 2 (HTTP/2)", RFC 7540,
DOI 10.17487/RFC7540, May 2015, DOI 10.17487/RFC7540, May 2015,
<http://www.rfc-editor.org/info/rfc7540>. <https://www.rfc-editor.org/info/rfc7540>.
[RFC7619] Smyslov, V. and P. Wouters, "The NULL Authentication [RFC7619] Smyslov, V. and P. Wouters, "The NULL Authentication
Method in the Internet Key Exchange Protocol Version 2 Method in the Internet Key Exchange Protocol Version 2
(IKEv2)", RFC 7619, DOI 10.17487/RFC7619, August 2015, (IKEv2)", RFC 7619, DOI 10.17487/RFC7619, August 2015,
<http://www.rfc-editor.org/info/rfc7619>. <https://www.rfc-editor.org/info/rfc7619>.
[RFC7624] Barnes, R., Schneier, B., Jennings, C., Hardie, T., [RFC7624] Barnes, R., Schneier, B., Jennings, C., Hardie, T.,
Trammell, B., Huitema, C., and D. Borkmann, Trammell, B., Huitema, C., and D. Borkmann,
"Confidentiality in the Face of Pervasive Surveillance: A "Confidentiality in the Face of Pervasive Surveillance: A
Threat Model and Problem Statement", RFC 7624, Threat Model and Problem Statement", RFC 7624,
DOI 10.17487/RFC7624, August 2015, DOI 10.17487/RFC7624, August 2015,
<http://www.rfc-editor.org/info/rfc7624>. <https://www.rfc-editor.org/info/rfc7624>.
[RFC7754] Barnes, R., Cooper, A., Kolkman, O., Thaler, D., and E. [RFC7754] Barnes, R., Cooper, A., Kolkman, O., Thaler, D., and E.
Nordmark, "Technical Considerations for Internet Service Nordmark, "Technical Considerations for Internet Service
Blocking and Filtering", RFC 7754, DOI 10.17487/RFC7754, Blocking and Filtering", RFC 7754, DOI 10.17487/RFC7754,
March 2016, <http://www.rfc-editor.org/info/rfc7754>. March 2016, <https://www.rfc-editor.org/info/rfc7754>.
[RFC7799] Morton, A., "Active and Passive Metrics and Methods (with [RFC7799] Morton, A., "Active and Passive Metrics and Methods (with
Hybrid Types In-Between)", RFC 7799, DOI 10.17487/RFC7799, Hybrid Types In-Between)", RFC 7799, DOI 10.17487/RFC7799,
May 2016, <http://www.rfc-editor.org/info/rfc7799>. May 2016, <https://www.rfc-editor.org/info/rfc7799>.
[RFC7826] Schulzrinne, H., Rao, A., Lanphier, R., Westerlund, M., [RFC7826] Schulzrinne, H., Rao, A., Lanphier, R., Westerlund, M.,
and M. Stiemerling, Ed., "Real-Time Streaming Protocol and M. Stiemerling, Ed., "Real-Time Streaming Protocol
Version 2.0", RFC 7826, DOI 10.17487/RFC7826, December Version 2.0", RFC 7826, DOI 10.17487/RFC7826, December
2016, <http://www.rfc-editor.org/info/rfc7826>. 2016, <https://www.rfc-editor.org/info/rfc7826>.
[RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., [RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D.,
and P. Hoffman, "Specification for DNS over Transport and P. Hoffman, "Specification for DNS over Transport
Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May
2016, <http://www.rfc-editor.org/info/rfc7858>. 2016, <https://www.rfc-editor.org/info/rfc7858>.
[RFC8073] Moriarty, K. and M. Ford, "Coordinating Attack Response at [RFC8073] Moriarty, K. and M. Ford, "Coordinating Attack Response at
Internet Scale (CARIS) Workshop Report", RFC 8073, Internet Scale (CARIS) Workshop Report", RFC 8073,
DOI 10.17487/RFC8073, March 2017, DOI 10.17487/RFC8073, March 2017,
<http://www.rfc-editor.org/info/rfc8073>. <https://www.rfc-editor.org/info/rfc8073>.
[RFCEdit] https://www.rfc-editor.org/materials/abbrev.expansion.txt, [RFCEdit] https://www.rfc-editor.org/materials/abbrev.expansion.txt,
"RFC Editor Abbreviation List". "RFC Editor Abbreviation List".
[SACM] https://datatracker.ietf.org/wg/sacm/charter/, "Security [SACM] https://datatracker.ietf.org/wg/sacm/charter/, "Security
Automation and Continuous Monitoring (sacm) IETF Working Automation and Continuous Monitoring (sacm) IETF Working
Group". Group".
[TS3GPP] "3GPP TS 24.301, "Non-Access-Stratum (NAS) protocol for [TS3GPP] "3GPP TS 24.301, "Non-Access-Stratum (NAS) protocol for
Evolved Packet System (EPS); Stage 3"", 2017. Evolved Packet System (EPS); Stage 3"", 2017.
 End of changes. 56 change blocks. 
79 lines changed or deleted 150 lines changed or added

This html diff was produced by rfcdiff 1.46. The latest version is available from http://tools.ietf.org/tools/rfcdiff/