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

[Benoit Claise <[e-mail]>]

Thanks Radia for your review.
The authors have posted the v10. I believe it addresses your feedback.
https://www.ietf.org/rfcdiff?url1=draft-ietf-lmap-framework-08&difftype=--html&submit=Go!&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 
> 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
> 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