[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Thoughts on NetConf Requirements

Wes Hardaker wrote:
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)?
This runs contrary to the IETF's goal of interoperability. There needs to be at least one mandated transport mapping. Without that one mapping you could have implementations with mutually exclusive mappings.

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?
That would be an inappropriate use of a "MUST NOT" since it does not impact interoperability. In fact it would be a bad idea in any event, as customers would be unable to turn off encryption in order to debug problems.

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.
But the choice typically isn't made based on information content but based on the customer's environment. For instance, some OSS networks don't *want* encryption. All of this having been said, if you would like I don't see any reason why we couldn't standardize an error message indicating that stronger encryption is required.

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.
What has to pass muster is what will be implemented and used. If the IESG mandates functionality that is not used, they will damage the industry by raising the cost of goods and services. However...

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.
All of this argues for ONE transport and that we get the ONE transport right, and that we do away with transport mappings. That way we reduce the number of combinations of potentially insecure configurations of the transport.



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.





How about a simple "permission denied"?  You can do this in your 
implementation without any extension to the protocol.



Eliot







--

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