Subject: [Netconf] NETCONF replace operation

From: Andy Bierman <[email-masked]>
Date: Fri, 12 Feb 2010 18:21:49 -0800

Hi,

I am trying to understand how all the NETCONF operations
behave in the presence of an access control model,
and I don't think copy-config and nc:operation="replace"
do the right thing, according to the current text.

Consider an operation like backup and restore:

1)
  $backup = get-config(source=running)

2)
  copy-config(source=$backup, target=running)

OR
  edit-config(source=$backup, target=running, default-operation=replace)

One would think this is a 'NO-OP' operation, but what
if $backup contains config data that the user is not authorized
to view?   The ACM will silently skip such child nodes
when generating the get-config reply.

When the same user replaces the entire config,
it is not the same as the original.  According
to rules for replace and copy-config, nodes
missing in source will be deleted in target.

Since this user is not authorized to delete the nodes
it wasn't allowed to view, the copy-config and replace
operation should fail will an access-denied error.

Is this a feature, a bug, or vendor-specific?
IMO, it is not clear that default-operation
can ever be 'replace' unless the user has access
to the entire database.

It is not clear that copy-config should be so fragile either.

It is also a security hole to require non-authorized users
to know the exact database nodes they are not authorized to
know about.

(Oh no! Is he trying to get us to discuss access control
requirements on the mailing list?! :-)

Andy

---

From: Johan Rydberg <[email-masked]>
Date: Sat, 13 Feb 2010 09:30:57 +0100

> missing in source will be deleted in target.
I can't say what's right or wrong, just tell you how we do it;

Our implementation starts out with doing a copy of the source
dataset.  It then copies the nodes from the target dataset to the
intermediate dataset that the session has not access to read.

We only have access-control on top-level containers.

---

From: Andy Bierman <[email-masked]>
Date: Sat, 13 Feb 2010 04:04:29 -0800

> intermediate dataset that the session has not access to read.

Agreed.

But this is clearly in violation of the standard.
In a replace operation, any nodes deleted from the source
are supposed to be deleted from the target.
This is not how any real systems actually work,
just how the standard is written.

> We only have access-control on top-level containers.

This isn't very robust.
IMO, the standard needs an ACM which
will allow any node (and all its descendants)
to be isolated.

