[secdir] secdir review of draft-ietf-ippm-lmap-path-05

"David Harrington" <dbharrington@comcast.net> Fri, 05 September 2014 15:38 UTC

Return-Path: <dbharrington@comcast.net>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E5B21A093B for <secdir@ietfa.amsl.com>; Fri, 5 Sep 2014 08:38:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.769
X-Spam-Level:
X-Spam-Status: No, score=-0.769 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001] autolearn=unavailable
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D2OooEmlDHgN for <secdir@ietfa.amsl.com>; Fri, 5 Sep 2014 08:38:04 -0700 (PDT)
Received: from qmta08.westchester.pa.mail.comcast.net (qmta08.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:80]) by ietfa.amsl.com (Postfix) with ESMTP id CA7141A08BE for <secdir@ietf.org>; Fri, 5 Sep 2014 08:38:03 -0700 (PDT)
Received: from omta03.westchester.pa.mail.comcast.net ([76.96.62.27]) by qmta08.westchester.pa.mail.comcast.net with comcast id nPGr1o0030bG4ec58Te3J6; Fri, 05 Sep 2014 15:38:03 +0000
Received: from JV6RVH1 ([67.189.237.137]) by omta03.westchester.pa.mail.comcast.net with comcast id nTe21o00T2yZEBF3PTe27L; Fri, 05 Sep 2014 15:38:03 +0000
From: "David Harrington" <dbharrington@comcast.net>
To: <secdir@ietf.org>, <draft-ietf-ippm-lmap-path.all@tools.ietf.org>, <iesg@ietf.org>
Date: Fri, 5 Sep 2014 11:38:00 -0400
Message-ID: <010501cfc91f$60926610$21b73230$@comcast.net>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: Ac/JGGxFZFjwTBimTBKDthR2TvnD5Q==
Content-Language: en-us
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1409931483; bh=QAcMzWvc1YfyFpjNWdsnFB4ocZi+1gwVQ5y6uzrv29Y=; h=Received:Received:From:To:Subject:Date:Message-ID:MIME-Version: Content-Type; b=sQ41ccXQAHcf543IqOko+xTpCTJsGnI0yvEruOIXAv2znOStZNoE4lSy0M9NSC7N6 IxiHJjBjd/4QXfCZPXXZIuXLh/qQHCac4xCoyvFI/lbUSkSRKW0qtMnNtkEG0TcR+w 8nXVBlY8/5c9WlZa4l0e3XSqQixN8SELmggsNzd4Cx8VfwYk6HzWioyj7jn6u4blUl Fq90AsgY+7iKaqX3btwHn5MN5vXOQamtHjN2NUxO1jCYhNXd9lLDT2901MD8selbkz I8KV1nVkDNh7beKe5vi1BBPa48f/FZOuzfBn86eK6wo/RtCuKLQP7901PAZPABCJBE fuNh9VqyAjt5Q==
Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/ceH_q2UVxE_uMFrS-MSu_ltrOsc
Subject: [secdir] secdir review of draft-ietf-ippm-lmap-path-05
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 05 Sep 2014 15:38:05 -0000

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@comcast.net
+1-603-828-1401