Re: [i2rs] I2RS Requriements - secure transfer

"Joel M. Halpern" <jmh@joelhalpern.com> Tue, 31 May 2016 20:17 UTC

Return-Path: <jmh@joelhalpern.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 712EA12D64A for <i2rs@ietfa.amsl.com>; Tue, 31 May 2016 13:17:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.722
X-Spam-Level:
X-Spam-Status: No, score=-2.722 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.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 epVSuJ_yqfDD for <i2rs@ietfa.amsl.com>; Tue, 31 May 2016 13:17:53 -0700 (PDT)
Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DFB4A12D0E9 for <i2rs@ietf.org>; Tue, 31 May 2016 13:17:53 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id CCA5C9E000F; Tue, 31 May 2016 13:17:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1464725873; bh=JV2qjavC3v/qlv7w0rbeOUoV8SyXg6Ttaf7Fupm4d60=; h=Subject:To:References:From:Date:In-Reply-To:From; b=dwJ0YE50PgwVvwLL0MLHfWp8aHlVn62mLC9/fqWqXwhp7jLp3sdKk6h5H8QXCUKfi nFWvwSUyz9lCw2OaxjrSN6n0sl9508wPhO9XHbQQiyzQFIvMtRL/0m/XbmrEOv5630 2pJTxkc7gO6j29A83vEonSSPZRO7iDVUfPF5m2r4=
X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net
Received: from Joels-MacBook-Pro.local (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 4E5861C0B82; Tue, 31 May 2016 13:17:53 -0700 (PDT)
To: Jeffrey Haas <jhaas@pfrc.org>, Susan Hares <shares@ndzh.com>, i2rs@ietf.org
References: <000601d1bad5$70523090$50f691b0$@ndzh.com> <20160531063840.GA21289@elstar.local> <20160531193640.GL17462@pfrc.org>
From: "Joel M. Halpern" <jmh@joelhalpern.com>
Message-ID: <92905b12-3422-316c-67e9-1aefbbebc035@joelhalpern.com>
Date: Tue, 31 May 2016 16:17:50 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:45.0) Gecko/20100101 Thunderbird/45.1.0
MIME-Version: 1.0
In-Reply-To: <20160531193640.GL17462@pfrc.org>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/i2rs/9jiQjs1glm_ykiGzyI4m9cnKKV0>
Subject: Re: [i2rs] I2RS Requriements - secure transfer
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, 31 May 2016 20:17:55 -0000

The more I read the text about marking secure or insecure transports, 
the I wonder whether it is an I2RS requirement at all.
that is, I2RS requires the ability to send notifications via an insecure 
channel.
I don't think I2RS cares what granularity this is marked at.
There are security reasons for wanting to restrict the usage.  Equally, 
one needs any definition of some usage to be done by the entity which 
actually knows what is needed.
I2RS as a system does not know or care how to resolve that tension.
So lets not state a requirement on it?

Jeff, you allude to using a protocol like IPFIX.  Given that IPFix won't 
be reading these YANG models at all, it seems that the requirement as 
stated (marking in the YANG which nodes are allowed to be transferred 
insecurely) won't help solve the problem.

I also wonder if the very notion of an I2RS protocol is getting in the 
way.  If the insecure transfer we envision is some protocol other than 
NetConf / RestConf, then we seem to be stating the requirement in the 
wrong place.

Yours,
Joel

On 5/31/16 3:36 PM, Jeffrey Haas wrote:
> ...
> On Tue, May 31, 2016 at 08:38:42AM +0200, Juergen Schoenwaelder wrote:
...
>>  2.  Does Ephemeral-REQ-06 provide the Yang requirements in
>>> a clear fashion?  Do you have any suggestions for alternative text?
>>
>> I think it is clear but broken. In particular the part about
>> indicating secure/non-secure transport.
>
> The text relating to transport is applied to generally and needs clarifying.
> Let's provide a specific goal:
>
> For Yang notifications, there may be some desire for the information to be
> sent across alternative transports, potentially with specific encodings.
> draft-ietf-netconf-yang-push covers I2RS use cases wherein the data may be
> sent via alternative transports.  Should we have some sort of markup in the
> Yang language to identify what transports might be utilized?  What about
> security requirements?
>
> Obviously we can spell out transport security considerations as part of the
> description clause within a notification.  However, since a significant
> amount of feedback has been given from individuals with a security
> background that many objects we're likely to use in I2RS may be security
> sensitive - but not all! - some way to indicate the sensitivity may be
> required.
>
> The motivation for this is that for insecure and high speed transports and
> ecodings such as IPFIX (e.g.) it may be fine to expose some data (e.g.
> interface statistics) but the same may not be true for other data and a
> secured transport may be required.
...