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

Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com> Mon, 22 August 2016 15:19 UTC

Return-Path: <kathleen.moriarty.ietf@gmail.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 A6FB412D1B2; Mon, 22 Aug 2016 08:19:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=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=gmail.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 qiKuNRTSsYVP; Mon, 22 Aug 2016 08:19:15 -0700 (PDT)
Received: from mail-ua0-x230.google.com (mail-ua0-x230.google.com [IPv6:2607:f8b0:400c:c08::230]) (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 015E312D0FA; Mon, 22 Aug 2016 08:19:15 -0700 (PDT)
Received: by mail-ua0-x230.google.com with SMTP id 97so194354103uav.3; Mon, 22 Aug 2016 08:19:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=j9BPI6j0cuw4sXrt6fZy+93MeTOJXcqoZbhHBjk6Cy4=; b=pDj9PFBPsg4L7cGMvPrMSfjLDhykgVkLR5E+xjqXg6FcrmeIfKYUJru/MmsgtP6Sga +t1aGUBFQnkrenpzHhEEl26YbaRfGXm/LEro3IRt3tQGopvTR2XDEoDwjs+DSVO0niaC FwZrWUOCjtSkfIjRugeRz0tquaKmafjfh+LhgiLKTElRC+NKtJyye8T16uFkp3nY+N3t nK89VjMtY3p95VJHSESYLhuXET8lYaPFgsp2638mvynch0nlfuBRyfnBwZz6TXlmapbv 5FUMHmIYSdCj+OHQAMDKG2RJ287DV/MCWWHSl2h/5u3/23Ikcn24VutQKa0g3EcE5aMo cRlg==
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:content-transfer-encoding; bh=j9BPI6j0cuw4sXrt6fZy+93MeTOJXcqoZbhHBjk6Cy4=; b=azNb2jCIgmYiW4Isb+2LM+tdoNlGRqQg5g3iXTb8HuNlEWiKY/UOdjP8l3E2YjzZlN 7/6YPR72zYMqG0S16SV6TrttPtFOloTcrbDeex1n7d1VGNueQN5F6YO/dwggMpeInuV3 NQIFn54q5sUHlm6abeSPrmqju4MA/bXrdW34MbieGf2EkAogGPWjaXMiXLKhQonWqokI IMMgRpyH/xA5XJ4Fh8lXcNrUtfHV9/D2sjKsLHAwDQHAIhfAz/BNUOecCHOdyeyQkB3r omZ2M/8qpkwK54+PO0KTmJ8Nz4E6JHCK2pAdNzMRCnehCl1b+vojTmcEUMwPhxFwyhfa 3AYA==
X-Gm-Message-State: AEkoouuLdxnfF4X2YXV+GLHbRLTbqnZK0OMFS5F+/NOaKRrcKPkfcnKWrLIiABWyLYsvKaA8Q4ogF+XuEn+XEw==
X-Received: by 10.176.83.46 with SMTP id x43mr11477194uax.113.1471879154030; Mon, 22 Aug 2016 08:19:14 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.176.1.228 with HTTP; Mon, 22 Aug 2016 08:19:12 -0700 (PDT)
In-Reply-To: <03ee01d1fc73$322502e0$966f08a0$@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> <03ee01d1fc73$322502e0$966f08a0$@ndzh.com>
From: Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com>
Date: Mon, 22 Aug 2016 11:19:12 -0400
Message-ID: <CAHbuEH6c+t_7C-dpeeXYZLXUv42EUBXYXv4p-Bx32HJaE1x6DQ@mail.gmail.com>
To: Susan Hares <shares@ndzh.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/i2rs/1Nb9z0KgLqh-I0TxbFM638cfdWU>
X-Mailman-Approved-At: Mon, 22 Aug 2016 08:36:32 -0700
Cc: i2rs@ietf.org, Alissa Cooper <alissa@cooperw.in>, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>, Andy Bierman <andy@yumaworks.com>, i2rs-chairs@ietf.org, 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: Mon, 22 Aug 2016 15:19:18 -0000

Hello,

My plan is to re-read the posted draft, but if you plan to include
Stephen's updates as well, I can wait to review that.  I'll have to
read the text to see where we are at as there have been a lot of
messages on this thread and updates from other related AD
comments/disucusses.  I'm still concerned about a few things, but will
see if that matters in the text.

I believe I responded on the heading for the mutual authentication
suggesting that it should really be identifiers and authentication
instead of mutual authentication.  I don't expect to see explicit
guidelines on mutual auth, but with that as the header, I would have.

Thanks,
Kathleen

On Mon, Aug 22, 2016 at 8:46 AM, Susan Hares <shares@ndzh.com> wrote:
> Juergen:
>
> Thank you for your input.
>
> I can find nothing new in your input that was not covered in the I2RS WG discussions. As far as I can tell you are re-iterating a discussion that occurred in the WG, and was closed.   I have given example (BGP route-view,  web-service up) as events which currently in the public and have been requested by some operators.  Please note that the operator should have a knob that says "always" secure-transport.
>
> Sue
>
> -----Original Message-----
> From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de]
> Sent: Monday, August 22, 2016 6:08 AM
> To: Susan Hares
> Cc: '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 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.)
>
> 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
>
> --
> 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/>
>



-- 

Best regards,
Kathleen