[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: architecture and security
On Mon, Apr 10, 2006 at 01:39:56PM -0700, Randy Presuhn wrote:
> 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.
Executive summary or my elaboration above:
VACM rules either leak information (because it is too hard or even
impossible to get them right) or they lead to inconsistencies
(because they suppress information that should be available).
I do not agree that it is the manager's fault if it assumes certain
information to be available. Sure, a manager should detect cases where
information is missing and not go crazy. But then again, once you have
insufficient information, there is not much useful management one can
expect to happen.
I agree with you so far as that "inconsistent" might be the wrong term
- the term "incomplete" might better describe the situation.
/js
--
Juergen Schoenwaelder International University Bremen
<http://www.eecs.iu-bremen.de/> P.O. Box 750 561, 28725 Bremen, Germany
--
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/>