Giles:
I disagree – the I2RS Topology model does fit within the original goals. It is a protocol independent model with information on topology. This was in the original use cases and has been a focus for I2RS WG. See rest of the responses below. The real change for RFC compliance for ODL’s read-only Topology model would be: a) use of NETCONF over TLS with X.509v3 authentication, b) denoting the “dynamic control plane data store” in the get applied (whenever that gets implemented), and support of the opaque secondary identity in tracing (if you support tracing). The change for the RFC compliance for the ODL’s read-write would be the utilizing priority to resolve contention if multiple clients try to write the topology database. The priority could be set per user identifier (passed in X.509v3) in a pre-configuration set-up stored. Ideally this pre-configuration would be stored in a key store or something that is secure. Sue Fr om: Giles Heron [mailto:[email protected]] Sent: Monday, January 23, 2017 11:26 AM To: Susan Hares Cc: Juergen Schoenwaelder; [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) Hi Sue, On 23 Jan 2017, at 14:40, Susan Hares <[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) . [Sue]: No, the topology model was part of the original I2RS YANG modules, and the Topology models (L2, L3, Base) fit its ue. 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). [Sue]: This fits the I2RS Yang module. 1) NETCONF over TLS with X.509v3 as mandatory to implement protocol, Giles: most NETCONF implementations I’m aware of use ssh. 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? Sue: NETCONF over TLS with X.509v3 is an RFC 7589. I2RS is requiring this to get mutual authentication, confidentiality, data integrity, [practical] reply protection for I2RS messages, and support DoS mitigation. This mandatory-to-implement status is a change from the basic NETCONF over SSH. 2) RESTCONF which uses HTTP over TLS with X.509v3 mutual authentication as a permissible implementation alternative. Giles: again isn’t that only specified as mandatory in an individual ID? Sue: The I2RS requires mutual authentication, confidentiality, data integrity, [practical] reply protection for I2RS messages, and support DoS mitigation. Therefore, the RESTCONF protocol is an alternative since it supports this with its basic work. 3) write contention for two clients writing a node using I2RS priority (linked to I2RS User-ID) Giles: so that one isn’t an issue for read-only implementations… Sue: Yes. You are correct. Sue: 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. Giles: indeed. Sue: No other responses are below ============================= 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; <mailto:[email protected]> [email protected]; <mailto:[email protected]> [email protected]; Kathleen Moriarty; The IESG; <mailto:[email protected]> [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 < > <mailto:[email protected]> > [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
_______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
