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

Alissa Cooper <alissa@cooperw.in> Thu, 18 August 2016 16:54 UTC

Return-Path: <alissa@cooperw.in>
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 90DAA12DA71; Thu, 18 Aug 2016 09:54:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.721
X-Spam-Level:
X-Spam-Status: No, score=-2.721 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cooperw.in header.b=FE06YrAW; dkim=pass (1024-bit key) header.d=messagingengine.com header.b=r8AntMNf
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 xVvheuF8L2bH; Thu, 18 Aug 2016 09:53:57 -0700 (PDT)
Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BED9512D1ED; Thu, 18 Aug 2016 09:53:57 -0700 (PDT)
Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 1654E2045E; Thu, 18 Aug 2016 12:53:57 -0400 (EDT)
Received: from frontend2 ([10.202.2.161]) by compute3.internal (MEProxy); Thu, 18 Aug 2016 12:53:57 -0400
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=cooperw.in; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-sasl-enc :x-sasl-enc; s=mesmtp; bh=jE3LuIFbeCLqCngZ3V8LRosWWC8=; b=FE06Yr AWqYWsVvBlx50YEpCPrvZe6sCJW4LvkfM5hv+dIUqjpt0UwpHnZkKb4fpNTiC/u6 5JIlftmwA1bSCOp2UEZpv/goyfx6Capm1jFH8zCrAWSvkFHZFVyfUA5XVQT+6vAg VvGeBmvL4pP+5rslKw5766xsLAT8t7Fn9ozLE=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=jE3LuIFbeCLqCng Z3V8LRosWWC8=; b=r8AntMNfzIG7ZR9kHI3NeH56HjApREYKp/AM1yzBx88R7Zi WY57YEj9h3eSI8MUDhf6Gl69pL/w4g1bVTv04Ew+kNmUbjett0/D+sFhVE46QsSQ wWr9ddfq1iaYBCAZmJaTmtgJLRP1Kfu4Jdru9XbGfRffoF6141lmPc4esDHU=
X-Sasl-enc: 0efvjAsgr2KdWK5YTvSpxSvteV/x8f++6nVV6UlS544G 1471539236
Received: from sjc-alcoop-8813.cisco.com (unknown [128.107.241.179]) by mail.messagingengine.com (Postfix) with ESMTPA id 3679DCCD83; Thu, 18 Aug 2016 12:53:55 -0400 (EDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Alissa Cooper <alissa@cooperw.in>
In-Reply-To: <6BCE198E4EAEFC4CAB45D75826EFB0761525CCD7@eusaamb101.ericsson.se>
Date: Thu, 18 Aug 2016 12:53:53 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <F8C205FB-665C-422C-B991-2F97F75CAE42@cooperw.in>
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>
To: Joel Halpern <joel.halpern@ericsson.com>
X-Mailer: Apple Mail (2.3124)
Archived-At: <https://mailarchive.ietf.org/arch/msg/i2rs/DlX4roR5CQ-nTKoggRu51GWuo7Y>
Cc: "i2rs@ietf.org" <i2rs@ietf.org>, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>, "i2rs-chairs@ietf.org" <i2rs-chairs@ietf.org>, Kathleen Moriarty <Kathleen.Moriarty.ietf@gmail.com>, IESG <iesg@ietf.org>, "jhaas@pfrc.org" <jhaas@pfrc.org>, Susan Hares <shares@ndzh.com>, "draft-ietf-i2rs-protocol-security-requirements@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)
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 16:54:35 -0000

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

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