On Thu, Aug 18, 2016 at 12:44 PM, Susan Hares <[email protected]> wrote:
> Andy: > > > > Thank you – I thought it was on whether we could implement insecure > transport in a Yang module. > > > > The requirement text you are working with is: > > > > 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. > > > I do not understand why approving the ok for non-secure transport for some > modules means the following to you: > > > > *“ the IETF needs to agree that there could never possibly be any > deployment that would not want to allow exposure of the data.* > > *Not now. Not 20 years from now.”* > > > I see your point now. This draft makes no mention of the YANG data model marking objects that can be nonsecure. SEC-REQ-08 is fine. The other requirement (sorry I don't have the number) is the one that should be removed. Andy I had thought that the security-directorate and other reviewers would look > at each module that is insecure, and consider whether it was reasonable > for the use case at this time. This is what I understood from Russ > Housley’s first review of this technology. Since like you, I believe the > operator is going to configure what modules are allowed on systems. I > agree that this requirement provides a full scope of the work, but > implementers will require network operators to configure these features on. > > > > Sue > > > > > > *From:* Andy Bierman [mailto:[email protected]] > *Sent:* Thursday, August 18, 2016 2:53 PM > *To:* Susan Hares > *Cc:* Alissa Cooper; Joel Halpern; [email protected]; Juergen Schoenwaelder; > [email protected]; Kathleen Moriarty; IESG; Jeffrey Haas; > [email protected] > *Subject:* Re: [i2rs] Kathleen Moriarty's Discuss on > draft-ietf-i2rs-protocol-security-requirements-07: (with DISCUSS and > COMMENT) > > > > Hi, > > > > I did not think Juergen's comment was about running code. > > > > In order for a data node to get the "ok-for-nonsecure-transports" approval > > in an IETF module, the IETF needs to agree that there could never possibly > be > > any deployment that would not want to allow exposure of the data. > > Not now. Not 20 years from now. > > > > I can see a vendor making that decision for their own proprietary modules, > > but it seems less likely for standard modules. > > > > Seems like the operator is going to have to configure what is allowed > > for nonsecure transport anyway, so just let them decide. > > I don't really object to the extension or the requirement. > > It doesn't help much but it doesn't hurt much either. > > > > > > Andy > > > > > > > > On Thu, Aug 18, 2016 at 11:35 AM, Susan Hares <[email protected]> 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-strawm > an-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
