[lmap] Fwd: Kathleen Moriarty's Discuss on draft-ietf-lmap-use-cases-05: (with DISCUSS)

[Benoit Claise <[e-mail]>]

FYI.

Regards, Benoit


-------- Original Message --------
Subject: 	Kathleen Moriarty's Discuss on draft-ietf-lmap-use-cases-05: 
(with DISCUSS)
Date: 	Wed, 3 Dec 2014 07:09:33 -0800
From: 	Kathleen Moriarty <[e-mail]>
To: 	The IESG <[e-mail]>
CC: 	<[e-mail]>, 
<[e-mail]>



Kathleen Moriarty has entered the following ballot position for
draft-ietf-lmap-use-cases-05: Discuss

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 http://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:
http://datatracker.ietf.org/doc/draft-ietf-lmap-use-cases/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

The draft is well written and easy to read, thank you for that.

I just have one concerns I'd like to chat about:

Section 3.1, second to last paragraph
This discusses the probes nicely in terms of privacy concerns, but leaves
out the security concerns that have resulted in any type of probe traffic
being blocked in the past.  If you are going to leave the privacy
concerns in this section, you should also have the security concerns with
network mapping and the ability to use this information to assess open
ports as well as path information that could be used in the first case to
attack/compromise a host or for denial of service attacks for the first
and second case.  Path information is mentioned in 3.3, so perhaps the
DoS mention would be better there and the general security along with the
privacy in section 3.1.

Later section 5 mentioned the use of an app to gather information from
the end user as opposed to their gateway.  Security and privacy
considerations should be mentioned here as well since they differ from
the the probe scenario.  I would not recommend going in depth on this
topic as this is just the use case document, but rather mentioning it.
It would be out-of-scope to get to deep into application security and
protections from compromise or the ability to gather privacy information
about the user patterns.  A high level statement of those concerns is
enough (IMO) and can get addressed in the solution documents.  Apps and
desktop tools can be directly associated with a user as opposed to a home
and can lead to desktop compromise, so this is different than the
previously mentioned privacy concerns in section 3.  I am aware that
these types of services are available today via web pages and is up to
the user to initiate.

Section 7
First bullet
I'd keep DoS attacks restricted to the degradation of service and have
the points on privacy and business confidentiality listed separately as
merging them confusing the points and attack vectors.  Both can
potentially use information gathered from the probes or the actual
management station itself, but in different ways, this isn't clear from
the bullet.  The DoS could be launched directly from the management
station or information about the network and path to hosts could be used
to launch a targeted DoS attack.  The accuracy of the measurement system
mentioned in the last part of the bullet makes sense combined with the
Dos Attack.
For privacy, you could collect patterns of use to understand user
behavior (already in bullet 2).  Additionally, one could use the
information gathered from probes to determine open ports and potential
vulnerabilities that could be used to compromise the end point (security
concern).
For business confidentiality, I'm not sure what you mean here.  Is this
referring to an ability to gather endpoint information to monitor along
paths for a business?  I would assume that the probe traffic will be
designed to include innocuous information and will just be used for
measurement data.

It looks as is the SecDir reviewer had similar concerns with the
connections between points made in bullet one, so it would be good to fix
this and I hope my above explanation is enough to help you adjust the
text and add the additional considerations.  I'm happy to help with the
text if needed.  The suggested text to the SecDir review is helpful, but
would need to change to address the additional concerns I raised (thanks
for your work on that with Hannes!).

http://trac.tools.ietf.org/area/ops/trac/wiki/mib-security

The SecDir review had a few other good points for bullet 6 that you have
addressed with proposed text and your proposed text is included here for
tracking purposes:
Part of Hannes' request:

  * prevent unauthorized access to collected measurement data,
  * give users the ability to view collected data,
  * give users the ability to exert control over sharing, and
  * enforce retention periods.

** Editor's proposed text on all points for bullet 6:
6. a measurement system that does not indicate who is responsible for the
collection and processing of personal data and who is responsible for
fulfilling the rights of users. The responsible party (often termed the
"data controller") should, as good practice, consider issues such as
defining:- the purpose for which the data is collected and used; how the
data is stored, accessed, and processed; how long it is retained for; and
how the end user can view, update, and even delete their personal data.
If anonymised personal data is shared with a third party, the data
controller should consider the possibility that the third party can
de-anonymise it by combining it with other information.




.