Re: [netmod] Kathleen Moriarty's Discuss on draft-ietf-netmod-revised-datastores-09: (with DISCUSS)

[Juergen Schoenwaelder <[e-mail]>]

Kathleen,

further thoughts inline...

On Wed, Jan 10, 2018 at 10:12:02PM -0500, Kathleen Moriarty wrote:
> Hi Juergen,
> 
> Thanks for your quick response.  Inline.
> 
> On Wed, Jan 10, 2018 at 2:45 PM, Juergen Schoenwaelder
> <[e-mail]> wrote:
> > On Wed, Jan 10, 2018 at 11:21:13AM -0800, Kathleen Moriarty wrote:
> >>
> >> ----------------------------------------------------------------------
> >> DISCUSS:
> >> ----------------------------------------------------------------------
> >>
> >> Hello,
> >>
> >> Thanks for your work on this draft.  I'm a little confused with some text in
> >> the draft and have a few questions.
> >>
> >> 1. The introductions says,
> >> "This architectural framework identifies a set of conceptual datastores but
> >>    it does not mandate that all network management protocols expose all
> >>    these conceptual datastores.  This architecture is agnostic with
> >>    regard to the encoding used by network management protocols."
> >>
> >> As such, the data stores could be exposed for some implementations, using
> >> whatever network management protocol (likely NetCONF or RESTCONF).  If this is
> >> the case, why doesn't at least some of the security considerations template
> >> apply for at least secure transport?
> >
> > The security considerations text is IMHO correct. The YANG modules defined
> > in this document do not define any accessible objects. Hence, the security
> > YANG template does not apply.
> 
> Could you make that more clear in the document?  The section from the
> introduction quoted above says it is possible if network management
> protocols expose the datastores.

I am still not sure what you find missing. A datastore is a container
for data.

- The structure and semantics of the data contained in a datastore is
  defined using YANG modules. YANG modules have security
  considerations text that discusses the specifics of the data modeled
  in a YANG module.

- The access to datastores is via management protocols such as NETCONF
  and RESTCONF. These protocols secure the data transport via SSH or
  TLS. In addition there is an access control system (NACM).

Datastores have been with us since the beginning of NETCONF but they
were kind of hardcoded and not extensible and not all data was
contained in datastores. What this document does is essentially to
introduce an architectural framework where all data is contained in
datastores and the set of datastores becomes extensible.

I assume the security template you have been referring to is the
template we use for YANG modules, i.e., the definition of the concrete
objects stored in a datastore. I do not see how this template relates
to the introductory text. The template only applies to the YANG
modules but as explained in the security considerations, these YANG
modules do not define any objects.

> >> 2. Section 5.3.4 - Is there any integrity protection on the origin information?
> >>  If not, can it be added or is there a good reason why it’s not possible?  I
> >> realize these are conceptual models that may or may not be exposed, but if
> >> exposed and used, wouldn’t some integrity protection on this be helpful?
> >
> > Can you clarify what you mean with 'integrity protection' in this
> > context and why you think origin attributes are special? The known
> > published network management protocols all use standard security
> > protocols (SSH and TLS). In general, security mechanisms are protocol
> > specific, I do not see how the architectual definition of datastores
> > requires discussion of special integrity mechanisms. Perhaps I do not
> > understand your concern.
> >
> 
> What I'm wondering here and wanted to discuss was really how the
> information on origin information will be used.  Does this information
> need to be from a source that can be validated?  If so, should there
> be some way to provide a MAC for the values for origin information in
> the data stores?  I am not referring to transport in this second
> question.  Your answer may be an explanation of how the origin
> information will be used that excludes any need for integrity
> protection.  I just wasn't clear on how the information from the data
> stores will be used from the draft.

The origin tells a client where a value in the operational datastore
is originating from. For example, if you see an IP address on an
interface, you can determine from the origin whether the IP address
was configured, learned say via DHCP or provided by the system
(e.g. an auto-configured link-local IPv6 address). One obvious value
is troubleshooting but this information can also help tools to
determine in which way the actual applied config differs from intended
config or what can be responsible for unexpected differences.

The source of the information is the device itself. Can this
information be validated? In general, not. Like pretty much anything
else that is reported by the device. If the device or its
NETCONF/RESTCONF server is lying at a client application, there is not
much we can do about it in general. (For some information, it may be
possible to cross check i.e. whether DHCP leases match up with learned
IP addresses.) But note that we always had to trust information
reported by devices, I do not see what the origin information is any
different. (In fact, in some data models we had special purpose origin
objects, in particular in forwarding table models.) There is no work
as far as I know to introduce some form of cryptographic signatures
for data exposed via NETCONF or RESTCONF.

That all said, and coming back to the first issue, I do think we
could actually say something about the origin annotation. RFC 7952
(which defined the syntax for metadata annotations) says in the
Security Considerations:

   Security implications of a particular annotation defined using this
   mechanism MUST be duly considered and documented in the annotation's
   definition.

So we should perhaps have text discussing the security implications of
the origin annotation. I would have to think a bit more what exactly
that text should say.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: [phone]         Campus Ring 1 | 28759 Bremen | Germany
Fax:   [phone]         <http://www.jacobs-university.de/>