Subject: architecture and security

From: Andy Bierman <[email-masked]>
Date: Thu, 06 Apr 2006 08:21:23 -0700

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

---

From: Martin Bjorklund <[email-masked]>
Date: Fri, 07 Apr 2006 21:05:38 +0200 (CEST)

>    send the manager specific agent data.

Could you elaborate on what the problem is?  Is this different/more
problematic than the SNMP VACM model?  I.e. can't you use a "notify"
view, and apply it to each notification generated by the agent?  Also,
I think the filter-based approach that Kent described can be seen as
one way to implement this model (if I understand him correctly).

/martin

---

From: Andy Bierman <[email-masked]>
Date: Fri, 07 Apr 2006 12:16:28 -0700

> one way to implement this model (if I understand him correctly).

Yes.
But my point is that the backwards 1-way RPC also reverses
the access control (incorrectly).

IMO, for the subscribe type of API, a profile name is
specified which points to all the parameters, such as
the access-control view to use.

The agent uses that access control profile when generating
each notification, to check it against the contained content.
If the user is allowed to see all the data, the notification is
sent, otherwise it is simply not sent to that user (i.e., on that
session).

Andy