Re: [perpass] On configuration versus mechanism

[Brian Trammell <[e-mail]>]

hi Stephen, all,

On Aug 18, 2013, at 11:47 PM, Stephen Farrell <[e-mail]> wrote:

> 
> Hi Brian,
> 
> First, thanks for the thoughtful post. You make some good points.
> A few responses below. Might be better to follow up in separate
> mails, since you raise too many interesting points probably:-)
> 
> On 08/18/2013 07:45 PM, Brian Trammell wrote:

<snip>

>> The tools of monitoring themselves are also applicable to operations
>> and management, which is where I got started in the IETF, working on
>> the protocols that are perhaps most directly applicable to network
>> monitoring at the scale applicable to pervasive passive surveillance,
> 
> Yep, that's a real issue - to what extent is it possible to be more
> robust against a pervasive passive monitor without buggering up n/w
> mgmt. I don't know the answer, but that's where the E in IETF should
> come into play.

One of the bits of relatively obvious guidance that came out of PRISM was "throw away what you don't need as early as you can": an added bonus is that this makes passive measurement scale a lot better too, because you're not keeping around a lot of useless state. This is a little contrary to the practice of science -- collect all you can and analyze later -- but has a real impact on the privacy risk of these technologies. In jurisdictions with serious privacy laws, it's the only way to operate. For example (hey look, another anecdote! ;) ) a few years ago [1], Google was cited by the German data protection authority for driving Street View cars around and saving all the (open) wireless traffic they saw -- including partial payload -- in order to do a later analysis of BSSIDs seen for geolocation purposes. Presumably this was either a packet capture misconfiguration or a bit of engineering laziness, which could have been avoided simply by making the software in the cars smarter about what they kept.

In passive monitoring for management and operations, this means each collection activity should have a specified purpose, and information irrelevant to that purpose simply shouldn't be collected at the observation point. This is admittedly easier for some things (passive performance characterization) than for others (billing and troubleshooting, both of which need to identify the endpoints). 

There's a metarequirement here, which should be explicitly stated: anything we do to protect a protocol against passive monitoring should take the manageability of the result into account.

>> IPFIX (RFC5101 and draft-ietf-ipfix-protocol-rfc5101bis) and PSAMP
>> (RFC5474-5477). Here, we've defined protocols that by _necessity_
>> enable large-scale passive data collection. That's what they were
>> designed to do, though of course they were designed with a rather
>> more limited applicability in mind, focusing on billing, capacity
>> planning, troubleshooting, and forensics and security monitoring on
>> enterprise networks.
>> 
>> It was through working on these protocols that I remember that the
>> IETF made a policy statement on passive surveillance in the form of
>> wiretapping (full content delivery to a third party) thirteen years
>> ago. RFC 2804 states, in essence, that requirements for wiretapping
>> are not to be considered in the creation and maintenance of IETF
>> standards, though the reasoning presented behind this is rather more
>> motivated by practical concerns than an inherent desire to protect
>> communications.
>> 
>> RFC 2804 has been generally cited as "we don't do wiretapping here",
>> to the extent that the security considerations of RFC 5476 (PSAMP)
>> state that "[t]he PSAMP Device SHOULD NOT export the full payload of
>> conversations, as this would mean wiretapping [RFC2804].  The PSAMP
>> Device MUST respect local privacy laws" -- in effect, though this is
>> not the _spirit_ of the statement, we say that a device in a
>> jursidiction with weak privacy laws with a full-payload sampling
>> probability of 0.99 is compliant, while one with a sampling
>> probability of 1.00 is not. This illustrates a second issue, which I
>> think can be generalized (but maybe I only think this because I'm a
>> measurement geek):
>> 
>> (2) Most (perhaps all) technologies that can be applied to passive
>> network measurement for operations and management purposes can be
>> applied to pervasive passive network surveillance: the only
>> difference is one of configuration and deployment.
>> 
>> To me, this indicates we'll probably end up focusing more on
>> configuration and implementation guidance than on changing protocols,
>> except in those cases where protocols need specific support for
>> cryptography which they presently lack. This is probably a good
>> thing.
>> 
>> We spent a good deal of time thinking about these issues a few years
>> ago in the FP7-PRISM project (http://fp7-prism.eu) (no, not that
>> PRISM; yes, I appreciate the irony). 
> 
> Are there any of the publications/deliverables from that that'd
> be a good read for folks on this list? (The site has too much to
> digest tonight:-)

Unfortunately, in the public deliverables, not really; they're all a bit too wordy to jump into and really understand what's going on, and the target moved a bit during the project, which makes it difficult to start at  the introductory material and understand where we ended up. Originally, we were looking into using homomorphic encryption in network monitoring -- projecting filtering and aggregation operations into encrypted data space, and decrypting only the results -- but this turned out (perhaps not surprisingly) not to scale very well.

There's a very quick and inadequately detailed introduction to the architecture in "An introduction to IPFIX", IEEE Communications Magazine, April 2011. Sections 2 and 3.1 of http://telscom.ch/wp-content/uploads/Prism/FP7-PRISM-WP2.2-D2.2.2.pdf are reasonably understandable on their own; the rest of the document gets very rapidly into the gory details.

In any case, I'd suggest taking architectural guidance from the general pattern of usage (separating measurement configuration control from measurement configuration, protecting the channel with single-use credentials) as opposed to trying to implement PRISM as is.

Best regards,

Brian

[1] http://googleblog.blogspot.ch/2010/05/wifi-data-collection-update.html