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

From: <[email-masked]>
Date: Thu, 13 Oct 2016 12:28:03 +0000 (UTC)

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
(831) 659-8360

---

From: "MORTON, ALFRED C (AL)" <[email-masked]>
Date: Sun, 16 Oct 2016 10:36:12 -0400

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

-=-=-=-=-=-=-=-=-=-=-=-=-=-

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

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.

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

4.1.3.1 NAT

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.

From: [email-masked] [mailto:[email-masked]]
Sent: Thursday, October 13, 2016 8:28 AM
To: [email-masked]
Cc: MORTON, ALFRED C (AL); Kathleen Moriarty
Subject: Re: draft-mm-wg-effect-encrypt-03

Kathleen and Al,

Great work, guys!!!

Suggested words:

4.1.3.1 NAT

Thanks,

Nalini Elkins
Inside Products, Inc.
www.insidethestack.com<http://www.insidethestack.com>
(831) 659-8360

---

From: Stephen Farrell <[email-masked]>
Date: Sun, 16 Oct 2016 15:58:04 +0100

Hi Al,

I've a general question about this text but will just use the
one example below. There are other examples in the text you
just sent to the list...

On 16/10/16 15:36, MORTON, ALFRED C (AL) wrote:
> 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.

What is the goal of this text? Is it to a) describe current
or historic practice or b) describe the changes that are
needed when we properly protect things or c) argue that MITM
behaviour is somehow necessary or correct?

I think if the goal were (a) or (b) we would not use the language
above ("valuable asset"), so I'm left wondering if this text is
really aimed at (c).

My understanding is that this draft aims at a mixture of (a) and
(b), and I would have a problem with anything that seems to me
like it has goal (c).

To be clear: if asked to sponsor a document as AD I will not
start a last call for anything with chunks of text that I think
has goal (c). Goals (a) and (b) are of course useful so I'd be
happy to progress such a document. I hope you and Kathleen take
that into account when doing edits to the draft so that we can
all save ourselves some cycles and angst:-)

Thanks,
S.

PS: I realise that this is your initial edit of Nalini's text so
it could be that additional edits are all that's needed here.

---

From: "MORTON, ALFRED C (AL)" <[email-masked]>
Date: Sun, 16 Oct 2016 13:19:43 -0400

Hi Stephen, thanks for sharing an example that needs fix.

I re-worded a paragraph that repeated statements
from an earlier section. I believe Nalini was describing
current capabilities, and implying a gap if there is 
no replacement to aid network management in the future.
This is the fundamental tension, as I understand it.

> above ("valuable asset"), so I'm left wondering if this text is

I agree to substitute another phrase for "valuable asset"
since it's distracting; "current capability" or other, WFM.
I didn't write "is a required capability", that would be 
more consistent with goal c).

Clearly, changes in current management practices will be needed,
and that process could be more efficient with constructive input
from all involved. Understanding the many gaps is the first step,
and IMO, what this memo is about.  No arguing for solutions,
MITM or otherwise.

I hope this helps,
Al

> -----Original Message-----
> From: Stephen Farrell [mailto:[email-masked]]
> Sent: Sunday, October 16, 2016 10:58 AM
> To: MORTON, ALFRED C (AL); [email-masked];
> [email-masked]
> Subject: Re: [saag] draft-mm-wg-effect-encrypt-03
> 
> 
> Hi Al,
>

---

From: Stephen Farrell <[email-masked]>
Date: Sun, 16 Oct 2016 19:27:36 +0100

Hi Al,

> and IMO, what this memo is about.  No arguing for solutions,

I agree. Figuring out what solutions are needed for n/w
management given the fact of much more ciphertext is work for
another day and for other documents and WGs.

I think what makes this tricky is that people understandably
tend to mix up current solutions and requirements, e.g. it is
natural enough (but wrong) to think that because I do X today
that that implies doing X is required (and hence language like
"valuable" etc.).

We directly saw that in the recent TLS WG discussion of RSA key
transport, which was kicked off by (I think) the same set of
folks. In the end the TLS WG chairs saw a very clear consensus
to stick with PFS and to not add back RSA key transport to
TLS1.3, despite RSA key transport being a "feature" on which
it appears some enterprise networks still seem to depend for
some forms of "attacking"/deciphering traffic to/from their own
TLS servers.

