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

[Kathleen Moriarty <[e-mail]>]

Hi Juergen,

Thank you very much for the additional information.  This was very
helpful.  Benoit and I discussed it a bit further on the telechat and
some text changes in the introduction and security considerations
section to provide some of this information for the reader will be
helpful.  I got the explanations and appreciate them and from the
explanations, my discuss questions have been answered and I'll switch
this to a no objection leaving you and Benoit to add the text as
helpful for other readers.

Best regards,
Kathleen

On Thu, Jan 11, 2018 at 2:52 AM, Juergen Schoenwaelder
<[e-mail]> wrote:
> 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/>



-- 

Best regards,
Kathleen