Re: [i2rs] Kathleen Moriarty's Discuss on draft-ietf-i2rs-protocol-security-requirements-07: (with DISCUSS and COMMENT)

"Susan Hares" <shares@ndzh.com> Fri, 19 August 2016 16:57 UTC

Return-Path: <shares@ndzh.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 A9C2812D0C6; Fri, 19 Aug 2016 09:57:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.739
X-Spam-Level: *
X-Spam-Status: No, score=1.739 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, RDNS_NONE=0.793] autolearn=no 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 g4j3TySOkoar; Fri, 19 Aug 2016 09:57:39 -0700 (PDT)
Received: from hickoryhill-consulting.com (unknown [50.245.122.97]) (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 901C812B025; Fri, 19 Aug 2016 09:57:38 -0700 (PDT)
X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=184.157.82.170;
From: "Susan Hares" <shares@ndzh.com>
To: "'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> <001501d1fa30$46d0ac70$d4720550$@ndzh.com> <CABCOCHSO=oK+dzxOoAqngF45-+Nu47Gv3gc8LZt0ZsW5vpVjhA@mail.gmail.com>
In-Reply-To: <CABCOCHSO=oK+dzxOoAqngF45-+Nu47Gv3gc8LZt0ZsW5vpVjhA@mail.gmail.com>
Date: Fri, 19 Aug 2016 12:55:53 -0400
Message-ID: <00e701d1fa3a$8cf41a70$a6dc4f50$@ndzh.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_00E8_01D1FA19.05E7AA90"
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQJ/RF5y8kBC7R3sO+auWKe566R2lwEcb/3KAg+ndAACAypBUwGJSPf4Amiv8FwDJLAGjQJqExQkAqfTovACEJToAwFDCzFbAlTVyfQCrq8/9AJKcpLBAq9whFMCDwN3eQIvrQjwAMUBZUsCRhcJ253GViOg
Content-Language: en-us
X-Authenticated-User: skh@ndzh.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/i2rs/MAyIGR0uLkgoSUdMB9qOW9Xn-8o>
X-Mailman-Approved-At: Fri, 19 Aug 2016 10:01:34 -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:57:43 -0000

Andy: 

 

The easy of reviewing per leaf – is why I suggested the per leaf.  

I also agree it is important to mention this non-secure/secure requirement to the PUSH work team we are both on. 

 

Should I change: 

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

   confidential in the data model. /

 

 

Sue 

 

From: Andy Bierman [mailto:andy@yumaworks.com] 
Sent: Friday, August 19, 2016 12:32 PM
To: Susan Hares
Cc: Lou Berger; 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)

 

 

 

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] 
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-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]
>>>> 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>om>; 'The IESG' <iesg@ietf.org>rg>;
>>>> 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