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

kathleen.moriarty.ietf@gmail.com Mon, 22 August 2016 16:30 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 E68F812D65F; Mon, 22 Aug 2016 09:30:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 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_LOW=-0.7, 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 lRCHpeUi1qH7; Mon, 22 Aug 2016 09:30:28 -0700 (PDT)
Received: from mail-qk0-x231.google.com (mail-qk0-x231.google.com [IPv6:2607:f8b0:400d:c09::231]) (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 E36DD12D576; Mon, 22 Aug 2016 09:30:27 -0700 (PDT)
Received: by mail-qk0-x231.google.com with SMTP id l2so87112891qkf.3; Mon, 22 Aug 2016 09:30:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=n23sRNIo4oH88IpnJ7JeW6E0P/7FllG3cW2apL2fRBM=; b=rd6XmcI7EPZDcDKYg26RbccIMHgOcW6jlCUvLus/vXxRjj4vVh0mImNsJpK8v5cNgv 3vT5k9W2XMqOxeGeTY5arGJXQ8asL49izb2HnHPhd3iouCpf0Kudh2L55LALxVyeqYgq 1kufxuOqh2oci6kAARDAD9bgqu5iTna7sBC5DziLhDgqIyrfF+/z5svVQzlfnebNFM3k c2Mijpej5NGlgAHhG2rZdYCP7VLNURdzm0wcCiKfDQGSfQG18LIekH+8ARVXAtxZD9tl GgE7Tae7kHzuGQ6yaiGcm4UZSy929tLivlawxSToRRFT2ynGQHr0wfZMD9cMpTOU2A3X qY9A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=n23sRNIo4oH88IpnJ7JeW6E0P/7FllG3cW2apL2fRBM=; b=AhEv7t29N3SHcEZ1n/+hxzAS5Ii1Wq8zApBxqSjR3HNEqRwvGnUzMa4SH7PJS5aiWn QI+RZ0xVGN5QrVqVBIXk2A06MRm2+rB6SAQwH3GBFWTGcjtwGskzxfpm50NyABWGtQk1 J2j9Puvt4YS4cvZJgBtqGF97c9hWgrfJtOeDkGGbkPSd8lPwYrxMNCRqVUPjaWQH2LlT TOyruXT+WDV+2aZGXKCfBreBF2ySRx5b6s0ho4SkOfcHpXDsCuPy0Xofpod30e3pPp7N S8VLZ0nNFT3WBNSv8KOx76gc1CM3hY8xUvulP1n6bRrY5FsHlIc1+D9VShevtETTIIVZ DIpg==
X-Gm-Message-State: AEkooutwKvrcn3UrLPw4AwRdC2RYYB/p39EfjwqGe2yp4W93L4nfM3U+QBVYh2TNJlLwZg==
X-Received: by 10.55.39.146 with SMTP id n140mr26089612qkn.103.1471883426994; Mon, 22 Aug 2016 09:30:26 -0700 (PDT)
Received: from [192.168.1.6] (209-6-124-204.c3-0.arl-ubr1.sbo-arl.ma.cable.rcn.com. [209.6.124.204]) by smtp.gmail.com with ESMTPSA id 95sm11580749qkx.15.2016.08.22.09.30.26 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 22 Aug 2016 09:30:26 -0700 (PDT)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (1.0)
From: kathleen.moriarty.ietf@gmail.com
X-Mailer: iPhone Mail (13G35)
In-Reply-To: <029901d1fc8a$c9fca840$5df5f8c0$@ndzh.com>
Date: Mon, 22 Aug 2016 12:30:25 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <7DD36C23-1935-4273-AA66-AF52D85A0B70@gmail.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> <CAHbuEH6c+t_7C-dpeeXYZLXUv42EUBXYXv4p-Bx32HJaE1x6DQ@mail.gmail.com> <029901d1fc8a$c9fca840$5df5f8c0$@ndzh.com>
To: Susan Hares <shares@ndzh.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/i2rs/e2Xywxr7zpTdjQAD82aqf_ocBHQ>
X-Mailman-Approved-At: Mon, 22 Aug 2016 10:32:41 -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 16:30:30 -0000

Thank you, Sue.  I'll wait until then to review again.

Best regards,
Kathleen 

Sent from my iPhone

> On Aug 22, 2016, at 11:35 AM, Susan Hares <shares@ndzh.com> wrote:
> 
> Kathleen:
> 
> I will include some of Stephen's updates.   The document update will probably late today or early tomorrow.  
> 
> Sue 
> 
> -----Original Message-----
> From: Kathleen Moriarty [mailto:kathleen.moriarty.ietf@gmail.com] 
> Sent: Monday, August 22, 2016 11:19 AM
> To: Susan Hares
> Cc: Juergen Schoenwaelder; Andy Bierman; Lou Berger; i2rs@ietf.org; Alissa Cooper; i2rs-chairs@ietf.org; 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)
> 
> 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
>