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 <[email protected]> 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 >> <[email protected]> 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: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 <http://www.jacobs-university.de/> -- Best regards, Kathleen _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
