Effect of Pervasive Encryption on
Operators
Dell EMC
176 South St
Hopkinton
MA
USA
+1
Kathleen.Moriarty@dell.com
AT&T Labs
200 Laurel Avenue South
Middletown,
NJ
07748
USA
+1 732 420 1571
+1 732 368 1192
acmorton@att.com
Pervasive Monitoring (PM) attacks on the privacy of Internet users is
of serious concern to both the user and the operator communities.
RFC7258 discussed the critical need to protect users' privacy when
developing IETF specifications and also recognized making networks
unmanageable to mitigate PM is not an acceptable outcome, an appropriate
balance is needed. This document discusses current security and network
management practices that may be impacted by the shift to increased use
of encryption to help guide protocol development in support of
manageable, secure networks.
In response to pervasive monitoring revelations and the IETF
consensus that Pervasive Monitoring is an Attack , efforts are underway to increase encryption of
Internet traffic. Pervasive Monitoring (PM) is of serious concern to
users, operators, and application providers. RFC7258 discussed the
critical need to protect users' privacy when developing IETF
specifications and also recognized that making networks unmanageable to
mitigate PM is not an acceptable outcome, but rather that an appropriate
balance would emerge over time.
This document discusses practices currently used by network operators
to manage, operate, and secure their networks and how those practices
may be impacted by a shift to increased use of encryption. It provides
network operators' perspectives about the motivations and objectives of
those practices as well as effects anticipated by operators as use of
encryption increases. It is a summary of concerns of the operational
community as they transition to managing networks with less visibility.
The document does not endorse the use of the practices described herein.
Nor does it aim to provide a comprehensive treatment of the effects of
current practices, some of which have been considered controversial from
a technical or business perspective or contradictory to previous IETF
statements (e.g., [RFC 1958], [RFC 1984], [RFC 2804], [RFC 2775], [RFC
3724], [RFC 7754]).
This document aims to help IETF participants understand network
operators' perspectives about the impact of pervasive encryption, both
opportunistic and strong end-to-end encryption, on operational
practices. The goal is to help inform future protocol development to
ensure that operational impact is part of the conversation. Ideally, new
methods could be developed to accomplish the goals of current practices
despite changes in the extent to which cleartext will be available to
network operators. Discussion of current practices and the potential
future changes is provided as a prerequisite to potential future
cross-industry and cross-layer work to support the ongoing evolution
towards a functional Internet with pervasive encryption.
Traditional network management, planning, security operations, and
performance optimization have been developed in an Internet where a
large majority of data traffic flows without encryption. While
unencrypted traffic has made information that aids operations and
troubleshooting at all layers accessible, it has also made pervasive
monitoring by unseen parties possible. With broad support and increased
awareness of the need to consider privacy in all aspects across the
Internet, it is important to catalog existing management, operational,
and security practices that have depended upon the availability of
cleartext to function.
This document includes a sampling of current practices and does not
attempt to describe every nuance. Some sections cover technologies used
over a broad spectrum of devices and use cases.
Session encryption helps to prevent both passive and active attacks
on transport protocols; more on pervasive monitoring can be found in
Confidentiality in the Face of Pervasive Surveillance: A Threat Model
and Problem Statement . The Internet
Architecture Board (IAB) released a statement advocating for increased
use of encryption in November 2014. Perspectives on encryption
paradigms have also shifted. One such shift is documented in
"Opportunistic Security" (OS) , which suggests
that when use of authenticated encryption is not possible, cleartext
sessions should be upgraded to unauthenticated session encryption,
rather than no encryption. OS encourages upgrading from cleartext, but
cannot require or guarantee such upgrades. Once OS is used, it allows
for an evolution to authenticated encryption. These efforts are
necessary to improve end user's expectation of privacy, making
pervasive monitoring cost prohibitive. With OS in use, active attacks
are still possible on unauthenticated sessions. OS has been
implemented as NULL Authentication with IPsec
and there are a number of infrastructure use cases such as server to
server encryption, where this mode is deployed. IPsec with
authentication has many useful applications and usage has increased
for infrastructure applications such as for virtual private networks
between data centers.
Although there is a push for OS, there is also work being done to
improve the implementation, development and configuration of TLS and
DTLS sessions to prevent active attacks used to monitor or intercept
session data. The
(UTA) working group has been publishing documentation to improve
the security of TLS and DTLS sessions. They have documented the known
attack vectors in and have documented Best
Practices for TLS and DTLS in and have other
documents in the queue.
In addition to encrypted web site access (HTTP over TLS), there are
other well-deployed application level transport encryption efforts
such as mail transfer agent (MTA)-to-MTA session encryption transport
for email (SMTP over TLS) and gateway-to-gateway for instant messaging
(Extensible Messaging and Presence Protocol (XMPP) over TLS). Although
this does provide protection from transport layer attacks, the servers
could be a point of vulnerability if user-to-user encryption is not
provided for these messaging protocols. User-to-user content
encryption schemes, such as S/MIME and PGP for email and encryption
(e.g. Off-the-Record (OTR)) for XMPP are used by those interested to
protect their data as it crosses intermediary servers, preventing the
vulnerability described by providing an end-to-end solution.
User-to-user schemes are under review and additional options will
emerge to ease the configuration requirements, making this type of
option more accessible to non-technical users interested in protecting
their privacy.
Increased use of encryption, either opportunistic or authenticated,
at the transport, network or application layer, impacts how networks
are operated, managed, and secured. In some cases, new methods to
operate, manage, and secure networks will evolve in response. In other
cases, currently available capabilities for monitoring or
troubleshooting networks could become unavailable. This document lists
a collection of functions currently employed by network operators that
may be impacted by the shift to increased use of encryption. This
draft does not attempt to specify responses or solutions to these
impacts, but rather documents the current state.
This document refers to several different forms of service
providers, distinguished with adjectives. For example, network service
providers (or network operators) provide IP-packet transport
primarily, though they may bundle other services with packet
transport. Alternatively, application service providers primarily
offer systems that participate as an end-point in communications with
the application user, and hosting service providers lease computing,
storage, and communications systems in datacenters. In practice, many
companies perform two or more service provider roles, but may be
historically associated with one.
Network Service Providers (SP) for this definition include the
backbone Internet Service providers as well as those providing
infrastructure at scale for core Internet use (hosted infrastructure and
services such as email).
Following the Snowden revelations, application service providers
responded by encrypting traffic between their data centers (IPsec) to
prevent passive monitoring from taking place unbeknownst to them (Yahoo,
Google, etc.). Large mail service providers also began to encrypt
session transport (TLS) to hosted mail services. This and other
increases in the use of encryption had the immediate effect of helping
protect the privacy of users' data, but created a problem for some
network management functions. They could no longer gain access to some
session streams resulting in actions by several to regain their
operational practices that previously depended on cleartext data
sessions.
The EFF reported several network service
providers taking steps to prevent the use of SMTP over TLS by breaking
STARTTLS (section 3.2 of ), essentially
preventing the negotiation process resulting in fallback to the use of
clear text. In other cases, some service providers have relied on middle
boxes having access to clear text for the purposes of load balancing,
monitoring for attack traffic, meeting regulatory requirements, or for
other purposes. These middle box implementations, whether performing
functions considered legitimate by the IETF or not, have been impacted
by increases in encrypted traffic. Only methods keeping with the goal of
balancing network management and PM mitigation in should be considered in solution work resulting from
this document.
Network service providers use various techniques to operate, manage,
and secure their networks. The following subsections detail the purpose
of each technique and which protocol fields are used to accomplish each
task. In response to increased encryption of these fields, some network
service providers may be tempted to undertake undesirable security
practices in order to gain access to the fields in unencrypted data
flows. To avoid this situation, ideally new methods could be developed
to accomplish the same goals without service providers having the
ability to see session data.
Internet traffic surveys are useful in many pursuits, such as
input for CAIDA studies , network planning and
optimization. Tracking the trends in Internet traffic growth, from
earlier peer-to-peer communication to the extensive adoption of
unicast video streaming applications, has relied on a view of
traffic composition with a particular level of assumed accuracy,
based on access to cleartext by those conducting the surveys.
Passive monitoring makes inferences about observed traffic using
the maximal information available, and is subject to inaccuracies
stemming from incomplete sampling (of packets in a stream) or loss
due to monitoring system overload. When encryption conceals more
layers in each packet, reliance on pattern inferences and other
heuristics grows, and accuracy suffers. For example, the traffic
patterns between server and browser are dependent on browser
supplier and version, even when the sessions use the same server
application (e.g., web e-mail access). It remains to be seen whether
more complex inferences can be mastered to produce the same
monitoring accuracy.
Network operators use packet captures and protocol-dissecting
analyzers when responding to customer problems, to identify the
presence of attack traffic, and to identify root causes of the
problem such as misconfiguration. The protocol dissection is
generally limited to supporting protocols (e.g., DNS, DHCP), network
and transport (e.g., IP, TCP), and some higher layer protocols
(e.g., RTP, RTCP).
Network operators are often the first ones called upon to
investigate application problems (e.g., "my HD video is choppy").
When diagnosing a customer problem, the starting point may be a
particular application that isn't working. The ability to identify
the problem application's traffic is important and deep packet
inspection (DPI) is often used for this purpose; IP address
filtering is not useful for applications using CDNs or cloud
providers. After identifying the traffic, an operator may analyze
the traffic characteristics and routing of the traffic.
For example, by investigating packet loss (from TCP sequence and
acknowledgement numbers), round-trip-time (from TCP timestamp
options or application-layer transactions, e.g., DNS or HTTP
response time), TCP receive-window size, packet corruption (from
checksum verification), inefficient fragmentation, or
application-layer problems, the operator can narrow the problem to a
portion of the network, server overload, client or server
misconfiguration, etc. Network operators may also be able to
identify the presence of attack traffic as not conforming to the
application the user claims to be using.
One way of quickly excluding the network as the bottleneck during
troubleshooting is to check whether the speed is limited by the
endpoints. For example, the connection speed might instead be
limited by suboptimal TCP options, the sender's congestion window,
the sender temporarily running out of data to send, the sender
waiting for the receiver to send another request, or the receiver
closing the receive window. All this information can be derived from
the cleartext TCP header.
Packet captures and protocol-dissecting analyzers have been
important tools. Automated monitoring has also been used to
proactively identify poor network conditions, leading to maintenance
and network upgrades before user experience declines. For example,
findings of loss and jitter in VoIP traffic can be a predictor of
future customer dissatisfaction (supported by metadata from RTP/RTCP
protocol ), or increases in DNS response
time can generally make interactive web browsing appear sluggish.
But to detect such problems, the application or service stream must
first be distinguished from others.
When using increased encryption, operators lose a source of data
that may be used to debug user issues. Because of this, application
server operators using increased encryption should expect to be
called upon more frequently to assist with debugging and
troubleshooting, and thus may want to consider what tools can be put
in the hands of their clients or network operators.
Further, the performance of some services can be more efficiently
managed and repaired when information on user transactions is
available to the service provider. It may be possible to continue
such monitoring activities without clear text access to the
application layers of interest, but inaccuracy will increase and
efficiency of repair activities will decrease. For example, an
application protocol error or failure would be opaque to network
troubleshooters when transport encryption is applied, making root
cause location more difficult and therefore increasing the
time-to-repair. Repair time directly reduces the availability of the
service, and most network operators have made availability a key
metric in their Service Level Agreements and/or subscription
rebates. Also, there may be more cases of user communication
failures when the additional encryption processes are introduced
(e.g., key management at large scale), leading to more customer
service contacts and (at the same time) less information available
to network operations repair teams.
In mobile networks, knowledge about TCP's stream transfer
progress (by observing ACKs, retransmissions, packet drops, and the
Sector Utilization Level etc.) is further used to measure the
performance of Network Segments (Sector, eNodeB (eNB) etc.). This
information is used as Key Performance Indicators (KPIs) and for the
estimation of User/Service Key Quality Indicators at network edges
for circuit emulation (CEM) as well as input for mitigation methods.
If the make-up of active services per user and per sector are not
visible to a server that provides Internet Access Point Names (APN),
it cannot perform mitigation functions based on network segment
view.
It is important to note that the push for encryption by
application providers has been motivated by the application of the
described techniques. Some application providers have noted degraded
performance and/or user experience when network-based optimization
or enhancement of their traffic has occurred, and such cases may
result in additional operator troubleshooting, as well.
Fingerprinting is used in traffic analysis and monitoring to
identify traffic streams that match certain patterns. This technique
is sometimes used with clear text or encrypted sessions. Some
Distributed Denial of Service (DDoS) prevention techniques at the
network provider level rely on the ability to fingerprint traffic in
order to mitigate the effect of this type of attack. Thus,
fingerprinting may be an aspect of an attack or part of attack
countermeasures.
A common, early trigger for DDoS mitigation includes observing
uncharacteristic traffic volumes or sources; congestion; or
degradation of a given network or service. One approach to mitigate
such an attack involves distinguishing attacker traffic from
legitimate user traffic. The ability to examine layers and payloads
above transport provides a new range of filtering opportunities at
each layer in the clear. If fewer layers are in the clear, this
means that there are reduced filtering opportunities available to
mitigate attacks. However, fingerprinting is still possible.
Passive monitoring of network traffic can lead to invasion of
privacy by external actors at the endpoints of the monitored
traffic. Encryption of traffic end-to-end is one method to obfuscate
some of the potentially identifying information. Many DoS mitigation
systems perform this manner of passive monitoring.
For example, browser fingerprints are comprised of many
characteristics, including User Agent, HTTP Accept headers, browser
plug-in details, screen size and color details, system fonts and
time zone. A monitoring system could easily identify a specific
browser, and by correlating other information, identify a specific
user.
A standalone load balancer is a function one can take off the
shelf, place in front of a pool of servers, configure appropriately,
and it will balance the traffic load among servers in the pool. This
is a typical setup for load balancers. Standalone load balancers
rely on the plainly observable information in the packets they are
forwarding and rely on industry-accepted standards in interpreting
the plainly observable information. Typically, this is a 5-tuple of
the connection. This configuration terminates TLS sessions at the
load balancer, making it the end point instead of the server.
Standalone load balancers are considered middleboxes, but are an
integral part of server infrastructure that scales.
In contrast, an integrated load balancer is developed to be an
integral part of the service provided by the server pool behind that
load balancer. These load balancers can communicate state with their
pool of servers to better route flows to the appropriate servers.
They rely on non-standard system-specific information and
operational knowledge shared between the load balancer and its
servers.
Both standalone and integrated load balancers can be deployed in
pools for redundancy and load sharing. For high availability, it is
important that when packets belonging to a flow start to arrive at a
different load balancer in the load balancer pool, the packets
continue to be forwarded to the original server in the server pool.
The importance of this requirement increases as the chances of such
load balancer change event increases.
Mobile operators deploy integrated load balancers to assist with
maintaining connection state as devices migrate. With the
proliferation of mobile connected devices, there is an acute need
for connection-oriented protocols that maintain connections after a
network migration by an endpoint. This connection persistence
provides an additional challenge for multi-homed anycast-based
services typically employed by large content owners and Content
Distribution Networks (CDNs). The challenge is that a migration to a
different network in the middle of the connection greatly increases
the chances of the packets routed to a different anycast
point-of-presence (POP) due to the new network's different
connectivity and Internet peering arrangements. The load balancer in
the new POP, potentially thousands of miles away, will not have
information about the new flow and would not be able to route it
back to the original POP.
To help with the endpoint network migration challenges, anycast
service operations are likely to employ integrated load balancers
that, in cooperation with their pool servers, are able to ensure
that client-to-server packets contain some additional identification
in plainly-observable parts of the packets (in addition to the
5-tuple). As noted in Section 2 of , careful
consideration in protocol design to mitigate PM is important, while
ensuring manageability of the network.
Some integrated load balancers have the ability to use additional
plainly observable information even for today's protocols that are
not network migration tolerant. This additional information allows
for improved availability and scaleability of the load balancing
operation. For example, BGP reconvergence can cause a flow to switch
anycast POPs even without a network change by any endpoint.
Additionally, a system that is able to encode the identity of the
pool server in plain text information available in each incoming
packet is able to provide stateless load balancing. This ability
confers great reliability and scaleability advantages even if the
flow remains in a single POP, because the load balancing system is
not required to keep state of each flow. Even more importantly,
there's no requirement to continuously synchronize such state among
the pool of load balancers.
Current protocols, such as TCP, allow the development of
stateless integrated load balancers by availing such load balancers
of additional plain text information in client-to-server packets. In
case of TCP, such information can be encoded by having
server-generated sequence numbers (that are ACK'd by the client),
segment values, lengths of the packet sent, etc.
Mobile operators apply Self Organizing Networks (3GPP SON) for
intelligent workflows such as content-aware MLB (Mobility Load
Balancing). Where network load balancers have been configured to
route according to application-layer semantics, an encrypted payload
is effectively invisible. This has resulted in practices of
intercepting TLS in front of load balancers to regain that
visibility, but at a cost to security and privacy.
In future Network Function Virtualization (NFV) architectures,
load balancing functions are likely to be more prevalent (deployed
at locations throughout operators' networks), so they would be
handling traffic using encrypted tunnels whenever it is present.
Data transfer capacity resources in cellular radio networks tend
to be more constrained than in fixed networks. This is a result of
variance in radio signal strength as a user moves around a cell, the
rapid ingress and egress of connections as users hand off between
adjacent cells, and temporary congestion at a cell. Mobile networks
alleviate this by queuing traffic according to its required
bandwidth and acceptable latency: for example, a user is unlikely to
notice a 20ms delay when receiving a simple Web page or email, or an
instant message response, but will very likely notice a re-buffering
pause in a video playback or a VoIP call de-jitter buffer. Ideally,
the scheduler manages the queue so that each user has an acceptable
experience as conditions vary, but inferences of the traffic type
have been used to make bearer assignments and set scheduler
priority.
Deep Packet Inspection (DPI) allows identification of
applications based on payload signatures, in contrast to trusting
well-known port numbers. Application and transport layer encryption
make the traffic type estimation more complex and less accurate, and
therefore it may not be effectual to use this information as input
for queue management. With the use of WebSockets , for example, many forms of communications (from
isochronous/real-time to bulk/elastic file transfer) will take place
over HTTP port 80 or port 443, so only the messages and higher-layer
data will make application differentiation possible. If the
monitoring system sees only "HTTP port 443", it cannot distinguish
application streams that would benefit from priority queueing from
others that would not.
Mobile networks especially rely on content/application based
prioritization of Over-the-Top (OTT) services - each
application-type or service has different delay/loss/throughput
expectations, and each type of stream will be unknown to an edge
device if encrypted; this impedes dynamic-QoS adaptation. An
alternate way to achieve encrypted application separation is
possible when the User Equipment (UE) requests a dedicated bearer
for the specific application stream (known by the UE), using a
mechanism such as the one described in Section 6.5 of 3GPP TS 24.301
. The UE's request includes the Quality Class
Indicator (QCI) appropriate for each application, based on their
different delay/loss/throughput expectations. However, UE requests
for dedicated bearers and QCI may not be supported at the
subscriber's service level, or in all mobile networks.
These effects and potential alternative solutions have been
discussed at the accord BoF at
IETF95.
For User Plane Congestion Management (3GPP UPCON) – ability
to understand content and manage network during congestion.
Mitigating techniques such as deferred download, off-peak
acceleration, and outbound roamers.
Due to the characteristics of the mobile link,
performance-enhancing TCP proxies may perform local retransmission
at the mobile edge. In TCP, duplicated ACKs are detected and
potentially concealed when the proxy retransmits a segment that was
lost on the mobile link without involvement of the far end (see
section 2.1.1 of and section 3.5 of ).
This optimization at network edges measurably improves real-time
transmission over long delay Internet paths or networks with large
capacity-variation (such as mobile/cellular networks).
In general, performance-enhancing proxies have a lower Round-Trip
Time (RTT) to the client and therefore determine the responsiveness
of flow control. A lower RTT makes the flow control loop more
responsive to changing in the mobile network conditions and enables
faster adaptation in a delay and capacity varying network due to
user mobility.
Further, service-provider-operated proxies are used to reduce the
control delay between the sender and a receiver on a mobile network
where resources are limited. The RTT determines how quickly an
user's attempt to cancel a video is recognized and therefore how
quickly the traffic is stopped, thus keeping un-wanted video packets
from entering the radio scheduler queue.
An application-type-aware network edge (middlebox) can further
control pacing, limit simultaneous HD videos, or prioritize active
videos against new videos, etc.
The features and efficiency of some Internet services can be
augmented through analysis of user flows and the applications they
provide. For example, network caching of popular content at a
location close to the requesting user can improve delivery
efficiency (both in terms of lower request response times and
reduced use of International Internet links when content is remotely
located), and authorized parties acting on their behalf use DPI in
combination with content distribution networks to determine if they
can intervene effectively. Web proxies are widely used , and caching is supported by the recent update
of "Hypertext Transfer Protocol (HTTP/1.1): Caching" in . Encryption of packet contents at a given
protocol layer usually makes DPI processing of that layer and higher
layers impossible. That being said, it should be noted that some
content providers prevent caching to control content delivery
through the use of encrypted end-to-end sessions. CDNs vary in their
deployment options of end-to-end encryption. The business risk is a
motivation outside of privacy and pervasive monitoring that are
driving end-to-end encryption for these content providers.
Content replication in caches (for example live video, DRM
protected content) is used to most efficiently utilize the available
limited bandwidth and thereby maximize the user's Quality of
Experience (QoE). Especially in mobile networks, duplicating every
stream through the transit network increases backhaul cost for live
TV. The Enhanced Multimedia Broadcast/Multicast Services (3GPP
eMBMS) – trusted edge proxies facilitate delivering same
stream to different users, using either unicast or multicast
depending on channel conditions to the user.
Alternate approaches such as blind caches are being explored to allow caching
of encrypted content; however, they still need to intercept the
end-to-end transport connection.
In addition to caching, various applications exist to provide
data compression in order to conserve the life of the user's mobile
data plan and optimize delivery over the mobile link. The
compression proxy access can be built into a specific user level
application, such as a browser, or it can be available to all
applications using a system level application. The primary method is
for the mobile application to connect to a centralized server as a
proxy, with the data channel between the client application and the
server using compression to minimize bandwidth utilization. The
effectiveness of such systems depends on the server having access to
unencrypted data flows.
Mobile Networks and many ISPs operate under the regulations of
their licensing government authority. These regulations include Lawful
Intercept, adherence to Codes of Practice on content filtering, and
application of court order filters. Such regulations assume network
access to provide content filtering and accounting, as discussed
below.
There are numerous reasons why service providers might block
content: to comply with requests from law enforcement or regulatory
authorities, to effectuate parental controls, to enforce
content-based billing, or for other reasons, possibly considered
inappropriate by some. See RFC7754 for
a survey of Internet filtering techniques and motivations. This
section is intended to document a selection of current content
blocking practices by operators and the effects of encryption on
those practices. Content blocking may also happen at endpoints or at
the edge of enterprise networks, but those are not addressed in this
section.
In a mobile network content filtering usually occurs in the core
network. A proxy is installed which analyses the transport metadata
of the content users are viewing and either filters content based on
a blacklist of sites or based on the user's pre-defined profile
(e.g. for age sensitive content). Although filtering can be done by
many methods, one commonly used method involves a trigger based on
the proxy identifying a DNS lookup of a host name in a URL which
appears on a blacklist being used by the operator. The subsequent
requests to that domain will be re-routed to a proxy which checks
whether the full URL matches a blocked URL on the list, and will
return a 404 if a match is found. All other requests should
complete. This technique does not work in situations where DNS
traffic is encrypted (e.g., by employing
).
Another form of content filtering is called parental control,
where some users are deliberately denied access to age-sensitive
content as a feature to the service subscriber. Some sites involve a
mixture of universal and age-sensitive content and filtering
software. In these cases, more granular (application layer) metadata
may be used to analyze and block traffic. Methods that accessed
cleartext application-layer metadata no longer work when sessions
are encrypted. This type of granular filtering could occur at the
endpoint. However, the lack of ability to efficiently manage
endpoints as a service reduces providers' ability to offer parental
control.
Approved access to a network is a prerequisite to requests for
Internet traffic.
However, there are cases (beyond parental control) when a network
service provider currently redirects customer requests for content
(affecting content accessibility):
The network service provider is performing the accounting and
billing for the content provider, and the customer has not (yet)
purchased the requested content.
Further content may not be allowed as the customer has
reached their usage limit and needs to purchase additional data
service, which is the usual billing approach in mobile
networks.
Currently, some mobile network service providers redirect
the customer using HTTP redirect to a page that explains to those
customers the reason for the blockage and the steps to proceed. When
the HTTP headers and content are encrypted, this prevents mobile
carriers from intercepting the traffic and performing an HTTP
redirect. As a result, some mobile carriers block customer's
encrypted requests, which is a far less optimal customer experience
because the blocking reason must be conveyed by some other means.
The customer may need to call customer care to find out the reason,
both an inconvenience to the customer and additional overhead to the
mobile network service provider.
Further, when the requested service is about to consume the
remainder of the user's plan limits, the transmission could be
terminated and advance notifications may be sent to the user by
their service provider to warn the user ahead of the exhausted plan.
If web content is encrypted, the network provider cannot know the
data transfer size at request time. Lacking this visibility of the
application type and content size, the network would continue the
transmission and stop the transfer when the limit was reached. A
partial transfer may not be usable by the client wasting both
network and user resources, possibly leading to customer complaints.
The content provider does not know user's service plans or current
usage, and cannot warn the user of plan exhaustion.
In addition, mobile network operator often sell tariffs that
allow free-data access to certain sites, known as 'zero rating'. A
session to visit such a site incurs no additional cost or data usage
to the user. This feature is impacted if encryption hides the
details of the content domain from the network.
Application Layer Gateways (ALG) assist applications to set
connectivity across Network Address Translators (NAT), Firewalls,
and/or Load Balancers for specific applications running across
mobile networks. Section 2.9 of describes
the role of ALGs and their interaction with NAT and/or application
payloads. ALG are deployed with an aim to improve connectivity.
However, it is an IETF Best Common Practice recommendation that ALGs
for UDP-based protocols SHOULD be turned off .
One example of an ALG in current use is aimed at video
applications that use the Real Time Session Protocol (RTSP) primary stream as a means to identify related
Real Time Protocol/Real Time Control Protocol (RTP/RTCP) flows at set-up. The ALG in this case relies on
the 5-tuple flow information derived from RTSP to provision NAT or
other middle boxes and provide connectivity. Implementations vary,
and two examples follow:
Parse the content of the RTSP stream and identify the 5-tuple
of the supporting streams as they are being negotiated.
Intercept and modify the 5-tuple information of the
supporting media streams as they are being negotiated on the
RTSP stream, which is more intrusive to the media streams.
When RTSP stream content is encrypted, the 5-tuple information
within the payload is not visible to these ALG implementations, and
therefore they cannot provision their associated middelboxes with
that information.
Some mobile carriers use HTTP header insertion (see section 3.2.1
of ) to provide information about their
customers to third parties or to their own internal systems . Third parties use the inserted information for
analytics, customization, advertising, to bill the customer, or to
selectively allow or block content. HTTP header insertion is also
used to pass information internally between a mobile service
provider's sub-systems, thus keeping the internal systems loosely
coupled. When HTTP connections are encrypted, mobile network service
providers cannot insert headers to accomplish the functions
above.
Hosted environments have had varied requirements in the past for
encryption, with many businesses choosing to use these services
primarily for data and applications that are not business or privacy
sensitive. A shift prior to the revelations on surveillance/passive
monitoring began where businesses were asking for hosted environments to
provide higher levels of security so that additional applications and
service could be hosted externally. Businesses understanding the threats
of monitoring in hosted environments only increased that pressure to
provide more secure access and session encryption to protect the
management of hosted environments as well as for the data and
applications.
Hosted environments may have multiple levels of management access,
where some may be strictly for the Hosting SP (infrastructure that may
be shared among customers) and some may be accessed by a specific
customer for application management. In some cases, there are multiple
levels of hosting service providers, further complicating the security
of management infrastructure and the associated requirements.
Hosting service provider management access is typically segregated
from other traffic with a control channel and may or may not be
encrypted depending upon the isolation characteristics of the
management session. Customer access may be through a dedicated
connection, but discussion for that connection method is out-of-scope
for this document.
Application Service Providers may offer content-level monitoring
options to detect intellectual property leakage, or other attacks. In
service provider environments where Data Loss Prevention (DLP) has
been implemented on the basis of the service provider having cleartext
access to session streams, the use of encrypted streams prevents these
implementations from conducting content searches for the keywords or
phrases configured in the DLP system. DLP is often used to prevent the
leakage of Personally Identifiable Information (PII) as well as
financial account information, Personal Health Information (PHI), and
Payment Card Information (PCI). If session encryption is terminated at
a gateway prior to accessing these services, DLP on session data can
still be performed. The decision of where to terminate encryption to
hosted environments will be a risk decision made between the
application service provider and customer organization according to
their priorities. DLP can be performed at the server for the hosted
application and on an end user's system in an organization as
alternate or additional monitoring points of content; however, this is
not frequently done in a service provider environment.
Application service providers, by their very nature, control the
application endpoint. As such, much of the information gleaned from
sessions are still available on that endpoint. However, when a gap
exists in the application's logging and debugging capabilities, this
has led the application service provider to access data-in-transport
for monitoring and debugging.
Overlay networks (e.g. VXLAN, Geneve, etc.) may be used to indicate
desired isolation, but this is not sufficient to prevent deliberate
attacks that are aware of the use of the overlay network. It is
possible to use an overlay header in combination with IPsec, but this
adds the requirement for authentication infrastructure and may reduce
packet transfer performance. Additional extension mechanisms to
provide integrity and/or privacy protections are being investigated
for overlay encapsulations. Section 7 of [RFC7348] describes some of
the security issues possible when deploying VXLAN on Layer 2 networks.
Rogue endpoints can join the multicast groups that carry broadcast
traffic, for example.
Hosted applications that allow some level of customer management
access may also require monitoring by the hosting service provider.
Monitoring could include access control restrictions such as
authentication, authorization, and accounting for filtering and
firewall rules to ensure they are continuously met. Customer access
may occur on multiple levels, including user-level and
administrative access. The hosting service provider may need to
monitor access either through session monitoring or log evaluation
to ensure security service level agreements (SLA) for access
management are met. The use of session encryption to access hosted
environments limits access restrictions to the metadata described
below. Monitoring and filtering may occur at an:
IP-level with source and destination IP
addresses alone, or
IP and protocol-level with source IP
address, destination IP address, protocol number, source port
number, and destination port number.
Session encryption at the application level, TLS for example,
currently allows access to the 5-tuple. IP-level encryption, such as
IPsec in tunnel mode prevents access to the original 5-tuple and may
limit the ability to restrict traffic via filtering techniques. This
shift may not impact all hosting service provider solutions as
alternate controls may be used to authenticate sessions or access
may require that clients access such services by first connecting to
the organization before accessing the hosted application. Shifts in
access may be required to maintain equivalent access control
management. Logs may also be used for monitoring that access control
restrictions are met, but would be limited to the data that could be
observed due to encryption at the point of log generation. Log
analysis is out of scope for this document.
The following observations apply to any IT organization that is
responsible for delivering services, whether to third-parties, for
example as a web based service, or to internal customers in an
enterprise, e.g. a data processing system that forms a part of the
enterprise’s business.
Organizations responsible for the operation of a data center have
many processes which access the contents of IP packets (passive
methods of measurement, as defined in ).
These processes are typically for service assurance or security
purposes as part of their data center operations.
Examples include:
- Network Performance Monitoring/Application Performance
Monitoring
- Intrusion defense/prevention systems
- Malware detection
- Fraud Monitoring
- Application DDOS protection
- Cyber-attack investigation
- Proof of regulatory compliance
Many application service providers simply terminate
sessions to/from the Internet at the edge of the data center in the
form of SSL/TLS offload in the load balancer. Not only does this
reduce the load on application servers, it simplifies the processes
to enable monitoring of the session content.
However, in some situations, encryption deeper in the data center
may be necessary to protect personal information or in order to meet
industry regulations, e.g. those set out by the Payment Card
Industry (PCI). In such situations, various methods have been used
to allow service assurance and security processes to access
unencrypted data. These include SSL/TLS decryption in dedicated
units, which then forward packets to SP-controlled tools, or by
real-time or post-capture decryption in the tools themselves. The
use of tools that perform SSL/TLS decryption are impacted by the
increased use of encryption that prevents interception.
Data center operators may also maintain packet recordings in
order to be able to investigate attacks, breach of internal
processes, etc. In some industries, organizations may be legally
required to maintain such information for compliance purposes.
Investigations of this nature have used access to the unencrypted
contents of the packet. Alternate methods to investigate attacks or
breach of process will rely on endpoint information, such as logs.
As previously noted, logs often lack complete information, and this
is seen as a concern resulting in some relying on session access for
additional information.
Organizations are increasingly using hosted applications rather
than in-house solutions that require maintenance of equipment and
software. Examples include Enterprise Resource Planning (ERP)
solutions, payroll service, time and attendance, travel and expense
reporting among others. Organizations may require some level of
management access to these hosted applications and will typically
require session encryption or a dedicated channel for this
activity.
In other cases, hosted applications may be fully managed by a
hosting service provider with service level agreement expectations for
availability and performance as well as for security functions
including malware detection. Due to the sensitive nature of these
hosted environments, the use of encryption is already prevalent. Any
impact may be similar to an enterprise with tools being used inside of
the hosted environment to monitor traffic. Additional concerns were
not reported in the call for contributions.
Performance, availability, and other aspects of a SLA are often
collected through passive monitoring. For example:
Availability: ability to establish connections with hosts to
access applications, and discern the difference between network
or host-related causes of unavailability.
Performance: ability to complete transactions within a target
response time, and discern the difference between network or
host-related causes of excess response time.
Here, as with all passive monitoring, the accuracy of inferences
are dependent on the cleartext information available, and encryption
would tend to reduce the information and therefore, the accuracy of
each inference. Passive measurement of some metrics will be
impossible with encryption that prevents inferring packet
correspondence across multiple observation points, such as for
packet loss metrics.
Until application logging is sufficient, the ability to make
accurate inferences in an environment with increased encryption will
remain a gap for passive performance monitoring.
Mail (application) service providers vary in what services they
offer. Options may include a fully hosted solution where mail is
stored external to an organization's environment on mail service
provider equipment or the service offering may be limited to monitor
incoming mail to remove SPAM [Section 5.1], malware [Section 5.6],
and phishing attacks [Section 5.3] before mail is directed to the
organization's equipment. In both of these cases, content of the
messages and headers is monitored to detect SPAM, malware, phishing,
and other messages that may be considered an attack.
STARTTLS ought have zero effect on anti-SPAM efforts for SMTP
traffic. Anti-SPAM services could easily be performed on an SMTP
gateway, eliminating the need for TLS decryption services. The
impact to Anti-SPAM service providers should be limited to a change
in tools, where middle boxes were deployed to perform these
functions.
Many efforts are emerging to improve user-to-user encryption,
including promotion of PGP and newer efforts such as Dark Mail . Of course, SPAM filtering will not be possible
on encrypted content.
Numerous service offerings exist that provide hosted storage
solutions. This section describes the various offerings and details
the monitoring for each type of service and how encryption may impact
the operational and security monitoring performed.
Trends in data storage encryption for hosted environments include a
range of options. The following list is intentionally high-level to
describe the types of encryption used in coordination with data
storage that may be hosted remotely, meaning the storage is physically
located in an external data center requiring transport over the
Internet. Options for monitoring will vary with each encryption
approach described below.
For higher security and/or privacy of data and applications,
options that provide end-to-end encryption of the data from the
user's desktop or server to the storage platform may be preferred.
With this description, host level encryption includes any solution
that encrypts data at the object level, not transport level.
Encryption of data may be performed with libraries on the system or
at the application level, which includes file encryption services
via a file manager. Host-level encryption is useful when data
storage is hosted, or scenarios when storage location is determined
based on capacity or based on a set of parameters to automate
decisions. This could mean that large data sets accessed
infrequently could be sent to an off-site storage platform at an
external hosting service, data accessed frequently may be stored
locally, or the decision could be based on the transaction type.
Host-level encryption is grouped separately for the purpose of this
document since data may be stored in multiple locations including
off-site remote storage platforms. If session encryption is used,
the protocol is likely to be TLS.
Monitoring of hosted storage solutions that use host-level
(object) encryption is described in this subsection. Host-level
encryption can be employed for backup services, and occasionally
for external storage services (operated by a third party) when
internal storage limits are exceeded.
Monitoring of data flows to hosted storage solutions is
performed for security and operational purposes. The security
monitoring may be to detect anomalies in the data flows that could
include changes to destination, the amount of data transferred, or
alterations in the size and frequency of flows. Operational
considerations include capacity and availability monitoring.
There are multiple ways to achieve full disk encryption for
stored data. Encryption may be performed on data to be stored while
in transit close to the storage media with solutions like Controller
Based Encryption (CBE) or in the drive system with Self-Encrypting
Drives (SED). Session encryption is typically coupled with
encryption of these data at rest (DAR) solutions to also protect
data in transit. Transport encryption is likely via TLS.
Monitoring for transport of data to storage platforms, where
object level encryption is performed close to or on the storage
platform are similar to those described in the section on
Monitoring for Hosted Storage. The primary difference for these
solutions is the possible exposure of sensitive information, which
could include privacy related data, financial information, or
intellectual property if session encryption via TLS is not
deployed. Session encryption is typically used with these
solutions, but that decision would be based on a risk assessment.
There are use cases where DAR or disk-level encryption is
required. Examples include preventing exposure of data if physical
disks are stolen or lost. In the case where TLS is in use,
monitoring and the exposure of data is limited to a 5-tuple.
Storage services also include data replication which may occur
between data centers and may leverage Internet connections to tunnel
traffic. The traffic may use iSCSI or FC/IP
encapsulated in IPsec. Either transport or
tunnel mode may be used for IPsec depending upon the termination
points of the IPsec session, if it is from the storage platform
itself or from a gateway device at the edge of the data center
respectively.
Monitoring for data replication services are described in this
subsection.
Monitoring of data flows between data centers may be performed
for security and operational purposes and would typically
concentrate more on operational aspects since these flows are
essentially virtual private networks (VPN) between data centers.
Operational considerations include capacity and availability
monitoring. The security monitoring may be to detect anomalies in
the data flows, similar to what was described in the "Monitoring
for Hosted Storage Section". If IPsec tunnel mode is in use,
monitoring is limited to a 2-tuple, or with transport mode, a
5-tuple.
Encryption of network traffic within the private enterprise is a
growing trend, particularly in industries with audit and regulatory
requirements. Some enterprise internal networks are almost completely
TLS and/or IPsec encrypted.
For each type of monitoring, different techniques and access to parts
of the data stream are part of current practice. As we transition to an
increased use of encryption, alternate methods of monitoring for
operational purposes may be necessary to reduce the practice of breaking
encryption (other policies may apply in some enterprise settings).
Large corporate enterprises are the owners of the platforms, data,
and network infrastructure that provide critical business services to
their user communities. As such, these enterprises are responsible for
all aspects of the performance, availability, security, and quality of
experience for all user sessions. These responsibilities break down
into three basic areas:
Security Monitoring and Control
Application Performance Monitoring and Reporting
Network Diagnostics and Troubleshooting
In each of the above areas, technical support teams utilize
collection, monitoring, and diagnostic systems. Some organizations
currently use attack methods such as replicated TLS server RSA private
keys to decrypt passively monitored copies of encrypted TLS packet
streams.
For an enterprise to avoid costly application down time and deliver
expected levels of performance, protection, and availability, some
forms of traffic analysis, sometimes including examination of packet
payloads, are currently used.
Enterprise users are subject to the policies of their
organization and the jurisdictions in which the enterprise operates.
As such, proxies may be in use to:
intercept outbound session traffic to monitor for
intellectual property leakage (by users or, more likely these
days, through malware and trojans),
detect viruses/malware entering the network via email or web
traffic,
detect malware/Trojans in action, possibly connecting to
remote hosts,
detect attacks (Cross site scripting and other common web
related attacks),
track misuse and abuse by employees,
restrict the types of protocols permitted to/from the entire
corporate environment,
detect and defend against Internet DDoS attacks, including
both volumetric and layer 7 attacks.
A significant portion of malware hides its activity within
TLS or other encrypted protocols. This includes lateral movement,
Command and Control, and Data Exfiltration. Detecting these
functions are important to effective monitoring and mitigation of
malicious traffic, not limited to malware.
Security monitoring in the enterprise may also be performed at
the endpoint with numerous current solutions that mitigate the same
problems as some of the above mentioned solutions. Since the
software agents operate on the device, they are able to monitor
traffic before it is encrypted, monitor for behavior changes, and
lock down devices to use only the expected set of applications.
Session encryption does not affect these solutions. Some might argue
that scaling is an issue in the enterprise, but some large
enterprises have used these tools effectively.
There are two main goals of monitoring:
Assess traffic volume on a per-application basis, for
billing, capacity planning, optimization of geographical
location for servers or proxies, and other goals.
Assess performance in terms of application response time and
user perceived response time.
Network-based Application Performance Monitoring tracks
application response time by user and by URL, which is the
information that the application owners and the lines of business
request. Content Delivery Networks (CDNs) add complexity in
determining the ultimate endpoint destination. By their very nature,
such information is obscured by CDNs and encrypted protocols --
adding a new challenge for troubleshooting network and application
problems. URL identification allows the application support team to
do granular, code level troubleshooting at multiple tiers of an
application.
New methodologies to monitor user perceived response time and to
separate network from server time are evolving. For example, the
IPv6 Destination Option Header (DOH) implementation of Performance
and Diagnostic Metrics (PDM) will provide this . Using PDM with IPSec
Encapsulating Security Payload (ESP) Transport Mode requires
placement of the PDM DOH within the ESP encrypted payload to avoid
leaking timing and sequence number information that could be useful
to an attacker. Use of PDM DOH also may introduce some security
weaknesses, including a timing attack, as described in Section 7 of
. For these and other
reasons, requires
that the PDM DOH option be explicitly turned on by administrative
action in each host where this measurement feature will be used.
One primary key to network troubleshooting is the ability to
follow a transaction through the various tiers of an application in
order to isolate the fault domain. A variety of factors relating to
the structure of the modern data center and multi-tiered application
have made it difficult to follow a transaction in network traces
without the ability to examine some of the packet payload. Alternate
methods, such as log analysis need improvement to fill this gap.
Content Delivery Networks (CDNs) and NATs and Network Address
and Port Translators (NAPT) obscure the ultimate endpoint
designation (See for types of address
sharing and a list of issues). Troubleshooting a problem for a
specific end user requires finding information such as the IP
address and other identifying information so that their problem
can be resolved in a timely manner.
NAT is also frequently used by lower layers of the data center
infrastructure. Firewalls, Load Balancers, Web Servers, App
Servers, and Middleware servers all regularly NAT the source IP of
packets. Combine this with the fact that users are often allocated
randomly by load balancers to all these devices, the network
troubleshooter is often left with very few options in today's
environment due to poor logging implementations in applications.
As such, network troubleshooting is used to trace packets at a
particular layer, decrypt them, and look at the payload to find a
user session.
This kind of bulk packet capture and bulk decryption is
frequently used when troubleshooting a large and complex
application. Endpoints typically don't have the capacity to handle
this level of network packet capture, so out-of-band networks of
robust packet brokers and network sniffers that use techniques
such as copies of TLS RSA private keys accomplish this task
today.
TCP Pipelining/Session Multiplexing used mainly by middle boxes
today allow for multiple end user sessions to share the same TCP
connection. Today's network troubleshooter often relies upon
session decryption to tell which packet belongs to which end user,
since the logs are currently inadequate for the analysis
performed.
Increased use of HTTP/2 will likely further increase the
prevalence of session multiplexing, both on the Internet and in
the private data center.
When an application server makes an HTTP service call to back
end services on behalf of a user session, it uses a completely
different URL and a completely different TCP connection.
Troubleshooting via network trace involves matching up the user
request with the HTTP service call. Some organizations do this
today by decrypting the TLS packet and inspecting the payload.
Logging has not been adequate for their purposes.
Many applications use text formats such as XML to transport
data or application level information. When transaction failures
occur and the logs are inadequate to determine the cause, network
and application teams work together, each having a different view
of the transaction failure. Using this troubleshooting method, the
network packet is correlated with the actual problem experienced
by an application to find a root cause. The inability to access
the payload prevents this method of troubleshooting.
Corporate networks commonly monitor outbound session traffic to
detect or prevent attacks as well as to guarantee service level
expectations. In some cases, alternate options are available when
encryption is in use, but techniques like that of data leakage
prevention tools at a proxy would not be possible if encrypted traffic
cannot be intercepted, encouraging alternate options such as
performing these functions at the edge.
Some DLP tools intercept traffic at the Internet gateway or proxy
services with the ability to man-in-the-middle (MiTM) encrypted
session traffic (HTTP/TLS). These tools may use key words important to
the enterprise including business sensitive information such as trade
secrets, financial data, personally identifiable information (PII), or
personal health information (PHI). Various techniques are used to
intercept HTTP/TLS sessions for DLP and other purposes, and are
described in "Summarizing Known Attacks on TLS and DTLS" . Note: many corporate policies allow access to
personal financial and other sites for users without interception.
Another option is to terminate a TLS session prior to the point where
monitoring is performed.
Monitoring traffic patterns for anomalous behavior such as
increased flows of traffic that could be bursty at odd times or flows
to unusual destinations (small or large amounts of traffic) is common.
This traffic may or may not be encrypted and various methods of
encryption or just obfuscation may be used.
Restrictions on traffic to approved sites: Web proxies are
sometimes used to filter traffic, allowing only access to well-known
sites found to be legitimate and free of malware on last check by a
proxy service company. This type of restriction is usually not
noticeable in a corporate setting as the typical corporate user does
not access sites that are not well-known to these tools, but may be
noticeable to those in research who are unable to access colleague's
individual sites or new web sites that have not yet been screened. In
situations where new sites are required for access, they can typically
be added after notification by the user or proxy log alerts and
review. Home mail account access may be blocked in corporate settings
to prevent another vector for malware to enter as well as for
intellectual property to leak out of the network. This method remains
functional with increased use of encryption and may be more effective
at preventing malware from entering the network. Web proxy solutions
monitor and potentially restrict access based on the destination URL
or the DNS name. A complete URL may be used in cases where access
restrictions vary for content on a particular site or for the sites
hosted on a particular server.
Desktop DLP tools are used in some corporate environments as well.
Since these tools reside on the desktop, they can intercept traffic
before it is encrypted and may provide a continued method of
monitoring intellectual property leakage from the desktop to the
Internet or attached devices.
DLP tools can also be deployed by Network Service providers, as
they have the vantage point of monitoring all traffic paired with
destinations off the enterprise network. This makes an effective
solution for enterprises that allow "bring-your-own" devices when the
traffic is not encrypted, and for devices outside the desktop category
(such as mobile phones) that are used on corporate networks
nonetheless.
Enterprises may wish to reduce the traffic on their Internet access
facilities by monitoring requests for within-policy content and
caching it. In this case, repeated requests for Internet content
spawned by URLs in e-mail trade newsletters or other sources can be
served within the enterprise network. Gradual deployment of end to end
encryption would tend to reduce the cacheable content over time, owing
to concealment of critical headers and payloads. Many forms of
enterprise performance management may be similarly affected.
Effective incident response today requires collaboration at Internet
scale. This section will only focus on efforts of collaboration at
Internet scale that are dedicated to specific attack types. They may
require new monitoring and detection techniques in an increasingly
encrypted Internet. As mentioned previously, some service providers have
been interfering with STARTTLS to prevent session encryption to be able
to perform functions they are used to (injecting ads, monitoring, etc.).
By detailing the current monitoring methods used for attack detection
and response, this information can be used to devise new monitoring
methods that will be effective in the changed Internet via collaboration
and innovation.
The largest operational effort to prevent mail abuse is through the
Messaging, Malware, Mobile Anti-Abuse Working Group (M3AAWG). Mail abuse is combatted directly with mail
administrators who can shut down or stop continued mail abuse
originating from large scale providers that participate in using the
Abuse Reporting Format (ARF) agents standardized in the IETF , , , , , , and . The ARF agent directly reports abuse messages to
the appropriate service provider who can take action to stop or
mitigate the abuse. Since this technique uses the actual message, the
use of SMTP over TLS between mail gateways will not affect its
usefulness. As mentioned previously, SMTP over TLS only protects data
while in transit and the messages may be exposed on mail servers or
mail gateways if a user-to-user encryption method is not used. Current
user-to-user message encryption methods on email (S/MIME and PGP) do
not encrypt the email header information used by ARF and the service
provider operators in their abuse mitigation efforts.
Response to Denial of Service (DoS) attacks are typically
coordinated by the SP community with a few key vendors who have tools
to assist in the mitigation efforts. Traffic patterns are determined
from each DoS attack to stop or rate limit the traffic flows with
patterns unique to that DoS attack.
Data types used in monitoring traffic for DDoS are described in the
DDoS Open Threat Signaling (DOTS) working
group documents in development.
Data types used in DDoS attacks have been detailed in the IODEF
Guidance draft , Appendix
A.2, with the help of several members of the service provider
community. The examples provided are intended to help identify the
useful data in detecting and mitigating these attacks independent of
the transport and protocol descriptions in the drafts.
Investigations and response to phishing attacks follow well-known
patterns, requiring access to specific fields in email headers as well
as content from the body of the message. When reporting phishing
attacks, the recipient has access to each field as well as the body to
make content reporting possible, even when end-to-end encryption is
used. The email header information is useful to identify the mail
servers and accounts used to generate or relay the attack messages in
order to take the appropriate actions. The content of the message
often contains an embedded attack that may be in an infected file or
may be a link that results in the download of malware to the user's
system.
Administrators often find it helpful to use header information to
track down similar message in their mail queue or users inboxes to
prevent further infection. Combinations of To:, From:, Subject:,
Received: from header information might be used for this purpose.
Administrators may also search for document attachments of the same
name, size, or containing a file with a matching hash to a known
phishing attack. Administrators might also add URLs contained in
messages to block lists locally or this may also be done by browser
vendors through larger scales efforts like that of the Anti-Phishing
Working Group (APWG). See the Coordinating Attack Response at Internet
Scale (CARIS) workshop Report for additional
information and pointers to the APWG's efforts on anti- phishing.
A full list of the fields used in phishing attack incident response
can be found in RFC5901. Future plans to increase privacy protections
may limit some of these capabilities if some email header fields are
encrypted, such as To:, From:, and Subject: header fields. This does
not mean that those fields should not be encrypted, only that we
should be aware of how they are currently used.
Some products protect users from phishing by maintaining lists of
known phishing domains (such as misspelled bank names) and blocking
access. This can be done by observing DNS, clear-text HTTP, or SNI in
TLS, in addition to analyzing email. Alternate options to detect and
prevent phishing attacks may be needed. More recent examples of data
exchanged in spear phishing attacks has been detailed in the IODEF
Guidance draft , Appendix
A.3.
Botnet detection and mitigation is complex and may involve hundreds
or thousands of hosts with numerous Command and Control (C&C)
servers. The techniques and data used to monitor and detect each may
vary. Connections to C&C servers are typically encrypted,
therefore a move to an increasingly encrypted Internet may not affect
the detection and sharing methods used.
Malware monitoring and detection techniques vary. As mentioned in
the enterprise section, malware monitoring may occur at gateways to
the organization analyzing email and web traffic. These services can
also be provided by service providers, changing the scale and location
of this type of monitoring. Additionally, incident responders may
identify attributes unique to types of malware to help track down
instances by their communication patterns on the Internet or by
alterations to hosts and servers.
Data types used in malware investigations have been summarized in
an example of the IODEF Guidance draft , Appendix A.1.
The IETF has reacted to spoofed source IP address-based attacks,
recommending the use of network ingress filtering and the unicast Reverse Path Forwarding (uRPF)
mechanism . But uRPF suffers from limitations
regarding its granularity: a malicious node can still use a spoofed IP
address included inside the prefix assigned to its link. The Source
Address Validation Improvements (SAVI) mechanisms try to solve this
issue. Basically, a SAVI mechanism is based on the monitoring of a
specific address assignment/management protocol (e.g., SLAAC , SEND , DHCPv4/v6 ) and, according to this
monitoring, set-up a filtering policy allowing only the IP flows with
a correct source IP address (i.e., any packet with a source IP
address, from a node not owning it, is dropped). The encryption of
parts of the address assignment/management protocols, critical for
SAVI mechanisms, can result in a dysfunction of the SAVI
mechanisms.
Although incident response work will continue, new methods to
prevent system compromise through security automation and continuous
monitoring may provide alternate approaches
where system security is maintained as a preventative measure.
This section describes specific techniques used in monitoring
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.
Many of the accounting, monitoring and measurement tasks described
in this document, especially , , , ,
and use the IPFIX protocol
for export and storage of the monitored
information. IPFIX evolved from the widely-deployed NetFlow protocol
, 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 provides a
variety of Information Elements (IEs)
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
recommends encryption for this data at rest, and the IP Flow Anonymization
specification 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.
When initiating the TLS handshake, the Client may provide an
extension field (server_name) which 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 reports that
many of their customer 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 Server Name Indication (SNI) extension
(see section 9.2 of ).
This information is only visible if the client is populating the
Server Name Indication extension. This need not be done, but may be
done as per TLS standard and as stated above this has been implemented
by all major browsers. Therefore, even if existing network filters
look out for seeing a Server Name Indication extension, they may not
find one. The SNI Encryption
in TLS Through Tunneling draft has been adopted by the TLS
working group, which provides soltuions 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
Server Name Indication will only indicate the server domain rather
than a URL path.
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 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 which may make up streams within an HTTP/2
multiplex. ALPN will be encrypted in TLS 1.3.
The content length of encrypted traffic is effectively the same as
the cleartext. Although block ciphers utilise 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) may however incorporate
several application streams over one connection, which makes the
bitrate/pacing no longer application-specific.
This section considers the effects of transport level encryption on
existing forms of mobile network optimization techniques, as well as
potential new services. The material in this section assumes familiarity
with mobile network concepts, specifications, and architectures. Readers
who need additional background should start with the 3GPP's web pages on
various topics of interest, especially the
article on Long Term Evolution (LTE). 3GPP provides a mapping between
their expanding technologies and the different series of technical
specifications . 3GPP also has a canonical
specification of their vocabulary, definitions, and acronyms , as does the RFC Editor for abbreviations .
The stream of TCP ACKs that flow from a receiver of a byte stream
using TCP for reliability, flow-control, and NAT/firewall transversal
is called an ACK stream. The ACKs contain segment numbers that confirm
successful transmission and their RTT, or indicate packet loss
(duplicate ACKs). If this view of progress of stream transfer is lost,
then the mobile network has greatly reduced ability to monitor
transport layer performance. When the ACK stream is encrypted, it
prevents the following mobile network functions from operating:
Measurement of Network Segment (Sector, eNodeB (eNB) etc.)
characterization KPIs (Retransmissions, packet drops, Sector
Utilization Level etc.), estimation of User/Service KQIs at
network edges for circuit emulation (CEM), and mitigation methods.
The active services per user and per sector are not visible to a
server that only services Internet Access Point Names (APN), and
thus could not perform mitigation functions based on network
segment view.
Ability to deploy SP-operated proxies that reduce control
round-trip time (RTT) between the TCP transmitter and receiver.
The RTT determines how quickly a user’s attempt to cancel a
video is recognized (how quickly the traffic is stopped, thus
keeping un-wanted video packets from entering the radio scheduler
queue).
Performance-enhancing proxy with low RTT determines the
responsiveness of TCP flow control, and enables faster adaptation
in a delay & capacity varying network due to user mobility.
Low RTT permits use of a smaller send window, which makes the flow
control loop more responsive to changing mobile network
conditions.
When the Transport Header is encrypted, it prevents the following
mobile network features from operating:
Application-type-aware network edge (middlebox) that could
control pacing, limit simultaneous HD videos, prioritize active
videos against new videos, etc.
For Self Organizing Networks (3GPP SON) – intelligent SON
workflows such as content-aware MLB (Mobility Load Balancing)
Reduces the benefits IP/DSCP-based transit network delivery
optimizations where a mobile<->transit marking agreement
exists; since multiple applications are multiplexed within the
same 5-tuple transport connection, a reasonable assumption is that
the DSCP markings would be withheld from the outer IP header to
further obscure which packets belong to each application flow.
Advance notification for dense data usages – If the
application types are visible, transit network element could warn
(ahead of usage) that the requested service consumes user plan
limits, and transmission could be terminated. Without such
visibility, the network might have to continue the operation and
stop the operation at the limit. Partially loaded content wastes
resources and may not be usable by the client, thus increasing
customer complaints. Content publisher will not know user-service
plans, and Network Edge would not know data transfer lengths
before large object is requested.
This section describes some new/emerging mobile services and how
they might be affected with transport encryption:
Content/Application based Prioritization of Over-the-Top (OTT)
services – each application-type or service has different
delay/loss/throughput expectations, and each type of stream will
be unknown to an edge device if encrypted; this impedes
dynamic-QoS adaptation.
Rich Communication Services (3GPP-RCS) using different Quality
Class Indicators (QCIs in LTE) – Operators offer different
QoS classes for value-added services. The QCI type is visible in
RAN control plane and invisible in user plane, thus the QCI cannot
be set properly when the application -type is unknown.
The transport header encryption prevents trusted transit proxies.
It may be that the benefits of such proxies could be achieved by end
to end client & server optimizations and distribution using CDNs,
plus the ability to continue connections across different access
technologies (across dynamic user IP addresses). The following aspects
need to be considered in this approach:
In a wireless mobile network, the delay and channel capacity
per user and sector varies due to coverage, contention, user
mobility, and scheduling balances fairness, capacity and service
QoE. If most users are at the cell edge, the controller cannot use
more complex QAM, thus reducing total cell capacity; similarly if
a UMTS edge is serving some number of CS-Voice Calls, the
remaining capacity for packet services is reduced.
Roamers: Mobile wireless networks service in-bound roamers
(Users of Operator A in a foreign operator Network B) by
backhauling their traffic though Operator B’s network to
Operator A’s Network and then serving through the P-Gateway
(PGW), General GPRS Support Node (GGSN), Content Distribution
Network (CDN) etc., of Operator A (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.
Issues in deploying CDNs in RAN: Decreasing Client-Server
control loop requires deploying CDNs/Cloud functions that
terminate encryption closer to the edge. In Cellular RAN, the user
IP traffic is encapsulated into General Packet Radio Service
(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 APN. Since CDNs generally operate on user IP flows,
deploying them would require enhancing them with tunnel
translation, etc., tunnel management functions.
While CDNs that de-encrypt flows or split-connection proxy
(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;
thus content from some Small-Medium Businesses (SMBs) would not
get such CDN benefits.
In the best case scenario, engineers and other innovators would work
to solve the problems at hand in new ways rather than prevent the use of
encryption. As stated in , "an appropriate
balance (between network management and PM mitigations) will emerge over
time as real instances of this tension are considered."
There has already been documented cases of service providers
preventing STARTTLS to prevent session
encryption negotiation on some session to inject a super cookie. In
order to effectively deploy encryption and prevent interception,
considerations for protocol design should factor in network management
functions to work toward the balance called out in RFC7258.
It is well known that national surveillance programs monitor traffic
as Internet security practitioners monitor for
criminal activities. Governments vary on their balance between
monitoring versus the protection of user privacy, data, and assets.
Those that favor unencrypted access to data ignore the real need to
protect users' identity, financial transactions and intellectual
property, which requires security and encryption to prevent crime. A
clear understanding of technology, encryption, and monitoring goals will
aid in the development of solutions to appropriately balance these with
privacy. As this understanding increases, hopefully the discussions will
improve; this draft is meant to help further the discussion.
Changes to improve encryption or to deploy OS methods have little
impact on the detection of malicious actors; they already have access to
strong encryption. The current push to increase encryption is aimed at
increasing users' privacy and providing application integrity. There is
already protection in place for purchases, financial transactions,
systems management infrastructure, and intellectual property although
this too can be improved. The Opportunistic Security (OS) efforts aim to increase the costs of monitoring
through the use of encryption that can be subject to active attacks, but
make passive monitoring broadly cost prohibitive. This is meant to
restrict monitoring to sessions where there is reason to have
suspicion.
There are no additional security considerations as this is a summary
and does not include a new protocol or functionality.
This memo makes no requests of IANA.
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,
and Mirja Kuhlewind 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.
Electronic Frontier Foundation https://www.eff.org/
CAIDA *Anonymized Internet Traces*
[http://www.caida.org/data/overview/ and
http://www.caida.org/data/passive/passive_2016_dataset.xml]
Messaging, Malware, Mobile Anti-Abuse Working Group (M3AAWG)
https://www.maawg.org/
ISPs Removing their Customers EMail Encryption
https://www.eff.org/deeplinks/2014/11/starttls-downgrade-attacks/
Acord BoF IETF95
https://www.ietf.org/proceedings/95/accord.html
10 Standards for Oversight and Transparency of National
Intelligence Services http://jnslp.com/
Surveillance, Vol. 8 No. 3
EFF Report on STARTTLS Downgrade Attacks
https://www.eff.org/deeplinks/2014/11/starttls-downgrade-attacks
3GPP Web pages on specific topics of interest
http://www.3gpp.org/technologies/95-keywords-acronyms
3GPP TR 21.905 V13.1.0 (2016-06) Vocabulary for 3GPP
Specifications
https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=558
RFC Editor Abbreviation List
https://www.rfc-editor.org/materials/abbrev.expansion.txt
Mapping between technologies and specifications
http://www.3gpp.org/technologies
Investigating Transparent Web Proxies in Cellular Networks,
Passive and Active Measurement Conference (PAM)
USC
Header Enrichment or ISP Enrichment? Emerging Privacy Threats
in Mobile Networks, Hot Middlebox’15, August 17-21 2015,
London, United Kingdom
ICSI Berkley
Security Automation and Continuous Monitoring (sacm) IETF
Working Group
DDoS Open Threat Signaling IETF Working Group
Erik Nygren, personal reference
3GPP TS 24.301, "Non-Access-Stratum (NAS) protocol for
Evolved Packet System (EPS); Stage 3"
The Dark Mail Technical Aliance
https://darkmail.info/
IP Flow Information Export (IPFIX) Entities
https://www.iana.org/assignments/ipfix/