Telechat Review of draft-ietf-ippm-lmap-path-05
review-ietf-ippm-lmap-path-05-opsdir-telechat-harrington-2014-09-12-00

Request Review of draft-ietf-ippm-lmap-path
Requested rev. no specific revision (document currently at 07)
Type Telechat Review
Team Ops Directorate (opsdir)
Deadline 2014-09-02
Requested 2014-08-25
Draft last updated 2014-09-12
Completed reviews Genart Last Call review of -05 by Elwyn Davies (diff)
Genart Telechat review of -05 by Elwyn Davies (diff)
Secdir Last Call review of -05 by David Harrington (diff)
Opsdir Telechat review of -05 by David Harrington (diff)
Assignment Reviewer David Harrington
State Completed
Review review-ietf-ippm-lmap-path-05-opsdir-telechat-harrington-2014-09-12
Reviewed rev. 05 (document currently at 07)
Review result Has Issues
Review completed: 2014-09-12

Review
review-ietf-ippm-lmap-path-05-opsdir-telechat-harrington-2014-09-12

Hi,

I did this secdir review, and most of the concerns are really also ops
related.
It might be good to include this as an opsdir review of the document (to
supplement the official opsdir review).

David Harrington
dbharrington at comcast.net
+1-603-828-1401

> -----Original Message-----
> From: David Harrington [

mailto:dbharrington

 at comcast.net]
> Sent: Friday, September 05, 2014 11:38 AM
> To: secdir at ietf.org; draft-ietf-ippm-lmap-path.all at tools.ietf.org;
> iesg at ietf.org
> Subject: secdir review of draft-ietf-ippm-lmap-path-05
> 
> I have reviewed this document as part of the security directorate's
> ongoing effort to review all IETF documents being processed by the
> IESG.  These comments were written primarily for the benefit of the
> security area directors.  Document editors and WG chairs should treat
> these comments just like any other last call comments.
> 
> Sorry I'm late with this review, given that the telechat was yesterday,
but
> it is held up by discusses that are related to my comments, so maybe my
> comments will still be useful.
> 
> Summary: Almost ready. I have a few concerns about controlling access to
> network management topology information.
> 
> Abstract: This document defines a reference path for Large-scale
> Measurement
> of
>    Broadband Access Performance (LMAP) and measurement points for
>    commonly used performance metrics.  Other similar measurement
>    projects may also be able to use the extensions described here for
>    measurement point location.
> 
> This informational draft defines some terminology and methodology for
> describing the measurement points and paths exercised to gather metrics
> about broadband performance.
> This methodology is to enable the sharing of information in a way that can
> describe where in the network the metrics were generated.
> This draft does not define any messaging formats, and does not expose any
> information on the Internet.
> 
> Since this does involve sharing of information between interested parties,
> there are potential privacy issues.
> Privacy is discussed in the security considerations section, and refers
the
> reader to the LMAP Framework document that discusses privacy in more
> detail.
> 
> The document doesn't discuss who the information is meant to be shared
> with
> - is this sharing within an administrative domain, or across (peering?)
> domains, or made public?
> This does involve exposing network management information, which might
> be
> sensitive because it exposes the network topology and might identify nodes
> in that topology.
> It might be good to at least point out that those who create the reference
> path descriptions be careful who they share the information with.
> If this were a MIB module, the reference path "management objects" would
> probably need to be included as read-sensitive in the MIB security
> boilerplate, and would recommend suitable confidentiality and access
> controls.
> I see that Benoit has suggested generalizing this information beyond LMAP.
> That might make this topology exposure issue more important.
> 
> Which makes me, as an OPSDIR reviewer as well,  wonder if there should be
> an
> associated MIB module to enable the sharing of this reference path
> information in a consistent manner - a manner that already has
> confidentiality and access controls, and for which
operators/administrators
> are already careful about sharing network management information. Of
> course,
> having a MIB module for the reference path by itself would not be very
> important if the measurements themselves are not exposed via a MIB
> module.
> 
> The quality of the text is good. I found the content understandable even
> though I have little background in LMAP (but I do have a background in
> network management so I understand the reference path issue).
> 
> David Harrington
> dbharrington at comcast.net
> +1-603-828-1401