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

Andy Bierman <andy@yumaworks.com> Tue, 23 August 2016 17:08 UTC

Return-Path: <andy@yumaworks.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 6261F12D620 for <i2rs@ietfa.amsl.com>; Tue, 23 Aug 2016 10:08:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com
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 5r6U4AXniyLQ for <i2rs@ietfa.amsl.com>; Tue, 23 Aug 2016 10:08:48 -0700 (PDT)
Received: from mail-ua0-x22c.google.com (mail-ua0-x22c.google.com [IPv6:2607:f8b0:400c:c08::22c]) (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 692DD12D627 for <i2rs@ietf.org>; Tue, 23 Aug 2016 10:08:40 -0700 (PDT)
Received: by mail-ua0-x22c.google.com with SMTP id n59so255665572uan.2 for <i2rs@ietf.org>; Tue, 23 Aug 2016 10:08:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=X+Z4SPR2kcNLEg4mnXjFKQ0kMj55w1AriUfJqhGFl7k=; b=oWSewiAhMeP9rx8odNA9NVNANJR0zC3hlnZJMCHnF4olj+XgllPHoZv3LNmkp55faE tyD3vccmC/ITZBkzb0h353/4AOgzeFkxtWkKXfYIDLOenoeVdYNf/q6bned6ocher+ML DWlTqyv36hBFzA6oLKUYnYcDWvfI2IgLnwaE49rdHk6xHtaqNntgc8Y7mJ+/mMHp1lRW HlFqt++fRItQbYYcI07J1i77CL0A1KSqdkF6IBWEpR8vgVezXmCum8gDdNTO9oST3LtG UAhrflJpftC5z5CwZG1aI2yVUi+Z4mAFm5NlnRATHBqa3/eZ0jf/Sc+jeXSA6cDaJtzU grpw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=X+Z4SPR2kcNLEg4mnXjFKQ0kMj55w1AriUfJqhGFl7k=; b=T6yKTtYjSoS1hHc73m2Xh9J24J2Ht2Zsek9koNQsgdZxPU8swDBzEJ8m5hTHWKbJvY EZy/dybnpoels5BrCMkmfuKBO8VZ+VO6oMosU/Tb+lLiH1GNrl5QGIYnu1SKse9IONCS 8SMr0OnLoMeTOea6pNOGXNVti6nY7PN7NkbonS7AhklZqfpOZRK2TkIC02vP4zorLecp ur6fBSxhqcpeaJ6zOT1NgwyK702l/CqQq2Bgo5Yk157x16/rxzsgWqH2b4qH4E7OVccq pmyR43uYyjAhFn0+AmGLOzWTon8LfAE/5F/o0KRRUuQzzrCeFeEfbRCdKMSUdjS/gkBG FgVw==
X-Gm-Message-State: AEkooutf7P2W7Gw7taaWcCqWzPwPmrwiVeOEvTee2kOitEQ6s2oq/2cHmwcEgj70pyu19Df9xHAOBBX55Uf+cw==
X-Received: by 10.159.40.167 with SMTP id d36mr14835577uad.55.1471972119407; Tue, 23 Aug 2016 10:08:39 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.103.4.134 with HTTP; Tue, 23 Aug 2016 10:08:37 -0700 (PDT)
In-Reply-To: <0f2501d1fd5b$d3cddbb0$7b699310$@ndzh.com>
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> <0f2501d1fd5b$d3cddbb0$7b699310$@ndzh.com>
From: Andy Bierman <andy@yumaworks.com>
Date: Tue, 23 Aug 2016 10:08:37 -0700
Message-ID: <CABCOCHRekbW2ngPGnLtFoubJjX7wSC6QyZa=yr2nzO66c-w0hw@mail.gmail.com>
To: Susan Hares <shares@ndzh.com>
Content-Type: multipart/alternative; boundary=94eb2c1237944c191d053ac03714
Archived-At: <https://mailarchive.ietf.org/arch/msg/i2rs/JgLYi_MVZAn7NMkXZBX7oUCzd4s>
X-Mailman-Approved-At: Tue, 23 Aug 2016 13:13:27 -0700
Cc: "i2rs@ietf.org" <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: Tue, 23 Aug 2016 17:08:49 -0000

On Tue, Aug 23, 2016 at 9:31 AM, Susan Hares <shares@ndzh.com> wrote:

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

That was Juergen's comment.

I think the tagging proposal is OK if the standard protocol that YANG Push
designates as non-secure (HTTP?) is not allowed to send any YANG data
that is not properly tagged.

(If the protocol is allowed to ignore this extension, then the extension is
pointless.)

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


The actual data sent to listeners can be altered in flight.
This may be a low risk.  This is part of the decision WGs will
have to make to support non-secure transport of data in the data models.



>
>
> Sue Hares
>


Andy


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