Subject: RE: architecture and security

From: "Hector Trevino \(htrevino\)" <[email-masked]>
Date: Mon, 10 Apr 2006 13:38:42 -0700

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] 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 [email-masked] 
> 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 [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>

---

From: Balazs Lengyel <[email-masked]>
Date: Thu, 13 Apr 2006 15:47:34 +0200

Yes some deployments will require additional granularity for access control. But different 
node types might have very different requirements about the fine granularity. Interface 
level might be good for you but I might want to have subscriber management separated from 
the rest of the data or might want the possibility to authorize each virtual router 
separately.

My point is that while granular access control is needed the standard should not try to 
define the levels of access control.

Balazs

Hector Trevino (htrevino) wrote:

> down to the interface level should be sufficient.

---

From: Andy Bierman <[email-masked]>
Date: Thu, 13 Apr 2006 07:20:09 -0700

Balazs Lengyel wrote:
> Yes some deployments will require additional granularity for access 
> control. But different node types might have very different requirements 
> about the fine granularity. Interface level might be good for you but I 
> might want to have subscriber management separated from the rest of the 
> data or might want the possibility to authorize each virtual router 
> separately.
> 
> My point is that while granular access control is needed the standard 
> should not try to define the levels of access control.
> 

I disagree.
We have gone pretty far along now ignoring access control.
IMO, applying access control on the subscription, but not
the outbound notifications, is just broken.

The config data is dynamic, the access rights database is dynamic.
What matters is the receivers access rights at the time
the notification is sent, not when the subscription is made.

I don't think we have to define a detailed model now,
but we have agree when and where access control is applied.

Andy