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

"Susan Hares" <shares@ndzh.com> Tue, 23 August 2016 16:33 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 E19E212D550; Tue, 23 Aug 2016 09:33:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.957
X-Spam-Level:
X-Spam-Status: No, score=0.957 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_BL=0.01, RCVD_IN_MSPIKE_L5=0.001] 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 sKWc0Stty6SQ; Tue, 23 Aug 2016 09:33:10 -0700 (PDT)
Received: from hickoryhill-consulting.com (50-245-122-97-static.hfc.comcastbusiness.net [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 B441612D59F; Tue, 23 Aug 2016 09:33:09 -0700 (PDT)
X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=74.43.47.166;
From: "Susan Hares" <shares@ndzh.com>
To: "'Andy Bierman'" <andy@yumaworks.com>, "'Juergen Schoenwaelder'" <j.schoenwaelder@jacobs-university.de>, "'Lou Berger'" <lberger@labn.net>, <i2rs@ietf.org>, "'Alissa Cooper'" <alissa@cooperw.in>, <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>, <draft-ietf-i2rs-protocol-security-requirements@ietf.org>
References: <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> <00e701d1fa3a$8cf41a70$a6dc4f50$@ndzh.com> <20160822100738.GA12248@elstar.local> <CABCOCHQaj=Q5hX1v_vzR9KyEFVXeYw3ejPPodJzFinNh2XZbqA@mail.gmail.com>
In-Reply-To: <CABCOCHQaj=Q5hX1v_vzR9KyEFVXeYw3ejPPodJzFinNh2XZbqA@mail.gmail.com>
Date: Tue, 23 Aug 2016 12:31:39 -0400
Message-ID: <0f2501d1fd5b$d3cddbb0$7b699310$@ndzh.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0F26_01D1FD3A.4CBD7430"
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQFDCzFbX6CMUYXOBAS3fGQAhaIB3wJU1cn0Aq6vP/QCSnKSwQKvcIRTAg8Dd3kCL60I8ADFAWVLAkYXCdsCCOmClAIqM4lcAovteGagtG1yAA==
Content-Language: en-us
X-Authenticated-User: skh@ndzh.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/i2rs/KEaWu-fPgueSQXnkTLPQbFoMq6I>
X-Mailman-Approved-At: Tue, 23 Aug 2016 10:00:45 -0700
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: Tue, 23 Aug 2016 16:33:12 -0000

Andy: 

 

Rather than state “data model as 'non-confidential' remains a flawed” in the abstract, can we simply discuss the specifics I listed? 

 

1)      BGP information publically sent as part of route-views

Sent as an  event stream from an I2RS client 

 

2)      Web server “up” messages sent as an event 

With the text similar to:   “go-to-me.com web server is up”  where “go-to-me” is a public name. 

 

Please consider in terms of an Event stream model we are working in the push.  Remember the configuration of the stream is via secure servers, and what we are talking about is listeners to the stream.  

 

Sue Hares         

 

From: Andy Bierman [mailto:andy@yumaworks.com] 
Sent: Monday, August 22, 2016 1:07 PM
To: Juergen Schoenwaelder; Susan Hares; Andy Bierman; Lou Berger; 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)

 

 

 

On Mon, Aug 22, 2016 at 3:07 AM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:

On Fri, Aug 19, 2016 at 12:55:53PM -0400, Susan Hares wrote:
> 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. /
>

Tagging something in the data model as 'non-confidential' remains a
flawed idea. What can be considered 'non-confidential' depends on the
deployment scenario. It is even worse to standardize some piece of
information as 'non-confidential'. How can the IETF claim that
something is always 'non-confidential'? (And note, a non-secure
transport is not just about confidentiality, it also implies that
boxes on the path can arbitrarily change the information.)

 

This additional note is quite interesting.

It is 1 thing to decide if the data is public info or not.

(Assume security guidelines could be provided that clearly define that.)

 

It is quite another to say "it's OK if the monitoring data gets modified in flight".

I can't imagine any use-cases for that.

 

 

In case this is not clear: What we have done for ~30 years is to have
the decision which information goes into an insecure transport be
taken by an access control model. This makes the decision runtime
configurable and thus things can be deployment specific. This has
worked for 30 years and I have no problem with this. What I am
struggling with is the idea to standardize parts of YANG data models
as 'non-confidential'.

/js

 

 

Andy

 

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