Re: [i2rs] Kathleen Moriarty's Discuss on draft-ietf-i2rs-protocol-security-requirements-07: (with DISCUSS and COMMENT)

[Jeffrey Haas <[e-mail]>]

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