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

[<[e-mail]>]

Radia,
Thank you very much for your review.
Some comments in-line

Best wishes,
Phil

------
From: Radia Perlman [mailto:[e-mail]]
Sent: 18 November 2014 05:39
To: [e-mail]; The IESG; [e-mail]
Subject: Secdir review of draft-ietf-lmap-framework-08

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",
[phil] strained indeed. But too late to change the acronym!

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.
[phil] to note in passing, they may be the same or different protocol (this is to be decided)

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.
[phil] correct, the protocol doc(s) will have to cover this

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.

[phil] Good point. Even if somehow the MA is prevented from injecting falsified reports, a sophisticated customer could distort the measurements (eg add box that drops packets)
I will add something about this. thanks.


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.

[phil]  We’ve discussed this a bit (for example, near the end of the Dublin interim). I think people favour the former approach – the MA regularly calls in to check if the config /instruction has changed.

I’m not sure whether this doc should state that, or give the pros and cons (your text above) – the latter would be the default, though personally I wouldn’t mind if we said the former. What approach do people prefer?


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.

[phil] I guess it depends how much traffic is generated – in general I don’t think there’ll be much, so I’m inclined to disagree.
Note if the Collector did get this information, the Controller would have to be told at least a summary, so it could modify the instructions as appropriate. (A controller-collector interface is out of scope, at this stage.)
Any thoughts?
Radia