Subject: [OPSAWG] Alissa Cooper's Abstain on draft-mm-wg-effect-encrypt-17: (with COMMENT)

From: Alissa Cooper <[email-masked]>
Date: Thu, 08 Feb 2018 05:26:43 -0800

Alissa Cooper has entered the following ballot position for
draft-mm-wg-effect-encrypt-17: Abstain

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-mm-wg-effect-encrypt/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Many thanks for all the effort that has gone in to addressing all the comments
from the last IESG review and from the community. I find this version to be
much improved from the last time the IESG reviewed it.

However, I do not feel that I can support the publication of the document.
While the tone has improved in many places and the introduction does a better
job of contextualizing the document, the document still contains text in
several sections that states service providers' claims about their practices as
facts rather than stating them as claims or presenting the practices in a
neutral way. This was a point raised in my previous DISCUSS (I've included my
previous DISCUSS ballot text below in full for reference). In the previous
review round Warren had invited recommendations for places where the tone or
choice of words could be made more neutral or balanced, and I provided many
detailed suggestions, but a number of those were not adopted. I also realize
that the introduction contains much of the disclaimer text we previously hashed
out to try to address this, but it doesn't contain all of it. So this is still
a major issue for the document, IMO.

The document also still extemporizes about future possible impacts, making it
hard to come away with a neutral view of their treatment, as I noted in my
previous DISCUSS ballot.

I support the DISCUSS position held by Ekr. But given the above I don't think
it will be fruitful for me to continue to engage on the details of this
document, so I'm abstaining.

I've included below some of the areas that I still find problematic, as well as
some nits.

Problematic areas:

= Section 2.1.2 =

(1)
"Network operators are often the first ones called upon to investigate
   application problems"

I still contend that without data to back this up, this claim should not be
made, especially for the enterprise context.

(2)
"Vendors must be aware that in order for operators to better
   troubleshoot and manage networks with increasing amounts of encrypted
   traffic, built-in diagnostics and serviceability must be enhanced to
   provide detailed logging and debugging capabilities that, when
   possible, can reveal cleartext network parameters."

If I try to paraphrase this it sounds like "vendors should build in
capabilities to decrypt encrypted traffic." Was that the intent?

= Section 2.2.4 =

I agree with Christian Huitema's unresolved comments on this section. In the
thread regarding his comments Kathleen said "we don't want to make general
statements that aren't necessarily true" -- IMO that is what the middle three
paragraphs in this section are doing. At a minimum, I think the
characterizations about the effects of performance-enhancing proxies needs to
be qualified by saying "some operators find that ..." rather than stating their
effects as fact.

= Section 2.2.7 =

"There is work in progress to specify protocols that permit Service
   Function Chaining (SFC)."

I don't think it makes sense to have this forward-looking statement when
Section 1 states that "This document describes practices currently used by
network operators to manage, operate, and secure their networks." I think it
makes sense to focus this section on how existing SFC deployments have stopped
functioning because of increased use of encrypted traffic, but it seems unfair
to claim that some future, yet-to-deployed functionality will be broken.

= Section 2.3.2 =

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

This could easily be read to imply that sending requests in cleartext is
optimal.

Overall, the use of the words "usual," "optimal," and "often" in this section
imply a level of generality that is unwarranted I think.

= Section 5.6 =

The implications for SAVI seem speculative unless you can point to SAVI
deployments that have been impacted by increased use of encryption.

Nits:

= Abstract =

s/Pervasive Monitoring (PM) attacks on the privacy of Internet users is
   of serious concern/Pervasive Monitoring (PM) attacks on the privacy of
   Internet users are of serious concern/

= Section 2.1.2 =

(1)
"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 ..."

It's not clear what "such monitoring" refers to, since the previous sentence is
about performance management and service repair.

(2)
Is "User/Service Key Quality Indicators" a term of art? It seems weird to be
capitalized.

= Section 2.2.3 =

This section seems like it was left in the document by mistake.

= Section 2.3 =

"As previously stated, the intent of this document is to
   document existing practices, the development of IETF protocols
   follows the guiding principles of [RFC1984] and [RFC2804]."

Is that comma supposed to be a period? I'm not following the grammar here.

= Section 2.3.1 =

