Subject: [Netconf] 2 more confirmed-commit details

From: Andy Bierman <[email-masked]>
Date: Sun, 27 Sep 2009 10:33:30 -0700

Hi,

IMO, the confirmed-commit procedure is really fuzzy wrt/
applying access control policy.  Without any standard ACM,
it may be too out of scope to consider, but I'll try anyway:

1) What is the username is effect during the rollback?

   I assumed the rollback edits are done in the ACM context
   of the original user who started the confirmed-commit.
   Is this correct?

2) incremental edits blocking rollback

  If session 1 started the confirmed-commit, but session 2
  extended it by adding some changes, it is possible for
  the rollback edits to touch subtrees that S2 was authorized
  to write, but not S1.  This should not cause the entire rollback
  to fail, but the S2-edits cannot be undone.

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 28 Sep 2009 09:09:25 +0200 (CEST)

>   to fail, but the S2-edits cannot be undone.

Or maybe some of the S2-edits are undone, i.e. the ones that S1 has
access to?  What if the resulting db is not valid at this point?

If this is how extended confirmed commit is supposed to work with
access control, then I prefer to remove the extended confirmed commit
feature.  Logically, when the first confirmed commit is issued, the db
is checkpointed.  Extra commits from this point does not affect the
checkpoint.  If the box reboots it will boot from the checkpointed db.

But is this really a logical consequence of having an ACM?  The
scenario is:

  S1: edits candidate, does confirmed commit
  S2: edits candidate, does commit
  S1: reboots or terminates the session
  S2's changes are now gone -- this is the potential ACM violation

Consider a similar case, w/o candidate:

  S1: edits running, and does copy-config to startup
  S2: edits running
  S1 reboots the box
  S2's changes are now gone - is this a ACM violation??

/martin

---

From: Andy Bierman <[email-masked]>
Date: Mon, 28 Sep 2009 01:03:26 -0700

> checkpoint.  If the box reboots it will boot from the checkpointed db.

I'm just guessing at how it should work.
I don't like the extend-mode with changes.
It is not intuitive how the recovery works.
I'm not sure access control actually does work
in all recovery modes.

NETCONF database transactions without locking
could be considered a garbage-in/garbage-out corner-case.
IMO, the server should not be bothered to try very
hard to sort out the wreckage and undo the garbage edits.

One approach is to say that the server (superuser) is
running the rollback and discard-changes, so it always wins,
and therefore the rollback wins over the new edits.

>   S2's changes are now gone -- this is the potential ACM violation

A rollback gets triggered when commit-timeout expires as well.
It is this rollback edit on the altered subtrees that I
am wondering about.  The reboot rollback falls out for
free because the NV-store never happened, so the previous NV-store
contents are still in place.

>   S2's changes are now gone - is this a ACM violation??

You get what you get when you interleave database transactions
without any locking.  S2 should have known not to commit
anything while S1 had a confirmed-commit running. :-)
(Of course, this is no way for S2 to know that in
the standard, so use locking or be sorry.)

If S2 locks candidate or running, then it could be argued that
S1 still wins, because the server promised to execute a
confirmed-commit before it gave out the lock.

It would be nice to clear confirmed-commit in 4741bis.
You never realize how under-specified something is
until you try to implement it ;-)

Andy

---

From: WashamFan <[email-masked]>
Date: Mon, 28 Sep 2009 22:46:37 +0800

Hi,

----- Original Message -----
From: Andy Bierman <[email-masked]>
Date: Monday, September 28, 2009 4:06 pm
Subject: Re: [Netconf] 2 more confirmed-commit details
To: Martin Bjorklund <[email-masked]>
Cc: [email-masked]

> hard to sort out the wreckage and undo the garbage edits.

+1
The last para in 8.4.1, RFC4741 points it out:

   For shared configurations, this feature can cause other configuration
   changes (for example, via other NETCONF sessions) to be inadvertently
   altered or removed, unless the configuration locking feature is used
   (in other words, the lock is obtained before the edit-config
   operation is started).  Therefore, it is strongly suggested that in
   order to use this feature with shared configuration databases,
   configuration locking should also be used.

> confirmed-commit before it gave out the lock.

