Re: [i2rs] Kathleen Moriarty's Discuss on draft-ietf-i2rs-protocol-security-requirements-07: (with DISCUSS and COMMENT)
Alia Atlas <akatlas@gmail.com> Fri, 19 August 2016 20:29 UTC
Return-Path: <akatlas@gmail.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 C487012D7D0; Fri, 19 Aug 2016 13:29:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.999
X-Spam-Level:
X-Spam-Status: No, score=-101.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 LmO4EstffPFH; Fri, 19 Aug 2016 13:29:26 -0700 (PDT)
Received: from mail-ua0-x230.google.com (mail-ua0-x230.google.com [IPv6:2607:f8b0:400c:c08::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 50C6B12D781; Fri, 19 Aug 2016 13:29:26 -0700 (PDT)
Received: by mail-ua0-x230.google.com with SMTP id 97so99158962uav.3; Fri, 19 Aug 2016 13:29:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=vCYJBZ/egpNBu9rDMrBzPA+fl+z8HORH5O46LxZfdR0=; b=h8Q4BhliNjnnmxKXgNBBJoJplkPflfS5kDvA2E8BmgZ3G97nT56EoruklPiqnBKAxt unghMLcOgxKvagUU6FBv7JEIPKDu3gd8WRlhyYiq2YVFHw4WUjgSavV7pxgShD4RX1O/ m43tVrAgmevoySE9WIz7X9kB7VIgaDqrh0QKK6curKSmiLA3oWUuG54x56bDJUVUilGy e+84FzfcuSh0xgkfRkAoulAC27wKF+faw0aQbSZQlKnQT0riiSUNvCelhnqdoGO66xDQ nhie6aHsvxUEQerqajXBFVCQdRqskBdTbUm6WPawuSPb7jdcaGVj6nSHPnQnK93ufqAK S4Lw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=vCYJBZ/egpNBu9rDMrBzPA+fl+z8HORH5O46LxZfdR0=; b=eiHq2JlWBrneHui/k/hCNzmSYUxC7oPOjam4exi/KTnH82C0s7/tRwU5/zq33UJf58 8ATMu5HJKsgp7FUCHwUBc6sOZLxoMrSirQYeLmrXEyahpwQUZPTsqS+N2GTq7lJ9lbOA 7GppkbwDnZ1SuM+BE6EbYc/FNi/FQe2kJkkECd3HptI2FqZd+bg+jP+rlKzk088QOVVX I+0kiLflU8b8uPCk3hJCIgV0dvxoK0aa/CUtTCDL1iuKalEk8sRO60qdwgnuVAD5slY7 vFpQy2oHUNYz7HZaKGS1iataKERU0ucn66wE6mR6eNvgPkptg2GShl1ObATasNhWCz/3 Yf8g==
X-Gm-Message-State: AEkoousdKh6yDR0l50gnmB6zT/7GRkvAIsefrmf6ytLcMrbBP2XfpoIXg5AVYunPQsWuqeHwznJS32k8lYbFxQ==
X-Received: by 10.176.1.167 with SMTP id 36mr5261834ual.140.1471638565170; Fri, 19 Aug 2016 13:29:25 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.103.50.7 with HTTP; Fri, 19 Aug 2016 13:29:23 -0700 (PDT)
In-Reply-To: <CABCOCHSO=oK+dzxOoAqngF45-+Nu47Gv3gc8LZt0ZsW5vpVjhA@mail.gmail.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> <001501d1fa30$46d0ac70$d4720550$@ndzh.com> <CABCOCHSO=oK+dzxOoAqngF45-+Nu47Gv3gc8LZt0ZsW5vpVjhA@mail.gmail.com>
From: Alia Atlas <akatlas@gmail.com>
Date: Fri, 19 Aug 2016 16:29:23 -0400
Message-ID: <CAG4d1rd5qdire3QjmKZiVzHCNxmyP7inQjKQddDzF2pVG=xZCQ@mail.gmail.com>
To: Andy Bierman <andy@yumaworks.com>
Content-Type: multipart/alternative; boundary="001a1135de1cea3415053a728d55"
Archived-At: <https://mailarchive.ietf.org/arch/msg/i2rs/pIsqW-W3PRc20zmel5KYJc3C5BQ>
X-Mailman-Approved-At: Fri, 19 Aug 2016 14:04:58 -0700
Cc: "i2rs@ietf.org" <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>, Susan Hares <shares@ndzh.com>, 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 20:29:32 -0000
First, to be very clear. This document has WG consensus - confirmed over multiple WGLCs - in the I2RS WG. This thread is to resolve the concerns expressed by the ADs about specific aspects of this document. Second, by having a requirement for indicating in the model - whether for the whole model or per leaf - that the data may be sent over an insecure transport, this encourages limiting the standard use of an insecure transport to exactly those models or data that requires it for a given use-case. I do see this as limited to certain types of use-cases and the ability to mount a model differently allows the flexibility of describing a particular model as acceptable for insecure transport rather than requiring a leaf-by-leaf indication. The use of insecure transport is to accommodate use-cases that were not in the scope initially considered for NetConf/RestConf. Regards, Alia On Fri, Aug 19, 2016 at 12:32 PM, Andy Bierman <andy@yumaworks.com> wrote: > > > On Fri, Aug 19, 2016 at 8:42 AM, Susan Hares <shares@ndzh.com> wrote: > >> Andy: >> >> >> >> I have been thinking about your question for 30 minutes. Let me put >> down a few of my personal opinions: >> >> >> >> 1) Most (99%) of the ephemeral data models will not allow >> non-secure transport. >> >> 2) If any ephemeral data models have an insecure section, the >> review and consensus for a standards model should take longer. >> >> I hope we can streamline the normal Yang model review. [It would be nice >> to streamline features additions for NETCONF/RESTCONF as well]. >> >> >> > > I hope you are right that it will almost always be easy for a WG > to decide this issue for each leaf. > > We already have "security tagging" in NACM, and this has not caused delays. > This is the opposite decision -- Is this data so sensitive that the NACM > default > access control needs to block writes (nacm:default-deny-write) or block > all access > (nacm:default-deny-all)? > > These extensions are used in ietf-system.yang, not just in the NACM RFC. > They can be used anywhere and a NACM implementation MUST enforce > the extension semantics. > > If YANG Push had similar requirements (i.e, MUST NOT send data in the clear > that is not tagged with the appropriate extension) and the review criteria > is clear, > then this approach should be OK. > > > Andy > > > 3) I prefer to have the non-secure sections of a data model moved to >> a separate date model, and the data model marked as insecure. >> >> [I do not know if we could use the library function to mark the data >> model in meta-language.] >> >> However, until we complete the mount schema work – I do not know if this >> is workable. >> >> >> >> Would it help if I changed version -08 to >> >> Old/ >> >> 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. / >> >> New:/ >> >> A non-secure transport can be used for publishing telemetry data or >> other >> >> Operational state that was specifically indicated to be >> non-confidential in the data model. >> >> / >> >> >> >> Sue >> >> >> >> >> >> *From:* i2rs [mailto:i2rs-bounces@ietf.org] *On Behalf Of *Susan Hares >> *Sent:* Friday, August 19, 2016 10:59 AM >> *To:* 'Andy Bierman'; 'Lou Berger' >> *Cc:* i2rs@ietf.org; 'Alissa Cooper'; 'Juergen Schoenwaelder'; >> i2rs-chairs@ietf.org; 'Kathleen Moriarty'; 'IESG'; 'Jeffrey Haas'; 'Joel >> Halpern'; 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) >> >> >> >> 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 <andy@yumaworks.com>] >> *Sent:* Friday, August 19, 2016 10:24 AM >> *To:* Lou Berger >> *Cc:* Susan Hares; Juergen Schoenwaelder; i2rs@ietf.org; Alissa Cooper; >> i2rs-chairs@ietf.org; Kathleen Moriarty; IESG; Jeffrey Haas; Joel >> Halpern; 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> 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] >> > Sent: Friday, August 19, 2016 7:34 AM >> > To: Susan Hares; 'Juergen Schoenwaelder' >> > Cc: i2rs@ietf.org; 'Alissa Cooper'; i2rs-chairs@ietf.org; 'Kathleen >> Moriarty'; 'IESG'; jhaas@pfrc.org; 'Joel Halpern'; >> 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] >> >> Sent: Friday, August 19, 2016 4:58 AM >> >> To: Susan Hares >> >> Cc: 'Alissa Cooper'; 'Joel Halpern'; i2rs@ietf.org; >> >> i2rs-chairs@ietf.org; 'Kathleen Moriarty'; 'IESG'; jhaas@pfrc.org; >> >> 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] >> >>> Sent: Thursday, August 18, 2016 12:54 PM >> >>> To: Joel Halpern >> >>> Cc: Susan Hares; Juergen Schoenwaelder; i2rs@ietf.org; >> >>> i2rs-chairs@ietf.org; Kathleen Moriarty; IESG; jhaas@pfrc.org; >> >>> 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> 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:shares@ndzh.com] >> >>>> Sent: Thursday, August 18, 2016 9:17 AM >> >>>> To: 'Juergen Schoenwaelder' <j.schoenwaelder@jacobs-university.de> >> >>>> Cc: i2rs@ietf.org; i2rs-chairs@ietf.org; 'Kathleen Moriarty' >> >>>> <Kathleen.Moriarty.ietf@gmail.com>; 'The IESG' <iesg@ietf.org>; >> >>>> jhaas@pfrc.org; >> >>>> 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] >> >>>> Sent: Thursday, August 18, 2016 9:06 AM >> >>>> To: Susan Hares >> >>>> Cc: i2rs@ietf.org; i2rs-chairs@ietf.org; 'Kathleen Moriarty'; 'The >> >>>> IESG'; jhaas@pfrc.org; >> >>>> 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] On Behalf Of Juergen >> >>>>> Schoenwaelder >> >>>>> Sent: Thursday, August 18, 2016 8:14 AM >> >>>>> To: Susan Hares >> >>>>> Cc: i2rs@ietf.org; i2rs-chairs@ietf.org; 'Kathleen Moriarty'; 'The >> >>>>> IESG'; jhaas@pfrc.org; >> >>>>> 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] >> >>>>>> Sent: Thursday, August 18, 2016 3:32 AM >> >>>>>> To: Susan Hares >> >>>>>> Cc: 'Kathleen Moriarty'; 'The IESG'; jhaas@pfrc.org; >> >>>>>> i2rs@ietf.org; i2rs-chairs@ietf.org; >> >>>>>> 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 >> >>>>>> 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 >> >>>>> 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 >> 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