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:45 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 1DBFF12D7DB; Mon, 22 Aug 2016 12:45:13 -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 XfdcgC3Kmh-C; Mon, 22 Aug 2016 12:45:12 -0700 (PDT)
Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id EF12412D1E0; Mon, 22 Aug 2016 12:45:11 -0700 (PDT)
Received: by slice.pfrc.org (Postfix, from userid 1001) id 9C8741E32B; Mon, 22 Aug 2016 15:45:49 -0400 (EDT)
Date: Mon, 22 Aug 2016 15:45:49 -0400
From: Jeffrey Haas <jhaas@pfrc.org>
To: Andy Bierman <andy@yumaworks.com>
Message-ID: <20160822194549.GA5600@pfrc.org>
References: <051701d1f952$c4ae0b30$4e0a2190$@ndzh.com> <6BCE198E4EAEFC4CAB45D75826EFB0761525CCD7@eusaamb101.ericsson.se> <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>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CABCOCHStcL9-j_ZzG+J+Gj2=kx+N_F9WVzAVTU2pdnLo5dOF+g@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: <https://mailarchive.ietf.org/arch/msg/i2rs/B18D1N_qJ-73N44t8W5rP6bPGss>
X-Mailman-Approved-At: Tue, 23 Aug 2016 07:35:38 -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>, 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:45:14 -0000

I'm lagging in my email, as usual.  However, this one caught my eye:

On Fri, Aug 19, 2016 at 07:23:47AM -0700, Andy Bierman wrote:
> We could have been tagging MIB objects all along, but we don't.
> Imagine if there was a debate for every single OBJECT-TYPE macro
> "is this leaf OK for noAuth/noPriv?"
> 
> Are there even clear SEC-DIR guidelines on how one would decide this
> debate in a WG? Does SEC-DIR really want to be flooded with review
> requests so they become a bottleneck in YANG RFC publication process?

I wanted to point out some of the per-object security evaluation that is
already imposed on MIB modules.  Consider the following text from RFC 4273:

:    There are a number of managed objects in this MIB that contain
:    sensitive information regarding the operation of a network.  For
:    example, a BGP peer's local and remote addresses might be sensitive
:    for ISPs who want to keep interface addresses on routers confidential
:    in order to prevent router addresses used for a denial of service
:    attack or spoofing.
: 
:    Therefore, it is important in most environments to control read
:    access to these objects and possibly to even encrypt the values of
:    these object when sending them over the network via SNMP.

In some respect, the discussion with regard to I2RS annotation of yang nodes
with security considerations have precedence.  It could be done in the
containing documents' security considerations section.  It could be part of
the description clause for the node.  

Having some notion of the consideration available as a machine-parseable
markup thus doesn't seem completely unreasonable.

The essence of your point, Andy, and I believe Juergen's is given a presmise
of "secure by default", is it okay to mark things as "the author of this
module believes this to be okay to be insecure by default"?

Possibly not.  As you both mention, it will depend on the circumstances of a
given operator's deployment.  

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.


-- Jeff