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