s/However, the lack of ability to efficiently manage
   endpoints as a service reduces providers' ability to offer parental
   control./However, the lack of ability to efficiently manage
   endpoints as a service reduces network service providers' ability to offer
   parental control./

= Section 4.1.2 =

It seems like a single reference to RFC 8250 would suffice.

= Section 7.4 =

What is a trusted transit proxy?

----------------------------------------------------------------

Previous DISCUSS ballot text:

I have cleared my original DISCUSS point from my earlier review -- I get what
the text is saying now, although I still think the "lose the option" language
implies some entitlement to the option in the first place, which seems
inappropriate.

But given the reviews from Martin Thomson and Christian Huitema, it's not clear
to me that this document represents the consensus view of the IETF community.
Kathleen's response to Martin reinforces the point that we were discussing in
the first ballot cycle, which is that this document is written for and
represents operators, not the broader array of Internet interests. Yet the
suggestion to state that fact up front in the document was not adopted.

Having had some more time to review this document than I had in the previous
ballot cycle, I also am finding myself in agreement with significant portions
of the reviews from Martin and Christian. Reading their reviews helped
crystallize a lot of the difficulty I had in parsing this document the first
time around.

I understand the rationale that led to this document being written and I think
there is a version of this document that could be written that would achieve
the original goals while giving the subject matter a readable, neutral
treatment. Such a version would be a useful contribution. But I don't think
this document achieves that. In particular, there are four things that I think
it would need to do to achieve that:

1. State the analysis in a neutral way. As I had mentioned in one of the email
threads for the previous ballot cycle, I believe this document could be written
in a neutral way -- e.g., “Service providers currently do X. It is implemented
using Y mechanism. Encryption at Z layer breaks current implementations.” --
but it is not. Instead it characterizes many of the practices described as
"optimizations" or "features" or "enrichment" and states service providers'
claims about what these practices accomplish (e.g., "maximize QOE") as facts
rather than stating them as the reasons given by service providers for why they
engage in the practices. This is why in the previous round I suggested the
disclaimer at the top of the document to say that the document is giving a view
from service providers; that apparently didn't go anywhere, so the other option
is to describe each technique neutrally, or explain with each technique that
the characterization of the benefits is from the view of the operator. Martin's
comments about being clear about who is benefitting point this out as well.

2. Limit the discussion to techniques presently being affected and those
effects. There is a bunch of extemporizing about future possible impacts (e.g.,
in Sec. 2.7, 4.1.2, 4.1.3.1, 5.7, 7, 8). It's very hard to characterize future
implications, who will bear the "cost" for what, whether increases in user
complaints to various parties are "worth it," etc., in a way that is perceived
as neutral by all affected parties. Better not to make predictions if the goal
is to give a neutral treatment of network functions being impacted today.

3. Acknowledge the controversy. Many of the practices described in this
document are controversial, and have been for a long time. There is nothing
wrong with that. I agree with Christian that it would be better to state an
understanding of that head-on rather than leave it to the reader to decide
whether any particular characterization of something described implies an
endorsement of it. This has been done before, even in potentially controversial
documents that this document references, e.g. RFC 3135.

4. Structure the document in a way that is consistent and logical with minimal
repetition. It seems like there are multiple ways that this could be done.
Organizing based on use case (per Christian) and then discussing techniques
used within each use case is one way; organizing based on technique while
mentioning the goals for which each technique is employed is another. At
present the document is jumble of these.

---

From: Kathleen Moriarty <[email-masked]>
Date: Thu, 22 Feb 2018 16:07:37 -0500

Hi Alissa,

I believe this is the last set of comments received that we had left
to respond.  The next update that will come out shortly following this
message should address all comments and subsequent discussions
received to date.

> https://datatracker.ietf.org/doc/draft-mm-wg-effect-encrypt/

I believe we had responded to the discussion and left off with the
updates matching the last parts of the discussion.

> made, especially for the enterprise context.

