Re: Ever onward

[Andy Bierman <abierman@cisco.com>]

At 10:30 PM 2/3/2004, Phil Shafer wrote:
>Wes Hardaker writes:

I agree with Phil.  The issue of partial locks is closed.
We are only supporting global locks in v1.0.  There are 
2 reasons for this:
  1) implementing partial locks is difficult, especially
     across all access mechanisms like CLI, SNMP, HTTP, etc.
  2) identifying a subset of a data model in a standard
     way is future work, not in our charter

I think partial locks will be needed, and should be
future work.  Developers and operators want partial
locks for better provisioning performance, not for
better security.

I don't think we need <steal-lock>.  NETCONF does not 
create any new security holes.  This attack scenario 
falls under the general category of password maintenance.

Andy


>>   Or, social engineering attacks (I've always hated
>>   that term) is trivial these days
>
>This assumes that the attacker won't acquire a user capable of
>locking the entire config.  If not, there's no disadvantage of
>a global lock.
>
>>3) administrator painfully tries to fix all those devices.  Notes:
>>   can't be fixed without a specific tool or protocol to steal the
>>   lock back and delete/modify the compromised user.
>
>The "steal the lock back" program would be a specific tool.
>
>I don't see how does this varies from battling for 'configure
>exclusive' mode in JUNOS or 'enable' mode in IOS.  I don't see this
>as a concern there, nor do I see netconf putting additional tools
>in the attackers toolbox.
>
>>4) If you believe you can beat the race condition that has been
>>   discussed, you should note that the attack could also involve a
>>   DDoS attack against the management station, network, or router in
>>   front of same.
>
>The attack could also involve a forest fire or other natural
>disaster, moving it into the realm of "unrealistic scenario". ;^)
>
>Seriously, there are scenarios where the attackers enjoy an advantage.
>These scenarios are not intrinsic to netconf, nor is their solution
>dependent on <steal-lock>.  Network resources need protection from
>evil doers.  But unless we're adding firewalling and filtering to
>netconf charter, I think most of this is outside the scope of this
>protocol.
>
>>The fundamental problem here is that you're mixing global operations
>>and isolated operations.
>
>No, I want global protection for isolated operations.  I want to
>lock the entire configuration while I make my change so that I don't
>have to worry about interference between my script, your script,
>and the other guy's script.  Even if we're munging different pieces
>of the configuration, calculating, debugging and recovering from
>the interaction is needless heartache.
>
>>You want to provide fine-grained access for
>>some commands and not for others all of which affect the same objects,
>>which is fundamentally a poor security design.
>
>I don't think so.  I want course-grained locking for anything
>affecting the configuration.  I want to avoid bizarre interactions,
>making more robust applications and better network reliability.
>
>>I'm confused why disallowing locks to affect non-accessible objects is
>>a problem?
>
>Because it introduces complexity into a problem that is already
>sufficiently complex.  We need to build a straight-forward solution
>that can handle the most common network management tasks in as
>simple, robust, and dependable a manner as possible.  Adding
>complexity for rare use cases, odd scenarios, and "what if"s is a
>lose.
>
>The most common scenario for netconf will be an application or
>script that hands a chunk of configuration (in XML) to a library
>and tells it to load that configuration onto a specific device.
>The protocol design should maximize that probability that this
>configuration delta can be loaded correctly, or that an appropriate
>error can be returned if it does not.
>
>The second most common scenario will be an application or script
>pulling the entire configuration of the device for archive or
>examination.  The protocol design should maximize the probabilty
>that the configuration can be delivered intact, or that an
>appropriate error can be returned if it does not.
>
>Global locks aid in both scenarios.  They are simple to understand.
>They are simple to implement.  Nuff said?
>
>Thanks,
> Phil
>
>--
>to unsubscribe send a message to netconf-request@ops.ietf.org with
>the word 'unsubscribe' in a single line as the message text body.
>archive: <http://ops.ietf.org/lists/netconf/> 


--
to unsubscribe send a message to netconf-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>