 |
 |
 |
 |
|
 |
|
 |
|
 |
|
 |
|
|
|
|
|
|
|
|
|
|
|
|
Randy Presuhn wrote:
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 8:01 PM Subject: Re: [Netconf] notification access control...Simple example: ISP has equipment with dedicated interfaces for two companies. Let's call them AndyCorp and RandyCorp. Each of these companies is provided (limited) access to its dedicated interfaces, and should be kept in the dark about what's happening with the competitor's interfaces. By subscribing to all notifications, RandyCorp could get a pretty good idea what's happening at AndyCorp, even if all the AndyCorp content was stripped from the notifications.I'm not seeing the security hole here. Why assume that the ACM cannot simply put a filter on the eventType, which is the most common usage of a filter? That way the entire notification will be dropped.Because both AndyCorp and RandyCorp will need to get the same event types. Consider a linkDown as an example.
Why assume the ACM is incapable of providing this data isolation, if that is what the operator wants? Why assume a <get> operation on the other companies <interface> entry can be properly protected by the ACM, but not a <link-down> notification?
But that is up to the operator to decide by configuring the ACM one way or another. The vendor should use virtual routers or some solution like that if ACM alone cannot be trusted to prevent one org from spying on another.What I'm saying is that attempts to redact notification payloads will still leak information since you can't reasonably expect to limit who should get a notification based on notification type alone.
Depending on the environment, the operator can configure the ACM to do the right thing.
Randy
Andy