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 11:40 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 3805D12DDFE; Fri, 19 Aug 2016 04:40:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.738
X-Spam-Level: *
X-Spam-Status: No, score=1.738 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, 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 f0CBkOLQLT_L; Fri, 19 Aug 2016 04:40:45 -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 76A2812DA77; Fri, 19 Aug 2016 04:40:44 -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: "'Kathleen Moriarty'" <kathleen.moriarty.ietf@gmail.com>
References: <147146974235.23784.4389421535496134619.idtracker@ietfa.amsl.com> <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> <CABCOCHS-72KK0VgUARynb_19YLA5oM1g1odSLpezuBrq=+dmqg@mail.gmail.com> <00dc01d1f988$f2cec280$d86c4780$@ndzh.com> <CABCOCHTSjeipwFsNvYZssDayu9axg=g=6mwmyxxfCvCyWfw0Fw@mail.gmail.com> <012e01d1f98b$ec9d09a0$c5d71ce0$@ndzh.com> <CAHbuEH6B8xj5U8S6ccMeW9zxtS4mUmy00sVD5PhWwnMvkFj7ZA@mail.gmail.com>
In-Reply-To: <CAHbuEH6B8xj5U8S6ccMeW9zxtS4mUmy00sVD5PhWwnMvkFj7ZA@mail.gmail.com>
Date: Fri, 19 Aug 2016 07:39:22 -0400
Message-ID: <026c01d1fa0e$551e72c0$ff5b5840$@ndzh.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQIa7Lz6VgZw6h2A0uGNzOgAA2Ic8QJ/RF5yARxv/coCD6d0AAIDKkFTAYlI9/gCaK/wXAMksAaNAmoTFCQCp9Oi8AIQlOgDAIZjbI0CaGRfrQGPw5JeAkOaiKwBgcGFUp7M2hJg
Content-Language: en-us
X-Authenticated-User: skh@ndzh.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/i2rs/-vkPZkiPVAYRJkJBElUE8B32-3s>
X-Mailman-Approved-At: Fri, 19 Aug 2016 04:59:48 -0700
Cc: i2rs@ietf.org, 'Alissa Cooper' <alissa@cooperw.in>, 'Juergen Schoenwaelder' <j.schoenwaelder@jacobs-university.de>, 'Andy Bierman' <andy@yumaworks.com>, i2rs-chairs@ietf.org, 'IESG' <iesg@ietf.org>, 'Jeffrey Haas' <jhaas@pfrc.org>, 'Joel Halpern' <joel.halpern@ericsson.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 11:40:47 -0000

Kathleen: 

Thank you for your suggestions.  See below for the modification. 

Sue 

-----Original Message-----
From: Kathleen Moriarty [mailto:kathleen.moriarty.ietf@gmail.com] 
Sent: Thursday, August 18, 2016 8:47 PM
To: Susan Hares
Cc: Andy Bierman; Alissa Cooper; Joel Halpern; i2rs@ietf.org; Juergen Schoenwaelder; i2rs-chairs@ietf.org; IESG; Jeffrey Haas; 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 think there are some easy tweaks that could make everyone happy.  We should be focusing on MTI, not MTU for requirements so that operators can make decisions as needed.  I think we can all agree with that statement.  We are worried about a few areas of text in the document, namely where the data model can trigger the use of an insecure transport.  The default is a secure transport for the protocol, so that is MTI across the board.  One of the sections that causes concern is the following:

[please define:  MTI/MTU] 


>Section 3: (I think the latest proposed text)
>
>  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.

The latest text from -08.txt is: 

>The security for the I2RS protocol requires mutually authenticated I2RS 
>clients and I2RS agents. The I2RS client and I2RS agent using the I2RS 
>protocol MUST be able to exchange data over a secure transport.  
>Optionally, the I2RS Client and I2RS agent MAY operate on a non-secure 
>transport to transfer a specific set of non-confidential data
 
