Re: [saag] draft-mm-wg-effect-encrypt-03

[<[e-mail]>]

Kathleen and Al,



The "Effect of Ubiquitous Encryption" draft is an excellent summary of the impact on operations and network management posed by the changes to the security environment.  
Great work, guys!!!

I wanted to comment on a few things as far as they impact private enterprises.


1. In the Abstract: we may want to remind the reader that network management includes troubleshooting because a number of changes will need to be made in how troubleshooting is done.  I would suggest the following:

Old: This draft includes a collection of current security and network management functions that may be impacted by this shift to increased use of encryption. 


New: This draft includes a collection of current security and network management (including troubleshooting) functions that may be impacted by this shift to increased use of encryption.



2.  At the end of section 1, we might want to add that private enterprises are also considered.

Suggested words:

"We will also consider the situation of the private enterprise, where IP packet transport, applications, and infrastructure are privately owned and contained within or interconnect private data centers." 

 

3.  Then, I would suggest replacing Sections 4 and 4.1 of the draft in its entirety with the words below:

********************************************

4.  Encryption for Enterprise Users

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 parts of the data stream may be necessary.  As we transition to an increased use of encryption that is increasingly harder to break, alternate methods of monitoring for operational purposes may be necessary to prevent the need to break encryption and thus privacy of users (which may not apply in a corporate setting by policy).


4.1.  Monitoring Needs of the Enterprise

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:

          1. Security Monitoring and Control
          2. Application Performance Monitoring and Reporting
          3. Network Diagnostics and Troubleshooting 

In each of the above areas, technical support teams utilize collection, monitoring, and diagnostic systems that in some organizations currently use static RSA private keys to decrypt
passively monitored copies of encrypted TLS packet streams.


To an enterprise (and the customers that it serves), the cost of network and/or application down time can be great.  The focus of enterprises in their private data centers is to deliver expected levels of service, performance, protection, and availability.


4.1.1 Security Monitoring in the Enterprise

Enterprise Security Monitoring breaks down into the following areas:

1.  Data Loss Prevention - intercept outbound session traffic to monitor for intellectual property leakage (by users or more likely these days through malware and trojans),

2.  Intrusion Detection/Intrusion Prevention - detect viruses/malware entering the network via email or web traffic,

3.  Malware Detection - detect malware/Trojans in action, possibly connecting to remote hosts, 

4.  Security Analytics - detect attacks (Cross site scripting and other common web related attacks),

5.  Track misuse and abuse by employees,

6.  Restrict the types of protocols permitted to/from the corporate environment,

7.  DDoS Prevention - 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.  These functions are critical to security and fraud monitoring.

To an enterprise (and the customers that it serves), the cost of network and/or application down time can be great.  The focus of enterprises in their private data centers is to deliver expected levels of service, performance, protection, and availability. AND this can be accomplished using some form of traffic analysis sometimes including examination of the payload.



4.1.2 Application Performance Monitoring in the Enterprise
1.  Assess traffic volume on a per-application basis, for billing, capacity planning, optimization of geographical location for servers or proxies, and other needs, 

2.  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 need. 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 implementation of Performance and Diagnostic Metrics (PDM) will provide this. [draft-ietf-ippm-6man-pdm-option-06]



4.1.3 Enterprise Network Diagnostics and Troubleshooting

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 the modern multi-tiered application have made it impossible to follow a transaction in network traces without the ability to examine some of the packet payload.


4.1.3.1 NAT

Content Delivery Networks (CDNs) and NATs obscure the ultimate endpoint designation.  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 sprayed randomly by load balancers to all these devices, the network troubleshooter is often left with no option in today's environment except to trace all packets at a particular layer, decrypt them all, and look at the payload to find a user session.


This kind of bulk packet capture and bulk decryption is frequently required 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, which depend on static RSA private  keys, have evolved to fill this need.

4.1.3.2 TCP Pipelining/Session Multiplexing

When TCP Pipelining/Session Multiplexing is used, usually by Middle boxes today, multiple end user sessions share the same TCP connection.  Today's  network troubleshooter often relies upon session decryption to tell which packet belongs to which end user.

With the advent of HTTP2, session multiplexing will be used ubiquitously, both on the Internet and in the private data center. 


4.1.3.3 HTTP Service Calls

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.  It must be possible  to match up the user request above with the HTTP service call below.  Today, this is done by decrypting the TLS packet and inspecting the payload.


4.1.3.4 Application Layer Data

Modern applications often use XML structures in the payload of the data to store application level information.  When the network and application teams must work together, each has a different view of the transaction failure. It is important to be able to correlate the network packet with the actual problem experienced by an application.
  


Thanks,

Nalini Elkins
Inside Products, Inc.
www.insidethestack.com
[phone]