I don't think it is clear that server should execute a confirmed-commit
before it gave out the lock in current text, could you point it out
for me

washam

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

---

From: Andy Bierman <[email-masked]>
Date: Mon, 28 Sep 2009 08:17:24 -0700

> before it gave out the lock in current text, could you point it out

As I said in the email, the draft is unclear
and it doesn't say anything whatsoever about
access control or rollback when locked by another
session.

We are trying to reach consensus on the need
for any new text.

Andy

---

From: Wes Hardaker <[email-masked]>
Date: Mon, 28 Sep 2009 09:05:41 -0700

>>>>> On Mon, 28 Sep 2009 01:03:26 -0700, Andy Bierman <[email-masked]> said:

AB> One approach is to say that the server (superuser) is
AB> running the rollback and discard-changes, so it always wins,
AB> and therefore the rollback wins over the new edits.

That's not a good solution and provides a huge number of problems as
well.

The correct thing to do, if you've decided that commit/rollback features
are unsafe without a lock, is to require a lock in order to use them.

As I've said before, the biggest issues I have with netconf and security
is that it's a mix of both atomic and subatomic operations that conflict
when you try to apply it to scalable multi-operator scenarios.  To get
around the core issues you need to either treat the whole thing as a
single-user-at-a-time solution (locking, copy-config, commit, rollback,
etc) or a proper multi-user-at-a-time solution (partial-lock, patch,
patch-commit, etc but no global copy-config).  Right now there is a mix
of two entirely different types of operations.

-- 
Wes Hardaker
Cobham Analytic Solutions

---

From: Andy Bierman <[email-masked]>
Date: Mon, 28 Sep 2009 09:42:23 -0700

> of two entirely different types of operations.

The NETCONF WG decided locking should be optional-to-use,
so your suggestion won't work.

I am not going to worry too much about GIGO.
The standard doesn't have any access control at all,
so every server can do what they want.

SNMP never had any locking at all, and that
hasn't seemed to cause many problems, or it would have
been forced to add locking at some point.

Locks are like traffic lights.  If you ignore them,
you rely on random events to prevent collisions.
IMO, the standard should not waste a lot of effort
describing how all servers must clean up the wreckage
of bad database usage.

Andy

---

From: WashamFan <[email-masked]>
Date: Tue, 29 Sep 2009 13:21:08 +0800

>  so your suggestion won't work.

Sorry, I don't think so. global lock is mandatory-to-implement
and should be used in appropriate case. Actually, I totally agree
with Wes that use lock when you think it is neccessary.

>  been forced to add locking at some point.

I don't think locking means much to SNMP alone. Cause
SNMP SET seldom configures the whole box but does
set some features. But locking makes sense to SNMP
where let's say, Netconf, CLI, even Cops and SNMP
reside in the same device and all be active. Actually we
had done this effort by draft-fan-meng-snmp-lock

washam

---

From: Andy Bierman <[email-masked]>
Date: Mon, 28 Sep 2009 22:48:08 -0700

> with Wes that use lock when you think it is neccessary.

Where does 4741bis say that clients MUST use locking?
Or where does it say the server is allowed to
return an error for edit-config, commit, etc.
if the database is not locked and the PDUs are
well-formed, and authorized?

If the operator knows nobody else will be editing the database
over some known time interval, then locking will not matter.
It is up to the operator to decide to use locking, not the server.

> had done this effort by draft-fan-meng-snmp-lock

there is nothing in SNMP to prevent one NMS
from setting a MIB object at the same time as another NMS.
It has nothing to do with the number of access methods,
but rather the number of concurrent database writers.

Andy

---

From: WashamFan <[email-masked]>
Date: Tue, 29 Sep 2009 14:05:49 +0800

>  >>  > when you try to apply it to scalable multi-operator scenarios.  
> To 
>  >> get
>  >>  > around the core issues you need to either treat the whole thing 
> as 
>  >> a
>  >>  > patch-commit, etc but no global copy-config).  Right now there 
> is a 
>  >> mix
  
>  It is up to the operator to decide to use locking, not the server.

That is what I was trying to say. I just meant, locking is chosen
by the client, there is no responsibility for the server  to guarantee
atomicity of <confirmed-commt>, <rollback> transaction

