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

Jeffrey Haas <jhaas@pfrc.org> Mon, 22 August 2016 19:57 UTC

Return-Path: <jhaas@slice.pfrc.org>
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 788B912D5FB; Mon, 22 Aug 2016 12:57:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.45
X-Spam-Level:
X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 L2TVDhLdA8ee; Mon, 22 Aug 2016 12:57:44 -0700 (PDT)
Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 630E712D177; Mon, 22 Aug 2016 12:57:44 -0700 (PDT)
Received: by slice.pfrc.org (Postfix, from userid 1001) id 3C5491E32B; Mon, 22 Aug 2016 15:58:22 -0400 (EDT)
Date: Mon, 22 Aug 2016 15:58:22 -0400
From: Jeffrey Haas <jhaas@pfrc.org>
To: Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com>
Message-ID: <20160822195821.GB5600@pfrc.org>
References: <F8C205FB-665C-422C-B991-2F97F75CAE42@cooperw.in> <003801d1f97f$3d16eb10$b744c130$@ndzh.com> <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> <20160822194549.GA5600@pfrc.org> <CAHbuEH4Eim65T_SrsDnLf2bBLY2dhY1kKDEfZxKqmNyrpAq+fg@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CAHbuEH4Eim65T_SrsDnLf2bBLY2dhY1kKDEfZxKqmNyrpAq+fg@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: <https://mailarchive.ietf.org/arch/msg/i2rs/vbRC0dU4slth380VBXTH9oZgYKg>
X-Mailman-Approved-At: Tue, 23 Aug 2016 07:35:38 -0700
Cc: "i2rs@ietf.org" <i2rs@ietf.org>, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>, Alissa Cooper <alissa@cooperw.in>, Andy Bierman <andy@yumaworks.com>, i2rs-chairs@ietf.org, IESG <iesg@ietf.org>, Joel Halpern <joel.halpern@ericsson.com>, Lou Berger <lberger@labn.net>, Susan Hares <shares@ndzh.com>, 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: Mon, 22 Aug 2016 19:57:45 -0000

On Mon, Aug 22, 2016 at 03:51:09PM -0400, Kathleen Moriarty wrote:
> > The underlying I2RS question is how to mark nodes in such a way that the
> > insecure transport protocols may be permitted to publish them without
> > requiring every single node to be audited if you have relatively weak
> > deployment considerations?  If the answer is "read the security
> > considerations and write a filter", it's not the answer i2rs is looking for.
> 
> I think it's just that it is easier to mark the items that require
> confidentiality and integrity protection, when that is clear, rather
> than trying to figure out that something is absolutely not in need of
> any confidentiality and integrity protections.

I think I2RS has done generally better than that.  When not so marked, the
intent is secure.

>From a syntactic standpoint, it's much nicer to add keywords for the
exceptions rather than the default. :-)

> In this case, you are
> not saying that items don't need security, you are just not taking an
> official stance and it's up to the user to turn on or off the default
> knob for session transport security.

Mostly I'm saying that once you have annotated some data node as being "okay
to be insecure", the user can have tools to programmatically act upon that
based on information in the model.  Lacking that, we're back in SNMP land
wherein people have to put in per-object filters to implement this.

Note this is "can act".  It'd be fine to have your policy be "even if marked
insecure, leave secure".  It's even fine, IMO (but not as an author of this
document), for such "leave secure unless otherwise configured" to be the
mandatory to implement default.

I'm somewhat curious if you've done such configuration in SNMP.  It's a
PITA. :-)

-- Jeff