RE: architecture and security

["Hector Trevino \(htrevino\)" <htrevino@cisco.com>]

> -----Original Message-----
> From: owner-netconf@ops.ietf.org 
> [mailto:owner-netconf@ops.ietf.org] On Behalf Of Andy Bierman
> Sent: Thursday, April 06, 2006 9: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)

HT: I'll comment in separate e-mail
> 
> 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.
> 

HT: I agree w/the above but that's not the intention (yes, I know this
is not in the draft). 
A manager has to have a subscription registered with the agent to
receive notifications. This can be done directly by the manager or by
some other means (e.g. manually on the device). You could explicitley
configure the subscription or reference some pre-defined profile. 

Let's take case 1 above (i.e. manager creates a subscription) and add
the goal of leveraging existing NE security mechanisms. When a request
is issued (i.e. create subscription) the user's authorization is
validated (e.g. via external server or locally). The first level is to
determine whether or not the user is allowed to receive the type of
notifications which are being requested (e.g. config changes). At this
point, the request is accepted because a) the user is allowed to receive
all requested notifications or b) the user is allowed to receive a
subset but the agent applies an additional filter OR it is rejected
because the user is not allowed to receive all the requested
notification types. This IMO should be the base capability. 

Some deployments will require additional granularity in which case going
down to the interface level should be sufficient. At least for
monitoring this allows partitioning the views/reception of notifications
and keeps down the administration burden. 

 

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