Re: [i2rs] Kathleen Moriarty's Discuss on draft-ietf-i2rs-protocol-security-requirements-07: (with DISCUSS and COMMENT)
joel jaeggli <joelja@bogus.com> Fri, 19 August 2016 16:12 UTC
Return-Path: <joelja@bogus.com>
X-Original-To: i2rs@ietfa.amsl.com
Delivered-To: i2rs@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14CCF12D125; Fri, 19 Aug 2016 09:12:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.147
X-Spam-Level:
X-Spam-Status: No, score=-8.147 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.247] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WiSsZ6-r3-Dw; Fri, 19 Aug 2016 09:12:40 -0700 (PDT)
Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7998812D09B; Fri, 19 Aug 2016 09:12:40 -0700 (PDT)
Received: from mb-2.local ([IPv6:2601:647:4201:9e61:a5a6:9f65:49b4:5665]) (authenticated bits=0) by nagasaki.bogus.com (8.15.2/8.15.2) with ESMTPSA id u7JGCTfL094634 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT); Fri, 19 Aug 2016 16:12:30 GMT (envelope-from joelja@bogus.com)
X-Authentication-Warning: nagasaki.bogus.com: Host [IPv6:2601:647:4201:9e61:a5a6:9f65:49b4:5665] claimed to be mb-2.local
To: Susan Hares <shares@ndzh.com>, 'Andy Bierman' <andy@yumaworks.com>
References: <013b01d1f8ee$31fa09b0$95ee1d10$@ndzh.com> <20160818073203.GA4338@elstar.local> <04b501d1f949$116c63e0$34452ba0$@ndzh.com> <20160818121405.GA5282@elstar.local> <051301d1f950$7739c670$65ad5350$@ndzh.com> <20160818130555.GA5366@elstar.local> <051701d1f952$c4ae0b30$4e0a2190$@ndzh.com> <6BCE198E4EAEFC4CAB45D75826EFB0761525CCD7@eusaamb101.ericsson.se> <F8C205FB-665C-422C-B991-2F97F75CAE42@cooperw.in> <003801d1f97f$3d16eb10$b744c130$@ndzh.com> <20160819085756.GA6759@elstar.local> <01e501d1fa07$6d613fe0$4823bfa0$@ndzh.com> <9c53ff98-3268-f6e2-fbe6-862fc3948794@labn.net> <027a01d1fa12$3879b270$a96d1750$@ndzh.com> <a0e36f97-b62d-228f-f8f7-fadefd1570a1@labn.net> <CABCOCHStcL9-j_ZzG+J+Gj2=kx+N_F9WVzAVTU2pdnLo5dOF+g@mail.gmail.com> <036801d1fa2a$466e9e00$d34bda00$@ndzh.com> <CABCOCHSH1-CypkacnkvVjZiD76vKUgGbT+cgbCDannhHtTjqfw@mail.gmail.com> <005501d1fa33$3d36e960$b7a4bc20$@ndzh.com>
From: joel jaeggli <joelja@bogus.com>
Message-ID: <82159be3-622a-e986-ac97-628313fa1d68@bogus.com>
Date: Fri, 19 Aug 2016 09:12:26 -0700
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:47.0) Gecko/20100101 Thunderbird/47.0
MIME-Version: 1.0
In-Reply-To: <005501d1fa33$3d36e960$b7a4bc20$@ndzh.com>
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="nX1bUIRId4uk6rV9ETvt0HqX1OkShSAcW"
Archived-At: <https://mailarchive.ietf.org/arch/msg/i2rs/_yhnCsGOhI_JVHqON_5rpf6StEU>
X-Mailman-Approved-At: Fri, 19 Aug 2016 09:15:16 -0700
Cc: i2rs@ietf.org, 'Alissa Cooper' <alissa@cooperw.in>, 'Juergen Schoenwaelder' <j.schoenwaelder@jacobs-university.de>, i2rs-chairs@ietf.org, 'Kathleen Moriarty' <Kathleen.Moriarty.ietf@gmail.com>, 'IESG' <iesg@ietf.org>, 'Jeffrey Haas' <jhaas@pfrc.org>, 'Joel Halpern' <joel.halpern@ericsson.com>, 'Lou Berger' <lberger@labn.net>, draft-ietf-i2rs-protocol-security-requirements@ietf.org
Subject: Re: [i2rs] Kathleen Moriarty's Discuss on draft-ietf-i2rs-protocol-security-requirements-07: (with DISCUSS and COMMENT)
X-BeenThere: i2rs@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "Interface to The Internet Routing System \(IRS\)" <i2rs.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/i2rs>, <mailto:i2rs-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/i2rs/>
List-Post: <mailto:i2rs@ietf.org>
List-Help: <mailto:i2rs-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/i2rs>, <mailto:i2rs-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 19 Aug 2016 16:12:44 -0000
On 8/19/16 9:03 AM, Susan Hares wrote: > Andy/Kathleen: > > > > What do MTI and MTU standard for? Mandatory to implement / use > > > Sue > > > > *From:*i2rs [mailto:i2rs-bounces@ietf.org] *On Behalf Of *Andy Bierman > *Sent:* Friday, August 19, 2016 11:43 AM > *To:* Susan Hares > *Cc:* i2rs@ietf.org; Alissa Cooper; Juergen Schoenwaelder; > i2rs-chairs@ietf.org; Kathleen Moriarty; IESG; Jeffrey Haas; Joel > Halpern; Lou Berger; draft-ietf-i2rs-protocol-security-requirements@ietf.org > *Subject:* Re: [i2rs] Kathleen Moriarty's Discuss on > draft-ietf-i2rs-protocol-security-requirements-07: (with DISCUSS and > COMMENT) > > > > Hi, > > > > That is simple. > > There needs to be consensus on the syntax and semantics of each > > statement in the YANG module. > > > > Since security is MTI and MTU for NETCONF and RESTCONF, there > > is no point debating which objects are OK without security. > > > > Andy > > > > > > > > On Fri, Aug 19, 2016 at 7:59 AM, Susan Hares <shares@ndzh.com > <mailto:shares@ndzh.com>> wrote: > > 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:andy@yumaworks.com <mailto:andy@yumaworks.com>] > *Sent:* Friday, August 19, 2016 10:24 AM > *To:* Lou Berger > *Cc:* Susan Hares; Juergen Schoenwaelder; i2rs@ietf.org > <mailto:i2rs@ietf.org>; Alissa Cooper; i2rs-chairs@ietf.org > <mailto:i2rs-chairs@ietf.org>; Kathleen Moriarty; IESG; Jeffrey Haas; > Joel Halpern; draft-ietf-i2rs-protocol-security-requirements@ietf.org > <mailto:draft-ietf-i2rs-protocol-security-requirements@ietf.org> > *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 <lberger@labn.net > <mailto:lberger@labn.net>> 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:lberger@labn.net <mailto:lberger@labn.net>] >> Sent: Friday, August 19, 2016 7:34 AM >> To: Susan Hares; 'Juergen Schoenwaelder' >> Cc: i2rs@ietf.org <mailto:i2rs@ietf.org>; 'Alissa Cooper'; > i2rs-chairs@ietf.org <mailto:i2rs-chairs@ietf.org>; 'Kathleen Moriarty'; > 'IESG'; jhaas@pfrc.org <mailto:jhaas@pfrc.org>; 'Joel Halpern'; > draft-ietf-i2rs-protocol-security-requirements@ietf.org > <mailto:draft-ietf-i2rs-protocol-security-requirements@ietf.org> >> 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:j.schoenwaelder@jacobs-university.de > <mailto:j.schoenwaelder@jacobs-university.de>] >>> Sent: Friday, August 19, 2016 4:58 AM >>> To: Susan Hares >>> Cc: 'Alissa Cooper'; 'Joel Halpern'; i2rs@ietf.org > <mailto:i2rs@ietf.org>; >>> i2rs-chairs@ietf.org <mailto:i2rs-chairs@ietf.org>; 'Kathleen > Moriarty'; 'IESG'; jhaas@pfrc.org <mailto:jhaas@pfrc.org>; >>> draft-ietf-i2rs-protocol-security-requirements@ietf.org > <mailto:draft-ietf-i2rs-protocol-security-requirements@ietf.org> >>> 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:alissa@cooperw.in > <mailto:alissa@cooperw.in>] >>>> Sent: Thursday, August 18, 2016 12:54 PM >>>> To: Joel Halpern >>>> Cc: Susan Hares; Juergen Schoenwaelder; i2rs@ietf.org > <mailto:i2rs@ietf.org>; >>>> i2rs-chairs@ietf.org <mailto:i2rs-chairs@ietf.org>; Kathleen > Moriarty; IESG; jhaas@pfrc.org <mailto:jhaas@pfrc.org>; >>>> draft-ietf-i2rs-protocol-security-requirements@ietf.org > <mailto:draft-ietf-i2rs-protocol-security-requirements@ietf.org> >>>> 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 > <joel.halpern@ericsson.com <mailto:joel.halpern@ericsson.com>> 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:shares@ndzh.com <mailto:shares@ndzh.com>] >>>>> Sent: Thursday, August 18, 2016 9:17 AM >>>>> To: 'Juergen Schoenwaelder' <j.schoenwaelder@jacobs-university.de > <mailto:j.schoenwaelder@jacobs-university.de>> >>>>> Cc: i2rs@ietf.org <mailto:i2rs@ietf.org>; i2rs-chairs@ietf.org > <mailto:i2rs-chairs@ietf.org>; 'Kathleen Moriarty' >>>>> <Kathleen.Moriarty.ietf@gmail.com > <mailto:Kathleen.Moriarty.ietf@gmail.com>>; 'The IESG' <iesg@ietf.org > <mailto:iesg@ietf.org>>; >>>>> jhaas@pfrc.org <mailto:jhaas@pfrc.org>; >>>>> draft-ietf-i2rs-protocol-security-requirements@ietf.org > <mailto:draft-ietf-i2rs-protocol-security-requirements@ietf.org> >>>>> 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:j.schoenwaelder@jacobs-university.de > <mailto:j.schoenwaelder@jacobs-university.de>] >>>>> Sent: Thursday, August 18, 2016 9:06 AM >>>>> To: Susan Hares >>>>> Cc: i2rs@ietf.org <mailto:i2rs@ietf.org>; i2rs-chairs@ietf.org > <mailto:i2rs-chairs@ietf.org>; 'Kathleen Moriarty'; 'The >>>>> IESG'; jhaas@pfrc.org <mailto:jhaas@pfrc.org>; >>>>> draft-ietf-i2rs-protocol-security-requirements@ietf.org > <mailto:draft-ietf-i2rs-protocol-security-requirements@ietf.org> >>>>> 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:i2rs-bounces@ietf.org > <mailto:i2rs-bounces@ietf.org>] On Behalf Of Juergen >>>>>> Schoenwaelder >>>>>> Sent: Thursday, August 18, 2016 8:14 AM >>>>>> To: Susan Hares >>>>>> Cc: i2rs@ietf.org <mailto:i2rs@ietf.org>; i2rs-chairs@ietf.org > <mailto:i2rs-chairs@ietf.org>; 'Kathleen Moriarty'; 'The >>>>>> IESG'; jhaas@pfrc.org <mailto:jhaas@pfrc.org>; >>>>>> draft-ietf-i2rs-protocol-security-requirements@ietf.org > <mailto:draft-ietf-i2rs-protocol-security-requirements@ietf.org> >>>>>> 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:j.schoenwaelder@jacobs-university.de > <mailto:j.schoenwaelder@jacobs-university.de>] >>>>>>> Sent: Thursday, August 18, 2016 3:32 AM >>>>>>> To: Susan Hares >>>>>>> Cc: 'Kathleen Moriarty'; 'The IESG'; jhaas@pfrc.org > <mailto:jhaas@pfrc.org>; >>>>>>> i2rs@ietf.org <mailto:i2rs@ietf.org>; i2rs-chairs@ietf.org > <mailto:i2rs-chairs@ietf.org>; >>>>>>> draft-ietf-i2rs-protocol-security-requirements@ietf.org > <mailto:draft-ietf-i2rs-protocol-security-requirements@ietf.org> >>>>>>> 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 >>>>>>> i2rs@ietf.org <mailto:i2rs@ietf.org> >>>>>>> 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 >>>>>> i2rs@ietf.org <mailto:i2rs@ietf.org> >>>>>> 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 > i2rs@ietf.org <mailto:i2rs@ietf.org> > https://www.ietf.org/mailman/listinfo/i2rs > > > > >
- Re: [i2rs] Kathleen Moriarty's Discuss on draft-i… Susan Hares
- Re: [i2rs] Kathleen Moriarty's Discuss on draft-i… Alia Atlas
- Re: [i2rs] Kathleen Moriarty's Discuss on draft-i… William Atwood
- Re: [i2rs] Kathleen Moriarty's Discuss on draft-i… Susan Hares
- Re: [i2rs] Kathleen Moriarty's Discuss on draft-i… Andy Bierman
- Re: [i2rs] Kathleen Moriarty's Discuss on draft-i… Susan Hares
- Re: [i2rs] Kathleen Moriarty's Discuss on draft-i… joel jaeggli
- Re: [i2rs] Kathleen Moriarty's Discuss on draft-i… Kathleen Moriarty
- Re: [i2rs] Kathleen Moriarty's Discuss on draft-i… Susan Hares
- Re: [i2rs] Kathleen Moriarty's Discuss on draft-i… Susan Hares
- Re: [i2rs] Kathleen Moriarty's Discuss on draft-i… Susan Hares
- Re: [i2rs] Kathleen Moriarty's Discuss on draft-i… Andy Bierman
- Re: [i2rs] Kathleen Moriarty's Discuss on draft-i… Kathleen Moriarty
- Re: [i2rs] Kathleen Moriarty's Discuss on draft-i… Susan Hares
- Re: [i2rs] Kathleen Moriarty's Discuss on draft-i… Andy Bierman
- Re: [i2rs] Kathleen Moriarty's Discuss on draft-i… Spencer Dawkins at IETF
- Re: [i2rs] Kathleen Moriarty's Discuss on draft-i… Susan Hares
- Re: [i2rs] Kathleen Moriarty's Discuss on draft-i… Susan Hares
- Re: [i2rs] Kathleen Moriarty's Discuss on draft-i… Spencer Dawkins at IETF
- Re: [i2rs] Kathleen Moriarty's Discuss on draft-i… Susan Hares
- Re: [i2rs] Kathleen Moriarty's Discuss on draft-i… Lou Berger
- Re: [i2rs] Kathleen Moriarty's Discuss on draft-i… Susan Hares
- Re: [i2rs] Kathleen Moriarty's Discuss on draft-i… Susan Hares
- Re: [i2rs] Kathleen Moriarty's Discuss on draft-i… Lou Berger
- Re: [i2rs] Kathleen Moriarty's Discuss on draft-i… Susan Hares
- Re: [i2rs] Kathleen Moriarty's Discuss on draft-i… Kathleen Moriarty
- Re: [i2rs] Kathleen Moriarty's Discuss on draft-i… joel jaeggli
- Re: [i2rs] Kathleen Moriarty's Discuss on draft-i… Andy Bierman
- Re: [i2rs] Kathleen Moriarty's Discuss on draft-i… Andy Bierman
- Re: [i2rs] Kathleen Moriarty's Discuss on draft-i… Susan Hares
- Re: [i2rs] Kathleen Moriarty's Discuss on draft-i… kathleen.moriarty.ietf
- Re: [i2rs] Kathleen Moriarty's Discuss on draft-i… Juergen Schoenwaelder
- Re: [i2rs] Kathleen Moriarty's Discuss on draft-i… Andy Bierman
- Re: [i2rs] Kathleen Moriarty's Discuss on draft-i… Susan Hares
- Re: [i2rs] Kathleen Moriarty's Discuss on draft-i… Andy Bierman
- Re: [i2rs] Kathleen Moriarty's Discuss on draft-i… Susan Hares
- Re: [i2rs] Kathleen Moriarty's Discuss on draft-i… Susan Hares
- Re: [i2rs] Kathleen Moriarty's Discuss on draft-i… Alissa Cooper
- Re: [i2rs] Kathleen Moriarty's Discuss on draft-i… Susan Hares
- Re: [i2rs] Kathleen Moriarty's Discuss on draft-i… Joel Halpern
- Re: [i2rs] Kathleen Moriarty's Discuss on draft-i… Susan Hares
- Re: [i2rs] Kathleen Moriarty's Discuss on draft-i… Susan Hares
- Re: [i2rs] Kathleen Moriarty's Discuss on draft-i… Kathleen Moriarty
- Re: [i2rs] Kathleen Moriarty's Discuss on draft-i… Susan Hares
- Re: [i2rs] Kathleen Moriarty's Discuss on draft-i… Kathleen Moriarty
- Re: [i2rs] Kathleen Moriarty's Discuss on draft-i… Juergen Schoenwaelder
- Re: [i2rs] Kathleen Moriarty's Discuss on draft-i… Kathleen Moriarty
- Re: [i2rs] Kathleen Moriarty's Discuss on draft-i… Susan Hares
- Re: [i2rs] Kathleen Moriarty's Discuss on draft-i… Juergen Schoenwaelder
- Re: [i2rs] Kathleen Moriarty's Discuss on draft-i… Susan Hares
- Re: [i2rs] Kathleen Moriarty's Discuss on draft-i… Juergen Schoenwaelder
- Re: [i2rs] Kathleen Moriarty's Discuss on draft-i… Susan Hares
- Re: [i2rs] Kathleen Moriarty's Discuss on draft-i… Joel M. Halpern
- [i2rs] Kathleen Moriarty's Discuss on draft-ietf-… Kathleen Moriarty
- Re: [i2rs] Kathleen Moriarty's Discuss on draft-i… Susan Hares
- Re: [i2rs] Kathleen Moriarty's Discuss on draft-i… Juergen Schoenwaelder
- Re: [i2rs] Kathleen Moriarty's Discuss on draft-i… Susan Hares
- Re: [i2rs] Kathleen Moriarty's Discuss on draft-i… Kathleen Moriarty
- Re: [i2rs] Kathleen Moriarty's Discuss on draft-i… Susan Hares
- Re: [i2rs] Kathleen Moriarty's Discuss on draft-i… kathleen.moriarty.ietf
- Re: [i2rs] Kathleen Moriarty's Discuss on draft-i… Andy Bierman
- Re: [i2rs] Kathleen Moriarty's Discuss on draft-i… Jeffrey Haas
- Re: [i2rs] Kathleen Moriarty's Discuss on draft-i… Kathleen Moriarty
- Re: [i2rs] Kathleen Moriarty's Discuss on draft-i… Jeffrey Haas
- Re: [i2rs] Kathleen Moriarty's Discuss on draft-i… Kathleen Moriarty
- Re: [i2rs] Kathleen Moriarty's Discuss on draft-i… Susan Hares
- Re: [i2rs] Kathleen Moriarty's Discuss on draft-i… Andy Bierman
- Re: [i2rs] Kathleen Moriarty's Discuss on draft-i… Susan Hares
- Re: [i2rs] Kathleen Moriarty's Discuss on draft-i… Susan Hares
- Re: [i2rs] Kathleen Moriarty's Discuss on draft-i… Andy Bierman
- Re: [i2rs] Kathleen Moriarty's Discuss on draft-i… Juergen Schoenwaelder
- Re: [i2rs] Kathleen Moriarty's Discuss on draft-i… Jeffrey Haas