>  but rather the number of concurrent database writers.

Agreed. But I am not sure how it matters in reality. Since Netconf
defines locking which would imapct SNMP, locking problem to SNMP
might arise in this case. Currently, this issue does not concern people.

washam

---

From: Wes Hardaker <[email-masked]>
Date: Tue, 29 Sep 2009 06:08:55 -0700

>>>>> On Mon, 28 Sep 2009 09:42:23 -0700, Andy Bierman <[email-masked]> said:

AB> The NETCONF WG decided locking should be optional-to-use,
AB> so your suggestion won't work.

I certainly understand that view point.  But does that mean that no
future feature can depend on or require it to be used?  Though in terms
of commit/rollback, it's not exactly a "future" feature.

AB> I am not going to worry too much about GIGO.
AB> The standard doesn't have any access control at all,
AB> so every server can do what they want.

Designing a protocol without worrying about access control, whether it
exists at the moment or not, will certainly insert protocol operations
that turn out to be safe when access control is eventually applied to
the problem.  I fail to see how this is a safe attitude to take.

AB> SNMP never had any locking at all, and that
AB> hasn't seemed to cause many problems, or it would have
AB> been forced to add locking at some point.

SNMP was a much more simple protocol that didn't have commit and
rollback either.  If it did, similar issues may have resulted.  SNMP
didn't have notions of global config that you could copy around.  It
never had to worry about the fact that different users might need to
issue copy commands to move entire config sets around that they may not
even have access rights to modify let alone view.

It would certainly be easier if you simply declared that netconf was
never to have any sort of access control and was to be treated as a
root-only protocol, but no one has ever tried to declare that and in
fact many people have hinted (yourself included) that access control is
an eventual goal.

AB> Locks are like traffic lights.  If you ignore them,
AB> you rely on random events to prevent collisions.

Which is why laws exist saying you can't do that.  Somehow, though, in
NETCONF you're fine with traffic lights being optional and fine with
them being merely advisory.

AB> IMO, the standard should not waste a lot of effort describing how
AB> all servers must clean up the wreckage of bad database usage.

The issue, to me, isn't wreckage of bad data.  It's how such oddities of
the protocol can be used by nefarious people to achieve goals beyond
their assigned capabilities.

If you truly believe that netconf shouldn't have access control, then
you should write a draft that defines authentication = authorization and
see if it's accepted.  Maybe it'd be accepted as the best path forward
since it would certainly remove a lot of the issues that come up.  At a
cost of course.

---

From: Phil Shafer <[email-masked]>
Date: Tue, 29 Sep 2009 09:42:44 -0400

>them being merely advisory.

I see it more as arguing over traffic lights in, say, 1910, when
the bigger issues are getting the cows out of the road and making
sure that all the car makers are using the same fuel.  If you can't
get the cows out of the road, you aren't going anywhere, and if you
can't get the fuel, your model-T will end up being towed by
a horse:

  http://www.strangecosmos.com/images/content/117027.jpg

or worse:

  http://farm4.static.flickr.com/3537/3418988849_3e62a077ea.jpg

>since it would certainly remove a lot of the issues that come up.  At a

I don't think anyone is suggesting this.  I think the understanding
is that the server has an access control mechanism that allows
differing users to read and write differing parts of the configuration.
How this is specified and how it is learned does not seem sufficiently
interesting to anyone to push them into making a draft and getting
the working group behind it.  IMHO there are more important issues
ahead of us.

To keep with the auto metaphor, this would be like trying to set
up the DMV before people can drive cars down the road.

Thanks,
 Phil

---

From: Andy Bierman <[email-masked]>
Date: Tue, 29 Sep 2009 07:32:06 -0700

> since it would certainly remove a lot of the issues that come up.  At a

I personally tried several times to get the NETCONF WG
to work on access control.  It has always been a very low
priority.

There isn't any standard data to configure yet,
so a standard way to partition access to the
data that doesn't exist yet is not going to be
a high priority.

Andy

---

From: Andy Bierman <[email-masked]>
Date: Tue, 29 Sep 2009 08:57:28 -0700

