Subject: [OPSAWG] Adam Roach's No Objection on draft-mm-wg-effect-encrypt-17: (with COMMENT)

From: Adam Roach <[email-masked]>
Date: Mon, 05 Feb 2018 17:00:10 -0800

Adam Roach has entered the following ballot position for
draft-mm-wg-effect-encrypt-17: No Objection

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

Thanks for all the work that has gone into this document. The framing and tone
is much improved over -10, and the reorganization of section 7 into the rest
of the document helps a lot. I do have a handful of comments. In particular,
I think the omission in section 2.3.4 is very important; however, I
wanted to clear my discuss and trust the sponsoring AD to do the right thing
here rather than re-issuing a different discuss position.

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

§2.1.2 -- I am surprised that there is so much discussion of fields that are
not generally encrypted in practice (e.g., RTP headers, TCP headers). It may
be worth distinguishing between session-layer, transport-layer and
network-layer security.

(I think I mentioned this in my initial review, and saw neither a response nor a
document change in reaction to it.)

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

§2.2.3 -- This section reads like a set of unfinished "notes to self" for the
authors' later use. Minimally, I would suggest restructuring the sentence
fragments in this section into sentences. I will also note that section 2
indicates that the following sections will discuss both (a) purpose of the
technique, and (b) fields used to achieve this purpose. This section appears
to lack the latter.

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

§2.2.5:

>   For example, network caching of popular content at a
>   location close to the requesting user can improve delivery efficiency
>   (both in terms of lower request response times and reduced use of
>   International Internet links when content is remotely located), and
>   authorized parties acting on their behalf use DPI in combination with
>   content distribution networks to determine if they can intervene
>   effectively.  Caching was first supported in [RFC1945] and continued
>   in the recent update of "Hypertext Transfer Protocol (HTTP/1.1):
>   Caching" in [RFC7234].

The transition from the general case of caching to the specific case of HTTP
proxy caching (and the subsequent change back to the general case) seems
rather abrupt. Consider splitting the HTTP proxy caching out into a separate
paragraph.

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

§2.2.5:

>   The Enhanced Multimedia Broadcast/
>   Multicast Services (3GPP eMBMS) - trusted edge proxies facilitate
>   delivering same stream to different users, using either unicast or
>   multicast depending on channel conditions to the user.

This passage also reads like outline notes rather than a finished document.

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

§2.2.5:

>   preserving end-to-end security: AMT, for instance, allows CDNs to

Please expand "AMT".

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

§2.2.7:

>    A goal is protecting end-user
>    data -- but at the same time not making the network inoperable or
>    unmanageable.

I fear this sentence falls back to the hyperbolic tone that plagued version
-10 of this document. I suggest something more along the lines of "...not
forcing changes to the way networks have historically been operated and
managed" or something similar.

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

§2.3.2:

>   The customer may need
>   call customer care to find out the reason, both an inconvenience
>   to the customer and additional overhead to the mobile network service
>   provider.

I believe this is false. Please remove this assertion or support it with a
citation.

To my knowledge, standard operating procedure for mobile networks (based on my
personal experience on two different post-paid US carriers and probably half a
dozen pre-paid non-US carriers) is that users are sent an SMS message
explaining the situation. I think the statement above overstates the
inconvenience to both users and operators, and consequently runs the risk of
causing protocol designers to evaluate the impact incorrectly.

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

§2.3.4:

>   Third parties use
>   the inserted information for analytics, customization, advertising,
>   to bill the customer, or to selectively allow or block content.

This is much improved over the previous formulation, but it leaves out a simple
factual statement that is highly relevant when designers are evaluating the
impact of encryption on this behavior. In fact, I would argue that it leaves
out the *most* notable use of these headers: cross-site user tracking. I
suggest amending the list to something like:

    Third parties use the inserted information for analytics, customization,
    advertising, cross-site tracking of users, to bill the customer, or to
    selectively allow or block content.

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

§3.3:

>   encryption approach described below.  In most cases, solution have
>   been identified to provide encryption while ensuring management

Nit: "...solutions have..."

---------------------------------------------------------------------------
§3.2.2 and §5.1:

Nit: s/SPAM/spam/g

---

From: Kathleen Moriarty <[email-masked]>
Date: Fri, 9 Feb 2018 09:22:07 -0500

Hi Adam,

