-----Original Message-----
From: Andy Bierman [mailto:ietf@andybierman.com]
Sent: Thursday, April 06, 2006 12:53 PM
To: Kent Watsen
Cc: Netconf (E-mail)
Subject: Re: architecture and security
Kent Watsen wrote:
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...
I need to understand this architecture better.
The WG agreed that a user-based access control model
needs to be supported, but we never specified the details.
So "user A" connects to your NB NSM API to receive notifications.
The NSM (as "user B") has a SB session to a netconf agent configured
to send notifications.
Then "user C" connects to the netconf agent and causes a notification
to be generated.
Let's use the (unexplained) example in sec. 5.1 of the draft.
The agent knows that user C has access to this <config> data.
How does the agent know that the information in the <data> element,
such as the operation performed, the interface name, or the mtu,
can be viewed by user B? How does the your NSM make sure that
user A has proper access to this data?
I think the netconf standard architecture needs to account
for the user C -> B scenario, but avoid proxy in the model
at all costs (i.e., leave C -> B -> A out of the model).
I think the access control granularity needs to be per-object
at least, and per-instance in some use cases.
Kent
Andy
-----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/>
--
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/>