Re: architecture and security

["Randy Presuhn" <randy_presuhn@mindspring.com>]

Hi -

> From: "Juergen Schoenwaelder" <j.schoenwaelder@iu-bremen.de>
> To: "Randy Presuhn" <randy_presuhn@mindspring.com>
> Cc: "Netconf (E-mail)" <netconf@ops.ietf.org>
> Sent: Monday, April 10, 2006 12:52 PM
> Subject: Re: architecture and security
... 
> I have recently looked at a different problem, namely the
> anonymization (or pseudonymization) of management traffic and
> configurations and it is virtually impossible to get this right since
> information leaks through very easily (just consider an IPv6 address
> derived from an IEEE MAC address which is then used to derive an
> SnmpEngineID - and now your task is to anonymize the MAC address).
> While it might be possible to get things right for a given device with
> enough man-power for standard read-only tables (and I very much doubt
> that someone is willing spending this money for a single device while
> the next device means you have to repeat major parts of the exercise
> due to many private MIB objects), things melt down quite quickly once
> you face tables where users can name entries or even put descriptions
> or other opaque things into an agent. Operationally useful names
> usually carry quite a bit of context (this is exactly why they are
> useful to operators) and so it is very likely that information leaks
> through these descriptions.

No disagreement on this point, but I think it is quite a different one from
the claim that VACM causes management information to become
inconsistent.

> Talking about VACM: VACM fails by design when it comes to situations
> where the item you want to base your access control decision is not in
> the OID.  No, I am not asking for a VACM++ - this would only help in
> theory and make things worse in practice.
...

Again, no disagreement.  I think the issue for netconf is just what is
needed to do access control on a subscription, and whether the
possibility of changes to configuration or access control policy may
render inadequate a strategy of evaluating the access decision function
only at the time the subscription is created.

Randy


--
to unsubscribe send a message to netconf-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>