Subject: [i2rs] topo model use of NACM

From: Andy Bierman <[email-masked]>
Date: Thu, 16 Feb 2017 11:00:10 -0800

Hi,

The use of NACM for server-provided data is under-specified (at best)

from sec. 4.1:

   Finally, there is an object "server-provided".  This object is state
   that indicates how the network came into being.  Network data can
   come into being in one of two ways.  In one way, network data is
   configured by client applications, for example in case of overlay
   networks that are configured by an SDN Controller application.  In
   annother way, it is populated by the server, in case of networks that
   can be discovered.

   If server-provided is set to false, the network was configured by a
   client application, for example in the case of an overlay network
   that is configured by a controller application.  If server-provided
   is set to true, the network was populated by the server itself,
   respectively an application on the server that is able to discover
   the network.  *Client applications SHOULD NOT modify configurations of
   networks for which "server-provided" is true.*  When they do, they
   need to be aware that any modifications they make are subject to be
   reverted by the server.  For servers that support NACM (Netconf
   Access Control Model), *data node rules should ideally prevent* write
   access by other clients to network instances for which server-
   provided is set to true.

The SHOULD NOT above is really odd, considering is not supported by YANG
or the NC/RC protocols.

"data node rules should ideally prevent"

s/should/SHOULD/

Ideally prevent?
Is that a new engineering term?
Either this new usage of NACM works or it doesn't.

Also, there is no guidance or examples of the NACM config that the
server is supposed to magically create for server-provided topology data.
There is nothing in NACM at all about server-created data rules.
This is not supported by NACM.

Does the I2RS text imply that the server-provided property extends
to the NACM sub-trees? They are also subject to replacement by the server?
The client SHOULD NOT change these NACM rules?

IMO the way this server-provided property is being done is a short-sighted
point solution, but this should be a fundamental part of the revised
datastores work.
Is there something special about network topology such that
server-provided data for a different module will require a different
solution? If not, is the topo module solution reusable?

Andy

---

From: "Susan Hares" <[email-masked]>
Date: Thu, 16 Feb 2017 14:29:52 -0500

Andy: 

<chair hat> 

Thank you for bringing up your questions regarding NACM,  I2RS topologies, and revised data stores.  This area of discussion may be part of Alex’s work that he indicates he’s going to review.  Splitting the conversation into “current” yang and “revised datastores” yang is a very good idea.  I encourage the authors to do so.  

</chair hat off> 

point solution, but this should be a fundamental part of the revised datastores work.

Sue Hares 

From: i2rs [mailto:[email-masked]] On Behalf Of Andy Bierman
Sent: Thursday, February 16, 2017 2:00 PM
To: [email-masked]
Subject: [i2rs] topo model use of NACM

Hi,

 

from sec. 4.1:

   If server-provided is set to false, the network was configured by a
   client application, for example in the case of an overlay network
   that is configured by a controller application.  If server-provided
   is set to true, the network was populated by the server itself,
   respectively an application on the server that is able to discover
   the network.  Client applications SHOULD NOT modify configurations of
   networks for which "server-provided" is true.  When they do, they
   need to be aware that any modifications they make are subject to be
   reverted by the server.  For servers that support NACM (Netconf
   Access Control Model), data node rules should ideally prevent write
   access by other clients to network instances for which server-
   provided is set to true.

or the NC/RC protocols.

s/should/SHOULD/

Ideally prevent?

point solution, but this should be a fundamental part of the revised datastores work.

 

Andy

---

From: "Susan Hares" <[email-masked]>
Date: Thu, 16 Feb 2017 14:47:16 -0500

Andy: 

<chair hat off, individual contributor hat on> 

AFAIK – I believe the revised data store model is right approach.   It is an important question to ask whether the ability to have a mixture of “server-provided” and “configured” is important for all topology models.  I hope Xufeng and other topology models will comment on this point. 

Does the NETCONF data store in the revised data-store future include the control plane data stores? I thought the answer was “no” it does not.   Here’s some text from draft-ietf-netconf-rfc6536bis that leads me to believe that 

On NACM, draft-ietf-netconf-rfc6536bis it says: 

   It is necessary to control access to specific nodes and subtrees

   within the NETCONF datastore, regardless of which protocol operation,

   standard or proprietary, was used to access the datastore.

 <https://tools.ietf.org/html/draft-ietf-netconf-rfc6536bis-00#section-3.2> 3.2.  Datastore Access

   The same access control rules apply to all datastores, for example,
   the candidate configuration datastore or the running configuration
   datastore.
 
   Only the standard NETCONF datastores (candidate, running, and
   startup) are controlled by NACM.  Local or remote files or datastores
   accessed via the <url> parameter are not controlled by NACM.  A
   standalone RESTCONF server (i.e., not co-located with a NETCONF
   server) applies NACM rules to a conceptual datastore, since
   datastores are not supported in RESTCONF.