Thanks for the additional comments.  We'll discuss in line and make
updates as appropriate.

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

Thank you and we'll do our best to address comments.

As a result of your comments and other similar ones, the introduction
text was updated to explain that this document is not limited to TLS
and that other end to end encryption protocols are considered in this
draft.  The IPsec OS implementations (NULL authentication) resulting
from RFC7258 decisions is one example of an increase in encryption
deployment and in this case limiting visibility to a 2-tuple.
Breaking down what is used in current operations is a way to
understand that impact, hence discussions on visibility used from
5-tuples is discussed in the draft.  This section talks about the
actual headers used in monitoring, which is at a more detailed level
than stating session, transport, or network layer.  So we assumed
making this additions satisfied your comment at a more detailed level.
Would you like to see the layer in addition to the header accessed or
an explanation in one section on what is in each layer?  I'd just like
to understand what you are looking for in this comment to make the
document read more clearly.

In the last revision, we tried to add in (where it made sense) if a
2-tuple or 5-tuple was enough throughout the document, so that's
pretty much the same thing, but I thought was a bit more precise.  Or
are you just asking for a discussion within this section in
particular?  Thanks!

We'll fix the sentences, the section looks bad and I'm sorry we
somehow didn't catch that. We've been hesitant to make additional
changes over what's been requested by reviewers/ADs as it seems to
invite more comments, so that may be part of why it wasn't fixed
previously.

How about the following:
"For User Plane Congestion Management (3GPP UPCON) the ability to
understand content and manage networks during periods of congestion is
th efocus of this work item. Mitigating techniques such as deferred
download, off-peak acceleration, and outbound roamers are a few
examples of the areas explored in the associated 3GPP documents
describing the issues, data utilized in managing congestion, and
policy recommendations."

Unfortunately, the document relied on contributions and if they didn't
come in, we weren't able to make assumptions of what was used as
editors.

That makes sense, thanks.  Suggestion implemented.

How about the following:
The Enhanced Multimedia Broadcast/Multicast Services (3GPP eMBMS)
utilizes trusted edge proxies to facilitate delivering the same stream
to different users, using either unicast or multicast depending on
channel conditions to the user.

Thanks for catching that!

Done, thanks!

I'd like Al to weigh in one this change from an operator perspective.
To me, this reads like both sides are being weighed equally.  He may
have another suggestion that works to help with the tone you are
looking for, but also acks the impact to operators to further the
discussion.

I'll wait for Al to weigh in since he works at a major provider,
especially since this just says "may".  I wouldn't want to weigh in
with my anecdotal experience as an end user.  I have had to call my
provider at times and it is an inconvenience to say the least!

Thanks, that's a fair addition.  Done!
Thanks, updated!

Done, thanks.

Thanks for helping to improve the document.

-- 

Best regards,
Kathleen

---

From: "MORTON, ALFRED C (AL)" <[email-masked]>
Date: Fri, 9 Feb 2018 17:21:42 +0000

Adam, please see two further suggestions, in-line:

> -----Original Message-----
> From: Kathleen Moriarty [mailto:[email-masked]]
> Sent: Friday, February 09, 2018 9:22 AM
> To: Adam Roach
> Cc: The IESG; [email-masked]; Warren Kumari; Paul Hoffman; draft-mm-wg-
> [email-masked]
> Subject: Re: Adam Roach's No Objection on draft-mm-wg-effect-encrypt-17:
> (with COMMENT)
> 
> Hi Adam,
> 
... <snip> ... to add a suggestions where needed ...
> -----
[ACM] 
Since this is the section on SFC, and describing the failure of the 
classifier function [RFC7665], we are talking about the present-day
designs and possible loss of functionality.

I suggest (last phrase, with the entire paragraph included for context):

   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.

> -----
> > explaining the situation. 
[ACM] 
If you are notified by SMS, what happens next?
Does the SMS suggest that you call customer care to resolve the issue
(which might be less efficient than accessing your account on the web,
and authorizing additional Data Usage) ?

> > I think the statement above overstates the
[ACM] Perhaps some re-wording to remove "inconvenience" ?
Suggest:
   ... 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.

> -----
<snip>
> Thanks for helping to improve the document.

[ACM] +1

Al

---

From: Adam Roach <[email-masked]>
Date: Fri, 9 Feb 2018 13:34:17 -0700

