Re: [Netconf] notification access control
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Netconf] notification access control



Hi,

----- Original Message -----
From: Andy Bierman <andy at netconfcentral.com>
Date: Thursday, June 18, 2009 3:25 am
Subject: [Netconf] notification access control
To: NETCONF <netconf at ietf.org>


> Hi,
>  
>  I know I keep complaining about the lack of a coherent
>  ACM in NETCONF, but the presumption of a completely
>  unspecified access control in this RFC is problematic.
>  
>  3.2, para 4:
>  
>      After generation of the <notification> element, access control is
>      applied by the server.  If a session does not have permission to
>      receive the <notification>, then it is discarded for that session,
>      and processing of the internal event is completed for that session.
>  
>  Without any actual ACM, what does 'permission' really mean?

I assume read-access.
 
>  Why is there a presumption that data delivered to a session
>  via <get> should have a different ACM architecture than data
>  delivered to the exact same session via <notification>?

I am not quite sure how data to get differentiate from notif data.
(Since Randy argue that notif data means more than the info
it contains). If yes, notif data should be dropped completely
just as current text says.
  
>  The RFC never says the agent MUST make an all-or-nothing
>  decision wrt/ granting permission to deliver the notification.
>  What if access control is enforced at a lower level,
>  in the XML generation, so no matter what RPC method is
>  trying to access /path/to/secret-password, they can't?

Although NETCONF ACM is lack, but IMO, the ACM should be
applied on XML data. (I.e., after XML generation). Sorry,
maybe I am misunderstood.

>  I will assume an implementation may silently prune
>  parts of the payload from the notification, due to access
>  control policy.  The notification MUST be dropped
>  if the <eventType> element would be filtered out,
>  in violation of the <notification> element schema.

So, if we treat the notif data as the same way as data to get,
then 3 filters might exist: vendor-defined filter for stream definition,
access control filter and user-defined filter when subscription
is created. the latter two filters should be applied to the XML
data (i.e., after <notification> element generation).

[By the way, I am not sure what <eventType> is refering to?
event stream?]

washam


Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.