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

Kathleen Moriarty <> Thu, 11 January 2018 16:04 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E7F3012EBB7; Thu, 11 Jan 2018 08:04:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id efZvuZIFxE7F; Thu, 11 Jan 2018 08:04:11 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:400e:c00::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 4BF2912D87E; Thu, 11 Jan 2018 08:04:11 -0800 (PST)
Received: by with SMTP id e3so1961350pfi.10; Thu, 11 Jan 2018 08:04:11 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-transfer-encoding; bh=gfh7RDtUZ/03knTAamkjuxT8ATB46c2ijyhWCuQOKt8=; b=ET0Z+ySmwE5DqzUm/WEgEBxMGs6wOfoOqHSFhHlkh6O7Pq/WagLGpae7S2EzBt6J4i zK5DV6ULRjXcswn0MuUYIEiojmDT8BnGX9V+ywxG36T/1DUxwk34v6lW9vfhAFKPXCN5 1FreRA9qDDQkyoreEaMnvQ+Z6R44XdBZw5pPG1/BIT5ufJXh7e68f4UkpXJn+zK0z0iv WyeiZvLEWG5RE5w3tl3CSBTembO5sPUXAASL0Np+pnkbN/YjHEgXa9fT/s/mBaVXANOL QhIz6qatCe7WALecdmgiG6ik6lPwLGupt+vaX6ic6o/rJKXqmQxYAEwdFOgfGFRE7kgK RX/g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:content-transfer-encoding; bh=gfh7RDtUZ/03knTAamkjuxT8ATB46c2ijyhWCuQOKt8=; b=HrmxGTUDp9ISds+BBn5JdB93xsnoHiYWAJJlg0h+F3Qy5DPlij6MTBtDG+/vgLBgsh n6qyF0gLFIXJnkO5QdXCvuBNzHdFXRbjvephk1Kh+ObahF3bez0RWAQPlMJ/OWTHPqWu TwJXRG9XcIbwT1q5uY9/YeRmXW8nsgQZZIIJGiwbAjklXuYIEYJjhVyS82kZBjJjnqeO 6qyMZMb0sxjRhwR7/1QFMIa3nhtrMRvggPJp42oYlt6sF9NqGtN9MTr6jD0VyinZ7vi3 o6BU8ieYu1h/Hr7V7S4NvGWErKR0oKZRJvi2aRFd6Rmx3KAULiHcUTgx+emPBEMQd3RU IrYw==
X-Gm-Message-State: AKGB3mJWNWMVR6mM9OfEZK/8bzZfbbfY5Dz2w+QLaxelioN4Kbf2wN9P I6JGEpIJ8JFN30Uml5A1Aht7XsPrFQ4ZvxJ36Ok=
X-Google-Smtp-Source: ACJfBouP8Hunp9wn5wE2blj3dC4xKccgSRM/v7PCxsMEWwiryGgBYdzCd+oTHKmZQs/lmBhha/1EwqrxMnhfhYlpUDg=
X-Received: by with SMTP id s7mr18117988pgb.132.1515686650667; Thu, 11 Jan 2018 08:04:10 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Thu, 11 Jan 2018 08:03:30 -0800 (PST)
In-Reply-To: <20180111075218.3tu65mthzlnef3bi@elstar.local>
References: <> <20180110194529.3myrio6vrvsn3jjh@elstar.local> <> <20180111075218.3tu65mthzlnef3bi@elstar.local>
From: Kathleen Moriarty <>
Date: Thu, 11 Jan 2018 11:03:30 -0500
Message-ID: <>
To: Juergen Schoenwaelder <>, Kathleen Moriarty <>, The IESG <>,, Lou Berger <>,,
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <>
Subject: Re: [netmod] Kathleen Moriarty's Discuss on draft-ietf-netmod-revised-datastores-09: (with DISCUSS)
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 11 Jan 2018 16:04:14 -0000

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,

On Thu, Jan 11, 2018 at 2:52 AM, Juergen Schoenwaelder
<> 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
>> <> 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         <>


Best regards,