Juergen, On Wed, Aug 24, 2016 at 05:24:37PM +0200, Juergen Schoenwaelder wrote: > I fail to understand why it makes a difference whether something is > accessed via pub/sub or in a more traditional way. We need to look at > this from an architectural point of view. And I am a big fan of the > separation of mechanism from policy [1].
The main i2rs use case is pub-sub. I personally have no objection if the use of such a mechanism is made general and is tied to the security properties of the transport rather than the transport type. > The question what can be sent over an insecure transport is a policy > decision of a specific deployment and hard-coding such policies > statically in a data model scares me. SNMP got this piece right since > SNMP left it to the access control subsystem to take the decision and > thus policies could be flexible. In my opinion, SNMP is often improperly secured since the mechanisms provided to lock down sensitive objects puts too much onus on the users to "get it right". This is made particularly difficult by the lack of machine parseable hints in SMIv2 and requires the users to dig through conformance statements, textual conventions and security considerations of the underlying document which may not even be available in the extracted MIBs. I will concede that by starting with "we're secure by default", a number of such headaches with regard to the security of objects is remediated. What is missing is the ability to make it easy to expose objects that have less sensitivity. > If there is a need to document common policies that certain > applications may find useful, then simply write them down as NACM > rules in XML. (The only little issue is that NACM today does not know > whether a request came via a non-secure transport since it assumes > there are only secure transports. But this seems to be fixable and > required to fix if NETCONF indeed introduces non-secure transports.) Presume NACM gained visibility into the security profile of a transport. What would such common policies look like? Where do they get published? Can we make them machine extractable so they can be loaded onto routers as a default profile for a given presumed security level? My suspicion is much of such a profile would simply reduce to "the following nodes are permitted to be covered by the lower security profile". Having markup in the yang to permit extraction by NACM without explicit enumeration in a per-module fashion helps quite a bit. -- Jeff _______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
