Re: [secdir] secdir review of draft-ietf-netconf-partial-lock-09.txt

Andy Bierman <ietf@andybierman.com> Fri, 14 August 2009 15:12 UTC

Return-Path: <ietf@andybierman.com>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0A7373A6D31 for <secdir@core3.amsl.com>; Fri, 14 Aug 2009 08:12:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.488
X-Spam-Level:
X-Spam-Status: No, score=-2.488 tagged_above=-999 required=5 tests=[AWL=0.111, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dKQNOrbE+N0e for <secdir@core3.amsl.com>; Fri, 14 Aug 2009 08:12:46 -0700 (PDT)
Received: from smtp107.sbc.mail.mud.yahoo.com (smtp107.sbc.mail.mud.yahoo.com [68.142.198.206]) by core3.amsl.com (Postfix) with SMTP id E939E3A6CDE for <secdir@ietf.org>; Fri, 14 Aug 2009 08:12:45 -0700 (PDT)
Received: (qmail 81614 invoked from network); 14 Aug 2009 15:12:47 -0000
Received: from unknown (HELO ?192.168.0.10?) (ietf@67.125.157.61 with plain) by smtp107.sbc.mail.mud.yahoo.com with SMTP; 14 Aug 2009 15:12:47 -0000
X-YMail-OSG: ftp8zPkVM1nRxYBaJI2kokGKf5TRXoqH5cu5CMadm.Ip9OIytD1fIxOmUkRhutuK1aJJJ2ZdEyW4q_imBxLZfQYq3RRZQDUOLLLCAbF6pv9Imtn.VwJ.v8NzX8Oq3YTbEFx.nQG7hlILgmUXpwgLkmpoHvtMY8KNkhOUT2nNlcE76Z7Y5Dqatf5QDv0N819thAgi7WPUVEw822M0VY1E8o1ECjMcCvbeRtsNtCanJV3MTfNx223Icz7qcTEZNKw82OPJ49AHj7gBsdvNXmUjZm.spjYhBWei2DDDNUnCaV9C9A0ojrM2xk.4d7m1WRjo_uUye8zTs.xjibubLCpHdV3Cp8DvtusAsl02r5FkhL8R
X-Yahoo-Newman-Property: ymail-3
Message-ID: <4A857EDB.9010803@andybierman.com>
Date: Fri, 14 Aug 2009 08:12:27 -0700
From: Andy Bierman <ietf@andybierman.com>
User-Agent: Thunderbird 2.0.0.22 (X11/20090608)
MIME-Version: 1.0
To: Wes Hardaker <wjhns1@hardakers.net>
References: <AC6674AB7BC78549BB231821ABF7A9AE8E775BCA45@EMBX01-WF.jnpr.net> <016701ca1bf7$400ac480$0601a8c0@allison> <AC6674AB7BC78549BB231821ABF7A9AE8E777C002A@EMBX01-WF.jnpr.net> <4A83FA7D.9040209@bwijnen.net> <AC6674AB7BC78549BB231821ABF7A9AE8E777C00E6@EMBX01-WF.jnpr.net> <4A8430BE.2050701@andybierman.com> <sdk517cuw1.fsf@wes.hardakers.net> <4A847DB3.2050209@andybierman.com> <sd1vne5ufd.fsf@wes.hardakers.net>
In-Reply-To: <sd1vne5ufd.fsf@wes.hardakers.net>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: "draft-ietf-netconf-partial-lock@tools.ietf.org" <draft-ietf-netconf-partial-lock@tools.ietf.org>, "ietf@ietf.org" <ietf@ietf.org>, "secdir@ietf.org" <secdir@ietf.org>
Subject: Re: [secdir] secdir review of draft-ietf-netconf-partial-lock-09.txt
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 14 Aug 2009 15:12:47 -0000

Wes Hardaker wrote:
>>>>>> On Thu, 13 Aug 2009 13:55:15 -0700, Andy Bierman <ietf@andybierman.com> said:
> 
> AB> Oherwise the agent would deadlock.
> AB> discard-changes does not affect the running configuration.
> 
> No, but it does affect the other users notion of changes.  You should
> never be allowed to discard changes that another user has made.
> 

this assumes you have an access control model in mind.
I do too -- they aren't the same.
Without any standards for this, neither of us are wrong.


> AB> It just resets the scratchpad database.
> AB> Why bother applying the ACLs before the edit operation
> AB> is attempted for real?
> 
> user 1: add new important policy configuration
> user 2: discard-changes
> user 1: commit
> 
> Granted, user 1 should be using locks of some kind.
> 

what is the NETCONF 'add new' operation?
step 1 is very unclear.


> To undo changes it's rather important that someone with proper
> authorization to the everything changed (IE, an admin) performs the
> discard.
> 
> Or are you suggesting that one shouldn't ever have access control
> applied to the candidate store in the first place?  (I hope not).
> 

I apply it to the candidate and to running,
except discard-changes, otherwise the agent would deadlock
often and that would be counter-productive
to network operations.

When you start with an awful design premises like
locking should be optional to use, then you might
end up with messy code.  Nothing new there.


> AB> Requiring small embedded devices to serve as robust
> AB> database engines may be more expensive than
> AB> the rest of the code combined.  We are coming from
> AB> an operational environment based on humans using the CLI,
> AB> which has no locking at all.  The globally locked
> AB> candidate "edit, validate, and commit" model
> AB> is way better than anything we ever had in SNMP or CLI.
> 
> If you look at history of operating just about anything, after it gets
> to a point where multiple operators need to scale things up you'll find
> that eventually stuff gets put into a multi-user revision database type
> system.  We are far beyond the point where operators are editing single
> flat-files using "vi" and hitting "save" without any form of revision
> control.  After that point, then went to locking version control systems
> (sccs?  I'm forgetting the early version-control system names).  Then
> people realized that caused huge headaches because the global file
> locking, although it prevented some types of problems, caused a bunch of
> other problems.  Eventually more modern version control systems were
> developed that allowed people to simultaneously edit things and only
> get bothered when conflicts happen.  This was a huge win, ask anyone who
> works with version control systems.
> 
> But now, in this space, we're going back to the older methodologies of
> editing a single file and hoping that two people don't conflict (with or
> without a lock).
> 

again -- when locking is optional to use, the database
is never going to be very good.


> 
> I've said this before, but I'll repeat it now: netconf, from a
> protocol-operation point of view, is designed to work in a
> single-operator type environment.  The instant you add multiple-users
> with or without different roles all these problems come up.  This is
> actually just fine, but it needs to either:
> 
> 1) be fixed so that these problems go away.
> 2) stop being advertised as a multi-operator type solution.
> 

I disagree.
The partial-lock feature is not needed in every environment.
NETCONF supports the SQL-like model (write directly to
the persistent datastore) and that is good enough.
Why does the scratchpad model need to be per-session?
That is nice-to-have, but not important.


> I think "being fixed" is a great long term goal.  But for right now, I'd
> suggest we simple say "this is version 1 at the moment and it is
> currently designed for use by single-operator systems".
> 
> (And it doesn't prevent an external version-control system for being the
> master and pushing the config down.  It just doesn't work on the device
> itself).

Andy