Re: [i2rs] draft-chen-i2rs-identifier-management-00

["Susan Hares" <[e-mail]>]

Juergen: 

 

I appreciate your patience as I attempt to answer your question in these
three emails: 

http://www.ietf.org/mail-archive/web/i2rs/current/msg02534.html

If the priority is a property of the I2RS client
(this is how I understand the I2RS architecture document), why would
it be configured as part of a NACM rule as suggestd in section 5.2 of
draft-haas-i2rs-ephemeral-state-reqs-00? Jeff's design makes the
priority a property of the scope of a NACM group.

 

http://www.ietf.org/mail-archive/web/i2rs/current/msg02534.html

"My concern is the server and I like to get an answer whether the priority

is a property of a client, a property of a NACM group (of clients), or

whether the priority is a property of a NACM access control rule."

 

http://www.ietf.org/mail-archive/web/i2rs/current/msg02536.html

Thanks for all the details but I am missing an answer to my question.
Shall I repeat it once more?

 

 

Short Answer:   I agree with Andy's message that priority is an
property/attribute of a client.  Alia and Joel state that 1 client has 1 and
only 1 priority.  Only an administrator can change the priority associated
with a client.  No one has specified what occurs when the administrator
changes priority.  Andy's 3 proposals below do not provide a complete
alternate proposal to Jeff proposal.  

 

Recommendation: I recommend we call for consensus for a client having 1 and
only 1 priority, and determine what happens when the administrator can
change the priority.   After we agree, we can focus on suggesting a change
to section 5.2 of draft-haas-i2rs-ephemeral-state-req.  Jeff's statement
"This priority may vary on a per-node or sub-tree basis based for a given
identity" does not seem to have consensus with the I2RS WG.    

 

Longer Answer:    Section 5.2 draft-haas-i2rs-ephemeral-state-reqs  links
this to a NACM that is arbitrating the correct state of data when multiple
clients attempt to manipulate the same piece of data.  This is done via a
priority mechanism with the highest priority winning.
Draft-haas-i2rs-ephemeral-state-req states "this priority may vary on a
per-node or sub-tree basis based for a given identity."  Jeff's  proposal
arises out of section 4.2 in the I2RS architecture document.  This section
states: 

 

An approach to a similar access control problem is defined in the NetConf
Access Control Model (NACM) [RFC6536]; it allows arbitrary access to be
specified for a data node instance identifier while defining meaningful
manipulable defaults.  The identity within NACM [RFC6536] can be specifying
as either a user name or a group user name (e.g.  Root), and this name is
linked a scope policy that contained in a set of access control rules.
Similarly, it is expected the I2RS identity links to one role which has a
scope policy specified by a set of access control rules.  This scope policy
is can be provided via Local Config, exposed as an I2RS Service for
manipulation by authorized clients, or via some other method (e.g.   AAA
service).

 

You can see in this point that the client identity is being linked to the
scope policy controlling read or write.  Section 7.8 points out that
priority "ensures predictability" in write conditions between two I2RS
Clients trying to write data in one agent, or between an I2RS client and the
local config.   Jeff's requirements flow out of this section, but he makes
the assumption that: "This priority may vary on a per-node or sub-tree basis
based for a given identity." (section 5.2) 

 

A consensus call will be issue to check to agree that: 

"A client identity have only 1 priority for all nodes or sub-trees.  If a
client uses multiple TCP sessions each with a different priority, the client
must use multiple identities where each identity is linked to 1 and only 1
priority." 

 ============

 

Andy's Proposals:  Andy's Bierman's suggestion in
http://www.ietf.org/mail-archive/web/i2rs/current/msg02523.html  has been
responded to in other email asking for clarification of the proposal.   

 

Proposal 1: Moving i2rs-priority to client user 

 

  This is a Is a change section 5.2 of draft-haas-i2rs-ephemeral-state-reqs
to move from NACM

 

  +--rw i2rs:i2rs-priority i2rs-priority-type

 

Andy states jeff's change is  optional mode of NACM
(http://www.ietf.org/mail-archive/web/i2rs/current/msg02532.html) . Andy
first indicates Jeff thought the the priority can be on the group-list
(http://www.ietf.org/mail-archive/web/i2rs/current/msg02523.html), but later
he revises his opinion (
http://www.ietf.org/mail-archive/web/i2rs/current/msg02540.html) to state
this must be associated with the client.  He notes Martin mentioned this
first. This placement of priority on client aligns with Joel and Alia's
comments. 

 

Issue regarding this options:  Why are we not using NACM rule list to
protect against multiple write access by lower priority clients? 

1)      If we agree that a client can be linked to a single priority - it
doesn't matter where it is located.  It can be configured by AAA and stored
in a location in the I2RS Agent and the I2RS client. 

 

2)      Andy states in
http://www.ietf.org/mail-archive/web/i2rs/current/msg02530.html

"I don't think the client should provide the priority in request messages.
This is configured on the agent, not requested by the client." IMHO Jeff's
proposal suggests it is passed in out-of-band mechanism from netconf or i2RS
additions to netconf. 

 

3) Mixing client and groups is problematic: 

