Subject: Re: [Netconf] AD review of draft-ietf-netconf-monitoring-12

From: Mark Scott <[email-masked]>
Date: Mon, 3 May 2010 11:59:20 -0400

Juergen,

Thank you for the comments.

To address your questions:

The "can be used to uniquely..." was meant to state that in combination with the other data it could uniquely identify a session.  I.e. for a user 'Joe' you would not reply with username 'Joe-a' or 'Joe-b'.  You would reply 'Joe' which in combination with other data like session-id and source-host provide uniqueness.  Agreed the text should be clearer.

The "human or machine" was added to explicitly cover various authentication methods such as (human) login credentials vs. (machine) keys in the case of SSH.  It isn't needed though and I will remove it.

For the revised text, if I could suggest one of these:

1.  In the interest of being even more precise:
    "The username is the NETCONF transport protocol identity used      
     by the client to authenticate with the server."

2.  Or perhaps you didn't want to tie specifically to transport for flexibility to accommodate NETCONF security features:
     "The username is the NETCONF identity used by the client to          
      authenticate with the NETCONF server."

My preference is the first one.

If neither was the intent what is the "authenticated identity" referring to in your proposed text?

thank you,
Mark

-----Original Message-----
From: Juergen Schoenwaelder [mailto:[email-masked]] 
Sent: April-30-10 3:35 PM
To: Mark Scott
Cc: [email-masked]; [email-masked]
Subject: Re: [Netconf] AD review of draft-ietf-netconf-monitoring-12

On Fri, Apr 30, 2010 at 07:59:45PM +0200, Mark Scott wrote:
> 
> I will also remove the text suggesting the special handling ('if present') from sec 2.1.4:
> 
> "username (string)
>      The username contains an identifier which can be used to 
>      uniquely identify an individual client (human or machine)."

Now that we have the text in front of us: 'contains an identifier' or
'is an identifier'? what does 'uniquely identify an individual client'
mean? If I have user joe using two clients a and b to access a server
concurrently, will the usernames be "joe-a" and "joe-b"? Likely not,
but the text says "uniquely identify an individual client". And what
does (human or machine) mean? Whether joe relates to a human or a
program, a server won't know. So what about this:

      The username identifies the authenticated identity on which
      behalf a client accesses a server.

I believe this is shorter and more precise.
 
> and from the yang module:
> 
> "leaf username  {
>           type string;
>           description
>             "The username contains an identifier which can
>              be used to uniquely identify an individual client (human
>              or machine).  This is likely to be implementation specific
>              and subject to the security requirements of the device
>              vendor and/or operators,  e.g., an SSH user, a host RSA
>              fingerprint or other identifier deemed acceptable.";
>         }"

Similar changes should be done here if people like my proposal.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: Mark Scott <[email-masked]>
Date: Mon, 3 May 2010 12:14:06 -0400

I don't agree that username should be mandatory.

Per earlier exchanges the monitoring draft will identify this as potentially sensitive data in the security considerations.  Under some circumstances it may not be part of the reply.

Mark

>              fingerprint or other identifier deemed acceptable.";

If we agree that the username is always there, we should add a
'mandatory true;' statement to the leaf.

/martin

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 03 May 2010 18:30:19 +0200 (CEST)

Mark Scott <[email-masked]> wrote:
> Per earlier exchanges the monitoring draft will identify this as potentially
> sensitive data in the security considerations.  Under some circumstances it may
> not be part of the reply.

But whether it is included in the reply b/c of access control policies
(or filtering) is orthogonal to if it is mandatory in the data model
or not.  From a data modelling perspective, it is mandatory, which
means that it is always there -- but that does not mean that it is
included in all NETCONF PDUs.

/martin

---

From: Andy Bierman <[email-masked]>
Date: Mon, 03 May 2010 09:51:28 -0700

> included in all NETCONF PDUs.

