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

Andy Bierman <andy@yumaworks.com> Mon, 22 August 2016 17:06 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 4A81512D794 for <i2rs@ietfa.amsl.com>; Mon, 22 Aug 2016 10:06:48 -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=ham 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 57rIWIeu8hhZ for <i2rs@ietfa.amsl.com>; Mon, 22 Aug 2016 10:06:46 -0700 (PDT)
Received: from mail-ua0-x236.google.com (mail-ua0-x236.google.com [IPv6:2607:f8b0:400c:c08::236]) (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 89B3512D549 for <i2rs@ietf.org>; Mon, 22 Aug 2016 10:06:46 -0700 (PDT)
Received: by mail-ua0-x236.google.com with SMTP id k90so200355939uak.1 for <i2rs@ietf.org>; Mon, 22 Aug 2016 10:06:46 -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; bh=yraaCc6Gqu7H92VMUDdmlU6c67E/PX5k26/9MUTIXz8=; b=E5/MxO3Cy5kyqexsHw3VSnr6FsH3+agoFmT6Zu2kEyrhFIxcnSyfWirF6aFrGCPX1e Lkoo8v/TgikxKQmvNWXajih78Z18F3XdG5HFiwlAolr71jNGB2tQnwHnGrW9xUWsboLO iG0RFBM7aWTuBwuKREGVA1Ds9OMVdhn/aMgL24stb+tTp9wowotHbiPM0sd2qrfisJ7Q xib0DgjvUjG6GEmxbvNpraGMhSoA0K2SfPw1QG1b1SP4QussUooB3BDgjSNeuEDTR6nF Wf5y+fxhlmLK2cjBVY/PZN3qPF+zzdhE1SYOKaa3NdHc4KKKiJrGFRAahPU4fLG0Akwi griw==
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; bh=yraaCc6Gqu7H92VMUDdmlU6c67E/PX5k26/9MUTIXz8=; b=mcYf5YkLjJUmDz+Ali8SPqIVC8DYYKU0wUydz3ujuqkayXrTWo5ziXoaIaGtYJL466 /DyA2q8rgrpQfEIVJdvHNa0BIUw/X5kZFgazrDrTRkq01qIv7fyWtrnm8Wi87dml/nYZ u89TIn8QifvijvmBE+S2QcMZrlbPBRL1iX0ShsG4gqU4EerhGwyouiEhODSi9qtVpNsm bWTTKNRkSJri2KXkTX793Z8ttwN+n+1K32bJPbRXnJEVPj9E61l/y/UpEIngmq5zsCNy Em0KGLj748Y7bWhzxrmDxiIFLKMpBoZROJebZWGSD2WZQlx3GAqcij5/oVh8PRmB3Twm B17Q==
X-Gm-Message-State: AEkoouvBNbwu4gKVUsiT+d6loi9XSYdiYh580R+TV2Md3dMkUse+kx127bXlNqyAItCnUnVQYweYbJ4mgHWelA==
X-Received: by 10.176.68.166 with SMTP id n35mr12338873uan.47.1471885605577; Mon, 22 Aug 2016 10:06:45 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.103.4.134 with HTTP; Mon, 22 Aug 2016 10:06:43 -0700 (PDT)
In-Reply-To: <20160822100738.GA12248@elstar.local>
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>
From: Andy Bierman <andy@yumaworks.com>
Date: Mon, 22 Aug 2016 10:06:43 -0700
Message-ID: <CABCOCHQaj=Q5hX1v_vzR9KyEFVXeYw3ejPPodJzFinNh2XZbqA@mail.gmail.com>
To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>, Susan Hares <shares@ndzh.com>, Andy Bierman <andy@yumaworks.com>, Lou Berger <lberger@labn.net>, "i2rs@ietf.org" <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
Content-Type: multipart/alternative; boundary="94eb2c05c5deabc1e9053aac12a4"
Archived-At: <https://mailarchive.ietf.org/arch/msg/i2rs/ZYFEXbM5XCMX9oN0F_3LwbMAXOA>
X-Mailman-Approved-At: Mon, 22 Aug 2016 10:32:41 -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: Mon, 22 Aug 2016 17:06:48 -0000

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