Alvaro made the point this text was redundant. I agreed and suggested it be removed -09.txt.
Does this satisfy you.  

===================

>Which doesn't exactly meet the stated requirement in Section 3.2:
>
>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.

> I think if we reword the text in section 3 as follows, the requirement for support of a secure transport will be clear, a way to mark the data model for the possible use of insecure > transport is possible (decision of the operator).
> 
> How about:
>    I2RS allows the use of an insecure transport for portions of data
>    models that clearly indicate data confidentiality and integrity protection may not be necessary.
>    Operators deploying I2RS must determine if they want to populate and
>   deploy the portions of the data model with a configuration option to use insecure transports.
> 
> I understand this changes your requirements a bit and your implementation, but is this a way that we could allow some operators to operate in a secure mode for this data if they choose and also allow MTU to be less than the default?
> 

Sue: Would removal of this text work instead?  As Alvaro pointed out, it is redundant to SEC-REQ-08. 
I agreed to remove that text which results in: 

The Start of section 3 would be: 

   The security for the I2RS protocol requires mutually authenticated
   I2RS clients and I2RS agents communicating over a secure transport.  
   The I2RS protocol MUST be able to provide atomicity of an I2RS
   transaction, but it is not required to have multi-message atomicity
   and roll-back mechanism transactions.  Multiple messages transactions
   may be impacted by the interdependency of data.  This section
   discusses the details of these security requirements.
=====================================

>If that's agreeable - with the other ADs too - then some more text in section 3.2 needs to be tweaked in a similar way.
>
>The text in section 3.2 is closer to what I am proposing, you have the sentence:
>
> 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.
>
>This talks about the data being marked in terms of a need for confidentiality (should be integrity too as I could corrupt a clear text stream in a way that is not detectable) instead >of explicitly stating that the transport should be insecure.  If the data model had a attribute that had this marking (operator driven), I think that's an improvement.

>How about:
>
> A non-secure transport can be used for publishing telemetry data or
>  other operational state that was specifically indicated as non-
>  confidential and does not require integrity protection through an
>  option provided in the data model.
>
>I think this text allows for the WG goal of using a data model to indicate the transport option, but for it to be an operator driven decision in case some operators prefer to use >transport encryption for this section of the data model... or things change and they all decide this is a good idea.

Technical point:  The phrase: 
  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.

This text always implied to the WG that the operator could always elect to send the non-secure marked portion of a data model over secure transport.  Therefore, I am happy you want to emphasize this technical issue in the text.  I think we are aligned on this higher issue.   However, this alternate text has a problem. 

 Textual comments: The reason we stated:  

   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.

  And 

   The default mode of transport is
   secure so data models SHOULD clearly annotate what data nodes can be
   passed over an insecure connection.

Is to provide precise requirements for the NETCONF/NETMOD WG with whom the I2RS WG to whom the 
I2RS WG will send these initial comments.  Your text does not provide that precise instruction. 

How about this version for SEC-REQ-08:


   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 may optionally 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.  
   Since the non-secure transport is optional, an operator may set an option 
   to send the data marked "non-secure" in the Yang syntax 
   over a secure transport.    

   The following are further restrictions on this optionally non-secure transport: 

   1) The configuration of ephemeral data in the I2RS Agent by the I2RS
   client SHOULD be done over a secure transport.
 
   2)  It is anticipated  that the passing of most I2RS ephemeral state operational status
   SHOULD be done over a secure transport.  

   3) As [I-D.ietf-i2rs-ephemeral-state] notes 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.   
-------
Does this refinement of the text make it clear the operator can always turn 
on the secure transport? 

> I'll get back to the other responses to my comments and discuss in a separate message (possibly tomorrow).
>
> If this alters discussions from other threads, please point me to the thread and I'll catch up.

I've pointed you at Alvaro message. 

------------------
Thanks,
Kathleen

Thank you Kathleen.   This  helped!


