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

[Kathleen Moriarty <[e-mail]>]

Hello,

Nalini, thank you very much for your suggested text, this is helpful to
fill a gap in the draft and is much appreciated.  Al had provided a text
diff file from your proposed text, so I used that to edit a little further
and provide additional edit suggestions on your text.  I also inserted a
note.  I hope it's easy enough to see the changes although I am afraid it
may be a little tougher.  Here's the suggested changes:


Section 4., paragraph 2:
OLD:

 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).

NEW:

 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 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 (other policies may
apply in some enterprise settings).

Section 4.1, paragraph 2:
OLD:
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.

NEW:
In each of the above areas, technical support teams utilize collection,
monitoring, and diagnostic systems.  Some organizations currently use
attack methods such as static RSA private keys to decrypt
passively monitored copies of encrypted TLS packet streams.

Section 7., paragraph 2:
OLD:

 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.

NEW:

 For an enterprise to avoid costly application down time and deliver
expected levels of performance, protection, and availability, some form of
traffic analysis sometimes including examination of packet payloads can be
a valuable asset.

Section 4.1.1, 4.1.2
Note: I'm not thrilled with the proposed headings for each bullet as I
don't think they are really needed, but will go with consensus if others
really think it's helpful.  Some have a subheading now and others don't.
The headings are technology specific, whereas the previous bullets were
just covering the functions without naming technologies.

I'm fine with the additional bullets, but would like the technologies
removed.


Section 4.1.2, paragraph 1:
OLD:

 1.  Assess traffic volume on a per-application basis, for billing,
capacity planning, optimization of geographical location for servers or
proxies, and other needs,

NEW:

 There are two main goals of monitoring:


Section 4.1.2, paragraph 2:
OLD:

 2.  Assess performance in terms of application response time and user
perceived response time,

NEW:

 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


Section 4.1.3.1, paragraph 2:
OLD:

 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.

NEW:

 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 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.


Section 4.1.3.1, paragraph 3:
OLD:

 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.

NEW:

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
utilize static RSA private keys to accomplish this task today.

Thank you,
Kathleen

On Sun, Oct 16, 2016 at 10:36 AM, MORTON, ALFRED C (AL) <[e-mail]>
wrote:

> Hi Nalini,
>
>
>
> Thanks for your many suggestions.
>
>
>
> As a first step, I edited your suggested
>
> text for sections 4 and 4.1, below and
>
> attached. See what you think.
>
>
>
> Al
>
>
>
> -=-=-=-=-=-=-=-=-=-=-=-=-=-
>
>
>
> 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 access to 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 (other policies may apply in
> some enterprise settings).
>
>
>
>
>
> 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.
>
>
>
> For an enterprise to avoid costly application down time and deliver
> expected levels of performance, protection, and availability, some form of
> traffic analysis sometimes including examination of packet payloads can be
> a valuable asset.
>
>
>
>
>
>
>
> 4.1.2 Application Performance Monitoring in the Enterprise
>
>
>
> There are two main goals of monitoring:
>
>
>
> 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 allocated 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 that 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.
>
>
>
> *From:* [e-mail] [mailto:nalini.elkins@
> insidethestack.com]
> *Sent:* Thursday, October 13, 2016 8:28 AM
> *To:* [e-mail]
> *Cc:* MORTON, ALFRED C (AL); Kathleen Moriarty
> *Subject:* Re: draft-mm-wg-effect-encrypt-03
>
>
>
> 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]
>
>


-- 

Best regards,
Kathleen