Responses inline; some text elided.
On 2/9/18 8:22 AM, Kathleen Moriarty wrote:
---------------------------------------------------------------------------
§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.)
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.
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.
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.
Right; I saw that elsewhere, and thought it was a very good addition.
Or
are you just asking for a discussion within this section in
particular? Thanks!
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.
---------------------------------------------------------------------------
§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.
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.
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.
---------------------------------------------------------------------------
§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.
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.
Looks good to me. I'll respond to Al's email separately. Thanks!
/a
_______________________________________________
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
