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

From: "Susan Hares" <[email-masked]>
Date: Wed, 27 May 2015 15:59:12 -0400

Ran and Joel: 

Joel dropped me a note indicating two points on my message to you was
unclear. 

.         The WG has made a decision to have mutual authentication for
client and agent done outside the I2RS protocol, 

.         One example of an out-of-protocol work is AAA.  In our
discussions, most people indicated that a AAA protocol (diameter and radius)
would be used.  It is not mandatory to use these. 

.         NACM is being proposed to link client ID (by Jeff's draft). 

At this point, any contribution to the I2RS requirements should discuss the
pros/cons of the existing proposals. 

Joel - please let me know if I am clear enough on the draft. 

Sue 

From: Susan Hares [mailto:[email-masked]] 
Sent: Wednesday, May 27, 2015 2:53 PM
To: [email-masked]'
Cc: 'Alia Atlas'; [email-masked]'; 'Jeffrey Haas'
Subject: draft-chen-i2rs-identifier-management-00

Ran

I appreciate you taking the time to present your draft at the i2RS interim.
Your draft suggests: 

When the I2RS session is opened, An I2RS Client should advertise to

   an I2RS Agent that the I2RS Client's identifier and priority.  The

   I2RS Client's identifier and priority should be managed by the I2RS

   Agent, and associated with its I2RS session.

It was an important contrast to the existing assumption which Joel pointed
out - that I2RS authentication is done outside of the I2RS protocol.  This
is the agreed upon position in the I2RS architecture document. 

The I2RS architecture has proposed that the other authentication protocols
(For Example AAA's Radius or Diameter) would establish the identity outside
the I2RS protocol.  Most routing people have AAA protocols to establish
identity for other purposes.  The priority would be associated with the
client identity and stored by the I2RS agent per client. 

Your draft provides another alternative the WG should hear during its
deliberation process.  It could be done outside the I2RS protocol as a
simple authentication scheme.  As a WG chair, I appreciate your willingness
to bring an alternate proposal to our current thoughts to help us keep
nimble in our thinking.   During the next 2 weeks, I hope you will continue
to actively participate in the authentication and identity discussion. 

Joel's comments were: 

.         We already have an identity establishing mechanism between the
client-agent. It is the AAA authentication. If we introduce into the I2RS
protocol any in-protocol portion fo identity, we make our lives harder

.         [Ran]: Could you expand upon the question and concepts? 

.         [joel]: If you look at the I2RS mutual authentication in AAA, it
is a identity that other people understand. The client -agent authentication
in the out-protocol use is what people understand. 

.         [Ran]: netconf/restconf have authentication, but it only includes
identity. It does not include the priority.  We can also modify priority.

.         [Joel]: Let me step back into your draft for a moment.  You have a
constraint on the format of Identity and the mappings between identity to
implementation format.  We had that debate, and decided these implementation
mappings are an implementation format. 

.         [Joel]: Let me return to priority, the NACM (as defined in Jeff's
draft) will give us priority associated with a client.  We do not need new
mechanism. 

.         [Ran]: Is this a requirement in the architecture or a restatement
from the WG discussion? 

.         [Sue]: Restatement of the WG discussion on NACM.   The
implementation mapping should be implied in the architecture document.
However we are grateful for your question that makes this clearer. 

.         [Alia]: We choose this direction to maximize re-use of existing
protocols and mechanism for the first release of the I2RS protocol.

.         [Sue]: Is Client priority store in the agent per node? How does it
occur? 

.         [Jeff]: It is stored in the NACM for client, and the client
identity is tagged to a node (E.g. per route).  

This further implies that priority is an attribute that is stored in
   the NETCONF Access Control Model [RFC6536
<https://tools.ietf.org/html/rfc6536> ] as part of a rule-list.
   E.g.:

   +--rw rule-list [name]

      +--rw name     string

      +--rw group*   union

      +--rw rule [name]

         +--rw name string

         +--rw module-name?  union

         +--rw (rule-type)?

         |  +--:(protocol-operation)

         |  |  +--rw rpc-name?  union

         |  +--:(notification)

         |  |  +--rw notification-name?  union

         |  +--:(data-node)

         |     +--rw path node-instance-identifier

         +--rw access-operations?  union

         +--rw action action-type

         +--rw comment?  string

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

 People may respond to this post with other discussion points on the
identity and secondary identity. 

Sue