This is in section 2.1.2, which is specific to service provider
networks.  Al responded on this previously from his experience.  My
experience having worked at a service provider and having managed/been
responsible for the security of several large enterprises matches his
- the service provider is often the first call, especially with the
cited example.  If there's a perceived issue that's network related,
you have an SLA with the service provider and they have to assist.
They will figure out if there is a routing issue, congestion, the
service is not responding, DDoS, or something else that is happening
to cause the trouble.  These are all issues that require a little
network troubleshooting before you point the problem at the
application.  It's not as easy with an application as you don't always
have someone you can call.  The service provider may be seeing the
application issue from multiple customers and may then act on behalf
of many customers to get in touch with the application provider.
Getting to the right person at an application provider is typically
much harder then the initial troubleshooting steps to discover if
there is a network issue.  I'd be embarrassed if I called an
application provider and the issue was the network.  I'd want to rule
out the network and services like DNS prior to making that call.

I know this is one Al wanted to hold firm on and I agree with him from
my experience.

How about the following to make the point more clear for those not
familiar with troubleshooting:

OLD:
Network operators are often the first ones called upon to investigate
application problems (e.g., "my HD video is choppy").

NEW:
Network operators are often the first ones called upon to investigate
application problems (e.g., "my HD video is choppy"), to first rule
out network and network services as a cause for the underlying issue.

I think the real issue though is the text in the rest of the paragraph
(as opposed to the above statement) as it is mixing up practices of
enterprises and that of SPs.  So here is that cleaned up a bit,
removing the packet captures (which might be used if a customer
provides them, but this is stated in the adjusted version of the
previous paragraph.

OLD:
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 packet capture is often
used for this purpose; IP address filtering is not useful for
applications using content delivery networks (CDNs) or cloud
providers. After identifying the traffic, an operator may analyze the
traffic characteristics and routing of the traffic.

NEW:
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 packet capture provided
from the customer close to the edge may be used for this purpose; IP
address filtering is not useful for applications using content
delivery networks (CDNs) or cloud providers. After identifying the
traffic, an operator may analyze the traffic characteristics and
routing of the traffic.  This diagnostic step is important to help
determine the root cause before exploring if the issue is directly
with the application.

> capabilities to decrypt encrypted traffic." Was that the intent?

This text has been modified as a result of the OPS-Dir review and is
much more helpful, IMO.  It's in a few of the recent versions.

NEW:
A gap exists for vendors where built-in diagnostics and serviceability
is not adequate to provide detailed logging and debugging capabilities
that, when possible, can access cleartext network parameters. In
addition to traditional logging and debugging methods, packet tracing
and inspection along the service path provides operators the
visibility to continue to diagnose problems reported both internally
and by their customers. Logging of service path upon exit for routing
overlay protocols will assist with policy management and
troubleshooting capabilities for traffic flows on encrypted networks.
Protocol trace logging and protocol data unit (PDU) logging should
also be considered to improve visibility to monitor and troubleshoot
application level traffic. Additional work on this gap would assist
network operators to better troubleshoot and manage networks with
increasing amounts of encrypted traffic.

> be qualified by saying "some operators find that ..." rather than stating their

The following edits have been made to address this comment:

Operators report that 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). However, such optimizations can also cause problems with
performance, for example if the characteristics of some packet streams
begin to vary significantly from those considered in the proxy design.

In general some operators have stated that 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 changes in the mobile network
conditions and enables faster adaptation in a delay and capacity
varying network due to user mobility.

Further, some use service-provider-operated proxies to reduce the
control delay between the sender and a receiver on a mobile network
where resources are limited. The RTT determines how quickly a 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. If impacted by encryption, performance
enhancing proxies could make use of routing overlay protocols to
accomplish the same task, but this results in additional overhead.

> to claim that some future, yet-to-deployed functionality will be broken.

The work is continuing, so it was poor phrasing that has been
corrected.  This came in from the Gen-ART reviewer, whose in the
routing area.  I checked with Alia on the new text as she confirmed
the only new part of SFC is NSH.  SFC has been around for a while as I
have a colleague who worked on it years ago at Cisco.  This seems
pretty straightforward for the adjustments given the drafts that have
recently been approved, even for NSH.

