Re: Ever onward

[Phil Shafer <phil@juniper.net>]

Wes Hardaker writes:
>   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/>