However, the write access needs to work the same
way as read access for 'wildcard' or 'implied' access.
When I ask for access to /foo/*, I am implicitly
asking for only the child nodes of /foo I am authorized to use,
so child node expansion is post-access-control.

Andy

---

From: Wes Hardaker <[email-masked]>
Date: Tue, 16 Feb 2010 10:57:49 -0800

>>>>> On Fri, 12 Feb 2010 18:21:49 -0800, Andy Bierman <[email-masked]> said:

AB> It is not clear that copy-config should be so fragile either.

AB> It is also a security hole to require non-authorized users
AB> to know the exact database nodes they are not authorized to
AB> know about.

For a long time I've tried to describe the problems associated with
combining large bulk operations (copy-config) and small ones
(edit-config) when combined with things like access control and
locking.  Thanks for finding another example problem!

-- 
Wes Hardaker
Cobham Analytic Solutions

---

From: Andy Bierman <[email-masked]>
Date: Tue, 16 Feb 2010 11:09:10 -0800

> locking.  Thanks for finding another example problem!

I am starting to think that there are some
corner cases where you need a 'root' class of
user with access to everything.  I think the
current NETCONF behavior could be considered OK if this
more restrictive POV was taken.

IMO, the Apache 'virtual host' kind of approach is better,
in order to let the user pretend that a
copy-config or commit is affecting the entire database,
when it is actually just the authorized subset.

BTW, if the NETCONF WG ever starts an access control
model, you might be obliged to help document these
problems! ;-)

Andy

---

From: Wes Hardaker <[email-masked]>
Date: Tue, 16 Feb 2010 15:02:24 -0800

>>>>> On Tue, 16 Feb 2010 11:09:10 -0800, Andy Bierman <[email-masked]> said:

AB> I am starting to think that there are some
AB> corner cases where you need a 'root' class of
AB> user with access to everything.  I think the
AB> current NETCONF behavior could be considered OK if this
AB> more restrictive POV was taken.

The other thing I've been saying for a long time both inside and outside
the IETF: "netconf is a great looking protocol, but it's designed for
all-or-nothing access".  IE, it works great if everyone is root.
-- 
Wes Hardaker
Cobham Analytic Solutions

---

From: Andy Bierman <[email-masked]>
Date: Tue, 16 Feb 2010 15:43:40 -0800

> all-or-nothing access".  IE, it works great if everyone is root.

It is designed so that access control is proprietary
until it is standardized in the future.  Every development cycle,
I (and others) suggest we work on standard access control.
But 5 times in a row, the WG has decided that other things should be
standardized first.

Andy

---

From: Wes Hardaker <[email-masked]>
Date: Fri, 19 Feb 2010 09:23:24 -0800

>>>>> On Tue, 16 Feb 2010 15:43:40 -0800, Andy Bierman <[email-masked]> said:

>> all-or-nothing access".  IE, it works great if everyone is root.

AB> It is designed so that access control is proprietary
AB> until it is standardized in the future.

No, you missed the point: access control will be difficult at best to
get right considering the nature of the protocol operations.  You're
seeing some of the issues now as you've just pointed out some of the
difficulties in getting it right or even workable.  The protocol,
intentionally or not, is designed to trust the operators.  As you've
just shown in another example, copy-config and edit-config are dangerous
command to give to someone that doesn't have global root-level access to
everything.  It's inherit in the protocol.  It's not, necessarily, a bad
thing unless you *want* to do role-based access control.  Many
claim that role-based access control isn't used in the wild and we
shouldn't worry about it anyway because 99% of the use case is "everyone
with access is already root".  Though I agree that's true for many
enterprises, I've definitely seen (many) cases where it isn't true.

---

From: Andy Bierman <[email-masked]>
Date: Fri, 19 Feb 2010 09:44:47 -0800

> enterprises, I've definitely seen (many) cases where it isn't true.

The NETCONF protocol is still a work in progress.
SNMP was published in August 1988.
There wasn't any access control published
(VACM) until January 1998.

By then, everyone was using a 'public' and 'private'
community strings (sometimes with those exact values!).
Operators wanted to partition read-only and read-write access.
That much of SNMP access control was used.

I disagree that it is too late to add access control to NETCONF.
It is not too late to learn that VACM was an over-engineered
disaster and a simpler approach is needed for NETCONF.
It may not be bullet-proof (e.g., poorly documented vendor RPC
changes some underlying config nodes), but it will be a whole
lot better than nothing.

Andy

---

From: Phil Shafer <[email-masked]>
Date: Fri, 19 Feb 2010 13:08:01 -0500

>(VACM) until January 1998.

Sure but when will useful[1] access control for SNMP be available? ;^)

Sorry, couldn't resist, but in trying to solve a single problem in
an exhaustive way, VACM makes something that no one wants.  I hope
we can do better for NETCONF.  Perhaps you would be well served to
start with the 10 biggest ACM-related problem scenarios you want
to solve and work forward from there.

Thanks,
 Phil

1: Feel free to replace "useful" with "real-world", "useable",
or "widely deployed".

---

From: Andy Bierman <[email-masked]>
Date: Fri, 19 Feb 2010 11:18:26 -0800

> to solve and work forward from there.

I just pointed out a 10 year time span between
publication dates.  It is well understood that
VACM is not widely deployed.

The most common form of SNMP access control several
years ago was to simply disable the 'write' community string
with the CLI.  There isn't much need to partition
the read-only data into different access levels.

We should learn from VACM and move on.

Andy

---

From: Phil Shafer <[email-masked]>
Date: Fri, 19 Feb 2010 14:09:58 -0500

>We should learn from VACM and move on.

IMHO we should learn this isn't a problem we will solve in the next
little while and our efforts will be better spent on other issues
where we can bear fruit that people will need and use.

Thanks,
 Phil

---

From: Andy Bierman <[email-masked]>
Date: Fri, 19 Feb 2010 11:37:59 -0800

> where we can bear fruit that people will need and use.

If NETCONF is going to be a real replacement/supplement to CLI
then it needs at least some of the ACM features used in CLI.
Some operators use Radius and TACACS+ for CLI access control.
Some just use 2 types of passwords -- root user and everybody else.

IMO, we should support these CLI access control modes in NETCONF standard.

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 19 Feb 2010 21:05:52 +0100

> all-or-nothing access".  IE, it works great if everyone is root.

I do not see it that way. This is similar to a backup of a Unix system
- if you want a full backup, you better have full access to the
filesystem in question. Still, if you are an ordinary user of a Unix
box, it is still meaningful to do a backup of your home directory and
it is also meaningful to restore it. And yes, you would not expect any
other parts to be included in the backup and you would not expect
other parts you do not have access to to change. Can there be odd
cases? Sure, depends to a large extend how you organize the data; if
the logical unit of work is in a subtree, things get simpler. This is
why having a home directory is a perfectly reasonable file system
organization for most users.

In other words, I believe a meaningful solution can be engineered,
even if it might assume some reasonable organization of the config.
(Even VACM assumes or sometimes requires a meaningful organization,
so this is not even something new.)

/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: Phil Shafer <[email-masked]>
Date: Sat, 20 Feb 2010 10:12:57 -0500

>Some just use 2 types of passwords -- root user and everybody else.

Given that:

(a) operators want something simple
(b) operators already use the CLI
(c) operators use Radius and TACACS+ for CLI access control
(d) operators have their ACM model already set up for the CLI users

the simplest path would be for the on-box NETCONF ACM to mirror the
CLI ACM mechanism.  If you can't touch a config knob via the CLI,
you can't touch it via the API.  If you can't see a config knob in
the CLI, you can't see it in the API.  The operator wants a single
cohesive ACM model for the entire box, not one for the CLI and one
for the API.

If my RANCID login needs read access to the full config, then my
application that performs backups can use this same login without
the operator even needing to understand a different ACM model.

This is my view and the way the XML API in JUNOS has always worked.
This gives operators a level of comfort in using the API, knowing
they are not opening anything that isn't already accessible.

Regardless of how simple a model you think you can build, reusing
what's already there (understood, configured, deployed, working)
makes more sense.  This is the same reasoning that led us to use
ssh instead of rolling our own login mechanism.  ssh (keys, agents,
etc) are already in use, so we couldn't have made anything simpler.

If you see the need for a new ACM model for NETCONF, please feel
free to write a draft with specific ideas.  Until we have something
concrete to discuss, can we please lay this topic to rest (one more
time)?

Thanks,
 Phil

---

From: Phil Shafer <[email-masked]>
Date: Sat, 20 Feb 2010 10:21:52 -0500

Wes Hardaker writes:
>As you've
>everything.  It's inherit in the protocol.

I can't disagree more.  "edit-config" is no more dangerous than
"load" in the CLI.  If the user isn't allowed to delete something
and attempts to, it's an error.  If you want to backup the full
config, then you need to give your user access to the full config.
If you arrange to only backup part of the config, then you'll only
restore that part of the config.  This is not dangerous or an error
in protocol design.

Thanks,
 Phil

---

From: Andy Bierman <[email-masked]>
Date: Sat, 20 Feb 2010 07:49:20 -0800

> concrete to discuss, can we please lay this topic to rest (one more

This applies to any and every new work item, right?
IMO, we should be using the mailing list (like
we are right now) to discuss access control requirements.
You say we have other more important work to do.
Where are the drafts?  What work are you talking about?

IMO, Wes is mostly correct -- the NETCONF standard
has all-or-nothing access, and this is not suitable for
all systems. It's kind of like the IPFIX vendors who
want to run over UDP and do not care that the IETF wants
a more congestion-friendly transport for IPFIX.

Andy

---

From: Wes Hardaker <[email-masked]>
Date: Mon, 22 Feb 2010 07:11:33 -0800

>>>>> On Fri, 19 Feb 2010 09:44:47 -0800, Andy Bierman <[email-masked]> said:

AB> I disagree that it is too late to add access control to NETCONF.

You seem to be in the habit of reading a lot of things from the
statements I make.  Maybe I'm not projecting my thoughts well.  I
suspect, however, that defining access control may require protocol
modifications.
-- 
Wes Hardaker
Cobham Analytic Solutions

---

From: "Bert Wijnen" <[email-masked]>
Date: Fri, 19 Feb 2010 23:55:03 +0100

I have learned from VACM two things:

- We should not over-engineer. We did that with VACM. Nodbody uses/wants it,
  It was mainly a theorethical exercise.
- Even though VACM can be configerd in a simple way (like just read and write acces),
  it is not being used in a simple way... mostly (I think) because we overengineered it and
  so it looks/feels compliated to do even the simple thing.

my 2 cents,
Bert
  ----- Original Message ----- 
  From: Andy Bierman 
  To: Phil Shafer 
  Cc: NETCONF 
  Sent: Friday, February 19, 2010 8:37 PM
  Subject: Re: [Netconf] NETCONF replace operation

  >  Phil

  Andy
  _______________________________________________
  Netconf mailing list
  [email-masked]
  https://www.ietf.org/mailman/listinfo/netconf

------------------------------------------------------------------------------

  Geen virus gevonden in het binnenkomende-bericht.
  Gecontroleerd door AVG - www.avg.com 
  Versie: 9.0.733 / Virusdatabase: 271.1.1/2697 - datum van uitgifte: 02/19/10 08:34:00