Juergen: There are two I2RS drafts related to security: draft-ietf-i2rs-protocol-security-requirements and draft-ietf-i2rs-security-environment-reqs-02. The draft-ietf-i2rs-protocol-security-requirements has pass IESG review and is waiting for the RFC editor. The draft-i2rs-security-environment-reqs-02.txt has not passed WG LC. You are correct that draft-hares-i2rs-yang-sec-consider-00.txt is an individual draft. This individual draft is also based on draft-ietf-netmod-ietf-revised-datastores-00.txt.
The impetus for this individual draft (draft-hares-i2rs-yang-sec-consider) was the DISCUSS by the security ADs regarding security consideration section in two drafts: draft-ietf-i2rs-yang-network-topology and draft-ietf-i2rs-yang-l3-topology-08.txt. The draft indicates the following 6 areas where the I2RS protocol and environment security requirements differ: 1) mandatory-to-implement transport layer, 2) priority and secondary opaque identifier, 3) different data store, 4) different validations in I2RS control plane data store, 5) different NACM policy, and 6) optional insecure protocol. None of these are handled in the current YANG security considerations template. Items 1, 2, and 5 are specified in draft-ietf-protocol-security-requirements plus SEC-ENV-REQ-8 AND SEC-ENV-REQ-9 from the draft-i2rs-security-environment-reqs-02.txt. Item 5 arises out of SEC-ENV-REQ-05 and SEC-ENV-REQ-06 in the draft-ietf-i2rs-security-environment-reqs-02.txt. Items 3 and 4 arise out of the draft-ietf-netmod-revised-datastores-00.txt. I welcome a discussion on whether this individual draft truly represents the content of these 3 drafts. The individual draft tries to provide the information from the draft-ietf-i2rs-protocol-security-requirements and draft-ietf-i2rs-security-environment-reqs-02.txt in a format consistent with the current Yang Considerations model. I welcome comments on whether this draft provides a format consistent with the current yang considerations model formats. The purpose behind this draft is to establish a template for security considerations that the netmod/netconf experts, I2RS protocol experts, and the security ADs would accept. The urgency for this discussion is to resolve the valid points made in the security AD's DISCUSS on these two YANG modules which are key to other YANG modules. Cheerily, Sue Hares -----Original Message----- From: Juergen Schoenwaelder [mailto:[email protected]] Sent: Monday, January 23, 2017 1:34 PM To: Susan Hares Cc: 'Giles Heron'; [email protected]; [email protected]; 'Kathleen Moriarty'; 'The IESG'; [email protected] Subject: Re: [i2rs] Kathleen Moriarty's No Objection on draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) There are no I2RS security guidelines. We should not confuse an individual I-D with guidelines. I believe the regular YANG security guidelines do the work. /js On Mon, Jan 23, 2017 at 09:40:43AM -0500, Susan Hares 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). > > > > 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: > > > > 1) NETCONF over TLS with X.509v3 as mandatory to implement protocol, > > 2) RESTCONF which uses HTTP over TLS with X.509v3 mutual authentication as a > permissible implementation alternative. > > 3) write contention for two clients writing a node using I2RS priority > (linked to I2RS User-ID) > > > > 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. > > > > 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]] > Sent: Monday, January 23, 2017 6:45 AM > To: Juergen Schoenwaelder > Cc: Susan Hares; [email protected]; > [email protected]; Kathleen Moriarty; The IESG; [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]> 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'; > > >> <mailto:[email protected]> > >> [email protected]; <mailto:[email protected]> > >> [email protected]; > > >> <mailto:[email protected]> [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'; > > >>> <mailto:[email protected]> > >>> [email protected]; <mailto:[email protected]> > >>> [email protected]; > > >>> <mailto:[email protected]> [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-consi > >>>> der> > >>>> https://datatracker.ietf.org/doc/draft-hares-i2rs-yang-sec-consid > >>>> er > > >>>> / > > >>>> > > >>>> 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: <mailto:[email protected]> > >>>> [email protected]; > >>>> <mailto:[email protected]> [email protected]; > > >>>> <mailto:[email protected]> [email protected]; > >>>> <mailto:[email protected]> [email protected]; <mailto:[email protected]> > >>>> [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-topolog > >>>> y/> > >>>> 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 > > >>>> <mailto:[email protected]> [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 > > > <mailto:[email protected]> [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/> _______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
