[secdir] Secdir review of draft-ietf-lmap-framework-08

Radia Perlman <radiaperlman@gmail.com> Tue, 18 November 2014 05:39 UTC

Return-Path: <radiaperlman@gmail.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id 647681AC447; Mon, 17 Nov 2014 21:39:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.1
X-Spam-Status: No, score=-0.1 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id 0uIx2yRVr2j6; Mon, 17 Nov 2014 21:39:26 -0800 (PST)
Received: from mail-la0-x22f.google.com (mail-la0-x22f.google.com [IPv6:2a00:1450:4010:c03::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 943551A00D0; Mon, 17 Nov 2014 21:39:25 -0800 (PST)
Received: by mail-la0-f47.google.com with SMTP id gq15so3769280lab.20 for <multiple recipients>; Mon, 17 Nov 2014 21:39:23 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=66byMaXb08HlXC0BhKMNEgQOKYpKbI7ZQU3ZXjzWpkg=; b=fYxNFXd2ol1kz9iGW6l1w0Q6FNhkXq3C7eg6F4u9kzFAPKZW014YDoO6cML34KdeRn XUwBXJYaIZ353TmKehe7iI4lLbrhjUWeIbvPOcyRcg5qgqqakwzN1sV8BTaCg61H5QQQ 9WEa7FU7VBCosLEouBPA4YHRsKKX8EqA7RfgKU6vCNSYqbxYN2oCNqrtRy5/sdBVuXep pUErth3WxFAwCpadp7xnIEtGCvY1QqaOmSL8dxJNb1KA97EDDfOwc2qd6xkO7B94/W2z 2fC92S7XOi5NdPBSFD8S2Yc+GlUsBfpKHihl0y2H2q9PTl+Dzi/wtP4erywWlk/TjFXr Pc/A==
MIME-Version: 1.0
X-Received: by with SMTP id o6mr33481892lao.8.1416289163694; Mon, 17 Nov 2014 21:39:23 -0800 (PST)
Received: by with HTTP; Mon, 17 Nov 2014 21:39:23 -0800 (PST)
Date: Mon, 17 Nov 2014 21:39:23 -0800
Message-ID: <CAFOuuo666Xa2Oodv5psgD83rPBNq8n6HWVkbO7=wxLUXopDVRw@mail.gmail.com>
From: Radia Perlman <radiaperlman@gmail.com>
To: "secdir@ietf.org" <secdir@ietf.org>, The IESG <iesg@ietf.org>, draft-ietf-lmap-framework.all@tools.ietf.org
Content-Type: multipart/alternative; boundary=089e01419d1a8056dd05081b8452
Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/J-cvIMuDJPPdon4BmhVI41Af86M
Subject: [secdir] Secdir review of draft-ietf-lmap-framework-08
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: Tue, 18 Nov 2014 05:39:29 -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.  Document
editors and WG chairs should treat these comments just like any other last
call comments.

Summary: It's fine, though I couldn't resist making a few suggestions.

LMAP is apparently a strained acronym for "Large-scale Measurement of Access
network Performance", a collection of protocols designed for measuring the
capacity and responsiveness of connectivity provided by broadband ISPs,
though there may have been some feature creep as the protocols are
sufficiently general to be used for other things. This document is a
framework document defining terms and providing an overview of the intended
deployment model (and intended to be INFORMATIONAL). There are companion
I-Ds specifying individual protocols in more detail. As such, most of the
security considerations would be discussed in those documents, though this
overview document provides an overview of the types of security
considerations to be discussed in those documents.

The major components of LMAP are a Measurement Agent (MA) usually residing
on customer premises that runs periodic performance tests and reports
results, a Controller usually residing off-customer-premises that configures
some large collection of Measurement Agents, and a Collector usually
residing off-customer-premises that receives and records reports from the
Measurement Agents. Those reports may contain statistical data concerning
normal operation of the MA's platform as well as the results of specific
tests. It is the Controller to MA and MA to Collector protocols that will
require rigorous security analysis and which are specified in different
documents within LMAP. The protocols whose performance is measured may also
require a rigorous security analysis, but they are defined outside of LMAP.

The security considerations section lists the sorts of issues that will need
to be dealt with in the other documents. It does not go into how those
issues are addressed; presumably the companion documents do. There is a much
longer privacy considerations section that enumerates an intimidating set of
potential privacy abuses that need to be mitigated.

An important security consideration that I didn't see was dealing with the
case of a corrupted MA that reports falsified information to the collector.
This might occur in the case where a customer wants it to appear that the
ISP is not meeting its commitments when in fact the ISP is. Whether this can
be effectively mitigated depends on the platform on which the MA is
deployed, but where the MA is deployed on a customer-controlled platform it
must be recognized that the data collected is to some degree inherently
untrustworthy. This means, for example, that in such configurations the data
should not be used as the basis for a customer to get refunds of
subscription fees.

I saw two questionable aspects of the design (at this level of abstraction).

The first has to do with who initiates the Controller to MA connection. This
spec seems to imply that the connection can be initiated from either end...
the Controller can initiate a connection to the MA when it wants to update
the MA's configuration and the MA and initiate a connection to the
controller to report errors and log debugging information. This is
problematic for several reasons. Most importantly, in many scenarios the MA
might move around and therefore be difficult for the Controller to find; or
it might be behind a NAT or other firewall and might not be capable of
accepting incoming connections (at least not without a lot of additional
effort). If all such connections were initiated by the MA, including a
polling interval configured by the controller, such configuration issues go

Alternately, if the Controller initiated all connections, it becomes much
easier to protect the Controller from DoS attacks, since it is generally
much easier to attack a server than a client. But having connections being
initiated from both directions gives the worst of both worlds.

The second has to do with the MA sending error and log reports to the
Controller. While it makes sense for the MA to report errors that occur in
processing Controller Instructions in the responses to those commands,
errors and logged events that occur asynchronously would seem (to me anyway)
as more naturally being sent to the Collector, since its job is to harvest
massive amounts of information from lots of MAs. It is likely to be more
highly replicated and load balanced than the Controller, and thus more
capable of handling bursty loads. But this has little to do with security,
and I throw it out only for your consideration.