>>>>>> On Mon, 28 Sep 2009 09:42:23 -0700, Andy Bierman <[email-masked]> said:
...

> even have access rights to modify let alone view.

SNMP has the same sort of database validation as NETCONF/YANG,
except it isn't really formalized.

SNMP has VACM, which is optional-to-use, and was not added
to SNMP until well after the protocol was in use with
some standard content.

We are supposedly in the NETCONF access control requirements
gathering phase right now.  There are some proprietary
ACMs, and maybe more along the way.  This should help
lead to better understanding of the requirements.

There may be renewed interest in a standard ACM after
YANG is published.  I prefer to see some core data structures
to manage first (or concurrently) such as interfaces and system
groups.

> fact many people have hinted (yourself included) that access control is

We didn't do that for SNMP in the early days of SNMP.
First the WG has to agree on the requirements,
and that isn't going to happen right away.

Andy

---

From: "Bert (IETF) Wijnen" <[email-masked]>
Date: Wed, 30 Sep 2009 09:12:50 +0200

I believe the below discussion has turned into the topic of Access Control.

It would be best if we all try to make sure that emai subject lines 
cover the content of
the email. That will make it easier if we need to go through email 
threads later.

Thanks,
Bert

---

From: Wes Hardaker <[email-masked]>
Date: Wed, 30 Sep 2009 09:39:05 -0700

>>>>> On Tue, 29 Sep 2009 08:57:28 -0700, Andy Bierman <[email-masked]> said:

AB> SNMP has the same sort of database validation as NETCONF/YANG,
AB> except it isn't really formalized.

I disagree, they're quite different.  But I'm not sure it's relevant.

AB> There may be renewed interest in a standard ACM after
AB> YANG is published.  I prefer to see some core data structures
AB> to manage first (or concurrently) such as interfaces and system
AB> groups.

Getting back to the confirmed-commit issue (Thanks Bert), my point
wasn't to argue about access control and how it might work or whether
it'll exist.  My point was it seems like you're designing protocol
features while simultaneously saying "we don't care how this operation
works under multi-role models with different access, because there is no
access control so we don't have to care".  That sort of attitude will
certainly end up developing protocol operations that will either fail to
work when proper access control is in place, or worse, will prevent an
access control method to developed.

Consider:

  A: start confirmed commit
  A: edit A1 in candidate
  B: edit B1 in candidate
  A: kills-own-session
  B: edit B2 in candidate
  B: commit

Previously you stated:

This is the statement that I don't think is safe.  If you want to just
say "we don't care about access control because there isn't any" then at
some point you'll have to care (maybe?), and I wouldn't be surprised if
some of the existing commands will be incompatible with the desired
access control because no one thought about them at the same time.

---

From: Andy Bierman <[email-masked]>
Date: Wed, 30 Sep 2009 10:13:00 -0700

>   A: start confirmed commit

big deal.
we can all come up with 1000 different ways that
the global candidate or running databases can
be edited concurrently with bad or unintended results.

Confirmed-commit is kind of a corner-case.
The global database is shared.  If you don't
want to share, use locking.

> access control because no one thought about them at the same time.

I should be more clear.
I am using access control, and trying to design
a workable system.  The standards documents provide part of
the solution, but not all of it.  That is rather common.

It is not my opinion that access control should be optional,
let alone ignored by the standard.  But I sure don't
want something as over-engineered and awful as VACM,
so proprietary ACMs are OK for now.  Let people prove
they know how to manage NETCONF content access control
with complete, yet simple solutions.  The WG should
start with working solutions, not from scratch,
and finish in 1 year, not 3 years.

By 'we' in 'we don't have to worry about robust protocol
operations in the presence of an ACM', I mean the IETF.
I agree with you that this is kind of clueless, but the
WG consensus has been rather consistent on this point.
Look at all the work items that have been chosen instead
of an ACM, and you get the impression that this aspect of
security is just not relevant at this time.

I agree with Phil only because we need standard content
before anything else.  Standardizing an ACM now would
be based entirely on experience with proprietary data models.
This may not completely reflect how standard YANG modules
are designed.  Let's see if any interoperability can
be achieved on some core system content first.

Andy