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

"Susan Hares" <shares@ndzh.com> Thu, 18 August 2016 13:17 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 EB59E12D747; Thu, 18 Aug 2016 06:17:57 -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 nJTkQGgsBCuK; Thu, 18 Aug 2016 06:17:56 -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 CB91B12DE19; Thu, 18 Aug 2016 06:17:55 -0700 (PDT)
X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=174.124.167.170;
From: "Susan Hares" <shares@ndzh.com>
To: "'Juergen Schoenwaelder'" <j.schoenwaelder@jacobs-university.de>
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>
In-Reply-To: <20160818130555.GA5366@elstar.local>
Date: Thu, 18 Aug 2016 09:16:44 -0400
Message-ID: <051701d1f952$c4ae0b30$4e0a2190$@ndzh.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQIa7Lz6VgZw6h2A0uGNzOgAA2Ic8QJ/RF5yARxv/coCD6d0AAIDKkFTAYlI9/gCaK/wXJ9fxVgQ
Content-Language: en-us
X-Authenticated-User: skh@ndzh.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/i2rs/TYnnE2B0ABZzSqLqCopYoFJAH1M>
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)
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: Thu, 18 Aug 2016 13:17:58 -0000

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