===========

The I2RS security environment actually looks at 3 policies on the server 

Network Access ß-à server ß-à routing-system access  

              (aka I2RS agent)

                    |ßà System access 

It also looks at application access to the client 

  Network accessßà client ßà application-access  

The protocol only needs to consider the NACM Access, but the routing infrastructure need to consider the server to/from routing system, and server to/from system.  My understanding is that the Routing system access control module (RACM) and the system access control module (SACM) functions were not in NACM. 

Thanks again for posting, 

Sue  

Hi,

 

from sec. 4.1:

or the NC/RC protocols.

s/should/SHOULD/

Ideally prevent?

 

Andy

---

From: Andy Bierman <[email-masked]>
Date: Thu, 16 Feb 2017 12:49:13 -0800

Hi,

I am most concerned about getting the architecture right.
We have ignored server-created nodes until now.
I am glad I2RS WG is trying to deal with the problem.
Just make sure we have a reusable solution.

Also concerned about tool automation.
There was some discussion of a 'server-created' extension at some point I
think.
This would help, because the server-created leaf is not really
deterministic.
It is just a convention.

e.g.

  container networks {
     list network {
         i2rs:server-created;
         ...
         leaf server-created { ... }
         ...
     }
  }

Andy

On Thu, Feb 16, 2017 at 11:47 AM, Susan Hares <[email-masked]> wrote:

> AFAIK – I believe the revised data store model is right approach.   It is
> an important question to ask whether the ability to have a mixture of
> “server-provided” and “configured” is important for all topology models.  I
> hope Xufeng and other topology models will comment on this point.
>
>
>
>
>
> Does the NETCONF data store in the revised data-store future include the
> control plane data stores? I thought the answer was “no” it does not.
>  Here’s some text from draft-ietf-netconf-rfc6536bis that leads me to
> believe that
>
>
>
> 3.2
> <https://tools.ietf.org/html/draft-ietf-netconf-rfc6536bis-00#section-3.2>.
> Datastore Access
>
> The protocol only needs to consider the NACM Access, but the routing
> infrastructure need to consider the server to/from routing system, and
> server to/from system.  My understanding is that the Routing system access
> control module (RACM) and the system access control module (SACM) functions
> were not in NACM.
>
>
>
> *From:* i2rs [mailto:[email-masked]] *On Behalf Of *Andy Bierman
> *Sent:* Thursday, February 16, 2017 2:00 PM
> *To:* [email-masked]
> *Subject:* [i2rs] topo model use of NACM
>
>
>
> Hi,
>
>
>
>    the network.  *Client applications SHOULD NOT modify configurations of*
>
> *   networks for which "server-provided" is true.*  When they do, they
>

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 16 Feb 2017 22:14:12 +0100 (CET)

> There was some discussion of a 'server-created' extension at some point I

That old discussion was about a different (and simpler) use case; it
was about when a server would add some nodes to the configuration as
part of a client's creation request.  For example, a server would
automatically assign a 'uid' to a newly created user.

The topology use case is more complicated.  The server can discover a
topology and instantiate it somewhere - originally it was instantiated
in the configuration, but that is questionable.  I still don't really
understand the expected lifecycle of these server provided instances;
specifically, can they come and go completely dynamically, even if
there are other instances that refer to them?

/martin

---

From: Alexander Clemm <[email-masked]>
Date: Thu, 16 Feb 2017 22:18:13 +0000

There are actually a number of interesting implications with regards to NACM.  NACM could indeed be a key to the solution if it provides sufficient flexibility with regards to articulating and enforcing authorization rules.  Regarding this, I have a number of questions/comments:

-          If a subtree contains objects that a client does not have write privileges for, will the client be prevented from locking the subtree? How about the case when the client does not even have read privileges?

The current NACM-bis draft states in section 3.7.2 that this is not the case – i.e. a client is able to lock an entire subtree, even in cases when there is not a single object in that subtree that the client actually has access privileges to.

To me, this does not seem right.  It just invites abuse.

Now, there is still the possibility to restrict access to the operation overall.  But again, this means that you have to give a users an all-or-nothing choice.  Too inflexible.  By the same token that partial locks were supported to avoid requiring anyone who needs the ability to conduct a transaction to lock down the entire server, there should be the ability to restrict access to the lock and partial-lock operation by targeted subtree.  However, this capability is currently missing.

-          Where can NACM rules originate from?   The current model seems to assume that rules will always be explicitly configured from an external client and constitute part of configuration. Now, what about the case when rules are to be enforced automatically by the server?   I think NACM should allow for that, and having a mix of both.  (The server-provided topologies are one potential example where this would be very useful.  In fact, if this capability were supported, I don’t think we would be having the server-provided discussion in the topology context – NACM would be all we need.  However, there are other use cases for this.  Think e.g. an intrusion protection component on the server, that you would not want to override by an external user administration client application that you would still want to allow as well.  Or cases when some authorizations get signaled, e.g. in the case of autonomic peer-to-peer type of applications.)

