security for snmpbulk transfers

[Matt White <mwhite@torrentnet.com>]

So I was whining about having a username/password for a statistics server 
in a managed device at the EOS meeting and thought I'd carry that whining 
on to the list.

Bottom line: I really don't think this is going to fly.  Statistics 
information used for billing and accounting is considered extremely 
sensitive by providers.  I don't think providers, particularly telcos, are 
going to be at all thrilled at putting that information in their network 
devices.

There are a couple ways of dealing with this that I can think of off the 
top of my head:

1)  Move from a push to a pull model.  The SNMP agent modifies a MIB 
variable to indicate that it is ready to transmit data via the oob channel 
specified and then the management station should connect and collect the 
information.

Pros:  Best security of what I'm about to list and what's been proposed in 
the WG.  Authentication credentials are stored only on the management 
station or statistics server.
Cons:  Requires explicit support for bulk transfer on the manager.  It's 
possible that agent will run out of caching room while waiting for the 
manager to download (although I'd argue that a proper implementation would 
not have this problem).


2)  A careful specification of how to secure the statistics server.  In 
this case what we want is compartmentalization.  The agent pushes the 
collected statistics to a write-only filestore.  This is really more of a 
policy issue in general but we need to specify name collision behaviour 
because we cannot overwrite files.  It'd be nice to specify a way for the 
router to authenticate using its private key, if it has sshd support.

Pros:  Decent security potential as long as proper guidance is given. 
Worst case scenario is that that a compromised agent could perform a DoS 
attack on the statistics server.  You could argue that with proper quotas 
set, this DoS attack could be limited to only logging for the compromised 
box, which you can't trust now anyway.
Cons:  It'll be easy for operators to misconfigure server security in this 
scheme.


Thoughts?

Matt White
Ericsson IPI