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

[Alissa Cooper <[e-mail]>]

Hi Kathleen,

> On Feb 22, 2018, at 4:07 PM, Kathleen Moriarty <[e-mail]> wrote:
> 
> 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.

Thanks!

> 
> On Thu, Feb 8, 2018 at 8:26 AM, Alissa Cooper <[e-mail]> wrote:
>> 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.
> 
> I believe we had responded to the discussion and left off with the
> updates matching the last parts of the discussion.
> 
>> 
>> 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.
> 
> This is in section 2.1.2, which is specific to service provider
> 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
> 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.

These edits look good to me.

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

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

Much improved, thanks.

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

Looks good, thanks.

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

Much improved, thanks.

Nit fixes look fine to me.

Thanks,
Alissa

> 
>> 
>> 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.
>> 
> 
> 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.
> 
>> 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/
> 
> Thanks, thank has been fixed already.
>> 
>> = 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.
> 
> Transaction monitoring, so the text has been altered to make this
> explicit.  Thanks.
> 
>> 
>> (2)
>> Is "User/Service Key Quality Indicators" a term of art? It seems weird to be
>> capitalized.
> 
> I put it in lower case, but am guessing it is normally KQIs and should
> be lower case when spelled out.
> 
>> 
>> = Section 2.2.3 =
>> 
>> 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.
> 
>> 
>> = 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.
> 
> 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.
> 
>> 
>> = 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./
> 
> Done.
> 
>> 
>> = Section 4.1.2 =
>> 
>> 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.
> 
>> 
>> = Section 7.4 =
>> 
>> 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
> 
>> 
>> ----------------------------------------------------------------
>> 
>> 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.
>> 
>> 
> 
> 
> 
> -- 
> 
> Best regards,
> Kathleen