RE: architecture and security

["Kent Watsen" <kwatsen@juniper.net>]

NSM also supports notifications thru its northbound interface.  The way
that we address access control is by authorizing the subscription
request.  This approach has proven ideal for us as it:

  1. limits the system to only having to test client-initiated requests
  2. enables the system to add "implicit-filters" to the requests
  3. eliminates the system from having to apply filters to the responses

To understand the desire for implicit filters, please consider that the
system may implement granular access-controls such that an authenticated
user may only have access to a subset of a data repository.  For
instance, the user may only have access to a particular virtual system
(i.e. virtual router); from the user's perspective, the subscription
might be to "all events" but, upon receiving the request, the system's
access-control module might add an implicit-filter so that the request
then reads "all events where event->vsys == user->vsys" - after having
modified the incoming request, the access-control module can than pass
the request down into the system, which can remain unaware of
access-control issues...


Kent





-----Original Message-----
From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org] On
Behalf Of Andy Bierman
Sent: Thursday, April 06, 2006 8:21 AM
To: Netconf (E-mail)
Subject: architecture and security

Hi,

I think the architecture for netconf notifications needs more attention.
The current draft tries to fit notifications into the existing model
for remote procedure calls.  The <rpc-one-way> is supposedly just
like a regular <rpc>, except it goes from the agent to the manager,
and there is no return value.  Also, the WG decided (based on
Junoscript experience) that returning <ok> was better than
no return value -- we explicitly don't want a 1-way-rpc --
in either direction.


There are 2 major problems with this architecture:

1) Headers are different becase the messages are different;
   Notifications have different general characteristics
   than RPC requests, so the headers will be different
   (e.g., no timestamp in an RPC request like a notification)

2) Access control is backwards;
   It doesn't make sense to apply access control to the '1 way RPC'
   in the same sense as a regular RPC.  It is the manager who is
   supposed to have access granted to view specific agent data -- not
   the agent that is supposed to have access granted to
   send the manager specific agent data.


Even though the term <rpc-one-way> is being removed, and the
message will be called <notification> instead (as it is on
page 17), we still need a secure architecture which scales well,
and will support a user-based access control model.
We need to think of how notifications fit into the base
netconf protocol, as well as existing security and NM protocols.
Operational issues and common use cases (e.g., building power-cycle)
need to be addressed.

Once the requirements and architecture are understood,
we will be able to simplify and focus the API.  It isn't
acceptable to come to the conclusion that a feature is
a 95% lose-lose scenario, but we should do it anyway.


Andy



--
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/>

--
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/>