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
> 
>  
> 
>  
>