> On Jan 23, 2017:11:25 AM, at 11:25 AM, Giles Heron <[email protected]>
> wrote:
>
> Hi Sue,
>
>> On 23 Jan 2017, at 14:40, Susan Hares <[email protected]
>> <mailto:[email protected]>> wrote:
>>
>> Giles:
>>
>> Thank you for your comments on ODL and your implementation within ODL.
>> There are two different issues in discussion: guidelines for I2RS Yang
>> modules and the application of these guidelines to the I2RS Yang Topology
>> model. The guidelines for the I2RS Yang Module have three security
>> considerations: a) basic yang considerations, b) I2RS ephemeral state
>> considerations, and c) insecure considerations. Since the topology model
>> does not operate over an insecure transport, the only thing that I believe
>> you are questioning is the "I2RS Yang Models for Secure-Only transports".
>> Let's walk through the draft-ietf-i2rs-yang-l3-topology model
>> (ietf-l3-unicast-topology) and the draft-ietf-i2rs-yang-network-topo models
>> (ietf-network, ietf-network-topology).
>
> i wasn’t the implementer of those models in ODL. But I’ve used them a fair
> bit.
>
> at any rate applying the I2RS security guidelines to the I2RS YANG topology
> model is a bit tricky IMHO as the topology model doesn’t really “fit” with
> the original goal of I2RS (ephemeral configuration of RIBs, ACLs etc. on
> network elements)
I totally agree. The model was and is currently used as just that and
without any of the I2RS semantics. There are examples other than ODL too.
>>
>> The topology model as described in draft-ietf-i2rs-yang-network-topo-10.txt
>> has read/write nodes at the network, link and termination point. Please see
>> the copy of the YHL diagrams below. Therefore, the basic topology model is
>> read-write. The L3 model (draft-ietf-i2rs-yang-l3-topology-08.txt) is read
>> write. Please see a copy of the YHL diagrams below. Therefore, although
>> your implementation is read-only, the approved YANG modules are read-write.
>> This must be considered in the Security considerations section. The basic
>> requirements for I2RS are:
>
> Sure - the models are read/write but ODL’s implementation is generally
> read-only (as I understand it, it’s down to each individual protocol or
> application that leverages the models to decide whether to use them in
> read-write or read-only mode).
>
>> 1) NETCONF over TLS with X.509v3 as mandatory to implement protocol,
>
> most NETCONF implementations I’m aware of use ssh.
+1. Again this is a model. Trying to hoist semantics from I2RS is ill
advised as the model is used in many places that are absent of anything I2RS.
—Tom
> And this is mandatory only per an individual ID, right? Or is it in a WG
> draft now? And do we have WG consensus that this applies to read-only data
> as well as to read-write?
>
>> 2) RESTCONF which uses HTTP over TLS with X.509v3 mutual authentication as a
>> permissible implementation alternative.
>
> again isn’t that only specified as mandatory in an individual ID?
>
>> 3) write contention for two clients writing a node using I2RS priority
>> (linked to I2RS User-ID)
>
> so that one isn’t an issue for read-only implementations…
>
>> If the ODL model does not support writes to these data models, then it would
>> not have to support the priority mechanism to resolve two clients writing
>> one data node.
>
> indeed.
>
> Giles
>
>> A) Basic Yang considerations
>>
>> 1) readable nodes with sensitive data: Kathleen Moriarty and Stephen
>> indicate that the topology data could be considered sensitive read data. A
>> paragraph needs to be added to each draft indicating risks involved in
>> providing this information, and how deployments can keep this data safe.
>> Privacy issues are involved if the topologies are within homes or indicate
>> user's personal devices.
>>
>> If the I2RS mandatory transport is utilized, the data streams utilize mutual
>> authentication, confidentiality, data integrity, and [practical] replay
>> protection for I2RS messages" and support "mechanism that mitigate DoS
>> attacks" and "DDos prevention". This level of security is useful when
>> protecting sensitive data.
>>
>> 2) writeable nodes with sensitive data: Since the topology nodes are
>> writeable, a security considerations needs to consider how these sensitive
>> data nodes will be protected. While ODL does not support writes to any
>> data node, the base models do. Therefore, security considerations must be
>> written here.
>>
>> 3) RPCs: No new RPCs are considered, but providing information on the
>> notification data may be also useful.
>>
>> I2RS YANG Model Security Considerations
>>
>> The requirement for this section is the following information:
>>
>> 1) Indication of deployment requirement for mandatory-to-implement NETCONF
>> (RFC7589) or optional RESTCONF (draft-ietf-netconf-restconf),
>> 2) Discussion of RPCs specific to I2RS control plane data store,
>> 3) NACM policy impacts the read-write state and augmentation of NACM by
>> access control for read/writing of routing protocols (RACM), system
>> information (SACM), and between datastores (config to/from ephemeral state).
>> 4) Discussion of data retrieved from routing protocols, system information,
>> dynamic configuration (dhcp)
>> 5) Any suggestion for operational knobs that control overlay of I2RS
>> configuration over normal configuration and I2RS operational state over
>> other operational state.
>>
>> For the topology data models (ietf-network, ietf-network-topology), the
>> paragraph could be:
>>
>> “The I2RS topology data models (ietf-network, ietf-network-topology) require
>> mutual authentication, confidentiality, data integrity, and [practical]
>> replay protection for I2RS messages. Therefore, there is a
>> mandatory-to-implement transport protocol of TLS (see RFC7589), or an
>> optional transport support of RESTCONF (draft-ietf-netconf-restconf).
>> This data model does not implement any additional RPCs specific to this data
>> model or any notifications.
>>
>> NACM policies may restrict exterior access to this YANG model to simply
>> read-only. For those NACM policies allowing write-access, there is a risk
>> that a write to a topology may create a looping topology or overload a
>> particular node. NACM policies may be augment by routing protocol access
>> control methods (RACM), system data access control methods (SACM), and
>> inter-data store access control mechanisms (DACM). The engagement of this
>> policy should also be control by user policy switches (on/of).
>>
>> For the topology mode, the access to information on interfaces may be
>> control by SACM related to the interface model. Any I2RS topology model
>> termination point configuration which takes augments must take care not to
>> cause fluctuation in the interface state. Dynamic configuration protocols
>> such as DHCP or DHCPv6 may also alter the IP Addresses associated with an
>> interface. DACM related to the inter-datastore policy on the precedence
>> between configuration of interface IP addresses, DHCP/DHCPv6 configuration,
>> or Topology configuration will need to make sure the interface IP address
>> does not cause fluctuations in the system. Deployments may provide general
>> configuration knobs that set the default state for NACM, RACM, SACM and DACM
>> for the topology database. “
>>
>> For the L3 topology data models (ietf-l3-unicast-topology), the paragraph
>> could be:
>>
>> “The I2RS L3 Unicast topology data model (ietf-l3-unicast-topology) require
>> mutual authentication, confidentiality, data integrity, and [practical]
>> replay protection for I2RS messages. Therefore, there is a
>> mandatory-to-implement transport protocol of NETCONF over TLS with X.509v3
>> mutual authentication (RFC7589), or an optional transport support of
>> RESTCONF (draft-ietf-netconf-restconf). This data model does not
>> implement any additional RPCs specific to this data model. This data model
>> does support the following new notifications: l3-node-event, l3-link-event,
>> l3-prefix-event, and termination-point-event. These events provide the
>> information about the changing L3 topology which may provide information
>> regarding key nodes. Since these events are only transported over secure
>> transports that support mutual authentication, confidentiality, data
>> integrity, and [practice] replay protection, the use of this information for
>> DoS of an I2RS agent (aka NETCONF server) requires the mutual authenticated
>> client to be suborned.
>>
>> NACM policies may restrict exterior access to this YANG model to simply
>> read-only. For those NACM policies allowing write-access, there is a risk
>> that a write to a topology may create a looping topology or overload a
>> particular node. NACM policies may be augment by routing protocol access
>> control methods (RACM), system data access control methods (SACM), and
>> inter-data store access control mechanisms (DACM). The engagement of this
>> policy should also be control by user policy switches (on/of).
>>
>> For the L3 topology mode, the access to information on interfaces may be
>> control by SACM related to the interface model. Any I2RS topology model
>> termination point configuration which takes augments must take care not to
>> cause fluctuation in the interface state. Dynamic configuration protocols
>> such as DHCP or DHCPv6 may also alter the IP Addresses associated with an
>> interface. DACM related to the inter-datastore policy on the precedence
>> between configuration of interface IP addresses, DHCP/DHCPv6 configuration,
>> or Topology configuration will need to make sure the interface IP address
>> does not cause fluctuations in the system. The L3 Topology model may also
>> read information from the routing protocols (ospf, isis or others), or write
>> data to the routing protocol. RACM policy should be carefully set so that
>> the routing protocols do not form a place to launch a DoS attack.
>> Deployments may provide general configuration knobs that set the default
>> state for NACM, RACM, SACM and DACM for the topology database. “
>>
>>
>> Hopefully, this makes the suggestion for I2RS security policy a bit more
>> concrete.
>
>> Sue Hares
>>
>>
>> ===========================================================
>>
>> High-level Yang diagrams for draft-ietf-i2rs-yang-network-topo-10.txt
>>
>> +--rw networks
>> +--rw network* [network-id]
>> +--rw network-types
>> +--rw network-id network-id
>> +--ro server-provided? boolean
>> +--rw supporting-network* [network-ref]
>> | +--rw network-ref -> /networks/network/network-id
>> +--rw node* [node-id]
>> +--rw node-id node-id
>> +--rw supporting-node* [network-ref node-ref]
>> +--rw network-ref -> ../../../supporting-network/ +
>> | network-ref
>> +--rw node-ref -> /networks/network/node/node-id
>>
>> module: ietf-network-topology
>> augment /nd:networks/nd:network:
>> +--rw link* [link-id]
>> +--rw source
>> | +--rw source-node? -> ../../../nd:node/node-id
>> | +--rw source-tp? -> ../../../nd:node[nd:node-id=current()/+
>> | ../source-node]/termination-point/tp-id
>> +--rw destination
>> | +--rw dest-node? -> ../../../nd:node/node-id
>> | +--rw dest-tp? -> ../../../nd:node[nd:node-id=current()/+
>> | ../dest-node]/termination-point/tp-id
>> +--rw link-id link-id
>> +--rw supporting-link* [network-ref link-ref]
>> +--rw network-ref -> ../../../nd:supporting-network/+
>> | network-ref
>> +--rw link-ref -> /nd:networks/network+
>> [nd:network-id=current()/../network-ref]/+
>> link/link-id
>>
>> augment /nd:networks/nd:network/nd:node:
>> +--rw termination-point* [tp-id]
>> +--rw tp-id tp-id
>> +--rw supporting-termination-point* [network-ref node-ref tp-ref]
>> +--rw network-ref -> ../../../nd:supporting-node/network-ref
>> +--rw node-ref -> ../../../nd:supporting-node/node-ref
>> +--rw tp-ref -> /nd:networks/network[nd:network-id=+
>> current()/../network-ref]/node+
>> [nd:node-id=current()/../node-ref]/+
>> termination-point/tp-id
>>
>>
>> module: ietf-l3-unicast-topology
>> augment /nd:networks/nd:network/nd:network-types:
>> +--rw l3-unicast-topology!
>> augment /nd:networks/nd:network:
>> +--rw l3-topology-attributes
>> +--rw name? string
>> +--rw flag* l3-flag-type
>> augment /nd:networks/nd:network/nd:node:
>> +--rw l3-node-attributes
>> +--rw name? inet:domain-name
>> +--rw flag* node-flag-type
>> +--rw router-id* inet:ip-address
>> +--rw prefix* [prefix]
>> +--rw prefix inet:ip-prefix
>> +--rw metric? uint32
>> +--rw flag* prefix-flag-type
>> augment /nd:networks/nd:network/lnk:link:
>> +--rw l3-link-attributes
>> +--rw name? string
>> +--rw flag* link-flag-type
>> +--rw metric? uint32
>> augment /nd:networks/nd:network/nd:node/lnk:termination-point:
>> +--rw l3-termination-point-attributes
>> +--rw (termination-point-type)?
>> +--:(ip)
>> | +--rw ip-address* inet:ip-address
>> +--:(unnumbered)
>> | +--rw unnumbered-id? uint32
>> +--:(interface-name)
>> +--ro interface-name? string
>>
>>
>>
>>
>>
>> -----Original Message-----
>> From: Giles Heron [mailto:[email protected]
>> <mailto:[email protected]>]
>> Sent: Monday, January 23, 2017 6:45 AM
>> To: Juergen Schoenwaelder
>> Cc: Susan Hares; [email protected]
>> <mailto:[email protected]>; [email protected]
>> <mailto:[email protected]>; Kathleen Moriarty; The IESG; [email protected]
>> <mailto:[email protected]>
>> Subject: Re: [i2rs] Kathleen Moriarty's No Objection on
>> draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT)
>>
>> ODL does, indeed, implement the topology models, but generally the data in
>> the topology model is operational data, so I’m not sure how that fits with
>> “designed for the I2RS ephemeral control plane data store” - since users
>> don’t write to the models directly (making validation, priority etc.
>> non-issues).
>>
>> > On 23 Jan 2017, at 11:29, Juergen Schoenwaelder
>> > <[email protected]
>> > <mailto:[email protected]>> wrote:
>> >
>> > I thought the topology models are coming more or less from
>> > OpenDaylight. If so, is ODL and I2RS implementation?
>> >
>> > /js
>> >
>> > On Mon, Jan 23, 2017 at 06:04:28AM -0500, Susan Hares wrote:
>> >> Juergen:
>> >>
>> >> Let's focus on your second point. The topology drafts are I2RS drafts
>> >> designed for the I2RS ephemeral control plane data store. How can these
>> >> be
>> >> generic YANG modules when the following is true:
>> >>
>> >> 1) I2RS Data models do not utilize the configuration data store,
>> >> 2) I2RS Data Models do not require the same validation as
>> >> configuration data store,
>> >> 3) I2RS Data models require the use of priority to handle the
>> >> multi-write contention problem into the I2RS Control Plane data
>> >> store,
>> >> 4) I2RS require TLS with X.509v3 over TCP for the
>> >> mandatory-to-implement transport,
>> >>
>> >> Do you disagree with draft-ietf-netmod-revised-datastores? If so,
>> >> the discussion should be taken up with netmod WG list.
>> >> Do you disagree with i2rs-protocol-security-requirements? That issue
>> >> is closed based on IESG approval.
>> >>
>> >> Sue Hares
>> >>
>> >> -----Original Message-----
>> >> From: Juergen Schoenwaelder
>> >> [mailto:[email protected]
>> >> <mailto:[email protected]>]
>> >> Sent: Monday, January 23, 2017 3:39 AM
>> >> To: Susan Hares
>> >> Cc: 'Kathleen Moriarty'; 'The IESG';
>> >> [email protected]
>> >> <mailto:[email protected]>; [email protected]
>> >> <mailto:[email protected]>;
>> >> [email protected] <mailto:[email protected]>
>> >> Subject: Re: [i2rs] Kathleen Moriarty's No Objection on
>> >> draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT)
>> >>
>> >> Susan,
>> >>
>> >> I consider tagging a YANG object statically and universally in the
>> >> data model as "does not need secure communication" fundamentally
>> >> flawed; I am not having an issue with insecure communication in certain
>> >> deployment contexts.
>> >>
>> >> The topology drafts are regular generic YANG models that just happen
>> >> to be done in I2RS - I believe that using the generic YANG security
>> >> guidelines we have is good enough to progress these drafts.
>> >>
>> >> /js
>> >>
>> >> On Thu, Jan 19, 2017 at 01:15:15PM -0500, Susan Hares wrote:
>> >>> Juergen:
>> >>>
>> >>> I recognize that dislike insecure communication. You made a similar
>> >>> comment during the WG LC and IETF review of
>> >>> draft-ietf-i2rs-protocol-security-requirements. However, the
>> >>> draft-ietf-i2rs-protocol-security-requirements were passed by the
>> >>> I2RS WG and approved by the IESG for RFC publication and it contains
>> >>> the non-secure communication. The mandate from the I2RS WG for this
>> >>> shepherd/co-chair is clear.
>> >>>
>> >>> As the shepherd for the topology drafts, I try to write-up something
>> >>> that might address Kathleen's Moriarty's concerns about the topology
>> >>> draft's security issues about privacy and the I2RS ephemeral control
>> >>> plane
>> >> data
>> >>> store. I welcome an open discussion on my ideas
>> >>> (https://datatracker.ietf.org/doc/draft-hares-i2rs-yang-sec-consider
>> >>> <https://datatracker.ietf.org/doc/draft-hares-i2rs-yang-sec-consider>).
>> >> The
>> >>> yang doctor's YANG security consideration template
>> >>> (https://trac.ietf.org/trac/ops/wiki/yang-security-guidelines
>> >>> <https://trac.ietf.org/trac/ops/wiki/yang-security-guidelines>) and
>> >>> the privacy related RFCs (RFC6973) note that some information is
>> >>> sensitive.
>> >>> Hopefully, this document extends these guidelines to a new data store.
>> >>>
>> >>> Cheerily,
>> >>> Sue Hares
>> >>>
>> >>> -----Original Message-----
>> >>> From: Juergen Schoenwaelder
>> >>> [mailto:[email protected]
>> >>> <mailto:[email protected]>]
>> >>> Sent: Thursday, January 19, 2017 10:34 AM
>> >>> To: Susan Hares
>> >>> Cc: 'Kathleen Moriarty'; 'The IESG';
>> >>> [email protected]
>> >>> <mailto:[email protected]>; [email protected]
>> >>> <mailto:[email protected]>;
>> >>> [email protected] <mailto:[email protected]>
>> >>> Subject: Re: [i2rs] Kathleen Moriarty's No Objection on
>> >>> draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT)
>> >>>
>> >>> For what it is worth, I find the notion that data models may be
>> >>> written for a specific non-secure transport plain broken. There is
>> >>> hardly any content of a data model I can think of which is generally
>> >>> suitable for insecure transports.
>> >>>
>> >>> Can we please kill this idea of _standardizing_ information that is
>> >>> suitable to send over non-secure transports? I really do not see how
>> >>> the IETF can make a claim that a given piece of information is never
>> >>> worth protecting (= suitable for non-secure transports).
>> >>>
>> >>> Note that I am fine if in a certain trusted tightly-coupled
>> >>> deployment information is shipped in whatever way but this is then a
>> >>> property of the _deployment_ and not a property of the _information_.
>> >>>
>> >>> /js
>> >>>
>> >>> On Thu, Jan 19, 2017 at 09:28:14AM -0500, Susan Hares wrote:
>> >>>> Kathleen:
>> >>>>
>> >>>> I have written a draft suggesting a template for the I2RS YANG
>> >>>> modules
>> >>> which are designed to exist in the I2RS Ephemeral Control Plane data
>> >>> store
>> >>> (configuration and operational state).
>> >>>>
>> >>>> Draft location:
>> >>>> https://datatracker.ietf.org/doc/draft-hares-i2rs-yang-sec-consider
>> >>>> <https://datatracker.ietf.org/doc/draft-hares-i2rs-yang-sec-consider>
>> >>>> /
>> >>>>
>> >>>> I would appreciate an email discussion with the security ADs,
>> >>>> OPS/NM ADs,
>> >>> and Routing AD (Alia Atlas). I agree that this I2RS YANG data model
>> >>> (L3) and the base I2RS topology model should both provide updated
>> >>> YANG Security Considerations sections. I would appreciate if Benoit
>> >>> or you hold a discuss until we sort out these issues.
>> >>>>
>> >>>> Thank you,
>> >>>>
>> >>>> Sue
>> >>>>
>> >>>> -----Original Message-----
>> >>>> From: Kathleen Moriarty [mailto:[email protected]
>> >>>> <mailto:[email protected]>]
>> >>>> Sent: Wednesday, January 18, 2017 9:44 PM
>> >>>> To: The IESG
>> >>>> Cc: [email protected]
>> >>>> <mailto:[email protected]>; [email protected]
>> >>>> <mailto:[email protected]>;
>> >>>> [email protected] <mailto:[email protected]>; [email protected]
>> >>>> <mailto:[email protected]>; [email protected] <mailto:[email protected]>
>> >>>> Subject: Kathleen Moriarty's No Objection on
>> >>>> draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT)
>> >>>>
>> >>>> Kathleen Moriarty has entered the following ballot position for
>> >>>> draft-ietf-i2rs-yang-l3-topology-08: No Objection
>> >>>>
>> >>>> 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
>> >>>> <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-i2rs-yang-l3-topology/
>> >>>> <https://datatracker.ietf.org/doc/draft-ietf-i2rs-yang-l3-topology/>
>> >>>>
>> >>>>
>> >>>>
>> >>>> -------------------------------------------------------------------
>> >>>> -
>> >>>> --
>> >>>> COMMENT:
>> >>>> -------------------------------------------------------------------
>> >>>> -
>> >>>> --
>> >>>>
>> >>>> I agree with Alissa's comment that the YANG module security
>> >>>> consideration
>> >>> section guidelines need to be followed and this shouldn't go forward
>> >>> until that is corrected. I'm told it will be, thanks.
>> >>>>
>> >>>>
>> >>>>
>> >>>> _______________________________________________
>> >>>> i2rs mailing list
>> >>>> [email protected] <mailto:[email protected]>
>> >>>> https://www.ietf.org/mailman/listinfo/i2rs
>> >>>> <https://www.ietf.org/mailman/listinfo/i2rs>
>> >>>
>> >>> --
>> >>> 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/
>> >>> <http://www.jacobs-university.de/>>
>> >>>
>> >>
>> >> --
>> >> 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/
>> >> <http://www.jacobs-university.de/>>
>> >>
>> >
>> > --
>> > 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/
>> > <http://www.jacobs-university.de/>>
>> >
>> > _______________________________________________
>> > i2rs mailing list
>> > [email protected] <mailto:[email protected]>
>> > https://www.ietf.org/mailman/listinfo/i2rs
>> > <https://www.ietf.org/mailman/listinfo/i2rs>
> _______________________________________________
> i2rs mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/i2rs
_______________________________________________
i2rs mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/i2rs
