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

From: Kathleen Moriarty <[email-masked]>
Date: Wed, 10 Jan 2018 11:21:13 -0800

Kathleen Moriarty has entered the following ballot position for
draft-ietf-netmod-revised-datastores-09: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-netmod-revised-datastores/

----------------------------------------------------------------------
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?

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?

Thanks in advance!

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 10 Jan 2018 20:45:29 +0100

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.

> 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.

/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/>

---

From: Kathleen Moriarty <[email-masked]>
Date: Wed, 10 Jan 2018 22:12:02 -0500

Hi Juergen,

Thanks for your quick response.  Inline.

> 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.

> requires discussion of special integrity mechanisms. Perhaps I do not

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.

Thank you,
Kathleen

-- 

Best regards,
Kathleen

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 11 Jan 2018 08:52:18 +0100

Kathleen,

further thoughts inline...

> 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.

> 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

---

From: Kathleen Moriarty <[email-masked]>
Date: Thu, 11 Jan 2018 11:03:30 -0500

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

-- 

Best regards,
Kathleen

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 12 Jan 2018 10:45:00 +0100

Kathleen,

we propose to add this text to the security considerations:

  The origin metadata annotation exposes the origin of values in the
  applied configuration. Origin information may provide hints that
  certain control plane protocols are active on a device. Since origin
  information is tied to applied configuration values, it is only
  accessible to clients that have the permissions to read the applied
  configuration values. Security administrators should consider the
  sensitivity of origin information while defining access control
  rules.

/js

---

From: Kathleen Moriarty <[email-masked]>
Date: Fri, 12 Jan 2018 09:23:28 -0500

Hi Juergen,

>   sensitivity of origin information while defining access control

Thank you, that is very helpful.  Would it also be possible to add
text in the introduction on where the data for these values comes from
(the device itself)?

Best regards,
Kathleen

-- 

Best regards,
Kathleen

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 12 Jan 2018 17:00:20 +0100

> text in the introduction on where the data for these values comes from

The Introduction does not really talk about the origin annotation
details and hence it seems such text would be misplaced or at least
confusing to read.  The definition of origin is in section 5.3.4. This
section starts with:

   As configuration flows into <operational>, it is conceptually marked
   with a metadata annotation ([RFC7952]) that indicates its origin.

Since the whole data flow between datastores resides on a 'device', it
seems clear that the origin values are added by the device itself. And
if any clarification is needed, I think it belongs into 5.3.4 and not
into the Introduction.

/js

---

From: Kathleen Moriarty <[email-masked]>
Date: Fri, 12 Jan 2018 12:51:34 -0500

> if any clarification is needed, I think it belongs into 5.3.4 and not

That sounds good, thank you.

Kathleen

-- 

Best regards,
Kathleen

---

From: Randy Presuhn <[email-masked]>
Date: Fri, 12 Jan 2018 11:37:17 -0800

Hi -

> if any clarification is needed, I think it belongs into 5.3.4 and not

Except when the netmod server is acting as a "front" for other devices.

Randy