http://www.ietf.org/mail-archive/web/i2rs/current/msg02540.html states: 

 

" A client can be placed in multiple NACM groups. 
When an edit request is made the client does not
indicate which group should be used.  The server will
pick the highest priority group that the user is a member,
and use that for the priority."  

 

Proposal 2) Adding a i2rs-client to local users table 

 

(from http://www.ietf.org/mail-archive/web/i2rs/current/msg02541.html) 

 

Actually the local user table is in ietf-system.yang:
http://www.netconfcentral.org/modules/ietf-system/2014-08-06#user.659
 
The 'user-name' leaf-list in the NACM 'group' list is populated by
the administrator.  The actual values are irrelevant to NACM.
They can be local users, Radius, or anything else.  Adding a user-name
to this list does not in any way enable the server to accept sessions
from that user.  This is outside the scope of NACM.

 

Issues with this proposal: 

1)      This proposal does not use NACM to enforce the I2RS priority
mechanism.  It requires the I2RS agent to create additional mechanisms to
enforce use of priority to resolve multi-headed control writes. 

 

2)      Andy states in
http://www.ietf.org/mail-archive/web/i2rs/current/msg02530.html

"I don't think the client should provide the priority in request messages.
This is configured on the agent, not requested by the client."  Does this
propose it is passed in an unsecure way? 
 
Section 5.2 of draft-haas-i2rs-ephemeral-state-reqs - implies this is stored
in a NACM rule list on the agent.  How the NACM rule is generated is not
specified IMHO. 
 
 

Proposal 3: Andy states in
http://www.ietf.org/mail-archive/web/i2rs/current/msg02530.html

 
"I don't want to change NETCONF and RESTCONF so that config=true objects use
priority.  Only I2RS should use it." 

 

Comment:  Section 5.2 of draft-haas-i2rs-ephemeral-state-reqs only applies
to config=false.  Is there some wording that

needs to be added to make sure Andy's concern is addressed. 

 
Let me know if you have more questions. 
 
Sue 

 

-----Original Message-----
From: i2rs [mailto:[e-mail]] On Behalf Of Juergen Schoenwaelder
Sent: Friday, May 29, 2015 2:10 AM
To: Susan Hares
Cc: [e-mail]; [e-mail]; 'Andy Bierman'; 'Alia Atlas';
'Jeffrey Haas'; 'Joel M. Halpern'
Subject: Re: [i2rs] draft-chen-i2rs-identifier-management-00

 

On Thu, May 28, 2015 at 08:09:23PM -0400, Susan Hares wrote:

> Andy: 

> 

> Thank you for your question.  Let me precise. 

> 

> Jeff proposes that clients specify the priority mechanism is an attribute
that is stored in the NACM list on the agent (see Section 5.2 as described
in the draft-haas-i2rs-ephemeral-state-reqs-00 (quoted below).   The
client-Agent identities are load in a mechanism which is out-of-band from
the I2RS protocol these values.  Into the Client, the Agent's ID is loaded.
Into the Agent, the valid client's identity is loaded along with the
client's priority.  AAA (Radius/Diameter) is an example of an out-of-band
mechanism to pass the information with.  IMU (in my understanding), the NACM
on the agent is created based on this AAA loading.  The i2rs secondary
identity is loaded via an edit-config mechanism in a config operation (see
section 5.1 of Jeff's document.).  Please let me know if my understanding of
NACM creation based on AAA input is correct.  

> 

 

So I will ask again: If the priority is a property of the I2RS client (this
is how I understand the I2RS architecture document), why would it be
configured as part of a NACM rule as suggestd in section 5.2 of
draft-haas-i2rs-ephemeral-state-reqs-00? Jeff's design makes the priority a
property of the scope of a NACM group.

 

/js

 

-- 

Juergen Schoenwaelder           Jacobs University Bremen gGmbH

Phone: [phone]         Campus Ring 1 | 28759 Bremen | Germany

Fax:   [phone]         < <http://www.jacobs-university.de/>
http://www.jacobs-university.de/>

 

_______________________________________________

i2rs mailing list

 <mailto:[e-mail]> [e-mail]

 <https://www.ietf.org/mailman/listinfo/i2rs>
https://www.ietf.org/mailman/listinfo/i2rs