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

Benoit Claise <> Tue, 17 February 2015 18:24 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 07C331A8AF0; Tue, 17 Feb 2015 10:24:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -14.51
X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id XE9OVI3zPL4S; Tue, 17 Feb 2015 10:24:32 -0800 (PST)
Received: from ( []) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 0D81B1A1B84; Tue, 17 Feb 2015 10:24:30 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=13860; q=dns/txt; s=iport; t=1424197471; x=1425407071; h=message-id:date:from:mime-version:to:subject:references: in-reply-to; bh=DLqvOzaYj2LD/aAP043/ukAiaecxM8U35/pjC8xVFXc=; b=PdAPpVCqy/BKjJC46iKr//YI15zSVVFAJqxPW2mC7IBtIAWcatSAH5VS XFUvY11ciOZdKVBArZkBBDGDdLYthG2yvEio8/tCLda8mFDEbgAc9OM/S 8pSyA67Lq5zj2REBZRH/PLFn0tpkvSbXrZ0LiTJe4wOxcqVviw2Cl5/Qz U=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.09,595,1418083200"; d="scan'208,217";a="352542337"
Received: from (HELO ([]) by with ESMTP; 17 Feb 2015 18:24:28 +0000
Received: from [] ( []) by (8.14.5/8.14.5) with ESMTP id t1HIOSP8031211; Tue, 17 Feb 2015 18:24:28 GMT
Message-ID: <>
Date: Tue, 17 Feb 2015 19:24:28 +0100
From: Benoit Claise <>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0
MIME-Version: 1.0
To: Radia Perlman <>, "" <>, The IESG <>,
References: <>
In-Reply-To: <>
Content-Type: multipart/alternative; boundary="------------050201070205090906050701"
Archived-At: <>
Subject: Re: [secdir] Secdir review of draft-ietf-lmap-framework-08
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 17 Feb 2015 18:24:35 -0000

Thanks Radia for your review.
The authors have posted the v10. I believe it addresses your feedback.!&url2=draft-ietf-lmap-framework-10
I would appreciate if you could double-check.

Regards, Benoit
> 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 
> 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
> away.
> 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.
> Radia