Lou:
I am happy to receive your email as it demonstrates misconceptions about what I stated. The original topic of this thread was the security considerations section regarding an I2RS Topology model. Due to my respect for you, I am going to provide you a technical response on list. I have labeled my responses to respond to your points. I have responded on l but I will not follow-up on this thread. I encourage you to contact me directly via phone or email. Cheerily, Sue ----Original Message----- From: Lou Berger [mailto:[email protected]] Sent: Wednesday, January 25, 2017 7:27 AM To: Susan Hares Cc: 'Martin Bjorklund'; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected] Subject: RE: [i2rs] Kathleen Moriarty's No Objection on draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) Sue, In short, I'm going to agree with Benoit - but for slightly different reasons as I also co-chair TEAS, a group that is basing some of its work on I2RS developed models. >Lou 1: As a WG chair, I have always viewed the models being developed by I2RS as typical models that are generally useful, and being defined by I2RS simply because they were ahead of other groups that might otherwise define the >models -- and I view this as a fine thing that has benefit for YANG users and other WGs. As TEAS chair, this is what lead me to ensure that the models being defined in TEAS built on the I2RS YANG modules vs their original path of redefining >parallel function. Sue 1: I am pleased that TEAS WG and other WG find the Topology models useful. The topology model design encompasses ephemeral state and security for ephemeral state. It was built to be a platform for topology models, and to had early experimentation in the ODL models. Perhaps you missed the email on this thread where an insightful Martin asked "Does this mean I2RS models cannot be used by Topology models in other WGs?" I responded "not really" and more specifically " Most of the topology models I have seen abide by the concepts found in the I2RS topology model." Please see the mail at: https://www.ietf.org/mail-archive/web/i2rs/current/msg04231.html. The Topology models really operate best in an ephemeral state environment. Ephemeral state is not a I2RS-only functionality. Starting 4 years ago with discussions with NETCONF/NETMOD at the NYC interim, It was indicated that ephemeral state would be used by other WGs. One of these key uses is the use for Topology models. Topology model's ephemeral state allow operational state learned from the routing system to be altered with writes from the I2RS Client. (Please note the security considerations occur once read sensitive information or write sensitive information). This mixture of state does not really match the definition of the o configuration datastore: The datastore holding the complete set of configuration data that is required to get a device from its initial default state into a desired operational state. Let's look at how this applies to the draft-ietf-teas-yang-te-topo-06.txt in section 3.1: " TE topology is a traffic engineering representation of one or more layers of network topologies. TE topology is comprised of TE nodes (TE graph vertices) interconnected via TE links (TE graph edges). A TE topology is mapped to a TE graph." TE topology model defines: underlay TE topology, overlay TE topology, and Abstract TE topology. The model in draft-ietf-teas-yang-te-topo-06.txt (ietf-te-topology) is technology agnostic blending learned topology (underlay TE topology) and configured topology to create an abstract TE topology. This is a wonderful use of the I2RS Topology model. Let's look what additional security is needed for Topology Models in Ephemeral state: Transport: Ephemeral state with topology models has security risks which include topology information may be sensitive or allow DoS attacks. Based on this point, the I2RS WG spent time looking at what protocol security and environment security is needed. To protect this information, I2RS WG decide the NETCONF/RESTCONF must run over a transport that provide mutual authentication, data confidentiality, data integrity and practical replay protections which had structure to limit DoS attacks. Mutual authentication requires a key management system and the definition of what an I2RS identifier is. The security environment would need policy that determine the interaction with other data stores, control plane protocols, and dynamic configuration protocols. These are additions to the basic yang security considerations (sensitive/privacy read nodes, sensitive/privacy in write nodes, or sensitive/privacy in rpc commands). I2RS allowed the security association to exist without transport connections, or to have multiple transport connections. This mechanism provide better bandwidth for accessing topology models. AFAIK - the NETCONF over SSH does not provide this level of security but NETCONF over TLS with X.509v3 does and RESTCONF do. If I NETCONF over SSH (RFC4722) does provide this level of security, then please let me know. Any data store must solve the problem of multiple clients writing a data node. I2RS decided multiple I2RS clients might want to write the topology in the I2RS Agent, but defined the simultaneous write as an error (with priority system as resolution). This write contention is an alternative to the configuration data store lock or the RESTCONF lock for a single actions. I2RS felt the speed choices on priority (similar to BGP choices) were better for ephemeral state. If the priority system is used, then one priority must be assigned per user identifier. If TEAS or NETMOD wants to define another mechanism, then this is a change from the I2RS protocol/ephemeral store definitions. It would be wonderful to have a discussion of this in NETMOD since the ephemeral state requirement require it. It would be nice to have one multiple-write mechanism for a generalize ephemeral state. I2RS felt tracing, better notification and pub/sub was necessary for I2RS. TEAS can refuse to import the trace, better notification or pub/sub work. >Lou 2: As part of my view of the I2RS models being generally applicable to uses beyond I2RS together with I2RS choosing YANG for modeling ephemeral data, I have always expected that the I2RS WG would at some (perhaps as part of >the I2RS protocol definition) define how any YANG model can be used to support I2RS. This view certainly lead me to conclude that having the I2RS models move forward, just like any other YANG model, makes sense and would benefit the > other models and WGs that reference this core work. This view also allows for the relationship to the revised-data store work, as well as the specification of which data > store(s) I2RS uses, to be separately defined -- and to not gate publication of these models. This separate specification would be the location for any I2RS-specific transport and security considers, so such would not belong in the > generally reusable models developed by I2RS. >Essentially, As NETMOD co-chair, I concluded that the revised data store work provided the direction on how ephemeral would be supported in a general YANG context and, therefore, the major open issue / gating impediment to >progressing I2RS models had been removed and publication of these models were unblocked. This also motivated my comments in the related discussions at the last meeting. Sue 2: Is the direction for the ephemeral state concepts agreed upon? The real test is if we are able to define ephemeral state within the control plane data store. You and I both thought that the adoption of draft-ietf-netmod-ietf-revised-datastores-00.txt completed this work on getting ephemeral data store concepts completed. You, I, Alia, Benoit thought progressing these key models based on these concepts of ephemeral state in this document seemed reasonable. However, this discussion seems to be stuck on what is ephemeral state and why is it different. If so, NETMOD does not have a clear ephemeral data store definition. Let's try 2 tests: a) did we get stuck on the security considerations section? (yes), b) Is there general agreement and a proposal for Yang modifications for ephemeral state? (no) Draft-ietf-netmod-ietf-revised-datastores-00.txt suggest the Control Plane Data stores but there has been confusion on this being an ephemeral data store with config=true nodes and operational state. There document suggests a "<get-data datastore>, but does not suggest a "write-data datastore> command for ephemeral data store. Perhaps based on the feedback from Juergen and Martin, means we need to create: a) an I2RS ephemeral Control Plane data store description, and b) create a document or a section in these documents on the assumptions of data stores. At the very least we should add to this document what Martin's suggests in the email at: https://www.ietf.org/mail-archive/web/i2rs/current/msg04234.html Which states: "Yes, but (1) draft-ietf-netmod-ietf-revised-datastores-00 is clearly work-in-progress, and (2) none of the topology drafts reference draft-ietf-netmod-ietf-revised-datastores-00, so if they depend on a solution in that draft, it is not very clear to the reader". The draft-hares-i2rs-yang-sec-consider-00 suggests security considerations need to indicate: mandatory transport, 4 features of the ephemeral data store defined by I2RS, and whether any portion of the YANG model can move over insecure transport. Since these 4 features of I2RS ephemeral data store set by the I2RS ephemeral state requirements (draft-ietf-i2rs-ephemeral-state-23.txt) are not agreed to in draft-ietf-netmod-ietf-revised-datastores-00.txt, we have not completed Lou 3: If my understanding/view is correct, i.e., that the topology models are just like any other YANG model, then I think publication can and should proceed (with the appropriate text for a typical YANG model). Sue 3: I hope that my explanation above indicates that the I2RS Topology models are ephemeral models built for Topologies like TEAS. It is the very qualities you see in topology models that cause them to be ephemeral in order to mix the operational state with configuration state in a way that the configuration data store cannot. If we have a solid definition of Ephemeral data stores and Ephemeral Data models, then these data models are like any other ephemeral YANG model. Any ephemeral model must choose a multiple client-write design. It would be lovely to have a single ephemeral data store design. Lou 4: If I misunderstood something, and the models produced by I2RS are limited to ephemeral representations/data stores as well as specific YANG transport protocols -- then as TEAS chair, I have to hit reset on the TEAS topology work, and as NETMOD chair I think the NETMOD WG needs to discuss what it means for a YANG model to be protocol/datastore specific and if any guidelines or other new NTEMOD documents are need to support such. Sue 4: Perhaps the TEAS WG Chair needs to discuss with the NETMOD WG Chair about completing the Ephemeral data store work before coming to a conclusion. Lou 5: Less importantly, as I2RS participant, I'd also ask for the documents to be sent back to the WG for a new last call once the documents are updated to reflect their narrow scope -- as I bet I'm not the only person who viewed this work applicable to non-ephemeral uses. Sue 5: As an I2RS Chair, I am not sure you have correctly defined the narrow scope of the I2RS work or these documents. Of course, after we complete the revisions of these documents if the ADs (Alia and Benoit) deem these need to go back to the WG for another WG LC, then we will send the drafts for another WG LC. Right now, the only thing that the drafts have firmly to revise is the Yang Security considerations define by https://trac.ietf.org/trac/ops/wiki/yang-security-guidelines The rest of this list discussion is simply a discussion of IESG members and people who did not participate in the WG LC or the IETF LC regarding a proposal for addition security considerations. As Shepherd, Kathleen's questions about security consideration found missing piece and I wrote a discussion document. Unfortunately, the discussion has not examined the document (draft-hares-i2rs-yang-sec-consider) or the open issues in ephemeral stsate. Lou 6: I hope this helps. Sue 6: Was it meant to be helpful? I really, really hope you are engaging in a technical discussion about ephemeral state and how we can move forward. Two comments: . "then as a TEAS chair, I have to hit rest on the TEAS topology work" or as a . "I2RS participant, I'd also ask for the document to be sent to the WG for a new last call once the documents are updated" seem to be making conclusions without discussion. Cheerily, Sue On January 24, 2017 11:56:32 AM "Susan Hares" < <mailto:[email protected]> [email protected]> wrote: > To: Martin: > > You have a reasonable request. If the NETMOD WG Chairs confirm their > decision to make I2RS Yang Modules part of the Control Plane Datastore > then as shepherd/WG-chair I will recommend these get added to the draft. > > Note to authors : > > As we wait for the NETMOD WG Chairs and Benoit to deliver the decision > on Config/Control Plane datastore, the authors should work on: Basic > Yang security considerations and the other I2RS Yang Module information. > > Sue Hares (Shepherd) > -----Original Message----- > From: Martin Bjorklund [ <mailto:[email protected]> mailto:[email protected]] > Sent: Tuesday, January 24, 2017 10:39 AM > To: <mailto:[email protected]> [email protected] > 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]; <mailto:[email protected]> [email protected]; <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 Hares" < <mailto:[email protected]> [email protected]> wrote: >> Martin: >> >> >> >> I'm sorry if misunderstood your comments regarding the >> draft-ietf-netmod-revised-datastores-00.txt. The reason the answer >> is unclear is that it depends on the context of the question. >> >> >> >> . If you ask if the pre-standardization I2RS Yang Topology models >> (basic and L3) implemented are part of the configuration data store, >> the answer is yes - AFAIK. > > This is not my question. > >> . If you ask if the WG LC Topology models are approved to be part > of >> the configuration data store, my understanding was no. I2RS WG was to >> abide by the decision of NETMOD WG on which data store I2RS modules >> were placed in. > > Yes, this is my question. And my concern is that even if your > understanding is that they are not designed to be part of the > configuration datastores, this fact is not mentioned in the drafts. > >> If you are concerned the implementation varies from the standardized, > please >> express this to Benoit Claise. Based on your comments on my email > thread, >> I will be brief in my answers today. > > This is not my concern. > > > /martin > > > >> >> >> >> Sue >> >> >> >> >> >> -----Original Message----- >> From: Martin Bjorklund [ <mailto:[email protected]> mailto:[email protected]] >> Sent: Tuesday, January 24, 2017 7:35 AM >> To: <mailto:[email protected]> [email protected] >> 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]; <mailto:[email protected]> [email protected]; <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 Hares" < < <mailto:[email protected]> mailto:[email protected]> <mailto:[email protected]> [email protected]> wrote: >> >> > Martin: >> >> > >> >> > Your statement "One problem is that relying on the solution in >> >> > draft-ietf-netmod-revised-datastores-00 is a bit premature - in >> > fact, >> >> > that document does not yet provide any details at all on the I2RS >> >> > ephemeral data store." This statement is not what I understood from >> > IETF >> 98 or the netmod >> >> > ADs. I guess your objection to this data model falls into Benoit > Claise >> >> > (AD) and the NETMOD folks to answer. >> >> >> >> Why do you think that I have any objection to >> draft-ietf-netmod-revised-datastores-00. Please re-read what I wrote. >> >> >> >> My objection regards your statement: >> >> >> >> 1) I2RS Data models do not utilize the configuration data store, >> >> >> >> If this is true it needs to be clarified in the document. >> >> >> >> After all these emails back and forth, it is still not clear whether >> this statement is true or not. >> >> >> >> >> >> /martin >> >> >> >> >> >> >> >> >> >> >> >> > >> >> > Sue Hares >> >> > >> >> > -----Original Message----- >> >> > From: i2rs [ < <mailto:[email protected]> mailto:[email protected]> >> > <mailto:[email protected]> mailto:[email protected]] >> On Behalf Of Martin >> >> > Bjorklund >> >> > Sent: Monday, January 23, 2017 5:26 PM >> >> > To: < <mailto:[email protected]> mailto:[email protected]> <mailto:[email protected]> [email protected] >> >> > Cc: < <mailto:[email protected]> mailto:[email protected]> <mailto:[email protected]> [email protected]; >> < <mailto:[email protected]> mailto:[email protected]> >> <mailto:[email protected]> [email protected]; >> >> > < <mailto:[email protected]> mailto:[email protected]> >> <mailto:[email protected]> [email protected]; < <mailto:[email protected]> mailto:[email protected]> >> <mailto:[email protected]> [email protected]; >> >> > < <mailto:[email protected]> mailto:[email protected]> <mailto:[email protected]> [email protected]; >> < <mailto:[email protected]> mailto:[email protected]> >> <mailto:[email protected]> [email protected]; < <mailto:[email protected]> mailto:[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 Hares" < < <mailto:[email protected]> mailto:[email protected]> <mailto:[email protected]> [email protected]> wrote: >> >> > > Robert and Martin: >> >> > > >> >> > > I agree with Robert that the current implementations of the ODL >> >> > > topology models are handled as part of the configuration data >> > > store >> >> > > with >> >> > ephemeral >> >> > > state. I will point out that these implementation are pre-standards >> >> > > implementations of the I2RS YANG Data model. >> >> > > >> >> > > While standardizing the topology data models, the I2RS WG have >> > > been >> >> > > asked to align with the >> > > draft-ietf-netmod-revised-datastores-00.txt >> >> > > NETMOD WG document. This NETMOD WG document moves the I2RS >> >> > > ephemeral data >> >> > store from >> >> > > configuration data store to a Control Plane data store. If we follow >> >> > this >> >> > > draft, the I2RS Topology models are part of the I2RS ephemeral >> > > data >> store. >> >> > > If you disagree with the placement of the Topology data models, >> >> > > please indicate this to the NETMOD WG and to Benoit. Could you >> >> > > propose a way that you would see the ephemeral state working with >> >> > > the configuration data >> >> > store >> >> > > to the NETMOD WG? >> >> > > >> >> > > Quite frankly, I feel a bit of whip-lash on this topic. NETMOD WG > asks >> >> > for >> >> > > Control Plane Data store. You ask for configuration data store >> >> > > (which was the I2RS initial proposal). >> >> > >> >> > Not really; I ask for clarification. >> >> > >> >> > > It is possible for either one to work for I2RS >> >> > > Topology models - if the right details are taken care of. How do we >> make >> >> > > progress on choosing one method so we can write the I2RS Topology >> >> > > Models security considerations.? >> >> > >> >> > One problem is that relying on the solution in >> >> > draft-ietf-netmod-revised-datastores-00 is a bit premature - in >> > fact, >> >> > that document does not yet provide any details at all on the I2RS >> >> > ephemeral datastore. >> >> > >> >> > So I see two alternatives. Either wait with these documents, or >> >> > publish them with their datamodels as is (i.e., no new additional >> >> > notes), for the existing protocols and architecure. This would >> > allow >> >> > them to be implemented just like any other YANG data model. This >> >> > would mean that the normal YANG security considerations guidelines >> > should >> be followed. >> >> > >> >> > >> >> > >> >> > /martin >> >> > >> >> > > >> >> > > Sue >> >> > > >> >> > > -----Original Message----- >> >> > > From: Robert Varga [ < <mailto:[email protected]> mailto:[email protected]> <mailto:[email protected]> mailto:[email protected]] >> >> > > Sent: Monday, January 23, 2017 4:11 PM >> >> > > To: Martin Bjorklund; < <mailto:[email protected]> mailto:[email protected]> <mailto:[email protected]> [email protected] >> >> > > Cc: < <mailto:[email protected]> mailto:[email protected]> <mailto:[email protected]> [email protected]; >> < <mailto:[email protected]> mailto:[email protected]> >> <mailto:[email protected]> [email protected]; >> >> > > < <mailto:[email protected]> mailto:[email protected]> >> <mailto:[email protected]> [email protected]; < <mailto:[email protected]> mailto:[email protected]> >> <mailto:[email protected]> [email protected]; >> >> > > < <mailto:[email protected]> mailto:[email protected]> >> <mailto:[email protected]> [email protected]; < <mailto:[email protected]> mailto:[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) >> >> > > >> >> > > On 01/23/2017 09:26 PM, Martin Bjorklund wrote: >> >> > > >> I'm pulling your questions to the top of this email. >> >> > > >> >> >> > > >> >> >> > > >> >> >> > > >> Question 1: Ok. Just to make sure I understand this correctly >> > > >> - >> >> > > >> these topology models are intended to be I2RS-specific, and >> > > >> they >> >> > > >> cannot be used for any other purpose. If anyone needs a >> > > >> general >> >> > > >> topology model outside of the I2RS protocol, they will have to >> >> > > >> design their own model. Is this correct? >> >> > > >> >> >> > > >> >> >> > > >> >> >> > > >> Response 1: Not really. >> >> > > > Ok, so are you saying that the models are in fact generic, and >> > > > can >> >> > > > be used outside of I2RS? I.e., they *can* be used with the >> > > > normal >> >> > > > configuration datastores? >> >> > > > >> >> > > >> >> > > From implementation experience, yes, they can be used for storing >> >> > > configuration. OpenDaylight uses (an ancient predecessor of) >> >> > > yang-network-topo to store configure details about devices in its >> >> > > managed networks. >> >> > > >> >> > > Regards, >> >> > > Robert >> >> > > >> >> > > >> >> > >> >> > _______________________________________________ >> >> > i2rs mailing list >> >> > < <mailto:[email protected]> mailto:[email protected]> <mailto:[email protected]> [email protected] >> >> > < <https://www.ietf.org/mailman/listinfo/i2rs> https://www.ietf.org/mailman/listinfo/i2rs> >> <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
