Early Review of draft-ietf-lmap-framework-08
review-ietf-lmap-framework-08-secdir-early-perlman-2014-11-20-00

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