yang-12, sec. 7.13.3, para 2:

   If a leaf in the output tree has a "mandatory" statement with the
   value "true", the leaf MUST be present in a NETCONF RPC reply.

No wonder he is confused.

> /martin

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 03 May 2010 19:04:05 +0200 (CEST)

> No wonder he is confused.

Ok, it could be more clear but this is for the output statement.
Section 7.6.5 says that the mandatory statement is a constraint and
covered by the rules in setion 8.  Section 8 says about state data:

  o  If the constraint is defined on state data, it MUST be true in a
     reply to a <get> operation without a filter.

It doesn't explicitly mention access control though...

/martin

---

From: Andy Bierman <[email-masked]>
Date: Mon, 03 May 2010 10:39:58 -0700

> It doesn't explicitly mention access control though...

The text is misleading.
The mandatory-stmt is supposed to mean mandatory-to-implement,
not mandatory-to-be-present-in-the-reply.

The draft cleverly avoids mentioning the fact that
mandatory=false for all config=false nodes
means that those nodes are optional-to-implement
for the server.

A server can advertise the module, and elect to never
include an optional config=false node in an rpc-reply.
The issue has nothing to do with rpc output section vs.
get/get-config <data> output.  It is really about
module conformance.

Andy

---

From: Mark Scott <[email-masked]>
Date: Tue, 4 May 2010 11:07:23 -0400

Thanks for the clarifications but I still interpret this as meaning we'd be expected to put this sensitive state data in an unfiltered reply.

In the absence of standard access control the handling of sensitive data (both state and config) is easier when it is not mandatory.

So my preference remains that this be optional.

Mark

-----Original Message-----
From: Martin Bjorklund [mailto:[email-masked]] 
Sent: May-03-10 1:04 PM
To: [email-masked]
Cc: Mark Scott; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [Netconf] AD review of draft-ietf-netconf-monitoring-12

/martin

---

From: Andy Bierman <[email-masked]>
Date: Tue, 04 May 2010 08:20:26 -0700

> So my preference remains that this be optional.

The conformance for this YANG module is a bit strange.
There are only 3 mandatory-to-implement leafs:

  - /netconf-state/sessions/session-id
  - /netconf-state/sessions/transport
  - /netconf-state/sessions/login-time

There is also a mandatory-to-implement operation (get-schema).

A server can advertise this module and not implement anything
else.  Not sure that is obvious to everyone.

I guess I prefer the SMIv2-style conformance. Although
extra work for the author, it does make it clear what a client
developer can hope to count on from a compliant server.
In this case, nothing worthwhile at all.

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 4 May 2010 19:41:39 +0200

> So my preference remains that this be optional.

I tend to disagree with this. The lack of standard access control does
not mean there is no access control. Furthermore, NETCONF runs over
secure transports so there is no arbitrary access to this data even if
you do not have granular access control.

If we go down the path of making everything optional because of the
lack of access control, where do we end with NETCONF?

/js

---

From: Phil Shafer <[email-masked]>
Date: Tue, 4 May 2010 14:19:37 -0400

>lack of access control, where do we end with NETCONF?

We'll end up right where we started off, where there's an implicit
assumption that the administrator will provision the permissions
of the client to allow the client to perform the actions the
administrator needs for that client to perform.

For example, if you want the client to back up your configuration,
you need to give them full read-only access to the configuration.
If the app is making VPNs, they need write access to all the
appropriate configuration.  If there's a leaf in the VPN config
that the admin does not want the app to turn on, then it doesn't
need write access to that.   What the admin wants to app to do
will dictate the permissions required by that app.

In short, the issue of access control is orthogonal to the needs
of the specific client application.  Either the app can to the work
it needs to do or it cannot.  One doesn't expect to have an application
auto-provision the user that it's going to use to login, right?
Is the value of the ACM to report when something is not configured
correctly?

