On 8/18/16 12:56 PM, Susan Hares wrote: > Alissa: > > A follow-up email on this topic. Joel suggests that I missing your question. > Are you asking who is in a position to determine that certain data is > reasonable to send unprotected? > Are you asking if it is the operator, the data model designer, or our > original WG designing the protocol? > > If this is the case, the final authority is the owner of the data - the > operator. The closer the operator works with vendors who supply code and > standardize it, the better the vendors understand the need. It is hoped that > the vendors and the operators will help I2RS or other WG to define these data > modules. We hope the security people from these operators and security > people from vendors and research will validate the security needs. We > believe we have a sense from the WG discussions on the categories I > mentioned: a) publically available data (route-views), b) events specific > to operators that are public, and c) interface/data that can be seen > publically (IXP ports or MEF exchange ports) > > Personally, I also want to be very careful with any data that can be linked > to a person. To me, this must be done over a secure transport. > > Does this help? Like Joel - I am proactively answering you, but confused on > what you want me to change. Another joel here,
Conceptually an I2RS system resembles the distributed control and forwarding architecture of a large routers. Likewise is possible to conceive of router(s) where the I2RS architecture is the control plane. If it appropriate to carry controller-plane programming or accounting information around internally in such a system for reasons of convenience or performance then architects will probably do that. I don't see as desirable, exposing my distributed control-plane to the potential for information leakage or compromise when it's distributed across the internet, At the same time if it's a big sheetmetal box with 12 linecards and internal network stashed away in a VRF, or a bunch of software blobs running on the same machine, I might be inclined to treat them differently. Respecting SEC-REQ-09 I can imagine it being appropriate to do both at the same time with the same data to different clients > > 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 > >> 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/> >> > >
signature.asc
Description: OpenPGP digital signature
_______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