> On Feb 9, 2018, at 10:21, MORTON, ALFRED C (AL) <[email-masked]> wrote:
> 

No, you access your account on the web.

/a

---

From: Kathleen Moriarty <[email-masked]>
Date: Fri, 9 Feb 2018 15:46:56 -0500

I just posted a new version based on the discussion prior to this and will update according to any follow ups from this or other edits.  The update only includes the comments responded to so far, more to come.

Thank you,
Kathleen 

Sent from my mobile device

> On Feb 9, 2018, at 3:34 PM, Adam Roach <[email-masked]> wrote:
> 
> 
>

---

From: "MORTON, ALFRED C (AL)" <[email-masked]>
Date: Fri, 9 Feb 2018 22:31:14 +0000

> From: Adam Roach [mailto:[email-masked]]
> Sent: Friday, February 09, 2018 3:34 PM
> To: MORTON, ALFRED C (AL)
> Cc: Kathleen Moriarty; The IESG; [email-masked]; Warren Kumari; Paul
> Hoffman; [email-masked]
[ACM] 

Good, that's a nice SMS-based work-around for HTTP Re-direct.
There are customers with no-SMS service, like laptops
with embedded or USB cellular modems. Got a good idea for them?

---

From: Kathleen Moriarty <[email-masked]>
Date: Fri, 9 Feb 2018 21:38:09 -0500

> with embedded or USB cellular modems. Got a good idea for them?

Other updates are in the pending version, this will follow after the
discussion comes to a conclusion.  Thanks.

-- 

Best regards,
Kathleen

---

From: Adam Roach <[email-masked]>
Date: Tue, 13 Feb 2018 17:26:47 -0600

Responses inline; some text elided.

> document read more clearly.

I think something very simple in §2.1.2 that explains that these 
problems arise when IPsec is used, but not when SRTP or TLS are.

> pretty much the same thing, but I thought was a bit more precise.

Right; I saw that elsewhere, and thought it was a very good addition.

> Or

I think the relevant paragraph is this one:

    When increased encryption is used, operators lose a source of data
    that may be used to debug user issues.  Because of this, application
    server operators using increased encryption might be called upon more
    frequently to assist with debugging and troubleshooting, and thus may
    want to consider what tools can be put in the hands of their clients
    or network operators.

Perhaps something like:

    When increased encryption is used, operators may lose a source of 
data that
    can be used to debug user issues, if the encrypted data has diagnostic
    value. For example, IPsec obscures TCP and RTP header information, while
    TLS and SRTP do not.  Because of this, application server operators 
using
    certain types of encryption might be called upon more frequently to 
assist with
    debugging and troubleshooting, and thus may want to consider what 
tools can
    be put in the hands of their clients or network operators.

I'm sure you can wordsmith that into something more elegant, but that's 
the general thrust of my comment. In particular, I don't want readers to 
naïvely take away that increased encryption necessarily prevents all of 
the techniques described in this section. SRTP in particular was 
specifically engineered so that the headers were available in cleartext 
for operational purposes (e.g., header compression), and I think it's a 
bit of a disservice to that design in this context not to acknowledge 
that such operational considerations were made.

> come in, we weren't able to make assumptions of what was used as

s/th efocus/the focus/ -- it otherwise reads fine.

However, without indicating the fields used to perform this task, this 
section is unactionable. What we know is that encrypting *something* 
causes issues, but we're left guessing what that thing is -- and even 
more in the dark about what might possibly replace it. In this case, I 
think input needs to be solicited from someone knowledgeable in these 
techniques so that the section can be completed. If we can't find that, 
then I propose removing the section: being unactionable, it adds nothing 
to the document but length.

> channel conditions to the user.

Looks good to me. I'll respond to Al's email separately. Thanks!

/a

---

From: Adam Roach <[email-masked]>
Date: Tue, 13 Feb 2018 17:32:25 -0600

Al --

Response inline, some text elided.

>     data, while retaining the intended functions of [RFC7665] at

Perfect. Thanks.

/a

---

From: Adam Roach <[email-masked]>
Date: Tue, 13 Feb 2018 17:35:13 -0600

> with embedded or USB cellular modems. Got a good idea for them?