Service Function Chaining (SFC) has been defined in RFC7665 and &
RFC8300.  As discussed in RFC 7498, common SFC deployments may use
classifiers to direct traffic into VLANs instead of using NSH, as
defined in RFC 8300.   As described in RFC7665, the ordered steering
steering of traffic to support specific optimizations depends upon the
ability of a Classifier to determine the microflows.  RFC2474 defines
"Microflow: a single instance of an application-to-application flow of
packets which is identified by source address, destination address,
protocol id, and source port, destination port (where applicable). "
SFC currently depends upon a classifier to at least identify the
microflow.  As the classifier's visibility is reduced from a 5-tuple
to a 2-tuple, or if information above the transport layer becomes
unaccessible, then the SFC Classifier is not able to perform its job
and the service functions of the path may be adversely affected.

There are also mechanisms provided to protect security and privacy. In
the SFC case, the layer below a network service header can be
protected with session encryption. A goal is protecting end-user data,
while retaining the intended functions of RFC7665 at the same time.

> This could easily be read to imply that sending requests in cleartext is

I read it differently, the customer experience is less optimal as they
don't have a way to provide notification via another means yet for non
SMS customers.

I tweaked a word in that sentence to see if it helps direct where the
'less optimal" is intended and am including text that is from recent
versions after discussion with Adam that you may find helpful.

As a result, some mobile carriers block customer's encrypted requests,
which impacts 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 and/or resolve the issue, possibly
extending the time needed to restore their network access. While there
are well deployed alternate SMS-based solutions that do not involve
out of specification protocol interception, this is still an unsolved
problem for non-SMS users.

Often was removed from the last paragraph as well.

> deployments that have been impacted by increased use of encryption.

Al may have been pulled int he original content here, so on my last
round of editing, I reached out  to Joel and SAVI is deployed in China
and the text is based on how the protocol works, hence the clear
impact to those using it.

>    Internet users are of serious concern/

Thanks, thank has been fixed already.
> about performance management and service repair.

Transaction monitoring, so the text has been altered to make this
explicit.  Thanks.

> Is "User/Service Key Quality Indicators" a term of art? It seems weird to be

I put it in lower case, but am guessing it is normally KQIs and should
be lower case when spelled out.

> This section seems like it was left in the document by mistake.

The text has been updated with a reference where the impact is noted.

> Is that comma supposed to be a period? I'm not following the grammar here.

This has been altered in an existing version to the following text:

As previously stated, the intent of this document is to document
existing practices; the development of IETF protocols follows the
guiding principles of RFC1984 and RFC2804 and explicitly do not
support tools and methods that could be used for wiretapping and
censorship.

>    endpoints as a service reduces network service providers' ability to offer

Done.

> It seems like a single reference to RFC 8250 would suffice.

The second use points to a specific section within the document, so
I'd prefer to leave that.  Since this is editorial, we can worry about
this later and address it witht he RFC editor.  This happens in a few
other places too.  We'll do something consistent.

> What is a trusted transit proxy?

In transit as opposed to edge.  We adjusted the text in a prior
version, which should help:

NEW(ish):
Transport header encryption prevents the use of transit proxies in
center of the network and the use of some edge proxies by preventing
the proxies from taking action on the stream.

Thanks for your comments to improve the document.
Kathleen

-- 

Best regards,
Kathleen

---

From: Alissa Cooper <[email-masked]>
Date: Wed, 28 Feb 2018 11:36:21 -0500

Hi Kathleen,

> On Feb 22, 2018, at 4:07 PM, Kathleen Moriarty <[email-masked]> wrote:
> 
> Hi Alissa,
> 

Thanks!

> networks.  Al responded on this previously from his experience.  

This was also my experience at BT. I don’t think it matches the experience of the folks who provide WebEx customer service, for example. But I acknowledge that is an enterprise example.

I realize that my last ballot text wasn’t clear on this, but my claim wasn’t that this is untrue, but rather that if you actually want the text to sound neutral rather than reflective of the biases of the authors, then both experiences would need to be reflected, not just one.

> My

These edits look good to me.

> that, when possible, can access cleartext network parameters.

I can’t follow the grammar of the above sentence to discern what it means, but I agree that it no longer has the problem I pointed out in my ballot.

> In

Much improved, thanks.

> while retaining the intended functions of RFC7665 at the same time.

Looks good, thanks.

> Often was removed from the last paragraph as well.

Much improved, thanks.

Nit fixes look fine to me.

Thanks,
Alissa