On Thu, Aug 18, 2016 at 4:05 PM, Susan Hares <shares@ndzh.com> wrote:
> Andy:
>
>
>
> If we create a yang data model that is insecure, and mount on another data
> model – does it have the same issue as module augmentation?   Of course, we
> could create a mount point for all insecure data modules, and all data 
> placed under that mount point – would be insecure.
>
>
>
> For the BGP route-views use case, this would make it clear that data 
> had to be transformed to be insecure transmission.
>
>
>
> Sue
>
>
>
> From: Andy Bierman [mailto:andy@yumaworks.com]
> Sent: Thursday, August 18, 2016 4:02 PM
>
>
> To: Susan Hares
> Cc: Alissa Cooper; Joel Halpern; i2rs@ietf.org; Juergen Schoenwaelder; 
> i2rs-chairs@ietf.org; Kathleen Moriarty; IESG; Jeffrey Haas; 
> 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 Thu, Aug 18, 2016 at 12:44 PM, Susan Hares <shares@ndzh.com> wrote:
>
> Andy:
>
>
>
> Thank you – I thought it was on whether we could implement insecure 
> transport in a Yang module.
>
>
>
> The requirement text you are working with is:
>
>
>
>    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.
>
>
>
> I do not understand why approving the ok for non-secure transport for 
> some modules means the following to you:
>
>
>
> “ the IETF needs to agree that there could never possibly be any 
> deployment that would not want to allow exposure of the data.
>
> Not now. Not 20 years from now.”
>
>
>
>
>
>
>
> As I understand it, this requirement has another requirement 
> associated with it
>
> that says the data has to be identified as OK-for-nonsecure-transport.
>
>
>
> An extension in the data model says that all instances of the object 
> in
>
> all possible deployments cannot be considered sensistive and therefore
>
> needs disclosure protection.
>
>
>
> It may seem like even a simple octet counter is safe to send in the 
> clear,
>
> but not if that opens up correlation attacks.  (e.g., I can send data 
> to some
>
> host.  I can see that index 455992 is incrementing the in-octets 
> counters
>
> in a way that strongly correlates to my test traffic.  Therefore I can 
> learn
>
> that arbitrary index 455992 is really John Doe or really suite #14, etc.
>
>
>
>
>
> I had thought that the security-directorate and other reviewers would 
> look at each module that is insecure, and  consider whether it was reasonable for
> the use case at this time.   This is what I understood from Russ Housley’s
> first review of this technology.  Since like you, I believe the operator is
> going to  configure what modules are allowed on systems.   I agree that this
> requirement provides a full scope of the work, but implementers will 
> require network operators to configure these features on.
>
>
>
> Sue
>
>
>
> Andy
>
>
>
>
>
>
>
> From: Andy Bierman [mailto:andy@yumaworks.com]
> Sent: Thursday, August 18, 2016 2:53 PM
> To: Susan Hares
> Cc: Alissa Cooper; Joel Halpern; i2rs@ietf.org; Juergen Schoenwaelder; 
> i2rs-chairs@ietf.org; Kathleen Moriarty; IESG; Jeffrey Haas; 
> 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 did not think Juergen's comment was about running code.
>
>
>
> In order for a data node to get the "ok-for-nonsecure-transports" 
> approval
>
> in an IETF module, the IETF needs to agree that there could never 
> possibly be
>
> any deployment that would not want to allow exposure of the data.
>
> Not now. Not 20 years from now.
>
>
>
> I can see a vendor making that decision for their own proprietary 
> modules,
>
> but it seems less likely for standard modules.
>
>
>
> Seems like the operator is going to have to configure what is allowed
>
> for nonsecure transport anyway, so just let them decide.
>
> I don't really object to the extension or the requirement.
>
> It doesn't help much but it doesn't hurt much either.
>
>
>
>
>
> Andy
>
>
>
>
>
>
>
> On Thu, Aug 18, 2016 at 11:35 AM, Susan Hares <shares@ndzh.com> 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
>
>
>
>



-- 

Best regards,
Kathleen