Hi Adam,

Thanks again for your updates.  Responses inline.

On Tue, Feb 13, 2018 at 6:26 PM, Adam Roach <a...@nostrum.com> wrote:
> 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.

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.

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

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

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

Thanks, I think you'll appreciate the other updates as well, I did.
>>> ---------------------------------------------------------------------------
>>> §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.

Done, thanks.
> 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.

Hmm, is the pointer to the work items that go into this enough?

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

>>> ---------------------------------------------------------------------------
>>> §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!

Thank you!

> /a


Best regards,

OPSAWG mailing list

Reply via email to