Re: [Netconf] notification access control
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Netconf] notification access control
Hi -
> From: "Andy Bierman" <andy at netconfcentral.com>
> To: "Randy Presuhn" <randy_presuhn at mindspring.com>
> Cc: "NETCONF" <netconf at ietf.org>
> Sent: Wednesday, June 17, 2009 4:30 PM
> Subject: Re: [Netconf] notification access control
>
> Randy Presuhn wrote:
> > Hi -
> >
> >> From: "Andy Bierman" <andy at netconfcentral.com>
> >> To: "Phil Shafer" <phil at juniper.net>
> >> Cc: "NETCONF" <netconf at ietf.org>
> >> Sent: Wednesday, June 17, 2009 1:17 PM
> >> Subject: Re: [Netconf] notification access control
...
> Since the filters will be removed from monitoring data,
> an attacker won't really have any way of knowing which
> sessions are trying to filter which content. Therefore,
> presence or absence of a notification does not really
> mean anything.
You're only looking at the potential eavesdropper.
Consider where the atacker is the authorized user,
trying to ferrer out information s/he is not supposed
to be able to have access to.
> What's the problem if the agent leaves out some subtrees
> in the payload on <get> or <notification>? And why
> would the ACM policy be different for <get> or <notification>
> in NETCONF? (it's all just SSH2 channel data to me :-)
It's not the omission per se that bothers me. It's that the
very existence of the notification reveals information.
That's why SNMP doesn't just consider the varbinds
in deciding whether to forward a notification. Now maybe
this is covered by Netconf's access control framework,
or maybe it isn't.
> The argument that the manager may not understand the
> notification payload is no different than if the
> manager did a NETCONF <get/> on the same data, and
> a subset was returned.
I don't think anyone is making that argument.
> Obviously, any system that rejected all <get/> requests
> with an access-denied error, would not be very usable.
> Silently skipping over unauthorized data is needed
> to provide a usable management system. What if an
> SNMP MIB walk crashed with an access-control error the
> first unauthorized node it hit? Same problem in NETCONF, no?
How did we get from notifications into get requests?
Randy
Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.