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?
