Andy:
Thank you for your comments. Perhaps you can provide for the IESG the list of things that are needed to move a Yang module forward in the IETF. Sue From: Andy Bierman [mailto:[email protected]] Sent: Friday, August 19, 2016 10:24 AM To: Lou Berger Cc: Susan Hares; Juergen Schoenwaelder; [email protected]; Alissa Cooper; [email protected]; Kathleen Moriarty; IESG; Jeffrey Haas; Joel Halpern; [email protected] Subject: Re: [i2rs] Kathleen Moriarty's Discuss on draft-ietf-i2rs-protocol-security-requirements-07: (with DISCUSS and COMMENT) Hi, I agree with Juergen. There are already too many details that need consensus to move a YANG module forward in the IETF. It takes too long already. We could have been tagging MIB objects all along, but we don't. Imagine if there was a debate for every single OBJECT-TYPE macro "is this leaf OK for noAuth/noPriv?" Are there even clear SEC-DIR guidelines on how one would decide this debate in a WG? Does SEC-DIR really want to be flooded with review requests so they become a bottleneck in YANG RFC publication process? Standardized insecure access is a big change from what we have done for 30 years. There could be a good reason why we left this out of scope all this time. Andy On Fri, Aug 19, 2016 at 5:20 AM, Lou Berger <[email protected]> wrote: Sue, My message said three things: 1) Juergen's comment resonates with me. 2) I think the current text is acceptable. 3) I see changing the SHOULD to a MUST as problematic. I understood one of the other messages on this thread proposing this change which is what triggered my message. If I misunderstood that message, feel free to interpret my message as supporting the current text in question. Note that I am only speaking for myself (including in my role as NETMOD co-chair) and not representing the consensus opinion of any WG. Lou On 8/19/2016 8:07 AM, Susan Hares wrote: > Lou: > > I am clear that Juergen does not want not want to place transport > requirements within the data model for NETMOD. His opinion was considered in > the rough for the I2RS WG. If this requirement is a problem for > NETCONF/NETMOD, the text currently says: > > REQ-SEC-09 states: > > The default mode of transport is secure so data models SHOULD clearly > annotate what data nodes can be > passed over an insecure connection. > > However, if this means the NETCONF/NETMOD WG will not even entertain proposal > for marking the insecure functions in yang text -- then the two WG > (I2RS/NETMOD) have a problem and should stop this standardization process > going forward. > > Sue > > > -----Original Message----- > From: Lou Berger [mailto:[email protected]] > Sent: Friday, August 19, 2016 7:34 AM > To: Susan Hares; 'Juergen Schoenwaelder' > Cc: [email protected]; 'Alissa Cooper'; [email protected]; 'Kathleen > Moriarty'; 'IESG'; [email protected]; 'Joel Halpern'; > [email protected] > Subject: Re: [i2rs] Kathleen Moriarty's Discuss on > draft-ietf-i2rs-protocol-security-requirements-07: (with DISCUSS and COMMENT) > > Sue, > > I don't see Juergen as arguing against model access via non-secure > transport. I read his point as that the transport security requirements don't > belong scattered within a data model. > > I have to say that from a model complexity (definition, process, review, > implementation - take your pick) , language and NETMOD co-chair perspective, > his comment resonates with me. > > I think this makes the key text: > > The default mode of transport is > secure so data models SHOULD clearly annotate what data nodes can be > passed over an insecure connection. > > > As this isn't a MUST, I personally think we can live with the text and we can > debate the issue further in the context of specific solutions. I would > strongly object to this being changed to a MUST, or if the document is > changed to make transport (security) requirements identified within data > models a requirement. > > Lou > > On 8/19/2016 6:49 AM, Susan Hares wrote: >> Juergen: >> >> You have laid out the two options: a) link the data-model to the >> non-secure transport, and b) do not link the data to the non-secure >> transport. I agree with you that past models did not link past SNMP MIB >> data model to the transport. Existing NETCONF models do not link it to the >> transport. As you have indicated, you disagreed in the I2RS WG and we >> found consensus was to include the non-secure transport. >> >> I2RS was created to build things as an interface to the routing environment. >> The operators clearly informed the I2RS group of this need during the >> requirement setting phase prior to the time I was chair. The reason I >> continue to press for this capability is their input, and the existing use >> cases I listed previously in this mail: >> >> a) public information - BGP route views, >> b) specific well know up events - such as public-web site up >> c) specific network service events - interface to particular public LAN up. >> >> As you know, we do not have any I2RS data models that specify this feature >> at this time. I suspect after we get through this lengthy requirement >> phase, the operators may begin to specify new models that have this feature. >> >> Sue >> >> -----Original Message----- >> From: Juergen Schoenwaelder >> [mailto:[email protected]] >> Sent: Friday, August 19, 2016 4:58 AM >> To: Susan Hares >> Cc: 'Alissa Cooper'; 'Joel Halpern'; [email protected]; >> [email protected]; 'Kathleen Moriarty'; 'IESG'; [email protected]; >> [email protected] >> Subject: Re: [i2rs] Kathleen Moriarty's Discuss on >> draft-ietf-i2rs-protocol-security-requirements-07: (with DISCUSS and >> COMMENT) >> >> I repeat my technical argument: While there may be deployments where >> non-secure transports may be reasonable to use, defining these situations >> statically as part of data model schemas does not follow established >> practices. The IETF has a long tradition of standardizing data models that >> can be used in a variety of operational contexts and I do not see reasons >> why we should move away from that basic approach. >> >> /js >> >> On Thu, Aug 18, 2016 at 02:35:03PM -0400, Susan Hares wrote: >>> Alissa: >>> >>> Just a little input you may not know. My background is 15 years >>> (1995-2010) developing a routing/switching platform (denoted as GateD) >>> which was sold to over 200 companies. We developed XML and a binary XML >>> based product that configured this product. It could do 100K configuration >>> lines and reboot in less than a second on most hardware. We also provide >>> status messages in secure streams and non-secure streams. I sold early >>> version of this code to companies that Alia has worked for - so she has >>> personal viewed the code. At the height of our work, our development team >>> ran to 50 people which I directed (First as VP of Engineering, and then as >>> CTO). It is due to this level of experience that Alia selected me for the >>> co-chair. Russ White has understood Cisco's process, and has also >>> directed software development teams for routing. >>> >>> In order to freshen my direct experience with I2RS on open source work, I >>> am working on a publically available work in Quagga based on the confD >>> product suggested by Cisco. >>> >>> In contrast, Juergen is a university professor who has worked on >>> proto-types. He is not working on an implementation. I hope he will. >>> >>> I hope you will consider this background in my response to your comments >>> below. >>> >>> Sue >>> >>> >>> -----Original Message----- >>> From: Alissa Cooper [mailto:[email protected]] >>> Sent: Thursday, August 18, 2016 12:54 PM >>> To: Joel Halpern >>> Cc: Susan Hares; Juergen Schoenwaelder; [email protected]; >>> [email protected]; Kathleen Moriarty; IESG; [email protected]; >>> [email protected] >>> Subject: Re: [i2rs] Kathleen Moriarty's Discuss on >>> draft-ietf-i2rs-protocol-security-requirements-07: (with DISCUSS and >>> COMMENT) >>> >>> Jumping in here because this is relevant to my DISCUSS, hope nobody minds >>> (but if you do, I can go back to the other thread). >>> >>>>> On Aug 18, 2016, at 10:30 AM, Joel Halpern <[email protected]> >>>>> wrote: >>>>> >>>>> Let me try a different take approach to this particular question. >>>>> >>>>> Let me start by putting aside the question of where things are marked, >>>>> and come back to that afterwards. >>>>> >>>>> There are a number of cases that I2RS has been asked to cover of high >>>>> rate telemetry data. This may be BGP update information, it may be >>>>> frequent information about line card activity. There are other cases, >>>>> some of which have been documented. >>>>> >>>>> While not completely insensitive, the operators have made clear that they >>>>> see protecting this data as unnecessary. While I would hope over time to >>>>> move to a domain where all of it is protect, that is not trivial. As the >>>>> I2RS Architecture points out, it is expected that what we describe as a >>>>> single I2RS >communication between a client and agent is actually >>>>> associated with multiple channels of communication. >>>>> >>>>> Now, if you want to say that the I2RS protocol requirements cannot allow >>>>> for unprotected channels, I guess we have disconnect between the IESG and >>>>> the WG. >>>>> >>>>> If we say that we can allow for unprotected channels, we then get to the >>>>> question of which data can be sent over such channels. While >>>>> architecturally I agree with Juergen that the model is a bad place to >>>>> specify it, the obverse is also true. Not having some limits on what can >>>>> be sent unprotected >causes concern about insufficient protection. If I >>>>> recall correctly, earlier security reviews called us to task for being >>>>> too broad in what we allowed. >>>>> >>>>> So, if the IESG wants us to just allow it anywhere, because the >>>>> model is an awkward place to define the limitation, I can live with that. >>>>> What I can't live with is being told both that the model is a bad place >>>>> to define it and that there must be restrictions on what is sent >>>>> unprotected, without any proposal on how we are to move forward. >>>> Thank you Joel, this explanation helps me a lot. I think there is a >>>> disconnect about how the restrictions are expressed. From reading the >>>> email traffic about this document, it strikes me that trying to express >>>> the restrictions programmatically doesn’t make much sense in this case. >>>> I agree with Juergen that it will be challenging to make a judgment a >>>> priori in order to bake a restriction into a data model, because data that >>>> is considered sensitive enough to warrant a secure transport in one >>>> deployment may not be considered sensitive in another deployment. >>>> So for any data elements where there is any question at all about >>>> whether they might be sensitive (i.e., any data elements that are not >>>> already routinely made public), I would expect data model authors to end >>>> up indicating that they may be sent over either secure or insecure >>>> transport, which renders the indication not useful. >>>> Perhaps it would make more sense then to just enumerate in the text the >>>> cases that motivate the inclusion of protocol support for insecure >>>> transport: >>>> >>>> 1. For conveyance of information that is already routinely made public. >>>> 2. For line card activity data where there is no likely upgrade path to >>>> support secure transports in the foreseeable future. >>>> >>>> Then the normative requirements would be on clients and agents to use >>>> secure transports unless those clients and agents are deployed where >>>> either of the operational circumstances above necessitate otherwise. >>>> Alissa >>> Point 1: >>> I disagree with Juergen on the difficulty in specifying the sections of the >>> yang modules. I have provided a suggested solution in: >>> https://tools.ietf.org/html/draft-hares-i2rs-protocol-strawman-03#section-4.5.2. >>> >>> Given the mount schema functionality, we can mount ephemeral state module >>> which augment non-ephemeral state modules which are "in-secure only". >>> >>> Point 2: >>> I am willing to put an enumeration of the use cases in the protocol >>> requirement, but I would like to understand the purpose for the >>> enumeration. We are not doing a use case, but a requirements document. >>> This information appears to be a "use case" rather than a technical >>> description. What purpose are you looking for this enumeration to server. >>> Are you looking for the enumeration in SEC-REQ-08? >>> >>> Point 3: Could you review -08.txt on this topic, especially the text below. >>> Given your comments, I believe I should change the last line to a MUST. >>> New/ The default mode of transport is >>> secure so data models MUST clearly annotate what data nodes can be >>> passed over an insecure connection. >>> / >>> >>> Sue >>> >>> =================== >>> As to the normative requirements (-08.txt) version: >>> >>> Section 3: >>> >>> I2RS allows the use of an insecure transport for portions of data >>> models that clearly indicate the use of an insecure transport. >>> Operators deploying I2RS must determine if they want to populate and >>> deploy the portions of the data model which use insecure transports. >>> >>> In Section 3.2 in version -08.txt >>> >>> SEC-REQ-08: The I2RS protocol MUST be able to transfer data over a >>> secure transport and optionally MAY be able to transfer data over a >>> non-secure transport. A secure transport MUST provide data >>> confidentiality, data integrity, and replay prevention. >>> >>> The default I2RS transport is a secure transport. >>> >>> A non-secure transport can be used for publishing telemetry data or >>> other operational state that was specifically indicated to non- >>> confidential in the data model in the Yang syntax. >>> >>> The configuration of ephemeral data in the I2RS Agent by the I2RS >>> client SHOULD be done over a secure transport. It is anticipated >>> that the passing of most I2RS ephemeral state operational status >>> SHOULD be done over a secure transport. As >>> [I-D.ietf-i2rs-ephemeral-state] notes, a data model MUST indicate >>> whether the transport exchanging the data between I2RS client and >>> I2RS agent is secure or insecure. >>> >>> The default mode of transport is >>> secure so data models SHOULD clearly annotate what data nodes can be >>> passed over an insecure connection. >>> >>>> Yours, >>>> Joel >>>> >>>> -----Original Message----- >>>> From: Susan Hares [mailto:[email protected]] >>>> Sent: Thursday, August 18, 2016 9:17 AM >>>> To: 'Juergen Schoenwaelder' <[email protected]> >>>> Cc: [email protected]; [email protected]; 'Kathleen Moriarty' >>>> <[email protected]>; 'The IESG' <[email protected]>; >>>> [email protected]; >>>> [email protected] >>>> Subject: RE: [i2rs] Kathleen Moriarty's Discuss on >>>> draft-ietf-i2rs-protocol-security-requirements-07: (with DISCUSS and >>>> COMMENT) >>>> >>>> Juergen and Kathleen: >>>> >>>> Let me proceed with two examples: BGP route views data model and the event >>>> for the web-service data. >>>> >>>> The content of these data models are designated as exposed to public. The >>>> routing system only populates the proposed BGP route views data model with >>>> the data destined for the BGP looking glass. The policy on the routing >>>> system indicates what information gets transferred. The data model is >>>> completely available to the public. The Yang Doctors are going to review >>>> this by seeing the whole model is public and available via non-secure >>>> means. >>>> The security people are going to review this seeing that the whole model >>>> is public, and available via an unprotect means. The fact the data model >>>> is all public should simplify the review. >>>> >>>> An event from the I2RS RIB that a web-service route is up is the second >>>> case. The I2RS RIB has an event based on policy that indicates a >>>> web-service route is up. The yang-1.1 doctors must review the content of >>>> the event text to see it does not break privacy or provide too much >>>> information The event mechanisms will need to work over secure transport >>>> and insecure transport. Most of the data will go over the secure >>>> transport event stream. However, a small amount of information may go over >>>> the insecure transport stream. >>>> >>>> First, let me know if my use cases are understandable. Second, let me >>>> know if you disagree with this use cases. >>>> >>>> Fyi - IESG approved the architecture with the insecure stream. >>>> >>>> Sue >>>> >>>> -----Original Message----- >>>> From: Juergen Schoenwaelder >>>> [mailto:[email protected]] >>>> Sent: Thursday, August 18, 2016 9:06 AM >>>> To: Susan Hares >>>> Cc: [email protected]; [email protected]; 'Kathleen Moriarty'; 'The >>>> IESG'; [email protected]; >>>> [email protected] >>>> Subject: Re: [i2rs] Kathleen Moriarty's Discuss on >>>> draft-ietf-i2rs-protocol-security-requirements-07: (with DISCUSS and >>>> COMMENT) >>>> >>>> I just do not know on which basis a data model writer can decide whether a >>>> data object can be exposed in an unprotected way. How are YANG doctors >>>> going to review this? How are security directorate people going to judge >>>> this? But as promised, I leave (still puzzled) now. >>>> >>>> /js >>>> >>>> On Thu, Aug 18, 2016 at 09:00:14AM -0400, Susan Hares wrote: >>>>> Juergen: >>>>> >>>>> Yes, we seem to disagree on the value of making it hardwired in the model. >>>>> For me, the value is a common understanding of deployment >>>>> distribution >>>> such >>>>> as the route-views. Since the operators argued strongly for this point, >>>> I >>>>> think the best idea is to get it working in code and then see if >>>>> the deployment matches the requests. >>>>> >>>>> Sue >>>>> >>>>> -----Original Message----- >>>>> From: i2rs [mailto:[email protected]] On Behalf Of Juergen >>>>> Schoenwaelder >>>>> Sent: Thursday, August 18, 2016 8:14 AM >>>>> To: Susan Hares >>>>> Cc: [email protected]; [email protected]; 'Kathleen Moriarty'; 'The >>>>> IESG'; [email protected]; >>>>> [email protected] >>>>> Subject: Re: [i2rs] Kathleen Moriarty's Discuss on >>>>> draft-ietf-i2rs-protocol-security-requirements-07: (with DISCUSS >>>>> and >>>>> COMMENT) >>>>> >>>>> Sue, >>>>> >>>>> I still do not see why the 'mode of exposure' of data benefits from >>>>> being hard-wired in the data model. For me, it is a situational and >>>>> deployment specific question. But I shut up here since I aired this >>>>> concern before (and we simply seem to disagree). >>>>> >>>>> /js >>>>> >>>>> On Thu, Aug 18, 2016 at 08:07:18AM -0400, Susan Hares wrote: >>>>>> Juergen: >>>>>> >>>>>> My example is the looking glass servers for the BGP route views >>>>>> project >>>>>> (http://www.routeviews.org/) or a route indicating the presence of a >>>>>> web-server that is public. For the BGP I2RS route, a yang model could >>>>>> replace the looking glass function, and provide events for these looking >>>>>> glass functions. For the web-server route, an event be sent when >>>> that >>>>>> one route is added. >>>>>> >>>>>> Sue >>>>>> >>>>>> >>>>>> -----Original Message----- >>>>>> From: Juergen Schoenwaelder >>>>>> [mailto:[email protected]] >>>>>> Sent: Thursday, August 18, 2016 3:32 AM >>>>>> To: Susan Hares >>>>>> Cc: 'Kathleen Moriarty'; 'The IESG'; [email protected]; >>>>>> [email protected]; [email protected]; >>>>>> [email protected] >>>>>> Subject: Re: [i2rs] Kathleen Moriarty's Discuss on >>>>>> draft-ietf-i2rs-protocol-security-requirements-07: (with DISCUSS >>>>>> and >>>>>> COMMENT) >>>>>> >>>>>> On Wed, Aug 17, 2016 at 09:16:48PM -0400, Susan Hares wrote: >>>>>>> ----------------------------------------------------------------- >>>>>>> - >>>>>>> -- >>>>>>> -- >>>>>>> COMMENT: >>>>>>> ----------------------------------------------------------------- >>>>>>> - >>>>>>> -- >>>>>>> -- >>>>>>> >>>>>>>> Section 3: >>>>>>>> Can you clarify the second to last sentence? Do you mean there >>>>>>>> are >>>>>> sections that indicate an insecure transport should be used? >>>>>>>> I2RS allows the use of an >>>>>>>> insecure transport for portions of data models that clearly >>>>>>>> indicate insecure transport. >>>>>>>> Perhaps: >>>>>>>> I2RS allows the use of an >>>>>>>> insecure transport for portions of data models that clearly >>>>>>>> indicate the use of an insecure transport. >>>>>> I still wonder how a data model writer can reasonably decide >>>>>> whether a piece of information can be shipped safely over an >>>>>> insecure transport since this decision often depends on the >>>>>> specifics of a deployment >>>>> situation. >>>>>> /js >>>>>> >>>>>> PS: I hope we do not end up with defining data multiple times (once >>>>>> for insecure transport and once for secured transports). >>>>>> >>>>>> -- >>>>>> 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 >>>>> -- >>>>> 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 >>>>> >>>> -- >>>> 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
_______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