Ah, that's a use case I hadn't considered. I suppose, since we aren't 
dealing with solutions in this document, explaining that a well-deployed 
and superior solution exists for the majority of mobile data users is a 
bit out of scope. I withdraw my objection to the statement, but would 
find a mention that problem this arises exclusively (or at least 
primarily) for non-SMS customers to be a significant improvement.

/a

---

From: Kathleen Moriarty <[email-masked]>
Date: Wed, 14 Feb 2018 09:46:07 -0500

On Tue, Feb 13, 2018 at 6:35 PM, Adam Roach <[email-masked]> wrote:
>>>> On Feb 9, 2018, at 10:21, MORTON, ALFRED C (AL) <[email-masked]>
>>>
>>> wrote:
>>>>
> dealing with solutions in this document, explaining that a well-deployed and
> superior solution exists for the majority of mobile data users is a bit out
> of scope. I withdraw my objection to the statement, but would find a mention
> that problem this arises exclusively (or at least primarily) for non-SMS
> customers to be a significant improvement.

Thanks, Adam.  To try to stay neutral in tone and present the facts,
how about the following additional text:

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.

If you have tweaks, please propose them.  I'll put this in the running
version and change if needed.

Thanks,
Kathleen

-- 

Best regards,
Kathleen

---

From: Kathleen Moriarty <[email-masked]>
Date: Wed, 14 Feb 2018 10:29:38 -0500

Hi Adam,

Thanks again for your updates.  Responses inline.

On Tue, Feb 13, 2018 at 6:26 PM, Adam Roach <[email-masked]> wrote:
> I think something very simple in §2.1.2 that explains that these problems
> arise when IPsec is used, but not when SRTP or TLS are.

OK and the following was also added per Chris Morrow & Randy Bush
pointing out SPs rarely use packet captures.  I think this text came
in adding packet captures as an edit from enterprise operators and for
some reason, Al and I didn't catch that as an issue.  The current
first paragraph may already address your concern:

Network operators use protocol-dissecting analyzers when responding to
customer problems, to identify the presence of attack traffic, and to
identify root causes of the problem such as misconfiguration. In
limited cases, packet captures may also be used when a customer
approves of access to their packets or provides packet captures close
to the endpoint. The protocol dissection is generally limited to
supporting protocols (e.g., DNS, DHCP), network and transport (e.g.,
IP, TCP), and some higher layer protocols (e.g., RTP, RTCP).
Troubleshooting will move closer to the endpoint with increased
encryption and adjustments in practices to effectively troubleshoot
using a 5-tuple may require education. Packet loss investigations rely
on network and transport layer headers taken at the endpoint. In this
case, captures on intermediate nodes are not reliable as there are far
too many cases of aggregate interfaces and alternate paths in service
provider networks.

We can add the following into the above sentence:
Packet loss investigations, and those where access is limited to a
2-tuple (IPsec tunnel mode), rely on network and transport layer
headers taken at the endpoints.

> Right; I saw that elsewhere, and thought it was a very good addition.

Good, you'll notice a few more places this was added to clarify
further in the current revision.

>    When increased encryption is used, operators may lose a source of data
> that
>    TLS and SRTP do not.  Because of this, application server operators using
>    debugging and troubleshooting, and thus may want to consider what tools
> can
> I'm sure you can wordsmith that into something more elegant, but that's the
> general thrust of my comment. In particular, I don't want readers to naïvely
> take away that increased encryption necessarily prevents all of the
> techniques described in this section. SRTP in particular was specifically
> engineered so that the headers were available in cleartext for operational
> purposes (e.g., header compression), and I think it's a bit of a disservice
> to that design in this context not to acknowledge that such operational
> considerations were made.

Thanks, I think you'll appreciate the other updates as well, I did.

Done, thanks.
> section is unactionable. What we know is that encrypting *something* causes
> issues, but we're left guessing what that thing is -- and even more in the
> dark about what might possibly replace it. In this case, I think input needs
> to be solicited from someone knowledgeable in these techniques so that the
> section can be completed. If we can't find that, then I propose removing the
> section: being unactionable, it adds nothing to the document but length.

Hmm, is the pointer to the work items that go into this enough?
http://www.3gpp.org/DynaReport/FeatureOrStudyItemFile-570029.htm

I just added that and had been using the link, but the reference wasn't there.

> Looks good to me. I'll respond to Al's email separately. Thanks!

Thank you!

-- 

Best regards,
Kathleen