I think another related thing we need to be careful about here
are claims of utility for features where there is little or no
(at least public) evidence but only assertion. For example, many
of the claims I hear about the effectiveness of scanning outbound
traffic seem dubious to me, so we'll want to try find evidence
to backup claims along those lines too if we want this document
to be of most use later on. (Or to qualify such things as being
e.g. "current practices for which there isn't such good evidence"
or something.)

Buy hey, that's why you get all those big bucks for being such
good document editors/authors I guess:-)

Cheers,
S.

---

From: <[email-masked]>
Date: Mon, 17 Oct 2016 01:48:12 +0000 (UTC)

Stephen & Al,
My comments inline. Thanks,
Nalini ElkinsInside Products, Inc.www.insidethestack.com(831) 659-8360

      From: "MORTON, ALFRED C (AL)" <[email-masked]>
 To: Stephen Farrell <[email-masked]>; "[email-masked]" <[email-masked]>; "[email-masked]" <[email-masked]> 
 Sent: Sunday, October 16, 2016 10:19 AM
 Subject: RE: [saag] draft-mm-wg-effect-encrypt-03
   
>This is the fundamental tension, as I understand it.
Definitely.    Sorry if the wording is awkward.   I was trying to not imply any solutions as that is not in the spirit of this draft.
I hope that the many issues (including a few of the ones that I suggested) in network management and diagnostics that have been pointed out by this draft will spark the conversation about how we might go about resolving them.   Maybe this is new tools, strategies or protocols.

---

From: Kathleen Moriarty <[email-masked]>
Date: Mon, 17 Oct 2016 21:50:20 -0400

Hi,

I'll start with responding to this message and then will respond to ones
with text for possible edits to the suggestions.

> that that implies doing X is required (and hence language like

Yes, agreed.  As the draft stands now, before these additions that point is
very clear.  The intent is to document the purpose of activities, what is
used now so that other methods might be identified to achieve the same
goal, possibly via an entirely different mechanism.

> some forms of "attacking"/deciphering traffic to/from their own

I agree entirely with the consensus, not to worry.  I'll comb through the
proposed text to make sure the intended approach for the draft is
maintained.

> e.g. "current practices for which there isn't such good evidence"

Yes, agreed.  For attack detection, we can confirm with MILE, but from my
experience attackers use whatever they would like to hide their tracks, so
worrying about TLS and the ability to break it doesn't really help anyway
as they'll just use something else.  I don't think that seeing into TLS
traffic is necessary for attack detection (Note: I have led incident
response and security teams that are quite advanced and consulted with
other teams that are quite advanced more recently. )  We can confirm with
MILE and DOTS as well, this should give us feedback from multiple industry
sectors.

> good document editors/authors I guess:-)

Ha.

Thanks,
Kathleen

>
> Cheers,
> S.
>
>
> _______________________________________________
> saag mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/saag
>
>

-- 

Best regards,
Kathleen

---

From: Kathleen Moriarty <[email-masked]>
Date: Mon, 17 Oct 2016 22:18:33 -0400

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:

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) <[email-masked]>
wrote:

> 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).
>
>
>
>
>
> 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:
>
>
>
> 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
>
> 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.
>
>
>
>
>
> 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,
>
>
>
> 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.
>
>
>
> expected levels of performance, protection, and availability, some form of
> traffic analysis sometimes including examination of packet payloads can be
> a valuable asset.
>
>
>
>
>
>
>
> 1.  Assess traffic volume on a per-application basis, for billing,
> capacity planning, optimization of geographical location for servers or
> proxies, and other needs.
>
>
>
> 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]
>
>
>
>
>
>
>
> 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.
>
>
>
> 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.
>
>
>
>
>
> 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.
>
>
>
>
>
> 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:* [email-masked] [mailto:nalini.elkins@
> insidethestack.com]
> *Sent:* Thursday, October 13, 2016 8:28 AM
> *To:* [email-masked]
> *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!!!
>
> 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.
>
>
>
> "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."
>
>
>
> 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).
>
>
> 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:
>
> 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
> 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.
>
>
> 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,
>
> 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.
>
>
>
> 1.  Assess traffic volume on a per-application basis, for billing,
> capacity planning, optimization of geographical location for servers or
> proxies, and other needs,
>
> 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]
>
>
>
> 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.
>
> 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.
>
>
> 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.
>
>
> 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
> (831) 659-8360
>
>

-- 

Best regards,
Kathleen