Hi Sue, On 1/25/2017 12:29 PM, Susan Hares wrote: > > 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. > Understood. > > Due to my respect for you, I am going to provide you a technical > response on list. > Thank you (I think).
> 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. > > > okay - but I'm not sure if you want me to address the comments below here or wait for an off-line call. I guess I'll wait for a one-on-one discussion. one point I think I need to clarify for everyone is in response to: > seem to be making conclusions without discussion. To be clear my statements on what's next had caveats that were based on what you/I2RS/the IESG decide - it was not stating a definitive conclusion or direction, but rather possibilities based on a decision that I expect to happen in the context of I2RS. Lou > 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" <[email protected] > <mailto:[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]] > > > Sent: Tuesday, January 24, 2017 10:39 AM > > > To: [email protected] <mailto:[email protected]> > > > Cc: [email protected] <mailto:[email protected]>; > [email protected] > <mailto:[email protected]>; > > > [email protected] > <mailto:[email protected]>; [email protected] > <mailto:[email protected]>; > > > [email protected] <mailto:[email protected]>; [email protected] > <mailto:[email protected]>; [email protected] > <mailto:[email protected]>; > > > [email protected] <mailto:[email protected]>; [email protected] > <mailto:[email protected]> > > > Subject: Re: [i2rs] Kathleen Moriarty's No Objection on > > > draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) > > > > > > "Susan Hares" <[email protected] <mailto:[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]] > > >> Sent: Tuesday, January 24, 2017 7:35 AM > > >> To: [email protected] <mailto:[email protected]> > > >> Cc: [email protected] <mailto:[email protected]>; > [email protected] > <mailto:[email protected]>; > > >> [email protected] > <mailto:[email protected]>; [email protected] > <mailto:[email protected]>; > > >> [email protected] <mailto:[email protected]>; [email protected] > <mailto:[email protected]>; [email protected] > <mailto:[email protected]>; > > >> [email protected] <mailto:[email protected]>; [email protected] > <mailto:[email protected]> > > >> Subject: Re: [i2rs] Kathleen Moriarty's No Objection on > > >> draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) > > >> > > >> > > >> > > >> "Susan Hares" < <mailto:[email protected]> [email protected] > <mailto:[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]] > > >> On Behalf Of Martin > > >> > > >> > Bjorklund > > >> > > >> > Sent: Monday, January 23, 2017 5:26 PM > > >> > > >> > To: <mailto:[email protected]> [email protected] > <mailto:[email protected]> > > >> > > >> > Cc: <mailto:[email protected]> [email protected] <mailto:[email protected]>; > > >> <mailto:[email protected]> > > >> [email protected] > <mailto:[email protected]>; > > >> > > >> > <mailto:[email protected]> > > >> [email protected] > <mailto:[email protected]>; > <mailto:[email protected]> > > >> [email protected] <mailto:[email protected]>; > > >> > > >> > <mailto:[email protected]> [email protected] <mailto:[email protected]>; > > >> <mailto:[email protected]> > > >> [email protected] > <mailto:[email protected]>; <mailto:[email protected]> > > >> [email protected] <mailto:[email protected]> > > >> > > >> > Subject: Re: [i2rs] Kathleen Moriarty's No Objection on > > >> > > >> > draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) > > >> > > >> > > > >> > > >> > "Susan Hares" < <mailto:[email protected]> [email protected] > <mailto:[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]] > > >> > > >> > > Sent: Monday, January 23, 2017 4:11 PM > > >> > > >> > > To: Martin Bjorklund; <mailto:[email protected]> [email protected] > <mailto:[email protected]> > > >> > > >> > > Cc: <mailto:[email protected]> [email protected] <mailto:[email protected]>; > > >> <mailto:[email protected]> > > >> [email protected] > <mailto:[email protected]>; > > >> > > >> > > <mailto:[email protected]> > > >> [email protected] > <mailto:[email protected]>; > <mailto:[email protected]> > > >> [email protected] <mailto:[email protected]>; > > >> > > >> > > <mailto:[email protected]> > > >> [email protected] > <mailto:[email protected]>; <mailto:[email protected]> > > >> [email protected] <mailto:[email protected]> > > >> > > >> > > Subject: Re: [i2rs] Kathleen Moriarty's No Objection on > > >> > > >> > > draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT) > > >> > > >> > > > > >> > > >> > > 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]> [email protected] <mailto:[email protected]> > > >> > > >> > <https://www.ietf.org/mailman/listinfo/i2rs> > > >> https://www.ietf.org/mailman/listinfo/i2rs > > >> > > >> > > > >> > > > > > > > > > _______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
