Sent from my iPhone
> On Aug 19, 2016, at 4:57 AM, Juergen Schoenwaelder > <[email protected]> wrote: > > 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. What I proposed just adds a trigger so operators can make that decision and can automate it. This isn't new for IETF protocols. I'm proposing this since it seems it was a working group decision to allow for automation. Is that not the case? Kathleen > > /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/> > > -- > 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
