Re: Thoughts on NetConf Requirements

[Wes Hardaker <wjhns1@hardakers.net>]

>>>>> On Mon, 16 Jun 2003 13:43:11 -0700, Andy Bierman <abierman@cisco.com> said:

Andy> This is debatable. IMO, the WG should only standardize
Andy> transport mappings that meet our security requirements.

Ok, so all transport mappings that will be created will be considered
equal (and equal for all points of time in the future)?  Are you going
to make a MUST requirement that all transports be configurable with
only AES128 or better encryption and that DES (or no-encryption)
transport configurations be a MUST NOT?

Andy> If an operator wants to do configuration over a non-secure
Andy> protocol, then that's their decision.  This is how CLI
Andy> configuration is done today.  Both telnet and SSH transports
Andy> are provided and the user can choose which one to use.

And attackers certainly know which they'll target if there is no
differentiation about what can be done over what protocol.

Andy> This is a recipe for over-engineering the netconf protocol.  We
Andy> should engineer for the working protocol scenario, not how we
Andy> may hack around unforeseen bugs in auxiliary protocols later on.

I'm not trying to get you to throw arbitrary stuff into the process.
Clearly spelling out something like "this document assumes that all
transports which carry the netconf protocol have been appropriately
configured and that all operating transports are functioning at a
security level acceptable to the security policies within the deployed
network." in the security considerations section may pass the IESG
review.  Maybe not.

All I'm saying is that if you have transports A, B, and C all leading
to protocol P and you don't do any verification of how the data
arrived then you have 3 points of failure.  Assuming that they must
all be configured appropriately and that no management application
will ever send inappropriate requests over an insecure channel leaves
the burden of deciding what is "appropriate communication" to the
management application.  Its a defendable position, but it means that
the operators fielding the deployed devices must be more knowledgeable
and security conscious because it means they must know which
management software should be used for which tasks and there is no way
they can configure their networks operational policy to double check
their operational habits.  It also means they must implicitly trust
the management software not to make mistakes and accidentally send the
wrong requests over the wrong transports.

>> The data itself can be critical.  Policy and security data, for
>> example, may dictate the firewall policies within my network or
>> critical security information (keys, etc).  I certainly want to
>> restrict who can view that data and over what transport its acceptable
>> to view it.

Andy> This is just more authorization rules.  You set up access rights
Andy> based on (user, operation, content). Firewall policies are just
Andy> different content from a management POV.

Different content that requires a greater level of protection than
interface information, for example.  It's impossible, in your model,
to disallow "user" from sending the firewall rules over an insecure
transport.  IE, there is nothing to prevent a user from requesting the
keys to the kingdom across an insecure transport.

-- 
"In the bathtub of history the truth is harder to hold than the soap,
 and much more difficult to find."  -- Terry Pratchett

--
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/>