--- Alex

From: i2rs [mailto:[email-masked]] On Behalf Of Andy Bierman
Sent: Thursday, February 16, 2017 12:49 PM
To: Susan Hares <[email-masked]>
Cc: [email-masked]
Subject: Re: [i2rs] topo model use of NACM

Hi,

Also concerned about tool automation.
There was some discussion of a 'server-created' extension at some point I think.
This would help, because the server-created leaf is not really deterministic.
It is just a convention.

e.g.

  container networks {
     list network {
         i2rs:server-created;
         ...

Andy

On Thu, Feb 16, 2017 at 11:47 AM, Susan Hares <[email-masked]<mailto:[email-masked]>> wrote:
Andy:
<chair hat off, individual contributor hat on>

3.2<https://tools.ietf.org/html/draft-ietf-netconf-rfc6536bis-00#section-3.2>.  Datastore Access

   datastore.

===========

Network Access <-----> server <-----> routing-system access
              (aka I2RS agent)
                    |<----> System access

  Network access<----> client <----> application-access

Sue

From: i2rs [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Andy Bierman
Sent: Thursday, February 16, 2017 2:00 PM
To: [email-masked]<mailto:[email-masked]>
Subject: [i2rs] topo model use of NACM

Hi,

from sec. 4.1:

   can be discovered.

   provided is set to true.

s/should/SHOULD/

Ideally prevent?

Andy

---

From: Andy Bierman <[email-masked]>
Date: Thu, 16 Feb 2017 14:36:34 -0800

On Thu, Feb 16, 2017 at 2:18 PM, Alexander Clemm <[email-masked]
> wrote:

> There are actually a number of interesting implications with regards to
> NACM.  NACM could indeed be a key to the solution if it provides sufficient
> flexibility with regards to articulating and enforcing authorization
> rules.  Regarding this, I have a number of questions/comments:
>
>
>
> -          If a subtree contains objects that a client does not have
> write privileges for, will the client be prevented from locking the
> subtree? How about the case when the client does not even have read
> privileges?
>

locking and NACM are 2 different things.
NETCONF has datastore (global) locks and subtree (partial) locks.
There is no mechanism in NACM or elsewhere that constrains the values
that a particular client can use. (NACM controls access to the rpc, with no
control over specific input paramters).

>
> The current NACM-bis draft states in section 3.7.2 that this is not the
> case – i.e. a client is able to lock an entire subtree, even in cases when
> there is not a single object in that subtree that the client actually has
> access privileges to.
>
>
>
> Now, there is still the possibility to restrict access to the operation
> overall.  But again, this means that you have to give a users an
> all-or-nothing choice.  Too inflexible.  By the same token that partial
> locks were supported to avoid requiring anyone who needs the ability to
> conduct a transaction to lock down the entire server, there should be the
> ability to restrict access to the lock and partial-lock operation by
> targeted subtree.  However, this capability is currently missing.
>

NACM was designed to be simple to implement.
Some complex features that were in VACM were intentionally left out of NACM.
NETCONF locking is also intentionally simple.

I would rather have NETCONF 2.0 use a mandatory implicit, optimistic
concurrent
locking model, rather than more band-aids on the optional explicit,
pessimistic
serialized locking model we have now.

>
> -          Where can NACM rules originate from?   The current model seems
> to assume that rules will always be explicitly configured from an external
> client and constitute part of configuration. Now, what about the case when
> rules are to be enforced automatically by the server?   I think NACM should
> allow for that, and having a mix of both.  (The server-provided topologies
> are one potential example where this would be very useful.  In fact, if
> this capability were supported, I don’t think we would be having the
> server-provided discussion in the topology context – NACM would be all we
> need.  However, there are other use cases for this.  Think e.g. an
> intrusion protection component on the server, that you would not want to
> override by an external user administration client application that you
> would still want to allow as well.  Or cases when some authorizations get
> signaled, e.g. in the case of autonomic peer-to-peer type of applications.)
>
>
I don't think any YANG configuration module precludes server-created
entries.
The configuration is created somehow.  The YANG module discusses the data
model
instances without saying how they got there.

Andy

> *Sent:* Thursday, February 16, 2017 12:49 PM
> *To:* Susan Hares <[email-masked]>
> *Cc:* [email-masked]
> *Subject:* Re: [i2rs] topo model use of NACM
>
>
>
> Hi,
>
>
>
> _______________________________________________
> i2rs mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/i2rs
>
>

---

From: Alexander Clemm <[email-masked]>
Date: Thu, 16 Feb 2017 22:59:01 +0000

Hi, inline, <ALEX>
--- Alex

From: Andy Bierman [mailto:[email-masked]]
Sent: Thursday, February 16, 2017 2:37 PM
To: Alexander Clemm <[email-masked]>
Cc: Susan Hares <[email-masked]>; [email-masked]
Subject: Re: [i2rs] topo model use of NACM

On Thu, Feb 16, 2017 at 2:18 PM, Alexander Clemm <[email-masked]<mailto:[email-masked]>> wrote:
There are actually a number of interesting implications with regards to NACM.  NACM could indeed be a key to the solution if it provides sufficient flexibility with regards to articulating and enforcing authorization rules.  Regarding this, I have a number of questions/comments:

I would rather have NETCONF 2.0 use a mandatory implicit, optimistic concurrent
locking model, rather than more band-aids on the optional explicit, pessimistic
serialized locking model we have now.

<ALEX> Simple is good, but it puts the onus on applications if they want to accomplish something more powerful.  And, there is the question if it is not too simple.  The  case of allowing any client (who needs to be granted _some_ access) from locking down entire configurations to me seems at least questionable; this does appear to be a case where it should be possible to differentiate privileges.

We are having the discussion in the context of the topology discussion.  What started it was the case of the backup/restore application that wants to be agnostic with regards to the data, yet that cannot be denied access to certain data that should not be subjected to this application.  If not for this, topology might be done by now.  In this case, the simplicity of the framework does cause significant complexity elsewhere.
</ALEX>

I don't think any YANG configuration module precludes server-created entries.
The configuration is created somehow.  The YANG module discusses the data model
instances without saying how they got there.

 <ALEX> Then why are we concerned in the topology model about how the entries got there?
</ALEX>

--- Alex

Andy

From: i2rs [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Andy Bierman
Sent: Thursday, February 16, 2017 12:49 PM
To: Susan Hares <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [i2rs] topo model use of NACM

Hi,

e.g.

  container networks {
     list network {
         i2rs:server-created;
         ...

Andy

   datastore.

===========

Sue

Hi,

from sec. 4.1:

   can be discovered.

   provided is set to true.

s/should/SHOULD/

Ideally prevent?

Andy

_______________________________________________
i2rs mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/i2rs

---

From: Kent Watsen <[email-masked]>
Date: Fri, 17 Feb 2017 17:57:28 +0000

Hi Andy,

There is an effort going to resolve this issue.  See the "modeling options for draft-ietf-i2rs-yang-network-topo" thread for the latest.

Hi Martin,

> I still don't really

Yes, the 'server-provided' nodes are opstate nodes.  That they're being potentially referenced by config nodes is inconsequential.

Kent

---

From: Robert Wilton <[email-masked]>
Date: Tue, 21 Feb 2017 09:33:05 +0000

Hi Andy,

On 16/02/2017 22:36, Andy Bierman wrote:
>
>
> On Thu, Feb 16, 2017 at 2:18 PM, Alexander Clemm 
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     There are actually a number of interesting implications with
>     regards to NACM.  NACM could indeed be a key to the solution if it
>     provides sufficient flexibility with regards to articulating and
>     enforcing authorization rules.  Regarding this, I have a number of
>     questions/comments:
>
>     -If a subtree contains objects that a client does not have write
>     privileges for, will the client be prevented from locking the
>     subtree? How about the case when the client does not even have
>     read privileges?
>
>
>     The current NACM-bis draft states in section 3.7.2 that this is
>     not the case – i.e. a client is able to lock an entire subtree,
>     even in cases when there is not a single object in that subtree
>     that the client actually has access privileges to.
>
>     Now, there is still the possibility to restrict access to the
>     operation overall.  But again, this means that you have to give a
>     users an all-or-nothing choice.  Too inflexible.  By the same
>     token that partial locks were supported to avoid requiring anyone
>     who needs the ability to conduct a transaction to lock down the
>     entire server, there should be the ability to restrict access to
>     the lock and partial-lock operation by targeted subtree.  However,
>     this capability is currently missing.
>
>
>
This is interesting.  If you have time, then at some point, please can 
you expand on this idea, perhaps on the NETCONF alias?

Thanks,
Rob

---

From: Andy Bierman <[email-masked]>
Date: Tue, 21 Feb 2017 11:30:48 -0800

On Tue, Feb 21, 2017 at 1:33 AM, Robert Wilton <[email-masked]> wrote:

> On Thu, Feb 16, 2017 at 2:18 PM, Alexander Clemm <
> [email-masked]> wrote:
>
> This is interesting.  If you have time, then at some point, please can you
> expand on this idea, perhaps on the NETCONF alias?
>
>
NETCONF does not really support concurrent transactions.
It supports serialized transactions with explicit locks.
More than that is complicated, so it's probably not going to change
any time soon.

Thanks,

Andy