So the question becomes if you build the all-singing all-dancing
access control solution, what is the target use case?  The VPN
config app?  The admin that's setting up the VPN config app?  Is
there any realistic chance of displacing the CLI as the main avenue
for configuring users and permissions?

Is this a problem domain that we feel will convince people that
NETCONF and YANG are the keys to addressing their configuration
needs?  Are ISPs dying to configure user permissions in an
automated way, especially given their use of RADIUS, etc?

Sorry, I know this is a tangent, but I just don't get it....

Thanks,
 Phil

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 04 May 2010 21:25:10 +0200 (CEST)

Juergen Schoenwaelder <[email-masked]> wrote:
> > Thanks for the clarifications but I still interpret this as meaning we'd be
> > expected to put this sensitive state data in an unfiltered reply.
> > 
> > In the absence of standard access control the handling of sensitive data
> > (both state and config) is easier when it is not mandatory.
> > 

I agree with Juergen.  Marking stuff as optional in the data model b/c
access control or subtree filtering might prune the data from some
replies for some users is wrong.  In this particular case, it seems we
agree that all sessions must have a corresponding user name, thus this
leaf should be marked as mandatory.

/martin

---

From: Mark Scott <[email-masked]>
Date: Wed, 5 May 2010 11:01:07 -0400

OK, consensus is 'username' will be mandatory.

Mark

-----Original Message-----
From: Martin Bjorklund [mailto:[email-masked]] 
Sent: May-04-10 3:25 PM
To: [email-masked]
Cc: Mark Scott; [email-masked]; [email-masked]
Subject: Re: [Netconf] AD review of draft-ietf-netconf-monitoring-12

/martin

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 06 May 2010 08:20:38 +0200 (CEST)

Hi,

> will dictate the permissions required by that app.

Here you argue why it is important to be able to configure access
control, but then your conclusion is that we don't need a standard
data model to do this?  Do you think that it is _better_ with
proprietary data models for access control?   If so, why is access
control special, why do we need standard data models at all?

> auto-provision the user that it's going to use to login, right?

No, just as we don't expect the NETCONF client to set up the initial
mgmt interface so we can talk NETCONF to the box.  But once the basic
interface is there, we do expect NETCONF clients to configure other
interfaces and protocol.  Same for access control.

> automated way, especially given their use of RADIUS, etc?

There is no std way to do NETCONF access control (as in checking data
rules) for RADIUS.  I think you have some vendor-specific way to
handle this, so maybe you should publish that in order to solve this
problem.

/martin

---

From: Phil Shafer <[email-masked]>
Date: Thu, 6 May 2010 09:57:45 -0400

>control special, why do we need standard data models at all?

If you look at this from the service providers point of view, access
control is a solved problem, with lots of existing any deployed
infrastructure.  SPs are comfortable managing users and permissions
in the CLI world, so just saying "a user can't do anything via the
API that they can't do via the CLI" makes them comfortable and
happy.  Telling them we are going to go make a yet another "better"
ACM does not.

In the same way we chose ssh as a transport in order to piggy-back
on the existing and deployed infrastructure, we should be expecting
NETCONF servers to take advantage of the existing and deployed
access control infrastructure.  If the first thing a potential
NETCONF user has to do is understand our custom ACM, this makes a
barrier to entry that won't be easily vaulted.

I know ACM and user management is a safe, familiar problem domain
for network management work, but it's not the problem domain that
will make people go "I gotta have that".  I'd rather we put our
cycles into areas that will make people start to salivate over
NETCONF/YANG solutions.

I want to model how VPNs work, or how a network of OSPF routers
work.  I want a standard model here to that my VPN provisioning
application or my OSPF sanity checker can use my models to talk to
every VPN endpoint or every OSPF router.  I don't see the value in
an application that configures NETCONF access control.  I don't
understand when I would use it, who I would sell it to, or when
they would need it.  I don't see a world where this happens without
the CLI and I don't see much value in making a "shadow world" of
what already exists in the CLI.

Thanks,
 Phil