From nobody Mon Aug 1 07:40:54 2016 Return-Path: X-Original-To: i2rs@ietf.org Delivered-To: i2rs@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 796DD12D735; Mon, 1 Aug 2016 07:40:52 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.29.0 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <20160801144052.32557.44206.idtracker@ietfa.amsl.com> Date: Mon, 01 Aug 2016 07:40:52 -0700 Archived-At: Cc: jhaas@pfrc.org, i2rs@ietf.org, draft-ietf-i2rs-protocol-security-requirements@ietf.org, i2rs-chairs@ietf.org, akatlas@gmail.com Subject: [i2rs] Last Call: (I2RS Security Related Requirements) to Informational RFC X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Reply-To: ietf@ietf.org List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Aug 2016 14:40:52 -0000 The IESG has received a request from the Interface to the Routing System WG (i2rs) to consider the following document: - 'I2RS Security Related Requirements' as Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2016-08-15. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This presents security-related requirements for the I2RS protocol for mutual authentication, transport protocols, data transfer and transactions. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-i2rs-protocol-security-requirements/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-i2rs-protocol-security-requirements/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Tue Aug 2 06:19:16 2016 Return-Path: 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 7BC8812D5B5 for ; Tue, 2 Aug 2016 06:19:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.439 X-Spam-Level: **** X-Spam-Status: No, score=4.439 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, RDNS_NONE=0.793] autolearn=no 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 CGN7Nhhkgegf for ; Tue, 2 Aug 2016 06:19:14 -0700 (PDT) Received: from hickoryhill-consulting.com (unknown [50.245.122.97]) (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 2D5F712D5B6 for ; Tue, 2 Aug 2016 06:19:14 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=174.124.199.15; From: "Susan Hares" To: Date: Tue, 2 Aug 2016 09:18:24 -0400 Message-ID: <00b801d1ecc0$594b0620$0be11260$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00B9_01D1EC9E.D23A9EA0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdHswClmv0wQaTDARICo4Xn1zgHT+Q== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: russ@riw.us, 'Alia Atlas' Subject: [i2rs] 2 Week WG LC on draft-ephemeral-state-15.txt (8/2 to 8/15) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2016 13:19:15 -0000 This is a multipart message in MIME format. ------=_NextPart_000_00B9_01D1EC9E.D23A9EA0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit This begins a 2 week WG LC on draft-i2rs-ephemeral-state-15.txt. This draft received a "hum" of consensus at IETF 96, and we are now taking the final text to a WG Last Call. Please send your comments on the requirements to the WG list. Sue Hares and Russ White ------=_NextPart_000_00B9_01D1EC9E.D23A9EA0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

This = begins a 2 week WG LC on draft-i2rs-ephemeral-state-15.txt.  This = draft received a “hum” of consensus at IETF 96, and we are = now taking the final text to a WG Last Call.  Please send your = comments on the requirements to the WG list.

 

Sue Hares = and Russ White

------=_NextPart_000_00B9_01D1EC9E.D23A9EA0-- From nobody Tue Aug 2 08:54:45 2016 Return-Path: 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 8553012D7C8 for ; Tue, 2 Aug 2016 08:54:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.507 X-Spam-Level: X-Spam-Status: No, score=-5.507 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.287, 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 iUVOgtBdZyg4 for ; Tue, 2 Aug 2016 08:54:41 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D1D312D7C2 for ; Tue, 2 Aug 2016 08:54:40 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml701-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CTQ85020; Tue, 02 Aug 2016 15:54:37 +0000 (GMT) Received: from DFWEML702-CAH.china.huawei.com (10.193.5.176) by lhreml701-cah.china.huawei.com (10.201.5.93) with Microsoft SMTP Server (TLS) id 14.3.235.1; Tue, 2 Aug 2016 16:54:36 +0100 Received: from DFWEML501-MBB.china.huawei.com ([10.193.5.179]) by dfweml702-cah.china.huawei.com ([10.193.5.176]) with mapi id 14.03.0235.001; Tue, 2 Aug 2016 08:54:34 -0700 From: Linda Dunbar To: Susan Hares , "i2rs@ietf.org" Thread-Topic: [i2rs] 2 Week WG LC on draft-ephemeral-state-15.txt (8/2 to 8/15) Thread-Index: AdHswClmv0wQaTDARICo4Xn1zgHT+QAFenkQ Date: Tue, 2 Aug 2016 15:54:33 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F657F0E5E0@dfweml501-mbb> References: <00b801d1ecc0$594b0620$0be11260$@ndzh.com> In-Reply-To: <00b801d1ecc0$594b0620$0be11260$@ndzh.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.192.11.202] Content-Type: multipart/alternative; boundary="_000_4A95BA014132FF49AE685FAB4B9F17F657F0E5E0dfweml501mbb_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020204.57A0C23D.02BD, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 21b39081c37fd7341da6e8bb53c32509 Archived-At: Cc: "russ@riw.us" , 'Alia Atlas' Subject: Re: [i2rs] 2 Week WG LC on draft-ephemeral-state-15.txt (8/2 to 8/15) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2016 15:54:44 -0000 --_000_4A95BA014132FF49AE685FAB4B9F17F657F0E5E0dfweml501mbb_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I think this draft is ready for RFC. No more comment. Linda Dunbar From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Susan Hares Sent: Tuesday, August 02, 2016 8:18 AM To: i2rs@ietf.org Cc: russ@riw.us; 'Alia Atlas' Subject: [i2rs] 2 Week WG LC on draft-ephemeral-state-15.txt (8/2 to 8/15) This begins a 2 week WG LC on draft-i2rs-ephemeral-state-15.txt. This draf= t received a "hum" of consensus at IETF 96, and we are now taking the final= text to a WG Last Call. Please send your comments on the requirements to = the WG list. Sue Hares and Russ White --_000_4A95BA014132FF49AE685FAB4B9F17F657F0E5E0dfweml501mbb_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I think this draft is = ready for RFC. No more comment.

 

Linda Dunbar

 

From: i2rs [ma= ilto:i2rs-bounces@ietf.org] On Behalf Of Susan Hares
Sent: Tuesday, August 02, 2016 8:18 AM
To: i2rs@ietf.org
Cc: russ@riw.us; 'Alia Atlas'
Subject: [i2rs] 2 Week WG LC on draft-ephemeral-state-15.txt (8/2 to= 8/15)

 

This begins a 2 week WG LC on draft-i2rs-ephemeral-s= tate-15.txt.  This draft received a “hum” of consensus at = IETF 96, and we are now taking the final text to a WG Last Call.  Plea= se send your comments on the requirements to the WG list.

 

Sue Hares and Russ White

--_000_4A95BA014132FF49AE685FAB4B9F17F657F0E5E0dfweml501mbb_-- From nobody Tue Aug 2 09:04:37 2016 Return-Path: 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 2E29412D137 for ; Tue, 2 Aug 2016 09:04:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.739 X-Spam-Level: * X-Spam-Status: No, score=1.739 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, RDNS_NONE=0.793] autolearn=no 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 uyg7OwkZL7Bi for ; Tue, 2 Aug 2016 09:04:34 -0700 (PDT) Received: from hickoryhill-consulting.com (unknown [50.245.122.97]) (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 8845D12B02F for ; Tue, 2 Aug 2016 09:04:34 -0700 (PDT) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=174.124.199.15; From: "Susan Hares" To: "'Linda Dunbar'" , References: <00b801d1ecc0$594b0620$0be11260$@ndzh.com> <4A95BA014132FF49AE685FAB4B9F17F657F0E5E0@dfweml501-mbb> In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F657F0E5E0@dfweml501-mbb> Date: Tue, 2 Aug 2016 12:03:36 -0400 Message-ID: <001801d1ecd7$6dc97ca0$495c75e0$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0019_01D1ECB5.E6B98A50" X-Mailer: Microsoft Outlook 14.0 Content-Language: en-us Thread-Index: AQKK2u9RuXRaZ/qKcZ/TddJhjST0/QHPXms9nrV929A= X-Authenticated-User: skh@ndzh.com Archived-At: Cc: russ@riw.us, 'Alia Atlas' Subject: Re: [i2rs] 2 Week WG LC on draft-ephemeral-state-15.txt (8/2 to 8/15) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2016 16:04:36 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0019_01D1ECB5.E6B98A50 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit +1 to Linda's comment. No IPR in the document. From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Linda Dunbar Sent: Tuesday, August 2, 2016 11:55 AM To: Susan Hares; i2rs@ietf.org Cc: russ@riw.us; 'Alia Atlas' Subject: Re: [i2rs] 2 Week WG LC on draft-ephemeral-state-15.txt (8/2 to 8/15) I think this draft is ready for RFC. No more comment. Linda Dunbar From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Susan Hares Sent: Tuesday, August 02, 2016 8:18 AM To: i2rs@ietf.org Cc: russ@riw.us; 'Alia Atlas' Subject: [i2rs] 2 Week WG LC on draft-ephemeral-state-15.txt (8/2 to 8/15) This begins a 2 week WG LC on draft-i2rs-ephemeral-state-15.txt. This draft received a "hum" of consensus at IETF 96, and we are now taking the final text to a WG Last Call. Please send your comments on the requirements to the WG list. Sue Hares and Russ White ------=_NextPart_000_0019_01D1ECB5.E6B98A50 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

<author hat on>

+1 to Linda’s = comment.  No IPR in the document.

</author hat off> =

 

From:= = i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Linda = Dunbar
Sent: Tuesday, August 2, 2016 11:55 AM
To: = Susan Hares; i2rs@ietf.org
Cc: russ@riw.us; 'Alia = Atlas'
Subject: Re: [i2rs] 2 Week WG LC on = draft-ephemeral-state-15.txt (8/2 to = 8/15)

 

I think this draft is ready for RFC. No more = comment.

 

Linda = Dunbar

 

From:= = i2rs [mailto:i2rs-bounces@ietf.org] = On Behalf Of Susan Hares
Sent: Tuesday, August 02, 2016 = 8:18 AM
To: i2rs@ietf.org
Cc: russ@riw.us; 'Alia = Atlas'
Subject: [i2rs] 2 Week WG LC on = draft-ephemeral-state-15.txt (8/2 to = 8/15)

 

This begins = a 2 week WG LC on draft-i2rs-ephemeral-state-15.txt.  This draft = received a “hum” of consensus at IETF 96, and we are now = taking the final text to a WG Last Call.  Please send your comments = on the requirements to the WG list.

 

Sue Hares = and Russ White

------=_NextPart_000_0019_01D1ECB5.E6B98A50-- From nobody Tue Aug 2 09:37:55 2016 Return-Path: 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 264F112D810 for ; Tue, 2 Aug 2016 09:37:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.808 X-Spam-Level: X-Spam-Status: No, score=-15.808 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_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 mJecKptakzog for ; Tue, 2 Aug 2016 09:37:53 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E499812D7FD for ; Tue, 2 Aug 2016 09:37:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2319; q=dns/txt; s=iport; t=1470155872; x=1471365472; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=s0Qcg+0+kWEDtHLFwhPCj8gZ95Uab9YDBbthbYkGCtY=; b=S9qZ+qtmNn9VNXMLfC24bdwZU7EcJxLKH/Z4RkH4pFTn6eta7zJ7G4Ah +9Lr6P4l2U6jfPZaBS+kTyo5ip7dn2odD59Nuy0l0Q/lLACyEDLg7/aXD zvfqQpk38ohgEZEWWH/EhPcm9fgwMY5AoZWXJkwDmoqZC4QETaY09iyaC k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DgCAAIzKBX/40NJK1UCYNFgQC6AIF9h?= =?us-ascii?q?h0CgUA5EwEBAQEBAQFdJ4RfAQUyAQVBEAsOCi5XBgEMCAEBiC3AbQEBAQEBAQE?= =?us-ascii?q?BAQEBAQEBAQEBAR+GKoF4glWEGYYCAQSZM4wHgniBaxeEQ4MOI4VJkCcgATOEF?= =?us-ascii?q?iCIYwEBAQ?= X-IronPort-AV: E=Sophos;i="5.28,461,1464652800"; d="scan'208";a="133239606" Received: from alln-core-8.cisco.com ([173.36.13.141]) by rcdn-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 02 Aug 2016 16:37:52 +0000 Received: from [10.150.55.172] (dhcp-10-150-55-172.cisco.com [10.150.55.172]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id u72GbpfT000871; Tue, 2 Aug 2016 16:37:52 GMT To: Susan Hares , i2rs@ietf.org References: <00b801d1ecc0$594b0620$0be11260$@ndzh.com> From: Joe Clarke Organization: Cisco Systems, Inc. Message-ID: <85dccb29-d395-e206-e53d-42e27e3300a0@cisco.com> Date: Tue, 2 Aug 2016 12:37:51 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <00b801d1ecc0$594b0620$0be11260$@ndzh.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: russ@riw.us, 'Alia Atlas' Subject: Re: [i2rs] 2 Week WG LC on draft-ephemeral-state-15.txt (8/2 to 8/15) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2016 16:37:54 -0000 On 8/2/16 09:18, Susan Hares wrote: > This begins a 2 week WG LC on draft-i2rs-ephemeral-state-15.txt. This > draft received a “hum” of consensus at IETF 96, and we are now taking > the final text to a WG Last Call. Please send your comments on the > requirements to the WG list. I think this is good. A general comment I have is that "ephemeral state" is used in a number of places where I think "ephemeral configuration" should be used. This may be a nit, but the device has one state that is dictated by the various configuration types and the operational state. This was raised in BA in the meetings as well. My recommendation is to replace "ephemeral state" with "ephemeral configuration". It's not a show-stopper the way it is, but I think the latter is a bit clearer. One nit I notice is a mixed use of Client/client Agent/agent. Per the last round of RFCs, we are normalizing on client and agent (lowercase). Section 7, bullet 2: This text reads strangely: OLD TEXT: The I2RS protocol MUST support the ability to have data nodes MAY store I2RS client identity and not the effective priority of the I2RS client at the time the data node is stored. PROPOSED NEW TEXT: The I2RS protocol MUST support the ability to have data nodes store I2RS client identity and not the effective priority of the I2RS client at the time the data node is stored. Section 8: I2RS is written "I2SR" Section 8: This text is odd OLD TEXT: multiple operations in one or more messages handling can handle errors within the set of operations in many ways. I'm stumped. This doesn't read as a requirement per se. Yes, the I2RS protocol can support multiple operations within one message or multiple messages. Based on the fact that atomicity is not provided, an error in one message will have no effect on other messages, even if they are related. So maybe: PROPOSED NEW TEXT: multiple operations in one or more messages; though errors in one message or operation will have no effect on other messages or commands even if they are related Section 9: OLD TEXT: requirements SHOULD be understood to be expanded to to include NEW TEXT: requirements SHOULD be understood to be expanded to include Joe From nobody Tue Aug 2 10:29:11 2016 Return-Path: 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 E596212D838 for ; Tue, 2 Aug 2016 10:29:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=messagingengine.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 EdozROGGo9gQ for ; Tue, 2 Aug 2016 10:28:56 -0700 (PDT) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5512B12D188 for ; Tue, 2 Aug 2016 10:28:56 -0700 (PDT) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 99A5A20974; Tue, 2 Aug 2016 13:28:54 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute4.internal (MEProxy); Tue, 02 Aug 2016 13:28:54 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=Fk2IuxQ3i8pAPL9 036iR8FEHEyk=; b=E6KIyKM1/Ly3dBO1ginbhkW6SciGpHxMLhLFt8qnrMzLUp7 +GkPWDSaAMpBz7bHbDx5VlG2+e8EHXbz0YKbNgFBxOW9zEFvcAojEfkhPkjb9qNI Fpyy7PZDdO3kxIunDdBaMPXnT3AAXX6IuR1JvbQD/uZ284T6DbveoNICV4Tk= X-Sasl-enc: P3yVh5lUt+cr3XfiK6e9uTmLsR4k5l7++4X3SNeHaNEw 1470158934 Received: from Russ (162-229-180-77.lightspeed.rlghnc.sbcglobal.net [162.229.180.77]) by mail.messagingengine.com (Postfix) with ESMTPA id 44637F29DB; Tue, 2 Aug 2016 13:28:54 -0400 (EDT) From: "Russ White" To: "'Susan Hares'" , References: <00b801d1ecc0$594b0620$0be11260$@ndzh.com> In-Reply-To: <00b801d1ecc0$594b0620$0be11260$@ndzh.com> Date: Tue, 2 Aug 2016 13:28:48 -0400 Message-ID: <018001d1ece3$54b870c0$fe295240$@riw.us> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQKK2u9RuXRaZ/qKcZ/TddJhjST0/Z7EELdQ Content-Language: en-us Archived-At: Cc: 'Alia Atlas' Subject: Re: [i2rs] 2 Week WG LC on draft-ephemeral-state-15.txt (8/2 to 8/15) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2016 17:29:10 -0000 This doc looks ready for publication to me... :-) Russ > -----Original Message----- > From: Susan Hares [mailto:shares@ndzh.com] > Sent: Tuesday, August 2, 2016 9:18 AM > To: i2rs@ietf.org > Cc: russ@riw.us; 'Alia Atlas' > Subject: 2 Week WG LC on draft-ephemeral-state-15.txt (8/2 to 8/15) > > This begins a 2 week WG LC on draft-i2rs-ephemeral-state-15.txt. This draft > received a "hum" of consensus at IETF 96, and we are now taking the final > text to a WG Last Call. Please send your comments on the requirements to > the WG list. > > > > Sue Hares and Russ White From nobody Tue Aug 2 11:59:45 2016 Return-Path: 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 5618A12D8A5 for ; Tue, 2 Aug 2016 11:59:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.702 X-Spam-Level: X-Spam-Status: No, score=-2.702 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, 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 fi5Tm5WIDWEE for ; Tue, 2 Aug 2016 11:59:42 -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 DE79212D893 for ; Tue, 2 Aug 2016 11:59:42 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id C4AB51C04B0; Tue, 2 Aug 2016 11:59:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1470164382; bh=fzaNhTjzIN9KSv753w197wPaJbk3LiP7Rpt3yBnWVKQ=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=hLTEkNY4RDMQXXv3t4OBK0LxnkcY+vMg6+w/vzCucN27NVEke+XWdnh35PgB2dx78 NqLkvC/r30vk1xtfd6J/NGLG1oZGbGVoH2OhaCLF15h+PWcqwBI1q2rV1sphENVRkc /WX/plZ8lVE7qMfAnOVJbSvM6id4Ah/mNZLMDcQ8= 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 3AEEC1C046B; Tue, 2 Aug 2016 11:59:42 -0700 (PDT) To: Susan Hares , i2rs@ietf.org References: <00b801d1ecc0$594b0620$0be11260$@ndzh.com> From: "Joel M. Halpern" Message-ID: <3bc43e40-0823-0666-b8cc-79acb99265a6@joelhalpern.com> Date: Tue, 2 Aug 2016 14:59:39 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <00b801d1ecc0$594b0620$0be11260$@ndzh.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: russ@riw.us, 'Alia Atlas' Subject: Re: [i2rs] 2 Week WG LC on draft-ephemeral-state-15.txt (8/2 to 8/15) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2016 18:59:44 -0000 This document appears to me to accurately reflect the working group agreed requirements. It also appears to be a a clear and effective statement of these requirements, which I support. Thus, I support publication of this document as an RFC. Yours, Joel On 8/2/16 9:18 AM, Susan Hares wrote: > This begins a 2 week WG LC on draft-i2rs-ephemeral-state-15.txt. This > draft received a “hum” of consensus at IETF 96, and we are now taking > the final text to a WG Last Call. Please send your comments on the > requirements to the WG list. > > > > Sue Hares and Russ White > > > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs > From nobody Wed Aug 3 02:27:10 2016 Return-Path: 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 2143C12D1AA for ; Wed, 3 Aug 2016 02:27:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.186 X-Spam-Level: X-Spam-Status: No, score=-8.186 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.287] 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 R1tNPK8xtTH5 for ; Wed, 3 Aug 2016 02:27:07 -0700 (PDT) Received: from p-us1-iereast-outbound.us1.avaya.com (p-us1-iereast-outbound.us1.avaya.com [135.11.29.13]) (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 4CD6F12D8B7 for ; Wed, 3 Aug 2016 02:27:07 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A2GFAQCFuKFX/xUHmMZdGgEBAQGCWSEtV?= =?us-ascii?q?nwHjSWsAoF9hh0CgUc4FAEBAQEBAQEDWieEXgEBAQEDEhtMEAIBCA0BAwQBAQs?= =?us-ascii?q?dBzIUCQgBAQQBDQUIGogPAaUQmgYBAQEBAQEBAQEBAQEBAQEBAQEBAQEchiuET?= =?us-ascii?q?IRCNIJ2gi8FmTQBkGmEWoMlhVWMMIN3HjaDem6HXQF+AQEB?= X-IPAS-Result: =?us-ascii?q?A2GFAQCFuKFX/xUHmMZdGgEBAQGCWSEtVnwHjSWsAoF9hh0?= =?us-ascii?q?CgUc4FAEBAQEBAQEDWieEXgEBAQEDEhtMEAIBCA0BAwQBAQsdBzIUCQgBAQQBD?= =?us-ascii?q?QUIGogPAaUQmgYBAQEBAQEBAQEBAQEBAQEBAQEBAQEchiuETIRCNIJ2gi8FmTQ?= =?us-ascii?q?BkGmEWoMlhVWMMIN3HjaDem6HXQF+AQEB?= X-IronPort-AV: E=Sophos;i="5.28,465,1464667200"; d="scan'208,217";a="199328587" Received: from unknown (HELO co300216-co-erhwest-exch.avaya.com) ([198.152.7.21]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 03 Aug 2016 05:26:51 -0400 X-OutboundMail_SMTP: 1 Received: from unknown (HELO AZ-FFEXHC01.global.avaya.com) ([135.64.58.11]) by co300216-co-erhwest-out.avaya.com with ESMTP/TLS/AES256-SHA; 03 Aug 2016 05:26:51 -0400 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC01.global.avaya.com ([135.64.58.11]) with mapi id 14.03.0294.000; Wed, 3 Aug 2016 11:26:49 +0200 From: "Romascanu, Dan (Dan)" To: Susan Hares , "i2rs@ietf.org" Thread-Topic: [i2rs] 2 Week WG LC on draft-ephemeral-state-15.txt (8/2 to 8/15) Thread-Index: AdHswClmv0wQaTDARICo4Xn1zgHT+QAqN3HA Date: Wed, 3 Aug 2016 09:26:48 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA75259CC2@AZ-FFEXMB04.global.avaya.com> References: <00b801d1ecc0$594b0620$0be11260$@ndzh.com> In-Reply-To: <00b801d1ecc0$594b0620$0be11260$@ndzh.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.47] Content-Type: multipart/alternative; boundary="_000_9904FB1B0159DA42B0B887B7FA8119CA75259CC2AZFFEXMB04globa_" MIME-Version: 1.0 Archived-At: Cc: "russ@riw.us" , 'Alia Atlas' Subject: Re: [i2rs] 2 Week WG LC on draft-ephemeral-state-15.txt (8/2 to 8/15) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2016 09:27:09 -0000 --_000_9904FB1B0159DA42B0B887B7FA8119CA75259CC2AZFFEXMB04globa_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable This document reflects the consensus hummed at IETF 96. I am fine with its = content. Regards, Dan From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Susan Hares Sent: Tuesday, August 2, 2016 4:18 PM To: i2rs@ietf.org Cc: russ@riw.us; 'Alia Atlas' Subject: [i2rs] 2 Week WG LC on draft-ephemeral-state-15.txt (8/2 to 8/15) This begins a 2 week WG LC on draft-i2rs-ephemeral-state-15.txt. This draf= t received a "hum" of consensus at IETF 96, and we are now taking the final= text to a WG Last Call. Please send your comments on the requirements to = the WG list. Sue Hares and Russ White --_000_9904FB1B0159DA42B0B887B7FA8119CA75259CC2AZFFEXMB04globa_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

This document reflects= the consensus hummed at IETF 96. I am fine with its content.

 

Regards,

 

Dan<= /p>

 

 

From: i2rs [ma= ilto:i2rs-bounces@ietf.org] On Behalf Of Susan Hares
Sent: Tuesday, August 2, 2016 4:18 PM
To: i2rs@ietf.org
Cc: russ@riw.us; 'Alia Atlas'
Subject: [i2rs] 2 Week WG LC on draft-ephemeral-state-15.txt (8/2 to= 8/15)

 

This begins a 2 week WG LC on draft-i2rs-ephemeral-s= tate-15.txt.  This draft received a “hum” of consensus at = IETF 96, and we are now taking the final text to a WG Last Call.  Plea= se send your comments on the requirements to the WG list.

 

Sue Hares and Russ White

--_000_9904FB1B0159DA42B0B887B7FA8119CA75259CC2AZFFEXMB04globa_-- From nobody Thu Aug 4 23:39:43 2016 Return-Path: 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 95EC312B01D for ; Thu, 4 Aug 2016 23:39:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.507 X-Spam-Level: X-Spam-Status: No, score=-5.507 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.287, 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 rS1uPawjw_Vc for ; Thu, 4 Aug 2016 23:39:38 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D382E127071 for ; Thu, 4 Aug 2016 23:39:37 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml703-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CTU77042; Fri, 05 Aug 2016 06:39:35 +0000 (GMT) Received: from NKGEML413-HUB.china.huawei.com (10.98.56.74) by lhreml703-cah.china.huawei.com (10.201.5.104) with Microsoft SMTP Server (TLS) id 14.3.235.1; Fri, 5 Aug 2016 07:39:33 +0100 Received: from NKGEML515-MBX.china.huawei.com ([fe80::a54a:89d2:c471:ff]) by NKGEML413-HUB.china.huawei.com ([10.98.56.74]) with mapi id 14.03.0235.001; Fri, 5 Aug 2016 14:39:29 +0800 From: "Dongjie (Jimmy)" To: Susan Hares , "i2rs@ietf.org" Thread-Topic: [i2rs] 2 Week WG LC on draft-ephemeral-state-15.txt (8/2 to 8/15) Thread-Index: AdHswClmv0wQaTDARICo4Xn1zgHT+QCI6LnQ Date: Fri, 5 Aug 2016 06:39:29 +0000 Message-ID: <76CD132C3ADEF848BD84D028D243C92774F00B65@NKGEML515-MBX.china.huawei.com> References: <00b801d1ecc0$594b0620$0be11260$@ndzh.com> In-Reply-To: <00b801d1ecc0$594b0620$0be11260$@ndzh.com> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.109.108.64] Content-Type: multipart/alternative; boundary="_000_76CD132C3ADEF848BD84D028D243C92774F00B65NKGEML515MBXchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020201.57A434A8.0002, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 21b39081c37fd7341da6e8bb53c32509 Archived-At: Cc: "russ@riw.us" , 'Alia Atlas' Subject: Re: [i2rs] 2 Week WG LC on draft-ephemeral-state-15.txt (8/2 to 8/15) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Aug 2016 06:39:42 -0000 --_000_76CD132C3ADEF848BD84D028D243C92774F00B65NKGEML515MBXchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I support the publication of this document as an RFC. Best regards, Jie From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Susan Hares Sent: Tuesday, August 02, 2016 9:18 PM To: i2rs@ietf.org Cc: russ@riw.us; 'Alia Atlas' Subject: [i2rs] 2 Week WG LC on draft-ephemeral-state-15.txt (8/2 to 8/15) This begins a 2 week WG LC on draft-i2rs-ephemeral-state-15.txt. This draf= t received a "hum" of consensus at IETF 96, and we are now taking the final= text to a WG Last Call. Please send your comments on the requirements to = the WG list. Sue Hares and Russ White --_000_76CD132C3ADEF848BD84D028D243C92774F00B65NKGEML515MBXchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

I support the publication of this document as an RFC.<= /span>

 

Best regards,

Jie

 

From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Susan Hares
Sent: Tuesday, August 02, 2016 9:18 PM
To: i2rs@ietf.org
Cc: russ@riw.us; 'Alia Atlas'
Subject: [i2rs] 2 Week WG LC on draft-ephemeral-state-15.txt (8/2 to= 8/15)

 

This begins a 2 week WG LC on d= raft-i2rs-ephemeral-state-15.txt.  This draft received a “hum= 221; of consensus at IETF 96, and we are now taking the final text to a WG = Last Call.  Please send your comments on the requirements to the WG list.

 

Sue Hares and Russ White <= /o:p>

--_000_76CD132C3ADEF848BD84D028D243C92774F00B65NKGEML515MBXchi_-- From nobody Tue Aug 9 16:03:25 2016 Return-Path: X-Original-To: i2rs@ietf.org Delivered-To: i2rs@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C40F12D1DE; Tue, 9 Aug 2016 16:03:20 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.29.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147078380037.30672.2531067853104970034.idtracker@ietfa.amsl.com> Date: Tue, 09 Aug 2016 16:03:20 -0700 Archived-At: Cc: i2rs@ietf.org Subject: [i2rs] I-D Action: draft-ietf-i2rs-yang-l3-topology-03.txt X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Aug 2016 23:03:20 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Interface to the Routing System of the IETF. Title : A YANG Data Model for Layer 3 Topologies Authors : Alexander Clemm Jan Medved Robert Varga Tony Tkacik Xufeng Liu Igor Bryskin Aihua Guo Hariharan Ananthakrishnan Nitin Bahadur Vishnu Pavan Beeram Filename : draft-ietf-i2rs-yang-l3-topology-03.txt Pages : 31 Date : 2016-08-09 Abstract: This document defines a YANG data model for layer 3 network topologies. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-i2rs-yang-l3-topology/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-i2rs-yang-l3-topology-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-i2rs-yang-l3-topology-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Aug 17 01:37:29 2016 Return-Path: X-Original-To: i2rs@ietf.org Delivered-To: i2rs@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D81212D1E6; Wed, 17 Aug 2016 01:37:27 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "Mirja Kuehlewind" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.29.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147142304704.12189.4149817417200297360.idtracker@ietfa.amsl.com> Date: Wed, 17 Aug 2016 01:37:27 -0700 Archived-At: Cc: jhaas@pfrc.org, i2rs@ietf.org, i2rs-chairs@ietf.org, draft-ietf-i2rs-protocol-security-requirements@ietf.org Subject: [i2rs] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft-i?= =?utf-8?q?etf-i2rs-protocol-security-requirements-06=3A_=28with_COMMENT?= =?utf-8?q?=29?= X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Aug 2016 08:37:27 -0000 Mirja Kühlewind has entered the following ballot position for draft-ietf-i2rs-protocol-security-requirements-06: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-i2rs-protocol-security-requirements/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- A few comments: 1) I don't think copy&paste from RFC4949 is necessary. I would recommend to remove this part and just name the definitions that are needed. 2) The following sentence seems to indicate that the refernce to RFC4949 should be normative. "The transfer of data via the I2RS protocol has the property of data integrity described in [RFC4949]." As I don't think this is needed, I would recommend to rather spell out the properties here in this sentence. Also, to be honstest I not sure what this sentence tells me at all. So maybe stating clearing what you mean (instead of just having the reference) would help anyway. 3) To me it's not really clear why there are several requirments docs (that also are connected and refer each other; see e.g. section 3.6 and SEC-REQ-16). The actually context of this doc is only 4 pages (3.1-3.6). Couldn't those docs be combined to one requiremnet doc? 4) Section 3.1 says: "The I2RS architecture [I-D.ietf-i2rs-architecture] sets the following requirements:" Why is this needed is RFC7921 already sets these requirements? From nobody Wed Aug 17 07:54:40 2016 Return-Path: X-Original-To: i2rs@ietf.org Delivered-To: i2rs@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id EC18012DF50; Wed, 17 Aug 2016 07:54:38 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Alissa Cooper" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.29.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147144567895.12152.15403435188950086025.idtracker@ietfa.amsl.com> Date: Wed, 17 Aug 2016 07:54:38 -0700 Archived-At: Cc: jhaas@pfrc.org, i2rs@ietf.org, i2rs-chairs@ietf.org, draft-ietf-i2rs-protocol-security-requirements@ietf.org Subject: [i2rs] Alissa Cooper's Discuss on draft-ietf-i2rs-protocol-security-requirements-06: (with DISCUSS and COMMENT) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Aug 2016 14:54:39 -0000 Alissa Cooper has entered the following ballot position for draft-ietf-i2rs-protocol-security-requirements-06: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-i2rs-protocol-security-requirements/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- == Section 3.2 == "A non-secure transport can be 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." What kind of telemetry data is it that is of no potential interest to any eavesdropper? This is not my area of expertise so I'm having a hard time conceiving of what that could be. I'm also wondering, since I2RS agents and clients will have to support secure transports anyway (and RESTCONF can only be used over a secure transport), why can't they be used for all transfers, instead of allowing this loophole in the name of telemetry, which undoubtedly will end up being used or exploited for other data transfers? If the argument was that this loophole is needed for backwards compatibility with insecure deployments of NETCONF or something like that I think it would make more sense, but my impression from the text is that those will have to be updated anyway to conform to the requirements in this document. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- In general I agree with Mirja that where other documents already provide definitions, they should be referenced, not copied or summarized, in this document. == Section 2.1 == Using "privacy" as a synonym for "confidentiality" is outmoded, I think, given current understanding of the many other facets of privacy (see, e.g., RFC 6793). I would suggest dropping the definition of data privacy and just using the word confidentiality when that is what you mean. == Section 2.2 == "The I2RS protocol exists as a higher-level protocol which may combine other protocols (NETCONF, RESTCONF, IPFIX and others) within a specific I2RS client-agent relationship with a specific trust for ephemeral configurations, event, tracing, actions, and data flow interactions." Reading the provided definition of "trust," I'm not sure what "with a specific trust for" means in the sentence above. "The I2RS architecture document [I-D.ietf-i2rs-architecture] defines a secondary identity as the entity of some non-I2RS entity (e.g. application) which has requested a particular I2RS client perform an operation." Per my comment above, I would suggest just referencing the definition from the architecture document. The text above is circular ("the entity of some ... entity") and conflates an identity with an identifier. == Section 3.1 == Agree with Mirja that this section is superfluous. == Section 3.3 == Since the normative recommendation here isn't to be enforced by the protocol, why is it SHOULD rather than MUST? Same question applies to SEC-REQ-17. == Section 3.5 == Is the omission of normative language from Sec-REQ-20 purposeful? From nobody Wed Aug 17 08:07:31 2016 Return-Path: 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 3607A12D86F; Wed, 17 Aug 2016 08:07:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.699 X-Spam-Level: X-Spam-Status: No, score=-102.699 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] 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 VEWTiE9dT17c; Wed, 17 Aug 2016 08:07:18 -0700 (PDT) Received: from mail-qk0-x22b.google.com (mail-qk0-x22b.google.com [IPv6:2607:f8b0:400d:c09::22b]) (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 4BED712D80A; Wed, 17 Aug 2016 08:07:18 -0700 (PDT) Received: by mail-qk0-x22b.google.com with SMTP id z190so70772128qkc.0; Wed, 17 Aug 2016 08:07:18 -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; bh=rOwVlCP9yK2cDx1ROfPb9SEMqcsEXaPhMJNlgUgxFIY=; b=nSQtKAFs5IeZjhgX79ILNOYW04fyS2lJIexdyrP3tPLyT5ipGkG0hMDNMWYRX08te4 rqPe09TfOiW8v2RHkBHfyYXFxiKy2Jg997tnD6oZLLyeGlx8kLfULv1hCOf6VWxGmgAK ttjFCvh6syutiyScDW+lS7IGnBIUqHIjIpUbC66ZnI4TZB7cNTVwYYt5MhUogrnXfgio IWc4Hp0PV5IQ/IWVCH042zIoXoHrC6Ejjaz3BeZy5JlZ5wUNfQQAKF02z6YmON1Xzh3m CD+eLgLjM22KRwyDw1B4A+17EyG29RINOYc7+md2tDCg3mBZEI8/4JyJhbeKz1bgV8LF 39mA== 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; bh=rOwVlCP9yK2cDx1ROfPb9SEMqcsEXaPhMJNlgUgxFIY=; b=XeR5FU7JLt9kkppOdlueCt8ssJsYvmKRrOgaxX5zi0N9jZlfuyiSDVRRX1KlhFgny7 +exhRIoky1zi/5JsZpdXOFgKbnlzxt2m63QmlhQEbNOI0y1Y5nkqoxdPY4dIe6Wu40za oB1CyMmoX+2Cg565qSrEBTPjcKzf8KT+m/SCtPx9fdW0bMhhVn4q/9u1mgghJK8jlP4z lJo9eufNermGQiSUquGWmEy8ov5EDXYiHtx5N5aqHb+RCcPE356/dIEPcAji0Fi9qfwD xi7Bjtd8M98OC/ZQq5mAwpYviN4n72GOr/9hKm0Is/Pb8KRJbi5E+eUSj2+e/GLWgnkT hXQQ== X-Gm-Message-State: AEkooutOJLd1PPlwmWsg0tFQfUE+bF7vQRfyY41UPSctNTdyozJwv370SOVo9DrAIsxgaDdOLVBacCitPTPjQg== X-Received: by 10.55.75.17 with SMTP id y17mr45316373qka.83.1471446437433; Wed, 17 Aug 2016 08:07:17 -0700 (PDT) MIME-Version: 1.0 Received: by 10.237.52.193 with HTTP; Wed, 17 Aug 2016 08:07:16 -0700 (PDT) In-Reply-To: <147144567895.12152.15403435188950086025.idtracker@ietfa.amsl.com> References: <147144567895.12152.15403435188950086025.idtracker@ietfa.amsl.com> From: Alia Atlas Date: Wed, 17 Aug 2016 11:07:16 -0400 Message-ID: To: Alissa Cooper Content-Type: multipart/alternative; boundary=001a114a88c8359912053a45d281 Archived-At: Cc: Jeffrey Haas , "i2rs@ietf.org" , draft-ietf-i2rs-protocol-security-requirements@ietf.org, The IESG , i2rs-chairs@ietf.org Subject: Re: [i2rs] Alissa Cooper's Discuss on draft-ietf-i2rs-protocol-security-requirements-06: (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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Aug 2016 15:07:22 -0000 --001a114a88c8359912053a45d281 Content-Type: text/plain; charset=UTF-8 Hi Alissa, On Wed, Aug 17, 2016 at 10:54 AM, Alissa Cooper wrote: > Alissa Cooper has entered the following ballot position for > draft-ietf-i2rs-protocol-security-requirements-06: Discuss > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-i2rs-protocol- > security-requirements/ > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > == Section 3.2 == > > "A non-secure transport can be 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." > > What kind of telemetry data is it that is of no potential interest to any > eavesdropper? This is not my area of expertise so I'm having a hard time > conceiving of what that could be. I'm also wondering, since I2RS agents > and clients will have to support secure transports anyway (and RESTCONF > can only be used over a secure transport), why can't they be used for all > transfers, instead of allowing this loophole in the name of telemetry, > which undoubtedly will end up being used or exploited for other data > transfers? > > If the argument was that this loophole is needed for backwards > compatibility with insecure deployments of NETCONF or something like that > I think it would make more sense, but my impression from the text is that > those will have to be updated anyway to conform to the requirements in > this document. > Data coming from a router can come from many different line-cards and processors. The line-cards that may be providing the data are not going to be supporting the secure transports anyway. A goal is to allow easy distribution of streaming data and event notifications. As for what type of data, as far as I know, currently IPFIX streams telemetry data without integrity much less authorization protection. There are existing deployments that use gRPC now for streaming telemetry data. Regards, Alia > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > In general I agree with Mirja that where other documents already provide > definitions, they should be referenced, not copied or summarized, in this > document. > > == Section 2.1 == > > Using "privacy" as a synonym for "confidentiality" is outmoded, I think, > given current understanding of the many other facets of privacy (see, > e.g., RFC 6793). I would suggest dropping the definition of data privacy > and just using the word confidentiality when that is what you mean. > > == Section 2.2 == > > "The I2RS protocol exists as a higher-level protocol which may > combine other protocols (NETCONF, RESTCONF, IPFIX and others) > within a specific I2RS client-agent relationship with a specific > trust for ephemeral configurations, event, tracing, actions, and > data flow interactions." > > Reading the provided definition of "trust," I'm not sure what "with a > specific trust for" means in the sentence above. > > "The I2RS architecture document [I-D.ietf-i2rs-architecture] > defines a secondary identity as the entity of some non-I2RS entity > (e.g. application) which has requested a particular I2RS client > perform an operation." > > Per my comment above, I would suggest just referencing the definition > from the architecture document. The text above is circular ("the entity > of some ... entity") and conflates an identity with an identifier. > > == Section 3.1 == > > Agree with Mirja that this section is superfluous. > > == Section 3.3 == > > Since the normative recommendation here isn't to be enforced by the > protocol, why is it SHOULD rather than MUST? Same question applies to > SEC-REQ-17. > > == Section 3.5 == > > Is the omission of normative language from Sec-REQ-20 purposeful? > > > --001a114a88c8359912053a45d281 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Alissa,

On Wed, Aug 17, 2016 at 10:54 AM, Alissa Cooper <alissa@coop= erw.in> wrote:
Alissa Cooper has entered the following ballot position for
draft-ietf-i2rs-protocol-security-requirements-06: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/<= wbr>statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.= ietf.org/doc/draft-ietf-i2rs-protocol-security-requirements/<= br>


-----------------------------------------------------------------= -----
DISCUSS:
-----------------------------------------------------------------= -----

=3D=3D Section 3.2 =3D=3D

"A non-secure transport can be can be used for publishing telemetry =C2=A0 =C2=A0data or other operational state that was specifically indicate= d to
=C2=A0 =C2=A0non-confidential in the data model in the Yang syntax."
What kind of telemetry data is it that is of no potential interest to any eavesdropper? This is not my area of expertise so I'm having a hard tim= e
conceiving of what that could be. I'm also wondering, since I2RS agents=
and clients will have to support secure transports anyway (and RESTCONF
can only be used over a secure transport), why can't they be used for a= ll
transfers, instead of allowing this loophole in the name of telemetry,
which undoubtedly will end up being used or exploited for other data
transfers?

If the argument was that this loophole is needed for backwards
compatibility with insecure deployments of NETCONF or something like that I think it would make more sense, but my impression from the text is that those will have to be updated anyway to conform to the requirements in
this document.

Data coming from a route= r can come from many different line-cards and processors.
The lin= e-cards that may be providing the data are not going to be supporting the= =C2=A0
secure transports anyway.=C2=A0 A goal is to allow easy di= stribution of streaming data
and event notifications.=C2=A0 As fo= r what type of data, as far as I know, currently IPFIX=C2=A0
stre= ams telemetry data without integrity much less authorization protection.

There are existing deployments that use gRPC now for= streaming telemetry data.

=C2=A0Regards,
Alia
=C2=A0
----------------------------------------------------------------------
COMMENT:
-----------------------------------------------------------------= -----

In general I agree with Mirja that where other documents already provide definitions, they should be referenced, not copied or summarized, in this document.

=3D=3D Section 2.1 =3D=3D

Using "privacy" as a synonym for "confidentiality" is o= utmoded, I think,
given current understanding of the many other facets of privacy (see,
e.g., RFC 6793). I would suggest dropping the definition of data privacy and just using the word confidentiality when that is what you mean.

=3D=3D Section 2.2 =3D=3D

"The I2RS protocol exists as a higher-level protocol which may
=C2=A0 =C2=A0 =C2=A0 combine other protocols (NETCONF, RESTCONF, IPFIX and = others)
=C2=A0 =C2=A0 =C2=A0 within a specific I2RS client-agent relationship with = a specific
=C2=A0 =C2=A0 =C2=A0 trust for ephemeral configurations, event, tracing, ac= tions, and
=C2=A0 =C2=A0 =C2=A0 data flow interactions."

Reading the provided definition of "trust," I'm not sure what= "with a
specific trust for" means in the sentence above.

"The I2RS architecture document [I-D.ietf-i2rs-architecture]
=C2=A0 =C2=A0 =C2=A0 defines a secondary identity as the entity of some non= -I2RS entity
=C2=A0 =C2=A0 =C2=A0 (e.g. application) which has requested a particular I2= RS client
=C2=A0 =C2=A0 =C2=A0 perform an operation."

Per my comment above, I would suggest just referencing the definition
from the architecture document. The text above is circular ("the entit= y
of some ... entity") and conflates an identity with an identifier.

=3D=3D Section 3.1 =3D=3D

Agree with Mirja that this section is superfluous.

=3D=3D Section 3.3 =3D=3D

Since the normative recommendation here isn't to be enforced by the
protocol, why is it SHOULD rather than MUST? Same question applies to
SEC-REQ-17.

=3D=3D Section 3.5 =3D=3D

Is the omission of normative language from Sec-REQ-20 purposeful?



--001a114a88c8359912053a45d281-- From nobody Wed Aug 17 08:26:35 2016 Return-Path: X-Original-To: i2rs@ietf.org Delivered-To: i2rs@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 88F3812E02F; Wed, 17 Aug 2016 08:26:30 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.29.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147144759055.12279.3151924101733178466.idtracker@ietfa.amsl.com> Date: Wed, 17 Aug 2016 08:26:30 -0700 Archived-At: Cc: i2rs@ietf.org Subject: [i2rs] I-D Action: draft-ietf-i2rs-protocol-security-requirements-07.txt X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Aug 2016 15:26:30 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Interface to the Routing System of the IETF. Title : I2RS Security Related Requirements Authors : Susan Hares Daniel Migault Joel Halpern Filename : draft-ietf-i2rs-protocol-security-requirements-07.txt Pages : 14 Date : 2016-08-16 Abstract: This presents security-related requirements for the I2RS protocol for mutual authentication, transport protocols, data transfer and transactions. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-i2rs-protocol-security-requirements/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-i2rs-protocol-security-requirements-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-i2rs-protocol-security-requirements-07 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Aug 17 10:02:21 2016 Return-Path: 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 432BB12D8B1; Wed, 17 Aug 2016 10:02:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.72 X-Spam-Level: X-Spam-Status: No, score=-2.72 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cooperw.in header.b=Hb+33/t8; dkim=pass (1024-bit key) header.d=messagingengine.com header.b=kKTNIXgl 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 rvRBN9R_afcP; Wed, 17 Aug 2016 10:02:11 -0700 (PDT) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9901912D7AD; Wed, 17 Aug 2016 10:02:11 -0700 (PDT) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id E55F720534; Wed, 17 Aug 2016 13:02:10 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute3.internal (MEProxy); Wed, 17 Aug 2016 13:02:11 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=cooperw.in; h=cc :content-type:date:from:in-reply-to:message-id:mime-version :references:subject:to:x-sasl-enc:x-sasl-enc; s=mesmtp; bh=f9hwr MGQoMu1S8I8joDA65is2fo=; b=Hb+33/t8h169UMLpi4h9M+mmKyYe95WV+/G++ 99AH26asXgty/JMuoEMd3u+xKXuWjcoYn0ZyrQwL+dzMUK3O6+zxeczpf2OACZpd s1LwhNXGzIGaWcAs5mVlqoBGIxHFwOcBStfbFt5PQUiZIUTN8XZQkrVqR/WZxEii KdjMgg= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-sasl-enc :x-sasl-enc; s=smtpout; bh=f9hwrMGQoMu1S8I8joDA65is2fo=; b=kKTNI Xgluj7HZV6OZBcFUteVdtBufvbgxXAfa3mUfXU7AFsDivHfGYLWL/6exd7s+UHuV DR/aE6KvRZrjNXqBvUL2SCrbkgXBend2mNtjr8h6ewQQeAtISFF1KpU4iGV0a5NM X5cQBfIomNGe4Bn563OcKhtK6feZ0ag40vQ5I0= X-Sasl-enc: KACMzPd1knJXcX4G9d+Fm5cNPJQYULXivcVAJcHXBWrK 1471453330 Received: from dhcp-10-150-9-151.cisco.com (unknown [173.38.117.72]) by mail.messagingengine.com (Postfix) with ESMTPA id 62529CCDC0; Wed, 17 Aug 2016 13:02:10 -0400 (EDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_AE69AB72-FF42-4939-A134-15F44F3D5569" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Alissa Cooper In-Reply-To: Date: Wed, 17 Aug 2016 13:02:09 -0400 Message-Id: <5B604C19-7AEF-4C92-B452-A034749A5FCA@cooperw.in> References: <147144567895.12152.15403435188950086025.idtracker@ietfa.amsl.com> To: Alia Atlas X-Mailer: Apple Mail (2.3124) Archived-At: Cc: Jeffrey Haas , "i2rs@ietf.org" , draft-ietf-i2rs-protocol-security-requirements@ietf.org, IESG , i2rs-chairs@ietf.org Subject: Re: [i2rs] Alissa Cooper's Discuss on draft-ietf-i2rs-protocol-security-requirements-06: (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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Aug 2016 17:02:14 -0000 --Apple-Mail=_AE69AB72-FF42-4939-A134-15F44F3D5569 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Alia, > On Aug 17, 2016, at 11:07 AM, Alia Atlas wrote: >=20 > Hi Alissa, >=20 > On Wed, Aug 17, 2016 at 10:54 AM, Alissa Cooper > wrote: > Alissa Cooper has entered the following ballot position for > draft-ietf-i2rs-protocol-security-requirements-06: Discuss >=20 > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut = this > introductory paragraph, however.) >=20 >=20 > Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html = > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > = https://datatracker.ietf.org/doc/draft-ietf-i2rs-protocol-security-require= ments/ = >=20 >=20 >=20 > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- >=20 > =3D=3D Section 3.2 =3D=3D >=20 > "A non-secure transport can be 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." >=20 > What kind of telemetry data is it that is of no potential interest to = any > eavesdropper? This is not my area of expertise so I'm having a hard = time > conceiving of what that could be. I'm also wondering, since I2RS = agents > and clients will have to support secure transports anyway (and = RESTCONF > can only be used over a secure transport), why can't they be used for = all > transfers, instead of allowing this loophole in the name of telemetry, > which undoubtedly will end up being used or exploited for other data > transfers? >=20 > If the argument was that this loophole is needed for backwards > compatibility with insecure deployments of NETCONF or something like = that > I think it would make more sense, but my impression from the text is = that > those will have to be updated anyway to conform to the requirements in > this document. >=20 > Data coming from a router can come from many different line-cards and = processors. > The line-cards that may be providing the data are not going to be = supporting the=20 > secure transports anyway.=20 Will they also not be supporting the I2RS protocol then, given the = requirement for support of a secure transport? > A goal is to allow easy distribution of streaming data > and event notifications. As for what type of data, as far as I know, = currently IPFIX=20 > streams telemetry data without integrity much less authorization = protection. What I=E2=80=99m questioning is the choice to extend that model to cases = where a third-party controller or application is one endpoint of the = data exchange, which is what I thought was part of the motivation for = I2RS (happy to be corrected though). >=20 > There are existing deployments that use gRPC now for streaming = telemetry data. Ok. So is the implication that the requirements here are needed for = backwards compatability with those deployments? Thanks, Alissa >=20 > Regards, > Alia > =20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > In general I agree with Mirja that where other documents already = provide > definitions, they should be referenced, not copied or summarized, in = this > document. >=20 > =3D=3D Section 2.1 =3D=3D >=20 > Using "privacy" as a synonym for "confidentiality" is outmoded, I = think, > given current understanding of the many other facets of privacy (see, > e.g., RFC 6793). I would suggest dropping the definition of data = privacy > and just using the word confidentiality when that is what you mean. >=20 > =3D=3D Section 2.2 =3D=3D >=20 > "The I2RS protocol exists as a higher-level protocol which may > combine other protocols (NETCONF, RESTCONF, IPFIX and others) > within a specific I2RS client-agent relationship with a specific > trust for ephemeral configurations, event, tracing, actions, and > data flow interactions." >=20 > Reading the provided definition of "trust," I'm not sure what "with a > specific trust for" means in the sentence above. >=20 > "The I2RS architecture document [I-D.ietf-i2rs-architecture] > defines a secondary identity as the entity of some non-I2RS = entity > (e.g. application) which has requested a particular I2RS client > perform an operation." >=20 > Per my comment above, I would suggest just referencing the definition > from the architecture document. The text above is circular ("the = entity > of some ... entity") and conflates an identity with an identifier. >=20 > =3D=3D Section 3.1 =3D=3D >=20 > Agree with Mirja that this section is superfluous. >=20 > =3D=3D Section 3.3 =3D=3D >=20 > Since the normative recommendation here isn't to be enforced by the > protocol, why is it SHOULD rather than MUST? Same question applies to > SEC-REQ-17. >=20 > =3D=3D Section 3.5 =3D=3D >=20 > Is the omission of normative language from Sec-REQ-20 purposeful? --Apple-Mail=_AE69AB72-FF42-4939-A134-15F44F3D5569 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Hi Alia,

On Aug 17, 2016, at 11:07 AM, = Alia Atlas <akatlas@gmail.com> wrote:

Hi Alissa,

On Wed, = Aug 17, 2016 at 10:54 AM, Alissa Cooper <alissa@cooperw.in> wrote:
Alissa Cooper = has entered the following ballot position for
draft-ietf-i2rs-protocol-security-requirements-06: Discuss

When responding, please keep the subject line intact and = reply to all
email addresses included in the To and CC = lines. (Feel free to cut this
introductory paragraph, = however.)


Please refer = to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT = positions.


The document, = along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-i2rs-protocol-security-requirements/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

=3D=3D Section 3.2 =3D=3D

"A non-secure transport can be 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."

What kind of telemetry data is it that is of = no potential interest to any
eavesdropper? This is not my = area of expertise so I'm having a hard time
conceiving of = what that could be. I'm also wondering, since I2RS agents
and clients will have to support secure transports anyway = (and RESTCONF
can only be used over a secure transport), = why can't they be used for all
transfers, instead of = allowing this loophole in the name of telemetry,
which = undoubtedly will end up being used or exploited for other data
transfers?

If the argument was = that this loophole is needed for backwards
compatibility = with insecure deployments of NETCONF or something like that
I think it would make more sense, but my impression from the = text is that
those will have to be updated anyway to = conform to the requirements in
this document.

Data coming from a router can come from many different = line-cards and processors.
The line-cards that may = be providing the data are not going to be supporting the 
secure transports anyway.  =

Will they also not be supporting the I2RS protocol = then, given the requirement for support of a secure = transport?


A goal = is to allow easy distribution of streaming data
and = event notifications.  As for what type of data, as far as I know, = currently IPFIX 
streams telemetry data = without integrity much less authorization = protection.

What I=E2=80=99m questioning is the choice to = extend that model to cases where a third-party controller or application = is one endpoint of the data exchange, which is what I thought was part = of the motivation for I2RS (happy to be corrected though).


There are existing deployments that use = gRPC now for streaming telemetry data.

Ok. So is the implication that the requirements = here are needed for backwards compatability with those = deployments?

Thanks,
Alissa


 Regards,
Alia
 
----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

In general I agree with Mirja that where other = documents already provide
definitions, they should be = referenced, not copied or summarized, in this
document.

=3D=3D Section 2.1 =3D=3D

Using "privacy" as a synonym for "confidentiality" is = outmoded, I think,
given current understanding of the many = other facets of privacy (see,
e.g., RFC 6793). I would = suggest dropping the definition of data privacy
and just = using the word confidentiality when that is what you mean.

=3D=3D Section 2.2 =3D=3D

"The I2RS protocol exists as a higher-level protocol which = may
      combine other protocols = (NETCONF, RESTCONF, IPFIX and others)
    =   within a = specific I2RS client-agent relationship with a specific
      trust for ephemeral = configurations, event, tracing, actions, and
    =   data flow = interactions."

Reading the provided = definition of "trust," I'm not sure what "with a
specific = trust for" means in the sentence above.

"The = I2RS architecture document [I-D.ietf-i2rs-architecture]
      defines a secondary = identity as the entity of some non-I2RS entity
  =     (e.g. = application) which has requested a particular I2RS client
      perform an operation."

Per my comment above, I would suggest just = referencing the definition
from the architecture document. = The text above is circular ("the entity
of some ... = entity") and conflates an identity with an identifier.

=3D=3D Section 3.1 =3D=3D

Agree = with Mirja that this section is superfluous.

=3D=3D Section 3.3 =3D=3D

Since = the normative recommendation here isn't to be enforced by the
protocol, why is it SHOULD rather than MUST? Same question = applies to
SEC-REQ-17.

=3D=3D = Section 3.5 =3D=3D

Is the omission of = normative language from Sec-REQ-20 = purposeful?

= --Apple-Mail=_AE69AB72-FF42-4939-A134-15F44F3D5569-- From nobody Wed Aug 17 11:24:39 2016 Return-Path: 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 883E612D727; Wed, 17 Aug 2016 11:24:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.548 X-Spam-Level: X-Spam-Status: No, score=-5.548 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_MED=-2.3, RP_MATCHES_RCVD=-1.247, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie 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 DjJOkYc9Ez2U; Wed, 17 Aug 2016 11:24:29 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3772812D1DD; Wed, 17 Aug 2016 11:24:29 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id DF211BE50; Wed, 17 Aug 2016 19:24:27 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AZRgeasV5wFW; Wed, 17 Aug 2016 19:24:26 +0100 (IST) Received: from [127.0.0.1] (unknown [95.39.226.90]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 8E424BE2F; Wed, 17 Aug 2016 19:24:25 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1471458266; bh=hm31Xi97Kb62EG0Lpad/sMarPcVpJIlp6SitORlF3aU=; h=To:Cc:From:Subject:In-Reply-To:References:Date:From; b=RtXg9mukD7UW5MIQD24l9S8pEIBf+1BOLPFFmcgSPN2wP+J6hwgFBzuj6hqIRpHXY VHCLTm/hzJhVKSCy8aDq64oOGaBSPOI1bX8v1/ahDfmmcesof0x0v7G4rpQW1N6QJy hfZCxVW9Bu37AF9iLxGG/zuDGOwId+PRl/hbLFQE= X-Priority: 3 To: alissa@cooperw.in From: stephen.farrell@cs.tcd.ie In-Reply-To: <5B604C19-7AEF-4C92-B452-A034749A5FCA@cooperw.in> References: <147144567895.12152.15403435188950086025.idtracker@ietfa.amsl.com> <5B604C19-7AEF-4C92-B452-A034749A5FCA@cooperw.in> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 Date: Wed, 17 Aug 2016 18:24:22 +0000 Message-ID: MIME-Version: 1.0 Archived-At: Cc: i2rs@ietf.org, i2rs-chairs@ietf.org, akatlas@gmail.com, iesg@ietf.org, jhaas@pfrc.org, draft-ietf-i2rs-protocol-security-requirements@ietf.org Subject: Re: [i2rs] Alissa Cooper's Discuss on draft-ietf-i2rs-protocol-security-requirements-06: (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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Aug 2016 18:24:32 -0000 SGl5YSwgDQoNCkknbSBvbiB2YWNhdGlvbiBzbyB3b24ndCBiZSBiYWxsb3RpbmcgdGhpcyB3ZWVr IGFuZCBJIG9ubHkgaGFkIGEgcXVpY2sgZmxpY2sgb2YgdGhpcywgYnV0IGlmIEknZCBoYWQgdGlt ZSBmb3IgYSBwcm9wZXIgcmVhZCBJIHRoaW5rIEknZCBiZSBhc2tpbmcgaG93IHJlYWxpc3RpYyBh cmUgdGhlc2UgcmVxdWlyZW1lbnRzLCBwb3NzaWJseSBhcyBhIGRpc2N1c3MgYmFsbG90LiBJZiBz b21lb25lIHdhbnRlZCB0byBoaXQgZGVmZXIgYW5kIGJsYW1lIG1lIChzb3JyeSBJIGRvbid0IGhh dmUgdGhlIHJpZ2h0IGRldmljZXMgd2l0aCBtZSB0byBkbyB0aGF0KSB0aGF0J2QgYmUgZ29vZC4g QnV0IGlmIHRoaXMgZHJhZnQgaXMgIHRpbWUtY3JpdGljYWwgZm9yIHRoZSBXRyB0aGVuIHBsZWFz ZSBpZ25vcmUgdGhlIGFib3ZlLiANCg0KUy4gDQoNCk9uIFdlZCBBdWcgMTcgMTk6MDI6MDkgMjAx NiBHTVQrMDIwMCwgQWxpc3NhIENvb3BlciB3cm90ZToNCj4gSGkgQWxpYSwNCj4gDQo+ID4gT24g QXVnIDE3LCAyMDE2LCBhdCAxMTowNyBBTSwgQWxpYSBBdGxhcyA8YWthdGxhc0BnbWFpbC5jb20+ IHdyb3RlOg0KPiA+IA0KPiA+IEhpIEFsaXNzYSwNCj4gPiANCj4gPiBPbiBXZWQsIEF1ZyAxNywg MjAxNiBhdCAxMDo1NCBBTSwgQWxpc3NhIENvb3BlciA8YWxpc3NhQGNvb3BlcncuaW4gPG1haWx0 bzphbGlzc2FAY29vcGVydy5pbj4+IHdyb3RlOg0KPiA+IEFsaXNzYSBDb29wZXIgaGFzIGVudGVy ZWQgdGhlIGZvbGxvd2luZyBiYWxsb3QgcG9zaXRpb24gZm9yDQo+ID4gZHJhZnQtaWV0Zi1pMnJz LXByb3RvY29sLXNlY3VyaXR5LXJlcXVpcmVtZW50cy0wNjogRGlzY3Vzcw0KPiA+IA0KPiA+IFdo ZW4gcmVzcG9uZGluZywgcGxlYXNlIGtlZXAgdGhlIHN1YmplY3QgbGluZSBpbnRhY3QgYW5kIHJl cGx5IHRvIGFsbA0KPiA+IGVtYWlsIGFkZHJlc3NlcyBpbmNsdWRlZCBpbiB0aGUgVG8gYW5kIEND IGxpbmVzLiAoRmVlbCBmcmVlIHRvIGN1dCB0aGlzDQo+ID4gaW50cm9kdWN0b3J5IHBhcmFncmFw aCwgaG93ZXZlci4pDQo+ID4gDQo+ID4gDQo+ID4gUGxlYXNlIHJlZmVyIHRvIGh0dHBzOi8vd3d3 LmlldGYub3JnL2llc2cvc3RhdGVtZW50L2Rpc2N1c3MtY3JpdGVyaWEuaHRtbCA8aHR0cHM6Ly93 d3cuaWV0Zi5vcmcvaWVzZy9zdGF0ZW1lbnQvZGlzY3Vzcy1jcml0ZXJpYS5odG1sPg0KPiA+IGZv ciBtb3JlIGluZm9ybWF0aW9uIGFib3V0IElFU0cgRElTQ1VTUyBhbmQgQ09NTUVOVCBwb3NpdGlv bnMuDQo+ID4gDQo+ID4gDQo+ID4gVGhlIGRvY3VtZW50LCBhbG9uZyB3aXRoIG90aGVyIGJhbGxv dCBwb3NpdGlvbnMsIGNhbiBiZSBmb3VuZCBoZXJlOg0KPiA+IGh0dHBzOi8vZGF0YXRyYWNrZXIu aWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtaTJycy1wcm90b2NvbC1zZWN1cml0eS1yZXF1aXJlbWVu dHMvIDxodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLWkycnMtcHJv dG9jb2wtc2VjdXJpdHktcmVxdWlyZW1lbnRzLz4NCj4gPiANCj4gPiANCj4gPiANCj4gPiAtLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tDQo+ID4gRElTQ1VTUzoNCj4gPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+ID4gDQo+ID4gPT0g U2VjdGlvbiAzLjIgPT0NCj4gPiANCj4gPiAiQSBub24tc2VjdXJlIHRyYW5zcG9ydCBjYW4gYmUg Y2FuIGJlIHVzZWQgZm9yIHB1Ymxpc2hpbmcgdGVsZW1ldHJ5DQo+ID4gICAgZGF0YSBvciBvdGhl ciBvcGVyYXRpb25hbCBzdGF0ZSB0aGF0IHdhcyBzcGVjaWZpY2FsbHkgaW5kaWNhdGVkIHRvDQo+ ID4gICAgbm9uLWNvbmZpZGVudGlhbCBpbiB0aGUgZGF0YSBtb2RlbCBpbiB0aGUgWWFuZyBzeW50 YXguIg0KPiA+IA0KPiA+IFdoYXQga2luZCBvZiB0ZWxlbWV0cnkgZGF0YSBpcyBpdCB0aGF0IGlz IG9mIG5vIHBvdGVudGlhbCBpbnRlcmVzdCB0byBhbnkNCj4gPiBlYXZlc2Ryb3BwZXI/IFRoaXMg aXMgbm90IG15IGFyZWEgb2YgZXhwZXJ0aXNlIHNvIEknbSBoYXZpbmcgYSBoYXJkIHRpbWUNCj4g PiBjb25jZWl2aW5nIG9mIHdoYXQgdGhhdCBjb3VsZCBiZS4gSSdtIGFsc28gd29uZGVyaW5nLCBz aW5jZSBJMlJTIGFnZW50cw0KPiA+IGFuZCBjbGllbnRzIHdpbGwgaGF2ZSB0byBzdXBwb3J0IHNl Y3VyZSB0cmFuc3BvcnRzIGFueXdheSAoYW5kIFJFU1RDT05GDQo+ID4gY2FuIG9ubHkgYmUgdXNl ZCBvdmVyIGEgc2VjdXJlIHRyYW5zcG9ydCksIHdoeSBjYW4ndCB0aGV5IGJlIHVzZWQgZm9yIGFs bA0KPiA+IHRyYW5zZmVycywgaW5zdGVhZCBvZiBhbGxvd2luZyB0aGlzIGxvb3Bob2xlIGluIHRo ZSBuYW1lIG9mIHRlbGVtZXRyeSwNCj4gPiB3aGljaCB1bmRvdWJ0ZWRseSB3aWxsIGVuZCB1cCBi ZWluZyB1c2VkIG9yIGV4cGxvaXRlZCBmb3Igb3RoZXIgZGF0YQ0KPiA+IHRyYW5zZmVycz8NCj4g PiANCj4gPiBJZiB0aGUgYXJndW1lbnQgd2FzIHRoYXQgdGhpcyBsb29waG9sZSBpcyBuZWVkZWQg Zm9yIGJhY2t3YXJkcw0KPiA+IGNvbXBhdGliaWxpdHkgd2l0aCBpbnNlY3VyZSBkZXBsb3ltZW50 cyBvZiBORVRDT05GIG9yIHNvbWV0aGluZyBsaWtlIHRoYXQNCj4gPiBJIHRoaW5rIGl0IHdvdWxk IG1ha2UgbW9yZSBzZW5zZSwgYnV0IG15IGltcHJlc3Npb24gZnJvbSB0aGUgdGV4dCBpcyB0aGF0 DQo+ID4gdGhvc2Ugd2lsbCBoYXZlIHRvIGJlIHVwZGF0ZWQgYW55d2F5IHRvIGNvbmZvcm0gdG8g dGhlIHJlcXVpcmVtZW50cyBpbg0KPiA+IHRoaXMgZG9jdW1lbnQuDQo+ID4gDQo+ID4gRGF0YSBj b21pbmcgZnJvbSBhIHJvdXRlciBjYW4gY29tZSBmcm9tIG1hbnkgZGlmZmVyZW50IGxpbmUtY2Fy ZHMgYW5kIHByb2Nlc3NvcnMuDQo+ID4gVGhlIGxpbmUtY2FyZHMgdGhhdCBtYXkgYmUgcHJvdmlk aW5nIHRoZSBkYXRhIGFyZSBub3QgZ29pbmcgdG8gYmUgc3VwcG9ydGluZyB0aGUgDQo+ID4gc2Vj dXJlIHRyYW5zcG9ydHMgYW55d2F5LiANCj4gDQo+IFdpbGwgdGhleSBhbHNvIG5vdCBiZSBzdXBw b3J0aW5nIHRoZSBJMlJTIHByb3RvY29sIHRoZW4sIGdpdmVuIHRoZSByZXF1aXJlbWVudCBmb3Ig c3VwcG9ydCBvZiBhIHNlY3VyZSB0cmFuc3BvcnQ/DQo+IA0KPiANCj4gPiBBIGdvYWwgaXMgdG8g YWxsb3cgZWFzeSBkaXN0cmlidXRpb24gb2Ygc3RyZWFtaW5nIGRhdGENCj4gPiBhbmQgZXZlbnQg bm90aWZpY2F0aW9ucy4gIEFzIGZvciB3aGF0IHR5cGUgb2YgZGF0YSwgYXMgZmFyIGFzIEkga25v dywgY3VycmVudGx5IElQRklYIA0KPiA+IHN0cmVhbXMgdGVsZW1ldHJ5IGRhdGEgd2l0aG91dCBp bnRlZ3JpdHkgbXVjaCBsZXNzIGF1dGhvcml6YXRpb24gcHJvdGVjdGlvbi4NCj4gDQo+IFdoYXQg SeKAmW0gcXVlc3Rpb25pbmcgaXMgdGhlIGNob2ljZSB0byBleHRlbmQgdGhhdCBtb2RlbCB0byBj YXNlcyB3aGVyZSBhIHRoaXJkLXBhcnR5IGNvbnRyb2xsZXIgb3IgYXBwbGljYXRpb24gaXMgb25l IGVuZHBvaW50IG9mIHRoZSBkYXRhIGV4Y2hhbmdlLCB3aGljaCBpcyB3aGF0IEkgdGhvdWdodCB3 YXMgcGFydCBvZiB0aGUgbW90aXZhdGlvbiBmb3IgSTJSUyAoaGFwcHkgdG8gYmUgY29ycmVjdGVk IHRob3VnaCkuDQo+IA0KPiA+IA0KPiA+IFRoZXJlIGFyZSBleGlzdGluZyBkZXBsb3ltZW50cyB0 aGF0IHVzZSBnUlBDIG5vdyBmb3Igc3RyZWFtaW5nIHRlbGVtZXRyeSBkYXRhLg0KPiANCj4gT2su IFNvIGlzIHRoZSBpbXBsaWNhdGlvbiB0aGF0IHRoZSByZXF1aXJlbWVudHMgaGVyZSBhcmUgbmVl ZGVkIGZvciBiYWNrd2FyZHMgY29tcGF0YWJpbGl0eSB3aXRoIHRob3NlIGRlcGxveW1lbnRzPw0K PiANCj4gVGhhbmtzLA0KPiBBbGlzc2ENCj4gDQo+ID4gDQo+ID4gIFJlZ2FyZHMsDQo+ID4gQWxp YQ0KPiA+ICANCj4gPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+ID4gQ09NTUVOVDoNCj4gPiAtLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tDQo+ID4gDQo+ID4gSW4gZ2VuZXJhbCBJIGFncmVlIHdpdGggTWlyamEgdGhhdCB3aGVyZSBv dGhlciBkb2N1bWVudHMgYWxyZWFkeSBwcm92aWRlDQo+ID4gZGVmaW5pdGlvbnMsIHRoZXkgc2hv dWxkIGJlIHJlZmVyZW5jZWQsIG5vdCBjb3BpZWQgb3Igc3VtbWFyaXplZCwgaW4gdGhpcw0KPiA+ IGRvY3VtZW50Lg0KPiA+IA0KPiA+ID09IFNlY3Rpb24gMi4xID09DQo+ID4gDQo+ID4gVXNpbmcg InByaXZhY3kiIGFzIGEgc3lub255bSBmb3IgImNvbmZpZGVudGlhbGl0eSIgaXMgb3V0bW9kZWQs IEkgdGhpbmssDQo+ID4gZ2l2ZW4gY3VycmVudCB1bmRlcnN0YW5kaW5nIG9mIHRoZSBtYW55IG90 aGVyIGZhY2V0cyBvZiBwcml2YWN5IChzZWUsDQo+ID4gZS5nLiwgUkZDIDY3OTMpLiBJIHdvdWxk IHN1Z2dlc3QgZHJvcHBpbmcgdGhlIGRlZmluaXRpb24gb2YgZGF0YSBwcml2YWN5DQo+ID4gYW5k IGp1c3QgdXNpbmcgdGhlIHdvcmQgY29uZmlkZW50aWFsaXR5IHdoZW4gdGhhdCBpcyB3aGF0IHlv dSBtZWFuLg0KPiA+IA0KPiA+ID09IFNlY3Rpb24gMi4yID09DQo+ID4gDQo+ID4gIlRoZSBJMlJT IHByb3RvY29sIGV4aXN0cyBhcyBhIGhpZ2hlci1sZXZlbCBwcm90b2NvbCB3aGljaCBtYXkNCj4g PiAgICAgICBjb21iaW5lIG90aGVyIHByb3RvY29scyAoTkVUQ09ORiwgUkVTVENPTkYsIElQRklY IGFuZCBvdGhlcnMpDQo+ID4gICAgICAgd2l0aGluIGEgc3BlY2lmaWMgSTJSUyBjbGllbnQtYWdl bnQgcmVsYXRpb25zaGlwIHdpdGggYSBzcGVjaWZpYw0KPiA+ICAgICAgIHRydXN0IGZvciBlcGhl bWVyYWwgY29uZmlndXJhdGlvbnMsIGV2ZW50LCB0cmFjaW5nLCBhY3Rpb25zLCBhbmQNCj4gPiAg ICAgICBkYXRhIGZsb3cgaW50ZXJhY3Rpb25zLiINCj4gPiANCj4gPiBSZWFkaW5nIHRoZSBwcm92 aWRlZCBkZWZpbml0aW9uIG9mICJ0cnVzdCwiIEknbSBub3Qgc3VyZSB3aGF0ICJ3aXRoIGENCj4g PiBzcGVjaWZpYyB0cnVzdCBmb3IiIG1lYW5zIGluIHRoZSBzZW50ZW5jZSBhYm92ZS4NCj4gPiAN Cj4gPiAiVGhlIEkyUlMgYXJjaGl0ZWN0dXJlIGRvY3VtZW50IFtJLUQuaWV0Zi1pMnJzLWFyY2hp dGVjdHVyZV0NCj4gPiAgICAgICBkZWZpbmVzIGEgc2Vjb25kYXJ5IGlkZW50aXR5IGFzIHRoZSBl bnRpdHkgb2Ygc29tZSBub24tSTJSUyBlbnRpdHkNCj4gPiAgICAgICAoZS5nLiBhcHBsaWNhdGlv bikgd2hpY2ggaGFzIHJlcXVlc3RlZCBhIHBhcnRpY3VsYXIgSTJSUyBjbGllbnQNCj4gPiAgICAg ICBwZXJmb3JtIGFuIG9wZXJhdGlvbi4iDQo+ID4gDQo+ID4gUGVyIG15IGNvbW1lbnQgYWJvdmUs IEkgd291bGQgc3VnZ2VzdCBqdXN0IHJlZmVyZW5jaW5nIHRoZSBkZWZpbml0aW9uDQo+ID4gZnJv bSB0aGUgYXJjaGl0ZWN0dXJlIGRvY3VtZW50LiBUaGUgdGV4dCBhYm92ZSBpcyBjaXJjdWxhciAo InRoZSBlbnRpdHkNCj4gPiBvZiBzb21lIC4uLiBlbnRpdHkiKSBhbmQgY29uZmxhdGVzIGFuIGlk ZW50aXR5IHdpdGggYW4gaWRlbnRpZmllci4NCj4gPiANCj4gPiA9PSBTZWN0aW9uIDMuMSA9PQ0K PiA+IA0KPiA+IEFncmVlIHdpdGggTWlyamEgdGhhdCB0aGlzIHNlY3Rpb24gaXMgc3VwZXJmbHVv dXMuDQo+ID4gDQo+ID4gPT0gU2VjdGlvbiAzLjMgPT0NCj4gPiANCj4gPiBTaW5jZSB0aGUgbm9y bWF0aXZlIHJlY29tbWVuZGF0aW9uIGhlcmUgaXNuJ3QgdG8gYmUgZW5mb3JjZWQgYnkgdGhlDQo+ ID4gcHJvdG9jb2wsIHdoeSBpcyBpdCBTSE9VTEQgcmF0aGVyIHRoYW4gTVVTVD8gU2FtZSBxdWVz dGlvbiBhcHBsaWVzIHRvDQo+ID4gU0VDLVJFUS0xNy4NCj4gPiANCj4gPiA9PSBTZWN0aW9uIDMu NSA9PQ0KPiA+IA0KPiA+IElzIHRoZSBvbWlzc2lvbiBvZiBub3JtYXRpdmUgbGFuZ3VhZ2UgZnJv bSBTZWMtUkVRLTIwIHB1cnBvc2VmdWw/DQo+IA0KPg== From nobody Wed Aug 17 14:11:32 2016 Return-Path: X-Original-To: i2rs@ietf.org Delivered-To: i2rs@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 406C512D73A; Wed, 17 Aug 2016 14:11:27 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "Ben Campbell" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.29.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147146828725.23668.4809857469458650681.idtracker@ietfa.amsl.com> Date: Wed, 17 Aug 2016 14:11:27 -0700 Archived-At: Cc: jhaas@pfrc.org, i2rs@ietf.org, i2rs-chairs@ietf.org, draft-ietf-i2rs-protocol-security-requirements@ietf.org Subject: [i2rs] Ben Campbell'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 List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Aug 2016 21:11:27 -0000 Ben Campbell has entered the following ballot position for draft-ietf-i2rs-protocol-security-requirements-07: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-i2rs-protocol-security-requirements/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- In section 3.4, the text says that the requirements that the integrity protection mechanisms can actually provide integrity protection are SHOULD because some communication may occur over non-secure channels. That does not follow, since the rationale is about use, while the actual requirement is about capability. As currently written, it leaves it possible for people to select a protocol that cannot provide integrity protection at all. I think the SHOULDs in 14 and 15 need to be MUSTS. In the third paragaph of 3.2, Isn't the point to say that ephemeral data MUST be sent over a secure transport unless the data model explicitly labels it as safe for insecure transports? As written, it seems to leave room to send data that is not labeled as safe to also be sent over insecure transports. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- -2.1: I am on the fence about other's comments about copying definitions here--but if you do copy them here, it seems strange to not mention "client" or "agent". I agree with Alissa about equating privacy and confidentiality. -3.1,: I’m confused by the first paragraph. I don’t find strings of the form of SEC-REQ-XX in 7921. I think _this_ doc sets these requirements, right? It’s not clear to me how 5 and 6 differ. Is it just a matter of the additional “before establishing a connection†part in 6? -3.4: Isn't 15 simply a restatement of the third item under 14? 3.5: The MAYs in 19 and 20 seem like statements of fact. (That is, do they simply recognize reality, or to they grant permission?) From nobody Wed Aug 17 14:35:46 2016 Return-Path: X-Original-To: i2rs@ietf.org Delivered-To: i2rs@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5841112D17A; Wed, 17 Aug 2016 14:35:42 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Kathleen Moriarty" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.29.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147146974235.23784.4389421535496134619.idtracker@ietfa.amsl.com> Date: Wed, 17 Aug 2016 14:35:42 -0700 Archived-At: Cc: jhaas@pfrc.org, i2rs@ietf.org, i2rs-chairs@ietf.org, draft-ietf-i2rs-protocol-security-requirements@ietf.org Subject: [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 List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Aug 2016 21:35:42 -0000 Kathleen Moriarty has entered the following ballot position for draft-ietf-i2rs-protocol-security-requirements-07: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-i2rs-protocol-security-requirements/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Thanks for your work on this draft. There may be some overlap in points, I tried to minimize them... ---- Section 3.1: I don't see any actual requirements for mutual authentication in this section, just requirements for identifiers. Did I miss something? Are all mutual auth schemes in scope? Are there any considerations for mutual authentication (passwords, keys, etc.)? ---- I share the same concern as others for secure transport, but since there are already discusses on that, I have one comment to add to the existing discusses below. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Section 3: Can you clarify the second to last sentence? Do you mean there are sections that indicate an insecure transport should be used? I2RS allows the use of an insecure transport for portions of data models that clearly indicate insecure transport. Perhaps: I2RS allows the use of an insecure transport for portions of data models that clearly indicate the use of an insecure transport. ---- Section 3.2 I agree with Alissa's discuss point on the following sentence (that could also be reworded a bit): A non-secure transport can be 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. ---- Section 3.4: In the following text: SEC-REQ-15: The integrity that the message data is not repeated means that I2RS client to I2RS agent transport SHOULD protect against replay attack I'm not sure why this just doesn't say: SEC-REQ-15: I2RS client to I2RS agent transport SHOULD protect against replay attack The additional text doesn't add anything and sounds a bit confusing. ---- Nit: I'm not sure these definitions add any value as they seem to restate the term defined: I2RS protocol data integrity The transfer of data via the I2RS protocol has the property of data integrity described in [RFC4949]. I2RS component protocols Protocols which are combined to create the I2RS protocol. ----- I also agree that the definitions from 4949 should be removed. Thank you in advance. From nobody Wed Aug 17 15:03:13 2016 Return-Path: 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 5981B12D7D5; Wed, 17 Aug 2016 15:03:12 -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 OHpCdUKzxs84; Wed, 17 Aug 2016 15:03:10 -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 5336212D7D6; Wed, 17 Aug 2016 15:03:10 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id EC3231C01C8; Wed, 17 Aug 2016 15:03:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1471471389; bh=gD6fPU43wFhXHDDbBymHxZ5+bs8FbS9a4faklrC9Uhg=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=AuKZwD/8aLA6rQfie0M+kzjvT3gGMl/VYDaSAAdzn8TBJGULhEHLKL4c7jyOf+3UN 4otEKEg69+yXj9aY5th+U8IYgvyUmq3V6CaCmxNSTZ0qe0ky8CNAJFSAsNp4JzuhtK pM2lmmalOdCUHzmLd5p2koLWFXdOLG2Z577y4sJM= 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 1EE781C0340; Wed, 17 Aug 2016 15:03:09 -0700 (PDT) To: Ben Campbell , The IESG References: <147146828725.23668.4809857469458650681.idtracker@ietfa.amsl.com> From: "Joel M. Halpern" Message-ID: <7ed760da-c57c-b2f7-9045-b6c033a6bcf3@joelhalpern.com> Date: Wed, 17 Aug 2016 18:04:56 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <147146828725.23668.4809857469458650681.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: jhaas@pfrc.org, i2rs@ietf.org, i2rs-chairs@ietf.org, draft-ietf-i2rs-protocol-security-requirements@ietf.org Subject: Re: [i2rs] Ben Campbell'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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Aug 2016 22:03:12 -0000 Making sure I understand what is being asked in each of these items, hence in-line. Yours, Joel On 8/17/16 5:11 PM, Ben Campbell wrote: > Ben Campbell has entered the following ballot position for > draft-ietf-i2rs-protocol-security-requirements-07: Discuss > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-i2rs-protocol-security-requirements/ > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > In section 3.4, the text says that the requirements that the integrity > protection mechanisms can actually provide integrity protection are > SHOULD because some communication may occur over non-secure channels. > That does not follow, since the rationale is about use, while the actual > requirement is about capability. As currently written, it leaves it > possible for people to select a protocol that cannot provide integrity > protection at all. I think the SHOULDs in 14 and 15 need to be MUSTS. I think what you are asking is that we rephrase these requirements to indicate that implementations must include integrity protection capability which meets these requirements. And that the current text explaining the SHOULD becomes text about when these mechanisms SHOULD be used? > > In the third paragaph of 3.2, Isn't the point to say that ephemeral data > MUST be sent over a secure transport unless the data model explicitly > labels it as safe for insecure transports? As written, it seems to leave > room to send data that is not labeled as safe to also be sent over > insecure transports. I am having trouble seeing the problem. The text, as far as I can tell, says "SHOULD be protect", and then goes on to say "except when the model says it is okay to send unprotected". That seems to say the right thing. > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > -2.1: I am on the fence about other's comments about copying definitions > here--but if you do copy them here, it seems strange to not mention > "client" or "agent". I can live with just listing the terms and references, without the text. It makes reading a little more complex for new readers, but avoids any risk of error in copying. > > I agree with Alissa about equating privacy and confidentiality. I was going to simply say "sure", but REQ-20 sems to need to still say "privacy". Not sure what you (individually or collectively) would like us to do. I do note that if the terminology has shifted from that documented in 4949, it would be helpful to those of us who do not live with it daily to have some way to know such. > > -3.1,: > I’m confused by the first paragraph. I don’t find strings of the form of > SEC-REQ-XX in 7921. I think _this_ doc sets these requirements, right? Section 3.1 is trying to recapitulate for context requirements that are stated in textual form in RFC 7921. No, they are not lsited as SEQ_REQ-XX or even REQ-XX in RFC 7921. Thus, in addition to context, listing them here allows us to give them numbers for consistency of discussion. (Thus, this is a case where repetition adds value.) > > It’s not clear to me how 5 and 6 differ. Is it just a matter of the > additional “before establishing a connection†part in 6? As far as I know, it is indeed just a matter of the timing being added in 6. If this is a problem, we can collapse them. > > -3.4: Isn't 15 simply a restatement of the third item under 14? that looks like an error on our part. Maybe I missed something, but I think we can drop that when we rewrite to address your major comment. > > 3.5: The MAYs in 19 and 20 seem like statements of fact. (That is, do > they simply recognize reality, or to they grant permission?) Re-reading these, the MAY in 19 is a description of allowed architecture, and seems to me to wall within the 2119 meaning. The may in 20 is subtler. I think it is recognizing reality, since that mechanism is not something we are going to be defining, as far as I know. It can be argued that it is saying that these requirements allow such a range of mechanism. But I agree that 2119 usage is a bit of a stretch there. > > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs > From nobody Wed Aug 17 15:09:02 2016 Return-Path: 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 695EF12D7F5; Wed, 17 Aug 2016 15:08:59 -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 j4SY5cBegn7J; Wed, 17 Aug 2016 15:08:57 -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 C2BAB12D7EC; Wed, 17 Aug 2016 15:08:50 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id B29221C0038; Wed, 17 Aug 2016 15:08:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=1.tigertech; t=1471471730; bh=p3pnxMNVX/Hl6RWAzl1TOXJHfLyK/viw2bzkqxPNMi0=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=Mq5l0BI9DCZS4VYsQMjpYUWzEBFf3X7+X5UxuXur1dlgrPL0pGHA+bnSrrVZSiF7g /SFK7ncCPkfHKyad6ZAnh0ZPLNUj7XADLYF7N+kuktxVUje62t5xKKb1DKWnEbLs+u t7gcXKPsX7Vf9LRwauBa5kzwevZYfmS0yiX0Y9HI= 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 EA12D1C028D; Wed, 17 Aug 2016 15:08:49 -0700 (PDT) To: Kathleen Moriarty , The IESG References: <147146974235.23784.4389421535496134619.idtracker@ietfa.amsl.com> From: "Joel M. Halpern" Message-ID: Date: Wed, 17 Aug 2016 18:10:37 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <147146974235.23784.4389421535496134619.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: jhaas@pfrc.org, i2rs@ietf.org, i2rs-chairs@ietf.org, 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Aug 2016 22:08:59 -0000 In line, I hope answering the questions. Yours, Joel On 8/17/16 5:35 PM, Kathleen Moriarty wrote: > Kathleen Moriarty has entered the following ballot position for > draft-ietf-i2rs-protocol-security-requirements-07: Discuss > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-i2rs-protocol-security-requirements/ > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > Thanks for your work on this draft. There may be some overlap in points, > I tried to minimize them... > ---- > Section 3.1: > > I don't see any actual requirements for mutual authentication in this > section, just requirements for identifiers. Did I miss something? The second bullet in section 3.1 (Mutual Authentication) is about mutually authenticating. The verbiage was chosen by the more security-experienced writer, so the co-authors assumed it was sufficient. If you can suggest better words, we are happy to change it. > > Are all mutual auth schemes in scope? Are there any considerations for > mutual authentication (passwords, keys, etc.)? I2RS does not have any constraints that we know of on the mutual authentication scheme used. The I2RS protocol may have some constraints or assumptions, but this document does not place any such. > ---- > I share the same concern as others for secure transport, but since there > are already discusses on that, I have one comment to add to the existing > discusses below. > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Section 3: > Can you clarify the second to last sentence? Do you mean there are > sections that indicate an insecure transport should be used? > > I2RS allows the use of an > insecure transport for portions of data models that clearly indicate > insecure transport. > > Perhaps: > I2RS allows the use of an > insecure transport for portions of data models that clearly indicate > the use of an > insecure transport. The ephemeral state document has wording that has been worked out carefully on how much we are mandating about the specificity of allowing non-secure transport. Since this document points there, how specific do we need to be here? (And do folks think that needs to be considered a normative reference? We can do that if needed.) > ---- > Section 3.2 > I agree with Alissa's discuss point on the following sentence (that could > also be reworded a bit): > A non-secure transport can be 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. > ---- > Section 3.4: In the following text: > SEC-REQ-15: The integrity that the message data is not repeated means > that I2RS client to I2RS agent transport SHOULD protect against > replay attack > > I'm not sure why this just doesn't say: > SEC-REQ-15: I2RS client to I2RS agent transport SHOULD protect > against > replay attack > > The additional text doesn't add anything and sounds a bit confusing. As per Ben's comments, I think this will get cleaned up. As you observe, it is overly verbose at the moment. > ---- > Nit: > > I'm not sure these definitions add any value as they seem to restate the > term defined: > > I2RS protocol data integrity > > The transfer of data via the I2RS protocol has the property of > data integrity described in [RFC4949]. > > I2RS component protocols > > Protocols which are combined to create the I2RS protocol. > ----- > > I also agree that the definitions from 4949 should be removed. > > Thank you in advance. > > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs > From nobody Wed Aug 17 15:53:15 2016 Return-Path: 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 574BC12B016; Wed, 17 Aug 2016 15:53:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.147 X-Spam-Level: X-Spam-Status: No, score=-3.147 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.247] 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 YElhxy4-7_Om; Wed, 17 Aug 2016 15:53:03 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 3AAB312D6AD; Wed, 17 Aug 2016 15:53:03 -0700 (PDT) Received: from [10.0.1.4] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id u7HMr2kS085893 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 17 Aug 2016 17:53:02 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.4] From: "Ben Campbell" To: "Joel M. Halpern" Date: Wed, 17 Aug 2016 17:53:01 -0500 Message-ID: <2A898F69-FE5D-46A3-8260-6285F5B49C1E@nostrum.com> In-Reply-To: <7ed760da-c57c-b2f7-9045-b6c033a6bcf3@joelhalpern.com> References: <147146828725.23668.4809857469458650681.idtracker@ietfa.amsl.com> <7ed760da-c57c-b2f7-9045-b6c033a6bcf3@joelhalpern.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Mailer: MailMate (1.9.4r5234) Archived-At: Cc: jhaas@pfrc.org, i2rs@ietf.org, draft-ietf-i2rs-protocol-security-requirements@ietf.org, The IESG , i2rs-chairs@ietf.org Subject: Re: [i2rs] Ben Campbell'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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Aug 2016 22:53:09 -0000 On 17 Aug 2016, at 17:04, Joel M. Halpern wrote: > Making sure I understand what is being asked in each of these items, > hence in-line. > Yours, > Joel > > On 8/17/16 5:11 PM, Ben Campbell wrote: [...] >> ---------------------------------------------------------------------- >> DISCUSS: >> ---------------------------------------------------------------------- >> >> In section 3.4, the text says that the requirements that the >> integrity >> protection mechanisms can actually provide integrity protection are >> SHOULD because some communication may occur over non-secure channels. >> That does not follow, since the rationale is about use, while the >> actual >> requirement is about capability. As currently written, it leaves it >> possible for people to select a protocol that cannot provide >> integrity >> protection at all. I think the SHOULDs in 14 and 15 need to be MUSTS. > > I think what you are asking is that we rephrase these requirements to > indicate that implementations must include integrity protection > capability which meets these requirements. And that the current text > explaining the SHOULD becomes text about when these mechanisms SHOULD > be used? > Yes. >> >> In the third paragaph of 3.2, Isn't the point to say that ephemeral >> data >> MUST be sent over a secure transport unless the data model explicitly >> labels it as safe for insecure transports? As written, it seems to >> leave >> room to send data that is not labeled as safe to also be sent over >> insecure transports. > > I am having trouble seeing the problem. The text, as far as I can > tell, says "SHOULD be protect", and then goes on to say "except when > the model says it is okay to send unprotected". That seems to say the > right thing. I take "SHOULD except..." to mean something fundamentally different than "MUST except..." SHOULD allows the implementers (or I guess protocol designers in this case) the additional flexibility of deciding they have some other good reason to deviate from the guidance, in addition to whatever might be list. Is that the intent here? > >> >> >> ---------------------------------------------------------------------- >> COMMENT: >> ---------------------------------------------------------------------- >> >> -2.1: I am on the fence about other's comments about copying >> definitions >> here--but if you do copy them here, it seems strange to not mention >> "client" or "agent". > > I can live with just listing the terms and references, without the > text. It makes reading a little more complex for new readers, but > avoids any risk of error in copying. I think that's a good answer to other people's comments :-) My comment was, _if_ this draft continues to mention the defined terms, it would be good to also mention client and agent. > >> >> I agree with Alissa about equating privacy and confidentiality. > > I was going to simply say "sure", but REQ-20 sems to need to still say > "privacy". Not sure what you (individually or collectively) would > like us to do. > I do note that if the terminology has shifted from that documented in > 4949, it would be helpful to those of us who do not live with it daily > to have some way to know such. > It probably makes sense to keep this discussion in the thread from Alissa's comments. >> >> -3.1,: >> I’m confused by the first paragraph. I don’t find strings of the >> form of >> SEC-REQ-XX in 7921. I think _this_ doc sets these requirements, >> right? > > Section 3.1 is trying to recapitulate for context requirements that > are stated in textual form in RFC 7921. No, they are not lsited as > SEQ_REQ-XX or even REQ-XX in RFC 7921. Thus, in addition to context, > listing them here allows us to give them numbers for consistency of > discussion. (Thus, this is a case where repetition adds value.) It think some clarification text would be in order. (I am agnostic about Mirja's and Alissa's comments about whether these should be replicated at all.) > >> >> It’s not clear to me how 5 and 6 differ. Is it just a matter of the >> additional “before establishing a connection†part in 6? > > As far as I know, it is indeed just a matter of the timing being added > in 6. If this is a problem, we can collapse them. I'm okay either way on this one. > >> >> -3.4: Isn't 15 simply a restatement of the third item under 14? > > that looks like an error on our part. Maybe I missed something, but I > think we can drop that when we rewrite to address your major comment. Okay. The odd part is that 15 seems to recognize that it's just a restatement :-) > >> >> 3.5: The MAYs in 19 and 20 seem like statements of fact. (That is, >> do >> they simply recognize reality, or to they grant permission?) > > Re-reading these, the MAY in 19 is a description of allowed > architecture, and seems to me to wall within the 2119 meaning. Is the MAY in 19 a materially new statement, or is that already covered in the architecture? If the latter, something to the effect of "The architecture allows..." might make more sense. > The may in 20 is subtler. I think it is recognizing reality, since > that mechanism is not something we are going to be defining, as far as > I know. It can be argued that it is saying that these requirements > allow such a range of mechanism. But I agree that 2119 usage is a bit > of a stretch there. > >> >> >> _______________________________________________ >> i2rs mailing list >> i2rs@ietf.org >> https://www.ietf.org/mailman/listinfo/i2rs >> From nobody Wed Aug 17 16:57:32 2016 Return-Path: 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 5C49A12D81B for ; Wed, 17 Aug 2016 16:45:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mail-regent-edu.20150623.gappssmtp.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 i_ohplkx5q6q for ; Wed, 17 Aug 2016 16:45:48 -0700 (PDT) Received: from mail-wm0-x244.google.com (mail-wm0-x244.google.com [IPv6:2a00:1450:400c:c09::244]) (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 1E67112D58D for ; Wed, 17 Aug 2016 16:45:45 -0700 (PDT) Received: by mail-wm0-x244.google.com with SMTP id q128so1780810wma.1 for ; Wed, 17 Aug 2016 16:45:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mail-regent-edu.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to:cc; bh=ngWYbaYXQ64L5Pq4Xt9y6DCIJaK8Knm6XMOVPLpwrY4=; b=KEt2HdofaZLDkTFLaNkwBG/p1KDtm+9qrmnFaZKWhCfvv87gnu2zX+IAj3cUqHUpZk V3ngN/qroIrSCrffCaBBSVLWINRt4exYKk0aCRctVe3luTetWSTjTlcANYH0wzOarrqa xz8QTei8LOpZhRUD2wNeyF1EJ5QLeHs9RPiUs+fNufEMKpKrQOHmSc3LO7HkBp/piS7y +HQMGtZ99JxVL8kx6a1+blD8KrSVLfaDmuBhwTvK2jygwIlPKnfB+hP534JKzxzcICNc tSctBxHXb/RIoKNBdhRKyppR0Q0m4PyE++9mZy57gPQLagAC7q8LlLzesm9phJhqtohr 1XXQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=ngWYbaYXQ64L5Pq4Xt9y6DCIJaK8Knm6XMOVPLpwrY4=; b=JMRSZuzlmsKj8FAzN93UNonrr0icFDyXxr5ap+C0WN+vWOw//NrBiOKe57Mq6KK0BT Tb9mT6QaYETiKnCqDUSsbZwYd8lHbnoZEoB/VbUcgzvOSqrPuqXTXB6dDwjlc0yJ3PKW zxy3UzCEEzc3iKXjasWTnu6cHQzfDlQWD36sdY8+c30PYHC7EJAbAIzkbPMETGIUwpxZ lP9xjEY8L+6a+LLIxVq7RhdWoUJZ5jbcMOUsthqR9zLgGRqm/+FJvfW/+wf9vNMcRETp T6Sb513QmfJ7XPmVUnZNZdY07AZ0j/4/WFqSy4q4u/KWevRJrW7q8n6jvilOtOatENc9 Koug== X-Gm-Message-State: AEkoousE7sl3lnvv+nDTTzkCbatRBIu6PPi1iYCmnTZRMBA4IemSXCIi/kI9M3A7TIlO9ByGXGIUyOwpV1aKkpA5 X-Received: by 10.28.18.11 with SMTP id 11mr28471692wms.11.1471477543414; Wed, 17 Aug 2016 16:45:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.194.66.102 with HTTP; Wed, 17 Aug 2016 16:45:42 -0700 (PDT) From: Susan Hares Date: Wed, 17 Aug 2016 19:45:42 -0400 Message-ID: To: Alia Atlas , Alissa Cooper Content-Type: multipart/alternative; boundary=001a11469722454591053a4d108e Archived-At: X-Mailman-Approved-At: Wed, 17 Aug 2016 16:57:31 -0700 Cc: i2rs@ietf.org, i2rs-chairs@ietf.org, iesg@ietf.org, jhass@pfrc.org, Susan Hares , draft-ietf-i2rs-protocol-security-requirements@ietf.org Subject: Re: [i2rs] Alissa Cooper's Discuss on draft-ietf-i2rs-protocol-security-requirements-06: (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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Aug 2016 23:45:50 -0000 --001a11469722454591053a4d108e Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Alissa: In storms in the mid-west have knock out power and connectivity to my mailer. It is up/down - so I am sending the response to you via my secondary mail address at my school. Please acknowledge when you receive this email, and send On the DISCUSS: Operators indicated that there are events which they will want to send publically. One example of such an event is the route establishment/loss (such as the routes available to http://www.routeviews.org/ or looking glass sites). This data is specific route information that is publically known. Right now this information requires a BGP connection, or data from a BGP connection. In the future, it would simply require an I2RS client to have a connection to an I2RS agent. Insecure I2RS Client=3D=3D=3D=3D=3D=3D=3DI2RS Agent This data can also be distributed in tiers =E2=80=93 where a massive amount= of clients connect to an I2RS agent which draws its information in a proxy mode: Insecure Proxy-model secure I2RS client-1=3D=3D=3D=3D=3D=3D=3D=3D=3D I2RS Agent /I2RS client --------= --------------- I2RS Agent I2RS client-2=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D| Alissa - does this provide you enough information to resolve your discuss? =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D On your comments: *section 2.1:* The addition of privacy was suggested by our QA sec-dir reviewer who made the point that privacy was not always equivalent to confidentiality. The suggestion was to clearly specify our use of privacy. If you, Kathleen, and Stephen have a suggestion for alternate language or to drop the privacy language. RFC6793 - BGP Support for Four-Octet Autonomous System (AS) Number Space. Therefore, you must mean a different RFC. Please provide this example. *Section 2.2: * =3D=3D Section 2.2 =3D=3D "The I2RS protocol exists as a higher-level protocol which may combine other protocols (NETCONF, RESTCONF, IPFIX and others) within a specific I2RS client-agent relationship with a specific trust for ephemeral configurations, event, tracing, actions, and data flow interactions." Reading the provided definition of "trust," I'm not sure what "with a specific trust for" means in the sentence above. *Sue: *The ephemeral state requires that the I2RS Client-Agent operate with default level of security (default secure transport) that IPFIX does not require. The I2RS client-I2RS Agent must provide mutual authentication. We summarized this as "specific trust". Do you have an alternate text? 2) definition of secondary identity "The I2RS architecture document [I-D.ietf-i2rs-architecture] defines a secondary identity as the entity of some non-I2RS entity (e.g. application) which has requested a particular I2RS client perform an operation." Per my comment above, I would suggest just referencing the definition from the architecture document. The text above is circular ("the entity of some ... entity") and conflates an identity with an identifier. Sue: We had comments from NETCONF that suggested adding this definition to make the requirements more user friendly. If this is a blocking comment, we will remove it. Otherwise the text will be changed to: "The I2RS architecture document [RFC7921]. Please note that the secondary identity specifies a non-I2RS entity (e.g. application) that has requested a particular I2RS client perform an operation." I look forward to your feedback on this new text. =3D=3D Section 3.1 =3D=3D Agree with Mirja that this section is superfluous. Sue: While this is rational idea, it was not superfluous during the discussion with NETCONF. Without this section, I2RS and NETCONF ran into miscommunication. Therefore, since this section clarified things for the creation of the I2RS protocol as additions to NETCONF/RESTCONF - unless this becomes a blocking comment - it will stay. =3D=3D Section 3.3 =3D=3D 3.3 . Data Confidentiality Requirements SEC-REQ-13: In a critical infrastructure, certain data within routing elements is sensitive and read/write operations on such data SHOULD be controlled in order to protect its confidentiality. Sue: If you do not use SHOULD, the document contradicts itself regarding insecure transport protocol. If you suggestions that handle both, please suggest text. 3.5 Is the omission of normative language from Sec-REQ-20 purposeful? Sec-REQ-20: If an I2RS agents or an I2RS client is tightly correlated with a person, then the I2RS protocol and data models should provide additional security that protects the person's privacy. SHOULD is normative whether caps or lower case. Did you want this to go a SHOULD? I've capitalized it in version-08. If you want it to go to a MUST, please just let me know why. Thank you for your comments, Sue --001a11469722454591053a4d108e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Alissa:=C2=A0

In storms in the mid-west= have knock out power and connectivity to my mailer.=C2=A0 It is up/down - = so I am sending the response to you via my secondary mail address at my sch= ool. =C2=A0 Please acknowledge when you receive this email, and=C2=A0
=
send=C2=A0

=C2=A0=C2=A0

On the DISCUSS:

=C2=A0

Operators indicated that there are events wh= ich they will want to send publically.=C2=A0=C2=A0 One example of such an event is the route establishment/loss (such as the routes available to http://www.routeviews.org/ or lookin= g glass sites).=C2=A0=C2=A0 This data is specific route information that is publically known.=C2=A0=C2=A0

=C2=A0

Right now this information requires a BGP co= nnection, or data from a BGP connection.=C2=A0=C2=A0 In the future, it would simply require an I2RS client to have a connection to an I2RS agent.=C2=A0 =

=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 Insecure

=C2=A0 I2RS Client=3D=3D=3D=3D=3D=3D=3DI2RS = Agent

=C2=A0

This data can also be distributed in tiers = =E2=80=93 where a massive amount of clients connect to an I2RS agent which draws its information in a proxy mod= e:

=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Insecure=C2=A0= =C2=A0=C2=A0 Proxy-model=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 secure

=C2=A0I2RS client-1=3D=3D=3D=3D=3D=3D=3D=3D= =3D=C2=A0 I2RS Agent /I2RS client ----------------------- I2RS Agent

I2RS client-2=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D|

=C2=A0

=C2=A0

Alissa - does this provide you enough inform= ation to resolve your discuss?

=C2= =A0

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

= On your comments:=C2=A0


section 2.1:=C2=A0


T= he addition of privacy was suggested by our QA sec-dir reviewer who made th= e point that privacy was not always equivalent to confidentiality.=C2=A0 Th= e suggestion was to clearly specify our use of privacy. =C2=A0=C2=A0=


If you, Kathleen, and Stephen have a suggestion for alternate languag= e or to drop the privacy language.=C2=A0

<= span style=3D"font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73= ,125)">

RFC6793 -=C2=A0= BGP Support for Four-Octet Au= tonomous System (AS) Number Space. =C2=A0Therefore, you must mean a different RFC. =C2=A0 Please provide this e= xample.=C2=A0


<= br>

Sec= tion 2.2:=C2=A0

=3D=3D Section 2.2 = =3D=3D

"The I2RS protocol exists as a higher-level protocol which may
=C2=A0 =C2=A0 =C2=A0 combine other protocols (NETCONF, RESTCONF, IPFIX and others)
=C2=A0 =C2=A0 =C2=A0 within a specific I2RS client-agent relationship with = a specific
=C2=A0 =C2=A0 =C2=A0 trust for ephemeral configurations, event, tracing, actions, and
=C2=A0 =C2=A0 =C2=A0 data flow interactions."

Reading the provided definition of "trust," I'm not sure what "with a
specific trust for" means in the sentence above.


Sue:= =C2=A0The ephemeral state requires that the I2RS Client-Agent=C2=A0

operate with= default level of security (default secure transport) that IPFIX does not r= equire.=C2=A0 The I2RS client-I2RS Agent must provide mutual authentication= .=C2=A0

We summ= arized this as "specific trust".=C2=A0 Do you have an alternate t= ext?=C2=A0


=

2) =C2=A0definition of secondary identity=C2= =A0


"The I2= RS architecture document =C2=A0[I-D.ietf-i2rs-architecture]=C2=A0
=C2=A0 =C2=A0 =C2=A0 defines a secondary identity as the entity of some non-I2RS entity
=C2=A0 =C2=A0 =C2=A0 (e.g. application) which has requested a particular I2= RS client
=C2=A0 =C2=A0 =C2=A0 perform an operation."

Per my comment above, I would suggest just referencing the definition
from the architecture document. The text above is circular ("the entit= y
of some ... entity") and conflates an identity with an identifier.

=C2=A0

=

Sue: We had comments from NETCONF that suggested= adding this definition to make the requirements more user friendly. =C2=A0=


If this is a b= locking comment, we will remove it.=C2=A0 Otherwise the text will be change= d to:=C2=A0


=C2=A0 =C2=A0"The I2RS archi= tecture document =C2=A0[RFC7921].=C2=A0 Please note that=C2=A0

=C2=A0 =C2=A0 =C2=A0the secondary identity = specifies a non-I2RS entity (e.g. application)=C2=A0

=C2=A0 =C2=A0 =C2=A0that=C2=A0has requested a particular I2RS = client=C2=A0perform an operation."


I look forward to your feedback on this new text.=C2=A0


=3D=3D Section 3.1=
 =3D=3D

Agree with Mirja that this section is superfluous.

Sue: =C2=A0While this i= s rational idea, it was not superfluous during the discussion with NETCONF.= =C2=A0 Without this section, I2RS and NETCONF ran into miscommunication. = =C2=A0 Therefore, since this section clarified things=C2=A0

for the creation of the I2RS protocol as addition= s to NETCONF/RESTCONF -=C2=A0

unl= ess this becomes a blocking comment - it will stay.=C2=A0


=3D=3D Section 3.3 =3D=3D



3.3.  Data =
Confidentiality Requirements


   SEC-REQ-13: In a critical infrastructure, certain data within routing
   elements is sensitive and read/write operations on such data SHOULD
   be controlled in order to protect its confidentiality.



Sue: If you do not use SHOULD, = =C2=A0the document contradicts itself=C2=A0

regarding insecure transport protocol. =C2=A0 =C2= =A0If you =C2=A0suggestions that handle both,=C2=A0

please suggest text.=C2=A0

=


3.5=C2=A0


Is the omission of normative language from Sec=
-REQ-20 purposeful?



   Sec-REQ-20: If an I2RS agen=
ts or an I2RS client is tightly correlated
   with a person, then the I2RS protocol and data models should provide
   additional security that protects the person's privacy.


SHO= ULD is normative whether caps or lower case.=C2=A0 Did you want this to=C2= =A0

go a SHOULD? I've capitali= zed it in version-08.=C2=A0 If you want it to go to a

MUST, please just let me know why.=C2=A0


Thank you = for your comments,


Sue=C2=A0

--001a11469722454591053a4d108e-- From nobody Wed Aug 17 16:59:14 2016 Return-Path: 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 CB98712D82E; Wed, 17 Aug 2016 16:59:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.738 X-Spam-Level: * X-Spam-Status: No, score=1.738 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, RDNS_NONE=0.793] autolearn=no 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 HUpWWzqL--lY; Wed, 17 Aug 2016 16:59:11 -0700 (PDT) Received: from hickoryhill-consulting.com (unknown [50.245.122.97]) (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 63B6D12D82C; Wed, 17 Aug 2016 16:59:10 -0700 (PDT) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=174.124.169.225; From: "Susan Hares" To: , References: <147144567895.12152.15403435188950086025.idtracker@ietfa.amsl.com> <5B604C19-7AEF-4C92-B452-A034749A5FCA@cooperw.in> In-Reply-To: Date: Wed, 17 Aug 2016 19:58:06 -0400 Message-ID: <008e01d1f8e3$33483590$99d8a0b0$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQG3q3aG/0u2B1HfPippUnE2NxzEQwGi2QgoAk3GCFUB6JhdAKBTpYIw Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: i2rs@ietf.org, i2rs-chairs@ietf.org, akatlas@gmail.com, iesg@ietf.org, jhaas@pfrc.org, draft-ietf-i2rs-protocol-security-requirements@ietf.org Subject: Re: [i2rs] Alissa Cooper's Discuss on draft-ietf-i2rs-protocol-security-requirements-06: (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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Aug 2016 23:59:13 -0000 Stephen:=20 We have discussed these requirements with the NETCONF/RESTCONF group as = part of the process. This WG group did not raise any issues of about = the requirements not being realistic.=20 Sue Hares=20 -----Original Message----- From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of = stephen.farrell@cs.tcd.ie Sent: Wednesday, August 17, 2016 2:24 PM To: alissa@cooperw.in Cc: i2rs@ietf.org; i2rs-chairs@ietf.org; akatlas@gmail.com; = iesg@ietf.org; jhaas@pfrc.org; = draft-ietf-i2rs-protocol-security-requirements@ietf.org Subject: Re: [i2rs] Alissa Cooper's Discuss on = draft-ietf-i2rs-protocol-security-requirements-06: (with DISCUSS and = COMMENT) Hiya,=20 I'm on vacation so won't be balloting this week and I only had a quick = flick of this, but if I'd had time for a proper read I think I'd be = asking how realistic are these requirements, possibly as a discuss = ballot. If someone wanted to hit defer and blame me (sorry I don't have = the right devices with me to do that) that'd be good. But if this draft = is time-critical for the WG then please ignore the above.=20 S.=20 On Wed Aug 17 19:02:09 2016 GMT+0200, Alissa Cooper wrote: > Hi Alia, >=20 > > On Aug 17, 2016, at 11:07 AM, Alia Atlas wrote: > >=20 > > Hi Alissa, > >=20 > > On Wed, Aug 17, 2016 at 10:54 AM, Alissa Cooper > wrote: > > Alissa Cooper has entered the following ballot position for > > draft-ietf-i2rs-protocol-security-requirements-06: Discuss > >=20 > > When responding, please keep the subject line intact and reply to=20 > > all email addresses included in the To and CC lines. (Feel free to=20 > > cut this introductory paragraph, however.) > >=20 > >=20 > > Please refer to=20 > > https://www.ietf.org/iesg/statement/discuss-criteria.html=20 > > > > for more information about IESG DISCUSS and COMMENT positions. > >=20 > >=20 > > The document, along with other ballot positions, can be found here: > > https://datatracker.ietf.org/doc/draft-ietf-i2rs-protocol-security-r > > equirements/=20 > > > requirements/> > >=20 > >=20 > >=20 > > -------------------------------------------------------------------- > > -- > > DISCUSS: > > -------------------------------------------------------------------- > > -- > >=20 > > =3D=3D Section 3.2 =3D=3D > >=20 > > "A non-secure transport can be 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." > >=20 > > What kind of telemetry data is it that is of no potential interest=20 > > to any eavesdropper? This is not my area of expertise so I'm having=20 > > a hard time conceiving of what that could be. I'm also wondering,=20 > > since I2RS agents and clients will have to support secure transports = > > anyway (and RESTCONF can only be used over a secure transport), why=20 > > can't they be used for all transfers, instead of allowing this=20 > > loophole in the name of telemetry, which undoubtedly will end up=20 > > being used or exploited for other data transfers? > >=20 > > If the argument was that this loophole is needed for backwards=20 > > compatibility with insecure deployments of NETCONF or something like = > > that I think it would make more sense, but my impression from the=20 > > text is that those will have to be updated anyway to conform to the=20 > > requirements in this document. > >=20 > > Data coming from a router can come from many different line-cards = and processors. > > The line-cards that may be providing the data are not going to be=20 > > supporting the secure transports anyway. >=20 > Will they also not be supporting the I2RS protocol then, given the = requirement for support of a secure transport? >=20 >=20 > > A goal is to allow easy distribution of streaming data and event=20 > > notifications. As for what type of data, as far as I know,=20 > > currently IPFIX streams telemetry data without integrity much less = authorization protection. >=20 > What I=E2=80=99m questioning is the choice to extend that model to = cases where a third-party controller or application is one endpoint of = the data exchange, which is what I thought was part of the motivation = for I2RS (happy to be corrected though). >=20 > >=20 > > There are existing deployments that use gRPC now for streaming = telemetry data. >=20 > Ok. So is the implication that the requirements here are needed for = backwards compatability with those deployments? >=20 > Thanks, > Alissa >=20 > >=20 > > Regards, > > Alia > > =20 > > -------------------------------------------------------------------- > > -- > > COMMENT: > > -------------------------------------------------------------------- > > -- > >=20 > > In general I agree with Mirja that where other documents already=20 > > provide definitions, they should be referenced, not copied or=20 > > summarized, in this document. > >=20 > > =3D=3D Section 2.1 =3D=3D > >=20 > > Using "privacy" as a synonym for "confidentiality" is outmoded, I=20 > > think, given current understanding of the many other facets of=20 > > privacy (see, e.g., RFC 6793). I would suggest dropping the=20 > > definition of data privacy and just using the word confidentiality = when that is what you mean. > >=20 > > =3D=3D Section 2.2 =3D=3D > >=20 > > "The I2RS protocol exists as a higher-level protocol which may > > combine other protocols (NETCONF, RESTCONF, IPFIX and others) > > within a specific I2RS client-agent relationship with a = specific > > trust for ephemeral configurations, event, tracing, actions, = and > > data flow interactions." > >=20 > > Reading the provided definition of "trust," I'm not sure what "with=20 > > a specific trust for" means in the sentence above. > >=20 > > "The I2RS architecture document [I-D.ietf-i2rs-architecture] > > defines a secondary identity as the entity of some non-I2RS = entity > > (e.g. application) which has requested a particular I2RS = client > > perform an operation." > >=20 > > Per my comment above, I would suggest just referencing the=20 > > definition from the architecture document. The text above is=20 > > circular ("the entity of some ... entity") and conflates an identity = with an identifier. > >=20 > > =3D=3D Section 3.1 =3D=3D > >=20 > > Agree with Mirja that this section is superfluous. > >=20 > > =3D=3D Section 3.3 =3D=3D > >=20 > > Since the normative recommendation here isn't to be enforced by the=20 > > protocol, why is it SHOULD rather than MUST? Same question applies=20 > > to SEC-REQ-17. > >=20 > > =3D=3D Section 3.5 =3D=3D > >=20 > > Is the omission of normative language from Sec-REQ-20 purposeful? >=20 > _______________________________________________ i2rs mailing list i2rs@ietf.org https://www.ietf.org/mailman/listinfo/i2rs From nobody Wed Aug 17 17:17:20 2016 Return-Path: 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 AAF0B12B03F; Wed, 17 Aug 2016 17:17:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.738 X-Spam-Level: * X-Spam-Status: No, score=1.738 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, RDNS_NONE=0.793] autolearn=no 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 LXuLTuqA0fb8; Wed, 17 Aug 2016 17:17:10 -0700 (PDT) Received: from hickoryhill-consulting.com (unknown [50.245.122.97]) (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 0D05712B007; Wed, 17 Aug 2016 17:17:09 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=174.124.169.225; From: "Susan Hares" To: "'Mirja Kuehlewind'" , "'The IESG'" References: <147142304704.12189.4149817417200297360.idtracker@ietfa.amsl.com> In-Reply-To: <147142304704.12189.4149817417200297360.idtracker@ietfa.amsl.com> Date: Wed, 17 Aug 2016 20:15:58 -0400 Message-ID: <00c001d1f8e5$b5d94790$218bd6b0$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQI+ckvMtsLj2hKLR4cahhlPTc8O8Z904frw Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: jhaas@pfrc.org, i2rs@ietf.org, i2rs-chairs@ietf.org, draft-ietf-i2rs-protocol-security-requirements@ietf.org Subject: Re: [i2rs] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft-i?= =?utf-8?q?etf-i2rs-protocol-security-requirements-06=3A_=28with_COMMENT?= =?utf-8?q?=29?= X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Aug 2016 00:17:12 -0000 Mirja:=20 Thank you for the review. Please see the comments below. Your = comments are sensible, but the sections were put in place to provide = background for the multiple working groups utilizing these requirements. = Please let me know if I can answer additional questions.=20 Sue Hares=20 -----Original Message----- From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Mirja Kuehlewind Sent: Wednesday, August 17, 2016 4:37 AM To: The IESG Cc: jhaas@pfrc.org; i2rs@ietf.org; i2rs-chairs@ietf.org; = draft-ietf-i2rs-protocol-security-requirements@ietf.org Subject: [i2rs] Mirja K=C3=BChlewind's No Objection on = draft-ietf-i2rs-protocol-security-requirements-06: (with COMMENT) Mirja K=C3=BChlewind has entered the following ballot position for draft-ietf-i2rs-protocol-security-requirements-06: No Objection When responding, please keep the subject line intact and reply to all = email addresses included in the To and CC lines. (Feel free to cut this = introductory paragraph, however.) Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-i2rs-protocol-security-requir= ements/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- A few comments: 1) I don't think copy&paste from RFC4949 is necessary. I would recommend = to remove this part and just name the definitions that are needed. Sue: Initially, the WG and the authors ran into problems with security = words. We included definitions that seem to resolve issues for the WG = and those who will need to implemented in NETCONF/RESTCONF. =20 2) The following sentence seems to indicate that the refernce to RFC4949 = should be normative. "The transfer of data via the I2RS protocol has the property of data = integrity described in [RFC4949]." As I don't think this is needed, I would recommend to rather spell out = the properties here in this sentence. Also, to be honstest I not sure = what this sentence tells me at all. So maybe stating clearing what you = mean (instead of just having the reference) would help anyway. Sue: I have moved RFC4949 to normative. RFC4949 states data integrity = means: a) data has not been changed, destroyed or lost in an = unauthorized (or accidental) manner, and b) the information has not = been modified or destroyed in an unauthorized manner. This statement = covers man-in-the middle attacks or unauthorized changes. =20 =20 3) To me it's not really clear why there are several requirments docs = (that also are connected and refer each other; see e.g. section 3.6 and = SEC-REQ-16). The actually context of this doc is only 4 pages (3.1-3.6). = Couldn't those docs be combined to one requirements doc? Sue: This is a good process question for a re-use protocol. A re-use = protocol has a different process than a protocol created out of a single = WG.=20 I2RS broke the requirements into pieces so that as we got agreement on = one piece, the NETCONF/RESTCONF team could begin to work on that piece. = For example, the pub/sub requirements (RFC7923) is already being worked = on in NETCONF. The I2RS ephemeral state requirements have been delayed = by the NETMOD/NETCONF discussions on opstate. If the IESG wishes, after = we have completed this work, we can compile these requirements into a = single document. This process focuses on running code and rough = consensus rather than a single review process for the IESG.=20 4) Section 3.1 says: "The I2RS architecture [I-D.ietf-i2rs-architecture] sets the following = requirements:" Why is this needed is RFC7921 already sets these requirements? Sue: What a logical and rational statement, but unfortunately this = assumption ran into problems in the working groups (NETMOD/NETCONF) who = reviewed the requirements. Therefore, this section is there to provide = explicit definitions that resolved inter-group (I2RS to NETCONF and I2RS = to NETMOD) questions on lists.=20 _______________________________________________ i2rs mailing list i2rs@ietf.org https://www.ietf.org/mailman/listinfo/i2rs From nobody Wed Aug 17 17:52:59 2016 Return-Path: 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 7A595128E19; Wed, 17 Aug 2016 17:52:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.738 X-Spam-Level: * X-Spam-Status: No, score=1.738 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, RDNS_NONE=0.793] autolearn=no 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 e1-e6kET6BIw; Wed, 17 Aug 2016 17:52:49 -0700 (PDT) Received: from hickoryhill-consulting.com (unknown [50.245.122.97]) (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 05F4212D529; Wed, 17 Aug 2016 17:52:48 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=174.124.169.225; From: "Susan Hares" To: "'Ben Campbell'" , "'Joel M. Halpern'" References: <147146828725.23668.4809857469458650681.idtracker@ietfa.amsl.com> <7ed760da-c57c-b2f7-9045-b6c033a6bcf3@joelhalpern.com> <2A898F69-FE5D-46A3-8260-6285F5B49C1E@nostrum.com> In-Reply-To: <2A898F69-FE5D-46A3-8260-6285F5B49C1E@nostrum.com> Date: Wed, 17 Aug 2016 20:51:41 -0400 Message-ID: <011e01d1f8ea$b1086c50$131944f0$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHqGqmshF2PWKHuom2ofn6vvvnQEwHjQMleAa29JnmgAQ/SIA== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: jhaas@pfrc.org, i2rs@ietf.org, draft-ietf-i2rs-protocol-security-requirements@ietf.org, 'The IESG' , i2rs-chairs@ietf.org Subject: Re: [i2rs] Ben Campbell'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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Aug 2016 00:52:51 -0000 Ben:=20 Does the following text work for section 3.4=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D SEC-REQ-14: An integrity protection mechanism for I2RS MUST be provided that will be able to ensure the following:=20 1) the data being protected is not modified without detection during=20 its transportation, =20 2) the data is actually from where it is expected to come from, and=20 3) the data is not repeated from some earlier interaction of the = protocol. (That is, when both confidentiality and integrity of data is properly = protected, it=20 is possible to ensure that encrypted data is not modified or replayed without detection.) SEC-REQ-15: The I2RS protocol MUST provide a mechanism for data = integrity=20 that insure the message data is not repeated, and that the secure = transport between =20 I2RS client to I2RS agent MUST be able to protect against replay attack Requirements SEC-REQ-14 and SEC-REQ-15 are requirements for the secure=20 channel which must be supported as the default by every I2RS Agent, and=20 by every I2RS client communicating over a secure transport. =20 In order to provide some traceability or notification for the non-secure = protocol, SEC-REQ-16 suggests traceability and notification are important to = include for any non-secure protocol. SEC-REQ-16: The I2RS protocol MUST provide a mechanism for=20 message traceability and notification requirements=20 requirements found in and that can be supported=20 in communication channel that is non-secure to trace or notify about = potential security issues. -------------- If so, I will place this in version-08.txt.=20 I've merged SEC-REQ-05 and SEC-REQ-06 in version -08.txt=20 Sue=20 -----Original Message----- From: Ben Campbell [mailto:ben@nostrum.com]=20 Sent: Wednesday, August 17, 2016 6:53 PM To: Joel M. Halpern Cc: The IESG; jhaas@pfrc.org; i2rs@ietf.org; i2rs-chairs@ietf.org; = draft-ietf-i2rs-protocol-security-requirements@ietf.org Subject: Re: [i2rs] Ben Campbell's Discuss on = draft-ietf-i2rs-protocol-security-requirements-07: (with DISCUSS and = COMMENT) On 17 Aug 2016, at 17:04, Joel M. Halpern wrote: > Making sure I understand what is being asked in each of these items,=20 > hence in-line. > Yours, > Joel > > On 8/17/16 5:11 PM, Ben Campbell wrote: [...] >> --------------------------------------------------------------------- >> - >> DISCUSS: >> --------------------------------------------------------------------- >> - >> >> In section 3.4, the text says that the requirements that the=20 >> integrity protection mechanisms can actually provide integrity=20 >> protection are SHOULD because some communication may occur over=20 >> non-secure channels. >> That does not follow, since the rationale is about use, while the=20 >> actual requirement is about capability. As currently written, it=20 >> leaves it possible for people to select a protocol that cannot=20 >> provide integrity protection at all. I think the SHOULDs in 14 and 15 = >> need to be MUSTS. > > I think what you are asking is that we rephrase these requirements to=20 > indicate that implementations must include integrity protection=20 > capability which meets these requirements. And that the current text=20 > explaining the SHOULD becomes text about when these mechanisms SHOULD=20 > be used? > Yes. >> >> In the third paragaph of 3.2, Isn't the point to say that ephemeral=20 >> data MUST be sent over a secure transport unless the data model=20 >> explicitly labels it as safe for insecure transports? As written, it=20 >> seems to leave room to send data that is not labeled as safe to also=20 >> be sent over insecure transports. > > I am having trouble seeing the problem. The text, as far as I can=20 > tell, says "SHOULD be protect", and then goes on to say "except when=20 > the model says it is okay to send unprotected". That seems to say the = > right thing. I take "SHOULD except..." to mean something fundamentally different than = "MUST except..." SHOULD allows the implementers (or I guess protocol = designers in this case) the additional flexibility of deciding they have = some other good reason to deviate from the guidance, in addition to = whatever might be list. Is that the intent here? > >> >> >> --------------------------------------------------------------------- >> - >> COMMENT: >> --------------------------------------------------------------------- >> - >> >>> -2.1: I am on the fence about other's comments about copying=20 >>> definitions here--but if you do copy them here, it seems strange to=20 >>> not mention "client" or "agent". >> >> [Joel] I can live with just listing the terms and references, without = the=20 >> text. It makes reading a little more complex for new readers, but=20 >> avoids any risk of error in copying. >>I think that's a good answer to other people's comments :-) My comment = was, _if_ this draft continues to mention the defined terms, it would be = good to also mention client and >agent. Sue: Clarifying question - are you suggestion this removal of the = security definitions (section 2.1) or for section 2.2 as well? =20 I am concern that it makes the reading of the requirements harder for = the netconf/restconf people. Since this is a re-use protocol, this = requirements specification will go right into the validation of the = NETCONF/RESTCONF as having the appropriate protocols. There will be = new readers in these WG that do not have the security background - so = reducing complexity is useful here. =20 >>> I agree with Alissa about equating privacy and confidentiality. > > I was going to simply say "sure", but REQ-20 sems to need to still say = > "privacy". Not sure what you (individually or collectively) would=20 > like us to do. I do note that if the terminology has shifted from that = documented in=20 > 4949, it would be helpful to those of us who do not live with it daily = > to have some way to know such. REQ-20 states privacy that relates to pervasive privacy RFCs? What do = you want us to do here?=20 A suggestion would be useful. We will be utilizing this in the = NETCONF/NETMOD/I2RS discussions - so helpful comments.=20 It probably makes sense to keep this discussion in the thread from=20 Alissa's comments. >>> >>> -3.1,: >>> I=E2=80=99m confused by the first paragraph. I don=E2=80=99t find = strings of the=20 >>> form of >>> SEC-REQ-XX in 7921. I think _this_ doc sets these requirements,=20 >>> right? >> >> Section 3.1 is trying to recapitulate for context requirements that=20 >> are stated in textual form in RFC 7921. No, they are not lsited as=20 >> SEQ_REQ-XX or even REQ-XX in RFC 7921. Thus, in addition to context, = >> listing them here allows us to give them numbers for consistency of=20 >> discussion. (Thus, this is a case where repetition adds value.) >It think some clarification text would be in order. (I am agnostic = about=20 >Mirja's and Alissa's comments about whether these should be replicated=20 >at all.) Sue: This is a practical matter. Without these explicit comments, the = design discussion between I2RS/NETCONF/NETMOD were running into = problems. We are numbering these expansions and giving them specific = requirements so that the protocol which fulfills these requirements = (e.g. NETCONF, RESTCONF, IPFIX) can be judged on these specific = requirements.=20 > >> >> It=E2=80=99s not clear to me how 5 and 6 differ. Is it just a matter = of the >> additional =E2=80=9Cbefore establishing a connection=E2=80=9D part in = 6? > > As far as I know, it is indeed just a matter of the timing being added = > in 6. If this is a problem, we can collapse them. >I'm okay either way on this one. I have merged these into one requirement. =20 > >>> >>> -3.4: Isn't 15 simply a restatement of the third item under 14? >> >> that looks like an error on our part. Maybe I missed something, but = I=20 >> think we can drop that when we rewrite to address your major comment. >>Okay. The odd part is that 15 seems to recognize that it's just a=20 >restatement :-) Addressed in version 8. =20 >>> >>> 3.5: The MAYs in 19 and 20 seem like statements of fact. (That is,=20 >>> do >>> they simply recognize reality, or to they grant permission?) >> >> Re-reading these, the MAY in 19 is a description of allowed=20 >> architecture, and seems to me to wall within the 2119 meaning. >Is the MAY in 19 a materially new statement, or is that already covered = >in the architecture? If the latter, something to the effect of "The=20 >architecture allows..." might make more sense. This was written to provide additional clarification to the = NETCONF/NETMOD group beyond the architecture document.=20 > The may in 20 is subtler. I think it is recognizing reality, since=20 > that mechanism is not something we are going to be defining, as far as = > I know. It can be argued that it is saying that these requirements=20 > allow such a range of mechanism. But I agree that 2119 usage is a bit = > of a stretch there. > Sue: Here we are trying to give the NETCONF/NETMOD folks an example of = what the I2RS WG is thinking.=20 >> >> >> _______________________________________________ >> i2rs mailing list >> i2rs@ietf.org >> https://www.ietf.org/mailman/listinfo/i2rs >> From nobody Wed Aug 17 18:17:59 2016 Return-Path: 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 97F5312D0BC; Wed, 17 Aug 2016 18:17:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.738 X-Spam-Level: * X-Spam-Status: No, score=1.738 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, RDNS_NONE=0.793] autolearn=no 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 c5JUAgf1eNah; Wed, 17 Aug 2016 18:17:51 -0700 (PDT) Received: from hickoryhill-consulting.com (unknown [50.245.122.97]) (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 8A82E12B04B; Wed, 17 Aug 2016 18:17:51 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=174.124.169.225; From: "Susan Hares" To: "'Kathleen Moriarty'" , "'The IESG'" References: <147146974235.23784.4389421535496134619.idtracker@ietfa.amsl.com> In-Reply-To: <147146974235.23784.4389421535496134619.idtracker@ietfa.amsl.com> Date: Wed, 17 Aug 2016 21:16:48 -0400 Message-ID: <013b01d1f8ee$31fa09b0$95ee1d10$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIa7Lz6VgZw6h2A0uGNzOgAA2Ic8Z+7/Lyg Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: jhaas@pfrc.org, i2rs@ietf.org, i2rs-chairs@ietf.org, 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Aug 2016 01:17:53 -0000 Kathleen:=20 Thank you for your comments. Please see the inline comments below. I = will be uploading a version -08.txt that will resolve some of these = comments.=20 Sue=20 -----Original Message----- From: Kathleen Moriarty [mailto:Kathleen.Moriarty.ietf@gmail.com]=20 Sent: Wednesday, August 17, 2016 5:36 PM To: The IESG Cc: draft-ietf-i2rs-protocol-security-requirements@ietf.org; Jeffrey = Haas; i2rs-chairs@ietf.org; jhaas@pfrc.org; i2rs@ietf.org Subject: Kathleen Moriarty's Discuss on = draft-ietf-i2rs-protocol-security-requirements-07: (with DISCUSS and = COMMENT) Kathleen Moriarty has entered the following ballot position for draft-ietf-i2rs-protocol-security-requirements-07: Discuss When responding, please keep the subject line intact and reply to all = email addresses included in the To and CC lines. (Feel free to cut this = introductory paragraph, however.) Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-i2rs-protocol-security-requir= ements/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Thanks for your work on this draft. There may be some overlap in = points, I tried to minimize them... ---- >Section 3.1: > >I don't see any actual requirements for mutual authentication in this = section, just requirements for identifiers. Did I miss something? =20 No, there are no additional requirements. We only have requirements for = identifiers. Do you have a suggestion for improved language.=20 > Are all mutual auth schemes in scope? Are there any considerations = for mutual authentication (passwords, keys, etc.)? All mutual identification schemes are in scope. Is there a reason we = should restrict the mutual authentication schemes to a subset.=20 ---- >I share the same concern as others for secure transport, but since = there are already discusses on that, I have one comment to add to the = existing discusses below. You have a concern regarding the secure transport? My understanding is = that other people had a concern regarding the insecure transport. I = have provide an example of the BGP data feed utilized by = http://www.routeviews.org/ project. =20 ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- > Section 3:=20 > Can you clarify the second to last sentence? Do you mean there are = sections that indicate an insecure transport should be used? > I2RS allows the use of an > insecure transport for portions of data models that clearly indicate > insecure transport. > Perhaps: > I2RS allows the use of an > insecure transport for portions of data models that clearly indicate = the use of an > insecure transport. Changed to : I2RS allows the use of an insecure transport for portions of data models = that clearly indicate the use of an insecure transport. Operators deploying I2RS must = determine if they want to populate and=20 deploy the portions of the data model which use insecure transports. ---- > Section 3.2 > I agree with Alissa's discuss point on the following sentence (that = could also be reworded a bit): > A non-secure transport can be 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. I would appreciate a recommended set of text or additional explanation = on what you would like to see in rewording.=20 ---- >Section 3.4: In the following text: > SEC-REQ-15: The integrity that the message data is not repeated = means > that I2RS client to I2RS agent transport SHOULD protect against > replay attack >I'm not sure why this just doesn't say: > SEC-REQ-15: I2RS client to I2RS agent transport SHOULD protect against > replay attack >The additional text doesn't add anything and sounds a bit confusing. Sue: Is this ok. It will be changed=20 =20 ---- Nit: I'm not sure these definitions add any value as they seem to restate the = term defined: > I2RS protocol data integrity > > The transfer of data via the I2RS protocol has the property of > data integrity described in [RFC4949]. Deleted=20 > I2RS component protocols > > Protocols which are combined to create the I2RS protocol. Please suggest alternative text for this section.=20 ----- > I also agree that the definitions from 4949 should be removed. > Thank you in advance. These definition have been removed. I will provide feedback if this = removal cause problems in the creation of the protocol.=20 From nobody Wed Aug 17 18:53:29 2016 Return-Path: X-Original-To: i2rs@ietf.org Delivered-To: i2rs@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 833B012D18A; Wed, 17 Aug 2016 18:53:27 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "Alvaro Retana" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.29.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147148520752.23682.12743310118152055665.idtracker@ietfa.amsl.com> Date: Wed, 17 Aug 2016 18:53:27 -0700 Archived-At: Cc: Jeffrey Haas , i2rs@ietf.org, i2rs-chairs@ietf.org, draft-ietf-i2rs-protocol-security-requirements@ietf.org Subject: [i2rs] Alvaro Retana's No Objection on draft-ietf-i2rs-protocol-security-requirements-07: (with COMMENT) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Aug 2016 01:53:27 -0000 Alvaro Retana has entered the following ballot position for draft-ietf-i2rs-protocol-security-requirements-07: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-i2rs-protocol-security-requirements/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I have the same concerns as others around the secure transport, but I'm not putting in a DISCUSS because the concerns are already well represented. Just one additional comment on the topic: I think there is a contradiction between SEC-REQ-09 ("The I2RS protocol MUST be able to transfer data over a secure transport and optionally MAY be able to transfer data over a non-secure transport") and this text from Section 3. (Security-Related Requirements): "…MUST be able to exchange data over a secure transport, but some functions may operate on a non-secure transport." The latter text talks bout "some functions" using a non-secure transport, while SEC-REQ-09 implies that everything may use it. Other comments from Section 3.1. (Mutual authentication of an I2RS client and an I2RS Agent) -- The text says that the "I2RS architecture [I-D.ietf-i2rs-architecture] sets the following requirements". I'm not sure what you mean my "sets", as there are no requirements (labeled as such) in the architecture document. If there are, then this section doesn't seem to be needed (as others have mentioned). Maybe "these requirements are derived from the architecture", or something similar may be more appropriate. -- What is a "valid identifier"? A couple of requirements where a "valid identifier" "MUST" be confirmed are listed, but no indication as to what that may be in this document or the architecture one. The definition of identifier doesn't help… -- SEC-REQ-05 and SEC-REQ-06 sound the same to me. What is the difference? BTW, if there is a difference, instead of "IETF" I think that "standardized" may be better. From nobody Wed Aug 17 19:13:12 2016 Return-Path: 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 D522112D587; Wed, 17 Aug 2016 19:13:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.739 X-Spam-Level: * X-Spam-Status: No, score=1.739 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, RDNS_NONE=0.793] autolearn=no 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 LRyVi74PMUgW; Wed, 17 Aug 2016 19:13:00 -0700 (PDT) Received: from hickoryhill-consulting.com (unknown [50.245.122.97]) (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 A6BED12D1BC; Wed, 17 Aug 2016 19:12:59 -0700 (PDT) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=174.124.169.225; From: "Susan Hares" To: "'Alia Atlas'" , "'Alissa Cooper'" Date: Wed, 17 Aug 2016 22:11:52 -0400 Message-ID: <014a01d1f8f5$e5b27990$b1176cb0$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_014B_01D1F8D4.5EA23920" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdH49S7BU0lovAolRGWjp7L/qQslOg== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: 'Jeffrey Haas' , i2rs@ietf.org, draft-ietf-i2rs-protocol-security-requirements@ietf.org, 'The IESG' , i2rs-chairs@ietf.org Subject: Re: [i2rs] Alissa Cooper's Discuss on draft-ietf-i2rs-protocol-security-requirements-06: (with DISCUSS and COMMENT) - resending comment X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Aug 2016 02:13:02 -0000 This is a multipart message in MIME format. ------=_NextPart_000_014B_01D1F8D4.5EA23920 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Alia and Alissa:=20 =20 Resending =E2=80=93 this comment in case it got ost=20 ------------------------ =20 On the DISCUSS:=20 =20 Operators indicated that there are events which they will want to send = publically. One example of such an event is the route = establishment/loss (such as the routes available to = http://www.routeviews.org/ or looking glass sites). This data is = specific route information that is publically known. =20 =20 Right now this information requires a BGP connection, or data from a BGP = connection. In the future, it would simply require an I2RS client to = have a connection to an I2RS agent. =20 =20 Insecure=20 I2RS Client=3D=3D=3D=3D=3D=3D=3DI2RS Agent=20 =20 This data can also be distributed in tiers =E2=80=93 where a massive = amount of clients connect to an I2RS agent which draws its information = in a proxy mode:=20 =20 Insecure Proxy-model = secure=20 I2RS client-1=3D=3D=3D=3D=3D=3D=3D=3D=3D I2RS Agent /I2RS client = ----------------------- I2RS Agent I2RS client-2=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D| =20 =20 Does this provide you enough information to resolve your discuss or do = you have additional questions? =20 Sue =20 =20 =20 On the editorial=20 =20 =20 =20 From: Alia Atlas [mailto:akatlas@gmail.com]=20 Sent: Wednesday, August 17, 2016 11:07 AM To: Alissa Cooper Cc: The IESG; Jeffrey Haas; i2rs@ietf.org; i2rs-chairs@ietf.org; = draft-ietf-i2rs-protocol-security-requirements@ietf.org Subject: Re: Alissa Cooper's Discuss on = draft-ietf-i2rs-protocol-security-requirements-06: (with DISCUSS and = COMMENT) =20 Hi Alissa, =20 On Wed, Aug 17, 2016 at 10:54 AM, Alissa Cooper = wrote: Alissa Cooper has entered the following ballot position for draft-ietf-i2rs-protocol-security-requirements-06: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-i2rs-protocol-security-requir= ements/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- =3D=3D Section 3.2 =3D=3D "A non-secure transport can be 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." What kind of telemetry data is it that is of no potential interest to = any eavesdropper? This is not my area of expertise so I'm having a hard time conceiving of what that could be. I'm also wondering, since I2RS agents and clients will have to support secure transports anyway (and RESTCONF can only be used over a secure transport), why can't they be used for = all transfers, instead of allowing this loophole in the name of telemetry, which undoubtedly will end up being used or exploited for other data transfers? If the argument was that this loophole is needed for backwards compatibility with insecure deployments of NETCONF or something like = that I think it would make more sense, but my impression from the text is = that those will have to be updated anyway to conform to the requirements in this document. =20 Data coming from a router can come from many different line-cards and = processors. The line-cards that may be providing the data are not going to be = supporting the=20 secure transports anyway. A goal is to allow easy distribution of = streaming data and event notifications. As for what type of data, as far as I know, = currently IPFIX=20 streams telemetry data without integrity much less authorization = protection. =20 There are existing deployments that use gRPC now for streaming telemetry = data. =20 Regards, Alia =20 ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- In general I agree with Mirja that where other documents already provide definitions, they should be referenced, not copied or summarized, in = this document. =3D=3D Section 2.1 =3D=3D Using "privacy" as a synonym for "confidentiality" is outmoded, I think, given current understanding of the many other facets of privacy (see, e.g., RFC 6793). I would suggest dropping the definition of data privacy and just using the word confidentiality when that is what you mean. =3D=3D Section 2.2 =3D=3D "The I2RS protocol exists as a higher-level protocol which may combine other protocols (NETCONF, RESTCONF, IPFIX and others) within a specific I2RS client-agent relationship with a specific trust for ephemeral configurations, event, tracing, actions, and data flow interactions." Reading the provided definition of "trust," I'm not sure what "with a specific trust for" means in the sentence above. "The I2RS architecture document [I-D.ietf-i2rs-architecture] defines a secondary identity as the entity of some non-I2RS entity (e.g. application) which has requested a particular I2RS client perform an operation." Per my comment above, I would suggest just referencing the definition from the architecture document. The text above is circular ("the entity of some ... entity") and conflates an identity with an identifier. =3D=3D Section 3.1 =3D=3D Agree with Mirja that this section is superfluous. =3D=3D Section 3.3 =3D=3D Since the normative recommendation here isn't to be enforced by the protocol, why is it SHOULD rather than MUST? Same question applies to SEC-REQ-17. =3D=3D Section 3.5 =3D=3D Is the omission of normative language from Sec-REQ-20 purposeful? =20 ------=_NextPart_000_014B_01D1F8D4.5EA23920 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Alia and Alissa:

 

Resending =E2=80=93 this comment in case it got ost =

------------------------

 

On the DISCUSS:

 

Operators indicated that there are events which they will want to = send publically.=C2=A0=C2=A0 One example of such an event is the route = establishment/loss (such as the routes available to http://www.routeviews.org/ or = looking glass sites).=C2=A0=C2=A0 This data is specific route = information that is publically known.=C2=A0=C2=A0 =

 

Right now this information requires a BGP connection, or data from a = BGP connection.=C2=A0=C2=A0 In the future, it would simply require an = I2RS client to have a connection to an I2RS agent.=C2=A0 =

 

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Insecure =

=C2=A0=C2=A0I2RS Client=3D=3D=3D=3D=3D=3D=3DI2RS Agent =

 

This data can also be distributed in tiers =E2=80=93 where a massive = amount of clients connect to an I2RS agent which draws its information = in a proxy mode:

 

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Insecure=C2=A0=C2=A0=C2=A0 = Proxy-model=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 secure

=C2=A0I2RS client-1=3D=3D=3D=3D=3D=3D=3D=3D=3D=C2=A0 I2RS Agent /I2RS = client ----------------------- I2RS Agent

I2RS = client-2=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D|

 

 

Does this provide you enough information to resolve your discuss or = do you have additional questions?

 

Sue =C2=A0

 

 

On the editorial

 

 

 

From:= = Alia Atlas [mailto:akatlas@gmail.com] =
Sent: Wednesday, August 17, 2016 11:07 AM
To: = Alissa Cooper
Cc: The IESG; Jeffrey Haas; i2rs@ietf.org; i2rs-chairs@ietf.org; d= raft-ietf-i2rs-protocol-security-requirements@ietf.org
Subject:= Re: Alissa Cooper's Discuss on = draft-ietf-i2rs-protocol-security-requirements-06: (with DISCUSS and = COMMENT)

 

Hi = Alissa,

 

On Wed, = Aug 17, 2016 at 10:54 AM, Alissa Cooper <alissa@cooperw.in> wrote:

Alissa Cooper has entered the following ballot = position for
draft-ietf-i2rs-protocol-security-requirements-06: = Discuss

When responding, please keep the subject line intact and = reply to all
email addresses included in the To and CC lines. (Feel = free to cut this
introductory paragraph, however.)


Please = refer to https://www.ietf.org/iesg/statement/discuss-criteria.ht= ml
for more information about IESG DISCUSS and COMMENT = positions.


The document, along with other ballot positions, = can be found here:
https://datatracker.ietf.org/doc/draft-ietf-i2rs-protoc= ol-security-requirements/



----------------------------= ------------------------------------------
DISCUSS:
---------------= -------------------------------------------------------

=3D=3D = Section 3.2 =3D=3D

"A non-secure transport can be 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."

What kind of telemetry data is it that is of no = potential interest to any
eavesdropper? This is not my area of = expertise so I'm having a hard time
conceiving of what that could be. = I'm also wondering, since I2RS agents
and clients will have to = support secure transports anyway (and RESTCONF
can only be used over = a secure transport), why can't they be used for all
transfers, = instead of allowing this loophole in the name of telemetry,
which = undoubtedly will end up being used or exploited for other = data
transfers?

If the argument was that this loophole is = needed for backwards
compatibility with insecure deployments of = NETCONF or something like that
I think it would make more sense, but = my impression from the text is that
those will have to be updated = anyway to conform to the requirements in
this = document.

 

Data coming from a router can come from many different = line-cards and processors.

The line-cards that may be providing the data are not = going to be supporting the 

secure transports anyway.  A goal is to allow = easy distribution of streaming data

and event notifications.  As for what type of = data, as far as I know, currently = IPFIX 

streams = telemetry data without integrity much less authorization = protection.

 

There are existing deployments that use gRPC now for = streaming telemetry data.

 

 Regards,

Alia

 

------------------------------------------= ----------------------------
COMMENT:
-----------------------------= -----------------------------------------

In general I agree with = Mirja that where other documents already provide
definitions, they = should be referenced, not copied or summarized, in = this
document.

=3D=3D Section 2.1 =3D=3D

Using = "privacy" as a synonym for "confidentiality" is = outmoded, I think,
given current understanding of the many other = facets of privacy (see,
e.g., RFC 6793). I would suggest dropping the = definition of data privacy
and just using the word confidentiality = when that is what you mean.

=3D=3D Section 2.2 = =3D=3D

"The I2RS protocol exists as a higher-level protocol = which may
      combine other protocols (NETCONF, = RESTCONF, IPFIX and others)
      within a specific = I2RS client-agent relationship with a specific
      = trust for ephemeral configurations, event, tracing, actions, = and
      data flow interactions."

Reading = the provided definition of "trust," I'm not sure what = "with a
specific trust for" means in the sentence = above.

"The I2RS architecture document = [I-D.ietf-i2rs-architecture]
      defines a secondary = identity as the entity of some non-I2RS entity
      = (e.g. application) which has requested a particular I2RS = client
      perform an operation."

Per my = comment above, I would suggest just referencing the definition
from = the architecture document. The text above is circular ("the = entity
of some ... entity") and conflates an identity with an = identifier.

=3D=3D Section 3.1 =3D=3D

Agree with Mirja = that this section is superfluous.

=3D=3D Section 3.3 = =3D=3D

Since the normative recommendation here isn't to be = enforced by the
protocol, why is it SHOULD rather than MUST? Same = question applies to
SEC-REQ-17.

=3D=3D Section 3.5 = =3D=3D

Is the omission of normative language from Sec-REQ-20 = purposeful?

 

------=_NextPart_000_014B_01D1F8D4.5EA23920-- From nobody Wed Aug 17 19:21:37 2016 Return-Path: X-Original-To: i2rs@ietf.org Delivered-To: i2rs@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 41DC112D62A; Wed, 17 Aug 2016 19:21:32 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.29.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147148689226.23776.12417431741305846455.idtracker@ietfa.amsl.com> Date: Wed, 17 Aug 2016 19:21:32 -0700 Archived-At: Cc: i2rs@ietf.org Subject: [i2rs] I-D Action: draft-ietf-i2rs-protocol-security-requirements-08.txt X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Aug 2016 02:21:32 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Interface to the Routing System of the IETF. Title : I2RS Security Related Requirements Authors : Susan Hares Daniel Migault Joel Halpern Filename : draft-ietf-i2rs-protocol-security-requirements-08.txt Pages : 12 Date : 2016-08-17 Abstract: This presents security-related requirements for the I2RS protocol for mutual authentication, transport protocols, data transfer and transactions. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-i2rs-protocol-security-requirements/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-i2rs-protocol-security-requirements-08 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-i2rs-protocol-security-requirements-08 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Aug 17 19:37:16 2016 Return-Path: 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 2D30512D587; Wed, 17 Aug 2016 19:37:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.738 X-Spam-Level: * X-Spam-Status: No, score=1.738 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, RDNS_NONE=0.793] autolearn=no 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 2ueSV7TDU8Aq; Wed, 17 Aug 2016 19:37:13 -0700 (PDT) Received: from hickoryhill-consulting.com (unknown [50.245.122.97]) (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 43BAD12B041; Wed, 17 Aug 2016 19:37:13 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=174.124.169.225; From: "Susan Hares" To: "'Alvaro Retana'" , "'The IESG'" References: <147148520752.23682.12743310118152055665.idtracker@ietfa.amsl.com> In-Reply-To: <147148520752.23682.12743310118152055665.idtracker@ietfa.amsl.com> Date: Wed, 17 Aug 2016 22:36:11 -0400 Message-ID: <000001d1f8f9$490933a0$db1b9ae0$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJc/Nj7gQdXELJSuw4AgM5RmU8Yz5839V1g Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: 'Jeffrey Haas' , i2rs@ietf.org, i2rs-chairs@ietf.org, draft-ietf-i2rs-protocol-security-requirements@ietf.org Subject: Re: [i2rs] Alvaro Retana's No Objection on draft-ietf-i2rs-protocol-security-requirements-07: (with COMMENT) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Aug 2016 02:37:15 -0000 Alvaro:=20 I just uploaded version -08.txt. Please review it to see if has changed = your feelings on the secure transport. See comments below.=20 -----Original Message----- From: Alvaro Retana [mailto:aretana@cisco.com]=20 Sent: Wednesday, August 17, 2016 9:53 PM To: The IESG Cc: draft-ietf-i2rs-protocol-security-requirements@ietf.org; Jeffrey = Haas; i2rs-chairs@ietf.org; i2rs@ietf.org Subject: Alvaro Retana's No Objection on = draft-ietf-i2rs-protocol-security-requirements-07: (with COMMENT) Alvaro Retana has entered the following ballot position for draft-ietf-i2rs-protocol-security-requirements-07: No Objection When responding, please keep the subject line intact and reply to all = email addresses included in the To and CC lines. (Feel free to cut this = introductory paragraph, however.) Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-i2rs-protocol-security-requir= ements/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- >I have the same concerns as others around the secure transport, but I'm = not putting in a DISCUSS because the concerns are already well = represented. Just one additional comment >on the topic: Please see if I have answered these questions in version -08.txt and in = the email. If not, please let me know.=20 >I think there is a contradiction between SEC-REQ-09 ("The I2RS protocol = MUST be able to transfer data over a secure transport and optionally MAY = be able to transfer data over a >non-secure transport") and this text = from Section 3. (Security-Related Requirements): "=E2=80=A6MUST be able = to exchange data over a secure transport, but some functions may operate = >on a non-secure transport." The latter text talks bout "some = functions" using a non-secure transport, while SEC-REQ-09 implies that = everything may use it. I do not see the contradiction in -08.txt. =20 "The I2RS client and I2RS agent using the I2RS protocol MUST be able to = exchange=20 data over a secure transport, but some functions may operate on a = non-secure transport."=20 This says the I2RS client and I2RS agent must support using the I2RS = protocol over a security transport, but I2RS client software and I2RS = agent software may operate on non-secure transport. =20 Other comments from Section 3.1. (Mutual authentication of an I2RS = client and an I2RS Agent)=20 >-- The text says that the "I2RS architecture = [I-D.ietf-i2rs-architecture] sets the following requirements". I'm not = sure what you mean my "sets", as there are no requirements=20 > labeled as such) in the architecture document. If there are, then = this section doesn't seem to be needed (as others have mentioned). = Maybe "these requirements are derived=20 > from the architecture", or something similar may be more appropriate. You are correct, the I2RS architecture does not label such requirements. = =20 We got into discussing a strawman protocol, and we found we needed to = restate the I2RS architecture documents design in the specific = requirements listed now in version 8 as: SEC-REQ-01 to SEC-REQ-07. In = this case the restatement is useful (see Joel's comment). Do you have a = suggestion for another term than "sets". =20 >-- What is a "valid identifier"? A couple of requirements where a = "valid identifier" "MUST" be confirmed are listed, but no indication as = to what >that may be in this document or the architecture one. The definition = of > identifier doesn't help=E2=80=A6 Actually, the security people indicated that a "valid identifier" was = the appropriate term. You have an identity which is expressed as an = identifier. The identifier can (or cannot be) a valid identifier for the = identity. Identity consists of loss of features. An identifier is the = way to express the identity in a protocol.=20 > SEC-REQ-05 and SEC-REQ-06 sound the same to me. What is the = difference? BTW, if there is a difference, instead of "IETF" I think = that "standardized" may be better. Merged these into one in version -08.txt . Let me know what you think = of the merge.=20 Sue=20 From nobody Wed Aug 17 19:45:10 2016 Return-Path: X-Original-To: i2rs@ietf.org Delivered-To: i2rs@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B8B7512D605; Wed, 17 Aug 2016 19:45:04 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "Ben Campbell" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.29.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147148830474.23714.14742463076688973726.idtracker@ietfa.amsl.com> Date: Wed, 17 Aug 2016 19:45:04 -0700 Archived-At: Cc: jhaas@pfrc.org, i2rs@ietf.org, i2rs-chairs@ietf.org, draft-ietf-i2rs-protocol-security-requirements@ietf.org Subject: [i2rs] Ben Campbell's No Objection on draft-ietf-i2rs-protocol-security-requirements-08: (with COMMENT) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Aug 2016 02:45:05 -0000 Ben Campbell has entered the following ballot position for draft-ietf-i2rs-protocol-security-requirements-08: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-i2rs-protocol-security-requirements/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Version 8 resolved my discuss point for section 3.4. Thanks! I don't think it resolved my discuss point for 3.2. I'm clearing anyway, because I think my point has been made. I would prefer the language to say that anything not explicitly marked as non-confidential in the relevant data model MUST be sent over a protected transport. But I will leave it to the authors to do the right thing. I will leave my non-discuss comments below for reference. I think version 8 resolves at least some of them. Any remaining are up to you; none of them are show stoppers. -2.1: I am on the fence about other's comments about copying definitions here--but if you do copy them here, it seems strange to not mention "client" or "agent". I agree with Alissa about equating privacy and confidentiality. -3.1,: I’m confused by the first paragraph. I don’t find strings of the form of SEC-REQ-XX in 7921. I think _this_ doc sets these requirements, right? It’s not clear to me how 5 and 6 differ. Is it just a matter of the additional “before establishing a connection†part in 6? -3.4: Isn't 15 simply a restatement of the third item under 14? 3.5: The MAYs in 19 and 20 seem like statements of fact. (That is, do they simply recognize reality, or to they grant permission?) From nobody Wed Aug 17 19:53:39 2016 Return-Path: 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 3EBAD12D843; Wed, 17 Aug 2016 19:53:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.768 X-Spam-Level: X-Spam-Status: No, score=-15.768 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_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.247, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 h1cpLApc-RZI; Wed, 17 Aug 2016 19:53:31 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A515312B063; Wed, 17 Aug 2016 19:53:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3215; q=dns/txt; s=iport; t=1471488810; x=1472698410; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=iqvqJGCahmOnbFgM7uNc9pRBzkb6XEYfAXOhmk0T+Zk=; b=L3EiKAV36Vtrme6GpYoe5cS2paoXG/vKw8bCjrsO9n1B85xOvkBXMAlD fQf5EZNk75r2PHjl0TLtWdZSIMrJ3FwNfIMp73ti3om4Q2uGZYC/pmXoF ZLXqBVWGwd+4RzO9FRHpndsd3E3+i2NWS1Vs0SB2mwoYL70na1NxprE8s w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CJAgADHrVX/4QNJK1eg0SBUge1RYIPg?= =?us-ascii?q?X2CZoM3AoFmOBQCAQEBAQEBAV4nhF8BBXkQAgEIDgQpCzIXDgIEAQkEBYgxviI?= =?us-ascii?q?BAQEBAQEBAQEBAQEBAQEBAQEBAQEchiqETYQdhX4BBJN9hUcBjx2PSZAyAR42g?= =?us-ascii?q?kWBNW6FaUV/AQEB?= X-IronPort-AV: E=Sophos;i="5.28,537,1464652800"; d="scan'208";a="141076943" Received: from alln-core-10.cisco.com ([173.36.13.132]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 18 Aug 2016 02:53:29 +0000 Received: from XCH-ALN-001.cisco.com (xch-aln-001.cisco.com [173.36.7.11]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id u7I2rTpJ006487 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 18 Aug 2016 02:53:29 GMT Received: from xch-aln-002.cisco.com (173.36.7.12) by XCH-ALN-001.cisco.com (173.36.7.11) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 17 Aug 2016 21:53:29 -0500 Received: from xch-aln-002.cisco.com ([173.36.7.12]) by XCH-ALN-002.cisco.com ([173.36.7.12]) with mapi id 15.00.1210.000; Wed, 17 Aug 2016 21:53:28 -0500 From: "Alvaro Retana (aretana)" To: Susan Hares , "'The IESG'" Thread-Topic: Alvaro Retana's No Objection on draft-ietf-i2rs-protocol-security-requirements-07: (with COMMENT) Thread-Index: AQHR+Plx0ThSsjCXkUiHItVMbeJWy6BOBWuA Date: Thu, 18 Aug 2016 02:53:28 +0000 Message-ID: References: <147148520752.23682.12743310118152055665.idtracker@ietfa.amsl.com> <000001d1f8f9$490933a0$db1b9ae0$@ndzh.com> In-Reply-To: <000001d1f8f9$490933a0$db1b9ae0$@ndzh.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.2.160219 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.82.173.92] Content-Type: text/plain; charset="Windows-1252" Content-ID: <7B312C21F6B87D47BFCA8E53AA2EF389@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: 'Jeffrey Haas' , "i2rs@ietf.org" , "i2rs-chairs@ietf.org" , "draft-ietf-i2rs-protocol-security-requirements@ietf.org" Subject: Re: [i2rs] Alvaro Retana's No Objection on draft-ietf-i2rs-protocol-security-requirements-07: (with COMMENT) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Aug 2016 02:53:32 -0000 On 8/17/16, 9:36 PM, "iesg on behalf of Susan Hares" wrote: Sue: Hi! ... > >>I think there is a contradiction between SEC-REQ-09 ("The I2RS protocol >>MUST be able to transfer data over a secure transport and optionally MAY >>be able to transfer data over a >non-secure transport") and this text >>from Section 3. (Security-Related Requirements): "=8AMUST be able to >>exchange data over a secure transport, but some functions may operate >>>on a non-secure transport." The latter text talks bout "some >>>functions" using a non-secure transport, while SEC-REQ-09 implies that >>>everything may use it. > >I do not see the contradiction in -08.txt. > >"The I2RS client and I2RS agent using the I2RS protocol MUST be able to >exchange=20 >data over a secure transport, but some functions may operate on a >non-secure >transport."=20 > >This says the I2RS client and I2RS agent must support using the I2RS >protocol over a security transport, but I2RS client software and I2RS >agent software may operate on non-secure transport. -08 still has these two pieces of text: "SEC-REQ-08: The I2RS protocol MUST be able to transfer data over a secure transport and optionally MAY be able to transfer data over a non-secure transport." ...and... >From Section 3: "...MUST be able to exchange data over a secure transport, but some functions may operate on a non-secure transport." Again, the difference is that the latter text mentions "some functions" (which seems in line with the changes you made in this version to highlight that not everything could be run over an insecure transport), while SEC-REQ-08 basically says that the i2rs protocol MAY be run over non-secure transport -- but it doesn't limit the i2rs protocol to some functions or some type or information. > > >Other comments from Section 3.1. (Mutual authentication of an I2RS client >and an I2RS Agent) > >>-- The text says that the "I2RS architecture >>[I-D.ietf-i2rs-architecture] sets the following requirements". I'm not >>sure what you mean my "sets", as there are no requirements >> labeled as such) in the architecture document. If there are, then this >>section doesn't seem to be needed (as others have mentioned). Maybe >>"these requirements are derived >> from the architecture", or something similar may be more appropriate. > >You are correct, the I2RS architecture does not label such requirements. > >We got into discussing a strawman protocol, and we found we needed to >restate the I2RS architecture documents design in the specific >requirements listed now in version 8 as: SEC-REQ-01 to SEC-REQ-07. In >this case the restatement is useful (see Joel's comment). Do you have a >suggestion for another term than "sets". See above. ... > > >> SEC-REQ-05 and SEC-REQ-06 sound the same to me. What is the >>difference? BTW, if there is a difference, instead of "IETF" I think >>that "standardized" may be better. > >Merged these into one in version -08.txt . Let me know what you think of >the merge. Now the single requirement just sounds redundant... Thanks! Alvaro. From nobody Wed Aug 17 19:55:44 2016 Return-Path: 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 C34FD12B063; Wed, 17 Aug 2016 19:55:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.738 X-Spam-Level: * X-Spam-Status: No, score=1.738 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, RDNS_NONE=0.793] autolearn=no 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 1Vw7BYz9cN_j; Wed, 17 Aug 2016 19:55:40 -0700 (PDT) Received: from hickoryhill-consulting.com (unknown [50.245.122.97]) (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 2E7FD12D130; Wed, 17 Aug 2016 19:55:40 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=174.124.169.225; From: "Susan Hares" To: "'Ben Campbell'" , "'The IESG'" References: <147148830474.23714.14742463076688973726.idtracker@ietfa.amsl.com> In-Reply-To: <147148830474.23714.14742463076688973726.idtracker@ietfa.amsl.com> Date: Wed, 17 Aug 2016 22:54:37 -0400 Message-ID: <000801d1f8fb$dd471d00$97d55700$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQINh8A5dk5cjuLgs2hgWO8Payjh05/W5f/w Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: jhaas@pfrc.org, i2rs@ietf.org, i2rs-chairs@ietf.org, draft-ietf-i2rs-protocol-security-requirements@ietf.org Subject: Re: [i2rs] Ben Campbell's No Objection on draft-ietf-i2rs-protocol-security-requirements-08: (with COMMENT) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Aug 2016 02:55:42 -0000 Ben:=20 I'd be glad to take any further suggestions on section 3.2 that improves = it for you. Does modifying this section from=20 Old/ A non-secure transport can be used for publishing telemetry data=20 or other operational state that was specifically indicated to non-confidential in the data model in the Yang syntax. =20 / New/ A non-secure transport can be used for publishing telemetry data=20 or other operational state that was specifically indicated to non-confidential in the data model in the Yang syntax. =20 Anything not specifically marked as "non-confidential" MUST=20 be transmitted over a secure transport connection. / Help your concerns on version 3.2?=20 Sue=20 -----Original Message----- From: Ben Campbell [mailto:ben@nostrum.com]=20 Sent: Wednesday, August 17, 2016 10:45 PM To: The IESG Cc: draft-ietf-i2rs-protocol-security-requirements@ietf.org; Jeffrey = Haas; i2rs-chairs@ietf.org; jhaas@pfrc.org; i2rs@ietf.org Subject: Ben Campbell's No Objection on = draft-ietf-i2rs-protocol-security-requirements-08: (with COMMENT) Ben Campbell has entered the following ballot position for draft-ietf-i2rs-protocol-security-requirements-08: No Objection When responding, please keep the subject line intact and reply to all = email addresses included in the To and CC lines. (Feel free to cut this = introductory paragraph, however.) Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-i2rs-protocol-security-requir= ements/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Version 8 resolved my discuss point for section 3.4. Thanks! I don't think it resolved my discuss point for 3.2. I'm clearing anyway, = because I think my point has been made. I would prefer the language to = say that anything not explicitly marked as non-confidential in the = relevant data model MUST be sent over a protected transport. But I will = leave it to the authors to do the right thing. I will leave my non-discuss comments below for reference. I think = version 8 resolves at least some of them. Any remaining are up to you; none of = them are show stoppers. > -2.1: I am on the fence about other's comments about copying = definitions here--but if you do copy them here, it seems strange to not = mention "client" or "agent". [Sue] Removed definitions.=20 > I agree with Alissa about equating privacy and confidentiality. [Sue]: Removed definition with this text.=20 -3.1,:=20 >? I=E2=80=99m confused by the first paragraph. I don=E2=80=99t find = strings of the form of SEC-REQ-XX in 7921. I think _this_ doc sets these = requirements, right? This document restates the concepts in RFC7921, and adds specific = numbers. The restatement in this form allows requirements to be checked = against the developed protocol.=20 > It=E2=80=99s not clear to me how 5 and 6 differ. Is it just a matter = of the additional =E2=80=9Cbefore establishing a connection=E2=80=9D = part in 6? Version 08 has these two merged.=20 > -3.4: Isn't 15 simply a restatement of the third item under 14? Changed this text. Please review the new 13 and 14.=20 3.5: The MAYs in 19 and 20 seem like statements of fact. (That is, do = they simply recognize reality, or to they grant permission?) They provide a list of approved examples so that the NETCONF/RESTCONF = can review these examples. These examples will help the = NETCONF/RESTCONF in their design discussions.=20 Sue=20 From nobody Wed Aug 17 19:59:27 2016 Return-Path: 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 64F0E12D84D; Wed, 17 Aug 2016 19:59:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.147 X-Spam-Level: X-Spam-Status: No, score=-3.147 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.247] 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 VKLF3TG9goG8; Wed, 17 Aug 2016 19:59:17 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 AB30312B063; Wed, 17 Aug 2016 19:59:17 -0700 (PDT) Received: from [10.0.1.4] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id u7I2xGql012178 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 17 Aug 2016 21:59:16 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.4] From: "Ben Campbell" To: "Susan Hares" Date: Wed, 17 Aug 2016 21:59:16 -0500 Message-ID: <83E3F6F1-ED04-4744-BC42-84C67653EC34@nostrum.com> In-Reply-To: <000801d1f8fb$dd471d00$97d55700$@ndzh.com> References: <147148830474.23714.14742463076688973726.idtracker@ietfa.amsl.com> <000801d1f8fb$dd471d00$97d55700$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Mailer: MailMate (1.9.4r5234) Archived-At: Cc: Jeffrey Haas , i2rs@ietf.org, The IESG , i2rs-chairs@ietf.org, draft-ietf-i2rs-protocol-security-requirements@ietf.org Subject: Re: [i2rs] Ben Campbell's No Objection on draft-ietf-i2rs-protocol-security-requirements-08: (with COMMENT) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Aug 2016 02:59:19 -0000 Yes, that would address my concern, especially if you think implementers = will pay attention :-) There may be interaction with the SHOULD in the previous paragraph, but = I will leave the word-smithing to you. Thanks! Ben. On 17 Aug 2016, at 21:54, Susan Hares wrote: > Ben: > > I'd be glad to take any further suggestions on section 3.2 that = > improves it for you. Does modifying this section from > > 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 in the Yang syntax. > Anything not specifically marked as "non-confidential" MUST > be transmitted over a secure transport connection. > / > > Help your concerns on version 3.2? > > Sue > > > -----Original Message----- > From: Ben Campbell [mailto:ben@nostrum.com] > Sent: Wednesday, August 17, 2016 10:45 PM > To: The IESG > Cc: draft-ietf-i2rs-protocol-security-requirements@ietf.org; Jeffrey = > Haas; i2rs-chairs@ietf.org; jhaas@pfrc.org; i2rs@ietf.org > Subject: Ben Campbell's No Objection on = > draft-ietf-i2rs-protocol-security-requirements-08: (with COMMENT) > > Ben Campbell has entered the following ballot position for > draft-ietf-i2rs-protocol-security-requirements-08: No Objection > > When responding, please keep the subject line intact and reply to all = > email addresses included in the To and CC lines. (Feel free to cut = > this introductory paragraph, however.) > > > Please refer to = > https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-i2rs-protocol-security-requ= irements/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Version 8 resolved my discuss point for section 3.4. Thanks! > > I don't think it resolved my discuss point for 3.2. I'm clearing = > anyway, because I think my point has been made. I would prefer the = > language to say that anything not explicitly marked as = > non-confidential in the relevant data model MUST be sent over a = > protected transport. But I will leave it to the authors to do the = > right thing. > > I will leave my non-discuss comments below for reference. I think = > version > 8 resolves at least some of them. Any remaining are up to you; none of = > them are show stoppers. > >> -2.1: I am on the fence about other's comments about copying = >> definitions here--but if you do copy them here, it seems strange to = >> not mention "client" or "agent". > > [Sue] Removed definitions. > >> I agree with Alissa about equating privacy and confidentiality. > [Sue]: Removed definition with this text. > > -3.1,: >> ? I=E2=80=99m confused by the first paragraph. I don=E2=80=99t find st= rings of = >> the form of SEC-REQ-XX in 7921. I think _this_ doc sets these = >> requirements, right? > > This document restates the concepts in RFC7921, and adds specific = > numbers. The restatement in this form allows requirements to be = > checked against the developed protocol. > > >> It=E2=80=99s not clear to me how 5 and 6 differ. Is it just a matter o= f the = >> additional =E2=80=9Cbefore establishing a connection=E2=80=9D part in = 6? > > Version 08 has these two merged. > > >> -3.4: Isn't 15 simply a restatement of the third item under 14? > > Changed this text. Please review the new 13 and 14. > > 3.5: The MAYs in 19 and 20 seem like statements of fact. (That is, do = > they simply recognize reality, or to they grant permission?) > > They provide a list of approved examples so that the NETCONF/RESTCONF = > can review these examples. These examples will help the = > NETCONF/RESTCONF in their design discussions. > > Sue From nobody Wed Aug 17 20:04:33 2016 Return-Path: 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 AC2A712D548; Wed, 17 Aug 2016 20:04:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.738 X-Spam-Level: * X-Spam-Status: No, score=1.738 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, RDNS_NONE=0.793] autolearn=no 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 fUzYTLT1RSXt; Wed, 17 Aug 2016 20:04:24 -0700 (PDT) Received: from hickoryhill-consulting.com (unknown [50.245.122.97]) (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 4A97012B041; Wed, 17 Aug 2016 20:04:24 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=174.124.169.225; From: "Susan Hares" To: "'Alvaro Retana \(aretana\)'" , "'The IESG'" References: <147148520752.23682.12743310118152055665.idtracker@ietfa.amsl.com> <000001d1f8f9$490933a0$db1b9ae0$@ndzh.com> In-Reply-To: Date: Wed, 17 Aug 2016 23:03:23 -0400 Message-ID: <000a01d1f8fd$157d1bb0$40775310$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJc/Nj7gQdXELJSuw4AgM5RmU8YzwL7CBnjApNgb5ifC4utIA== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: 'Jeffrey Haas' , i2rs@ietf.org, i2rs-chairs@ietf.org, draft-ietf-i2rs-protocol-security-requirements@ietf.org Subject: Re: [i2rs] Alvaro Retana's No Objection on draft-ietf-i2rs-protocol-security-requirements-07: (with COMMENT) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Aug 2016 03:04:26 -0000 Alvaro:=20 How about the following for the introduction to section 3: The security for the I2RS protocol requires mutually authenticated I2RS clients and I2RS agents. The I2RS client and I2RS agent using the I2RS protocol = MUST be able to exchange=20 data over a secure transport. Optionally, the I2RS Client and I2RS = agent MAY operate on a non-secure transport to transfer a specific set of non-confidential data=20 I think this matches SEC-REQ-08=20 SEC-REQ-08: The I2RS protocol MUST be able to transfer data over a secure transport and optionally MAY be able to transfer data over a non-secure transport. A secure transport MUST provide data confidentiality, data integrity, and replay prevention. The default I2RS transport is a secure transport.=20 A non-secure transport can be used for publishing telemetry data=20 or other operational state that was specifically indicated to non-confidential in the data model in the Yang syntax. =20 Anything not specifically marked as "non-confidential" MUST=20 be transmitted over a secure transport connection.=20 The configuration of ephemeral data in the I2RS Agent by the=20 I2RS client SHOULD be done over a secure transport. It is anticipated that the passing of most I2RS ephemeral state operational=20 status SHOULD be done over a secure transport. =20 As draft-ietf-i2rs-ephemeral-state notes data model MUST indicate whether the transport exchanging the data between I2RS client and I2RS agent is=20 secure or insecure. The default mode of transport is=20 secure so data models SHOULD clearly annotate what data nodes can=20 be passed over an insecure connection. What do you think?=20 For SEC-REQ-05, I re-read it now and it is redundant. I changed to:=20 SEC-REQ-05: Identifier distribution and the loading of these identifiers into I2RS agent and I2RS Client SHOULD occur outside the I2RS protocol prior to the=20 I2RS protocol establishing a connection between I2RS client and I2RS = agent. (One mechanism such mechanism is AAA protocols.) What do you think?=20 These will be uploaded in a version -09.txt=20 Sue=20 -----Original Message----- From: Alvaro Retana (aretana) [mailto:aretana@cisco.com]=20 Sent: Wednesday, August 17, 2016 10:53 PM To: Susan Hares; 'The IESG' Cc: 'Jeffrey Haas'; i2rs@ietf.org; i2rs-chairs@ietf.org; draft-ietf-i2rs-protocol-security-requirements@ietf.org Subject: Re: Alvaro Retana's No Objection on draft-ietf-i2rs-protocol-security-requirements-07: (with COMMENT) On 8/17/16, 9:36 PM, "iesg on behalf of Susan Hares" wrote: Sue: Hi! ... > >>I think there is a contradiction between SEC-REQ-09 ("The I2RS=20 >>protocol MUST be able to transfer data over a secure transport and=20 >>optionally MAY be able to transfer data over a >non-secure transport") = >>and this text from Section 3. (Security-Related Requirements): = "=A9MUST=20 >>be able to exchange data over a secure transport, but some functions=20 >>may operate >>>on a non-secure transport." The latter text talks bout "some=20 >>>functions" using a non-secure transport, while SEC-REQ-09 implies=20 >>>that everything may use it. > >I do not see the contradiction in -08.txt. > >"The I2RS client and I2RS agent using the I2RS protocol MUST be able to = >exchange data over a secure transport, but some functions may operate=20 >on a non-secure transport." > >This says the I2RS client and I2RS agent must support using the I2RS=20 >protocol over a security transport, but I2RS client software and I2RS=20 >agent software may operate on non-secure transport. -08 still has these two pieces of text: "SEC-REQ-08: The I2RS protocol MUST be able to transfer data over a = secure transport and optionally MAY be able to transfer data over a non-secure transport." ...and... >From Section 3: "...MUST be able to exchange data over a secure=20 >transport, but some functions may operate on a non-secure transport." Again, the difference is that the latter text mentions "some functions" (which seems in line with the changes you made in this version to = highlight that not everything could be run over an insecure transport), while SEC-REQ-08 basically says that the i2rs protocol MAY be run over = non-secure transport -- but it doesn't limit the i2rs protocol to some functions or some type or information. > > >Other comments from Section 3.1. (Mutual authentication of an I2RS=20 >client and an I2RS Agent) > >>-- The text says that the "I2RS architecture=20 >>[I-D.ietf-i2rs-architecture] sets the following requirements". I'm=20 >>not sure what you mean my "sets", as there are no requirements =20 >>labeled as such) in the architecture document. If there are, then=20 >>this section doesn't seem to be needed (as others have mentioned). =20 >>Maybe "these requirements are derived from the architecture", or=20 >>something similar may be more appropriate. > >You are correct, the I2RS architecture does not label such = requirements. > >We got into discussing a strawman protocol, and we found we needed to=20 >restate the I2RS architecture documents design in the specific >requirements listed now in version 8 as: SEC-REQ-01 to SEC-REQ-07. = In >this case the restatement is useful (see Joel's comment). Do you have=20 >a suggestion for another term than "sets". See above. ... > > >> SEC-REQ-05 and SEC-REQ-06 sound the same to me. What is the=20 >>difference? BTW, if there is a difference, instead of "IETF" I think=20 >>that "standardized" may be better. > >Merged these into one in version -08.txt . Let me know what you think=20 >of the merge. Now the single requirement just sounds redundant... Thanks! Alvaro. From nobody Wed Aug 17 20:12:57 2016 Return-Path: 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 6306A12D85C; Wed, 17 Aug 2016 20:12:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.768 X-Spam-Level: X-Spam-Status: No, score=-15.768 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_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.247, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 m9UcAPfrnZ59; Wed, 17 Aug 2016 20:12:55 -0700 (PDT) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3BE7012D857; Wed, 17 Aug 2016 20:12:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1191; q=dns/txt; s=iport; t=1471489975; x=1472699575; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=nUyAcejGRPLAGau6Tl5+qEJ/LnG/12ZQ/baAol96RtQ=; b=IM74hr4ndLuGu/xqQAUJbOQU8opBvlzD39Y9LR3yF1QYToCN1ln/0QUv FyaCn6gdS/k+pz7f8ThAn8Hfj+RDRbaV7JWkvc2HioF5KJf+ejnh0QGRA uWlwVesxh/5Y2gt8tpsCYepCpwdR5wALiLqhHlpiA6Jbm9ib34mGbRXBg U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CJAgAsJ7VX/5ldJa1eg0SBUge1RYIPg?= =?us-ascii?q?X2GHQKBZzgUAgEBAQEBAQFeJ4RfAQU6PxACAQgOKAULMiUCBAEJBAWIMb4dAQE?= =?us-ascii?q?BAQEBAQEBAQEBAQEBAQEBAQEBHIYqhE2KGwEEk32FRwGPHYFriA6FUJAyAR42g?= =?us-ascii?q?kWBNW6GLn8BAQE?= X-IronPort-AV: E=Sophos;i="5.28,537,1464652800"; d="scan'208";a="312254759" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 18 Aug 2016 03:12:54 +0000 Received: from XCH-ALN-002.cisco.com (xch-aln-002.cisco.com [173.36.7.12]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id u7I3CsHp001914 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 18 Aug 2016 03:12:54 GMT Received: from xch-aln-002.cisco.com (173.36.7.12) by XCH-ALN-002.cisco.com (173.36.7.12) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 17 Aug 2016 22:12:53 -0500 Received: from xch-aln-002.cisco.com ([173.36.7.12]) by XCH-ALN-002.cisco.com ([173.36.7.12]) with mapi id 15.00.1210.000; Wed, 17 Aug 2016 22:12:53 -0500 From: "Alvaro Retana (aretana)" To: Susan Hares , "'The IESG'" Thread-Topic: Alvaro Retana's No Objection on draft-ietf-i2rs-protocol-security-requirements-07: (with COMMENT) Thread-Index: AQHR+Plx0ThSsjCXkUiHItVMbeJWy6BOBWuAgABWnYD//67PgA== Date: Thu, 18 Aug 2016 03:12:53 +0000 Message-ID: References: <147148520752.23682.12743310118152055665.idtracker@ietfa.amsl.com> <000001d1f8f9$490933a0$db1b9ae0$@ndzh.com> <000a01d1f8fd$157d1bb0$40775310$@ndzh.com> In-Reply-To: <000a01d1f8fd$157d1bb0$40775310$@ndzh.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.2.160219 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.82.173.92] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: 'Jeffrey Haas' , "i2rs@ietf.org" , "i2rs-chairs@ietf.org" , "draft-ietf-i2rs-protocol-security-requirements@ietf.org" Subject: Re: [i2rs] Alvaro Retana's No Objection on draft-ietf-i2rs-protocol-security-requirements-07: (with COMMENT) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Aug 2016 03:12:56 -0000 On 8/17/16, 10:03 PM, "iesg on behalf of Susan Hares" wrote: Hi! >How about the following for the introduction to section 3: > >The security for the I2RS protocol requires mutually authenticated I2RS >clients >and I2RS agents. The I2RS client and I2RS agent using the I2RS protocol >MUST >be able to exchange >data over a secure transport. Optionally, the I2RS Client and I2RS agent >MAY operate >on a non-secure transport to transfer a specific set of non-confidential >data=20 > >I think this matches SEC-REQ-08 It does.=20 Now that the text is in sync, it makes me wonder why it needs to be mentioned twice (and not just in the requirements section). ... >=20 >For SEC-REQ-05, I re-read it now and it is redundant. I changed to: > >SEC-REQ-05: Identifier distribution and the loading of these identifiers >into I2RS agent > and I2RS Client SHOULD occur outside the I2RS protocol prior to the > I2RS protocol establishing a connection between I2RS client and I2RS >agent. > > (One mechanism such mechanism is AAA protocols.) > >What do you think? Looks good to me. Thanks! Alvaro. From nobody Thu Aug 18 00:32:17 2016 Return-Path: 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 E8E9B12D6AE; Thu, 18 Aug 2016 00:32:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.447 X-Spam-Level: X-Spam-Status: No, score=-5.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.247] 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 QvyBwFn6a_fz; Thu, 18 Aug 2016 00:32:09 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EBDD512B011; Thu, 18 Aug 2016 00:32:08 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 546FDFAA; Thu, 18 Aug 2016 09:32:07 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.205]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id T44fxtizFCWL; Thu, 18 Aug 2016 09:32:03 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Thu, 18 Aug 2016 09:32:06 +0200 (CEST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 308012009D; Thu, 18 Aug 2016 09:32:06 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id wfmo7viZ7RuJ; Thu, 18 Aug 2016 09:32:04 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id DC405200A7; Thu, 18 Aug 2016 09:32:03 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id B4F893C23C55; Thu, 18 Aug 2016 09:32:03 +0200 (CEST) Date: Thu, 18 Aug 2016 09:32:03 +0200 From: Juergen Schoenwaelder To: Susan Hares Message-ID: <20160818073203.GA4338@elstar.local> Mail-Followup-To: Susan Hares , 'Kathleen Moriarty' , 'The IESG' , jhaas@pfrc.org, i2rs@ietf.org, i2rs-chairs@ietf.org, draft-ietf-i2rs-protocol-security-requirements@ietf.org References: <147146974235.23784.4389421535496134619.idtracker@ietfa.amsl.com> <013b01d1f8ee$31fa09b0$95ee1d10$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <013b01d1f8ee$31fa09b0$95ee1d10$@ndzh.com> User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Cc: i2rs@ietf.org, i2rs-chairs@ietf.org, 'Kathleen Moriarty' , 'The IESG' , jhaas@pfrc.org, 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 Reply-To: Juergen Schoenwaelder List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Aug 2016 07:32:11 -0000 On Wed, Aug 17, 2016 at 09:16:48PM -0400, Susan Hares wrote: > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > > Section 3: > > Can you clarify the second to last sentence? Do you mean there are sections that indicate an insecure transport should be used? > > I2RS allows the use of an > > insecure transport for portions of data models that clearly indicate > > insecure transport. > > > Perhaps: > > I2RS allows the use of an > > insecure transport for portions of data models that clearly indicate the use of an > > insecure transport. I still wonder how a data model writer can reasonably decide whether a piece of information can be shipped safely over an insecure transport since this decision often depends on the specifics of a deployment situation. /js PS: I hope we do not end up with defining data multiple times (once for insecure transport and once for secured transports). -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Thu Aug 18 05:08:38 2016 Return-Path: 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 1107712DA32; Thu, 18 Aug 2016 05:08:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.738 X-Spam-Level: * X-Spam-Status: No, score=1.738 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, RDNS_NONE=0.793] autolearn=no 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 MlxPfxpxX4j2; Thu, 18 Aug 2016 05:08:29 -0700 (PDT) Received: from hickoryhill-consulting.com (unknown [50.245.122.97]) (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 8495D12D9DE; Thu, 18 Aug 2016 05:08:27 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=174.124.167.170; From: "Susan Hares" To: "'Juergen Schoenwaelder'" References: <147146974235.23784.4389421535496134619.idtracker@ietfa.amsl.com> <013b01d1f8ee$31fa09b0$95ee1d10$@ndzh.com> <20160818073203.GA4338@elstar.local> In-Reply-To: <20160818073203.GA4338@elstar.local> Date: Thu, 18 Aug 2016 08:07:18 -0400 Message-ID: <04b501d1f949$116c63e0$34452ba0$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIa7Lz6VgZw6h2A0uGNzOgAA2Ic8QJ/RF5yARxv/cqfn9jgUA== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: i2rs@ietf.org, i2rs-chairs@ietf.org, 'Kathleen Moriarty' , 'The IESG' , jhaas@pfrc.org, 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Aug 2016 12:08:31 -0000 Juergen: My example is the looking glass servers for the BGP route views project (http://www.routeviews.org/) or a route indicating the presence of a web-server that is public. For the BGP I2RS route, a yang model could replace the looking glass function, and provide events for these looking glass functions. For the web-server route, an event be sent when that one route is added. Sue -----Original Message----- From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de] Sent: Thursday, August 18, 2016 3:32 AM To: Susan Hares Cc: 'Kathleen Moriarty'; 'The IESG'; jhaas@pfrc.org; i2rs@ietf.org; i2rs-chairs@ietf.org; 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 Wed, Aug 17, 2016 at 09:16:48PM -0400, Susan Hares wrote: > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > > Section 3: > > Can you clarify the second to last sentence? Do you mean there are sections that indicate an insecure transport should be used? > > I2RS allows the use of an > > insecure transport for portions of data models that clearly > > indicate insecure transport. > > > Perhaps: > > I2RS allows the use of an > > insecure transport for portions of data models that clearly > > indicate the use of an insecure transport. I still wonder how a data model writer can reasonably decide whether a piece of information can be shipped safely over an insecure transport since this decision often depends on the specifics of a deployment situation. /js PS: I hope we do not end up with defining data multiple times (once for insecure transport and once for secured transports). -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Thu Aug 18 05:15:23 2016 Return-Path: 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 5778A12DADD; Thu, 18 Aug 2016 05:15:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.447 X-Spam-Level: X-Spam-Status: No, score=-5.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.247] 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 yXhWXUAgLQY8; Thu, 18 Aug 2016 05:15:12 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 02EAE12DADF; Thu, 18 Aug 2016 05:14:11 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id C79DD8DF; Thu, 18 Aug 2016 14:14:09 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.205]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id i4sMtcNCP4rt; Thu, 18 Aug 2016 14:14:08 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Thu, 18 Aug 2016 14:14:08 +0200 (CEST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id B9D9F200A5; Thu, 18 Aug 2016 14:14:08 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 9tqARp_QHCOZ; Thu, 18 Aug 2016 14:14:07 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 716B1200A6; Thu, 18 Aug 2016 14:14:07 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 77F5C3C24F2C; Thu, 18 Aug 2016 14:14:06 +0200 (CEST) Date: Thu, 18 Aug 2016 14:14:05 +0200 From: Juergen Schoenwaelder To: Susan Hares Message-ID: <20160818121405.GA5282@elstar.local> Mail-Followup-To: Susan Hares , i2rs@ietf.org, i2rs-chairs@ietf.org, 'Kathleen Moriarty' , 'The IESG' , jhaas@pfrc.org, draft-ietf-i2rs-protocol-security-requirements@ietf.org References: <147146974235.23784.4389421535496134619.idtracker@ietfa.amsl.com> <013b01d1f8ee$31fa09b0$95ee1d10$@ndzh.com> <20160818073203.GA4338@elstar.local> <04b501d1f949$116c63e0$34452ba0$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <04b501d1f949$116c63e0$34452ba0$@ndzh.com> User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Cc: i2rs@ietf.org, i2rs-chairs@ietf.org, 'Kathleen Moriarty' , 'The IESG' , jhaas@pfrc.org, 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 Reply-To: Juergen Schoenwaelder List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Aug 2016 12:15:15 -0000 Sue, I still do not see why the 'mode of exposure' of data benefits from being hard-wired in the data model. For me, it is a situational and deployment specific question. But I shut up here since I aired this concern before (and we simply seem to disagree). /js On Thu, Aug 18, 2016 at 08:07:18AM -0400, Susan Hares wrote: > Juergen: > > My example is the looking glass servers for the BGP route views project > (http://www.routeviews.org/) or a route indicating the presence of a > web-server that is public. For the BGP I2RS route, a yang model could > replace the looking glass function, and provide events for these looking > glass functions. For the web-server route, an event be sent when that > one route is added. > > Sue > > > -----Original Message----- > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de] > Sent: Thursday, August 18, 2016 3:32 AM > To: Susan Hares > Cc: 'Kathleen Moriarty'; 'The IESG'; jhaas@pfrc.org; i2rs@ietf.org; > i2rs-chairs@ietf.org; > 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 Wed, Aug 17, 2016 at 09:16:48PM -0400, Susan Hares wrote: > > ---------------------------------------------------------------------- > > COMMENT: > > ---------------------------------------------------------------------- > > > > > Section 3: > > > Can you clarify the second to last sentence? Do you mean there are > sections that indicate an insecure transport should be used? > > > I2RS allows the use of an > > > insecure transport for portions of data models that clearly > > > indicate insecure transport. > > > > > Perhaps: > > > I2RS allows the use of an > > > insecure transport for portions of data models that clearly > > > indicate the use of an insecure transport. > > I still wonder how a data model writer can reasonably decide whether a piece > of information can be shipped safely over an insecure transport since this > decision often depends on the specifics of a deployment situation. > > /js > > PS: I hope we do not end up with defining data multiple times (once > for insecure transport and once for secured transports). > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Thu Aug 18 05:53:33 2016 Return-Path: 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 CD25D12D0B4; Thu, 18 Aug 2016 05:53:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.106 X-Spam-Level: X-Spam-Status: No, score=-1.106 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RDNS_NONE=0.793] autolearn=no 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 b9oh4_0ddW7b; Thu, 18 Aug 2016 05:53:30 -0700 (PDT) Received: from hickoryhill-consulting.com (unknown [50.245.122.97]) (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 043B312DD8F; Thu, 18 Aug 2016 05:52:35 -0700 (PDT) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=174.124.167.170; Date: Thu, 18 Aug 2016 08:51:26 -0400 Message-ID: Importance: normal From: Susan Hares To: "Alvaro Retana (aretana)" , 'The IESG' MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--_com.samsung.android.email_1243475407913100" X-Authenticated-User: skh@ndzh.com Archived-At: Cc: 'Jeffrey Haas' , "i2rs@ietf.org" , "i2rs-chairs@ietf.org" , "draft-ietf-i2rs-protocol-security-requirements@ietf.org" Subject: Re: [i2rs] Alvaro Retana's No Objection on draft-ietf-i2rs-protocol-security-requirements-07: (with COMMENT) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Aug 2016 12:53:32 -0000 ----_com.samsung.android.email_1243475407913100 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 QWx2YXJvOgpZb3UgYXJlIHJpZ2h0LiDCoEkgd2lsbCByZW1vdmUgaXQgaW4gdGhlIG5leHQgcmV2 aXNpb24uIMKgClN1ZQoKClNlbnQgdmlhIHRoZSBTYW1zdW5nIEdhbGF4eSBOb3RlNSwgYW4gQVQm VCA0RyBMVEUgc21hcnRwaG9uZQotLS0tLS0tLSBPcmlnaW5hbCBtZXNzYWdlIC0tLS0tLS0tRnJv bTogIkFsdmFybyBSZXRhbmEgKGFyZXRhbmEpIiA8YXJldGFuYUBjaXNjby5jb20+IERhdGU6IDgv MTcvMTYgIDExOjEyIFBNICAoR01ULTA1OjAwKSBUbzogU3VzYW4gSGFyZXMgPHNoYXJlc0BuZHpo LmNvbT4sICdUaGUgSUVTRycgPGllc2dAaWV0Zi5vcmc+IENjOiAnSmVmZnJleSBIYWFzJyA8amhh YXNAcGZyYy5vcmc+LCBpMnJzQGlldGYub3JnLCBpMnJzLWNoYWlyc0BpZXRmLm9yZywgZHJhZnQt aWV0Zi1pMnJzLXByb3RvY29sLXNlY3VyaXR5LXJlcXVpcmVtZW50c0BpZXRmLm9yZyBTdWJqZWN0 OiBSZTogQWx2YXJvIFJldGFuYSdzIE5vIE9iamVjdGlvbiBvbgogIGRyYWZ0LWlldGYtaTJycy1w cm90b2NvbC1zZWN1cml0eS1yZXF1aXJlbWVudHMtMDc6ICh3aXRoIENPTU1FTlQpIApPbiA4LzE3 LzE2LCAxMDowMyBQTSwgImllc2cgb24gYmVoYWxmIG9mIFN1c2FuIEhhcmVzIgo8aWVzZy1ib3Vu Y2VzQGlldGYub3JnIG9uIGJlaGFsZiBvZiBzaGFyZXNAbmR6aC5jb20+IHdyb3RlOgoKSGkhCgoK PkhvdyBhYm91dCB0aGUgZm9sbG93aW5nIGZvciB0aGUgaW50cm9kdWN0aW9uIHRvIHNlY3Rpb24g MzoKPgo+VGhlIHNlY3VyaXR5IGZvciB0aGUgSTJSUyBwcm90b2NvbCByZXF1aXJlcyBtdXR1YWxs eSBhdXRoZW50aWNhdGVkIEkyUlMKPmNsaWVudHMKPmFuZCBJMlJTIGFnZW50cy4gVGhlIEkyUlMg Y2xpZW50IGFuZCBJMlJTIGFnZW50IHVzaW5nIHRoZSBJMlJTIHByb3RvY29sCj5NVVNUCj5iZSBh YmxlIHRvIGV4Y2hhbmdlCj5kYXRhIG92ZXIgYSBzZWN1cmUgdHJhbnNwb3J0LsKgIE9wdGlvbmFs bHksIHRoZSBJMlJTIENsaWVudCBhbmQgSTJSUyBhZ2VudAo+TUFZIG9wZXJhdGUKPm9uIGEgbm9u LXNlY3VyZSB0cmFuc3BvcnQgdG8gdHJhbnNmZXIgYSBzcGVjaWZpYyBzZXQgb2Ygbm9uLWNvbmZp ZGVudGlhbAo+ZGF0YSAKPgo+SSB0aGluayB0aGlzIG1hdGNoZXMgU0VDLVJFUS0wOAoKSXQgZG9l cy4gCgpOb3cgdGhhdCB0aGUgdGV4dCBpcyBpbiBzeW5jLCBpdCBtYWtlcyBtZSB3b25kZXIgd2h5 IGl0IG5lZWRzIHRvIGJlCm1lbnRpb25lZCB0d2ljZSAoYW5kIG5vdCBqdXN0IGluIHRoZSByZXF1 aXJlbWVudHMgc2VjdGlvbikuCgouLi4KPiAKPkZvciBTRUMtUkVRLTA1LCBJIHJlLXJlYWQgaXQg bm93IGFuZCBpdCBpcyByZWR1bmRhbnQuwqAgSSBjaGFuZ2VkIHRvOgo+Cj5TRUMtUkVRLTA1OiBJ ZGVudGlmaWVyIGRpc3RyaWJ1dGlvbiBhbmQgdGhlIGxvYWRpbmcgb2YgdGhlc2UgaWRlbnRpZmll cnMKPmludG8gSTJSUyBhZ2VudAo+IGFuZCBJMlJTIENsaWVudCBTSE9VTEQgb2NjdXIgb3V0c2lk ZSB0aGUgSTJSUyBwcm90b2NvbCBwcmlvciB0byB0aGUKPiBJMlJTIHByb3RvY29sIGVzdGFibGlz aGluZyBhIGNvbm5lY3Rpb24gYmV0d2VlbiBJMlJTIGNsaWVudCBhbmQgSTJSUwo+YWdlbnQuCj4K PiAoT25lIG1lY2hhbmlzbSBzdWNoIG1lY2hhbmlzbSBpcyBBQUEgcHJvdG9jb2xzLikKPgo+V2hh dCBkbyB5b3UgdGhpbms/CgpMb29rcyBnb29kIHRvIG1lLgoKVGhhbmtzIQoKQWx2YXJvLgoK ----_com.samsung.android.email_1243475407913100 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 PGh0bWw+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0 L2h0bWw7IGNoYXJzZXQ9VVRGLTgiPjwvaGVhZD48Ym9keT48ZGl2PkFsdmFybzo8L2Rpdj48ZGl2 Pjxicj48L2Rpdj48ZGl2PllvdSBhcmUgcmlnaHQuICZuYnNwO0kgd2lsbCByZW1vdmUgaXQgaW4g dGhlIG5leHQgcmV2aXNpb24uICZuYnNwOzwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXY+U3VlPC9k aXY+PGRpdj48YnI+PC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdiBpZD0i Y29tcG9zZXJfc2lnbmF0dXJlIj48ZGl2IHN0eWxlPSJmb250LXNpemU6ODUlO2NvbG9yOiM1NzU3 NTciIGRpcj0iYXV0byI+U2VudCB2aWEgdGhlIFNhbXN1bmcgR2FsYXh5IE5vdGU1LCBhbiBBVCZh bXA7VCA0RyBMVEUgc21hcnRwaG9uZTwvZGl2PjwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXYgc3R5 bGU9ImZvbnQtc2l6ZToxMDAlO2NvbG9yOiMwMDAwMDAiPjwhLS0gb3JpZ2luYWxNZXNzYWdlIC0t PjxkaXY+LS0tLS0tLS0gT3JpZ2luYWwgbWVzc2FnZSAtLS0tLS0tLTwvZGl2PjxkaXY+RnJvbTog IkFsdmFybyBSZXRhbmEgKGFyZXRhbmEpIiAmbHQ7YXJldGFuYUBjaXNjby5jb20mZ3Q7IDwvZGl2 PjxkaXY+RGF0ZTogOC8xNy8xNiAgMTE6MTIgUE0gIChHTVQtMDU6MDApIDwvZGl2PjxkaXY+VG86 IFN1c2FuIEhhcmVzICZsdDtzaGFyZXNAbmR6aC5jb20mZ3Q7LCAnVGhlIElFU0cnICZsdDtpZXNn QGlldGYub3JnJmd0OyA8L2Rpdj48ZGl2PkNjOiAnSmVmZnJleSBIYWFzJyAmbHQ7amhhYXNAcGZy Yy5vcmcmZ3Q7LCBpMnJzQGlldGYub3JnLCBpMnJzLWNoYWlyc0BpZXRmLm9yZywgZHJhZnQtaWV0 Zi1pMnJzLXByb3RvY29sLXNlY3VyaXR5LXJlcXVpcmVtZW50c0BpZXRmLm9yZyA8L2Rpdj48ZGl2 PlN1YmplY3Q6IFJlOiBBbHZhcm8gUmV0YW5hJ3MgTm8gT2JqZWN0aW9uIG9uCiAgZHJhZnQtaWV0 Zi1pMnJzLXByb3RvY29sLXNlY3VyaXR5LXJlcXVpcmVtZW50cy0wNzogKHdpdGggQ09NTUVOVCkg PC9kaXY+PGRpdj48YnI+PC9kaXY+PC9kaXY+T24gOC8xNy8xNiwgMTA6MDMgUE0sICJpZXNnIG9u IGJlaGFsZiBvZiBTdXNhbiBIYXJlcyI8YnI+Jmx0O2llc2ctYm91bmNlc0BpZXRmLm9yZyBvbiBi ZWhhbGYgb2Ygc2hhcmVzQG5kemguY29tJmd0OyB3cm90ZTo8YnI+PGJyPkhpITxicj48YnI+PGJy PiZndDtIb3cgYWJvdXQgdGhlIGZvbGxvd2luZyBmb3IgdGhlIGludHJvZHVjdGlvbiB0byBzZWN0 aW9uIDM6PGJyPiZndDs8YnI+Jmd0O1RoZSBzZWN1cml0eSBmb3IgdGhlIEkyUlMgcHJvdG9jb2wg cmVxdWlyZXMgbXV0dWFsbHkgYXV0aGVudGljYXRlZCBJMlJTPGJyPiZndDtjbGllbnRzPGJyPiZn dDthbmQgSTJSUyBhZ2VudHMuIFRoZSBJMlJTIGNsaWVudCBhbmQgSTJSUyBhZ2VudCB1c2luZyB0 aGUgSTJSUyBwcm90b2NvbDxicj4mZ3Q7TVVTVDxicj4mZ3Q7YmUgYWJsZSB0byBleGNoYW5nZTxi cj4mZ3Q7ZGF0YSBvdmVyIGEgc2VjdXJlIHRyYW5zcG9ydC4mbmJzcDsgT3B0aW9uYWxseSwgdGhl IEkyUlMgQ2xpZW50IGFuZCBJMlJTIGFnZW50PGJyPiZndDtNQVkgb3BlcmF0ZTxicj4mZ3Q7b24g YSBub24tc2VjdXJlIHRyYW5zcG9ydCB0byB0cmFuc2ZlciBhIHNwZWNpZmljIHNldCBvZiBub24t Y29uZmlkZW50aWFsPGJyPiZndDtkYXRhIDxicj4mZ3Q7PGJyPiZndDtJIHRoaW5rIHRoaXMgbWF0 Y2hlcyBTRUMtUkVRLTA4PGJyPjxicj5JdCBkb2VzLiA8YnI+PGJyPk5vdyB0aGF0IHRoZSB0ZXh0 IGlzIGluIHN5bmMsIGl0IG1ha2VzIG1lIHdvbmRlciB3aHkgaXQgbmVlZHMgdG8gYmU8YnI+bWVu dGlvbmVkIHR3aWNlIChhbmQgbm90IGp1c3QgaW4gdGhlIHJlcXVpcmVtZW50cyBzZWN0aW9uKS48 YnI+PGJyPi4uLjxicj4mZ3Q7IDxicj4mZ3Q7Rm9yIFNFQy1SRVEtMDUsIEkgcmUtcmVhZCBpdCBu b3cgYW5kIGl0IGlzIHJlZHVuZGFudC4mbmJzcDsgSSBjaGFuZ2VkIHRvOjxicj4mZ3Q7PGJyPiZn dDtTRUMtUkVRLTA1OiBJZGVudGlmaWVyIGRpc3RyaWJ1dGlvbiBhbmQgdGhlIGxvYWRpbmcgb2Yg dGhlc2UgaWRlbnRpZmllcnM8YnI+Jmd0O2ludG8gSTJSUyBhZ2VudDxicj4mZ3Q7IGFuZCBJMlJT IENsaWVudCBTSE9VTEQgb2NjdXIgb3V0c2lkZSB0aGUgSTJSUyBwcm90b2NvbCBwcmlvciB0byB0 aGU8YnI+Jmd0OyBJMlJTIHByb3RvY29sIGVzdGFibGlzaGluZyBhIGNvbm5lY3Rpb24gYmV0d2Vl biBJMlJTIGNsaWVudCBhbmQgSTJSUzxicj4mZ3Q7YWdlbnQuPGJyPiZndDs8YnI+Jmd0OyAoT25l IG1lY2hhbmlzbSBzdWNoIG1lY2hhbmlzbSBpcyBBQUEgcHJvdG9jb2xzLik8YnI+Jmd0Ozxicj4m Z3Q7V2hhdCBkbyB5b3UgdGhpbms/PGJyPjxicj5Mb29rcyBnb29kIHRvIG1lLjxicj48YnI+VGhh bmtzITxicj48YnI+QWx2YXJvLjxicj48YnI+PC9ib2R5PjwvaHRtbD4= ----_com.samsung.android.email_1243475407913100-- From nobody Thu Aug 18 06:01:45 2016 Return-Path: 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 B62C212DDD2; Thu, 18 Aug 2016 06:01:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.738 X-Spam-Level: * X-Spam-Status: No, score=1.738 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, RDNS_NONE=0.793] autolearn=no 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 VzpqS3kM8yqR; Thu, 18 Aug 2016 06:01:41 -0700 (PDT) Received: from hickoryhill-consulting.com (unknown [50.245.122.97]) (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 4FEE212DDA8; Thu, 18 Aug 2016 06:01:25 -0700 (PDT) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=174.124.167.170; From: "Susan Hares" To: "'Juergen Schoenwaelder'" References: <147146974235.23784.4389421535496134619.idtracker@ietfa.amsl.com> <013b01d1f8ee$31fa09b0$95ee1d10$@ndzh.com> <20160818073203.GA4338@elstar.local> <04b501d1f949$116c63e0$34452ba0$@ndzh.com> <20160818121405.GA5282@elstar.local> In-Reply-To: <20160818121405.GA5282@elstar.local> Date: Thu, 18 Aug 2016 09:00:14 -0400 Message-ID: <051301d1f950$7739c670$65ad5350$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIa7Lz6VgZw6h2A0uGNzOgAA2Ic8QJ/RF5yARxv/coCD6d0AAIDKkFTn39SoPA= Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: i2rs@ietf.org, i2rs-chairs@ietf.org, 'Kathleen Moriarty' , 'The IESG' , jhaas@pfrc.org, 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Aug 2016 13:01:45 -0000 Juergen: Yes, we seem to disagree on the value of making it hardwired in the model. For me, the value is a common understanding of deployment distribution such as the route-views. Since the operators argued strongly for this point, I think the best idea is to get it working in code and then see if the deployment matches the requests. Sue -----Original Message----- From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Juergen Schoenwaelder Sent: Thursday, August 18, 2016 8:14 AM To: Susan Hares Cc: i2rs@ietf.org; i2rs-chairs@ietf.org; 'Kathleen Moriarty'; 'The IESG'; jhaas@pfrc.org; 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) Sue, I still do not see why the 'mode of exposure' of data benefits from being hard-wired in the data model. For me, it is a situational and deployment specific question. But I shut up here since I aired this concern before (and we simply seem to disagree). /js On Thu, Aug 18, 2016 at 08:07:18AM -0400, Susan Hares wrote: > Juergen: > > My example is the looking glass servers for the BGP route views > project > (http://www.routeviews.org/) or a route indicating the presence of a > web-server that is public. For the BGP I2RS route, a yang model could > replace the looking glass function, and provide events for these looking > glass functions. For the web-server route, an event be sent when that > one route is added. > > Sue > > > -----Original Message----- > From: Juergen Schoenwaelder > [mailto:j.schoenwaelder@jacobs-university.de] > Sent: Thursday, August 18, 2016 3:32 AM > To: Susan Hares > Cc: 'Kathleen Moriarty'; 'The IESG'; jhaas@pfrc.org; i2rs@ietf.org; > i2rs-chairs@ietf.org; > 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 Wed, Aug 17, 2016 at 09:16:48PM -0400, Susan Hares wrote: > > -------------------------------------------------------------------- > > -- > > COMMENT: > > -------------------------------------------------------------------- > > -- > > > > > Section 3: > > > Can you clarify the second to last sentence? Do you mean there > > > are > sections that indicate an insecure transport should be used? > > > I2RS allows the use of an > > > insecure transport for portions of data models that clearly > > > indicate insecure transport. > > > > > Perhaps: > > > I2RS allows the use of an > > > insecure transport for portions of data models that clearly > > > indicate the use of an insecure transport. > > I still wonder how a data model writer can reasonably decide whether a > piece of information can be shipped safely over an insecure transport > since this decision often depends on the specifics of a deployment situation. > > /js > > PS: I hope we do not end up with defining data multiple times (once > for insecure transport and once for secured transports). > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 _______________________________________________ i2rs mailing list i2rs@ietf.org https://www.ietf.org/mailman/listinfo/i2rs From nobody Thu Aug 18 06:05:34 2016 Return-Path: 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 B117F12DDED; Thu, 18 Aug 2016 06:05:27 -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 08crKAppKD7K; Thu, 18 Aug 2016 06:05:23 -0700 (PDT) Received: from mail-ua0-x22b.google.com (mail-ua0-x22b.google.com [IPv6:2607:f8b0:400c:c08::22b]) (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 9B20512DDBA; Thu, 18 Aug 2016 06:05:18 -0700 (PDT) Received: by mail-ua0-x22b.google.com with SMTP id 97so26598899uav.3; Thu, 18 Aug 2016 06:05:18 -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; bh=Dq5C77UwO3RMr86a66Bfj+KNffhXsrSXIu0WdKOfej0=; b=L5gaWz+d4W+xfAE478Bv096Wl9WxcOgpNaLV/kxYsP2myK06cxtD228gGKUkKeem++ h4dzf1xo+nfvE5yhDzvq7fV18dwd2hw7Qfvu0I64S/UsMRhDHSaTkgsDBk8uHPDVGE+u kQTe/i/UZByo6CalIVzSxbkprKLKPsrIUiWWteEsas/Jz5PrYqCHWMfr8GTIc+WOMIKX nTiZCMk08KMhQGbMr18yMIpj2/KCYAwebZ27a2WezHiU74EBwe/p27b0BDfuu3EJUPmr uWug5Z3BKTPzF9i82CluPiu7Kbu0kzrdKJedqjz5qiEuVYAtCQNVqMNur9dYrLJZkeaO XE8g== 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; bh=Dq5C77UwO3RMr86a66Bfj+KNffhXsrSXIu0WdKOfej0=; b=SvW8ytBDpcrDCnvBNFNEUx1hQAh3T+zBfQx7vOBtozHSrWrI7BINf45m/LkDMCQRta Dx6dbxJGvS8WoAdgSREStKXNot0Cb+Jn3KLktYC5smlhkIQbnMPim/Gik3mjSbLuRVC8 Eula7nerxHpxRWOiHjyo/kVy845WK139etw57x1yVtn9wFDUn/gSXa7F3lyjTKevQd0k Zra3cZXfcwE5JEm4oFjVrJxU/oS2VTjqGwUnYhXDY+eS9JlRWzxtXDJCrJ78GAu61clE hv7OeCCQER7o0e7NmDqivyigVEHJS6+N5J/Weeqh0tvDcl8RncIvT7Cx9M0ZofVIbBkS z/ng== X-Gm-Message-State: AEkoouvxM1kIkfdnHo+7T7xaeStMsIQUTTch+BohldD/02KZWnc+tZQdYFLF3KX8MDRm5ntNBZKOrpJkHboNCA== X-Received: by 10.31.157.70 with SMTP id g67mr849924vke.39.1471525517760; Thu, 18 Aug 2016 06:05:17 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.1.228 with HTTP; Thu, 18 Aug 2016 06:05:17 -0700 (PDT) In-Reply-To: <20160818121405.GA5282@elstar.local> References: <147146974235.23784.4389421535496134619.idtracker@ietfa.amsl.com> <013b01d1f8ee$31fa09b0$95ee1d10$@ndzh.com> <20160818073203.GA4338@elstar.local> <04b501d1f949$116c63e0$34452ba0$@ndzh.com> <20160818121405.GA5282@elstar.local> From: Kathleen Moriarty Date: Thu, 18 Aug 2016 09:05:17 -0400 Message-ID: To: Juergen Schoenwaelder , Susan Hares , i2rs@ietf.org, i2rs-chairs@ietf.org, Kathleen Moriarty , The IESG , Jeffrey Haas , draft-ietf-i2rs-protocol-security-requirements@ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Aug 2016 13:05:28 -0000 On Thu, Aug 18, 2016 at 8:14 AM, Juergen Schoenwaelder wrote: > Sue, > > I still do not see why the 'mode of exposure' of data benefits from > being hard-wired in the data model. For me, it is a situational and > deployment specific question. But I shut up here since I aired this > concern before (and we simply seem to disagree). I agree with Juergen on this point and the example provided seems to go in line with his line of reason. The decision could be made based on the data by the operator and not the data model. This is what typically happens and is more flexible to cover confidentiality and privacy decisions that do vary by situation. I'll go back through the other responses to my questions now. Thanks, Kathleen > > /js > > On Thu, Aug 18, 2016 at 08:07:18AM -0400, Susan Hares wrote: >> Juergen: >> >> My example is the looking glass servers for the BGP route views project >> (http://www.routeviews.org/) or a route indicating the presence of a >> web-server that is public. For the BGP I2RS route, a yang model could >> replace the looking glass function, and provide events for these looking >> glass functions. For the web-server route, an event be sent when that >> one route is added. >> >> Sue >> >> >> -----Original Message----- >> From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de] >> Sent: Thursday, August 18, 2016 3:32 AM >> To: Susan Hares >> Cc: 'Kathleen Moriarty'; 'The IESG'; jhaas@pfrc.org; i2rs@ietf.org; >> i2rs-chairs@ietf.org; >> 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 Wed, Aug 17, 2016 at 09:16:48PM -0400, Susan Hares wrote: >> > ---------------------------------------------------------------------- >> > COMMENT: >> > ---------------------------------------------------------------------- >> > >> > > Section 3: >> > > Can you clarify the second to last sentence? Do you mean there are >> sections that indicate an insecure transport should be used? >> > > I2RS allows the use of an >> > > insecure transport for portions of data models that clearly >> > > indicate insecure transport. >> > >> > > Perhaps: >> > > I2RS allows the use of an >> > > insecure transport for portions of data models that clearly >> > > indicate the use of an insecure transport. >> >> I still wonder how a data model writer can reasonably decide whether a piece >> of information can be shipped safely over an insecure transport since this >> decision often depends on the specifics of a deployment situation. >> >> /js >> >> PS: I hope we do not end up with defining data multiple times (once >> for insecure transport and once for secured transports). >> >> -- >> Juergen Schoenwaelder Jacobs University Bremen gGmbH >> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany >> Fax: +49 421 200 3103 >> >> _______________________________________________ >> i2rs mailing list >> i2rs@ietf.org >> https://www.ietf.org/mailman/listinfo/i2rs > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 -- Best regards, Kathleen From nobody Thu Aug 18 06:06:24 2016 Return-Path: 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 CE0BD12DDE6; Thu, 18 Aug 2016 06:06:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.447 X-Spam-Level: X-Spam-Status: No, score=-5.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.247] 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 iIKTIuLPrby5; Thu, 18 Aug 2016 06:06:15 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B8D8012DDC6; Thu, 18 Aug 2016 06:06:02 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 88B408F9; Thu, 18 Aug 2016 15:06:01 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.205]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id rARV_szcFUpW; Thu, 18 Aug 2016 15:05:59 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Thu, 18 Aug 2016 15:06:00 +0200 (CEST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 5862E200A7; Thu, 18 Aug 2016 15:06:00 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id hvFzGhTntwcB; Thu, 18 Aug 2016 15:05:58 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 15D5F200A5; Thu, 18 Aug 2016 15:05:58 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id F32CF3C25113; Thu, 18 Aug 2016 15:05:55 +0200 (CEST) Date: Thu, 18 Aug 2016 15:05:55 +0200 From: Juergen Schoenwaelder To: Susan Hares Message-ID: <20160818130555.GA5366@elstar.local> Mail-Followup-To: Susan Hares , i2rs@ietf.org, i2rs-chairs@ietf.org, 'Kathleen Moriarty' , 'The IESG' , jhaas@pfrc.org, draft-ietf-i2rs-protocol-security-requirements@ietf.org References: <147146974235.23784.4389421535496134619.idtracker@ietfa.amsl.com> <013b01d1f8ee$31fa09b0$95ee1d10$@ndzh.com> <20160818073203.GA4338@elstar.local> <04b501d1f949$116c63e0$34452ba0$@ndzh.com> <20160818121405.GA5282@elstar.local> <051301d1f950$7739c670$65ad5350$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <051301d1f950$7739c670$65ad5350$@ndzh.com> User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Cc: i2rs@ietf.org, i2rs-chairs@ietf.org, 'Kathleen Moriarty' , 'The IESG' , jhaas@pfrc.org, 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 Reply-To: Juergen Schoenwaelder List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Aug 2016 13:06:17 -0000 I just do not know on which basis a data model writer can decide whether a data object can be exposed in an unprotected way. How are YANG doctors going to review this? How are security directorate people going to judge this? But as promised, I leave (still puzzled) now. /js On Thu, Aug 18, 2016 at 09:00:14AM -0400, Susan Hares wrote: > Juergen: > > Yes, we seem to disagree on the value of making it hardwired in the model. > For me, the value is a common understanding of deployment distribution such > as the route-views. Since the operators argued strongly for this point, I > think the best idea is to get it working in code and then see if the > deployment matches the requests. > > Sue > > -----Original Message----- > From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Juergen Schoenwaelder > Sent: Thursday, August 18, 2016 8:14 AM > To: Susan Hares > Cc: i2rs@ietf.org; i2rs-chairs@ietf.org; 'Kathleen Moriarty'; 'The IESG'; > jhaas@pfrc.org; 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) > > Sue, > > I still do not see why the 'mode of exposure' of data benefits from being > hard-wired in the data model. For me, it is a situational and deployment > specific question. But I shut up here since I aired this concern before (and > we simply seem to disagree). > > /js > > On Thu, Aug 18, 2016 at 08:07:18AM -0400, Susan Hares wrote: > > Juergen: > > > > My example is the looking glass servers for the BGP route views > > project > > (http://www.routeviews.org/) or a route indicating the presence of a > > web-server that is public. For the BGP I2RS route, a yang model could > > replace the looking glass function, and provide events for these looking > > glass functions. For the web-server route, an event be sent when that > > one route is added. > > > > Sue > > > > > > -----Original Message----- > > From: Juergen Schoenwaelder > > [mailto:j.schoenwaelder@jacobs-university.de] > > Sent: Thursday, August 18, 2016 3:32 AM > > To: Susan Hares > > Cc: 'Kathleen Moriarty'; 'The IESG'; jhaas@pfrc.org; i2rs@ietf.org; > > i2rs-chairs@ietf.org; > > 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 Wed, Aug 17, 2016 at 09:16:48PM -0400, Susan Hares wrote: > > > -------------------------------------------------------------------- > > > -- > > > COMMENT: > > > -------------------------------------------------------------------- > > > -- > > > > > > > Section 3: > > > > Can you clarify the second to last sentence? Do you mean there > > > > are > > sections that indicate an insecure transport should be used? > > > > I2RS allows the use of an > > > > insecure transport for portions of data models that clearly > > > > indicate insecure transport. > > > > > > > Perhaps: > > > > I2RS allows the use of an > > > > insecure transport for portions of data models that clearly > > > > indicate the use of an insecure transport. > > > > I still wonder how a data model writer can reasonably decide whether a > > piece of information can be shipped safely over an insecure transport > > since this decision often depends on the specifics of a deployment > situation. > > > > /js > > > > PS: I hope we do not end up with defining data multiple times (once > > for insecure transport and once for secured transports). > > > > -- > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > > Fax: +49 421 200 3103 > > > > _______________________________________________ > > i2rs mailing list > > i2rs@ietf.org > > https://www.ietf.org/mailman/listinfo/i2rs > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs > -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Thu Aug 18 06:06:39 2016 Return-Path: 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 80F4112DDEF; Thu, 18 Aug 2016 06:06: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 ZwOAjbzFc7Wb; Thu, 18 Aug 2016 06:06:15 -0700 (PDT) Received: from mail-ua0-x22f.google.com (mail-ua0-x22f.google.com [IPv6:2607:f8b0:400c:c08::22f]) (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 2D07D12DDE2; Thu, 18 Aug 2016 06:06:03 -0700 (PDT) Received: by mail-ua0-x22f.google.com with SMTP id 97so26633633uav.3; Thu, 18 Aug 2016 06:06:03 -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; bh=5kMVXY9V5FTBE7tO/zn6AiMD7QGtEny5uCfogk3KOG8=; b=pVF2bF3vTe3jBCTlQprmRYEwKy9JhVStGHYcAGbvmX1mQ9wfP37go1+SvFuYDmaGAX MaBDCeYSDUDnP/uJZOy/6wCSg3vbMgvahlGobwr0Jwpv/azIW3RGk/cevcgaGs/JwC3b 0423Ljyhd8ZLyqiSP5RzqXZQj3XH5S3dAQaQ/xHQAPE+1yutRT7bj0FN6Nic1/kA3pOH 3nAfMz2KYd2q5WipN3XrOIaGZWLjKPWwejnkoEdoT9Lpe9iK4Nbsk9g7Oukw3GQM+YK2 n77nDObloJnyfwEqTYCHY6w0M4Wbh2tGnGy0diarC0SfrGVyUw0fueuCSewthfGxKYrZ ssAA== 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; bh=5kMVXY9V5FTBE7tO/zn6AiMD7QGtEny5uCfogk3KOG8=; b=TtQvLWf5lAvlx5sQU3UJp8SePeeHuBQknrynrzyT48XhgvQUjguk0of1bojP896JA+ s03RdnD273lM060SM5Q7WPiWluU3EDy0vf1e+wRSXGdqs0pp3c83t+lUI4y+ZKh3E3oR 6VNx51qqww2s3gQWiWOiMrdzbFL+0aUtNLhIECuwDSNPTooVi5eaTHSw8p20KzU7SlMy CEVRL6q7k518iyyUL6+FNSLRqVAx4IJvSdhB+Yxrh5wOrGxTIRSbyNYEeGPfDpq7WG/c aFL15nq43111yjrVo51V0PlPTbySm4AdKM3aHfY1o37ZiwI9x2V27UOwlOQQsiPiZsDp ovQA== X-Gm-Message-State: AEkoouuWKjlCikDZaUEEaxPxBk1/+NM4sywrf7n9PxVjK7IVTVbb56yEkhAZHnmkvbDnnFkxnksr6l/GtuUhxQ== X-Received: by 10.176.83.98 with SMTP id y31mr1035241uay.88.1471525562207; Thu, 18 Aug 2016 06:06:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.1.228 with HTTP; Thu, 18 Aug 2016 06:06:01 -0700 (PDT) In-Reply-To: <051301d1f950$7739c670$65ad5350$@ndzh.com> References: <147146974235.23784.4389421535496134619.idtracker@ietfa.amsl.com> <013b01d1f8ee$31fa09b0$95ee1d10$@ndzh.com> <20160818073203.GA4338@elstar.local> <04b501d1f949$116c63e0$34452ba0$@ndzh.com> <20160818121405.GA5282@elstar.local> <051301d1f950$7739c670$65ad5350$@ndzh.com> From: Kathleen Moriarty Date: Thu, 18 Aug 2016 09:06:01 -0400 Message-ID: To: Susan Hares Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: i2rs@ietf.org, Juergen Schoenwaelder , i2rs-chairs@ietf.org, The IESG , Jeffrey Haas , 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Aug 2016 13:06:17 -0000 On Thu, Aug 18, 2016 at 9:00 AM, Susan Hares wrote: > Juergen: > > Yes, we seem to disagree on the value of making it hardwired in the model. > For me, the value is a common understanding of deployment distribution such > as the route-views. Since the operators argued strongly for this point, I > think the best idea is to get it working in code and then see if the > deployment matches the requests. This sounds like more of an experiment, doesn't it? Thanks, Kathleen > > Sue > > -----Original Message----- > From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Juergen Schoenwaelder > Sent: Thursday, August 18, 2016 8:14 AM > To: Susan Hares > Cc: i2rs@ietf.org; i2rs-chairs@ietf.org; 'Kathleen Moriarty'; 'The IESG'; > jhaas@pfrc.org; 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) > > Sue, > > I still do not see why the 'mode of exposure' of data benefits from being > hard-wired in the data model. For me, it is a situational and deployment > specific question. But I shut up here since I aired this concern before (and > we simply seem to disagree). > > /js > > On Thu, Aug 18, 2016 at 08:07:18AM -0400, Susan Hares wrote: >> Juergen: >> >> My example is the looking glass servers for the BGP route views >> project >> (http://www.routeviews.org/) or a route indicating the presence of a >> web-server that is public. For the BGP I2RS route, a yang model could >> replace the looking glass function, and provide events for these looking >> glass functions. For the web-server route, an event be sent when that >> one route is added. >> >> Sue >> >> >> -----Original Message----- >> From: Juergen Schoenwaelder >> [mailto:j.schoenwaelder@jacobs-university.de] >> Sent: Thursday, August 18, 2016 3:32 AM >> To: Susan Hares >> Cc: 'Kathleen Moriarty'; 'The IESG'; jhaas@pfrc.org; i2rs@ietf.org; >> i2rs-chairs@ietf.org; >> 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 Wed, Aug 17, 2016 at 09:16:48PM -0400, Susan Hares wrote: >> > -------------------------------------------------------------------- >> > -- >> > COMMENT: >> > -------------------------------------------------------------------- >> > -- >> > >> > > Section 3: >> > > Can you clarify the second to last sentence? Do you mean there >> > > are >> sections that indicate an insecure transport should be used? >> > > I2RS allows the use of an >> > > insecure transport for portions of data models that clearly >> > > indicate insecure transport. >> > >> > > Perhaps: >> > > I2RS allows the use of an >> > > insecure transport for portions of data models that clearly >> > > indicate the use of an insecure transport. >> >> I still wonder how a data model writer can reasonably decide whether a >> piece of information can be shipped safely over an insecure transport >> since this decision often depends on the specifics of a deployment > situation. >> >> /js >> >> PS: I hope we do not end up with defining data multiple times (once >> for insecure transport and once for secured transports). >> >> -- >> Juergen Schoenwaelder Jacobs University Bremen gGmbH >> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany >> Fax: +49 421 200 3103 >> >> _______________________________________________ >> i2rs mailing list >> i2rs@ietf.org >> https://www.ietf.org/mailman/listinfo/i2rs > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs > -- Best regards, Kathleen From nobody Thu Aug 18 06:17:59 2016 Return-Path: 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 EB59E12D747; Thu, 18 Aug 2016 06:17:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.738 X-Spam-Level: * X-Spam-Status: No, score=1.738 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, RDNS_NONE=0.793] autolearn=no 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 nJTkQGgsBCuK; Thu, 18 Aug 2016 06:17:56 -0700 (PDT) Received: from hickoryhill-consulting.com (unknown [50.245.122.97]) (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 CB91B12DE19; Thu, 18 Aug 2016 06:17:55 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=174.124.167.170; From: "Susan Hares" To: "'Juergen Schoenwaelder'" References: <147146974235.23784.4389421535496134619.idtracker@ietfa.amsl.com> <013b01d1f8ee$31fa09b0$95ee1d10$@ndzh.com> <20160818073203.GA4338@elstar.local> <04b501d1f949$116c63e0$34452ba0$@ndzh.com> <20160818121405.GA5282@elstar.local> <051301d1f950$7739c670$65ad5350$@ndzh.com> <20160818130555.GA5366@elstar.local> In-Reply-To: <20160818130555.GA5366@elstar.local> Date: Thu, 18 Aug 2016 09:16:44 -0400 Message-ID: <051701d1f952$c4ae0b30$4e0a2190$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIa7Lz6VgZw6h2A0uGNzOgAA2Ic8QJ/RF5yARxv/coCD6d0AAIDKkFTAYlI9/gCaK/wXJ9fxVgQ Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: i2rs@ietf.org, i2rs-chairs@ietf.org, 'Kathleen Moriarty' , 'The IESG' , jhaas@pfrc.org, 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Aug 2016 13:17:58 -0000 Juergen and Kathleen: Let me proceed with two examples: BGP route views data model and the event for the web-service data. The content of these data models are designated as exposed to public. The routing system only populates the proposed BGP route views data model with the data destined for the BGP looking glass. The policy on the routing system indicates what information gets transferred. The data model is completely available to the public. The Yang Doctors are going to review this by seeing the whole model is public and available via non-secure means. The security people are going to review this seeing that the whole model is public, and available via an unprotect means. The fact the data model is all public should simplify the review. An event from the I2RS RIB that a web-service route is up is the second case. The I2RS RIB has an event based on policy that indicates a web-service route is up. The yang-1.1 doctors must review the content of the event text to see it does not break privacy or provide too much information The event mechanisms will need to work over secure transport and insecure transport. Most of the data will go over the secure transport event stream. However, a small amount of information may go over the insecure transport stream. First, let me know if my use cases are understandable. Second, let me know if you disagree with this use cases. Fyi - IESG approved the architecture with the insecure stream. Sue -----Original Message----- From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de] Sent: Thursday, August 18, 2016 9:06 AM To: Susan Hares Cc: i2rs@ietf.org; i2rs-chairs@ietf.org; 'Kathleen Moriarty'; 'The IESG'; jhaas@pfrc.org; 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) I just do not know on which basis a data model writer can decide whether a data object can be exposed in an unprotected way. How are YANG doctors going to review this? How are security directorate people going to judge this? But as promised, I leave (still puzzled) now. /js On Thu, Aug 18, 2016 at 09:00:14AM -0400, Susan Hares wrote: > Juergen: > > Yes, we seem to disagree on the value of making it hardwired in the model. > For me, the value is a common understanding of deployment distribution such > as the route-views. Since the operators argued strongly for this point, I > think the best idea is to get it working in code and then see if the > deployment matches the requests. > > Sue > > -----Original Message----- > From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Juergen > Schoenwaelder > Sent: Thursday, August 18, 2016 8:14 AM > To: Susan Hares > Cc: i2rs@ietf.org; i2rs-chairs@ietf.org; 'Kathleen Moriarty'; 'The > IESG'; jhaas@pfrc.org; > 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) > > Sue, > > I still do not see why the 'mode of exposure' of data benefits from > being hard-wired in the data model. For me, it is a situational and > deployment specific question. But I shut up here since I aired this > concern before (and we simply seem to disagree). > > /js > > On Thu, Aug 18, 2016 at 08:07:18AM -0400, Susan Hares wrote: > > Juergen: > > > > My example is the looking glass servers for the BGP route views > > project > > (http://www.routeviews.org/) or a route indicating the presence of a > > web-server that is public. For the BGP I2RS route, a yang model could > > replace the looking glass function, and provide events for these looking > > glass functions. For the web-server route, an event be sent when that > > one route is added. > > > > Sue > > > > > > -----Original Message----- > > From: Juergen Schoenwaelder > > [mailto:j.schoenwaelder@jacobs-university.de] > > Sent: Thursday, August 18, 2016 3:32 AM > > To: Susan Hares > > Cc: 'Kathleen Moriarty'; 'The IESG'; jhaas@pfrc.org; i2rs@ietf.org; > > i2rs-chairs@ietf.org; > > 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 Wed, Aug 17, 2016 at 09:16:48PM -0400, Susan Hares wrote: > > > ------------------------------------------------------------------ > > > -- > > > -- > > > COMMENT: > > > ------------------------------------------------------------------ > > > -- > > > -- > > > > > > > Section 3: > > > > Can you clarify the second to last sentence? Do you mean there > > > > are > > sections that indicate an insecure transport should be used? > > > > I2RS allows the use of an > > > > insecure transport for portions of data models that clearly > > > > indicate insecure transport. > > > > > > > Perhaps: > > > > I2RS allows the use of an > > > > insecure transport for portions of data models that clearly > > > > indicate the use of an insecure transport. > > > > I still wonder how a data model writer can reasonably decide whether > > a piece of information can be shipped safely over an insecure > > transport since this decision often depends on the specifics of a > > deployment > situation. > > > > /js > > > > PS: I hope we do not end up with defining data multiple times (once > > for insecure transport and once for secured transports). > > > > -- > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > > Fax: +49 421 200 3103 > > > > _______________________________________________ > > i2rs mailing list > > i2rs@ietf.org > > https://www.ietf.org/mailman/listinfo/i2rs > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs > -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Thu Aug 18 06:18:38 2016 Return-Path: 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 F2E1B12D6B9; Thu, 18 Aug 2016 06:18:31 -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 D_3Zg4rz_jy8; Thu, 18 Aug 2016 06:18:29 -0700 (PDT) Received: from mail-ua0-x236.google.com (mail-ua0-x236.google.com [IPv6:2607:f8b0:400c:c08::236]) (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 2BC4612DE16; Thu, 18 Aug 2016 06:18:20 -0700 (PDT) Received: by mail-ua0-x236.google.com with SMTP id 97so27212928uav.3; Thu, 18 Aug 2016 06:18:20 -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; bh=emJbhCLkWOOT4BKVosRYdL+/xv6dNh2WL/L9bW34y4c=; b=n9E0Vvb0XYq+PzY5tHz84f4/N3NBUEqym9mNYDNwtVaEeaGnLxIEuyXcUTa4gjsiha v/kOp/X0rcO/u1TYgCtL5W8MNt46Hwlr7HpwzdIMo1bRsGLp0c8/PX/hYb/uz3m7EeJO 2QeaRl9aa8tHzQKplLqE/pEIyhhm2I9v6qtsqvMEXEZQflK9ogLyI1GJnxkXfwsddQED IBbgAEYlwDbamA2SpoGtwlxaA8fPEHo34Ak0BVgFxaleJLZ0/MHhib+YjkucINwg1F+a lvcdz+McP6yrIyZGFRV1Ik4mFYVAmsfykIj/qlTwf0spuKIZzdRCelZ8Lbz5rxtRUERh E/dg== 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; bh=emJbhCLkWOOT4BKVosRYdL+/xv6dNh2WL/L9bW34y4c=; b=cmaB14zvzCfwKo9vdyyZ8UC6NxDOgVOm1lSzy0aYLePfZDS/Txv/k7qEbms3CjhcAb Hi68iAUlpAOMrwfuqOB1kh2Ze37zT65eLHFu1kwoLBGEMxyImBfia4cc/jIYGemOta2P 1M2Y2o+liA8eMZpW7A5WCs0YmmwLYhdDvak4ozW9U0SxUpOnOZ8zpPOshBWI5VkxM5DM fI24PpepsSMeEdmqjAPCSPHxIhs5hOQWCEoz7+B0xS/kanXMZ5LR+o4sN4qRwZADJDdr 5Rmd9b7dQHPfdgq5l1II6Im/xddC4anM9/028Ks9FNWW0qsXfxaExpQxHMtKJSXbAU89 IH3w== X-Gm-Message-State: AEkoouvn2u8xahQtV30Bqt2+thpd8ZgCZVOy/uSMUMRnXcS/jyIjCICO3eGLGLoVC2IEJzFy6/ahsZEtzWhr8Q== X-Received: by 10.159.53.1 with SMTP id o1mr996318uao.15.1471526299283; Thu, 18 Aug 2016 06:18:19 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.1.228 with HTTP; Thu, 18 Aug 2016 06:18:18 -0700 (PDT) In-Reply-To: <013b01d1f8ee$31fa09b0$95ee1d10$@ndzh.com> References: <147146974235.23784.4389421535496134619.idtracker@ietfa.amsl.com> <013b01d1f8ee$31fa09b0$95ee1d10$@ndzh.com> From: Kathleen Moriarty Date: Thu, 18 Aug 2016 09:18:18 -0400 Message-ID: To: Susan Hares Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Jeffrey Haas , i2rs@ietf.org, The IESG , i2rs-chairs@ietf.org, 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Aug 2016 13:18:32 -0000 Hi Sue, Thanks for your quick response. inline On Wed, Aug 17, 2016 at 9:16 PM, Susan Hares wrote: > Kathleen: > > Thank you for your comments. Please see the inline comments below. I will be uploading a version -08.txt that will resolve some of these comments. > > Sue > > -----Original Message----- > From: Kathleen Moriarty [mailto:Kathleen.Moriarty.ietf@gmail.com] > Sent: Wednesday, August 17, 2016 5:36 PM > To: The IESG > Cc: draft-ietf-i2rs-protocol-security-requirements@ietf.org; Jeffrey Haas; i2rs-chairs@ietf.org; jhaas@pfrc.org; i2rs@ietf.org > Subject: Kathleen Moriarty's Discuss on draft-ietf-i2rs-protocol-security-requirements-07: (with DISCUSS and COMMENT) > > Kathleen Moriarty has entered the following ballot position for > draft-ietf-i2rs-protocol-security-requirements-07: Discuss > > When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-i2rs-protocol-security-requirements/ > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > Thanks for your work on this draft. There may be some overlap in points, I tried to minimize them... > ---- >>Section 3.1: >> >>I don't see any actual requirements for mutual authentication in this section, just requirements for identifiers. Did I miss something? > > No, there are no additional requirements. We only have requirements for identifiers. Do you have a suggestion for improved language. >From your response & Joel's, I see bullet #2 is the only one that calls out the need for mutual authentication and it just states that with no additional details. That is fine, but the subject for section 3.1 should be something more like authentication and identifiers to represent the content better. > >> Are all mutual auth schemes in scope? Are there any considerations for mutual authentication (passwords, keys, etc.)? > > All mutual identification schemes are in scope. Is there a reason we should restrict the mutual authentication schemes to a subset. You don't have to, but the header of the section makes me think this is going to happen in the section. Maybe setting a baseline would be good if possible. Not using passwords - so a secure form of mutual authentication would be good if the requirements are only high level. > > ---- >>I share the same concern as others for secure transport, but since there are already discusses on that, I have one comment to add to the existing discusses below. > > You have a concern regarding the secure transport? KM: Yes, the wording that allows for insecure transport. Same concern expressed by other ADs. My understanding is that other people had a concern regarding the insecure transport. I have provide an example of the BGP data feed utilized by http://www.routeviews.org/ project. KM: Aren't you concerned about the integrity of this data? > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > >> Section 3: >> Can you clarify the second to last sentence? Do you mean there are sections that indicate an insecure transport should be used? >> I2RS allows the use of an >> insecure transport for portions of data models that clearly indicate >> insecure transport. > >> Perhaps: >> I2RS allows the use of an >> insecure transport for portions of data models that clearly indicate the use of an >> insecure transport. > > Changed to : > > I2RS allows the use of an insecure transport for portions of data models that clearly indicate > the use of an insecure transport. Operators deploying I2RS must determine if they want to populate and > deploy the portions of the data model which use insecure transports. > I don't agree with the data model setting the transport requirements. If this is done, it should be an experiment IMO. > > ---- >> Section 3.2 >> I agree with Alissa's discuss point on the following sentence (that could also be reworded a bit): >> A non-secure transport can be 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. > > I would appreciate a recommended set of text or additional explanation on what you would like to see in rewording. I'll have to look through Alissa's discuss, but isn't integrity a concern if confidentiality and privacy are not? I'm sure once this type of text is altered and used to make important decisions, this will come back to bite us. > > ---- >>Section 3.4: In the following text: >> SEC-REQ-15: The integrity that the message data is not repeated means >> that I2RS client to I2RS agent transport SHOULD protect against >> replay attack > >>I'm not sure why this just doesn't say: >> SEC-REQ-15: I2RS client to I2RS agent transport SHOULD protect against > > replay attack >>The additional text doesn't add anything and sounds a bit confusing. > > Sue: Is this ok. It will be changed Thanks. > > ---- > Nit: > > I'm not sure these definitions add any value as they seem to restate the term defined: > >> I2RS protocol data integrity >> >> The transfer of data via the I2RS protocol has the property of >> data integrity described in [RFC4949]. > > Deleted > > >> I2RS component protocols >> >> Protocols which are combined to create the I2RS protocol. > > Please suggest alternative text for this section. I think it is self explanatory. But if that's just me, leave the definition in. > > ----- > >> I also agree that the definitions from 4949 should be removed. >> Thank you in advance. > > These definition have been removed. I will provide feedback if this removal cause problems in the creation of the protocol. Thank you, Kathleen > -- Best regards, Kathleen From nobody Thu Aug 18 06:21:32 2016 Return-Path: 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 E1FF412DE24; Thu, 18 Aug 2016 06:21:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.738 X-Spam-Level: * X-Spam-Status: No, score=1.738 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, RDNS_NONE=0.793] autolearn=no 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 Ajr_xv3xyzzi; Thu, 18 Aug 2016 06:21:27 -0700 (PDT) Received: from hickoryhill-consulting.com (unknown [50.245.122.97]) (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 4D8E412DE34; Thu, 18 Aug 2016 06:21:18 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=174.124.167.170; From: "Susan Hares" To: "'Kathleen Moriarty'" References: <147146974235.23784.4389421535496134619.idtracker@ietfa.amsl.com> <013b01d1f8ee$31fa09b0$95ee1d10$@ndzh.com> <20160818073203.GA4338@elstar.local> <04b501d1f949$116c63e0$34452ba0$@ndzh.com> <20160818121405.GA5282@elstar.local> <051301d1f950$7739c670$65ad5350$@ndzh.com> In-Reply-To: Date: Thu, 18 Aug 2016 09:20:09 -0400 Message-ID: <051901d1f953$3f458ee0$bdd0aca0$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIa7Lz6VgZw6h2A0uGNzOgAA2Ic8QJ/RF5yARxv/coCD6d0AAIDKkFTAYlI9/gCVrmr1p9gV/+A Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: i2rs@ietf.org, 'Juergen Schoenwaelder' , i2rs-chairs@ietf.org, 'The IESG' , 'Jeffrey Haas' , 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Aug 2016 13:21:30 -0000 Kathleen:=20 Hmm. If this sounds like an experiment, then all new protocols are an = experiment. =20 This is a catch-22 - we are setting requirements for a re-use protocol = that has not be designed yet. We are working on prototypes, but these = prototypes cannot match the final work until we agree upon a set of = requirements for the protocol. =20 Sue Hares=20 -----Original Message----- From: Kathleen Moriarty [mailto:kathleen.moriarty.ietf@gmail.com]=20 Sent: Thursday, August 18, 2016 9:06 AM To: Susan Hares Cc: Juergen Schoenwaelder; i2rs@ietf.org; i2rs-chairs@ietf.org; The = IESG; Jeffrey Haas; = 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 Thu, Aug 18, 2016 at 9:00 AM, Susan Hares wrote: > Juergen: > > Yes, we seem to disagree on the value of making it hardwired in the = model. > For me, the value is a common understanding of deployment distribution = such > as the route-views. Since the operators argued strongly for this = point, I > think the best idea is to get it working in code and then see if the=20 > deployment matches the requests. This sounds like more of an experiment, doesn't it? Thanks, Kathleen > > Sue > > -----Original Message----- > From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Juergen=20 > Schoenwaelder > Sent: Thursday, August 18, 2016 8:14 AM > To: Susan Hares > Cc: i2rs@ietf.org; i2rs-chairs@ietf.org; 'Kathleen Moriarty'; 'The=20 > IESG'; jhaas@pfrc.org;=20 > 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) > > Sue, > > I still do not see why the 'mode of exposure' of data benefits from=20 > being hard-wired in the data model. For me, it is a situational and=20 > deployment specific question. But I shut up here since I aired this=20 > concern before (and we simply seem to disagree). > > /js > > On Thu, Aug 18, 2016 at 08:07:18AM -0400, Susan Hares wrote: >> Juergen: >> >> My example is the looking glass servers for the BGP route views=20 >> project >> (http://www.routeviews.org/) or a route indicating the presence of a >> web-server that is public. For the BGP I2RS route, a yang model = could >> replace the looking glass function, and provide events for these = looking >> glass functions. For the web-server route, an event be sent when = that >> one route is added. >> >> Sue >> >> >> -----Original Message----- >> From: Juergen Schoenwaelder >> [mailto:j.schoenwaelder@jacobs-university.de] >> Sent: Thursday, August 18, 2016 3:32 AM >> To: Susan Hares >> Cc: 'Kathleen Moriarty'; 'The IESG'; jhaas@pfrc.org; i2rs@ietf.org;=20 >> i2rs-chairs@ietf.org;=20 >> 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 Wed, Aug 17, 2016 at 09:16:48PM -0400, Susan Hares wrote: >> > ------------------------------------------------------------------- >> > - >> > -- >> > COMMENT: >> > ------------------------------------------------------------------- >> > - >> > -- >> > >> > > Section 3: >> > > Can you clarify the second to last sentence? Do you mean there=20 >> > > are >> sections that indicate an insecure transport should be used? >> > > I2RS allows the use of an >> > > insecure transport for portions of data models that clearly=20 >> > > indicate insecure transport. >> > >> > > Perhaps: >> > > I2RS allows the use of an >> > > insecure transport for portions of data models that clearly=20 >> > > indicate the use of an insecure transport. >> >> I still wonder how a data model writer can reasonably decide whether=20 >> a piece of information can be shipped safely over an insecure=20 >> transport since this decision often depends on the specifics of a=20 >> deployment > situation. >> >> /js >> >> PS: I hope we do not end up with defining data multiple times (once >> for insecure transport and once for secured transports). >> >> -- >> Juergen Schoenwaelder Jacobs University Bremen gGmbH >> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | = Germany >> Fax: +49 421 200 3103 >> >> _______________________________________________ >> i2rs mailing list >> i2rs@ietf.org >> https://www.ietf.org/mailman/listinfo/i2rs > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs > --=20 Best regards, Kathleen From nobody Thu Aug 18 06:48:09 2016 Return-Path: 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 193BC12D893; Thu, 18 Aug 2016 06:48:03 -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 cNgy-bzm4frT; Thu, 18 Aug 2016 06:48:01 -0700 (PDT) Received: from mail-ua0-x22c.google.com (mail-ua0-x22c.google.com [IPv6:2607:f8b0:400c:c08::22c]) (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 4FF6612D776; Thu, 18 Aug 2016 06:48:01 -0700 (PDT) Received: by mail-ua0-x22c.google.com with SMTP id n59so28661598uan.2; Thu, 18 Aug 2016 06:48:01 -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=asMH3uBk0TwTMmt5f/RForyDQ4XLKzXoYWglJZ2OFx8=; b=la/yj6WlSRjW77Jxn21xbeJ//mRNjmEeJLUriJnwN64UUJkrhOi4qqavmWn4ljQ7Ut wlpbdJMJuhcTpCgCkTsI2aaP4I5LZ78cp3tuPN7dlmu6rWfWWrTZV3XGfVtEu4zfXXJL gfSw2BgeV40AZJFDY9vbOK7TeLflyNDktTiw1wr47iGUTNVj7ub68ZOhk/4owyVeGezh 9rPXxyyhnqHC//ZxhXMZcmmuzg1edI8hkmoNiDIApa3pqLPFi1McXWo4xwO2a5r4PcHc KjQhefQaxqxlr/GfZMjhfyUI5ARkB+mmK01f08iaUr19xq3vcaQIVFiAd6L5zjP8LO6u zoSw== 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=asMH3uBk0TwTMmt5f/RForyDQ4XLKzXoYWglJZ2OFx8=; b=DIXPON6pcZ3wqfEGyf2OsWrTgAV5idf0sPPQEdxie6zw5CQNq6GT4NYhjcG/UZ5T7o 9j+/j12KDgD86//e0r/vA0U33Sl2AH3T5Vm9a3ml9Kt2SrQSaE1URV9KwDn8+1G9M2wf 9po/1FF0Vk4nV1NT58GKVDjm34BN+0ob+ZMsOJRcquIJRExPoryu9md/mt4CRgB8imff 5cb9PXaFZce4yQgnDhPCoAnWaxl77HOsfhU+oqofwP/eTHpk7mIQRRGIMOjndDz4ncln VdF7Iea8KgqP24OAjXmyq58TChDrqFX2fqSGYdSoN0iU8AHy0qzbOsllDGEb7V71cPxw L9eQ== X-Gm-Message-State: AEkooutpqt+MoKJbseFAngKbD4OOr6RjhriinlbZBvPwmVVg+VMF0BcbJmP32KgDCdpeAUU8E++eTPzXEHafXw== X-Received: by 10.31.73.67 with SMTP id w64mr1109262vka.156.1471528080350; Thu, 18 Aug 2016 06:48:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.1.228 with HTTP; Thu, 18 Aug 2016 06:47:59 -0700 (PDT) In-Reply-To: References: <147144567895.12152.15403435188950086025.idtracker@ietfa.amsl.com> <5B604C19-7AEF-4C92-B452-A034749A5FCA@cooperw.in> From: Kathleen Moriarty Date: Thu, 18 Aug 2016 09:47:59 -0400 Message-ID: To: Stephen Farrell Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: i2rs@ietf.org, Alissa Cooper , i2rs-chairs@ietf.org, Alia Atlas , "iesg@ietf.org" , Jeffrey Haas , draft-ietf-i2rs-protocol-security-requirements@ietf.org Subject: Re: [i2rs] Alissa Cooper's Discuss on draft-ietf-i2rs-protocol-security-requirements-06: (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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Aug 2016 13:48:03 -0000 On Wed, Aug 17, 2016 at 2:24 PM, wrote: > Hiya, > > I'm on vacation so won't be balloting this week and I only had a quick fl= ick of this, but if I'd had time for a proper read I think I'd be asking ho= w realistic are these requirements, possibly as a discuss ballot. If someon= e wanted to hit defer and blame me (sorry I don't have the right devices wi= th me to do that) that'd be good. But if this draft is time-critical for t= he WG then please ignore the above. I hit the defer button for Stephen. Alia doesn't want this to sit too long, so we'll ave to be good about wrapping it up as there are other groups waiting on it. Thanks, Kathleen > > S. > > On Wed Aug 17 19:02:09 2016 GMT+0200, Alissa Cooper wrote: >> Hi Alia, >> >> > On Aug 17, 2016, at 11:07 AM, Alia Atlas wrote: >> > >> > Hi Alissa, >> > >> > On Wed, Aug 17, 2016 at 10:54 AM, Alissa Cooper > wrote: >> > Alissa Cooper has entered the following ballot position for >> > draft-ietf-i2rs-protocol-security-requirements-06: Discuss >> > >> > When responding, please keep the subject line intact and reply to all >> > email addresses included in the To and CC lines. (Feel free to cut thi= s >> > introductory paragraph, however.) >> > >> > >> > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.h= tml >> > for more information about IESG DISCUSS and COMMENT positions. >> > >> > >> > The document, along with other ballot positions, can be found here: >> > https://datatracker.ietf.org/doc/draft-ietf-i2rs-protocol-security-req= uirements/ >> > >> > >> > >> > ---------------------------------------------------------------------- >> > DISCUSS: >> > ---------------------------------------------------------------------- >> > >> > =3D=3D Section 3.2 =3D=3D >> > >> > "A non-secure transport can be 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." >> > >> > What kind of telemetry data is it that is of no potential interest to = any >> > eavesdropper? This is not my area of expertise so I'm having a hard ti= me >> > conceiving of what that could be. I'm also wondering, since I2RS agent= s >> > and clients will have to support secure transports anyway (and RESTCON= F >> > can only be used over a secure transport), why can't they be used for = all >> > transfers, instead of allowing this loophole in the name of telemetry, >> > which undoubtedly will end up being used or exploited for other data >> > transfers? >> > >> > If the argument was that this loophole is needed for backwards >> > compatibility with insecure deployments of NETCONF or something like t= hat >> > I think it would make more sense, but my impression from the text is t= hat >> > those will have to be updated anyway to conform to the requirements in >> > this document. >> > >> > Data coming from a router can come from many different line-cards and = processors. >> > The line-cards that may be providing the data are not going to be supp= orting the >> > secure transports anyway. >> >> Will they also not be supporting the I2RS protocol then, given the requi= rement for support of a secure transport? >> >> >> > A goal is to allow easy distribution of streaming data >> > and event notifications. As for what type of data, as far as I know, = currently IPFIX >> > streams telemetry data without integrity much less authorization prote= ction. >> >> What I=E2=80=99m questioning is the choice to extend that model to cases= where a third-party controller or application is one endpoint of the data = exchange, which is what I thought was part of the motivation for I2RS (happ= y to be corrected though). >> >> > >> > There are existing deployments that use gRPC now for streaming telemet= ry data. >> >> Ok. So is the implication that the requirements here are needed for back= wards compatability with those deployments? >> >> Thanks, >> Alissa >> >> > >> > Regards, >> > Alia >> > >> > ---------------------------------------------------------------------- >> > COMMENT: >> > ---------------------------------------------------------------------- >> > >> > In general I agree with Mirja that where other documents already provi= de >> > definitions, they should be referenced, not copied or summarized, in t= his >> > document. >> > >> > =3D=3D Section 2.1 =3D=3D >> > >> > Using "privacy" as a synonym for "confidentiality" is outmoded, I thin= k, >> > given current understanding of the many other facets of privacy (see, >> > e.g., RFC 6793). I would suggest dropping the definition of data priva= cy >> > and just using the word confidentiality when that is what you mean. >> > >> > =3D=3D Section 2.2 =3D=3D >> > >> > "The I2RS protocol exists as a higher-level protocol which may >> > combine other protocols (NETCONF, RESTCONF, IPFIX and others) >> > within a specific I2RS client-agent relationship with a specific >> > trust for ephemeral configurations, event, tracing, actions, and >> > data flow interactions." >> > >> > Reading the provided definition of "trust," I'm not sure what "with a >> > specific trust for" means in the sentence above. >> > >> > "The I2RS architecture document [I-D.ietf-i2rs-architecture] >> > defines a secondary identity as the entity of some non-I2RS enti= ty >> > (e.g. application) which has requested a particular I2RS client >> > perform an operation." >> > >> > Per my comment above, I would suggest just referencing the definition >> > from the architecture document. The text above is circular ("the entit= y >> > of some ... entity") and conflates an identity with an identifier. >> > >> > =3D=3D Section 3.1 =3D=3D >> > >> > Agree with Mirja that this section is superfluous. >> > >> > =3D=3D Section 3.3 =3D=3D >> > >> > Since the normative recommendation here isn't to be enforced by the >> > protocol, why is it SHOULD rather than MUST? Same question applies to >> > SEC-REQ-17. >> > >> > =3D=3D Section 3.5 =3D=3D >> > >> > Is the omission of normative language from Sec-REQ-20 purposeful? >> >> --=20 Best regards, Kathleen From nobody Thu Aug 18 06:50:43 2016 Return-Path: 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 8303F12DEB2; Thu, 18 Aug 2016 06:50:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.738 X-Spam-Level: * X-Spam-Status: No, score=1.738 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, RDNS_NONE=0.793] autolearn=no 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 rlUfIyK8k5Pi; Thu, 18 Aug 2016 06:50:38 -0700 (PDT) Received: from hickoryhill-consulting.com (unknown [50.245.122.97]) (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 0823912DEC6; Thu, 18 Aug 2016 06:50:37 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=174.124.167.170; From: "Susan Hares" To: "'Kathleen Moriarty'" References: <147146974235.23784.4389421535496134619.idtracker@ietfa.amsl.com> <013b01d1f8ee$31fa09b0$95ee1d10$@ndzh.com> In-Reply-To: Date: Thu, 18 Aug 2016 09:49:34 -0400 Message-ID: <062f01d1f957$5b540900$11fc1b00$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIa7Lz6VgZw6h2A0uGNzOgAA2Ic8QJ/RF5yAoBVGeiflNEcgA== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: 'Jeffrey Haas' , i2rs@ietf.org, draft-ietf-i2rs-protocol-security-requirements@ietf.org, 'The IESG' , i2rs-chairs@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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Aug 2016 13:50:39 -0000 -----Original Message----- From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Kathleen Moriarty Sent: Thursday, August 18, 2016 9:18 AM To: Susan Hares Cc: Jeffrey Haas; i2rs@ietf.org; The IESG; i2rs-chairs@ietf.org; 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) Hi Sue, Thanks for your quick response. inline On Wed, Aug 17, 2016 at 9:16 PM, Susan Hares wrote: > Kathleen: > > Thank you for your comments. Please see the inline comments below. I will be uploading a version -08.txt that will resolve some of these comments. > > Sue > > -----Original Message----- > From: Kathleen Moriarty [mailto:Kathleen.Moriarty.ietf@gmail.com] > Sent: Wednesday, August 17, 2016 5:36 PM > To: The IESG > Cc: draft-ietf-i2rs-protocol-security-requirements@ietf.org; Jeffrey > Haas; i2rs-chairs@ietf.org; jhaas@pfrc.org; i2rs@ietf.org > Subject: Kathleen Moriarty's Discuss on > draft-ietf-i2rs-protocol-security-requirements-07: (with DISCUSS and > COMMENT) > > Kathleen Moriarty has entered the following ballot position for > draft-ietf-i2rs-protocol-security-requirements-07: Discuss > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut > this introductory paragraph, however.) > > > Please refer to > https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-i2rs-protocol-security-req > uirements/ > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > Thanks for your work on this draft. There may be some overlap in points, I tried to minimize them... > ---- >>>Section 3.1: >>> >>>I don't see any actual requirements for mutual authentication in this section, just requirements for identifiers. Did I miss something? >> >> No, there are no additional requirements. We only have requirements for identifiers. Do you have a suggestion for improved language. >From your response & Joel's, I see bullet #2 is the only one that >calls out the need for mutual authentication and it just states that with no additional details. That is fine, but the subject for section >3.1 should be something more like authentication and identifiers to represent the content better. Any suggestions on the header you would like to see? >> Are all mutual auth schemes in scope? Are there any considerations for mutual authentication (passwords, keys, etc.)? >> >> All mutual identification schemes are in scope. Is there a reason we should restrict the mutual authentication schemes to a subset. >You don't have to, but the header of the section makes me think this is going to happen in the section. Maybe setting a baseline would be good if possible. Not using passwords - so > a secure form of mutual authentication would be good if the requirements are only high level. Can you please suggest text for a removal of using passwords? > > ---- >>I share the same concern as others for secure transport, but since there are already discusses on that, I have one comment to add to the existing discusses below. > > You have a concern regarding the secure transport? KM: Yes, the wording that allows for insecure transport. Same concern expressed by other ADs. SH: My understanding is that other people had a concern regarding the insecure transport. I have provide an example of the BGP data feed utilized by http://www.routeviews.org/ project. KM: Aren't you concerned about the integrity of this data? SH: Let me answer this from the operators feedback that causes this input. Some operators state, I will run everything over secure transport. Other operators state, I want to have light weight clients that will receive certain types of information via insecure transport. The light-weight client will have caveats (insecure transport, could be spoofed), and then present the information. The argument within the WG was strong from operators for this second case, and we made the decision to include the insecure data stream. We can limit this second case to unique data models (due to the mount addition to netconf/netmod) which can be mounted. We could expand this to specific events. > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >> >>> Section 3: >>> Can you clarify the second to last sentence? Do you mean there are sections that indicate an insecure transport should be used? >>> I2RS allows the use of an >>> insecure transport for portions of data models that clearly indicate >>> insecure transport. >> >>> Perhaps: >>> I2RS allows the use of an >>> insecure transport for portions of data models that clearly indicate >>> the use of an insecure transport. >> >> Changed to : >> >> I2RS allows the use of an insecure transport for portions of data >> models that clearly indicate the use of an insecure transport. >> Operators deploying I2RS must determine if they want to populate and deploy the portions of the data model which use insecure transports. >> >I don't agree with the data model setting the transport requirements. >If this is done, it should be an experiment IMO. What does experimental mean in a re-use protocol requirements? Does it mean that the NETCONF/RESTCONF does not have to it functional? Does it mean that we indicate this function is experimental and needs to be reviewed again? If so, what are the criteria for the experiment to be successful? If experimental has the following constraint: 1) NETCONF/RESTCONF must provide both standards and experimental features in a design, 2) I2RS protocol may use standard and experimental features to judge a protocol fits I2RS protocol needs, 3) I2RS will write-up a document indicating what tests will be used to deem that the experimental features are ready for protocol standardization. > > ---- >> Section 3.2 >> I agree with Alissa's discuss point on the following sentence (that could also be reworded a bit): >> A non-secure transport can be 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. > > I would appreciate a recommended set of text or additional explanation on what you would like to see in rewording. > I'll have to look through Alissa's discuss, but isn't integrity a concern if confidentiality and privacy are not? I'm sure once this type of text is altered and used to make important > decisions, this will come back to bite us. Of course, integrity is desired. The non-secure transport is looking to provide public information for a light-weight client. Operators have indicated a light-weight I2RS client will use this point. The challenge will be to have a light-weight integrity. > > ---- >>>Section 3.4: In the following text: >>> SEC-REQ-15: The integrity that the message data is not repeated means >>> that I2RS client to I2RS agent transport SHOULD protect against >>> replay attack >> >>>I'm not sure why this just doesn't say: >>> SEC-REQ-15: I2RS client to I2RS agent transport SHOULD protect >>against > > replay attack >>The additional text doesn't add anything and sounds a bit confusing. > >> Sue: Is this ok. It will be changed > KM: Thanks. Sue: Please verify you have what you want in the -08.txt > > ---- > Nit: > > I'm not sure these definitions add any value as they seem to restate the term defined: > >> I2RS protocol data integrity >> >> The transfer of data via the I2RS protocol has the property of >> data integrity described in [RFC4949]. > > Deleted > > >> I2RS component protocols >> >> Protocols which are combined to create the I2RS protocol. > > Please suggest alternative text for this section. KM: I think it is self explanatory. But if that's just me, leave the definition in. Sue: Other people did not find it self-explanatory. > > ----- > >> I also agree that the definitions from 4949 should be removed. >> Thank you in advance. > > These definition have been removed. I will provide feedback if this removal cause problems in the creation of the protocol. Sue: You are welcome. Thank you, Kathleen > -- Best regards, Kathleen _______________________________________________ i2rs mailing list i2rs@ietf.org https://www.ietf.org/mailman/listinfo/i2rs From nobody Thu Aug 18 06:52:41 2016 Return-Path: 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 C0C1D12DED3; Thu, 18 Aug 2016 06:52:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.738 X-Spam-Level: * X-Spam-Status: No, score=1.738 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, RDNS_NONE=0.793] autolearn=no 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 hDyUXu10fw9Y; Thu, 18 Aug 2016 06:52:26 -0700 (PDT) Received: from hickoryhill-consulting.com (unknown [50.245.122.97]) (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 1257D12DEDF; Thu, 18 Aug 2016 06:52:21 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=174.124.167.170; From: "Susan Hares" To: "'Kathleen Moriarty'" , "'Stephen Farrell'" References: <147144567895.12152.15403435188950086025.idtracker@ietfa.amsl.com> <5B604C19-7AEF-4C92-B452-A034749A5FCA@cooperw.in> In-Reply-To: Date: Thu, 18 Aug 2016 09:51:13 -0400 Message-ID: <063101d1f957$9679ca10$c36d5e30$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQG3q3aG/0u2B1HfPippUnE2NxzEQwGi2QgoAk3GCFUB6JhdAADJV/ysoE5DYLA= Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: i2rs@ietf.org, 'Alissa Cooper' , i2rs-chairs@ietf.org, 'Alia Atlas' , iesg@ietf.org, 'Jeffrey Haas' , draft-ietf-i2rs-protocol-security-requirements@ietf.org Subject: Re: [i2rs] Alissa Cooper's Discuss on draft-ietf-i2rs-protocol-security-requirements-06: (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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Aug 2016 13:52:28 -0000 Kathleen and Stephen:=20 Can you tell me the reason for defer? Alia will not be there in the = next formal telechat - so no responsible AD will be there for the = document. =20 Sue=20 -----Original Message----- From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Kathleen Moriarty Sent: Thursday, August 18, 2016 9:48 AM To: Stephen Farrell Cc: i2rs@ietf.org; Alissa Cooper; i2rs-chairs@ietf.org; Alia Atlas; = iesg@ietf.org; Jeffrey Haas; = draft-ietf-i2rs-protocol-security-requirements@ietf.org Subject: Re: [i2rs] Alissa Cooper's Discuss on = draft-ietf-i2rs-protocol-security-requirements-06: (with DISCUSS and = COMMENT) On Wed, Aug 17, 2016 at 2:24 PM, wrote: > Hiya, > > I'm on vacation so won't be balloting this week and I only had a quick = flick of this, but if I'd had time for a proper read I think I'd be = asking how realistic are these requirements, possibly as a discuss = ballot. If someone wanted to hit defer and blame me (sorry I don't have = the right devices with me to do that) that'd be good. But if this draft = is time-critical for the WG then please ignore the above. I hit the defer button for Stephen. Alia doesn't want this to sit too = long, so we'll ave to be good about wrapping it up as there are other = groups waiting on it. Thanks, Kathleen > > S. > > On Wed Aug 17 19:02:09 2016 GMT+0200, Alissa Cooper wrote: >> Hi Alia, >> >> > On Aug 17, 2016, at 11:07 AM, Alia Atlas wrote: >> > >> > Hi Alissa, >> > >> > On Wed, Aug 17, 2016 at 10:54 AM, Alissa Cooper > wrote: >> > Alissa Cooper has entered the following ballot position for >> > draft-ietf-i2rs-protocol-security-requirements-06: Discuss >> > >> > When responding, please keep the subject line intact and reply to=20 >> > all email addresses included in the To and CC lines. (Feel free to=20 >> > cut this introductory paragraph, however.) >> > >> > >> > Please refer to=20 >> > https://www.ietf.org/iesg/statement/discuss-criteria.html=20 >> > >> > for more information about IESG DISCUSS and COMMENT positions. >> > >> > >> > The document, along with other ballot positions, can be found here: >> > https://datatracker.ietf.org/doc/draft-ietf-i2rs-protocol-security- >> > requirements/=20 >> > > > -requirements/> >> > >> > >> > >> > ------------------------------------------------------------------- >> > --- >> > DISCUSS: >> > ------------------------------------------------------------------- >> > --- >> > >> > =3D=3D Section 3.2 =3D=3D >> > >> > "A non-secure transport can be 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." >> > >> > What kind of telemetry data is it that is of no potential interest=20 >> > to any eavesdropper? This is not my area of expertise so I'm having = >> > a hard time conceiving of what that could be. I'm also wondering,=20 >> > since I2RS agents and clients will have to support secure=20 >> > transports anyway (and RESTCONF can only be used over a secure=20 >> > transport), why can't they be used for all transfers, instead of=20 >> > allowing this loophole in the name of telemetry, which undoubtedly=20 >> > will end up being used or exploited for other data transfers? >> > >> > If the argument was that this loophole is needed for backwards=20 >> > compatibility with insecure deployments of NETCONF or something=20 >> > like that I think it would make more sense, but my impression from=20 >> > the text is that those will have to be updated anyway to conform to = >> > the requirements in this document. >> > >> > Data coming from a router can come from many different line-cards = and processors. >> > The line-cards that may be providing the data are not going to be=20 >> > supporting the secure transports anyway. >> >> Will they also not be supporting the I2RS protocol then, given the = requirement for support of a secure transport? >> >> >> > A goal is to allow easy distribution of streaming data and event=20 >> > notifications. As for what type of data, as far as I know,=20 >> > currently IPFIX streams telemetry data without integrity much less = authorization protection. >> >> What I=E2=80=99m questioning is the choice to extend that model to = cases where a third-party controller or application is one endpoint of = the data exchange, which is what I thought was part of the motivation = for I2RS (happy to be corrected though). >> >> > >> > There are existing deployments that use gRPC now for streaming = telemetry data. >> >> Ok. So is the implication that the requirements here are needed for = backwards compatability with those deployments? >> >> Thanks, >> Alissa >> >> > >> > Regards, >> > Alia >> > >> > ------------------------------------------------------------------- >> > --- >> > COMMENT: >> > ------------------------------------------------------------------- >> > --- >> > >> > In general I agree with Mirja that where other documents already=20 >> > provide definitions, they should be referenced, not copied or=20 >> > summarized, in this document. >> > >> > =3D=3D Section 2.1 =3D=3D >> > >> > Using "privacy" as a synonym for "confidentiality" is outmoded, I=20 >> > think, given current understanding of the many other facets of=20 >> > privacy (see, e.g., RFC 6793). I would suggest dropping the=20 >> > definition of data privacy and just using the word confidentiality = when that is what you mean. >> > >> > =3D=3D Section 2.2 =3D=3D >> > >> > "The I2RS protocol exists as a higher-level protocol which may >> > combine other protocols (NETCONF, RESTCONF, IPFIX and others) >> > within a specific I2RS client-agent relationship with a = specific >> > trust for ephemeral configurations, event, tracing, actions, = and >> > data flow interactions." >> > >> > Reading the provided definition of "trust," I'm not sure what "with = >> > a specific trust for" means in the sentence above. >> > >> > "The I2RS architecture document [I-D.ietf-i2rs-architecture] >> > defines a secondary identity as the entity of some non-I2RS = entity >> > (e.g. application) which has requested a particular I2RS = client >> > perform an operation." >> > >> > Per my comment above, I would suggest just referencing the=20 >> > definition from the architecture document. The text above is=20 >> > circular ("the entity of some ... entity") and conflates an = identity with an identifier. >> > >> > =3D=3D Section 3.1 =3D=3D >> > >> > Agree with Mirja that this section is superfluous. >> > >> > =3D=3D Section 3.3 =3D=3D >> > >> > Since the normative recommendation here isn't to be enforced by the = >> > protocol, why is it SHOULD rather than MUST? Same question applies=20 >> > to SEC-REQ-17. >> > >> > =3D=3D Section 3.5 =3D=3D >> > >> > Is the omission of normative language from Sec-REQ-20 purposeful? >> >> --=20 Best regards, Kathleen _______________________________________________ i2rs mailing list i2rs@ietf.org https://www.ietf.org/mailman/listinfo/i2rs From nobody Thu Aug 18 06:57:55 2016 Return-Path: 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 3EF9012DE99; Thu, 18 Aug 2016 06:57:53 -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 YnuuKEVv0Lgb; Thu, 18 Aug 2016 06:57:50 -0700 (PDT) Received: from mail-ua0-x22e.google.com (mail-ua0-x22e.google.com [IPv6:2607:f8b0:400c:c08::22e]) (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 BBD2D12DE8C; Thu, 18 Aug 2016 06:57:50 -0700 (PDT) Received: by mail-ua0-x22e.google.com with SMTP id n59so29136981uan.2; Thu, 18 Aug 2016 06:57:50 -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=3U0Ds6wSp4fiFTPQ+ZxfAqlkz/KMzJFfWByVVYkTfD0=; b=a2dqDZkBUaNnrh+sQkowSm00DangP15eC1/O4IVTPDCIu55rFg/iAWKdnrsuF9Z6t8 PRDmiaLL+1P/PX5Vj/GDQNi7EZGlYYUS6hO6WJPdSju1vi/lwySfF5w2I01VssmfxOBt clvjYLTGi1fN8E0r1bqYWmp93fY6CDnvJmkf22vMWVIb+FMSuIvIzOlh4+ltUXDeupqS ECZr489yprq9Ls6QTyhcPGKRbWIb3Y8C5eo7kPvv1x9YtomEMIhp+Odj9xnqLEESshU6 Qmq/mrBashBrcD2QY8T8yDO+5BzqTY1dF90aHUJBomG8HRGLLBFI/XrMhYkcLqCj15qz vj2w== 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=3U0Ds6wSp4fiFTPQ+ZxfAqlkz/KMzJFfWByVVYkTfD0=; b=MHHm2W6PrhcTTu2BCgQPJBeVrhpOj/oYrJM0KZq6m1TTVb0bWUyOHVmcWk76Q81z/x fjy1/PkJsUe5izND9MpvmEhyJDMy4Af8RJSwROwKdi0X+OErb63TrYJ0lXOS5+Q3Cl17 zKs/lbUgS8wVFTXyrJ8c69OfVMF4sijNVTQ4yFvcRs8zQ6cwMHM/wn3rywd1oli64uiu XqpzkjZBCQVpTUajoA5IJFG1QVyEoIRVzsTKLk5oMc6y+ffuiieuByLLhrBhUchJFYRJ 54KoCUThgGy0hXZy2WpPMrg7/UmzidW/AR5Wvy9gWdrnp6wxRS9VyoHNY+7b4xBU7nWX 77eA== X-Gm-Message-State: AEkoouugFJy3oaDx/bXz6OzB2uMOaUccxRVZyUdJs/DP9oTV6Zgdzvx707u5KD0P6u5gWtyGoSfFWPEAnRJUIA== X-Received: by 10.159.34.177 with SMTP id 46mr1112085uan.111.1471528669913; Thu, 18 Aug 2016 06:57:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.1.228 with HTTP; Thu, 18 Aug 2016 06:57:49 -0700 (PDT) In-Reply-To: <063101d1f957$9679ca10$c36d5e30$@ndzh.com> References: <147144567895.12152.15403435188950086025.idtracker@ietfa.amsl.com> <5B604C19-7AEF-4C92-B452-A034749A5FCA@cooperw.in> <063101d1f957$9679ca10$c36d5e30$@ndzh.com> From: Kathleen Moriarty Date: Thu, 18 Aug 2016 09:57:49 -0400 Message-ID: To: Susan Hares Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: i2rs@ietf.org, Alissa Cooper , i2rs-chairs@ietf.org, Alia Atlas , "iesg@ietf.org" , Jeffrey Haas , draft-ietf-i2rs-protocol-security-requirements@ietf.org, Stephen Farrell Subject: Re: [i2rs] Alissa Cooper's Discuss on draft-ietf-i2rs-protocol-security-requirements-06: (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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Aug 2016 13:57:53 -0000 On Thu, Aug 18, 2016 at 9:51 AM, Susan Hares wrote: > Kathleen and Stephen: > > Can you tell me the reason for defer? Alia will not be there in the next= formal telechat - so no responsible AD will be there for the document. Stephen is on vacation and can't read the draft, but would like to read it. I chatted with Alia on it and if Stephen can read it next week to resolve any findings while Alia is not on vacation, this should be fine on the next telechat as she could set the appropriate action in place before the call (or before she leaves for vacation). Thanks, Kathleen > > Sue > > -----Original Message----- > From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Kathleen Moriarty > Sent: Thursday, August 18, 2016 9:48 AM > To: Stephen Farrell > Cc: i2rs@ietf.org; Alissa Cooper; i2rs-chairs@ietf.org; Alia Atlas; iesg@= ietf.org; Jeffrey Haas; draft-ietf-i2rs-protocol-security-requirements@ietf= .org > Subject: Re: [i2rs] Alissa Cooper's Discuss on draft-ietf-i2rs-protocol-s= ecurity-requirements-06: (with DISCUSS and COMMENT) > > On Wed, Aug 17, 2016 at 2:24 PM, wrote: >> Hiya, >> >> I'm on vacation so won't be balloting this week and I only had a quick f= lick of this, but if I'd had time for a proper read I think I'd be asking h= ow realistic are these requirements, possibly as a discuss ballot. If someo= ne wanted to hit defer and blame me (sorry I don't have the right devices w= ith me to do that) that'd be good. But if this draft is time-critical for = the WG then please ignore the above. > > I hit the defer button for Stephen. Alia doesn't want this to sit too lo= ng, so we'll ave to be good about wrapping it up as there are other groups = waiting on it. > > Thanks, > Kathleen > >> >> S. >> >> On Wed Aug 17 19:02:09 2016 GMT+0200, Alissa Cooper wrote: >>> Hi Alia, >>> >>> > On Aug 17, 2016, at 11:07 AM, Alia Atlas wrote: >>> > >>> > Hi Alissa, >>> > >>> > On Wed, Aug 17, 2016 at 10:54 AM, Alissa Cooper > wrote: >>> > Alissa Cooper has entered the following ballot position for >>> > draft-ietf-i2rs-protocol-security-requirements-06: Discuss >>> > >>> > When responding, please keep the subject line intact and reply to >>> > all email addresses included in the To and CC lines. (Feel free to >>> > cut this introductory paragraph, however.) >>> > >>> > >>> > Please refer to >>> > https://www.ietf.org/iesg/statement/discuss-criteria.html >>> > >>> > for more information about IESG DISCUSS and COMMENT positions. >>> > >>> > >>> > The document, along with other ballot positions, can be found here: >>> > https://datatracker.ietf.org/doc/draft-ietf-i2rs-protocol-security- >>> > requirements/ >>> > >> > -requirements/> >>> > >>> > >>> > >>> > ------------------------------------------------------------------- >>> > --- >>> > DISCUSS: >>> > ------------------------------------------------------------------- >>> > --- >>> > >>> > =3D=3D Section 3.2 =3D=3D >>> > >>> > "A non-secure transport can be 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." >>> > >>> > What kind of telemetry data is it that is of no potential interest >>> > to any eavesdropper? This is not my area of expertise so I'm having >>> > a hard time conceiving of what that could be. I'm also wondering, >>> > since I2RS agents and clients will have to support secure >>> > transports anyway (and RESTCONF can only be used over a secure >>> > transport), why can't they be used for all transfers, instead of >>> > allowing this loophole in the name of telemetry, which undoubtedly >>> > will end up being used or exploited for other data transfers? >>> > >>> > If the argument was that this loophole is needed for backwards >>> > compatibility with insecure deployments of NETCONF or something >>> > like that I think it would make more sense, but my impression from >>> > the text is that those will have to be updated anyway to conform to >>> > the requirements in this document. >>> > >>> > Data coming from a router can come from many different line-cards and= processors. >>> > The line-cards that may be providing the data are not going to be >>> > supporting the secure transports anyway. >>> >>> Will they also not be supporting the I2RS protocol then, given the requ= irement for support of a secure transport? >>> >>> >>> > A goal is to allow easy distribution of streaming data and event >>> > notifications. As for what type of data, as far as I know, >>> > currently IPFIX streams telemetry data without integrity much less au= thorization protection. >>> >>> What I=E2=80=99m questioning is the choice to extend that model to case= s where a third-party controller or application is one endpoint of the data= exchange, which is what I thought was part of the motivation for I2RS (hap= py to be corrected though). >>> >>> > >>> > There are existing deployments that use gRPC now for streaming teleme= try data. >>> >>> Ok. So is the implication that the requirements here are needed for bac= kwards compatability with those deployments? >>> >>> Thanks, >>> Alissa >>> >>> > >>> > Regards, >>> > Alia >>> > >>> > ------------------------------------------------------------------- >>> > --- >>> > COMMENT: >>> > ------------------------------------------------------------------- >>> > --- >>> > >>> > In general I agree with Mirja that where other documents already >>> > provide definitions, they should be referenced, not copied or >>> > summarized, in this document. >>> > >>> > =3D=3D Section 2.1 =3D=3D >>> > >>> > Using "privacy" as a synonym for "confidentiality" is outmoded, I >>> > think, given current understanding of the many other facets of >>> > privacy (see, e.g., RFC 6793). I would suggest dropping the >>> > definition of data privacy and just using the word confidentiality wh= en that is what you mean. >>> > >>> > =3D=3D Section 2.2 =3D=3D >>> > >>> > "The I2RS protocol exists as a higher-level protocol which may >>> > combine other protocols (NETCONF, RESTCONF, IPFIX and others) >>> > within a specific I2RS client-agent relationship with a specifi= c >>> > trust for ephemeral configurations, event, tracing, actions, an= d >>> > data flow interactions." >>> > >>> > Reading the provided definition of "trust," I'm not sure what "with >>> > a specific trust for" means in the sentence above. >>> > >>> > "The I2RS architecture document [I-D.ietf-i2rs-architecture] >>> > defines a secondary identity as the entity of some non-I2RS ent= ity >>> > (e.g. application) which has requested a particular I2RS client >>> > perform an operation." >>> > >>> > Per my comment above, I would suggest just referencing the >>> > definition from the architecture document. The text above is >>> > circular ("the entity of some ... entity") and conflates an identity = with an identifier. >>> > >>> > =3D=3D Section 3.1 =3D=3D >>> > >>> > Agree with Mirja that this section is superfluous. >>> > >>> > =3D=3D Section 3.3 =3D=3D >>> > >>> > Since the normative recommendation here isn't to be enforced by the >>> > protocol, why is it SHOULD rather than MUST? Same question applies >>> > to SEC-REQ-17. >>> > >>> > =3D=3D Section 3.5 =3D=3D >>> > >>> > Is the omission of normative language from Sec-REQ-20 purposeful? >>> >>> > > > > -- > > Best regards, > Kathleen > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs > --=20 Best regards, Kathleen From nobody Thu Aug 18 07:33:19 2016 Return-Path: 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 5CE4612DF52; Thu, 18 Aug 2016 07:33:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-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 x3YB-aGTsOxI; Thu, 18 Aug 2016 07:33:09 -0700 (PDT) Received: from usplmg20.ericsson.net (usplmg20.ericsson.net [198.24.6.45]) (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 A36BA12DD73; Thu, 18 Aug 2016 07:33:09 -0700 (PDT) X-AuditID: c618062d-980fb98000000a08-2f-57b5c815217a Received: from EUSAAHC005.ericsson.se (Unknown_Domain [147.117.188.87]) by (Symantec Mail Security) with SMTP id 18.FE.02568.518C5B75; Thu, 18 Aug 2016 16:37:10 +0200 (CEST) Received: from EUSAAMB101.ericsson.se ([147.117.188.118]) by EUSAAHC005.ericsson.se ([147.117.188.87]) with mapi id 14.03.0301.000; Thu, 18 Aug 2016 10:30:56 -0400 From: Joel Halpern To: Susan Hares , 'Juergen Schoenwaelder' Thread-Topic: [i2rs] Kathleen Moriarty's Discuss on draft-ietf-i2rs-protocol-security-requirements-07: (with DISCUSS and COMMENT) Thread-Index: AQHR+M9RS2GZh8i+ykKux5/BrfoGxqBOLdEAgABo2ICAAEzoAIAAAeWAgAAM5QCAAAGWgIAAAwYA///Pb2A= Date: Thu, 18 Aug 2016 14:30:56 +0000 Message-ID: <6BCE198E4EAEFC4CAB45D75826EFB0761525CCD7@eusaamb101.ericsson.se> References: <147146974235.23784.4389421535496134619.idtracker@ietfa.amsl.com> <013b01d1f8ee$31fa09b0$95ee1d10$@ndzh.com> <20160818073203.GA4338@elstar.local> <04b501d1f949$116c63e0$34452ba0$@ndzh.com> <20160818121405.GA5282@elstar.local> <051301d1f950$7739c670$65ad5350$@ndzh.com> <20160818130555.GA5366@elstar.local> <051701d1f952$c4ae0b30$4e0a2190$@ndzh.com> In-Reply-To: <051701d1f952$c4ae0b30$4e0a2190$@ndzh.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.12] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprLIsWRmVeSWpSXmKPExsUyuXRPuK7Yia3hBhO7uC0W9y1lsvhwrJnN Yt2MDywWM/5MZLa4uvEno8X+g29ZLRp25lv8efOKxYHDY+esu+weS5b8ZPLYcMDTY/br66we l3u3sgawRnHZpKTmZJalFunbJXBlbFrmUXDFvWLf37tMDYw7LbsYOTkkBEwkrr19zt7FyMUh JLCBUaL3SA8ThLOcUeLDnaPsIFVsAnoSa98/ZgKxRQSSJT7+bGAFsZkFTjBJfFsSBdIgLNDE KHF18RuwbhGBZkaJM2dnsEB0JEmsvLcZrINFQFVi/89esKm8Ar4SPXM3QK37xiTxpbUFrIFT wFxi4uXvzCA2o4CYxPdTa5gg1olL3HoynwnicAGJJXvOM0PYohIvH/9jhbCVJOa8vsYMUa8j sWD3JzYIW1ti2cLXzBCLBSVOznzCMoFRdBaSsbOQtMxC0jILScsCRpZVjBylxQU5uelGBpsY gZF2TIJNdwfj/emehxgFOBiVeHgVlm0JF2JNLCuuzD3EKMHBrCTCO+/I1nAh3pTEyqrUovz4 otKc1OJDjNIcLErivGKPFMOFBNITS1KzU1MLUotgskwcnFINjPM1/f8peFq+yT57RO7Gg9+n D53yWB9T836O41/JyjzfyCzZaec8F0sYP+soFNvysMY26O+23phdlv/l+vLszgg5H7d/0SJp yX79jLQSN//MX6rf8humtVf+OHuoW9Vg2fXSjT65f1gcnoZK+m7aL1mq/LQnNfOmScCVdyb/ Z35RTO3Zct7+khJLcUaioRZzUXEiAGW46SywAgAA Archived-At: Cc: "i2rs@ietf.org" , "i2rs-chairs@ietf.org" , 'Kathleen Moriarty' , 'The IESG' , "jhaas@pfrc.org" , "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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Aug 2016 14:33:12 -0000 Let me try a different take approach to this particular question. Let me start by putting aside the question of where things are marked, and = come back to that afterwards. There are a number of cases that I2RS has been asked to cover of high rate = telemetry data. This may be BGP update information, it may be frequent inf= ormation about line card activity. There are other cases, some of which ha= ve been documented. While not completely insensitive, the operators have made clear that they s= ee protecting this data as unnecessary. While I would hope over time to mo= ve to a domain where all of it is protect, that is not trivial. As the I2R= S Architecture points out, it is expected that what we describe as a single= I2RS communication between a client and agent is actually associated with = multiple channels of communication. Now, if you want to say that the I2RS protocol requirements cannot allow fo= r unprotected channels, I guess we have disconnect between the IESG and the= WG. If we say that we can allow for unprotected channels, we then get to the qu= estion of which data can be sent over such channels. While architecturally= I agree with Juergen that the model is a bad place to specify it, the obve= rse is also true. Not having some limits on what can be sent unprotected c= auses concern about insufficient protection. If I recall correctly, earlie= r security reviews called us to task for being too broad in what we allowed= . So, if the IESG wants us to just allow it anywhere, because the model is an= awkward place to define the limitation, I can live with that. What I can'= t live with is being told both that the model is a bad place to define it a= nd that there must be restrictions on what is sent unprotected, without any= proposal on how we are to move forward. Yours, Joel -----Original Message----- From: Susan Hares [mailto:shares@ndzh.com]=20 Sent: Thursday, August 18, 2016 9:17 AM To: 'Juergen Schoenwaelder' Cc: i2rs@ietf.org; i2rs-chairs@ietf.org; 'Kathleen Moriarty' ; 'The IESG' ; jhaas@pfrc.org; draft-iet= f-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) Juergen and Kathleen:=20 Let me proceed with two examples: BGP route views data model and the event = for the web-service data. =20 The content of these data models are designated as exposed to public. The = routing system only populates the proposed BGP route views data model with = the data destined for the BGP looking glass. The policy on the routing sys= tem indicates what information gets transferred. The data model is complet= ely available to the public. The Yang Doctors are going to review this by = seeing the whole model is public and available via non-secure means. The security people are going to review this seeing that the whole model is= public, and available via an unprotect means. The fact the data model is = all public should simplify the review.=20 An event from the I2RS RIB that a web-service route is up is the second cas= e. The I2RS RIB has an event based on policy that indicates a web-service = route is up. The yang-1.1 doctors must review the content of the event tex= t to see it does not break privacy or provide too much information The event mechanisms will need to work over secure transport and insecure transport. Most of the data will go over the secure transport= event stream. However, a small amount of information may go over the insec= ure transport stream.=20 First, let me know if my use cases are understandable. Second, let me know= if you disagree with this use cases.=20 Fyi - IESG approved the architecture with the insecure stream.=20 Sue=20 -----Original Message----- From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de] Sent: Thursday, August 18, 2016 9:06 AM To: Susan Hares Cc: i2rs@ietf.org; i2rs-chairs@ietf.org; 'Kathleen Moriarty'; 'The IESG'; j= haas@pfrc.org; 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) I just do not know on which basis a data model writer can decide whether a = data object can be exposed in an unprotected way. How are YANG doctors goin= g to review this? How are security directorate people going to judge this? = But as promised, I leave (still puzzled) now. /js On Thu, Aug 18, 2016 at 09:00:14AM -0400, Susan Hares wrote: > Juergen:=20 >=20 > Yes, we seem to disagree on the value of making it hardwired in the model= . > For me, the value is a common understanding of deployment distribution such > as the route-views. Since the operators argued strongly for this point, I > think the best idea is to get it working in code and then see if the=20 > deployment matches the requests. >=20 > Sue >=20 > -----Original Message----- > From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Juergen=20 > Schoenwaelder > Sent: Thursday, August 18, 2016 8:14 AM > To: Susan Hares > Cc: i2rs@ietf.org; i2rs-chairs@ietf.org; 'Kathleen Moriarty'; 'The=20 > IESG'; jhaas@pfrc.org;=20 > 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) >=20 > Sue, >=20 > I still do not see why the 'mode of exposure' of data benefits from=20 > being hard-wired in the data model. For me, it is a situational and=20 > deployment specific question. But I shut up here since I aired this=20 > concern before (and we simply seem to disagree). >=20 > /js >=20 > On Thu, Aug 18, 2016 at 08:07:18AM -0400, Susan Hares wrote: > > Juergen:=20 > >=20 > > My example is the looking glass servers for the BGP route views=20 > > project > > (http://www.routeviews.org/) or a route indicating the presence of a > > web-server that is public. For the BGP I2RS route, a yang model could > > replace the looking glass function, and provide events for these lookin= g > > glass functions. For the web-server route, an event be sent when that > > one route is added. =20 > >=20 > > Sue > >=20 > >=20 > > -----Original Message----- > > From: Juergen Schoenwaelder > > [mailto:j.schoenwaelder@jacobs-university.de] > > Sent: Thursday, August 18, 2016 3:32 AM > > To: Susan Hares > > Cc: 'Kathleen Moriarty'; 'The IESG'; jhaas@pfrc.org; i2rs@ietf.org;=20 > > i2rs-chairs@ietf.org;=20 > > 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) > >=20 > > On Wed, Aug 17, 2016 at 09:16:48PM -0400, Susan Hares wrote: > > > ------------------------------------------------------------------ > > > -- > > > -- > > > COMMENT: > > > ------------------------------------------------------------------ > > > -- > > > -- > > >=20 > > > > Section 3:=20 > > > > Can you clarify the second to last sentence? Do you mean there=20 > > > > are > > sections that indicate an insecure transport should be used? > > > > I2RS allows the use of an > > > > insecure transport for portions of data models that clearly=20 > > > > indicate insecure transport. > > >=20 > > > > Perhaps: > > > > I2RS allows the use of an > > > > insecure transport for portions of data models that clearly=20 > > > > indicate the use of an insecure transport. > >=20 > > I still wonder how a data model writer can reasonably decide whether=20 > > a piece of information can be shipped safely over an insecure=20 > > transport since this decision often depends on the specifics of a=20 > > deployment > situation. > >=20 > > /js > >=20 > > PS: I hope we do not end up with defining data multiple times (once > > for insecure transport and once for secured transports). > >=20 > > --=20 > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > > Fax: +49 421 200 3103 > >=20 > > _______________________________________________ > > i2rs mailing list > > i2rs@ietf.org > > https://www.ietf.org/mailman/listinfo/i2rs >=20 > --=20 > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 >=20 > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs >=20 --=20 Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Thu Aug 18 08:31:00 2016 Return-Path: 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 B6C2C12DCA3; Thu, 18 Aug 2016 08:30:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.738 X-Spam-Level: * X-Spam-Status: No, score=1.738 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, RDNS_NONE=0.793] autolearn=no 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 dMTZHe7BBzRA; Thu, 18 Aug 2016 08:30:57 -0700 (PDT) Received: from hickoryhill-consulting.com (unknown [50.245.122.97]) (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 4B7CA12DC8A; Thu, 18 Aug 2016 08:30:57 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=174.124.167.170; From: "Susan Hares" To: "'Joel Halpern'" , "'Juergen Schoenwaelder'" References: <147146974235.23784.4389421535496134619.idtracker@ietfa.amsl.com> <013b01d1f8ee$31fa09b0$95ee1d10$@ndzh.com> <20160818073203.GA4338@elstar.local> <04b501d1f949$116c63e0$34452ba0$@ndzh.com> <20160818121405.GA5282@elstar.local> <051301d1f950$7739c670$65ad5350$@ndzh.com> <20160818130555.GA5366@elstar.local> <051701d1f952$c4ae0b30$4e0a2190$@ndzh.com> <6BCE198E4EAEFC4CAB45D75826EFB0761525CCD7@eusaamb101.ericsson.se> In-Reply-To: <6BCE198E4EAEFC4CAB45D75826EFB0761525CCD7@eusaamb101.ericsson.se> Date: Thu, 18 Aug 2016 11:29:39 -0400 Message-ID: <06b701d1f965$560757f0$021607d0$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIa7Lz6VgZw6h2A0uGNzOgAA2Ic8QJ/RF5yARxv/coCD6d0AAIDKkFTAYlI9/gCaK/wXAMksAaNAmoTFCSfM3SwkA== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: i2rs@ietf.org, i2rs-chairs@ietf.org, 'Kathleen Moriarty' , 'The IESG' , jhaas@pfrc.org, 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Aug 2016 15:31:00 -0000 Joel and Kathleen: Just for the record, I disagree that putting in Yang 1.1 is awkward. It is only a key-word on an item that gives information to a implementation what transports can be used to transport data. If the telemetry information is events (pub/sub), then this telemetry information could encode it to go on secure stream or an insecure stream. If we are going to say that something is too difficult, I would like to discuss this point. Large routing systems are not what NETCONF/RESTCONF has been designing for the last 5 years. This telemetry information is target at those systems. The changes that I2RS is pushing is for routing systems. One of the reasons that Juergen and I disagree on the difficulty of the work is different of focus of IP systems (1-20 interfaces) and the large routing systems. I have given you BGP examples from Large routing systems. I believe this is necessary for large routing systems to give the BGP telemetry information to aid provider networks. I welcome comments from Joel on the usefulness of the BGP Route View information. +1 on the disconnect between the WG and the IESG. The I2RS architecture has the concept of an unsecure channel. Sue -----Original Message----- From: Joel Halpern [mailto:joel.halpern@ericsson.com] Sent: Thursday, August 18, 2016 10:31 AM To: Susan Hares; 'Juergen Schoenwaelder' Cc: i2rs@ietf.org; i2rs-chairs@ietf.org; 'Kathleen Moriarty'; 'The IESG'; jhaas@pfrc.org; 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) Let me try a different take approach to this particular question. Let me start by putting aside the question of where things are marked, and come back to that afterwards. There are a number of cases that I2RS has been asked to cover of high rate telemetry data. This may be BGP update information, it may be frequent information about line card activity. There are other cases, some of which have been documented. While not completely insensitive, the operators have made clear that they see protecting this data as unnecessary. While I would hope over time to move to a domain where all of it is protect, that is not trivial. As the I2RS Architecture points out, it is expected that what we describe as a single I2RS communication between a client and agent is actually associated with multiple channels of communication. Now, if you want to say that the I2RS protocol requirements cannot allow for unprotected channels, I guess we have disconnect between the IESG and the WG. If we say that we can allow for unprotected channels, we then get to the question of which data can be sent over such channels. While architecturally I agree with Juergen that the model is a bad place to specify it, the obverse is also true. Not having some limits on what can be sent unprotected causes concern about insufficient protection. If I recall correctly, earlier security reviews called us to task for being too broad in what we allowed. So, if the IESG wants us to just allow it anywhere, because the model is an awkward place to define the limitation, I can live with that. What I can't live with is being told both that the model is a bad place to define it and that there must be restrictions on what is sent unprotected, without any proposal on how we are to move forward. Yours, Joel -----Original Message----- From: Susan Hares [mailto:shares@ndzh.com] Sent: Thursday, August 18, 2016 9:17 AM To: 'Juergen Schoenwaelder' Cc: i2rs@ietf.org; i2rs-chairs@ietf.org; 'Kathleen Moriarty' ; 'The IESG' ; jhaas@pfrc.org; 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) Juergen and Kathleen: Let me proceed with two examples: BGP route views data model and the event for the web-service data. The content of these data models are designated as exposed to public. The routing system only populates the proposed BGP route views data model with the data destined for the BGP looking glass. The policy on the routing system indicates what information gets transferred. The data model is completely available to the public. The Yang Doctors are going to review this by seeing the whole model is public and available via non-secure means. The security people are going to review this seeing that the whole model is public, and available via an unprotect means. The fact the data model is all public should simplify the review. An event from the I2RS RIB that a web-service route is up is the second case. The I2RS RIB has an event based on policy that indicates a web-service route is up. The yang-1.1 doctors must review the content of the event text to see it does not break privacy or provide too much information The event mechanisms will need to work over secure transport and insecure transport. Most of the data will go over the secure transport event stream. However, a small amount of information may go over the insecure transport stream. First, let me know if my use cases are understandable. Second, let me know if you disagree with this use cases. Fyi - IESG approved the architecture with the insecure stream. Sue -----Original Message----- From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de] Sent: Thursday, August 18, 2016 9:06 AM To: Susan Hares Cc: i2rs@ietf.org; i2rs-chairs@ietf.org; 'Kathleen Moriarty'; 'The IESG'; jhaas@pfrc.org; 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) I just do not know on which basis a data model writer can decide whether a data object can be exposed in an unprotected way. How are YANG doctors going to review this? How are security directorate people going to judge this? But as promised, I leave (still puzzled) now. /js On Thu, Aug 18, 2016 at 09:00:14AM -0400, Susan Hares wrote: > Juergen: > > Yes, we seem to disagree on the value of making it hardwired in the model. > For me, the value is a common understanding of deployment distribution such > as the route-views. Since the operators argued strongly for this point, I > think the best idea is to get it working in code and then see if the > deployment matches the requests. > > Sue > > -----Original Message----- > From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Juergen > Schoenwaelder > Sent: Thursday, August 18, 2016 8:14 AM > To: Susan Hares > Cc: i2rs@ietf.org; i2rs-chairs@ietf.org; 'Kathleen Moriarty'; 'The > IESG'; jhaas@pfrc.org; > 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) > > Sue, > > I still do not see why the 'mode of exposure' of data benefits from > being hard-wired in the data model. For me, it is a situational and > deployment specific question. But I shut up here since I aired this > concern before (and we simply seem to disagree). > > /js > > On Thu, Aug 18, 2016 at 08:07:18AM -0400, Susan Hares wrote: > > Juergen: > > > > My example is the looking glass servers for the BGP route views > > project > > (http://www.routeviews.org/) or a route indicating the presence of a > > web-server that is public. For the BGP I2RS route, a yang model could > > replace the looking glass function, and provide events for these looking > > glass functions. For the web-server route, an event be sent when that > > one route is added. > > > > Sue > > > > > > -----Original Message----- > > From: Juergen Schoenwaelder > > [mailto:j.schoenwaelder@jacobs-university.de] > > Sent: Thursday, August 18, 2016 3:32 AM > > To: Susan Hares > > Cc: 'Kathleen Moriarty'; 'The IESG'; jhaas@pfrc.org; i2rs@ietf.org; > > i2rs-chairs@ietf.org; > > 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 Wed, Aug 17, 2016 at 09:16:48PM -0400, Susan Hares wrote: > > > ------------------------------------------------------------------ > > > -- > > > -- > > > COMMENT: > > > ------------------------------------------------------------------ > > > -- > > > -- > > > > > > > Section 3: > > > > Can you clarify the second to last sentence? Do you mean there > > > > are > > sections that indicate an insecure transport should be used? > > > > I2RS allows the use of an > > > > insecure transport for portions of data models that clearly > > > > indicate insecure transport. > > > > > > > Perhaps: > > > > I2RS allows the use of an > > > > insecure transport for portions of data models that clearly > > > > indicate the use of an insecure transport. > > > > I still wonder how a data model writer can reasonably decide whether > > a piece of information can be shipped safely over an insecure > > transport since this decision often depends on the specifics of a > > deployment > situation. > > > > /js > > > > PS: I hope we do not end up with defining data multiple times (once > > for insecure transport and once for secured transports). > > > > -- > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > > Fax: +49 421 200 3103 > > > > _______________________________________________ > > i2rs mailing list > > i2rs@ietf.org > > https://www.ietf.org/mailman/listinfo/i2rs > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs > -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Thu Aug 18 08:33:07 2016 Return-Path: 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 284CA12D7F4; Thu, 18 Aug 2016 08:33:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.738 X-Spam-Level: * X-Spam-Status: No, score=1.738 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, RDNS_NONE=0.793] autolearn=no 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 XtU4LLO-oHFZ; Thu, 18 Aug 2016 08:33:01 -0700 (PDT) Received: from hickoryhill-consulting.com (unknown [50.245.122.97]) (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 6E40812D796; Thu, 18 Aug 2016 08:33:00 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=174.124.167.170; From: "Susan Hares" To: "'Kathleen Moriarty'" References: <147144567895.12152.15403435188950086025.idtracker@ietfa.amsl.com> <5B604C19-7AEF-4C92-B452-A034749A5FCA@cooperw.in> <063101d1f957$9679ca10$c36d5e30$@ndzh.com> In-Reply-To: Date: Thu, 18 Aug 2016 11:31:53 -0400 Message-ID: <06b901d1f965$a61656b0$f2430410$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQG3q3aG/0u2B1HfPippUnE2NxzEQwGi2QgoAk3GCFUB6JhdAADJV/ysAeisWk0Cq5OlZqApvaRA Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: i2rs@ietf.org, 'Alissa Cooper' , i2rs-chairs@ietf.org, 'Alia Atlas' , iesg@ietf.org, 'Jeffrey Haas' , draft-ietf-i2rs-protocol-security-requirements@ietf.org, 'Stephen Farrell' Subject: Re: [i2rs] Alissa Cooper's Discuss on draft-ietf-i2rs-protocol-security-requirements-06: (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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Aug 2016 15:33:02 -0000 Thank you for letting me know the reasons and the schedule. I will make = time next week to do additional changes. I have a version-09 begun = with Alvaro's comments. Are there other changes I should include in = version -09.txt? Sue=20 -----Original Message----- From: Kathleen Moriarty [mailto:kathleen.moriarty.ietf@gmail.com]=20 Sent: Thursday, August 18, 2016 9:58 AM To: Susan Hares Cc: Stephen Farrell; i2rs@ietf.org; Alissa Cooper; i2rs-chairs@ietf.org; = Alia Atlas; iesg@ietf.org; Jeffrey Haas; = draft-ietf-i2rs-protocol-security-requirements@ietf.org Subject: Re: [i2rs] Alissa Cooper's Discuss on = draft-ietf-i2rs-protocol-security-requirements-06: (with DISCUSS and = COMMENT) On Thu, Aug 18, 2016 at 9:51 AM, Susan Hares wrote: > Kathleen and Stephen: > > Can you tell me the reason for defer? Alia will not be there in the = next formal telechat - so no responsible AD will be there for the = document. Stephen is on vacation and can't read the draft, but would like to read = it. I chatted with Alia on it and if Stephen can read it next week to = resolve any findings while Alia is not on vacation, this should be fine = on the next telechat as she could set the appropriate action in place = before the call (or before she leaves for vacation). Thanks, Kathleen > > Sue > > -----Original Message----- > From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Kathleen=20 > Moriarty > Sent: Thursday, August 18, 2016 9:48 AM > To: Stephen Farrell > Cc: i2rs@ietf.org; Alissa Cooper; i2rs-chairs@ietf.org; Alia Atlas;=20 > iesg@ietf.org; Jeffrey Haas;=20 > draft-ietf-i2rs-protocol-security-requirements@ietf.org > Subject: Re: [i2rs] Alissa Cooper's Discuss on=20 > draft-ietf-i2rs-protocol-security-requirements-06: (with DISCUSS and=20 > COMMENT) > > On Wed, Aug 17, 2016 at 2:24 PM, wrote: >> Hiya, >> >> I'm on vacation so won't be balloting this week and I only had a = quick flick of this, but if I'd had time for a proper read I think I'd = be asking how realistic are these requirements, possibly as a discuss = ballot. If someone wanted to hit defer and blame me (sorry I don't have = the right devices with me to do that) that'd be good. But if this draft = is time-critical for the WG then please ignore the above. > > I hit the defer button for Stephen. Alia doesn't want this to sit too = long, so we'll ave to be good about wrapping it up as there are other = groups waiting on it. > > Thanks, > Kathleen > >> >> S. >> >> On Wed Aug 17 19:02:09 2016 GMT+0200, Alissa Cooper wrote: >>> Hi Alia, >>> >>> > On Aug 17, 2016, at 11:07 AM, Alia Atlas = wrote: >>> > >>> > Hi Alissa, >>> > >>> > On Wed, Aug 17, 2016 at 10:54 AM, Alissa Cooper > wrote: >>> > Alissa Cooper has entered the following ballot position for >>> > draft-ietf-i2rs-protocol-security-requirements-06: Discuss >>> > >>> > When responding, please keep the subject line intact and reply to=20 >>> > all email addresses included in the To and CC lines. (Feel free to = >>> > cut this introductory paragraph, however.) >>> > >>> > >>> > Please refer to >>> > https://www.ietf.org/iesg/statement/discuss-criteria.html >>> > >>> > for more information about IESG DISCUSS and COMMENT positions. >>> > >>> > >>> > The document, along with other ballot positions, can be found = here: >>> > https://datatracker.ietf.org/doc/draft-ietf-i2rs-protocol-security >>> > - >>> > requirements/ >>> > >> > y >>> > -requirements/> >>> > >>> > >>> > >>> > ------------------------------------------------------------------ >>> > - >>> > --- >>> > DISCUSS: >>> > ------------------------------------------------------------------ >>> > - >>> > --- >>> > >>> > =3D=3D Section 3.2 =3D=3D >>> > >>> > "A non-secure transport can be 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." >>> > >>> > What kind of telemetry data is it that is of no potential interest = >>> > to any eavesdropper? This is not my area of expertise so I'm=20 >>> > having a hard time conceiving of what that could be. I'm also=20 >>> > wondering, since I2RS agents and clients will have to support=20 >>> > secure transports anyway (and RESTCONF can only be used over a=20 >>> > secure transport), why can't they be used for all transfers,=20 >>> > instead of allowing this loophole in the name of telemetry, which=20 >>> > undoubtedly will end up being used or exploited for other data = transfers? >>> > >>> > If the argument was that this loophole is needed for backwards=20 >>> > compatibility with insecure deployments of NETCONF or something=20 >>> > like that I think it would make more sense, but my impression from = >>> > the text is that those will have to be updated anyway to conform=20 >>> > to the requirements in this document. >>> > >>> > Data coming from a router can come from many different line-cards = and processors. >>> > The line-cards that may be providing the data are not going to be=20 >>> > supporting the secure transports anyway. >>> >>> Will they also not be supporting the I2RS protocol then, given the = requirement for support of a secure transport? >>> >>> >>> > A goal is to allow easy distribution of streaming data and event=20 >>> > notifications. As for what type of data, as far as I know,=20 >>> > currently IPFIX streams telemetry data without integrity much less = authorization protection. >>> >>> What I=E2=80=99m questioning is the choice to extend that model to = cases where a third-party controller or application is one endpoint of = the data exchange, which is what I thought was part of the motivation = for I2RS (happy to be corrected though). >>> >>> > >>> > There are existing deployments that use gRPC now for streaming = telemetry data. >>> >>> Ok. So is the implication that the requirements here are needed for = backwards compatability with those deployments? >>> >>> Thanks, >>> Alissa >>> >>> > >>> > Regards, >>> > Alia >>> > >>> > ------------------------------------------------------------------ >>> > - >>> > --- >>> > COMMENT: >>> > ------------------------------------------------------------------ >>> > - >>> > --- >>> > >>> > In general I agree with Mirja that where other documents already=20 >>> > provide definitions, they should be referenced, not copied or=20 >>> > summarized, in this document. >>> > >>> > =3D=3D Section 2.1 =3D=3D >>> > >>> > Using "privacy" as a synonym for "confidentiality" is outmoded, I=20 >>> > think, given current understanding of the many other facets of=20 >>> > privacy (see, e.g., RFC 6793). I would suggest dropping the=20 >>> > definition of data privacy and just using the word confidentiality = when that is what you mean. >>> > >>> > =3D=3D Section 2.2 =3D=3D >>> > >>> > "The I2RS protocol exists as a higher-level protocol which may >>> > combine other protocols (NETCONF, RESTCONF, IPFIX and = others) >>> > within a specific I2RS client-agent relationship with a = specific >>> > trust for ephemeral configurations, event, tracing, actions, = and >>> > data flow interactions." >>> > >>> > Reading the provided definition of "trust," I'm not sure what=20 >>> > "with a specific trust for" means in the sentence above. >>> > >>> > "The I2RS architecture document [I-D.ietf-i2rs-architecture] >>> > defines a secondary identity as the entity of some non-I2RS = entity >>> > (e.g. application) which has requested a particular I2RS = client >>> > perform an operation." >>> > >>> > Per my comment above, I would suggest just referencing the=20 >>> > definition from the architecture document. The text above is=20 >>> > circular ("the entity of some ... entity") and conflates an = identity with an identifier. >>> > >>> > =3D=3D Section 3.1 =3D=3D >>> > >>> > Agree with Mirja that this section is superfluous. >>> > >>> > =3D=3D Section 3.3 =3D=3D >>> > >>> > Since the normative recommendation here isn't to be enforced by=20 >>> > the protocol, why is it SHOULD rather than MUST? Same question=20 >>> > applies to SEC-REQ-17. >>> > >>> > =3D=3D Section 3.5 =3D=3D >>> > >>> > Is the omission of normative language from Sec-REQ-20 purposeful? >>> >>> > > > > -- > > Best regards, > Kathleen > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs > --=20 Best regards, Kathleen From nobody Thu Aug 18 09:55:18 2016 Return-Path: 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 90DAA12DA71; Thu, 18 Aug 2016 09:54:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.721 X-Spam-Level: X-Spam-Status: No, score=-2.721 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_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cooperw.in header.b=FE06YrAW; dkim=pass (1024-bit key) header.d=messagingengine.com header.b=r8AntMNf 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 xVvheuF8L2bH; Thu, 18 Aug 2016 09:53:57 -0700 (PDT) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BED9512D1ED; Thu, 18 Aug 2016 09:53:57 -0700 (PDT) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 1654E2045E; Thu, 18 Aug 2016 12:53:57 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute3.internal (MEProxy); Thu, 18 Aug 2016 12:53:57 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=cooperw.in; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-sasl-enc :x-sasl-enc; s=mesmtp; bh=jE3LuIFbeCLqCngZ3V8LRosWWC8=; b=FE06Yr AWqYWsVvBlx50YEpCPrvZe6sCJW4LvkfM5hv+dIUqjpt0UwpHnZkKb4fpNTiC/u6 5JIlftmwA1bSCOp2UEZpv/goyfx6Capm1jFH8zCrAWSvkFHZFVyfUA5XVQT+6vAg VvGeBmvL4pP+5rslKw5766xsLAT8t7Fn9ozLE= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=jE3LuIFbeCLqCng Z3V8LRosWWC8=; b=r8AntMNfzIG7ZR9kHI3NeH56HjApREYKp/AM1yzBx88R7Zi WY57YEj9h3eSI8MUDhf6Gl69pL/w4g1bVTv04Ew+kNmUbjett0/D+sFhVE46QsSQ wWr9ddfq1iaYBCAZmJaTmtgJLRP1Kfu4Jdru9XbGfRffoF6141lmPc4esDHU= X-Sasl-enc: 0efvjAsgr2KdWK5YTvSpxSvteV/x8f++6nVV6UlS544G 1471539236 Received: from sjc-alcoop-8813.cisco.com (unknown [128.107.241.179]) by mail.messagingengine.com (Postfix) with ESMTPA id 3679DCCD83; Thu, 18 Aug 2016 12:53:55 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Alissa Cooper In-Reply-To: <6BCE198E4EAEFC4CAB45D75826EFB0761525CCD7@eusaamb101.ericsson.se> Date: Thu, 18 Aug 2016 12:53:53 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <147146974235.23784.4389421535496134619.idtracker@ietfa.amsl.com> <013b01d1f8ee$31fa09b0$95ee1d10$@ndzh.com> <20160818073203.GA4338@elstar.local> <04b501d1f949$116c63e0$34452ba0$@ndzh.com> <20160818121405.GA5282@elstar.local> <051301d1f950$7739c670$65ad5350$@ndzh.com> <20160818130555.GA5366@elstar.local> <051701d1f952$c4ae0b30$4e0a2190$@ndzh.com> <6BCE198E4EAEFC4CAB45D75826EFB0761525CCD7@eusaamb101.ericsson.se> To: Joel Halpern X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "i2rs@ietf.org" , Juergen Schoenwaelder , "i2rs-chairs@ietf.org" , Kathleen Moriarty , IESG , "jhaas@pfrc.org" , Susan Hares , "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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Aug 2016 16:54:35 -0000 Jumping in here because this is relevant to my DISCUSS, hope nobody = minds (but if you do, I can go back to the other thread). > On Aug 18, 2016, at 10:30 AM, Joel Halpern = wrote: >=20 > Let me try a different take approach to this particular question. >=20 > Let me start by putting aside the question of where things are marked, = and come back to that afterwards. >=20 > There are a number of cases that I2RS has been asked to cover of high = rate telemetry data. This may be BGP update information, it may be = frequent information about line card activity. There are other cases, = some of which have been documented. >=20 > While not completely insensitive, the operators have made clear that = they see protecting this data as unnecessary. While I would hope over = time to move to a domain where all of it is protect, that is not = trivial. As the I2RS Architecture points out, it is expected that what = we describe as a single I2RS communication between a client and agent is = actually associated with multiple channels of communication. >=20 > Now, if you want to say that the I2RS protocol requirements cannot = allow for unprotected channels, I guess we have disconnect between the = IESG and the WG. >=20 > If we say that we can allow for unprotected channels, we then get to = the question of which data can be sent over such channels. While = architecturally I agree with Juergen that the model is a bad place to = specify it, the obverse is also true. Not having some limits on what = can be sent unprotected causes concern about insufficient protection. = If I recall correctly, earlier security reviews called us to task for = being too broad in what we allowed. >=20 > So, if the IESG wants us to just allow it anywhere, because the model = is an awkward place to define the limitation, I can live with that. = What I can't live with is being told both that the model is a bad place = to define it and that there must be restrictions on what is sent = unprotected, without any proposal on how we are to move forward. Thank you Joel, this explanation helps me a lot. I think there is a = disconnect about how the restrictions are expressed. =46rom reading the = email traffic about this document, it strikes me that trying to express = the restrictions programmatically doesn=E2=80=99t make much sense in = this case. I agree with Juergen that it will be challenging to make a = judgment a priori in order to bake a restriction into a data model, = because data that is considered sensitive enough to warrant a secure = transport in one deployment may not be considered sensitive in another = deployment. So for any data elements where there is any question at all = about whether they might be sensitive (i.e., any data elements that are = not already routinely made public), I would expect data model authors to = end up indicating that they may be sent over either secure or insecure = transport, which renders the indication not useful. Perhaps it would make more sense then to just enumerate in the text the = cases that motivate the inclusion of protocol support for insecure = transport: 1. For conveyance of information that is already routinely made public. 2. For line card activity data where there is no likely upgrade path to = support secure transports in the foreseeable future. Then the normative requirements would be on clients and agents to use = secure transports unless those clients and agents are deployed where = either of the operational circumstances above necessitate otherwise. Alissa >=20 > Yours, > Joel >=20 > -----Original Message----- > From: Susan Hares [mailto:shares@ndzh.com]=20 > Sent: Thursday, August 18, 2016 9:17 AM > To: 'Juergen Schoenwaelder' > Cc: i2rs@ietf.org; i2rs-chairs@ietf.org; 'Kathleen Moriarty' = ; 'The IESG' ; = jhaas@pfrc.org; 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) >=20 > Juergen and Kathleen:=20 >=20 > Let me proceed with two examples: BGP route views data model and the = event for the web-service data. =20 >=20 > The content of these data models are designated as exposed to public. = The routing system only populates the proposed BGP route views data = model with the data destined for the BGP looking glass. The policy on = the routing system indicates what information gets transferred. The = data model is completely available to the public. The Yang Doctors are = going to review this by seeing the whole model is public and available = via non-secure means. > The security people are going to review this seeing that the whole = model is public, and available via an unprotect means. The fact the = data model is all public should simplify the review.=20 >=20 > An event from the I2RS RIB that a web-service route is up is the = second case. The I2RS RIB has an event based on policy that indicates a = web-service route is up. The yang-1.1 doctors must review the content = of the event text to see it does not break privacy or provide too much > information The event mechanisms will need to work over secure = transport > and insecure transport. Most of the data will go over the secure = transport event stream. However, a small amount of information may go = over the insecure transport stream.=20 >=20 > First, let me know if my use cases are understandable. Second, let me = know if you disagree with this use cases.=20 >=20 > Fyi - IESG approved the architecture with the insecure stream.=20 >=20 > Sue=20 >=20 > -----Original Message----- > From: Juergen Schoenwaelder = [mailto:j.schoenwaelder@jacobs-university.de] > Sent: Thursday, August 18, 2016 9:06 AM > To: Susan Hares > Cc: i2rs@ietf.org; i2rs-chairs@ietf.org; 'Kathleen Moriarty'; 'The = IESG'; jhaas@pfrc.org; = 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) >=20 > I just do not know on which basis a data model writer can decide = whether a data object can be exposed in an unprotected way. How are YANG = doctors going to review this? How are security directorate people going = to judge this? But as promised, I leave (still puzzled) now. >=20 > /js >=20 > On Thu, Aug 18, 2016 at 09:00:14AM -0400, Susan Hares wrote: >> Juergen:=20 >>=20 >> Yes, we seem to disagree on the value of making it hardwired in the = model. >> For me, the value is a common understanding of deployment = distribution > such >> as the route-views. Since the operators argued strongly for this = point, > I >> think the best idea is to get it working in code and then see if the=20= >> deployment matches the requests. >>=20 >> Sue >>=20 >> -----Original Message----- >> From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Juergen=20 >> Schoenwaelder >> Sent: Thursday, August 18, 2016 8:14 AM >> To: Susan Hares >> Cc: i2rs@ietf.org; i2rs-chairs@ietf.org; 'Kathleen Moriarty'; 'The=20 >> IESG'; jhaas@pfrc.org;=20 >> 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) >>=20 >> Sue, >>=20 >> I still do not see why the 'mode of exposure' of data benefits from=20= >> being hard-wired in the data model. For me, it is a situational and=20= >> deployment specific question. But I shut up here since I aired this=20= >> concern before (and we simply seem to disagree). >>=20 >> /js >>=20 >> On Thu, Aug 18, 2016 at 08:07:18AM -0400, Susan Hares wrote: >>> Juergen:=20 >>>=20 >>> My example is the looking glass servers for the BGP route views=20 >>> project >>> (http://www.routeviews.org/) or a route indicating the presence of a >>> web-server that is public. For the BGP I2RS route, a yang model = could >>> replace the looking glass function, and provide events for these = looking >>> glass functions. For the web-server route, an event be sent when > that >>> one route is added. =20 >>>=20 >>> Sue >>>=20 >>>=20 >>> -----Original Message----- >>> From: Juergen Schoenwaelder >>> [mailto:j.schoenwaelder@jacobs-university.de] >>> Sent: Thursday, August 18, 2016 3:32 AM >>> To: Susan Hares >>> Cc: 'Kathleen Moriarty'; 'The IESG'; jhaas@pfrc.org; i2rs@ietf.org;=20= >>> i2rs-chairs@ietf.org;=20 >>> 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) >>>=20 >>> On Wed, Aug 17, 2016 at 09:16:48PM -0400, Susan Hares wrote: >>>> ------------------------------------------------------------------ >>>> -- >>>> -- >>>> COMMENT: >>>> ------------------------------------------------------------------ >>>> -- >>>> -- >>>>=20 >>>>> Section 3:=20 >>>>> Can you clarify the second to last sentence? Do you mean there=20 >>>>> are >>> sections that indicate an insecure transport should be used? >>>>> I2RS allows the use of an >>>>> insecure transport for portions of data models that clearly=20 >>>>> indicate insecure transport. >>>>=20 >>>>> Perhaps: >>>>> I2RS allows the use of an >>>>> insecure transport for portions of data models that clearly=20 >>>>> indicate the use of an insecure transport. >>>=20 >>> I still wonder how a data model writer can reasonably decide whether=20= >>> a piece of information can be shipped safely over an insecure=20 >>> transport since this decision often depends on the specifics of a=20 >>> deployment >> situation. >>>=20 >>> /js >>>=20 >>> PS: I hope we do not end up with defining data multiple times (once >>> for insecure transport and once for secured transports). >>>=20 >>> --=20 >>> Juergen Schoenwaelder Jacobs University Bremen gGmbH >>> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | = Germany >>> Fax: +49 421 200 3103 >>>=20 >>> _______________________________________________ >>> i2rs mailing list >>> i2rs@ietf.org >>> https://www.ietf.org/mailman/listinfo/i2rs >>=20 >> --=20 >> Juergen Schoenwaelder Jacobs University Bremen gGmbH >> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | = Germany >> Fax: +49 421 200 3103 >>=20 >> _______________________________________________ >> i2rs mailing list >> i2rs@ietf.org >> https://www.ietf.org/mailman/listinfo/i2rs >>=20 >=20 > --=20 > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 >=20 From nobody Thu Aug 18 11:36:26 2016 Return-Path: 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 1411012D8FE; Thu, 18 Aug 2016 11:36:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.738 X-Spam-Level: * X-Spam-Status: No, score=1.738 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, RDNS_NONE=0.793] autolearn=no 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 FcZxHNZuxcqu; Thu, 18 Aug 2016 11:36:22 -0700 (PDT) Received: from hickoryhill-consulting.com (unknown [50.245.122.97]) (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 30F5A12D751; Thu, 18 Aug 2016 11:36:22 -0700 (PDT) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=70.194.9.169; From: "Susan Hares" To: "'Alissa Cooper'" , "'Joel Halpern'" References: <147146974235.23784.4389421535496134619.idtracker@ietfa.amsl.com> <013b01d1f8ee$31fa09b0$95ee1d10$@ndzh.com> <20160818073203.GA4338@elstar.local> <04b501d1f949$116c63e0$34452ba0$@ndzh.com> <20160818121405.GA5282@elstar.local> <051301d1f950$7739c670$65ad5350$@ndzh.com> <20160818130555.GA5366@elstar.local> <051701d1f952$c4ae0b30$4e0a2190$@ndzh.com> <6BCE198E4EAEFC4CAB45D75826EFB0761525CCD7@eusaamb101.ericsson.se> In-Reply-To: Date: Thu, 18 Aug 2016 14:35:03 -0400 Message-ID: <003801d1f97f$3d16eb10$b744c130$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Content-Language: en-us Thread-Index: AQIa7Lz6VgZw6h2A0uGNzOgAA2Ic8QJ/RF5yARxv/coCD6d0AAIDKkFTAYlI9/gCaK/wXAMksAaNAmoTFCQCp9Oi8J8eWM5g X-Authenticated-User: skh@ndzh.com Archived-At: Cc: i2rs@ietf.org, 'Juergen Schoenwaelder' , i2rs-chairs@ietf.org, 'Kathleen Moriarty' , 'IESG' , jhaas@pfrc.org, 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Aug 2016 18:36:25 -0000 Alissa:=20 Just a little input you may not know. My background is 15 years = (1995-2010) developing a routing/switching platform (denoted as GateD) = which was sold to over 200 companies. We developed XML and a binary = XML based product that configured this product. It could do 100K = configuration lines and reboot in less than a second on most hardware. = We also provide status messages in secure streams and non-secure = streams. I sold early version of this code to companies that Alia has = worked for - so she has personal viewed the code. At the height of = our work, our development team ran to 50 people which I directed (First = as VP of Engineering, and then as CTO). It is due to this level of = experience that Alia selected me for the co-chair. Russ White has = understood Cisco's process, and has also directed software development = teams for routing.=20 In order to freshen my direct experience with I2RS on open source work, = I am working on a publically available work in Quagga based on the confD = product suggested by Cisco.=20 In contrast, Juergen is a university professor who has worked on = proto-types. He is not working on an implementation. I hope he will. = I hope you will consider this background in my response to your comments = below.=20 Sue=20 -----Original Message----- From: Alissa Cooper [mailto:alissa@cooperw.in]=20 Sent: Thursday, August 18, 2016 12:54 PM To: Joel Halpern Cc: Susan Hares; Juergen Schoenwaelder; i2rs@ietf.org; = i2rs-chairs@ietf.org; Kathleen Moriarty; IESG; jhaas@pfrc.org; = 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) Jumping in here because this is relevant to my DISCUSS, hope nobody = minds (but if you do, I can go back to the other thread). >> On Aug 18, 2016, at 10:30 AM, Joel Halpern = wrote: >>=20 >> Let me try a different take approach to this particular question. >>=20 >> Let me start by putting aside the question of where things are = marked, and come back to that afterwards. >>=20 >> There are a number of cases that I2RS has been asked to cover of high = rate telemetry data. This may be BGP update information, it may be = frequent information about line card activity. There are other cases, = some of which have been documented. >>=20 >> While not completely insensitive, the operators have made clear that = they see protecting this data as unnecessary. While I would hope over = time to move to a domain where all of it is protect, that is not = trivial. As the I2RS Architecture points out, it is expected that what = we describe as a single I2RS >communication between a client and agent = is actually associated with multiple channels of communication. >>=20 >> Now, if you want to say that the I2RS protocol requirements cannot = allow for unprotected channels, I guess we have disconnect between the = IESG and the WG. >>=20 >> If we say that we can allow for unprotected channels, we then get to = the question of which data can be sent over such channels. While = architecturally I agree with Juergen that the model is a bad place to = specify it, the obverse is also true. Not having some limits on what = can be sent unprotected >causes concern about insufficient protection. = If I recall correctly, earlier security reviews called us to task for = being too broad in what we allowed. >>=20 >> So, if the IESG wants us to just allow it anywhere, because the model = is an awkward place to define the limitation, I can live with that. = What I can't live with is being told both that the model is a bad place = to define it and that there must be restrictions on what is sent = unprotected,=20 >> without any proposal on how we are to move forward. > Thank you Joel, this explanation helps me a lot. I think there is a = disconnect about how the restrictions are expressed. From reading the = email traffic about this document, it strikes me that trying to express = the restrictions programmatically doesn=E2=80=99t make much sense in = this case.=20 > I agree with Juergen that it will be challenging to make a judgment a = priori in order to bake a restriction into a data model, because data = that is considered sensitive enough to warrant a secure transport in one = deployment may not be considered sensitive in another deployment.=20 > So for any data elements where there is any question at all about = whether they might be sensitive (i.e., any data elements that are not = already routinely made public),=20 > I would expect data model authors to end up indicating that they may = be sent over either secure or insecure transport, which renders the = indication not useful. > Perhaps it would make more sense then to just enumerate in the text = the cases that motivate the inclusion of protocol support for insecure = transport: >=20 > 1. For conveyance of information that is already routinely made = public. > 2. For line card activity data where there is no likely upgrade path = to support secure transports in the foreseeable future. >=20 > Then the normative requirements would be on clients and agents to use = secure transports unless those clients and agents are deployed where = either of the operational circumstances above necessitate otherwise. > Alissa Point 1:=20 I disagree with Juergen on the difficulty in specifying the sections of = the yang modules. I have provided a suggested solution in:=20 https://tools.ietf.org/html/draft-hares-i2rs-protocol-strawman-03#section= -4.5.2. =20 Given the mount schema functionality, we can mount ephemeral state = module which augment non-ephemeral state modules which are "in-secure = only". =20 Point 2:=20 I am willing to put an enumeration of the use cases in the protocol = requirement, but I would like to understand the purpose for the = enumeration. We are not doing a use case, but a requirements document. = This information appears to be a "use case" rather than a technical = description. What purpose are you looking for this enumeration to = server. Are you looking for the enumeration in SEC-REQ-08?=20 Point 3: Could you review -08.txt on this topic, especially the text = below. Given your comments, I believe I should change the last line to = a MUST.=20 New/ The default mode of transport is secure so data models MUST clearly annotate what data nodes can be passed over an insecure connection. / Sue=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=20 As to the normative requirements (-08.txt) version:=20 Section 3:=20 =20 I2RS allows the use of an insecure transport for portions of data models that clearly indicate the use of an insecure transport. Operators deploying I2RS must determine if they want to populate and deploy the portions of the data model which use insecure transports. In Section 3.2 in version -08.txt=20 SEC-REQ-08: The I2RS protocol MUST be able to transfer data over a secure transport and optionally MAY be able to transfer data over a non-secure transport. A secure transport MUST provide data confidentiality, data integrity, and replay prevention. The default I2RS transport is a secure transport. 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. The configuration of ephemeral data in the I2RS Agent by the I2RS client SHOULD be done over a secure transport. It is anticipated that the passing of most I2RS ephemeral state operational status SHOULD be done over a secure transport. As [I-D.ietf-i2rs-ephemeral-state] notes, a data model MUST indicate whether the transport exchanging the data between I2RS client and I2RS agent is secure or insecure. =20 The default mode of transport is secure so data models SHOULD clearly annotate what data nodes can be passed over an insecure connection. >=20 > Yours, > Joel >=20 > -----Original Message----- > From: Susan Hares [mailto:shares@ndzh.com] > Sent: Thursday, August 18, 2016 9:17 AM > To: 'Juergen Schoenwaelder' > Cc: i2rs@ietf.org; i2rs-chairs@ietf.org; 'Kathleen Moriarty'=20 > ; 'The IESG' ;=20 > jhaas@pfrc.org;=20 > draft-ietf-i2rs-protocol-security-requirements@ietf.org > Subject: RE: [i2rs] Kathleen Moriarty's Discuss on=20 > draft-ietf-i2rs-protocol-security-requirements-07: (with DISCUSS and=20 > COMMENT) >=20 > Juergen and Kathleen:=20 >=20 > Let me proceed with two examples: BGP route views data model and the = event for the web-service data. =20 >=20 > The content of these data models are designated as exposed to public. = The routing system only populates the proposed BGP route views data = model with the data destined for the BGP looking glass. The policy on = the routing system indicates what information gets transferred. The = data model is completely available to the public. The Yang Doctors are = going to review this by seeing the whole model is public and available = via non-secure means. > The security people are going to review this seeing that the whole = model is public, and available via an unprotect means. The fact the = data model is all public should simplify the review.=20 >=20 > An event from the I2RS RIB that a web-service route is up is the = second case. The I2RS RIB has an event based on policy that indicates a = web-service route is up. The yang-1.1 doctors must review the content = of the event text to see it does not break privacy or provide too much > information The event mechanisms will need to work over secure = transport > and insecure transport. Most of the data will go over the secure = transport event stream. However, a small amount of information may go = over the insecure transport stream.=20 >=20 > First, let me know if my use cases are understandable. Second, let me = know if you disagree with this use cases.=20 >=20 > Fyi - IESG approved the architecture with the insecure stream.=20 >=20 > Sue >=20 > -----Original Message----- > From: Juergen Schoenwaelder=20 > [mailto:j.schoenwaelder@jacobs-university.de] > Sent: Thursday, August 18, 2016 9:06 AM > To: Susan Hares > Cc: i2rs@ietf.org; i2rs-chairs@ietf.org; 'Kathleen Moriarty'; 'The=20 > IESG'; jhaas@pfrc.org;=20 > 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) >=20 > I just do not know on which basis a data model writer can decide = whether a data object can be exposed in an unprotected way. How are YANG = doctors going to review this? How are security directorate people going = to judge this? But as promised, I leave (still puzzled) now. >=20 > /js >=20 > On Thu, Aug 18, 2016 at 09:00:14AM -0400, Susan Hares wrote: >> Juergen:=20 >>=20 >> Yes, we seem to disagree on the value of making it hardwired in the = model. >> For me, the value is a common understanding of deployment=20 >> distribution > such >> as the route-views. Since the operators argued strongly for this = point, > I >> think the best idea is to get it working in code and then see if the=20 >> deployment matches the requests. >>=20 >> Sue >>=20 >> -----Original Message----- >> From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Juergen=20 >> Schoenwaelder >> Sent: Thursday, August 18, 2016 8:14 AM >> To: Susan Hares >> Cc: i2rs@ietf.org; i2rs-chairs@ietf.org; 'Kathleen Moriarty'; 'The=20 >> IESG'; jhaas@pfrc.org;=20 >> 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) >>=20 >> Sue, >>=20 >> I still do not see why the 'mode of exposure' of data benefits from=20 >> being hard-wired in the data model. For me, it is a situational and=20 >> deployment specific question. But I shut up here since I aired this=20 >> concern before (and we simply seem to disagree). >>=20 >> /js >>=20 >> On Thu, Aug 18, 2016 at 08:07:18AM -0400, Susan Hares wrote: >>> Juergen:=20 >>>=20 >>> My example is the looking glass servers for the BGP route views=20 >>> project >>> (http://www.routeviews.org/) or a route indicating the presence of a >>> web-server that is public. For the BGP I2RS route, a yang model = could >>> replace the looking glass function, and provide events for these = looking >>> glass functions. For the web-server route, an event be sent when > that >>> one route is added. =20 >>>=20 >>> Sue >>>=20 >>>=20 >>> -----Original Message----- >>> From: Juergen Schoenwaelder >>> [mailto:j.schoenwaelder@jacobs-university.de] >>> Sent: Thursday, August 18, 2016 3:32 AM >>> To: Susan Hares >>> Cc: 'Kathleen Moriarty'; 'The IESG'; jhaas@pfrc.org; i2rs@ietf.org;=20 >>> i2rs-chairs@ietf.org;=20 >>> 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) >>>=20 >>> On Wed, Aug 17, 2016 at 09:16:48PM -0400, Susan Hares wrote: >>>> ------------------------------------------------------------------ >>>> -- >>>> -- >>>> COMMENT: >>>> ------------------------------------------------------------------ >>>> -- >>>> -- >>>>=20 >>>>> Section 3:=20 >>>>> Can you clarify the second to last sentence? Do you mean there=20 >>>>> are >>> sections that indicate an insecure transport should be used? >>>>> I2RS allows the use of an >>>>> insecure transport for portions of data models that clearly=20 >>>>> indicate insecure transport. >>>>=20 >>>>> Perhaps: >>>>> I2RS allows the use of an >>>>> insecure transport for portions of data models that clearly=20 >>>>> indicate the use of an insecure transport. >>>=20 >>> I still wonder how a data model writer can reasonably decide whether = >>> a piece of information can be shipped safely over an insecure=20 >>> transport since this decision often depends on the specifics of a=20 >>> deployment >> situation. >>>=20 >>> /js >>>=20 >>> PS: I hope we do not end up with defining data multiple times (once >>> for insecure transport and once for secured transports). >>>=20 >>> --=20 >>> Juergen Schoenwaelder Jacobs University Bremen gGmbH >>> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | = Germany >>> Fax: +49 421 200 3103 >>>=20 >>> _______________________________________________ >>> i2rs mailing list >>> i2rs@ietf.org >>> https://www.ietf.org/mailman/listinfo/i2rs >>=20 >> --=20 >> Juergen Schoenwaelder Jacobs University Bremen gGmbH >> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | = Germany >> Fax: +49 421 200 3103 >>=20 >> _______________________________________________ >> i2rs mailing list >> i2rs@ietf.org >> https://www.ietf.org/mailman/listinfo/i2rs >>=20 >=20 > --=20 > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 >=20 From nobody Thu Aug 18 12:57:22 2016 Return-Path: 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 7D31412B03D; Thu, 18 Aug 2016 12:57:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.738 X-Spam-Level: * X-Spam-Status: No, score=1.738 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, RDNS_NONE=0.793] autolearn=no 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 THSMYWlJWGXj; Thu, 18 Aug 2016 12:57:18 -0700 (PDT) Received: from hickoryhill-consulting.com (unknown [50.245.122.97]) (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 EF6FB12B027; Thu, 18 Aug 2016 12:57:17 -0700 (PDT) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=174.124.185.60; From: "Susan Hares" To: "'Alissa Cooper'" , "'Joel Halpern'" References: <147146974235.23784.4389421535496134619.idtracker@ietfa.amsl.com> <013b01d1f8ee$31fa09b0$95ee1d10$@ndzh.com> <20160818073203.GA4338@elstar.local> <04b501d1f949$116c63e0$34452ba0$@ndzh.com> <20160818121405.GA5282@elstar.local> <051301d1f950$7739c670$65ad5350$@ndzh.com> <20160818130555.GA5366@elstar.local> <051701d1f952$c4ae0b30$4e0a2190$@ndzh.com> <6BCE198E4EAEFC4CAB45D75826EFB0761525CCD7@eusaamb101.ericsson.se> In-Reply-To: Date: Thu, 18 Aug 2016 15:56:01 -0400 Message-ID: <010f01d1f98a$8c17ad20$a4470760$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIa7Lz6VgZw6h2A0uGNzOgAA2Ic8QJ/RF5yARxv/coCD6d0AAIDKkFTAYlI9/gCaK/wXAMksAaNAmoTFCQCp9Oi8J8egLMg Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: i2rs@ietf.org, 'Juergen Schoenwaelder' , i2rs-chairs@ietf.org, 'Kathleen Moriarty' , 'IESG' , jhaas@pfrc.org, 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Aug 2016 19:57:20 -0000 Alissa:=20 A follow-up email on this topic. Joel suggests that I missing your = question. Are you asking who is in a position to determine that certain = data is reasonable to send unprotected? =20 Are you asking if it is the operator, the data model designer, or our = original WG designing the protocol?=20 If this is the case, the final authority is the owner of the data - the = operator. The closer the operator works with vendors who supply code = and standardize it, the better the vendors understand the need. It is = hoped that the vendors and the operators will help I2RS or other WG to = define these data modules. We hope the security people from these = operators and security people from vendors and research will validate = the security needs. We believe we have a sense from the WG discussions = on the categories I mentioned: a) publically available data = (route-views), b) events specific to operators that are public, and c) = interface/data that can be seen publically (IXP ports or MEF exchange = ports)=20 Personally, I also want to be very careful with any data that can be = linked to a person. To me, this must be done over a secure transport. =20 Does this help? Like Joel - I am proactively answering you, but = confused on what you want me to change. =20 Sue=20 -----Original Message----- From: Alissa Cooper [mailto:alissa@cooperw.in]=20 Sent: Thursday, August 18, 2016 12:54 PM To: Joel Halpern Cc: Susan Hares; Juergen Schoenwaelder; i2rs@ietf.org; = i2rs-chairs@ietf.org; Kathleen Moriarty; IESG; jhaas@pfrc.org; = 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) Jumping in here because this is relevant to my DISCUSS, hope nobody = minds (but if you do, I can go back to the other thread). > On Aug 18, 2016, at 10:30 AM, Joel Halpern = wrote: >=20 > Let me try a different take approach to this particular question. >=20 > Let me start by putting aside the question of where things are marked, = and come back to that afterwards. >=20 > There are a number of cases that I2RS has been asked to cover of high = rate telemetry data. This may be BGP update information, it may be = frequent information about line card activity. There are other cases, = some of which have been documented. >=20 > While not completely insensitive, the operators have made clear that = they see protecting this data as unnecessary. While I would hope over = time to move to a domain where all of it is protect, that is not = trivial. As the I2RS Architecture points out, it is expected that what = we describe as a single I2RS communication between a client and agent is = actually associated with multiple channels of communication. >=20 > Now, if you want to say that the I2RS protocol requirements cannot = allow for unprotected channels, I guess we have disconnect between the = IESG and the WG. >=20 > If we say that we can allow for unprotected channels, we then get to = the question of which data can be sent over such channels. While = architecturally I agree with Juergen that the model is a bad place to = specify it, the obverse is also true. Not having some limits on what = can be sent unprotected causes concern about insufficient protection. = If I recall correctly, earlier security reviews called us to task for = being too broad in what we allowed. >=20 > So, if the IESG wants us to just allow it anywhere, because the model = is an awkward place to define the limitation, I can live with that. = What I can't live with is being told both that the model is a bad place = to define it and that there must be restrictions on what is sent = unprotected, without any proposal on how we are to move forward. Thank you Joel, this explanation helps me a lot. I think there is a = disconnect about how the restrictions are expressed. From reading the = email traffic about this document, it strikes me that trying to express = the restrictions programmatically doesn=E2=80=99t make much sense in = this case. I agree with Juergen that it will be challenging to make a = judgment a priori in order to bake a restriction into a data model, = because data that is considered sensitive enough to warrant a secure = transport in one deployment may not be considered sensitive in another = deployment. So for any data elements where there is any question at all = about whether they might be sensitive (i.e., any data elements that are = not already routinely made public), I would expect data model authors to = end up indicating that they may be sent over either secure or insecure = transport, which renders the indication not useful. Perhaps it would make more sense then to just enumerate in the text the = cases that motivate the inclusion of protocol support for insecure = transport: 1. For conveyance of information that is already routinely made public. 2. For line card activity data where there is no likely upgrade path to = support secure transports in the foreseeable future. Then the normative requirements would be on clients and agents to use = secure transports unless those clients and agents are deployed where = either of the operational circumstances above necessitate otherwise. Alissa >=20 > Yours, > Joel >=20 > -----Original Message----- > From: Susan Hares [mailto:shares@ndzh.com] > Sent: Thursday, August 18, 2016 9:17 AM > To: 'Juergen Schoenwaelder' > Cc: i2rs@ietf.org; i2rs-chairs@ietf.org; 'Kathleen Moriarty'=20 > ; 'The IESG' ;=20 > jhaas@pfrc.org;=20 > draft-ietf-i2rs-protocol-security-requirements@ietf.org > Subject: RE: [i2rs] Kathleen Moriarty's Discuss on=20 > draft-ietf-i2rs-protocol-security-requirements-07: (with DISCUSS and=20 > COMMENT) >=20 > Juergen and Kathleen:=20 >=20 > Let me proceed with two examples: BGP route views data model and the = event for the web-service data. =20 >=20 > The content of these data models are designated as exposed to public. = The routing system only populates the proposed BGP route views data = model with the data destined for the BGP looking glass. The policy on = the routing system indicates what information gets transferred. The = data model is completely available to the public. The Yang Doctors are = going to review this by seeing the whole model is public and available = via non-secure means. > The security people are going to review this seeing that the whole = model is public, and available via an unprotect means. The fact the = data model is all public should simplify the review.=20 >=20 > An event from the I2RS RIB that a web-service route is up is the = second case. The I2RS RIB has an event based on policy that indicates a = web-service route is up. The yang-1.1 doctors must review the content = of the event text to see it does not break privacy or provide too much > information The event mechanisms will need to work over secure = transport > and insecure transport. Most of the data will go over the secure = transport event stream. However, a small amount of information may go = over the insecure transport stream.=20 >=20 > First, let me know if my use cases are understandable. Second, let me = know if you disagree with this use cases.=20 >=20 > Fyi - IESG approved the architecture with the insecure stream.=20 >=20 > Sue >=20 > -----Original Message----- > From: Juergen Schoenwaelder=20 > [mailto:j.schoenwaelder@jacobs-university.de] > Sent: Thursday, August 18, 2016 9:06 AM > To: Susan Hares > Cc: i2rs@ietf.org; i2rs-chairs@ietf.org; 'Kathleen Moriarty'; 'The=20 > IESG'; jhaas@pfrc.org;=20 > 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) >=20 > I just do not know on which basis a data model writer can decide = whether a data object can be exposed in an unprotected way. How are YANG = doctors going to review this? How are security directorate people going = to judge this? But as promised, I leave (still puzzled) now. >=20 > /js >=20 > On Thu, Aug 18, 2016 at 09:00:14AM -0400, Susan Hares wrote: >> Juergen:=20 >>=20 >> Yes, we seem to disagree on the value of making it hardwired in the = model. >> For me, the value is a common understanding of deployment=20 >> distribution > such >> as the route-views. Since the operators argued strongly for this = point, > I >> think the best idea is to get it working in code and then see if the=20 >> deployment matches the requests. >>=20 >> Sue >>=20 >> -----Original Message----- >> From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Juergen=20 >> Schoenwaelder >> Sent: Thursday, August 18, 2016 8:14 AM >> To: Susan Hares >> Cc: i2rs@ietf.org; i2rs-chairs@ietf.org; 'Kathleen Moriarty'; 'The=20 >> IESG'; jhaas@pfrc.org;=20 >> 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) >>=20 >> Sue, >>=20 >> I still do not see why the 'mode of exposure' of data benefits from=20 >> being hard-wired in the data model. For me, it is a situational and=20 >> deployment specific question. But I shut up here since I aired this=20 >> concern before (and we simply seem to disagree). >>=20 >> /js >>=20 >> On Thu, Aug 18, 2016 at 08:07:18AM -0400, Susan Hares wrote: >>> Juergen:=20 >>>=20 >>> My example is the looking glass servers for the BGP route views=20 >>> project >>> (http://www.routeviews.org/) or a route indicating the presence of a >>> web-server that is public. For the BGP I2RS route, a yang model = could >>> replace the looking glass function, and provide events for these = looking >>> glass functions. For the web-server route, an event be sent when > that >>> one route is added. =20 >>>=20 >>> Sue >>>=20 >>>=20 >>> -----Original Message----- >>> From: Juergen Schoenwaelder >>> [mailto:j.schoenwaelder@jacobs-university.de] >>> Sent: Thursday, August 18, 2016 3:32 AM >>> To: Susan Hares >>> Cc: 'Kathleen Moriarty'; 'The IESG'; jhaas@pfrc.org; i2rs@ietf.org;=20 >>> i2rs-chairs@ietf.org;=20 >>> 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) >>>=20 >>> On Wed, Aug 17, 2016 at 09:16:48PM -0400, Susan Hares wrote: >>>> ------------------------------------------------------------------ >>>> -- >>>> -- >>>> COMMENT: >>>> ------------------------------------------------------------------ >>>> -- >>>> -- >>>>=20 >>>>> Section 3:=20 >>>>> Can you clarify the second to last sentence? Do you mean there=20 >>>>> are >>> sections that indicate an insecure transport should be used? >>>>> I2RS allows the use of an >>>>> insecure transport for portions of data models that clearly=20 >>>>> indicate insecure transport. >>>>=20 >>>>> Perhaps: >>>>> I2RS allows the use of an >>>>> insecure transport for portions of data models that clearly=20 >>>>> indicate the use of an insecure transport. >>>=20 >>> I still wonder how a data model writer can reasonably decide whether = >>> a piece of information can be shipped safely over an insecure=20 >>> transport since this decision often depends on the specifics of a=20 >>> deployment >> situation. >>>=20 >>> /js >>>=20 >>> PS: I hope we do not end up with defining data multiple times (once >>> for insecure transport and once for secured transports). >>>=20 >>> --=20 >>> Juergen Schoenwaelder Jacobs University Bremen gGmbH >>> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | = Germany >>> Fax: +49 421 200 3103 >>>=20 >>> _______________________________________________ >>> i2rs mailing list >>> i2rs@ietf.org >>> https://www.ietf.org/mailman/listinfo/i2rs >>=20 >> --=20 >> Juergen Schoenwaelder Jacobs University Bremen gGmbH >> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | = Germany >> Fax: +49 421 200 3103 >>=20 >> _______________________________________________ >> i2rs mailing list >> i2rs@ietf.org >> https://www.ietf.org/mailman/listinfo/i2rs >>=20 >=20 > --=20 > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 >=20 From nobody Thu Aug 18 12:58:57 2016 Return-Path: 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 3927512D8F4 for ; Thu, 18 Aug 2016 11:53:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.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 zdxIXAQKhihz for ; Thu, 18 Aug 2016 11:53:39 -0700 (PDT) Received: from mail-ua0-x229.google.com (mail-ua0-x229.google.com [IPv6:2607:f8b0:400c:c08::229]) (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 26F0C12D89B for ; Thu, 18 Aug 2016 11:53:31 -0700 (PDT) Received: by mail-ua0-x229.google.com with SMTP id 74so43467255uau.0 for ; Thu, 18 Aug 2016 11:53:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=wFuTh3EOCazVcn2BJdzDCwlVfDlsc/nOPvK4H8stfdQ=; b=Lsn+NlJJhkveALuNM8T3hE3egLb4KfRBRDY/hL8pbVE4uw+kaRRf9r0RuiQ4cmMxv7 ciWQhoYDw8UcKDlcqMOJenUipm4IGvSQEhSAC4yBmrHUU0O3i7r7VmPbVEuZo1NsY7O1 BOVRaFJMgFnDDjB4RdMCoai40I3rW0R5UQsVT9Ozw8gtBxciQPy6ee3oXRvKe7vrEPAG snK0kluxBpQTEoxvN6P+tfUHOd1pvJ76ni87bctm8wlEb7FZU7197FolI121eM23N9QK IYg1LXF9zDNSEBQABihHn+HWXEmYIi+Xg0pBuz2Anhw9HSaN6qbuMgHBEx0ulGY9ukW+ /tkw== 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; bh=wFuTh3EOCazVcn2BJdzDCwlVfDlsc/nOPvK4H8stfdQ=; b=eqIIBo587Jr8wbZioQT3hUnbTLWXP3gzQDIZbzSrUm+E5s5F1qITrf3rjJY9k3Mlb5 f7HOashoDJye9R6bMQFPor97bPyQGmbVlfdY8d+fc/U9afqZDdcd/yaBxtYCNdiNWo9k WdXJ0dqbvKoQPZ/svyGOPz6M/hdZYggAsIbo65WTTdwm6gNl9uXsUL/E5YtUmueVXJBj t1hDVZYS1bZLnCnm1iHGeYMMSq1emrKPNByl4D6nOi5l7dlhqUsiaM5u5cUWsDIXfILk +D1BJyt8XS35SbhcGFujEgOrDyXS7VIx532jkXWt3sQ08pKPhmQ++eQ0aVWzQYGM0tuw WYmg== X-Gm-Message-State: AEkoouseFjfxtoOi5YA659AxDFfXnpDHU9ebcOOL5OVjav3Glptzf8Cr7qMFShpYlNXbN3r7i5abJdy4ruMQ0Q== X-Received: by 10.31.192.202 with SMTP id q193mr1586347vkf.44.1471546410152; Thu, 18 Aug 2016 11:53:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.4.198 with HTTP; Thu, 18 Aug 2016 11:53:29 -0700 (PDT) In-Reply-To: <003801d1f97f$3d16eb10$b744c130$@ndzh.com> References: <147146974235.23784.4389421535496134619.idtracker@ietfa.amsl.com> <013b01d1f8ee$31fa09b0$95ee1d10$@ndzh.com> <20160818073203.GA4338@elstar.local> <04b501d1f949$116c63e0$34452ba0$@ndzh.com> <20160818121405.GA5282@elstar.local> <051301d1f950$7739c670$65ad5350$@ndzh.com> <20160818130555.GA5366@elstar.local> <051701d1f952$c4ae0b30$4e0a2190$@ndzh.com> <6BCE198E4EAEFC4CAB45D75826EFB0761525CCD7@eusaamb101.ericsson.se> <003801d1f97f$3d16eb10$b744c130$@ndzh.com> From: Andy Bierman Date: Thu, 18 Aug 2016 11:53:29 -0700 Message-ID: To: Susan Hares Content-Type: multipart/alternative; boundary=001a114398de0c4a6f053a5d19bd Archived-At: X-Mailman-Approved-At: Thu, 18 Aug 2016 12:58:55 -0700 Cc: "i2rs@ietf.org" , Alissa Cooper , Juergen Schoenwaelder , 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) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Aug 2016 18:53:43 -0000 --001a114398de0c4a6f053a5d19bd Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, I did not think Juergen's comment was about running code. In order for a data node to get the "ok-for-nonsecure-transports" approval in an IETF module, the IETF needs to agree that there could never possibly be any deployment that would not want to allow exposure of the data. Not now. Not 20 years from now. I can see a vendor making that decision for their own proprietary modules, but it seems less likely for standard modules. Seems like the operator is going to have to configure what is allowed for nonsecure transport anyway, so just let them decide. I don't really object to the extension or the requirement. It doesn't help much but it doesn't hurt much either. Andy On Thu, Aug 18, 2016 at 11:35 AM, Susan Hares wrote: > Alissa: > > Just a little input you may not know. My background is 15 years > (1995-2010) developing a routing/switching platform (denoted as GateD) > which was sold to over 200 companies. We developed XML and a binary XML > based product that configured this product. It could do 100K configurati= on > lines and reboot in less than a second on most hardware. We also provide > status messages in secure streams and non-secure streams. I sold early > version of this code to companies that Alia has worked for - so she has > personal viewed the code. At the height of our work, our development te= am > ran to 50 people which I directed (First as VP of Engineering, and then a= s > CTO). It is due to this level of experience that Alia selected me for the > co-chair. Russ White has understood Cisco's process, and has also > directed software development teams for routing. > > In order to freshen my direct experience with I2RS on open source work, I > am working on a publically available work in Quagga based on the confD > product suggested by Cisco. > > In contrast, Juergen is a university professor who has worked on > proto-types. He is not working on an implementation. I hope he will. > > I hope you will consider this background in my response to your comments > below. > > Sue > > > -----Original Message----- > From: Alissa Cooper [mailto:alissa@cooperw.in] > Sent: Thursday, August 18, 2016 12:54 PM > To: Joel Halpern > Cc: Susan Hares; Juergen Schoenwaelder; i2rs@ietf.org; > i2rs-chairs@ietf.org; Kathleen Moriarty; IESG; jhaas@pfrc.org; > 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) > > Jumping in here because this is relevant to my DISCUSS, hope nobody minds > (but if you do, I can go back to the other thread). > > >> On Aug 18, 2016, at 10:30 AM, Joel Halpern > wrote: > >> > >> Let me try a different take approach to this particular question. > >> > >> Let me start by putting aside the question of where things are marked, > and come back to that afterwards. > >> > >> There are a number of cases that I2RS has been asked to cover of high > rate telemetry data. This may be BGP update information, it may be > frequent information about line card activity. There are other cases, so= me > of which have been documented. > >> > >> While not completely insensitive, the operators have made clear that > they see protecting this data as unnecessary. While I would hope over ti= me > to move to a domain where all of it is protect, that is not trivial. As > the I2RS Architecture points out, it is expected that what we describe as= a > single I2RS >communication between a client and agent is actually > associated with multiple channels of communication. > >> > >> Now, if you want to say that the I2RS protocol requirements cannot > allow for unprotected channels, I guess we have disconnect between the IE= SG > and the WG. > >> > >> If we say that we can allow for unprotected channels, we then get to > the question of which data can be sent over such channels. While > architecturally I agree with Juergen that the model is a bad place to > specify it, the obverse is also true. Not having some limits on what can > be sent unprotected >causes concern about insufficient protection. If I > recall correctly, earlier security reviews called us to task for being to= o > broad in what we allowed. > >> > >> So, if the IESG wants us to just allow it anywhere, because the model > is an awkward place to define the limitation, I can live with that. What= I > can't live with is being told both that the model is a bad place to defin= e > it and that there must be restrictions on what is sent unprotected, > >> without any proposal on how we are to move forward. > > > Thank you Joel, this explanation helps me a lot. I think there is a > disconnect about how the restrictions are expressed. From reading the ema= il > traffic about this document, it strikes me that trying to express the > restrictions programmatically doesn=E2=80=99t make much sense in this cas= e. > > I agree with Juergen that it will be challenging to make a judgment a > priori in order to bake a restriction into a data model, because data tha= t > is considered sensitive enough to warrant a secure transport in one > deployment may not be considered sensitive in another deployment. > > So for any data elements where there is any question at all about > whether they might be sensitive (i.e., any data elements that are not > already routinely made public), > > I would expect data model authors to end up indicating that they may be > sent over either secure or insecure transport, which renders the indicati= on > not useful. > > Perhaps it would make more sense then to just enumerate in the text the > cases that motivate the inclusion of protocol support for insecure > transport: > > > > 1. For conveyance of information that is already routinely made public. > > 2. For line card activity data where there is no likely upgrade path to > support secure transports in the foreseeable future. > > > > Then the normative requirements would be on clients and agents to use > secure transports unless those clients and agents are deployed where eith= er > of the operational circumstances above necessitate otherwise. > > Alissa > > Point 1: > I disagree with Juergen on the difficulty in specifying the sections of > the yang modules. I have provided a suggested solution in: > https://tools.ietf.org/html/draft-hares-i2rs-protocol- > strawman-03#section-4.5.2. > > Given the mount schema functionality, we can mount ephemeral state module > which augment non-ephemeral state modules which are "in-secure only". > > Point 2: > I am willing to put an enumeration of the use cases in the protocol > requirement, but I would like to understand the purpose for the > enumeration. We are not doing a use case, but a requirements document. > This information appears to be a "use case" rather than a technical > description. What purpose are you looking for this enumeration to > server. Are you looking for the enumeration in SEC-REQ-08? > > Point 3: Could you review -08.txt on this topic, especially the text > below. Given your comments, I believe I should change the last line to a > MUST. > New/ The default mode of transport is > secure so data models MUST clearly annotate what data nodes can be > passed over an insecure connection. > / > > Sue > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > As to the normative requirements (-08.txt) version: > > Section 3: > > I2RS allows the use of an insecure transport for portions of data > models that clearly indicate the use of an insecure transport. > Operators deploying I2RS must determine if they want to populate and > deploy the portions of the data model which use insecure transports. > > In Section 3.2 in version -08.txt > > SEC-REQ-08: The I2RS protocol MUST be able to transfer data over a > secure transport and optionally MAY be able to transfer data over a > non-secure transport. A secure transport MUST provide data > confidentiality, data integrity, and replay prevention. > > The default I2RS transport is a secure transport. > > 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. > > The configuration of ephemeral data in the I2RS Agent by the I2RS > client SHOULD be done over a secure transport. It is anticipated > that the passing of most I2RS ephemeral state operational status > SHOULD be done over a secure transport. As > [I-D.ietf-i2rs-ephemeral-state] notes, a data model MUST indicate > whether the transport exchanging the data between I2RS client and > I2RS agent is secure or insecure. > > The default mode of transport is > secure so data models SHOULD clearly annotate what data nodes can be > passed over an insecure connection. > > > > > Yours, > > Joel > > > > -----Original Message----- > > From: Susan Hares [mailto:shares@ndzh.com] > > Sent: Thursday, August 18, 2016 9:17 AM > > To: 'Juergen Schoenwaelder' > > Cc: i2rs@ietf.org; i2rs-chairs@ietf.org; 'Kathleen Moriarty' > > ; 'The IESG' ; > > jhaas@pfrc.org; > > 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) > > > > Juergen and Kathleen: > > > > Let me proceed with two examples: BGP route views data model and the > event for the web-service data. > > > > The content of these data models are designated as exposed to public. > The routing system only populates the proposed BGP route views data model > with the data destined for the BGP looking glass. The policy on the > routing system indicates what information gets transferred. The data mod= el > is completely available to the public. The Yang Doctors are going to > review this by seeing the whole model is public and available via > non-secure means. > > The security people are going to review this seeing that the whole mode= l > is public, and available via an unprotect means. The fact the data model > is all public should simplify the review. > > > > An event from the I2RS RIB that a web-service route is up is the second > case. The I2RS RIB has an event based on policy that indicates a > web-service route is up. The yang-1.1 doctors must review the content of > the event text to see it does not break privacy or provide too much > > information The event mechanisms will need to work over secure > transport > > and insecure transport. Most of the data will go over the secure > transport event stream. However, a small amount of information may go ove= r > the insecure transport stream. > > > > First, let me know if my use cases are understandable. Second, let me > know if you disagree with this use cases. > > > > Fyi - IESG approved the architecture with the insecure stream. > > > > Sue > > > > -----Original Message----- > > From: Juergen Schoenwaelder > > [mailto:j.schoenwaelder@jacobs-university.de] > > Sent: Thursday, August 18, 2016 9:06 AM > > To: Susan Hares > > Cc: i2rs@ietf.org; i2rs-chairs@ietf.org; 'Kathleen Moriarty'; 'The > > IESG'; jhaas@pfrc.org; > > 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) > > > > I just do not know on which basis a data model writer can decide whethe= r > a data object can be exposed in an unprotected way. How are YANG doctors > going to review this? How are security directorate people going to judge > this? But as promised, I leave (still puzzled) now. > > > > /js > > > > On Thu, Aug 18, 2016 at 09:00:14AM -0400, Susan Hares wrote: > >> Juergen: > >> > >> Yes, we seem to disagree on the value of making it hardwired in the > model. > >> For me, the value is a common understanding of deployment > >> distribution > > such > >> as the route-views. Since the operators argued strongly for this > point, > > I > >> think the best idea is to get it working in code and then see if the > >> deployment matches the requests. > >> > >> Sue > >> > >> -----Original Message----- > >> From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Juergen > >> Schoenwaelder > >> Sent: Thursday, August 18, 2016 8:14 AM > >> To: Susan Hares > >> Cc: i2rs@ietf.org; i2rs-chairs@ietf.org; 'Kathleen Moriarty'; 'The > >> IESG'; jhaas@pfrc.org; > >> 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) > >> > >> Sue, > >> > >> I still do not see why the 'mode of exposure' of data benefits from > >> being hard-wired in the data model. For me, it is a situational and > >> deployment specific question. But I shut up here since I aired this > >> concern before (and we simply seem to disagree). > >> > >> /js > >> > >> On Thu, Aug 18, 2016 at 08:07:18AM -0400, Susan Hares wrote: > >>> Juergen: > >>> > >>> My example is the looking glass servers for the BGP route views > >>> project > >>> (http://www.routeviews.org/) or a route indicating the presence of a > >>> web-server that is public. For the BGP I2RS route, a yang model cou= ld > >>> replace the looking glass function, and provide events for these > looking > >>> glass functions. For the web-server route, an event be sent when > > that > >>> one route is added. > >>> > >>> Sue > >>> > >>> > >>> -----Original Message----- > >>> From: Juergen Schoenwaelder > >>> [mailto:j.schoenwaelder@jacobs-university.de] > >>> Sent: Thursday, August 18, 2016 3:32 AM > >>> To: Susan Hares > >>> Cc: 'Kathleen Moriarty'; 'The IESG'; jhaas@pfrc.org; i2rs@ietf.org; > >>> i2rs-chairs@ietf.org; > >>> 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 Wed, Aug 17, 2016 at 09:16:48PM -0400, Susan Hares wrote: > >>>> ------------------------------------------------------------------ > >>>> -- > >>>> -- > >>>> COMMENT: > >>>> ------------------------------------------------------------------ > >>>> -- > >>>> -- > >>>> > >>>>> Section 3: > >>>>> Can you clarify the second to last sentence? Do you mean there > >>>>> are > >>> sections that indicate an insecure transport should be used? > >>>>> I2RS allows the use of an > >>>>> insecure transport for portions of data models that clearly > >>>>> indicate insecure transport. > >>>> > >>>>> Perhaps: > >>>>> I2RS allows the use of an > >>>>> insecure transport for portions of data models that clearly > >>>>> indicate the use of an insecure transport. > >>> > >>> I still wonder how a data model writer can reasonably decide whether > >>> a piece of information can be shipped safely over an insecure > >>> transport since this decision often depends on the specifics of a > >>> deployment > >> situation. > >>> > >>> /js > >>> > >>> PS: I hope we do not end up with defining data multiple times (once > >>> for insecure transport and once for secured transports). > >>> > >>> -- > >>> Juergen Schoenwaelder Jacobs University Bremen gGmbH > >>> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | German= y > >>> Fax: +49 421 200 3103 > >>> > >>> _______________________________________________ > >>> i2rs mailing list > >>> i2rs@ietf.org > >>> https://www.ietf.org/mailman/listinfo/i2rs > >> > >> -- > >> Juergen Schoenwaelder Jacobs University Bremen gGmbH > >> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > >> Fax: +49 421 200 3103 > >> > >> _______________________________________________ > >> i2rs mailing list > >> i2rs@ietf.org > >> https://www.ietf.org/mailman/listinfo/i2rs > >> > > > > -- > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > > Fax: +49 421 200 3103 > > > > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs > --001a114398de0c4a6f053a5d19bd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

I did not think Juergen's comme= nt was about running code.

In order for a data nod= e to get the "ok-for-nonsecure-transports" approval
in = an IETF module, the IETF needs to agree that there could never possibly be<= /div>
any deployment that would not want to allow exposure of the data.=
Not now. Not 20 years from now.

I can s= ee a vendor making that decision for their own proprietary modules,
but it seems less likely for standard modules.

= Seems like the operator is going to have to configure what is allowed
=
for nonsecure transport anyway, so just let them decide.
I d= on't really object to the extension or the requirement.
I= t doesn't help much but it doesn't hurt much either.

=

Andy



On Thu, Aug 18, 2016= at 11:35 AM, Susan Hares <shares@ndzh.com> wrote:
Alissa:

Just a little input you may not know.=C2=A0 My background is 15 years (1995= -2010)=C2=A0 developing a routing/switching platform (denoted as GateD) whi= ch was sold to over 200 companies.=C2=A0 =C2=A0We developed XML and a binar= y XML based product that configured this product.=C2=A0 It could do 100K co= nfiguration lines and reboot in less than a second on most hardware.=C2=A0 = We also provide status messages in secure streams and non-secure streams.= =C2=A0 =C2=A0 I sold early version of this code to companies that Alia has = worked for=C2=A0 - so she has personal viewed the code.=C2=A0 =C2=A0At the = height of our work, our development team ran to 50 people which I directed = (First as VP of Engineering, and then as CTO). It is due to this level of e= xperience that Alia selected me for the co-chair.=C2=A0 =C2=A0Russ White ha= s understood Cisco's process, and has also directed software developmen= t teams for routing.

In order to freshen my direct experience with I2RS on open source work, I a= m working on a publically available work in Quagga based on the confD produ= ct suggested by Cisco.

In contrast, Juergen is a university professor who has worked on proto-type= s.=C2=A0 =C2=A0He is not working on an implementation.=C2=A0 =C2=A0I hope h= e will.

I hope you will consider this background in my response to your comments be= low.

Sue


-----Original Message-----
From: Alissa Cooper [mailto:alissa@coo= perw.in]
Sent: Thursday, August 18, 2016 12:54 PM
To: Joel Halpern
Cc: Susan Hares; Juergen Schoenwaelder; i2= rs@ietf.org; i2rs-chairs@ietf.o= rg; Kathleen Moriarty; IESG; jhaas@pf= rc.org; draft-ietf-i2rs-protocol-security-requirements@ietf.org
Subject: Re: [i2rs] Kathleen Moriarty's Discuss on draft-ietf-i2rs-prot= ocol-security-requirements-07: (with DISCUSS and COMMENT)

Jumping in here because this is relevant to my DISCUSS, hope nobody minds (= but if you do, I can go back to the other thread).

>> On Aug 18, 2016, at 10:30 AM, Joel Halpern <joel.halpern@ericsson.com> wrote:
>>
>> Let me try a different take approach to this particular question.<= br> >>
>> Let me start by putting aside the question of where things are mar= ked, and come back to that afterwards.
>>
>> There are a number of cases that I2RS has been asked to cover of h= igh rate telemetry data.=C2=A0 This may be BGP update information, it may b= e frequent information about line card activity.=C2=A0 There are other case= s, some of which have been documented.
>>
>> While not completely insensitive, the operators have made clear th= at they see protecting this data as unnecessary.=C2=A0 While I would hope o= ver time to move to a domain where all of it is protect, that is not trivia= l.=C2=A0 As the I2RS Architecture points out, it is expected that what we d= escribe as a single I2RS >communication between a client and agent is ac= tually associated with multiple channels of communication.
>>
>> Now, if you want to say that the I2RS protocol requirements cannot= allow for unprotected channels, I guess we have disconnect between the IES= G and the WG.
>>
>> If we say that we can allow for unprotected channels, we then get = to the question of which data can be sent over such channels.=C2=A0 While a= rchitecturally I agree with Juergen that the model is a bad place to specif= y it, the obverse is also true.=C2=A0 Not having some limits on what can be= sent unprotected >causes concern about insufficient protection.=C2=A0 I= f I recall correctly, earlier security reviews called us to task for being = too broad in what we allowed.
>>
>> So, if the IESG wants us to just allow it anywhere, because the mo= del is an awkward place to define the limitation, I can live with that.=C2= =A0 What I can't live with is being told both that the model is a bad p= lace to define it and that there must be restrictions on what is sent unpro= tected,
>> without any proposal on how we are to move forward.

> Thank you Joel, this explanation helps me a lot. I think there is a di= sconnect about how the restrictions are expressed. From reading the email t= raffic about this document, it strikes me that trying to express the restri= ctions programmatically doesn=E2=80=99t make much sense in this case.
> I agree with Juergen that it will be challenging to make a judgment a = priori in order to bake a restriction into a data model, because data that = is considered sensitive enough to warrant a secure transport in one deploym= ent may not be considered sensitive in another deployment.
> So for any data elements where there is any question at all about whet= her they might be sensitive (i.e., any data elements that are not already r= outinely made public),
> I would expect data model authors to end up indicating that they may b= e sent over either secure or insecure transport, which renders the indicati= on not useful.
> Perhaps it would make more sense then to just enumerate in the text th= e cases that motivate the inclusion of protocol support for insecure transp= ort:
>
> 1. For conveyance of information that is already routinely made public= .
> 2. For line card activity data where there is no likely upgrade path t= o support secure transports in the foreseeable future.
>
> Then the normative requirements would be on clients and agents to use = secure transports unless those clients and agents are deployed where either= of the operational circumstances above necessitate otherwise.
> Alissa

Point 1:
I disagree with Juergen on the difficulty in specifying the sections of the= yang modules.=C2=A0 I have provided a suggested solution in:
https://tools.ietf.or= g/html/draft-hares-i2rs-protocol-strawman-03#section-4.5.2.
Given the mount schema functionality, we can mount ephemeral state module w= hich augment non-ephemeral state modules which are "in-secure only&quo= t;.

Point 2:
I am willing to put an enumeration of the use cases in the protocol require= ment, but I would like to understand the purpose for the enumeration.=C2=A0= =C2=A0We are not doing a use case, but a requirements document.=C2=A0 This= information appears to be a "use case" rather than a technical d= escription.=C2=A0 =C2=A0What purpose are you looking for this enumeration t= o server.=C2=A0 Are you looking for the enumeration in SEC-REQ-08?

Point 3: Could you review -08.txt on this topic, especially the text below.= =C2=A0 Given your comments, I believe I should change the last line to a MU= ST.
New/=C2=A0 =C2=A0The default mode of transport is
=C2=A0 =C2=A0secure so data models MUST clearly annotate what data nodes ca= n be
=C2=A0 =C2=A0passed over an insecure connection.
/

Sue

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
As to the normative requirements (-08.txt) version:

Section 3:

=C2=A0 =C2=A0I2RS allows the use of an insecure transport for portions of d= ata
=C2=A0 =C2=A0models that clearly indicate the use of an insecure transport.=
=C2=A0 =C2=A0Operators deploying I2RS must determine if they want to popula= te and
=C2=A0 =C2=A0deploy the portions of the data model which use insecure trans= ports.

In Section 3.2 in version -08.txt

=C2=A0 =C2=A0SEC-REQ-08: The I2RS protocol MUST be able to transfer data ov= er a
=C2=A0 =C2=A0secure transport and optionally MAY be able to transfer data o= ver a
=C2=A0 =C2=A0non-secure transport.=C2=A0 A secure transport MUST provide da= ta
=C2=A0 =C2=A0confidentiality, data integrity, and replay prevention.

=C2=A0 =C2=A0The default I2RS transport is a secure transport.

=C2=A0 =C2=A0A non-secure transport can be used for publishing telemetry da= ta or
=C2=A0 =C2=A0other operational state that was specifically indicated to non= -
=C2=A0 =C2=A0confidential in the data model in the Yang syntax.

=C2=A0 =C2=A0The configuration of ephemeral data in the I2RS Agent by the I= 2RS
=C2=A0 =C2=A0client SHOULD be done over a secure transport.=C2=A0 It is ant= icipated
=C2=A0 =C2=A0that the passing of most I2RS ephemeral state operational stat= us
=C2=A0 =C2=A0SHOULD be done over a secure transport.=C2=A0 As
=C2=A0 =C2=A0[I-D.ietf-i2rs-ephemeral-state] notes,=C2=A0 a data model= MUST indicate
=C2=A0 =C2=A0whether the transport exchanging the data between I2RS client = and
=C2=A0 =C2=A0I2RS agent is secure or insecure.

=C2=A0 =C2=A0The default mode of transport is
=C2=A0 =C2=A0secure so data models SHOULD clearly annotate what data nodes = can be
=C2=A0 =C2=A0passed over an insecure connection.

>
> Yours,
> Joel
>
> -----Original Message-----
> From: Susan Hares [mailto:shares@nd= zh.com]
> Sent: Thursday, August 18, 2016 9:17 AM
> To: 'Juergen Schoenwaelder' <j.schoenwaelder@jacobs-university.de>=
> Cc: i2rs@ietf.org; i2rs-chairs@ietf.org; 'Kathleen Moriarty&= #39;
> <Kathleen.Moria= rty.ietf@gmail.com>; 'The IESG' <iesg@ietf.org>;
> jhaas@pfrc.org;
> 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)
>
> Juergen and Kathleen:
>
> Let me proceed with two examples: BGP route views data model and the e= vent for the web-service data.
>
> The content of these data models are designated as exposed to public.= =C2=A0 The routing system only populates the proposed BGP route views data = model with the data destined for the BGP looking glass.=C2=A0 The policy on= the routing system indicates what information gets transferred.=C2=A0 The = data model is completely available to the public.=C2=A0 The Yang Doctors ar= e going to review this by seeing the whole model is public and available vi= a non-secure means.
> The security people are going to review this seeing that the whole mod= el is public, and available via an unprotect means.=C2=A0 The fact the data= model is all public should simplify the review.
>
> An event from the I2RS RIB that a web-service route is up is the secon= d case.=C2=A0 The I2RS RIB has an event based on policy that indicates a we= b-service route is up.=C2=A0 The yang-1.1 doctors must review the content o= f the event text to see it does not break privacy or provide too much
> information=C2=A0 =C2=A0The event mechanisms will need to work over se= cure transport
> and insecure transport.=C2=A0 Most of the data will go over the secure= transport event stream. However, a small amount of information may go over= the insecure transport stream.
>
> First, let me know if my use cases are understandable.=C2=A0 Second, l= et me know if you disagree with this use cases.
>
> Fyi -=C2=A0 IESG approved the architecture with the insecure stream. >
> Sue
>
> -----Original Message-----
> From: Juergen Schoenwaelder
> [mailto:j.scho= enwaelder@jacobs-university.de]
> Sent: Thursday, August 18, 2016 9:06 AM
> To: Susan Hares
> Cc: i2rs@ietf.org; i2rs-chairs@ietf.org; 'Kathleen Moriarty&= #39;; 'The
> IESG'; jhaas@pfrc.org;
> 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)
>
> I just do not know on which basis a data model writer can decide wheth= er a data object can be exposed in an unprotected way. How are YANG doctors= going to review this? How are security directorate people going to judge t= his? But as promised, I leave (still puzzled) now.
>
> /js
>
> On Thu, Aug 18, 2016 at 09:00:14AM -0400, Susan Hares wrote:
>> Juergen:
>>
>> Yes, we seem to disagree on the value of making it hardwired in th= e model.
>> For me, the value is a common understanding of deployment
>> distribution
> such
>> as the route-views.=C2=A0 =C2=A0Since the operators argued strongl= y for this point,
> I
>> think the best idea is to get it working in code and then see if t= he
>> deployment matches the requests.
>>
>> Sue
>>
>> -----Original Message-----
>> From: i2rs [mailto:i2rs-b= ounces@ietf.org] On Behalf Of Juergen
>> Schoenwaelder
>> Sent: Thursday, August 18, 2016 8:14 AM
>> To: Susan Hares
>> Cc: i2rs@ietf.org; i2rs-chairs@ietf.org; 'Kathleen Moria= rty'; 'The
>> IESG'; jhaas@pfrc.org; >> draft-ietf-i2rs-protocol-security-requirements@ietf.org >> Subject: Re: [i2rs] Kathleen Moriarty's Discuss on
>> draft-ietf-i2rs-protocol-security-requirements-07: (with DISC= USS and
>> COMMENT)
>>
>> Sue,
>>
>> I still do not see why the 'mode of exposure' of data bene= fits from
>> being hard-wired in the data model. For me, it is a situational an= d
>> deployment specific question. But I shut up here since I aired thi= s
>> concern before (and we simply seem to disagree).
>>
>> /js
>>
>> On Thu, Aug 18, 2016 at 08:07:18AM -0400, Susan Hares wrote:
>>> Juergen:
>>>
>>> My example is the looking glass servers for the BGP route view= s
>>> project
>>> (http://www.routeviews.org/) or a route indicating the pr= esence of a
>>> web-server that is public.=C2=A0 =C2=A0For the BGP I2RS route,= a yang model could
>>> replace the looking glass function, and provide events for the= se looking
>>> glass functions.=C2=A0 =C2=A0 For the web-server route,=C2=A0 = an event be sent when
> that
>>> one route is added.
>>>
>>> Sue
>>>
>>>
>>> -----Original Message-----
>>> From: Juergen Schoenwaelder
>>> [mailto:j.schoenwaelder@jacobs-university.de]
>>> Sent: Thursday, August 18, 2016 3:32 AM
>>> To: Susan Hares
>>> Cc: 'Kathleen Moriarty'; 'The IESG'; jhaas@pfrc.org; i2rs@ietf.org;
>>> i2rs-chairs@ietf.org;
>>> 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 Wed, Aug 17, 2016 at 09:16:48PM -0400, Susan Hares wrote: >>>> -----------------------------------------------------= -------------
>>>> --
>>>> --
>>>> COMMENT:
>>>> -----------------------------------------------------= -------------
>>>> --
>>>> --
>>>>
>>>>> Section 3:
>>>>> Can you clarify the second to last sentence?=C2=A0 Do = you mean there
>>>>> are
>>> sections that indicate an insecure transport should be used? >>>>>=C2=A0 I2RS allows the use of an
>>>>> insecure transport for portions of data models that cl= early
>>>>> indicate=C2=A0 insecure transport.
>>>>
>>>>> Perhaps:
>>>>> I2RS allows the use of an
>>>>> insecure transport for portions of data models that cl= early
>>>>> indicate the use of an=C2=A0 insecure transport.
>>>
>>> I still wonder how a data model writer can reasonably decide w= hether
>>> a piece of information can be shipped safely over an insecure<= br> >>> transport since this decision often depends on the specifics o= f a
>>> deployment
>> situation.
>>>
>>> /js
>>>
>>> PS: I hope we do not end up with defining data multiple times = (once
>>>=C2=A0 =C2=A0 for insecure transport and once for secured trans= ports).
>>>
>>> --
>>> Juergen Schoenwaelder=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= Jacobs University Bremen gGmbH
>>> Phone: +49 421 200 3587=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Campu= s Ring 1 | 28759 Bremen | Germany
>>> Fax:=C2=A0 =C2=A0+49 421 200 3103=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0<http://www.jacobs-university.de/>
>>>
>>> _______________________________________________
>>> i2rs mailing list
>>> i2rs@ietf.org
>>> https://www.ietf.org/mailman/listinfo/i2= rs
>>
>> --
>> Juergen Schoenwaelder=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Jaco= bs University Bremen gGmbH
>> Phone: +49 421 200 3587=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Campus Ri= ng 1 | 28759 Bremen | Germany
>> Fax:=C2=A0 =C2=A0+49 421 200 3103=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0<http://www.jacobs-university.de/>
>>
>> _______________________________________________
>> i2rs mailing list
>> i2rs@ietf.org
>> https://www.ietf.org/mailman/listinfo/i2rs
>>
>
> --
> Juergen Schoenwaelder=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Jacobs U= niversity Bremen gGmbH
> Phone: +49 421 200 3587=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Campus Ring 1= | 28759 Bremen | Germany
> Fax:=C2=A0 =C2=A0+49 421 200 3103=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<= ;http://www.jacobs-university.de/>
>


_______________________________________________
i2rs mailing list
i2rs@ietf.org
https://www.ietf.org/mailman/listinfo/i2rs

--001a114398de0c4a6f053a5d19bd-- From nobody Thu Aug 18 13:01:35 2016 Return-Path: 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 AF6C312B012; Thu, 18 Aug 2016 12:46:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.739 X-Spam-Level: * X-Spam-Status: No, score=1.739 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, RDNS_NONE=0.793] autolearn=no 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 GirRfv6Aykvb; Thu, 18 Aug 2016 12:46:00 -0700 (PDT) Received: from hickoryhill-consulting.com (unknown [50.245.122.97]) (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 CB61A12D0EE; Thu, 18 Aug 2016 12:45:59 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=174.124.185.60; From: "Susan Hares" To: "'Andy Bierman'" References: <147146974235.23784.4389421535496134619.idtracker@ietfa.amsl.com> <013b01d1f8ee$31fa09b0$95ee1d10$@ndzh.com> <20160818073203.GA4338@elstar.local> <04b501d1f949$116c63e0$34452ba0$@ndzh.com> <20160818121405.GA5282@elstar.local> <051301d1f950$7739c670$65ad5350$@ndzh.com> <20160818130555.GA5366@elstar.local> <051701d1f952$c4ae0b30$4e0a2190$@ndzh.com> <6BCE198E4EAEFC4CAB45D75826EFB0761525CCD7@eusaamb101.ericsson.se> <003801d1f97f$3d16eb10$b744c130$@ndzh.com> In-Reply-To: Date: Thu, 18 Aug 2016 15:44:34 -0400 Message-ID: <00dc01d1f988$f2cec280$d86c4780$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00DD_01D1F967.6BC252A0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIa7Lz6VgZw6h2A0uGNzOgAA2Ic8QJ/RF5yARxv/coCD6d0AAIDKkFTAYlI9/gCaK/wXAMksAaNAmoTFCQCp9Oi8AIQlOgDAIZjbI2fCcK+4A== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: X-Mailman-Approved-At: Thu, 18 Aug 2016 13:01:33 -0700 Cc: i2rs@ietf.org, 'Alissa Cooper' , 'Juergen Schoenwaelder' , 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) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Aug 2016 19:46:05 -0000 This is a multipart message in MIME format. ------=_NextPart_000_00DD_01D1F967.6BC252A0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Andy: =20 Thank you =E2=80=93 I thought it was on whether we could implement = insecure transport in a Yang module.=20 =20 The requirement text you are working with is: =20 SEC-REQ-08: The I2RS protocol MUST be able to transfer data over a secure transport and optionally MAY be able to transfer data over a non-secure transport. =20 I do not understand why approving the ok for non-secure transport for = some modules means the following to you:=20 =20 =E2=80=9C the IETF needs to agree that there could never possibly be any = deployment that would not want to allow exposure of the data. Not now. Not 20 years from now.=E2=80=9D =20 I had thought that the security-directorate and other reviewers would = look at each module that is insecure, and consider whether it was = reasonable for the use case at this time. This is what I understood = from Russ Housley=E2=80=99s first review of this technology. Since like = you, I believe the operator is going to configure what modules are = allowed on systems. I agree that this requirement provides a full = scope of the work, but implementers will require network operators to = configure these features on.=20 =20 Sue =20 =20 From: Andy Bierman [mailto:andy@yumaworks.com]=20 Sent: Thursday, August 18, 2016 2:53 PM To: Susan Hares Cc: Alissa Cooper; Joel Halpern; i2rs@ietf.org; Juergen Schoenwaelder; = i2rs-chairs@ietf.org; Kathleen Moriarty; IESG; Jeffrey Haas; = 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) =20 Hi, =20 I did not think Juergen's comment was about running code. =20 In order for a data node to get the "ok-for-nonsecure-transports" = approval in an IETF module, the IETF needs to agree that there could never = possibly be any deployment that would not want to allow exposure of the data. Not now. Not 20 years from now. =20 I can see a vendor making that decision for their own proprietary = modules, but it seems less likely for standard modules. =20 Seems like the operator is going to have to configure what is allowed for nonsecure transport anyway, so just let them decide. I don't really object to the extension or the requirement. It doesn't help much but it doesn't hurt much either. =20 =20 Andy =20 =20 =20 On Thu, Aug 18, 2016 at 11:35 AM, Susan Hares wrote: Alissa: Just a little input you may not know. My background is 15 years = (1995-2010) developing a routing/switching platform (denoted as GateD) = which was sold to over 200 companies. We developed XML and a binary = XML based product that configured this product. It could do 100K = configuration lines and reboot in less than a second on most hardware. = We also provide status messages in secure streams and non-secure = streams. I sold early version of this code to companies that Alia has = worked for - so she has personal viewed the code. At the height of = our work, our development team ran to 50 people which I directed (First = as VP of Engineering, and then as CTO). It is due to this level of = experience that Alia selected me for the co-chair. Russ White has = understood Cisco's process, and has also directed software development = teams for routing. In order to freshen my direct experience with I2RS on open source work, = I am working on a publically available work in Quagga based on the confD = product suggested by Cisco. In contrast, Juergen is a university professor who has worked on = proto-types. He is not working on an implementation. I hope he will. I hope you will consider this background in my response to your comments = below. Sue -----Original Message----- From: Alissa Cooper [mailto:alissa@cooperw.in] Sent: Thursday, August 18, 2016 12:54 PM To: Joel Halpern Cc: Susan Hares; Juergen Schoenwaelder; i2rs@ietf.org; = i2rs-chairs@ietf.org; Kathleen Moriarty; IESG; jhaas@pfrc.org; = 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) Jumping in here because this is relevant to my DISCUSS, hope nobody = minds (but if you do, I can go back to the other thread). >> On Aug 18, 2016, at 10:30 AM, Joel Halpern = wrote: >> >> Let me try a different take approach to this particular question. >> >> Let me start by putting aside the question of where things are = marked, and come back to that afterwards. >> >> There are a number of cases that I2RS has been asked to cover of high = rate telemetry data. This may be BGP update information, it may be = frequent information about line card activity. There are other cases, = some of which have been documented. >> >> While not completely insensitive, the operators have made clear that = they see protecting this data as unnecessary. While I would hope over = time to move to a domain where all of it is protect, that is not = trivial. As the I2RS Architecture points out, it is expected that what = we describe as a single I2RS >communication between a client and agent = is actually associated with multiple channels of communication. >> >> Now, if you want to say that the I2RS protocol requirements cannot = allow for unprotected channels, I guess we have disconnect between the = IESG and the WG. >> >> If we say that we can allow for unprotected channels, we then get to = the question of which data can be sent over such channels. While = architecturally I agree with Juergen that the model is a bad place to = specify it, the obverse is also true. Not having some limits on what = can be sent unprotected >causes concern about insufficient protection. = If I recall correctly, earlier security reviews called us to task for = being too broad in what we allowed. >> >> So, if the IESG wants us to just allow it anywhere, because the model = is an awkward place to define the limitation, I can live with that. = What I can't live with is being told both that the model is a bad place = to define it and that there must be restrictions on what is sent = unprotected, >> without any proposal on how we are to move forward. > Thank you Joel, this explanation helps me a lot. I think there is a = disconnect about how the restrictions are expressed. From reading the = email traffic about this document, it strikes me that trying to express = the restrictions programmatically doesn=E2=80=99t make much sense in = this case. > I agree with Juergen that it will be challenging to make a judgment a = priori in order to bake a restriction into a data model, because data = that is considered sensitive enough to warrant a secure transport in one = deployment may not be considered sensitive in another deployment. > So for any data elements where there is any question at all about = whether they might be sensitive (i.e., any data elements that are not = already routinely made public), > I would expect data model authors to end up indicating that they may = be sent over either secure or insecure transport, which renders the = indication not useful. > Perhaps it would make more sense then to just enumerate in the text = the cases that motivate the inclusion of protocol support for insecure = transport: > > 1. For conveyance of information that is already routinely made = public. > 2. For line card activity data where there is no likely upgrade path = to support secure transports in the foreseeable future. > > Then the normative requirements would be on clients and agents to use = secure transports unless those clients and agents are deployed where = either of the operational circumstances above necessitate otherwise. > Alissa Point 1: I disagree with Juergen on the difficulty in specifying the sections of = the yang modules. I have provided a suggested solution in: https://tools.ietf.org/html/draft-hares-i2rs-protocol-strawman-03#section= -4.5.2. Given the mount schema functionality, we can mount ephemeral state = module which augment non-ephemeral state modules which are "in-secure = only". Point 2: I am willing to put an enumeration of the use cases in the protocol = requirement, but I would like to understand the purpose for the = enumeration. We are not doing a use case, but a requirements document. = This information appears to be a "use case" rather than a technical = description. What purpose are you looking for this enumeration to = server. Are you looking for the enumeration in SEC-REQ-08? Point 3: Could you review -08.txt on this topic, especially the text = below. Given your comments, I believe I should change the last line to = a MUST. New/ The default mode of transport is secure so data models MUST clearly annotate what data nodes can be passed over an insecure connection. / Sue =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D As to the normative requirements (-08.txt) version: Section 3: I2RS allows the use of an insecure transport for portions of data models that clearly indicate the use of an insecure transport. Operators deploying I2RS must determine if they want to populate and deploy the portions of the data model which use insecure transports. In Section 3.2 in version -08.txt SEC-REQ-08: The I2RS protocol MUST be able to transfer data over a secure transport and optionally MAY be able to transfer data over a non-secure transport. A secure transport MUST provide data confidentiality, data integrity, and replay prevention. The default I2RS transport is a secure transport. 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. The configuration of ephemeral data in the I2RS Agent by the I2RS client SHOULD be done over a secure transport. It is anticipated that the passing of most I2RS ephemeral state operational status SHOULD be done over a secure transport. As [I-D.ietf-i2rs-ephemeral-state] notes, a data model MUST indicate whether the transport exchanging the data between I2RS client and I2RS agent is secure or insecure. The default mode of transport is secure so data models SHOULD clearly annotate what data nodes can be passed over an insecure connection. > > Yours, > Joel > > -----Original Message----- > From: Susan Hares [mailto:shares@ndzh.com] > Sent: Thursday, August 18, 2016 9:17 AM > To: 'Juergen Schoenwaelder' > Cc: i2rs@ietf.org; i2rs-chairs@ietf.org; 'Kathleen Moriarty' > ; 'The IESG' ; > jhaas@pfrc.org; > 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) > > Juergen and Kathleen: > > Let me proceed with two examples: BGP route views data model and the = event for the web-service data. > > The content of these data models are designated as exposed to public. = The routing system only populates the proposed BGP route views data = model with the data destined for the BGP looking glass. The policy on = the routing system indicates what information gets transferred. The = data model is completely available to the public. The Yang Doctors are = going to review this by seeing the whole model is public and available = via non-secure means. > The security people are going to review this seeing that the whole = model is public, and available via an unprotect means. The fact the = data model is all public should simplify the review. > > An event from the I2RS RIB that a web-service route is up is the = second case. The I2RS RIB has an event based on policy that indicates a = web-service route is up. The yang-1.1 doctors must review the content = of the event text to see it does not break privacy or provide too much > information The event mechanisms will need to work over secure = transport > and insecure transport. Most of the data will go over the secure = transport event stream. However, a small amount of information may go = over the insecure transport stream. > > First, let me know if my use cases are understandable. Second, let me = know if you disagree with this use cases. > > Fyi - IESG approved the architecture with the insecure stream. > > Sue > > -----Original Message----- > From: Juergen Schoenwaelder > [mailto:j.schoenwaelder@jacobs-university.de] > Sent: Thursday, August 18, 2016 9:06 AM > To: Susan Hares > Cc: i2rs@ietf.org; i2rs-chairs@ietf.org; 'Kathleen Moriarty'; 'The > IESG'; jhaas@pfrc.org; > 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) > > I just do not know on which basis a data model writer can decide = whether a data object can be exposed in an unprotected way. How are YANG = doctors going to review this? How are security directorate people going = to judge this? But as promised, I leave (still puzzled) now. > > /js > > On Thu, Aug 18, 2016 at 09:00:14AM -0400, Susan Hares wrote: >> Juergen: >> >> Yes, we seem to disagree on the value of making it hardwired in the = model. >> For me, the value is a common understanding of deployment >> distribution > such >> as the route-views. Since the operators argued strongly for this = point, > I >> think the best idea is to get it working in code and then see if the >> deployment matches the requests. >> >> Sue >> >> -----Original Message----- >> From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Juergen >> Schoenwaelder >> Sent: Thursday, August 18, 2016 8:14 AM >> To: Susan Hares >> Cc: i2rs@ietf.org; i2rs-chairs@ietf.org; 'Kathleen Moriarty'; 'The >> IESG'; jhaas@pfrc.org; >> 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) >> >> Sue, >> >> I still do not see why the 'mode of exposure' of data benefits from >> being hard-wired in the data model. For me, it is a situational and >> deployment specific question. But I shut up here since I aired this >> concern before (and we simply seem to disagree). >> >> /js >> >> On Thu, Aug 18, 2016 at 08:07:18AM -0400, Susan Hares wrote: >>> Juergen: >>> >>> My example is the looking glass servers for the BGP route views >>> project >>> (http://www.routeviews.org/) or a route indicating the presence of a >>> web-server that is public. For the BGP I2RS route, a yang model = could >>> replace the looking glass function, and provide events for these = looking >>> glass functions. For the web-server route, an event be sent when > that >>> one route is added. >>> >>> Sue >>> >>> >>> -----Original Message----- >>> From: Juergen Schoenwaelder >>> [mailto:j.schoenwaelder@jacobs-university.de] >>> Sent: Thursday, August 18, 2016 3:32 AM >>> To: Susan Hares >>> Cc: 'Kathleen Moriarty'; 'The IESG'; jhaas@pfrc.org; i2rs@ietf.org; >>> i2rs-chairs@ietf.org; >>> 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 Wed, Aug 17, 2016 at 09:16:48PM -0400, Susan Hares wrote: >>>> ------------------------------------------------------------------ >>>> -- >>>> -- >>>> COMMENT: >>>> ------------------------------------------------------------------ >>>> -- >>>> -- >>>> >>>>> Section 3: >>>>> Can you clarify the second to last sentence? Do you mean there >>>>> are >>> sections that indicate an insecure transport should be used? >>>>> I2RS allows the use of an >>>>> insecure transport for portions of data models that clearly >>>>> indicate insecure transport. >>>> >>>>> Perhaps: >>>>> I2RS allows the use of an >>>>> insecure transport for portions of data models that clearly >>>>> indicate the use of an insecure transport. >>> >>> I still wonder how a data model writer can reasonably decide whether >>> a piece of information can be shipped safely over an insecure >>> transport since this decision often depends on the specifics of a >>> deployment >> situation. >>> >>> /js >>> >>> PS: I hope we do not end up with defining data multiple times (once >>> for insecure transport and once for secured transports). >>> >>> -- >>> Juergen Schoenwaelder Jacobs University Bremen gGmbH >>> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | = Germany >>> Fax: +49 421 200 3103 >>> >>> _______________________________________________ >>> i2rs mailing list >>> i2rs@ietf.org >>> https://www.ietf.org/mailman/listinfo/i2rs >> >> -- >> Juergen Schoenwaelder Jacobs University Bremen gGmbH >> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | = Germany >> Fax: +49 421 200 3103 >> >> _______________________________________________ >> i2rs mailing list >> i2rs@ietf.org >> https://www.ietf.org/mailman/listinfo/i2rs >> > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 > _______________________________________________ i2rs mailing list i2rs@ietf.org https://www.ietf.org/mailman/listinfo/i2rs =20 ------=_NextPart_000_00DD_01D1F967.6BC252A0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Andy:<= /o:p>

 =

Thank you = =E2=80=93 I thought it was on whether we could implement insecure = transport in a Yang module.

 =

The = requirement text you are working with is:

 =

   SEC-REQ-08: The I2RS = protocol MUST be able to transfer data over a
   secure = transport and optionally MAY be able to transfer data over a
  =  non-secure transport.

 =

I do not = understand why approving the ok for non-secure transport for some = modules means the following to you:

 

=E2= =80=9C the IETF needs to agree that there could never possibly be any = deployment that would not want to allow exposure of the = data.

N= ot now. Not 20 years from now.=E2=80=9D

 =

I had = thought that the security-directorate and other reviewers would look at = each module that is insecure, and =C2=A0consider whether it was = reasonable for the use case at this time.=C2=A0 =C2=A0This is what I = understood from Russ Housley=E2=80=99s first review of this technology. = =C2=A0Since like you, I believe the operator is going to =C2=A0configure = what modules are allowed on systems.=C2=A0 =C2=A0I agree that this = requirement provides a full scope of the work, but implementers will = require network operators to configure these features on. =

 =

Sue<= o:p>

 

 

From:= = Andy Bierman [mailto:andy@yumaworks.com]
Sent: Thursday, = August 18, 2016 2:53 PM
To: Susan Hares
Cc: Alissa = Cooper; Joel Halpern; i2rs@ietf.org; Juergen Schoenwaelder; = i2rs-chairs@ietf.org; Kathleen Moriarty; IESG; Jeffrey Haas; = 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)

 

Hi,

 

I = did not think Juergen's comment was about running = code.

 

In order for a data node to get the = "ok-for-nonsecure-transports" = approval

in an IETF = module, the IETF needs to agree that there could never possibly = be

any deployment that = would not want to allow exposure of the = data.

Not now. Not 20 = years from now.

 

I = can see a vendor making that decision for their own proprietary = modules,

but it seems less = likely for standard modules.

 

Seems like the operator is going to have to configure = what is allowed

for = nonsecure transport anyway, so just let them = decide.

I don't really = object to the extension or the requirement.

It doesn't help much but it doesn't hurt much = either.

 

 

Andy

 

 

 

On Thu, = Aug 18, 2016 at 11:35 AM, Susan Hares <shares@ndzh.com> wrote:

Alissa:

Just a little input you may not = know.  My background is 15 years (1995-2010)  developing a = routing/switching platform (denoted as GateD) which was sold to over 200 = companies.   We developed XML and a binary XML based product = that configured this product.  It could do 100K configuration lines = and reboot in less than a second on most hardware.  We also provide = status messages in secure streams and non-secure streams.    I = sold early version of this code to companies that Alia has worked = for  - so she has personal viewed the code.   At the = height of our work, our development team ran to 50 people which I = directed (First as VP of Engineering, and then as CTO). It is due to = this level of experience that Alia selected me for the co-chair.  =  Russ White has understood Cisco's process, and has also directed = software development teams for routing.

In order to freshen my = direct experience with I2RS on open source work, I am working on a = publically available work in Quagga based on the confD product suggested = by Cisco.

In contrast, Juergen is a university professor who has = worked on proto-types.   He is not working on an = implementation.   I hope he will.

I hope you will = consider this background in my response to your comments = below.

Sue


-----Original Message-----
From: Alissa = Cooper [mailto:alissa@cooperw.in]
Sent: = Thursday, August 18, 2016 12:54 PM
To: Joel Halpern
Cc: Susan = Hares; Juergen Schoenwaelder; i2rs@ietf.org; i2rs-chairs@ietf.org; Kathleen = Moriarty; IESG; jhaas@pfrc.org; d= raft-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)

Jumping in here because this is relevant to my DISCUSS, = hope nobody minds (but if you do, I can go back to the other = thread).

>> On Aug 18, 2016, at 10:30 AM, Joel Halpern = <joel.halpern@ericsson.com&g= t; wrote:
>>
>> Let me try a different take approach = to this particular question.
>>
>> Let me start by = putting aside the question of where things are marked, and come back to = that afterwards.
>>
>> There are a number of cases = that I2RS has been asked to cover of high rate telemetry data.  = This may be BGP update information, it may be frequent information about = line card activity.  There are other cases, some of which have been = documented.
>>
>> While not completely insensitive, = the operators have made clear that they see protecting this data as = unnecessary.  While I would hope over time to move to a domain = where all of it is protect, that is not trivial.  As the I2RS = Architecture points out, it is expected that what we describe as a = single I2RS >communication between a client and agent is actually = associated with multiple channels of = communication.
>>
>> Now, if you want to say that the = I2RS protocol requirements cannot allow for unprotected channels, I = guess we have disconnect between the IESG and the = WG.
>>
>> If we say that we can allow for unprotected = channels, we then get to the question of which data can be sent over = such channels.  While architecturally I agree with Juergen that the = model is a bad place to specify it, the obverse is also true.  Not = having some limits on what can be sent unprotected >causes concern = about insufficient protection.  If I recall correctly, earlier = security reviews called us to task for being too broad in what we = allowed.
>>
>> So, if the IESG wants us to just allow = it anywhere, because the model is an awkward place to define the = limitation, I can live with that.  What I can't live with is being = told both that the model is a bad place to define it and that there must = be restrictions on what is sent unprotected,
>> without any = proposal on how we are to move forward.

> Thank you Joel, this = explanation helps me a lot. I think there is a disconnect about how the = restrictions are expressed. From reading the email traffic about this = document, it strikes me that trying to express the restrictions = programmatically doesn=E2=80=99t make much sense in this case.
> I = agree with Juergen that it will be challenging to make a judgment a = priori in order to bake a restriction into a data model, because data = that is considered sensitive enough to warrant a secure transport in one = deployment may not be considered sensitive in another = deployment.
> So for any data elements where there is any question = at all about whether they might be sensitive (i.e., any data elements = that are not already routinely made public),
> I would expect data = model authors to end up indicating that they may be sent over either = secure or insecure transport, which renders the indication not = useful.
> Perhaps it would make more sense then to just enumerate = in the text the cases that motivate the inclusion of protocol support = for insecure transport:
>
> 1. For conveyance of information = that is already routinely made public.
> 2. For line card activity = data where there is no likely upgrade path to support secure transports = in the foreseeable future.
>
> Then the normative = requirements would be on clients and agents to use secure transports = unless those clients and agents are deployed where either of the = operational circumstances above necessitate otherwise.
> = Alissa

Point 1:
I disagree with Juergen on the difficulty in = specifying the sections of the yang modules.  I have provided a = suggested solution in:
https://tools.ietf.org/html/draft-hares-i2rs-protocol-s= trawman-03#section-4.5.2.

Given the mount schema = functionality, we can mount ephemeral state module which augment = non-ephemeral state modules which are "in-secure = only".

Point 2:
I am willing to put an enumeration of the = use cases in the protocol requirement, but I would like to understand = the purpose for the enumeration.   We are not doing a use = case, but a requirements document.  This information appears to be = a "use case" rather than a technical description.  =  What purpose are you looking for this enumeration to server.  = Are you looking for the enumeration in SEC-REQ-08?

Point 3: Could = you review -08.txt on this topic, especially the text below.  Given = your comments, I believe I should change the last line to a = MUST.
New/   The default mode of transport is
  =  secure so data models MUST clearly annotate what data nodes can = be
   passed over an insecure = connection.
/

Sue

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D
As to the normative requirements (-08.txt) = version:

Section 3:

   I2RS allows the use of an = insecure transport for portions of data
   models that = clearly indicate the use of an insecure transport.
  =  Operators deploying I2RS must determine if they want to populate = and
   deploy the portions of the data model which use = insecure transports.

In Section 3.2 in version = -08.txt

   SEC-REQ-08: The I2RS protocol MUST be able = to transfer data over a
   secure transport and optionally = MAY be able to transfer data over a
   non-secure = transport.  A secure transport MUST provide data
  =  confidentiality, data integrity, and replay = prevention.

   The default I2RS transport is a secure = transport.

   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.

   The configuration = of ephemeral data in the I2RS Agent by the I2RS
   client = SHOULD be done over a secure transport.  It is = anticipated
   that the passing of most I2RS ephemeral = state operational status
   SHOULD be done over a secure = transport.  As
   [I-D.ietf-i2rs-ephemeral-state] = notes,  a data model MUST indicate
   whether the = transport exchanging the data between I2RS client and
  =  I2RS agent is secure or insecure.

   The default = mode of transport is
   secure so data models SHOULD = clearly annotate what data nodes can be
   passed over an = insecure connection.

>
> Yours,
> = Joel
>
> -----Original Message-----
> From: Susan = Hares [mailto:shares@ndzh.com]
> Sent: = Thursday, August 18, 2016 9:17 AM
> To: 'Juergen Schoenwaelder' = <j.schoenwaelder@jaco= bs-university.de>
> Cc: i2rs@ietf.org; i2rs-chairs@ietf.org; 'Kathleen = Moriarty'
> <Kathleen.Moriarty.ietf@g= mail.com>; 'The IESG' <iesg@ietf.org>;
> jhaas@pfrc.org;
> d= raft-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)
>
> Juergen and = Kathleen:
>
> Let me proceed with two examples: BGP route = views data model and the event for the web-service data.
>
> = The content of these data models are designated as exposed to = public.  The routing system only populates the proposed BGP route = views data model with the data destined for the BGP looking glass.  = The policy on the routing system indicates what information gets = transferred.  The data model is completely available to the = public.  The Yang Doctors are going to review this by seeing the = whole model is public and available via non-secure means.
> The = security people are going to review this seeing that the whole model is = public, and available via an unprotect means.  The fact the data = model is all public should simplify the review.
>
> An event = from the I2RS RIB that a web-service route is up is the second = case.  The I2RS RIB has an event based on policy that indicates a = web-service route is up.  The yang-1.1 doctors must review the = content of the event text to see it does not break privacy or provide = too much
> information   The event mechanisms will need = to work over secure transport
> and insecure transport.  Most = of the data will go over the secure transport event stream. However, a = small amount of information may go over the insecure transport = stream.
>
> First, let me know if my use cases are = understandable.  Second, let me know if you disagree with this use = cases.
>
> Fyi -  IESG approved the architecture with = the insecure stream.
>
> Sue
>
> -----Original = Message-----
> From: Juergen Schoenwaelder
> [mailto:j.schoenwaelder@jaco= bs-university.de]
> Sent: Thursday, August 18, 2016 9:06 = AM
> To: Susan Hares
> Cc: i2rs@ietf.org; i2rs-chairs@ietf.org; 'Kathleen = Moriarty'; 'The
> IESG'; jhaas@pfrc.org;
> d= raft-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)
>
> I just do not know on which basis a = data model writer can decide whether a data object can be exposed in an = unprotected way. How are YANG doctors going to review this? How are = security directorate people going to judge this? But as promised, I = leave (still puzzled) now.
>
> /js
>
> On Thu, = Aug 18, 2016 at 09:00:14AM -0400, Susan Hares wrote:
>> = Juergen:
>>
>> Yes, we seem to disagree on the value = of making it hardwired in the model.
>> For me, the value is a = common understanding of deployment
>> distribution
> = such
>> as the route-views.   Since the operators = argued strongly for this point,
> I
>> think the best = idea is to get it working in code and then see if the
>> = deployment matches the requests.
>>
>> = Sue
>>
>> -----Original Message-----
>> From: = i2rs [mailto:i2rs-bounces@ietf.org] On = Behalf Of Juergen
>> Schoenwaelder
>> Sent: Thursday, = August 18, 2016 8:14 AM
>> To: Susan Hares
>> Cc: i2rs@ietf.org; i2rs-chairs@ietf.org; 'Kathleen = Moriarty'; 'The
>> IESG'; jhaas@pfrc.org;
>> d= raft-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)
>>
>> = Sue,
>>
>> I still do not see why the 'mode of = exposure' of data benefits from
>> being hard-wired in the data = model. For me, it is a situational and
>> deployment specific = question. But I shut up here since I aired this
>> concern = before (and we simply seem to disagree).
>>
>> = /js
>>
>> On Thu, Aug 18, 2016 at 08:07:18AM -0400, = Susan Hares wrote:
>>> = Juergen:
>>>
>>> My example is the looking glass = servers for the BGP route views
>>> project
>>> = (http://www.routeviews.org/) or a route indicating = the presence of a
>>> web-server that is public.  =  For the BGP I2RS route, a yang model could
>>> replace = the looking glass function, and provide events for these = looking
>>> glass functions.    For the web-server = route,  an event be sent when
> that
>>> one = route is added.
>>>
>>> = Sue
>>>
>>>
>>> -----Original = Message-----
>>> From: Juergen Schoenwaelder
>>> = [mailto:j.schoenwaelder@jaco= bs-university.de]
>>> Sent: Thursday, August 18, 2016 = 3:32 AM
>>> To: Susan Hares
>>> Cc: 'Kathleen = Moriarty'; 'The IESG'; jhaas@pfrc.org; i2rs@ietf.org;
>>> i2rs-chairs@ietf.org;
>>= ;> d= raft-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 Wed, Aug = 17, 2016 at 09:16:48PM -0400, Susan Hares wrote:
>>>> = ------------------------------------------------------------------
>= ;>>> --
>>>> --
>>>> = COMMENT:
>>>> = ------------------------------------------------------------------
>= ;>>> --
>>>> = --
>>>>
>>>>> Section = 3:
>>>>> Can you clarify the second to last = sentence?  Do you mean there
>>>>> = are
>>> sections that indicate an insecure transport should = be used?
>>>>>  I2RS allows the use of = an
>>>>> insecure transport for portions of data = models that clearly
>>>>> indicate  insecure = transport.
>>>>
>>>>> = Perhaps:
>>>>> I2RS allows the use of = an
>>>>> insecure transport for portions of data = models that clearly
>>>>> indicate the use of an  = insecure transport.
>>>
>>> I still wonder how a = data model writer can reasonably decide whether
>>> a piece = of information can be shipped safely over an insecure
>>> = transport since this decision often depends on the specifics of = a
>>> deployment
>> = situation.
>>>
>>> = /js
>>>
>>> PS: I hope we do not end up with = defining data multiple times (once
>>>    for = insecure transport and once for secured = transports).
>>>
>>> --
>>> 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/>
>>>= ;
>>> = _______________________________________________
>>> i2rs = mailing list
>>> i2rs@ietf.org
>>> https://www.ietf.org/mailman/listinfo/i2rs
>&= gt;
>> --
>> 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/>
>>>> _______________________________________________
>> = i2rs mailing list
>> i2rs@ietf.org
>> https://www.ietf.org/mailman/listinfo/i2rs
>&= gt;
>
> --
> 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/>
>

_______________________________________________
i2rs mailing = list
i2rs@ietf.org
https://www.ietf.org/mailman/listinfo/i2rs

 

------=_NextPart_000_00DD_01D1F967.6BC252A0-- From nobody Thu Aug 18 13:07:20 2016 Return-Path: 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 113A812D0C5 for ; Thu, 18 Aug 2016 13:02:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.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 PMp5DP3_BJBX for ; Thu, 18 Aug 2016 13:02:29 -0700 (PDT) Received: from mail-ua0-x234.google.com (mail-ua0-x234.google.com [IPv6:2607:f8b0:400c:c08::234]) (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 602FE12D9CA for ; Thu, 18 Aug 2016 13:02:06 -0700 (PDT) Received: by mail-ua0-x234.google.com with SMTP id 97so46192537uav.3 for ; Thu, 18 Aug 2016 13:02:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=MUGfqRkKduLZ88sirwKJ2bLLZgVwioE9SrwnI5MYtb8=; b=L/1gPLj1pClR2/V+fHaCPHWOMulz56sDWrvX/zID93a9GqfewKZXwq7YcQ8i6m3pAU bfAAwxCPLg0mBWGpwmiN75pNEIPDKIqgxzlbgY+jbnUojptTcywsTJ2dWBWpO09qQU7K Pxc0Vtl7hO3iy+3ZFDgrjw63pm5jd/ObjGxBF3rKG+dmpk5Kx2eJbIDcUzg+XOyDxRFm kQgr+BR5oIQwCcSrxX/SDOeDWQeObFNEwssi/XLNkhpY5ZU5Q7R1Ctljv1EB0mYGg7H/ Ak7QbMwOdLxUBwtjvzm7A/+2Kc5bzhozH93/LTyLcgU9FCEDNCS7Rmua3Q5XEjTPRWos nhIg== 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; bh=MUGfqRkKduLZ88sirwKJ2bLLZgVwioE9SrwnI5MYtb8=; b=AxPrq+ZNiGv5lo2oOjEAv8AEPuY9U0gTFM+iOKDNSvskYq0cd06tCDA/+q8Wat739A MuTmkAdaKgjOS1rSfiZ3wkIlbqDS0w/omK+Ksm6lYDEZezcTf1z9jLl9MOvU1JXVa0Jw O+B9ftGzECRlN7uWQNIJ12ZLgkqk75wAIDK7OR3LJ1Z4YC12B2Mr4EpP0dqHwuxOBQ2s rKy0sZDXg9np+WW1I2IPLGlZPzUQmuEO4fO9NWdAtcbGA34v03H6OlUmmZHM3SGm2WrE X6bDt8mF96avN1N/Cr4eyM44LzLxIlVlqrG1XR512KZ2NAPuESTO8aeN8goS3NJodFUU EqPg== X-Gm-Message-State: AEkoouum+gASosqUuEF0606upw+LtYzMYzGg460PdEgVm9eTfKAtnX3FeW/TFEa2pkgNwYKwKOmye30zHrZUPQ== X-Received: by 10.176.3.72 with SMTP id 66mr2033187uat.105.1471550525306; Thu, 18 Aug 2016 13:02:05 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.4.198 with HTTP; Thu, 18 Aug 2016 13:02:03 -0700 (PDT) In-Reply-To: <00dc01d1f988$f2cec280$d86c4780$@ndzh.com> References: <147146974235.23784.4389421535496134619.idtracker@ietfa.amsl.com> <013b01d1f8ee$31fa09b0$95ee1d10$@ndzh.com> <20160818073203.GA4338@elstar.local> <04b501d1f949$116c63e0$34452ba0$@ndzh.com> <20160818121405.GA5282@elstar.local> <051301d1f950$7739c670$65ad5350$@ndzh.com> <20160818130555.GA5366@elstar.local> <051701d1f952$c4ae0b30$4e0a2190$@ndzh.com> <6BCE198E4EAEFC4CAB45D75826EFB0761525CCD7@eusaamb101.ericsson.se> <003801d1f97f$3d16eb10$b744c130$@ndzh.com> <00dc01d1f988$f2cec280$d86c4780$@ndzh.com> From: Andy Bierman Date: Thu, 18 Aug 2016 13:02:03 -0700 Message-ID: To: Susan Hares Content-Type: multipart/alternative; boundary=001a113f2694549a9b053a5e0e9d Archived-At: X-Mailman-Approved-At: Thu, 18 Aug 2016 13:07:18 -0700 Cc: "i2rs@ietf.org" , Alissa Cooper , Juergen Schoenwaelder , 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) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Aug 2016 20:02:33 -0000 --001a113f2694549a9b053a5e0e9d Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, Aug 18, 2016 at 12:44 PM, Susan Hares wrote: > Andy: > > > > Thank you =E2=80=93 I thought it was on whether we could implement insecu= re > transport in a Yang module. > > > > The requirement text you are working with is: > > > > SEC-REQ-08: The I2RS protocol MUST be able to transfer data over a > secure transport and optionally MAY be able to transfer data over a > non-secure transport. > > > > I do not understand why approving the ok for non-secure transport for som= e > modules means the following to you: > > > > *=E2=80=9C the IETF needs to agree that there could never possibly be any > deployment that would not want to allow exposure of the data.* > > *Not now. Not 20 years from now.=E2=80=9D* > > > As I understand it, this requirement has another requirement associated with it that says the data has to be identified as OK-for-nonsecure-transport. An extension in the data model says that all instances of the object in all possible deployments cannot be considered sensistive and therefore needs disclosure protection. It may seem like even a simple octet counter is safe to send in the clear, but not if that opens up correlation attacks. (e.g., I can send data to some host. I can see that index 455992 is incrementing the in-octets counters in a way that strongly correlates to my test traffic. Therefore I can lear= n that arbitrary index 455992 is really John Doe or really suite #14, etc. > I had thought that the security-directorate and other reviewers would loo= k > at each module that is insecure, and consider whether it was reasonable > for the use case at this time. This is what I understood from Russ > Housley=E2=80=99s first review of this technology. Since like you, I bel= ieve the > operator is going to configure what modules are allowed on systems. I > agree that this requirement provides a full scope of the work, but > implementers will require network operators to configure these features o= n. > > > > Sue > Andy > > > > > *From:* Andy Bierman [mailto:andy@yumaworks.com] > *Sent:* Thursday, August 18, 2016 2:53 PM > *To:* Susan Hares > *Cc:* Alissa Cooper; Joel Halpern; i2rs@ietf.org; Juergen Schoenwaelder; > i2rs-chairs@ietf.org; Kathleen Moriarty; IESG; Jeffrey Haas; > 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) > > > > Hi, > > > > I did not think Juergen's comment was about running code. > > > > In order for a data node to get the "ok-for-nonsecure-transports" approva= l > > in an IETF module, the IETF needs to agree that there could never possibl= y > be > > any deployment that would not want to allow exposure of the data. > > Not now. Not 20 years from now. > > > > I can see a vendor making that decision for their own proprietary modules= , > > but it seems less likely for standard modules. > > > > Seems like the operator is going to have to configure what is allowed > > for nonsecure transport anyway, so just let them decide. > > I don't really object to the extension or the requirement. > > It doesn't help much but it doesn't hurt much either. > > > > > > Andy > > > > > > > > On Thu, Aug 18, 2016 at 11:35 AM, Susan Hares wrote: > > Alissa: > > Just a little input you may not know. My background is 15 years > (1995-2010) developing a routing/switching platform (denoted as GateD) > which was sold to over 200 companies. We developed XML and a binary XML > based product that configured this product. It could do 100K configurati= on > lines and reboot in less than a second on most hardware. We also provide > status messages in secure streams and non-secure streams. I sold early > version of this code to companies that Alia has worked for - so she has > personal viewed the code. At the height of our work, our development te= am > ran to 50 people which I directed (First as VP of Engineering, and then a= s > CTO). It is due to this level of experience that Alia selected me for the > co-chair. Russ White has understood Cisco's process, and has also > directed software development teams for routing. > > In order to freshen my direct experience with I2RS on open source work, I > am working on a publically available work in Quagga based on the confD > product suggested by Cisco. > > In contrast, Juergen is a university professor who has worked on > proto-types. He is not working on an implementation. I hope he will. > > I hope you will consider this background in my response to your comments > below. > > Sue > > > -----Original Message----- > From: Alissa Cooper [mailto:alissa@cooperw.in] > Sent: Thursday, August 18, 2016 12:54 PM > To: Joel Halpern > Cc: Susan Hares; Juergen Schoenwaelder; i2rs@ietf.org; > i2rs-chairs@ietf.org; Kathleen Moriarty; IESG; jhaas@pfrc.org; > 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) > > Jumping in here because this is relevant to my DISCUSS, hope nobody minds > (but if you do, I can go back to the other thread). > > >> On Aug 18, 2016, at 10:30 AM, Joel Halpern > wrote: > >> > >> Let me try a different take approach to this particular question. > >> > >> Let me start by putting aside the question of where things are marked, > and come back to that afterwards. > >> > >> There are a number of cases that I2RS has been asked to cover of high > rate telemetry data. This may be BGP update information, it may be > frequent information about line card activity. There are other cases, so= me > of which have been documented. > >> > >> While not completely insensitive, the operators have made clear that > they see protecting this data as unnecessary. While I would hope over ti= me > to move to a domain where all of it is protect, that is not trivial. As > the I2RS Architecture points out, it is expected that what we describe as= a > single I2RS >communication between a client and agent is actually > associated with multiple channels of communication. > >> > >> Now, if you want to say that the I2RS protocol requirements cannot > allow for unprotected channels, I guess we have disconnect between the IE= SG > and the WG. > >> > >> If we say that we can allow for unprotected channels, we then get to > the question of which data can be sent over such channels. While > architecturally I agree with Juergen that the model is a bad place to > specify it, the obverse is also true. Not having some limits on what can > be sent unprotected >causes concern about insufficient protection. If I > recall correctly, earlier security reviews called us to task for being to= o > broad in what we allowed. > >> > >> So, if the IESG wants us to just allow it anywhere, because the model > is an awkward place to define the limitation, I can live with that. What= I > can't live with is being told both that the model is a bad place to defin= e > it and that there must be restrictions on what is sent unprotected, > >> without any proposal on how we are to move forward. > > > Thank you Joel, this explanation helps me a lot. I think there is a > disconnect about how the restrictions are expressed. From reading the ema= il > traffic about this document, it strikes me that trying to express the > restrictions programmatically doesn=E2=80=99t make much sense in this cas= e. > > I agree with Juergen that it will be challenging to make a judgment a > priori in order to bake a restriction into a data model, because data tha= t > is considered sensitive enough to warrant a secure transport in one > deployment may not be considered sensitive in another deployment. > > So for any data elements where there is any question at all about > whether they might be sensitive (i.e., any data elements that are not > already routinely made public), > > I would expect data model authors to end up indicating that they may be > sent over either secure or insecure transport, which renders the indicati= on > not useful. > > Perhaps it would make more sense then to just enumerate in the text the > cases that motivate the inclusion of protocol support for insecure > transport: > > > > 1. For conveyance of information that is already routinely made public. > > 2. For line card activity data where there is no likely upgrade path to > support secure transports in the foreseeable future. > > > > Then the normative requirements would be on clients and agents to use > secure transports unless those clients and agents are deployed where eith= er > of the operational circumstances above necessitate otherwise. > > Alissa > > Point 1: > I disagree with Juergen on the difficulty in specifying the sections of > the yang modules. I have provided a suggested solution in: > https://tools.ietf.org/html/draft-hares-i2rs-protocol- > strawman-03#section-4.5.2. > > Given the mount schema functionality, we can mount ephemeral state module > which augment non-ephemeral state modules which are "in-secure only". > > Point 2: > I am willing to put an enumeration of the use cases in the protocol > requirement, but I would like to understand the purpose for the > enumeration. We are not doing a use case, but a requirements document. > This information appears to be a "use case" rather than a technical > description. What purpose are you looking for this enumeration to > server. Are you looking for the enumeration in SEC-REQ-08? > > Point 3: Could you review -08.txt on this topic, especially the text > below. Given your comments, I believe I should change the last line to a > MUST. > New/ The default mode of transport is > secure so data models MUST clearly annotate what data nodes can be > passed over an insecure connection. > / > > Sue > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > As to the normative requirements (-08.txt) version: > > Section 3: > > I2RS allows the use of an insecure transport for portions of data > models that clearly indicate the use of an insecure transport. > Operators deploying I2RS must determine if they want to populate and > deploy the portions of the data model which use insecure transports. > > In Section 3.2 in version -08.txt > > SEC-REQ-08: The I2RS protocol MUST be able to transfer data over a > secure transport and optionally MAY be able to transfer data over a > non-secure transport. A secure transport MUST provide data > confidentiality, data integrity, and replay prevention. > > The default I2RS transport is a secure transport. > > 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. > > The configuration of ephemeral data in the I2RS Agent by the I2RS > client SHOULD be done over a secure transport. It is anticipated > that the passing of most I2RS ephemeral state operational status > SHOULD be done over a secure transport. As > [I-D.ietf-i2rs-ephemeral-state] notes, a data model MUST indicate > whether the transport exchanging the data between I2RS client and > I2RS agent is secure or insecure. > > The default mode of transport is > secure so data models SHOULD clearly annotate what data nodes can be > passed over an insecure connection. > > > > > Yours, > > Joel > > > > -----Original Message----- > > From: Susan Hares [mailto:shares@ndzh.com] > > Sent: Thursday, August 18, 2016 9:17 AM > > To: 'Juergen Schoenwaelder' > > Cc: i2rs@ietf.org; i2rs-chairs@ietf.org; 'Kathleen Moriarty' > > ; 'The IESG' ; > > jhaas@pfrc.org; > > 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) > > > > Juergen and Kathleen: > > > > Let me proceed with two examples: BGP route views data model and the > event for the web-service data. > > > > The content of these data models are designated as exposed to public. > The routing system only populates the proposed BGP route views data model > with the data destined for the BGP looking glass. The policy on the > routing system indicates what information gets transferred. The data mod= el > is completely available to the public. The Yang Doctors are going to > review this by seeing the whole model is public and available via > non-secure means. > > The security people are going to review this seeing that the whole mode= l > is public, and available via an unprotect means. The fact the data model > is all public should simplify the review. > > > > An event from the I2RS RIB that a web-service route is up is the second > case. The I2RS RIB has an event based on policy that indicates a > web-service route is up. The yang-1.1 doctors must review the content of > the event text to see it does not break privacy or provide too much > > information The event mechanisms will need to work over secure > transport > > and insecure transport. Most of the data will go over the secure > transport event stream. However, a small amount of information may go ove= r > the insecure transport stream. > > > > First, let me know if my use cases are understandable. Second, let me > know if you disagree with this use cases. > > > > Fyi - IESG approved the architecture with the insecure stream. > > > > Sue > > > > -----Original Message----- > > From: Juergen Schoenwaelder > > [mailto:j.schoenwaelder@jacobs-university.de] > > Sent: Thursday, August 18, 2016 9:06 AM > > To: Susan Hares > > Cc: i2rs@ietf.org; i2rs-chairs@ietf.org; 'Kathleen Moriarty'; 'The > > IESG'; jhaas@pfrc.org; > > 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) > > > > I just do not know on which basis a data model writer can decide whethe= r > a data object can be exposed in an unprotected way. How are YANG doctors > going to review this? How are security directorate people going to judge > this? But as promised, I leave (still puzzled) now. > > > > /js > > > > On Thu, Aug 18, 2016 at 09:00:14AM -0400, Susan Hares wrote: > >> Juergen: > >> > >> Yes, we seem to disagree on the value of making it hardwired in the > model. > >> For me, the value is a common understanding of deployment > >> distribution > > such > >> as the route-views. Since the operators argued strongly for this > point, > > I > >> think the best idea is to get it working in code and then see if the > >> deployment matches the requests. > >> > >> Sue > >> > >> -----Original Message----- > >> From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Juergen > >> Schoenwaelder > >> Sent: Thursday, August 18, 2016 8:14 AM > >> To: Susan Hares > >> Cc: i2rs@ietf.org; i2rs-chairs@ietf.org; 'Kathleen Moriarty'; 'The > >> IESG'; jhaas@pfrc.org; > >> 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) > >> > >> Sue, > >> > >> I still do not see why the 'mode of exposure' of data benefits from > >> being hard-wired in the data model. For me, it is a situational and > >> deployment specific question. But I shut up here since I aired this > >> concern before (and we simply seem to disagree). > >> > >> /js > >> > >> On Thu, Aug 18, 2016 at 08:07:18AM -0400, Susan Hares wrote: > >>> Juergen: > >>> > >>> My example is the looking glass servers for the BGP route views > >>> project > >>> (http://www.routeviews.org/) or a route indicating the presence of a > >>> web-server that is public. For the BGP I2RS route, a yang model cou= ld > >>> replace the looking glass function, and provide events for these > looking > >>> glass functions. For the web-server route, an event be sent when > > that > >>> one route is added. > >>> > >>> Sue > >>> > >>> > >>> -----Original Message----- > >>> From: Juergen Schoenwaelder > >>> [mailto:j.schoenwaelder@jacobs-university.de] > >>> Sent: Thursday, August 18, 2016 3:32 AM > >>> To: Susan Hares > >>> Cc: 'Kathleen Moriarty'; 'The IESG'; jhaas@pfrc.org; i2rs@ietf.org; > >>> i2rs-chairs@ietf.org; > >>> 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 Wed, Aug 17, 2016 at 09:16:48PM -0400, Susan Hares wrote: > >>>> ------------------------------------------------------------------ > >>>> -- > >>>> -- > >>>> COMMENT: > >>>> ------------------------------------------------------------------ > >>>> -- > >>>> -- > >>>> > >>>>> Section 3: > >>>>> Can you clarify the second to last sentence? Do you mean there > >>>>> are > >>> sections that indicate an insecure transport should be used? > >>>>> I2RS allows the use of an > >>>>> insecure transport for portions of data models that clearly > >>>>> indicate insecure transport. > >>>> > >>>>> Perhaps: > >>>>> I2RS allows the use of an > >>>>> insecure transport for portions of data models that clearly > >>>>> indicate the use of an insecure transport. > >>> > >>> I still wonder how a data model writer can reasonably decide whether > >>> a piece of information can be shipped safely over an insecure > >>> transport since this decision often depends on the specifics of a > >>> deployment > >> situation. > >>> > >>> /js > >>> > >>> PS: I hope we do not end up with defining data multiple times (once > >>> for insecure transport and once for secured transports). > >>> > >>> -- > >>> Juergen Schoenwaelder Jacobs University Bremen gGmbH > >>> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | German= y > >>> Fax: +49 421 200 3103 > >>> > >>> _______________________________________________ > >>> i2rs mailing list > >>> i2rs@ietf.org > >>> https://www.ietf.org/mailman/listinfo/i2rs > >> > >> -- > >> Juergen Schoenwaelder Jacobs University Bremen gGmbH > >> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > >> Fax: +49 421 200 3103 > >> > >> _______________________________________________ > >> i2rs mailing list > >> i2rs@ietf.org > >> https://www.ietf.org/mailman/listinfo/i2rs > >> > > > > -- > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > > Fax: +49 421 200 3103 > > > > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs > > > --001a113f2694549a9b053a5e0e9d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Aug 18, 2016 at 12:44 PM, Susan Hares <shares@ndzh.com> wrote:

Andy:

=C2=A0=

Thank you =E2=80=93 I though= t it was on whether we could implement insecure transport in a Yang module.=

=C2=A0=

The requirement text = you are working with is:

=C2=A0

=C2=A0 =C2= =A0SEC-REQ-08: The I2RS protocol MUST be able to transfer data over a
= =C2=A0 =C2=A0secure transport and optionally MAY be able to transfer data o= ver a
=C2=A0 =C2=A0non-secure transport.

=C2=A0

I do not understand why approving the ok for non-secure trans= port for some modules means the following to you:

=

=C2=A0

=E2=80=9C the IETF n= eeds to agree that there could never possibly be any deployment that would = not want to allow exposure of the data.

Not now. Not 20 years from now.= =E2=80=9D

<= u>=C2=A0



As I understand it, this requirement has another requirement associ= ated with it
that says the data has to be identified as OK-for-no= nsecure-transport.

An extension in the data model = says that all instances of the object in
all possible deployments= cannot be considered sensistive and therefore
needs disclosure p= rotection.

It may seem like even a simple octet co= unter is safe to send in the clear,
but not if that opens up corr= elation attacks. =C2=A0(e.g., I can send data to some
host.=C2=A0= I can see that index 455992 is incrementing the in-octets counters
in a way that strongly correlates to my test traffic.=C2=A0 Therefore I = can learn
that arbitrary index 455992 is really John Doe or reall= y suite #14, etc.

=C2=A0

I had thought that the security-directorate and other reviewers woul= d look at each module that is insecure, and =C2=A0consider whether it was r= easonable for the use case at this time.=C2=A0 =C2=A0This is what I underst= ood from Russ Housley=E2=80=99s first review of this technology.=C2=A0 Sinc= e like you, I believe the operator is going to =C2=A0configure what modules= are allowed on systems.=C2=A0 =C2=A0I agree that this requirement provides= a full scope of the work, but implementers will require network operators = to configure these features on.

=C2=A0

Sue


Andy
=C2=A0

<= p class=3D"MsoNormal">=C2=A0

=C2=A0=

From: Andy Bierman [mailto:andy@yumaworks.com]
Sent: Thursday, August 18, 2016 2:5= 3 PM
To: Susan Hares
Cc: Alissa Cooper; Joel Halpern; <= a href=3D"mailto:i2rs@ietf.org" target=3D"_blank">i2rs@ietf.org; Juerge= n Schoenwaelder; = i2rs-chairs@ietf.org; Kathleen Moriarty; IESG; Jeffrey Haas; draft-ietf-i2rs-protocol-security-requirements@ietf.orgSubject: Re: [i2rs] Kathleen Moriarty's Discuss on draft-ietf-i= 2rs-protocol-security-requirements-07: (with DISCUSS and COMMENT)

=C2=A0

Hi,

=C2=A0

I did not think Juergen= 's comment was about running code.

=C2=A0

In= order for a data node to get the "ok-for-nonsecure-transports" a= pproval

in an IETF modul= e, the IETF needs to agree that there could never possibly be=

any deployment that would not want to= allow exposure of the data.

Not now. Not 20 years from now.

=C2=A0

I = can see a vendor making that decision for their own proprietary modules,=

but it seems less likely f= or standard modules.

= =C2=A0

Seems like the opera= tor is going to have to configure what is allowed

for nonsecure transport anyway, so just let them = decide.

I don't real= ly object to the extension or the requirement.

=

It doesn't help much but it doesn't hurt muc= h either.

=C2=A0<= u>

=C2=A0

<= div>

Andy

=C2=A0

= =C2=A0

=C2=A0

On Thu, Aug 18, 2016 at 11:35 AM, Susan H= ares <shares@ndzh.c= om> wrote:

Alissa:

Ju= st a little input you may not know.=C2=A0 My background is 15 years (1995-2= 010)=C2=A0 developing a routing/switching platform (denoted as GateD) which= was sold to over 200 companies.=C2=A0 =C2=A0We developed XML and a binary = XML based product that configured this product.=C2=A0 It could do 100K conf= iguration lines and reboot in less than a second on most hardware.=C2=A0 We= also provide status messages in secure streams and non-secure streams.=C2= =A0 =C2=A0 I sold early version of this code to companies that Alia has wor= ked for=C2=A0 - so she has personal viewed the code.=C2=A0 =C2=A0At the hei= ght of our work, our development team ran to 50 people which I directed (Fi= rst as VP of Engineering, and then as CTO). It is due to this level of expe= rience that Alia selected me for the co-chair.=C2=A0 =C2=A0Russ White has u= nderstood Cisco's process, and has also directed software development t= eams for routing.

In order to freshen my direct experience with I2RS= on open source work, I am working on a publically available work in Quagga= based on the confD product suggested by Cisco.

In contrast, Juergen= is a university professor who has worked on proto-types.=C2=A0 =C2=A0He is= not working on an implementation.=C2=A0 =C2=A0I hope he will.

I hop= e you will consider this background in my response to your comments below.<= br>
Sue


-----Original Message-----
From: Alissa Cooper [ma= ilto:alissa@cooperw.= in]
Sent: Thursday, August 18, 2016 12:54 PM
To: Joel Halpern
= Cc: Susan Hares; Juergen Schoenwaelder; i2rs@ietf.org; i2rs-chairs@ietf.org; Kathleen Moriarty; IESG; jhaas@pfrc.org; 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)

= Jumping in here because this is relevant to my DISCUSS, hope nobody minds (= but if you do, I can go back to the other thread).

>> On Aug 1= 8, 2016, at 10:30 AM, Joel Halpern <joel.halpern@ericsson.com> wrote:
>= >
>> Let me try a different take approach to this particular qu= estion.
>>
>> Let me start by putting aside the question = of where things are marked, and come back to that afterwards.
>>>> There are a number of cases that I2RS has been asked to cover of= high rate telemetry data.=C2=A0 This may be BGP update information, it may= be frequent information about line card activity.=C2=A0 There are other ca= ses, some of which have been documented.
>>
>> While not = completely insensitive, the operators have made clear that they see protect= ing this data as unnecessary.=C2=A0 While I would hope over time to move to= a domain where all of it is protect, that is not trivial.=C2=A0 As the I2R= S Architecture points out, it is expected that what we describe as a single= I2RS >communication between a client and agent is actually associated w= ith multiple channels of communication.
>>
>> Now, if you= want to say that the I2RS protocol requirements cannot allow for unprotect= ed channels, I guess we have disconnect between the IESG and the WG.
>= ;>
>> If we say that we can allow for unprotected channels, we = then get to the question of which data can be sent over such channels.=C2= =A0 While architecturally I agree with Juergen that the model is a bad plac= e to specify it, the obverse is also true.=C2=A0 Not having some limits on = what can be sent unprotected >causes concern about insufficient protecti= on.=C2=A0 If I recall correctly, earlier security reviews called us to task= for being too broad in what we allowed.
>>
>> So, if the= IESG wants us to just allow it anywhere, because the model is an awkward p= lace to define the limitation, I can live with that.=C2=A0 What I can't= live with is being told both that the model is a bad place to define it an= d that there must be restrictions on what is sent unprotected,
>> = without any proposal on how we are to move forward.

> Thank you J= oel, this explanation helps me a lot. I think there is a disconnect about h= ow the restrictions are expressed. From reading the email traffic about thi= s document, it strikes me that trying to express the restrictions programma= tically doesn=E2=80=99t make much sense in this case.
> I agree with = Juergen that it will be challenging to make a judgment a priori in order to= bake a restriction into a data model, because data that is considered sens= itive enough to warrant a secure transport in one deployment may not be con= sidered sensitive in another deployment.
> So for any data elements w= here there is any question at all about whether they might be sensitive (i.= e., any data elements that are not already routinely made public),
> = I would expect data model authors to end up indicating that they may be sen= t over either secure or insecure transport, which renders the indication no= t useful.
> Perhaps it would make more sense then to just enumerate i= n the text the cases that motivate the inclusion of protocol support for in= secure transport:
>
> 1. For conveyance of information that is = already routinely made public.
> 2. For line card activity data where= there is no likely upgrade path to support secure transports in the forese= eable future.
>
> Then the normative requirements would be on c= lients and agents to use secure transports unless those clients and agents = are deployed where either of the operational circumstances above necessitat= e otherwise.
> Alissa

Point 1:
I disagree with Juergen on t= he difficulty in specifying the sections of the yang modules.=C2=A0 I have = provided a suggested solution in:
htt= ps://tools.ietf.org/html/draft-hares-i2rs-protocol-strawman-03#se= ction-4.5.2.

Given the mount schema functionality, we can mount = ephemeral state module which augment non-ephemeral state modules which are = "in-secure only".

Point 2:
I am willing to put an enume= ration of the use cases in the protocol requirement, but I would like to un= derstand the purpose for the enumeration.=C2=A0 =C2=A0We are not doing a us= e case, but a requirements document.=C2=A0 This information appears to be a= "use case" rather than a technical description.=C2=A0 =C2=A0What= purpose are you looking for this enumeration to server.=C2=A0 Are you look= ing for the enumeration in SEC-REQ-08?

Point 3: Could you review -08= .txt on this topic, especially the text below.=C2=A0 Given your comments, I= believe I should change the last line to a MUST.
New/=C2=A0 =C2=A0The d= efault mode of transport is
=C2=A0 =C2=A0secure so data models MUST clea= rly annotate what data nodes can be
=C2=A0 =C2=A0passed over an insecure= connection.
/

Sue

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D
As to the normative requirements (-08.txt) version:
Section 3:

=C2=A0 =C2=A0I2RS allows the use of an insecure tra= nsport for portions of data
=C2=A0 =C2=A0models that clearly indicate th= e use of an insecure transport.
=C2=A0 =C2=A0Operators deploying I2RS mu= st determine if they want to populate and
=C2=A0 =C2=A0deploy the portio= ns of the data model which use insecure transports.

In Section 3.2 i= n version -08.txt

=C2=A0 =C2=A0SEC-REQ-08: The I2RS protocol MUST be= able to transfer data over a
=C2=A0 =C2=A0secure transport and optional= ly MAY be able to transfer data over a
=C2=A0 =C2=A0non-secure transport= .=C2=A0 A secure transport MUST provide data
=C2=A0 =C2=A0confidentialit= y, data integrity, and replay prevention.

=C2=A0 =C2=A0The default I= 2RS transport is a secure transport.

=C2=A0 =C2=A0A non-secure trans= port can be used for publishing telemetry data or
=C2=A0 =C2=A0other ope= rational state that was specifically indicated to non-
=C2=A0 =C2=A0conf= idential in the data model in the Yang syntax.

=C2=A0 =C2=A0The conf= iguration of ephemeral data in the I2RS Agent by the I2RS
=C2=A0 =C2=A0c= lient SHOULD be done over a secure transport.=C2=A0 It is anticipated
= =C2=A0 =C2=A0that the passing of most I2RS ephemeral state operational stat= us
=C2=A0 =C2=A0SHOULD be done over a secure transport.=C2=A0 As
=C2= =A0 =C2=A0[I-D.ietf-i2rs-ephemeral-state] notes,=C2=A0 a data model MU= ST indicate
=C2=A0 =C2=A0whether the transport exchanging the data betwe= en I2RS client and
=C2=A0 =C2=A0I2RS agent is secure or insecure.
=C2=A0 =C2=A0The default mode of transport is
=C2=A0 =C2=A0secure so da= ta models SHOULD clearly annotate what data nodes can be
=C2=A0 =C2=A0pa= ssed over an insecure connection.

>
> Yours,
> Joel>
> -----Original Message-----
> From: Susan Hares [mailto= :shares@ndzh.com]<= br>> Sent: Thursday, August 18, 2016 9:17 AM
> To: 'Juergen Sc= hoenwaelder' <j.schoenwaelder@jacobs-university.de>
&g= t; Cc: i2rs@ietf.org= ; i2rs-chairs@iet= f.org; 'Kathleen Moriarty'
> <Kathleen.Moriarty.ietf@gmail.= com>; 'The IESG' <iesg@ietf.org>;
> jhaas@pfrc.org;
> draf= t-ietf-i2rs-protocol-security-requirements@ietf.org
> Subjec= t: RE: [i2rs] Kathleen Moriarty's Discuss on
> draft-ietf-i2rs-pr= otocol-security-requirements-07: (with DISCUSS and
> COMMENT)>
> Juergen and Kathleen:
>
> Let me proceed with two= examples: BGP route views data model and the event for the web-service dat= a.
>
> The content of these data models are designated as expos= ed to public.=C2=A0 The routing system only populates the proposed BGP rout= e views data model with the data destined for the BGP looking glass.=C2=A0 = The policy on the routing system indicates what information gets transferre= d.=C2=A0 The data model is completely available to the public.=C2=A0 The Ya= ng Doctors are going to review this by seeing the whole model is public and= available via non-secure means.
> The security people are going to r= eview this seeing that the whole model is public, and available via an unpr= otect means.=C2=A0 The fact the data model is all public should simplify th= e review.
>
> An event from the I2RS RIB that a web-service rou= te is up is the second case.=C2=A0 The I2RS RIB has an event based on polic= y that indicates a web-service route is up.=C2=A0 The yang-1.1 doctors must= review the content of the event text to see it does not break privacy or p= rovide too much
> information=C2=A0 =C2=A0The event mechanisms will n= eed to work over secure transport
> and insecure transport.=C2=A0 Mos= t of the data will go over the secure transport event stream. However, a sm= all amount of information may go over the insecure transport stream.
>= ;
> First, let me know if my use cases are understandable.=C2=A0 Seco= nd, let me know if you disagree with this use cases.
>
> Fyi -= =C2=A0 IESG approved the architecture with the insecure stream.
>
= > Sue
>
> -----Original Message-----
> From: Juergen S= choenwaelder
> [mailto:j.schoenwaelder@jacobs-university.de]<= br>> Sent: Thursday, August 18, 2016 9:06 AM
> To: Susan Hares
= > Cc: i2rs@ietf.org; i2rs-chairs@i= etf.org; 'Kathleen Moriarty'; 'The
> IESG'; jhaas@pfrc.org;
> = draft-ietf-i2rs-protocol-security-requirements@ietf.= org
> Subject: Re: [i2rs] Kathleen Moriarty's Discuss on
&= gt; draft-ietf-i2rs-protocol-security-requirements-07: (with DISCUSS a= nd
> COMMENT)
>
> I just do not know on which basis a dat= a model writer can decide whether a data object can be exposed in an unprot= ected way. How are YANG doctors going to review this? How are security dire= ctorate people going to judge this? But as promised, I leave (still puzzled= ) now.
>
> /js
>
> On Thu, Aug 18, 2016 at 09:00:14= AM -0400, Susan Hares wrote:
>> Juergen:
>>
>> Y= es, we seem to disagree on the value of making it hardwired in the model.>> For me, the value is a common understanding of deployment
>= ;> distribution
> such
>> as the route-views.=C2=A0 =C2= =A0Since the operators argued strongly for this point,
> I
>>= ; think the best idea is to get it working in code and then see if the
&= gt;> deployment matches the requests.
>>
>> Sue
>= ;>
>> -----Original Message-----
>> From: i2rs [mailto= :i2rs-bounces@ie= tf.org] On Behalf Of Juergen
>> Schoenwaelder
>> Sent= : Thursday, August 18, 2016 8:14 AM
>> To: Susan Hares
>>= Cc: i2rs@ietf.org; = i2rs-chairs@ietf.= org; 'Kathleen Moriarty'; 'The
>> IESG'; jhaas@pfrc.org;
>&= gt; draft-ietf-i2rs-protocol-security-requirements@i= etf.org
>> Subject: Re: [i2rs] Kathleen Moriarty's Discuss= on
>> draft-ietf-i2rs-protocol-security-requirements-07: (wi= th DISCUSS and
>> COMMENT)
>>
>> Sue,
>>= ;
>> I still do not see why the 'mode of exposure' of data= benefits from
>> being hard-wired in the data model. For me, it i= s a situational and
>> deployment specific question. But I shut up= here since I aired this
>> concern before (and we simply seem to = disagree).
>>
>> /js
>>
>> On Thu, Aug = 18, 2016 at 08:07:18AM -0400, Susan Hares wrote:
>>> Juergen:>>>
>>> My example is the looking glass servers for = the BGP route views
>>> project
>>> (http://www.routeviews.org/) = or a route indicating the presence of a
>>> web-server that is = public.=C2=A0 =C2=A0For the BGP I2RS route, a yang model could
>>&= gt; replace the looking glass function, and provide events for these lookin= g
>>> glass functions.=C2=A0 =C2=A0 For the web-server route,= =C2=A0 an event be sent when
> that
>>> one route is adde= d.
>>>
>>> Sue
>>>
>>>
&= gt;>> -----Original Message-----
>>> From: Juergen Schoen= waelder
>>> [mailto:j.schoenwaelder@jacobs-university.de]
>>> Sent: Thursday, August 18, 2016 3:32 AM
>>> = To: Susan Hares
>>> Cc: 'Kathleen Moriarty'; 'The I= ESG'; jhaas@pfrc.or= g; i2rs@ietf.org= ;
>>> i2rs-chairs@ietf.org;
>>> draft-ietf-i2r= s-protocol-security-requirements@ietf.org
>>> Subject:= Re: [i2rs] Kathleen Moriarty's Discuss on
>>> draft-ietf-i= 2rs-protocol-security-requirements-07: (with DISCUSS and
>>&g= t; COMMENT)
>>>
>>> On Wed, Aug 17, 2016 at 09:16:4= 8PM -0400, Susan Hares wrote:
>>>> -------------------------= -----------------------------------------
>>>> --<= br>>>>> --
>>>> COMMENT:
>>>> ---= --------------------------------------------------------------->>>> --
>>>> --
>>>>
>>= ;>>> Section 3:
>>>>> Can you clarify the second= to last sentence?=C2=A0 Do you mean there
>>>>> are
&= gt;>> sections that indicate an insecure transport should be used?>>>>>=C2=A0 I2RS allows the use of an
>>>>&g= t; insecure transport for portions of data models that clearly
>>&= gt;>> indicate=C2=A0 insecure transport.
>>>>
>&= gt;>>> Perhaps:
>>>>> I2RS allows the use of an<= br>>>>>> insecure transport for portions of data models that= clearly
>>>>> indicate the use of an=C2=A0 insecure tran= sport.
>>>
>>> I still wonder how a data model writ= er can reasonably decide whether
>>> a piece of information can= be shipped safely over an insecure
>>> transport since this de= cision often depends on the specifics of a
>>> deployment
&g= t;> situation.
>>>
>>> /js
>>>
&g= t;>> PS: I hope we do not end up with defining data multiple times (o= nce
>>>=C2=A0 =C2=A0 for insecure transport and once for secure= d transports).
>>>
>>> --
>>> Juergen S= choenwaelder=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Jacobs University Brem= en gGmbH
>>> Phone: +49 421 200 3587=C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0Campus Ring 1 | 28759 Bremen | Germany
>>> Fax:=C2=A0 = =C2=A0+49 421 200 3103=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<http://www.jacobs-univ= ersity.de/>
>>>
>>> ________________________= _______________________
>>> i2rs mailing list
>>&= gt; i2rs@ietf.org>>> https://www.ietf.org/mailman/listinfo/i2rs
>>=
>> --
>> Juergen Schoenwaelder=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0Jacobs University Bremen gGmbH
>> Phone: +49 421 = 200 3587=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Campus Ring 1 | 28759 Bremen | Ge= rmany
>> Fax:=C2=A0 =C2=A0+49 421 200 3103=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0<http://www.jacobs-university.de/>
>>
>> ___= ____________________________________________
>> i2rs mailing = list
>> i2rs@ie= tf.org
>> https://www.ietf.org/mailman/listinfo/i2rs>>
>
> --
> Juergen Schoenwaelder=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0Jacobs University Bremen gGmbH
> Phone: +49 4= 21 200 3587=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Campus Ring 1 | 28759 Bremen |= Germany
> Fax:=C2=A0 =C2=A0+49 421 200 3103=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0<http://www.jacobs-university.de/>
>


________= _______________________________________
i2rs mailing list
i2rs@ietf.org
https://w= ww.ietf.org/mailman/listinfo/i2rs

=C2=A0


--001a113f2694549a9b053a5e0e9d-- From nobody Fri Aug 19 01:58:26 2016 Return-Path: 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 D7F6212D86A; Fri, 19 Aug 2016 01:58:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.447 X-Spam-Level: X-Spam-Status: No, score=-5.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.247] 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 yDlUetKumjtP; Fri, 19 Aug 2016 01:58:14 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 612FA12D0B5; Fri, 19 Aug 2016 01:58:14 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 19DC2A80; Fri, 19 Aug 2016 10:58:04 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.205]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id nQEzDRBkf3Mk; Fri, 19 Aug 2016 10:57:56 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Fri, 19 Aug 2016 10:58:01 +0200 (CEST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 36D7C200A5; Fri, 19 Aug 2016 10:58:01 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id dvIB3dTu9LMa; Fri, 19 Aug 2016 10:57:58 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id D79DD200A3; Fri, 19 Aug 2016 10:57:57 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id AF3DC3C26DAA; Fri, 19 Aug 2016 10:57:56 +0200 (CEST) Date: Fri, 19 Aug 2016 10:57:56 +0200 From: Juergen Schoenwaelder To: Susan Hares Message-ID: <20160819085756.GA6759@elstar.local> Mail-Followup-To: Susan Hares , 'Alissa Cooper' , 'Joel Halpern' , i2rs@ietf.org, i2rs-chairs@ietf.org, 'Kathleen Moriarty' , 'IESG' , jhaas@pfrc.org, draft-ietf-i2rs-protocol-security-requirements@ietf.org References: <013b01d1f8ee$31fa09b0$95ee1d10$@ndzh.com> <20160818073203.GA4338@elstar.local> <04b501d1f949$116c63e0$34452ba0$@ndzh.com> <20160818121405.GA5282@elstar.local> <051301d1f950$7739c670$65ad5350$@ndzh.com> <20160818130555.GA5366@elstar.local> <051701d1f952$c4ae0b30$4e0a2190$@ndzh.com> <6BCE198E4EAEFC4CAB45D75826EFB0761525CCD7@eusaamb101.ericsson.se> <003801d1f97f$3d16eb10$b744c130$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline X-Clacks-Overhead: GNU Terry Pratchett Content-Transfer-Encoding: 8bit In-Reply-To: <003801d1f97f$3d16eb10$b744c130$@ndzh.com> User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Cc: i2rs@ietf.org, 'Alissa Cooper' , i2rs-chairs@ietf.org, 'Kathleen Moriarty' , 'IESG' , jhaas@pfrc.org, '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) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Aug 2016 08:58:18 -0000 I repeat my technical argument: While there may be deployments where non-secure transports may be reasonable to use, defining these situations statically as part of data model schemas does not follow established practices. The IETF has a long tradition of standardizing data models that can be used in a variety of operational contexts and I do not see reasons why we should move away from that basic approach. /js On Thu, Aug 18, 2016 at 02:35:03PM -0400, Susan Hares wrote: > Alissa: > > Just a little input you may not know. My background is 15 years (1995-2010) developing a routing/switching platform (denoted as GateD) which was sold to over 200 companies. We developed XML and a binary XML based product that configured this product. It could do 100K configuration lines and reboot in less than a second on most hardware. We also provide status messages in secure streams and non-secure streams. I sold early version of this code to companies that Alia has worked for - so she has personal viewed the code. At the height of our work, our development team ran to 50 people which I directed (First as VP of Engineering, and then as CTO). It is due to this level of experience that Alia selected me for the co-chair. Russ White has understood Cisco's process, and has also directed software development teams for routing. > > In order to freshen my direct experience with I2RS on open source work, I am working on a publically available work in Quagga based on the confD product suggested by Cisco. > > In contrast, Juergen is a university professor who has worked on proto-types. He is not working on an implementation. I hope he will. > > I hope you will consider this background in my response to your comments below. > > Sue > > > -----Original Message----- > From: Alissa Cooper [mailto:alissa@cooperw.in] > Sent: Thursday, August 18, 2016 12:54 PM > To: Joel Halpern > Cc: Susan Hares; Juergen Schoenwaelder; i2rs@ietf.org; i2rs-chairs@ietf.org; Kathleen Moriarty; IESG; jhaas@pfrc.org; 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) > > Jumping in here because this is relevant to my DISCUSS, hope nobody minds (but if you do, I can go back to the other thread). > > >> On Aug 18, 2016, at 10:30 AM, Joel Halpern wrote: > >> > >> Let me try a different take approach to this particular question. > >> > >> Let me start by putting aside the question of where things are marked, and come back to that afterwards. > >> > >> There are a number of cases that I2RS has been asked to cover of high rate telemetry data. This may be BGP update information, it may be frequent information about line card activity. There are other cases, some of which have been documented. > >> > >> While not completely insensitive, the operators have made clear that they see protecting this data as unnecessary. While I would hope over time to move to a domain where all of it is protect, that is not trivial. As the I2RS Architecture points out, it is expected that what we describe as a single I2RS >communication between a client and agent is actually associated with multiple channels of communication. > >> > >> Now, if you want to say that the I2RS protocol requirements cannot allow for unprotected channels, I guess we have disconnect between the IESG and the WG. > >> > >> If we say that we can allow for unprotected channels, we then get to the question of which data can be sent over such channels. While architecturally I agree with Juergen that the model is a bad place to specify it, the obverse is also true. Not having some limits on what can be sent unprotected >causes concern about insufficient protection. If I recall correctly, earlier security reviews called us to task for being too broad in what we allowed. > >> > >> So, if the IESG wants us to just allow it anywhere, because the model is an awkward place to define the limitation, I can live with that. What I can't live with is being told both that the model is a bad place to define it and that there must be restrictions on what is sent unprotected, > >> without any proposal on how we are to move forward. > > > Thank you Joel, this explanation helps me a lot. I think there is a disconnect about how the restrictions are expressed. From reading the email traffic about this document, it strikes me that trying to express the restrictions programmatically doesn’t make much sense in this case. > > I agree with Juergen that it will be challenging to make a judgment a priori in order to bake a restriction into a data model, because data that is considered sensitive enough to warrant a secure transport in one deployment may not be considered sensitive in another deployment. > > So for any data elements where there is any question at all about whether they might be sensitive (i.e., any data elements that are not already routinely made public), > > I would expect data model authors to end up indicating that they may be sent over either secure or insecure transport, which renders the indication not useful. > > Perhaps it would make more sense then to just enumerate in the text the cases that motivate the inclusion of protocol support for insecure transport: > > > > 1. For conveyance of information that is already routinely made public. > > 2. For line card activity data where there is no likely upgrade path to support secure transports in the foreseeable future. > > > > Then the normative requirements would be on clients and agents to use secure transports unless those clients and agents are deployed where either of the operational circumstances above necessitate otherwise. > > Alissa > > Point 1: > I disagree with Juergen on the difficulty in specifying the sections of the yang modules. I have provided a suggested solution in: > https://tools.ietf.org/html/draft-hares-i2rs-protocol-strawman-03#section-4.5.2. > > Given the mount schema functionality, we can mount ephemeral state module which augment non-ephemeral state modules which are "in-secure only". > > Point 2: > I am willing to put an enumeration of the use cases in the protocol requirement, but I would like to understand the purpose for the enumeration. We are not doing a use case, but a requirements document. This information appears to be a "use case" rather than a technical description. What purpose are you looking for this enumeration to server. Are you looking for the enumeration in SEC-REQ-08? > > Point 3: Could you review -08.txt on this topic, especially the text below. Given your comments, I believe I should change the last line to a MUST. > New/ The default mode of transport is > secure so data models MUST clearly annotate what data nodes can be > passed over an insecure connection. > / > > Sue > > =================== > As to the normative requirements (-08.txt) version: > > Section 3: > > I2RS allows the use of an insecure transport for portions of data > models that clearly indicate the use of an insecure transport. > Operators deploying I2RS must determine if they want to populate and > deploy the portions of the data model which use insecure transports. > > In Section 3.2 in version -08.txt > > SEC-REQ-08: The I2RS protocol MUST be able to transfer data over a > secure transport and optionally MAY be able to transfer data over a > non-secure transport. A secure transport MUST provide data > confidentiality, data integrity, and replay prevention. > > The default I2RS transport is a secure transport. > > 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. > > The configuration of ephemeral data in the I2RS Agent by the I2RS > client SHOULD be done over a secure transport. It is anticipated > that the passing of most I2RS ephemeral state operational status > SHOULD be done over a secure transport. As > [I-D.ietf-i2rs-ephemeral-state] notes, a data model MUST indicate > whether the transport exchanging the data between I2RS client and > I2RS agent is secure or insecure. > > The default mode of transport is > secure so data models SHOULD clearly annotate what data nodes can be > passed over an insecure connection. > > > > > Yours, > > Joel > > > > -----Original Message----- > > From: Susan Hares [mailto:shares@ndzh.com] > > Sent: Thursday, August 18, 2016 9:17 AM > > To: 'Juergen Schoenwaelder' > > Cc: i2rs@ietf.org; i2rs-chairs@ietf.org; 'Kathleen Moriarty' > > ; 'The IESG' ; > > jhaas@pfrc.org; > > 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) > > > > Juergen and Kathleen: > > > > Let me proceed with two examples: BGP route views data model and the event for the web-service data. > > > > The content of these data models are designated as exposed to public. The routing system only populates the proposed BGP route views data model with the data destined for the BGP looking glass. The policy on the routing system indicates what information gets transferred. The data model is completely available to the public. The Yang Doctors are going to review this by seeing the whole model is public and available via non-secure means. > > The security people are going to review this seeing that the whole model is public, and available via an unprotect means. The fact the data model is all public should simplify the review. > > > > An event from the I2RS RIB that a web-service route is up is the second case. The I2RS RIB has an event based on policy that indicates a web-service route is up. The yang-1.1 doctors must review the content of the event text to see it does not break privacy or provide too much > > information The event mechanisms will need to work over secure transport > > and insecure transport. Most of the data will go over the secure transport event stream. However, a small amount of information may go over the insecure transport stream. > > > > First, let me know if my use cases are understandable. Second, let me know if you disagree with this use cases. > > > > Fyi - IESG approved the architecture with the insecure stream. > > > > Sue > > > > -----Original Message----- > > From: Juergen Schoenwaelder > > [mailto:j.schoenwaelder@jacobs-university.de] > > Sent: Thursday, August 18, 2016 9:06 AM > > To: Susan Hares > > Cc: i2rs@ietf.org; i2rs-chairs@ietf.org; 'Kathleen Moriarty'; 'The > > IESG'; jhaas@pfrc.org; > > 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) > > > > I just do not know on which basis a data model writer can decide whether a data object can be exposed in an unprotected way. How are YANG doctors going to review this? How are security directorate people going to judge this? But as promised, I leave (still puzzled) now. > > > > /js > > > > On Thu, Aug 18, 2016 at 09:00:14AM -0400, Susan Hares wrote: > >> Juergen: > >> > >> Yes, we seem to disagree on the value of making it hardwired in the model. > >> For me, the value is a common understanding of deployment > >> distribution > > such > >> as the route-views. Since the operators argued strongly for this point, > > I > >> think the best idea is to get it working in code and then see if the > >> deployment matches the requests. > >> > >> Sue > >> > >> -----Original Message----- > >> From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Juergen > >> Schoenwaelder > >> Sent: Thursday, August 18, 2016 8:14 AM > >> To: Susan Hares > >> Cc: i2rs@ietf.org; i2rs-chairs@ietf.org; 'Kathleen Moriarty'; 'The > >> IESG'; jhaas@pfrc.org; > >> 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) > >> > >> Sue, > >> > >> I still do not see why the 'mode of exposure' of data benefits from > >> being hard-wired in the data model. For me, it is a situational and > >> deployment specific question. But I shut up here since I aired this > >> concern before (and we simply seem to disagree). > >> > >> /js > >> > >> On Thu, Aug 18, 2016 at 08:07:18AM -0400, Susan Hares wrote: > >>> Juergen: > >>> > >>> My example is the looking glass servers for the BGP route views > >>> project > >>> (http://www.routeviews.org/) or a route indicating the presence of a > >>> web-server that is public. For the BGP I2RS route, a yang model could > >>> replace the looking glass function, and provide events for these looking > >>> glass functions. For the web-server route, an event be sent when > > that > >>> one route is added. > >>> > >>> Sue > >>> > >>> > >>> -----Original Message----- > >>> From: Juergen Schoenwaelder > >>> [mailto:j.schoenwaelder@jacobs-university.de] > >>> Sent: Thursday, August 18, 2016 3:32 AM > >>> To: Susan Hares > >>> Cc: 'Kathleen Moriarty'; 'The IESG'; jhaas@pfrc.org; i2rs@ietf.org; > >>> i2rs-chairs@ietf.org; > >>> 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 Wed, Aug 17, 2016 at 09:16:48PM -0400, Susan Hares wrote: > >>>> ------------------------------------------------------------------ > >>>> -- > >>>> -- > >>>> COMMENT: > >>>> ------------------------------------------------------------------ > >>>> -- > >>>> -- > >>>> > >>>>> Section 3: > >>>>> Can you clarify the second to last sentence? Do you mean there > >>>>> are > >>> sections that indicate an insecure transport should be used? > >>>>> I2RS allows the use of an > >>>>> insecure transport for portions of data models that clearly > >>>>> indicate insecure transport. > >>>> > >>>>> Perhaps: > >>>>> I2RS allows the use of an > >>>>> insecure transport for portions of data models that clearly > >>>>> indicate the use of an insecure transport. > >>> > >>> I still wonder how a data model writer can reasonably decide whether > >>> a piece of information can be shipped safely over an insecure > >>> transport since this decision often depends on the specifics of a > >>> deployment > >> situation. > >>> > >>> /js > >>> > >>> PS: I hope we do not end up with defining data multiple times (once > >>> for insecure transport and once for secured transports). > >>> > >>> -- > >>> Juergen Schoenwaelder Jacobs University Bremen gGmbH > >>> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > >>> Fax: +49 421 200 3103 > >>> > >>> _______________________________________________ > >>> i2rs mailing list > >>> i2rs@ietf.org > >>> https://www.ietf.org/mailman/listinfo/i2rs > >> > >> -- > >> Juergen Schoenwaelder Jacobs University Bremen gGmbH > >> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > >> Fax: +49 421 200 3103 > >> > >> _______________________________________________ > >> i2rs mailing list > >> i2rs@ietf.org > >> https://www.ietf.org/mailman/listinfo/i2rs > >> > > > > -- > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > > Fax: +49 421 200 3103 > > > > -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Fri Aug 19 03:46:46 2016 Return-Path: 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 03F0112D8A5; Fri, 19 Aug 2016 03:46:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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, MIME_QP_LONG_LINE=0.001, 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 zrJT0ruCcpXm; Fri, 19 Aug 2016 03:46:42 -0700 (PDT) Received: from mail-qk0-x229.google.com (mail-qk0-x229.google.com [IPv6:2607:f8b0:400d:c09::229]) (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 6BABE12D51C; Fri, 19 Aug 2016 03:46:42 -0700 (PDT) Received: by mail-qk0-x229.google.com with SMTP id z190so41397120qkc.0; Fri, 19 Aug 2016 03:46:42 -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=NGObX4mwBrf6bm6yGpUHmkk+LTlKJLQbMaVm3fsm0qU=; b=LlgcYvWqR/BJhK41uL47RfixDj4n2LaXrPK0DGyRX0dOWVYfnTvA8oky63ZYqCCf0m ZYIdcR8vqmyYMH9Ql0TkVsQcndIVOzxFUf6TSkyqpXun3248tm2l9BOKiKlBvxewPT2S YgbH6VOUlATEHPybDkb5ChKgOsD2lEVMJ4bVF6scys2X/AVmJ0IsVRcgDK4+GPOKseGr y82xhIpEQDiwxnN0nsCzVJqXl+PHXWqRJKooRj06H475aQuC2XduhCuxtzrrWA5C/pJd HNjArUlgFqP0xS4cGtH00eQ5fNvyV6Hylek1pUspxRxYirxDIHNNbdXyjZaLrXrln8C4 mWRA== 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=NGObX4mwBrf6bm6yGpUHmkk+LTlKJLQbMaVm3fsm0qU=; b=kL6DxxPHR6a9lP6/ZRX4k5pNruJZjFOHMtgCTY87b88J5SOCnk38/6cl45Vg7IFpNR q9NjTweoBl8Cwb6JvDTaeldvZjWQ5u9ng5hZVo5sRzinwf06F2QCxpHeBxVM2ibFAXfL FqvFGIwJCE5qqLL9WyXJA2D6z5HtuvO1LgmJGlIe7iVP7zgSmTTdr6wA+eGJJsvVVAg6 l7WVx7vaG8yRlyia98y9cWCxX7oeFLmtxvuhS0i0b2cfhh9mfCz09JWDNc5p3C/Y7oOF +GVjIV5PfHs7BTFRv31lsNqDZwlYIRAC/bS03D3TvdDIUSYmaJkniOeZ0zynXeoiYp1Y NgeA== X-Gm-Message-State: AE9vXwNvQMZi1N4irIsSabE2C/pbAfLXKb7g4CFQAEP31uGoQCdDh9zmXpIBskqOBwnuPA== X-Received: by 10.55.53.3 with SMTP id c3mr3012199qka.38.1471603601352; Fri, 19 Aug 2016 03:46:41 -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 o5sm3480726qko.12.2016.08.19.03.46.40 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 19 Aug 2016 03:46:40 -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: <20160819085756.GA6759@elstar.local> Date: Fri, 19 Aug 2016 06:46:39 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <7F7EDE0F-792A-4292-9FE1-B31BC4AE40BB@gmail.com> References: <013b01d1f8ee$31fa09b0$95ee1d10$@ndzh.com> <20160818073203.GA4338@elstar.local> <04b501d1f949$116c63e0$34452ba0$@ndzh.com> <20160818121405.GA5282@elstar.local> <051301d1f950$7739c670$65ad5350$@ndzh.com> <20160818130555.GA5366@elstar.local> <051701d1f952$c4ae0b30$4e0a2190$@ndzh.com> <6BCE198E4EAEFC4CAB45D75826EFB0761525CCD7@eusaamb101.ericsson.se> <003801d1f97f$3d16eb10$b744c130$@ndzh.com> <20160819085756.GA6759@elstar.local> To: Juergen Schoenwaelder Archived-At: Cc: i2rs@ietf.org, Alissa Cooper , i2rs-chairs@ietf.org, IESG , jhaas@pfrc.org, Joel Halpern , Susan Hares , 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Aug 2016 10:46:45 -0000 Sent from my iPhone > On Aug 19, 2016, at 4:57 AM, Juergen Schoenwaelder wrote: >=20 > I repeat my technical argument: While there may be deployments where > non-secure transports may be reasonable to use, defining these > situations statically as part of data model schemas does not follow > established practices. The IETF has a long tradition of standardizing > data models that can be used in a variety of operational contexts and > I do not see reasons why we should move away from that basic approach. What I proposed just adds a trigger so operators can make that decision and c= an automate it. This isn't new for IETF protocols. I'm proposing this sinc= e it seems it was a working group decision to allow for automation. Is that= not the case? Kathleen=20 >=20 > /js >=20 >> On Thu, Aug 18, 2016 at 02:35:03PM -0400, Susan Hares wrote: >> Alissa:=20 >>=20 >> Just a little input you may not know. My background is 15 years (1995-20= 10) developing a routing/switching platform (denoted as GateD) which was so= ld to over 200 companies. We developed XML and a binary XML based product t= hat configured this product. It could do 100K configuration lines and reboo= t in less than a second on most hardware. We also provide status messages i= n secure streams and non-secure streams. I sold early version of this cod= e to companies that Alia has worked for - so she has personal viewed the co= de. At the height of our work, our development team ran to 50 people which= I directed (First as VP of Engineering, and then as CTO). It is due to this= level of experience that Alia selected me for the co-chair. Russ White ha= s understood Cisco's process, and has also directed software development tea= ms for routing.=20 >>=20 >> In order to freshen my direct experience with I2RS on open source work, I= am working on a publically available work in Quagga based on the confD prod= uct suggested by Cisco.=20 >>=20 >> In contrast, Juergen is a university professor who has worked on proto-ty= pes. He is not working on an implementation. I hope he will.=20 >>=20 >> I hope you will consider this background in my response to your comments b= elow.=20 >>=20 >> Sue=20 >>=20 >>=20 >> -----Original Message----- >> From: Alissa Cooper [mailto:alissa@cooperw.in]=20 >> Sent: Thursday, August 18, 2016 12:54 PM >> To: Joel Halpern >> Cc: Susan Hares; Juergen Schoenwaelder; i2rs@ietf.org; i2rs-chairs@ietf.o= rg; Kathleen Moriarty; IESG; jhaas@pfrc.org; draft-ietf-i2rs-protocol-securi= ty-requirements@ietf.org >> Subject: Re: [i2rs] Kathleen Moriarty's Discuss on draft-ietf-i2rs-protoc= ol-security-requirements-07: (with DISCUSS and COMMENT) >>=20 >> Jumping in here because this is relevant to my DISCUSS, hope nobody minds= (but if you do, I can go back to the other thread). >>=20 >>>> On Aug 18, 2016, at 10:30 AM, Joel Halpern w= rote: >>>>=20 >>>> Let me try a different take approach to this particular question. >>>>=20 >>>> Let me start by putting aside the question of where things are marked, a= nd come back to that afterwards. >>>>=20 >>>> There are a number of cases that I2RS has been asked to cover of high r= ate telemetry data. This may be BGP update information, it may be frequent i= nformation about line card activity. There are other cases, some of which h= ave been documented. >>>>=20 >>>> While not completely insensitive, the operators have made clear that th= ey see protecting this data as unnecessary. While I would hope over time to= move to a domain where all of it is protect, that is not trivial. As the I= 2RS Architecture points out, it is expected that what we describe as a singl= e I2RS >communication between a client and agent is actually associated with= multiple channels of communication. >>>>=20 >>>> Now, if you want to say that the I2RS protocol requirements cannot allo= w for unprotected channels, I guess we have disconnect between the IESG and t= he WG. >>>>=20 >>>> If we say that we can allow for unprotected channels, we then get to th= e question of which data can be sent over such channels. While architectura= lly I agree with Juergen that the model is a bad place to specify it, the ob= verse is also true. Not having some limits on what can be sent unprotected >= causes concern about insufficient protection. If I recall correctly, earlie= r security reviews called us to task for being too broad in what we allowed.= >>>>=20 >>>> So, if the IESG wants us to just allow it anywhere, because the model i= s an awkward place to define the limitation, I can live with that. What I c= an't live with is being told both that the model is a bad place to define it= and that there must be restrictions on what is sent unprotected,=20 >>>> without any proposal on how we are to move forward. >>=20 >>> Thank you Joel, this explanation helps me a lot. I think there is a disc= onnect about how the restrictions are expressed. =46rom reading the email tr= affic about this document, it strikes me that trying to express the restrict= ions programmatically doesn=E2=80=99t make much sense in this case.=20 >>> I agree with Juergen that it will be challenging to make a judgment a pr= iori in order to bake a restriction into a data model, because data that is c= onsidered sensitive enough to warrant a secure transport in one deployment m= ay not be considered sensitive in another deployment.=20 >>> So for any data elements where there is any question at all about whethe= r they might be sensitive (i.e., any data elements that are not already rout= inely made public),=20 >>> I would expect data model authors to end up indicating that they may be s= ent over either secure or insecure transport, which renders the indication n= ot useful. >>> Perhaps it would make more sense then to just enumerate in the text the c= ases that motivate the inclusion of protocol support for insecure transport:= >>>=20 >>> 1. For conveyance of information that is already routinely made public. >>> 2. For line card activity data where there is no likely upgrade path to s= upport secure transports in the foreseeable future. >>>=20 >>> Then the normative requirements would be on clients and agents to use se= cure transports unless those clients and agents are deployed where either of= the operational circumstances above necessitate otherwise. >>> Alissa >>=20 >> Point 1:=20 >> I disagree with Juergen on the difficulty in specifying the sections of t= he yang modules. I have provided a suggested solution in:=20 >> https://tools.ietf.org/html/draft-hares-i2rs-protocol-strawman-03#section= -4.5.2. =20 >>=20 >> Given the mount schema functionality, we can mount ephemeral state module= which augment non-ephemeral state modules which are "in-secure only". =20 >>=20 >> Point 2:=20 >> I am willing to put an enumeration of the use cases in the protocol requi= rement, but I would like to understand the purpose for the enumeration. We= are not doing a use case, but a requirements document. This information ap= pears to be a "use case" rather than a technical description. What purpose= are you looking for this enumeration to server. Are you looking for the en= umeration in SEC-REQ-08?=20 >>=20 >> Point 3: Could you review -08.txt on this topic, especially the text belo= w. Given your comments, I believe I should change the last line to a MUST.=20= >> New/ The default mode of transport is >> secure so data models MUST clearly annotate what data nodes can be >> passed over an insecure connection. >> / >>=20 >> Sue=20 >>=20 >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=20 >> As to the normative requirements (-08.txt) version:=20 >>=20 >> Section 3:=20 >>=20 >> I2RS allows the use of an insecure transport for portions of data >> models that clearly indicate the use of an insecure transport. >> Operators deploying I2RS must determine if they want to populate and >> deploy the portions of the data model which use insecure transports. >>=20 >> In Section 3.2 in version -08.txt=20 >>=20 >> SEC-REQ-08: The I2RS protocol MUST be able to transfer data over a >> secure transport and optionally MAY be able to transfer data over a >> non-secure transport. A secure transport MUST provide data >> confidentiality, data integrity, and replay prevention. >>=20 >> The default I2RS transport is a secure transport. >>=20 >> 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. >>=20 >> The configuration of ephemeral data in the I2RS Agent by the I2RS >> client SHOULD be done over a secure transport. It is anticipated >> that the passing of most I2RS ephemeral state operational status >> SHOULD be done over a secure transport. As >> [I-D.ietf-i2rs-ephemeral-state] notes, a data model MUST indicate >> whether the transport exchanging the data between I2RS client and >> I2RS agent is secure or insecure. =20 >>=20 >> The default mode of transport is >> secure so data models SHOULD clearly annotate what data nodes can be >> passed over an insecure connection. >>=20 >>>=20 >>> Yours, >>> Joel >>>=20 >>> -----Original Message----- >>> From: Susan Hares [mailto:shares@ndzh.com] >>> Sent: Thursday, August 18, 2016 9:17 AM >>> To: 'Juergen Schoenwaelder' >>> Cc: i2rs@ietf.org; i2rs-chairs@ietf.org; 'Kathleen Moriarty'=20 >>> ; 'The IESG' ;=20 >>> jhaas@pfrc.org;=20 >>> draft-ietf-i2rs-protocol-security-requirements@ietf.org >>> Subject: RE: [i2rs] Kathleen Moriarty's Discuss on=20 >>> draft-ietf-i2rs-protocol-security-requirements-07: (with DISCUSS and=20 >>> COMMENT) >>>=20 >>> Juergen and Kathleen:=20 >>>=20 >>> Let me proceed with two examples: BGP route views data model and the eve= nt for the web-service data. =20 >>>=20 >>> The content of these data models are designated as exposed to public. T= he routing system only populates the proposed BGP route views data model wit= h the data destined for the BGP looking glass. The policy on the routing sy= stem indicates what information gets transferred. The data model is complet= ely available to the public. The Yang Doctors are going to review this by s= eeing the whole model is public and available via non-secure means. >>> The security people are going to review this seeing that the whole model= is public, and available via an unprotect means. The fact the data model i= s all public should simplify the review.=20 >>>=20 >>> An event from the I2RS RIB that a web-service route is up is the second c= ase. The I2RS RIB has an event based on policy that indicates a web-service= route is up. The yang-1.1 doctors must review the content of the event tex= t to see it does not break privacy or provide too much >>> information The event mechanisms will need to work over secure transpo= rt >>> and insecure transport. Most of the data will go over the secure transp= ort event stream. However, a small amount of information may go over the ins= ecure transport stream.=20 >>>=20 >>> First, let me know if my use cases are understandable. Second, let me k= now if you disagree with this use cases.=20 >>>=20 >>> Fyi - IESG approved the architecture with the insecure stream.=20 >>>=20 >>> Sue >>>=20 >>> -----Original Message----- >>> From: Juergen Schoenwaelder=20 >>> [mailto:j.schoenwaelder@jacobs-university.de] >>> Sent: Thursday, August 18, 2016 9:06 AM >>> To: Susan Hares >>> Cc: i2rs@ietf.org; i2rs-chairs@ietf.org; 'Kathleen Moriarty'; 'The=20 >>> IESG'; jhaas@pfrc.org;=20 >>> 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) >>>=20 >>> I just do not know on which basis a data model writer can decide whether= a data object can be exposed in an unprotected way. How are YANG doctors go= ing to review this? How are security directorate people going to judge this?= But as promised, I leave (still puzzled) now. >>>=20 >>> /js >>>=20 >>>> On Thu, Aug 18, 2016 at 09:00:14AM -0400, Susan Hares wrote: >>>> Juergen:=20 >>>>=20 >>>> Yes, we seem to disagree on the value of making it hardwired in the mod= el. >>>> For me, the value is a common understanding of deployment=20 >>>> distribution >>> such >>>> as the route-views. Since the operators argued strongly for this poin= t, >>> I >>>> think the best idea is to get it working in code and then see if the=20= >>>> deployment matches the requests. >>>>=20 >>>> Sue >>>>=20 >>>> -----Original Message----- >>>> From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Juergen=20 >>>> Schoenwaelder >>>> Sent: Thursday, August 18, 2016 8:14 AM >>>> To: Susan Hares >>>> Cc: i2rs@ietf.org; i2rs-chairs@ietf.org; 'Kathleen Moriarty'; 'The=20 >>>> IESG'; jhaas@pfrc.org;=20 >>>> 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) >>>>=20 >>>> Sue, >>>>=20 >>>> I still do not see why the 'mode of exposure' of data benefits from=20 >>>> being hard-wired in the data model. For me, it is a situational and=20 >>>> deployment specific question. But I shut up here since I aired this=20 >>>> concern before (and we simply seem to disagree). >>>>=20 >>>> /js >>>>=20 >>>>> On Thu, Aug 18, 2016 at 08:07:18AM -0400, Susan Hares wrote: >>>>> Juergen:=20 >>>>>=20 >>>>> My example is the looking glass servers for the BGP route views=20 >>>>> project >>>>> (http://www.routeviews.org/) or a route indicating the presence of a >>>>> web-server that is public. For the BGP I2RS route, a yang model coul= d >>>>> replace the looking glass function, and provide events for these looki= ng >>>>> glass functions. For the web-server route, an event be sent when >>> that >>>>> one route is added. =20 >>>>>=20 >>>>> Sue >>>>>=20 >>>>>=20 >>>>> -----Original Message----- >>>>> From: Juergen Schoenwaelder >>>>> [mailto:j.schoenwaelder@jacobs-university.de] >>>>> Sent: Thursday, August 18, 2016 3:32 AM >>>>> To: Susan Hares >>>>> Cc: 'Kathleen Moriarty'; 'The IESG'; jhaas@pfrc.org; i2rs@ietf.org;=20= >>>>> i2rs-chairs@ietf.org;=20 >>>>> 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) >>>>>=20 >>>>>> On Wed, Aug 17, 2016 at 09:16:48PM -0400, Susan Hares wrote: >>>>>> ------------------------------------------------------------------ >>>>>> -- >>>>>> -- >>>>>> COMMENT: >>>>>> ------------------------------------------------------------------ >>>>>> -- >>>>>> -- >>>>>>=20 >>>>>>> Section 3:=20 >>>>>>> Can you clarify the second to last sentence? Do you mean there=20 >>>>>>> are >>>>> sections that indicate an insecure transport should be used? >>>>>>> I2RS allows the use of an >>>>>>> insecure transport for portions of data models that clearly=20 >>>>>>> indicate insecure transport. >>>>>>=20 >>>>>>> Perhaps: >>>>>>> I2RS allows the use of an >>>>>>> insecure transport for portions of data models that clearly=20 >>>>>>> indicate the use of an insecure transport. >>>>>=20 >>>>> I still wonder how a data model writer can reasonably decide whether=20= >>>>> a piece of information can be shipped safely over an insecure=20 >>>>> transport since this decision often depends on the specifics of a=20 >>>>> deployment >>>> situation. >>>>>=20 >>>>> /js >>>>>=20 >>>>> PS: I hope we do not end up with defining data multiple times (once >>>>> for insecure transport and once for secured transports). >>>>>=20 >>>>> --=20 >>>>> Juergen Schoenwaelder Jacobs University Bremen gGmbH >>>>> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany= >>>>> Fax: +49 421 200 3103 >>>>>=20 >>>>> _______________________________________________ >>>>> i2rs mailing list >>>>> i2rs@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/i2rs >>>>=20 >>>> --=20 >>>> Juergen Schoenwaelder Jacobs University Bremen gGmbH >>>> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany >>>> Fax: +49 421 200 3103 >>>>=20 >>>> _______________________________________________ >>>> i2rs mailing list >>>> i2rs@ietf.org >>>> https://www.ietf.org/mailman/listinfo/i2rs >>>=20 >>> --=20 >>> Juergen Schoenwaelder Jacobs University Bremen gGmbH >>> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany >>> Fax: +49 421 200 3103 >=20 > --=20 > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 From nobody Fri Aug 19 03:51:27 2016 Return-Path: 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 3613212D8AC; Fri, 19 Aug 2016 03:51:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.738 X-Spam-Level: * X-Spam-Status: No, score=1.738 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, RDNS_NONE=0.793] autolearn=no 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 5fVqDzkZQWlO; Fri, 19 Aug 2016 03:51:17 -0700 (PDT) Received: from hickoryhill-consulting.com (unknown [50.245.122.97]) (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 26A9D12D8A5; Fri, 19 Aug 2016 03:51:17 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=184.157.82.170; From: "Susan Hares" To: "'Juergen Schoenwaelder'" References: <013b01d1f8ee$31fa09b0$95ee1d10$@ndzh.com> <20160818073203.GA4338@elstar.local> <04b501d1f949$116c63e0$34452ba0$@ndzh.com> <20160818121405.GA5282@elstar.local> <051301d1f950$7739c670$65ad5350$@ndzh.com> <20160818130555.GA5366@elstar.local> <051701d1f952$c4ae0b30$4e0a2190$@ndzh.com> <6BCE198E4EAEFC4CAB45D75826EFB0761525CCD7@eusaamb101.ericsson.se> <003801d1f97f$3d16eb10$b744c130$@ndzh.com> <20160819085756.GA6759@elstar.local> In-Reply-To: <20160819085756.GA6759@elstar.local> Date: Fri, 19 Aug 2016 06:49:56 -0400 Message-ID: <01e501d1fa07$6d613fe0$4823bfa0$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJ/RF5y8kBC7R3sO+auWKe566R2lwEcb/3KAg+ndAACAypBUwGJSPf4Amiv8FwDJLAGjQJqExQkAqfTovACEJToAwFDCzFbnlAndzA= Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: i2rs@ietf.org, 'Alissa Cooper' , i2rs-chairs@ietf.org, 'Kathleen Moriarty' , 'IESG' , jhaas@pfrc.org, '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) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Aug 2016 10:51:20 -0000 Juergen: You have laid out the two options: a) link the data-model to the = non-secure transport, and b) do not link the data to the non-secure = transport. I agree with you that past models did not link past SNMP = MIB data model to the transport. Existing NETCONF models do not link it = to the transport. As you have indicated, you disagreed in the I2RS WG = and we found consensus was to include the non-secure transport.=20 I2RS was created to build things as an interface to the routing = environment. The operators clearly informed the I2RS group of this = need during the requirement setting phase prior to the time I was chair. = The reason I continue to press for this capability is their input, and = the existing use cases I listed previously in this mail: a) public information - BGP route views, =20 b) specific well know up events - such as public-web site up=20 c) specific network service events - interface to particular public LAN = up.=20 As you know, we do not have any I2RS data models that specify this = feature at this time. I suspect after we get through this lengthy = requirement phase, the operators may begin to specify new models that = have this feature. =20 Sue=20 -----Original Message----- From: Juergen Schoenwaelder = [mailto:j.schoenwaelder@jacobs-university.de]=20 Sent: Friday, August 19, 2016 4:58 AM To: Susan Hares Cc: 'Alissa Cooper'; 'Joel Halpern'; i2rs@ietf.org; = i2rs-chairs@ietf.org; 'Kathleen Moriarty'; 'IESG'; jhaas@pfrc.org; = 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) I repeat my technical argument: While there may be deployments where = non-secure transports may be reasonable to use, defining these = situations statically as part of data model schemas does not follow = established practices. The IETF has a long tradition of standardizing = data models that can be used in a variety of operational contexts and I = do not see reasons why we should move away from that basic approach. /js On Thu, Aug 18, 2016 at 02:35:03PM -0400, Susan Hares wrote: > Alissa:=20 >=20 > Just a little input you may not know. My background is 15 years = (1995-2010) developing a routing/switching platform (denoted as GateD) = which was sold to over 200 companies. We developed XML and a binary = XML based product that configured this product. It could do 100K = configuration lines and reboot in less than a second on most hardware. = We also provide status messages in secure streams and non-secure = streams. I sold early version of this code to companies that Alia has = worked for - so she has personal viewed the code. At the height of = our work, our development team ran to 50 people which I directed (First = as VP of Engineering, and then as CTO). It is due to this level of = experience that Alia selected me for the co-chair. Russ White has = understood Cisco's process, and has also directed software development = teams for routing.=20 >=20 > In order to freshen my direct experience with I2RS on open source = work, I am working on a publically available work in Quagga based on the = confD product suggested by Cisco.=20 >=20 > In contrast, Juergen is a university professor who has worked on = proto-types. He is not working on an implementation. I hope he will. = >=20 > I hope you will consider this background in my response to your = comments below.=20 >=20 > Sue >=20 >=20 > -----Original Message----- > From: Alissa Cooper [mailto:alissa@cooperw.in] > Sent: Thursday, August 18, 2016 12:54 PM > To: Joel Halpern > Cc: Susan Hares; Juergen Schoenwaelder; i2rs@ietf.org;=20 > i2rs-chairs@ietf.org; Kathleen Moriarty; IESG; jhaas@pfrc.org;=20 > draft-ietf-i2rs-protocol-security-requirements@ietf.org > Subject: Re: [i2rs] Kathleen Moriarty's Discuss on=20 > draft-ietf-i2rs-protocol-security-requirements-07: (with DISCUSS and=20 > COMMENT) >=20 > Jumping in here because this is relevant to my DISCUSS, hope nobody = minds (but if you do, I can go back to the other thread). >=20 > >> On Aug 18, 2016, at 10:30 AM, Joel Halpern = wrote: > >>=20 > >> Let me try a different take approach to this particular question. > >>=20 > >> Let me start by putting aside the question of where things are = marked, and come back to that afterwards. > >>=20 > >> There are a number of cases that I2RS has been asked to cover of = high rate telemetry data. This may be BGP update information, it may be = frequent information about line card activity. There are other cases, = some of which have been documented. > >>=20 > >> While not completely insensitive, the operators have made clear = that they see protecting this data as unnecessary. While I would hope = over time to move to a domain where all of it is protect, that is not = trivial. As the I2RS Architecture points out, it is expected that what = we describe as a single I2RS >communication between a client and agent = is actually associated with multiple channels of communication. > >>=20 > >> Now, if you want to say that the I2RS protocol requirements cannot = allow for unprotected channels, I guess we have disconnect between the = IESG and the WG. > >>=20 > >> If we say that we can allow for unprotected channels, we then get = to the question of which data can be sent over such channels. While = architecturally I agree with Juergen that the model is a bad place to = specify it, the obverse is also true. Not having some limits on what = can be sent unprotected >causes concern about insufficient protection. = If I recall correctly, earlier security reviews called us to task for = being too broad in what we allowed. > >>=20 > >> So, if the IESG wants us to just allow it anywhere, because the=20 > >> model is an awkward place to define the limitation, I can live with = that. What I can't live with is being told both that the model is a bad = place to define it and that there must be restrictions on what is sent = unprotected, without any proposal on how we are to move forward. >=20 > > Thank you Joel, this explanation helps me a lot. I think there is a = disconnect about how the restrictions are expressed. From reading the = email traffic about this document, it strikes me that trying to express = the restrictions programmatically doesn=E2=80=99t make much sense in = this case.=20 > > I agree with Juergen that it will be challenging to make a judgment = a priori in order to bake a restriction into a data model, because data = that is considered sensitive enough to warrant a secure transport in one = deployment may not be considered sensitive in another deployment.=20 > > So for any data elements where there is any question at all about=20 > > whether they might be sensitive (i.e., any data elements that are = not already routinely made public), I would expect data model authors to = end up indicating that they may be sent over either secure or insecure = transport, which renders the indication not useful. > > Perhaps it would make more sense then to just enumerate in the text = the cases that motivate the inclusion of protocol support for insecure = transport: > >=20 > > 1. For conveyance of information that is already routinely made = public. > > 2. For line card activity data where there is no likely upgrade path = to support secure transports in the foreseeable future. > >=20 > > Then the normative requirements would be on clients and agents to = use secure transports unless those clients and agents are deployed where = either of the operational circumstances above necessitate otherwise. > > Alissa >=20 > Point 1:=20 > I disagree with Juergen on the difficulty in specifying the sections = of the yang modules. I have provided a suggested solution in:=20 > = https://tools.ietf.org/html/draft-hares-i2rs-protocol-strawman-03#section= -4.5.2. =20 >=20 > Given the mount schema functionality, we can mount ephemeral state = module which augment non-ephemeral state modules which are "in-secure = only". =20 >=20 > Point 2:=20 > I am willing to put an enumeration of the use cases in the protocol = requirement, but I would like to understand the purpose for the = enumeration. We are not doing a use case, but a requirements document. = This information appears to be a "use case" rather than a technical = description. What purpose are you looking for this enumeration to = server. Are you looking for the enumeration in SEC-REQ-08?=20 >=20 > Point 3: Could you review -08.txt on this topic, especially the text = below. Given your comments, I believe I should change the last line to = a MUST.=20 > New/ The default mode of transport is > secure so data models MUST clearly annotate what data nodes can be > passed over an insecure connection. > / >=20 > Sue >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > As to the normative requirements (-08.txt) version:=20 >=20 > Section 3:=20 > =20 > I2RS allows the use of an insecure transport for portions of data > models that clearly indicate the use of an insecure transport. > Operators deploying I2RS must determine if they want to populate = and > deploy the portions of the data model which use insecure = transports. >=20 > In Section 3.2 in version -08.txt >=20 > SEC-REQ-08: The I2RS protocol MUST be able to transfer data over a > secure transport and optionally MAY be able to transfer data over a > non-secure transport. A secure transport MUST provide data > confidentiality, data integrity, and replay prevention. >=20 > The default I2RS transport is a secure transport. >=20 > 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. >=20 > The configuration of ephemeral data in the I2RS Agent by the I2RS > client SHOULD be done over a secure transport. It is anticipated > that the passing of most I2RS ephemeral state operational status > SHOULD be done over a secure transport. As > [I-D.ietf-i2rs-ephemeral-state] notes, a data model MUST indicate > whether the transport exchanging the data between I2RS client and > I2RS agent is secure or insecure. =20 >=20 > The default mode of transport is > secure so data models SHOULD clearly annotate what data nodes can = be > passed over an insecure connection. >=20 > >=20 > > Yours, > > Joel > >=20 > > -----Original Message----- > > From: Susan Hares [mailto:shares@ndzh.com] > > Sent: Thursday, August 18, 2016 9:17 AM > > To: 'Juergen Schoenwaelder' > > Cc: i2rs@ietf.org; i2rs-chairs@ietf.org; 'Kathleen Moriarty'=20 > > ; 'The IESG' ;=20 > > jhaas@pfrc.org;=20 > > 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) > >=20 > > Juergen and Kathleen:=20 > >=20 > > Let me proceed with two examples: BGP route views data model and the = event for the web-service data. =20 > >=20 > > The content of these data models are designated as exposed to = public. The routing system only populates the proposed BGP route views = data model with the data destined for the BGP looking glass. The policy = on the routing system indicates what information gets transferred. The = data model is completely available to the public. The Yang Doctors are = going to review this by seeing the whole model is public and available = via non-secure means. > > The security people are going to review this seeing that the whole = model is public, and available via an unprotect means. The fact the = data model is all public should simplify the review.=20 > >=20 > > An event from the I2RS RIB that a web-service route is up is the = second case. The I2RS RIB has an event based on policy that indicates a = web-service route is up. The yang-1.1 doctors must review the content = of the event text to see it does not break privacy or provide too much > > information The event mechanisms will need to work over secure = transport > > and insecure transport. Most of the data will go over the secure = transport event stream. However, a small amount of information may go = over the insecure transport stream.=20 > >=20 > > First, let me know if my use cases are understandable. Second, let = me know if you disagree with this use cases.=20 > >=20 > > Fyi - IESG approved the architecture with the insecure stream.=20 > >=20 > > Sue > >=20 > > -----Original Message----- > > From: Juergen Schoenwaelder > > [mailto:j.schoenwaelder@jacobs-university.de] > > Sent: Thursday, August 18, 2016 9:06 AM > > To: Susan Hares > > Cc: i2rs@ietf.org; i2rs-chairs@ietf.org; 'Kathleen Moriarty'; 'The=20 > > IESG'; jhaas@pfrc.org;=20 > > 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) > >=20 > > I just do not know on which basis a data model writer can decide = whether a data object can be exposed in an unprotected way. How are YANG = doctors going to review this? How are security directorate people going = to judge this? But as promised, I leave (still puzzled) now. > >=20 > > /js > >=20 > > On Thu, Aug 18, 2016 at 09:00:14AM -0400, Susan Hares wrote: > >> Juergen:=20 > >>=20 > >> Yes, we seem to disagree on the value of making it hardwired in the = model. > >> For me, the value is a common understanding of deployment=20 > >> distribution > > such > >> as the route-views. Since the operators argued strongly for this = point, > > I > >> think the best idea is to get it working in code and then see if=20 > >> the deployment matches the requests. > >>=20 > >> Sue > >>=20 > >> -----Original Message----- > >> From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Juergen=20 > >> Schoenwaelder > >> Sent: Thursday, August 18, 2016 8:14 AM > >> To: Susan Hares > >> Cc: i2rs@ietf.org; i2rs-chairs@ietf.org; 'Kathleen Moriarty'; 'The=20 > >> IESG'; jhaas@pfrc.org;=20 > >> 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=20 > >> and > >> COMMENT) > >>=20 > >> Sue, > >>=20 > >> I still do not see why the 'mode of exposure' of data benefits from = > >> being hard-wired in the data model. For me, it is a situational and = > >> deployment specific question. But I shut up here since I aired this = > >> concern before (and we simply seem to disagree). > >>=20 > >> /js > >>=20 > >> On Thu, Aug 18, 2016 at 08:07:18AM -0400, Susan Hares wrote: > >>> Juergen:=20 > >>>=20 > >>> My example is the looking glass servers for the BGP route views=20 > >>> project > >>> (http://www.routeviews.org/) or a route indicating the presence of = a > >>> web-server that is public. For the BGP I2RS route, a yang model = could > >>> replace the looking glass function, and provide events for these = looking > >>> glass functions. For the web-server route, an event be sent = when > > that > >>> one route is added. =20 > >>>=20 > >>> Sue > >>>=20 > >>>=20 > >>> -----Original Message----- > >>> From: Juergen Schoenwaelder > >>> [mailto:j.schoenwaelder@jacobs-university.de] > >>> Sent: Thursday, August 18, 2016 3:32 AM > >>> To: Susan Hares > >>> Cc: 'Kathleen Moriarty'; 'The IESG'; jhaas@pfrc.org;=20 > >>> i2rs@ietf.org; i2rs-chairs@ietf.org;=20 > >>> 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=20 > >>> and > >>> COMMENT) > >>>=20 > >>> On Wed, Aug 17, 2016 at 09:16:48PM -0400, Susan Hares wrote: > >>>> ----------------------------------------------------------------- > >>>> - > >>>> -- > >>>> -- > >>>> COMMENT: > >>>> ----------------------------------------------------------------- > >>>> - > >>>> -- > >>>> -- > >>>>=20 > >>>>> Section 3:=20 > >>>>> Can you clarify the second to last sentence? Do you mean there=20 > >>>>> are > >>> sections that indicate an insecure transport should be used? > >>>>> I2RS allows the use of an > >>>>> insecure transport for portions of data models that clearly=20 > >>>>> indicate insecure transport. > >>>>=20 > >>>>> Perhaps: > >>>>> I2RS allows the use of an > >>>>> insecure transport for portions of data models that clearly=20 > >>>>> indicate the use of an insecure transport. > >>>=20 > >>> I still wonder how a data model writer can reasonably decide=20 > >>> whether a piece of information can be shipped safely over an=20 > >>> insecure transport since this decision often depends on the=20 > >>> specifics of a deployment > >> situation. > >>>=20 > >>> /js > >>>=20 > >>> PS: I hope we do not end up with defining data multiple times = (once > >>> for insecure transport and once for secured transports). > >>>=20 > >>> --=20 > >>> Juergen Schoenwaelder Jacobs University Bremen gGmbH > >>> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | = Germany > >>> Fax: +49 421 200 3103 > >>>=20 > >>> _______________________________________________ > >>> i2rs mailing list > >>> i2rs@ietf.org > >>> https://www.ietf.org/mailman/listinfo/i2rs > >>=20 > >> --=20 > >> Juergen Schoenwaelder Jacobs University Bremen gGmbH > >> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | = Germany > >> Fax: +49 421 200 3103 > >>=20 > >> _______________________________________________ > >> i2rs mailing list > >> i2rs@ietf.org > >> https://www.ietf.org/mailman/listinfo/i2rs > >>=20 > >=20 > > --=20 > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | = Germany > > Fax: +49 421 200 3103 > >=20 >=20 >=20 --=20 Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Fri Aug 19 04:02:28 2016 Return-Path: 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 E2C5812DB90 for ; Thu, 18 Aug 2016 13:57:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=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=yumaworks-com.20150623.gappssmtp.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 KiGbQeec7c62 for ; Thu, 18 Aug 2016 13:57:38 -0700 (PDT) Received: from mail-ua0-x22b.google.com (mail-ua0-x22b.google.com [IPv6:2607:f8b0:400c:c08::22b]) (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 1336012DB80 for ; Thu, 18 Aug 2016 13:57:38 -0700 (PDT) Received: by mail-ua0-x22b.google.com with SMTP id 74so48759700uau.0 for ; Thu, 18 Aug 2016 13:57:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=5fM2V/twdBn/Z75ooMcxOhzNDx0264tHFJMbyFM+QJk=; b=OIiEc9I7RGO4eBN9w/x9lqAm0ffqd60iaDOOnGEXGkMjXn5MVSb+njh2Quc+ID3TqR 82765SrD1OCQDyiSNw/h9xQ4hfASndLvxVZJZ/HLKKXIybNlJSU88/Ybg3BkEaMlkpFK m4IMDwHxvTs0pjjE6l608jxGtBmPQnkWXyt+7OEKKh5FI6My+vIqBoQDFmgSZHIhOwfG B8EwFZuavfk+x/7e9CHp6ZoIC4iDxMLghSveTDXNN3IPP5q2Ia175/z59skc/JlfMFaE +FOMuHOWWmxodWkth0XkvAPs2gvaxga3hqMndZert5idkZIoL/f6w37H4Dd8A5gCB4qY LuFQ== 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; bh=5fM2V/twdBn/Z75ooMcxOhzNDx0264tHFJMbyFM+QJk=; b=aBMBL/Ic80UTrIndRM8IuLxg30dMC/bCBwsmgnYOv2I/4NFsTzk+UtjKbvC21uI7NB rgToDDzdoa8PorVFHsORtoH3+AvM5jlkud7pdjgkPEPAdJzf988U8S4kMwZW6oUNYZ9a 2NjG+jzBRC7XksXhRE2OYJvxE0Y1+Mei8zTldRmEzpUUoAHJxcxGC1bBq7Uq5d5Bxbsr CvNFpGLcwdLVp+Au+K5ZRlFEXtSTN8pJmMmjB3gtlTltL5YwORs8+b0XQ42XXD4CvcJR JDBe7Y3OktZW3czOYQc8SvHBvaACNN2RIRkgLbXUivbKWu3bFBduinro3Yid7UCY4qpt K0Cg== X-Gm-Message-State: AEkoouv2p8uh7C49f5d3g33TnTmD8A3S+Z1L9oje32Lh+6zxkTrfQZlBlRiJQ02UxB28F1e6nSGOCjSDyYOpWw== X-Received: by 10.159.40.167 with SMTP id d36mr2211173uad.55.1471553857044; Thu, 18 Aug 2016 13:57:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.4.198 with HTTP; Thu, 18 Aug 2016 13:57:36 -0700 (PDT) In-Reply-To: <012e01d1f98b$ec9d09a0$c5d71ce0$@ndzh.com> References: <147146974235.23784.4389421535496134619.idtracker@ietfa.amsl.com> <013b01d1f8ee$31fa09b0$95ee1d10$@ndzh.com> <20160818073203.GA4338@elstar.local> <04b501d1f949$116c63e0$34452ba0$@ndzh.com> <20160818121405.GA5282@elstar.local> <051301d1f950$7739c670$65ad5350$@ndzh.com> <20160818130555.GA5366@elstar.local> <051701d1f952$c4ae0b30$4e0a2190$@ndzh.com> <6BCE198E4EAEFC4CAB45D75826EFB0761525CCD7@eusaamb101.ericsson.se> <003801d1f97f$3d16eb10$b744c130$@ndzh.com> <00dc01d1f988$f2cec280$d86c4780$@ndzh.com> <012e01d1f98b$ec9d09a0$c5d71ce0$@ndzh.com> From: Andy Bierman Date: Thu, 18 Aug 2016 13:57:36 -0700 Message-ID: To: Susan Hares Content-Type: multipart/alternative; boundary=94eb2c123794ead881053a5ed459 Archived-At: X-Mailman-Approved-At: Fri, 19 Aug 2016 04:02:25 -0700 Cc: "i2rs@ietf.org" , Alissa Cooper , Juergen Schoenwaelder , 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) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Aug 2016 20:57:43 -0000 --94eb2c123794ead881053a5ed459 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, I guess we disagree on how easy it will be for the IETF to decide all instances of certain objects can be read using nonsecure protocols. This seems like a log of effort for something the operator should be deciding anyway. Andy On Thu, Aug 18, 2016 at 1:05 PM, Susan Hares wrote: > Andy: > > > > If we create a yang data model that is insecure, and mount on another dat= a > model =E2=80=93 does it have the same issue as module augmentation? Of = course, we > could create a mount point for all insecure data modules, and all data > placed under that mount point =E2=80=93 would be insecure. > > > > For the BGP route-views use case, this would make it clear that data had > to be transformed to be insecure transmission. > > > > Sue > > > > *From:* Andy Bierman [mailto:andy@yumaworks.com] > *Sent:* Thursday, August 18, 2016 4:02 PM > *To:* Susan Hares > *Cc:* Alissa Cooper; Joel Halpern; i2rs@ietf.org; Juergen Schoenwaelder; > i2rs-chairs@ietf.org; Kathleen Moriarty; IESG; Jeffrey Haas; > 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 Thu, Aug 18, 2016 at 12:44 PM, Susan Hares wrote: > > Andy: > > > > Thank you =E2=80=93 I thought it was on whether we could implement insecu= re > transport in a Yang module. > > > > The requirement text you are working with is: > > > > SEC-REQ-08: The I2RS protocol MUST be able to transfer data over a > secure transport and optionally MAY be able to transfer data over a > non-secure transport. > > > > I do not understand why approving the ok for non-secure transport for som= e > modules means the following to you: > > > > *=E2=80=9C the IETF needs to agree that there could never possibly be any > deployment that would not want to allow exposure of the data.* > > *Not now. Not 20 years from now.=E2=80=9D* > > > > > > > > As I understand it, this requirement has another requirement associated > with it > > that says the data has to be identified as OK-for-nonsecure-transport. > > > > An extension in the data model says that all instances of the object in > > all possible deployments cannot be considered sensistive and therefore > > needs disclosure protection. > > > > It may seem like even a simple octet counter is safe to send in the clear= , > > but not if that opens up correlation attacks. (e.g., I can send data to > some > > host. I can see that index 455992 is incrementing the in-octets counters > > in a way that strongly correlates to my test traffic. Therefore I can > learn > > that arbitrary index 455992 is really John Doe or really suite #14, etc. > > > > > > I had thought that the security-directorate and other reviewers would loo= k > at each module that is insecure, and consider whether it was reasonable > for the use case at this time. This is what I understood from Russ > Housley=E2=80=99s first review of this technology. Since like you, I bel= ieve the > operator is going to configure what modules are allowed on systems. I > agree that this requirement provides a full scope of the work, but > implementers will require network operators to configure these features o= n. > > > > Sue > > > > Andy > > > > > > > > *From:* Andy Bierman [mailto:andy@yumaworks.com] > *Sent:* Thursday, August 18, 2016 2:53 PM > *To:* Susan Hares > *Cc:* Alissa Cooper; Joel Halpern; i2rs@ietf.org; Juergen Schoenwaelder; > i2rs-chairs@ietf.org; Kathleen Moriarty; IESG; Jeffrey Haas; > 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) > > > > Hi, > > > > I did not think Juergen's comment was about running code. > > > > In order for a data node to get the "ok-for-nonsecure-transports" approva= l > > in an IETF module, the IETF needs to agree that there could never possibl= y > be > > any deployment that would not want to allow exposure of the data. > > Not now. Not 20 years from now. > > > > I can see a vendor making that decision for their own proprietary modules= , > > but it seems less likely for standard modules. > > > > Seems like the operator is going to have to configure what is allowed > > for nonsecure transport anyway, so just let them decide. > > I don't really object to the extension or the requirement. > > It doesn't help much but it doesn't hurt much either. > > > > > > Andy > > > > > > > > On Thu, Aug 18, 2016 at 11:35 AM, Susan Hares wrote: > > Alissa: > > Just a little input you may not know. My background is 15 years > (1995-2010) developing a routing/switching platform (denoted as GateD) > which was sold to over 200 companies. We developed XML and a binary XML > based product that configured this product. It could do 100K configurati= on > lines and reboot in less than a second on most hardware. We also provide > status messages in secure streams and non-secure streams. I sold early > version of this code to companies that Alia has worked for - so she has > personal viewed the code. At the height of our work, our development te= am > ran to 50 people which I directed (First as VP of Engineering, and then a= s > CTO). It is due to this level of experience that Alia selected me for the > co-chair. Russ White has understood Cisco's process, and has also > directed software development teams for routing. > > In order to freshen my direct experience with I2RS on open source work, I > am working on a publically available work in Quagga based on the confD > product suggested by Cisco. > > In contrast, Juergen is a university professor who has worked on > proto-types. He is not working on an implementation. I hope he will. > > I hope you will consider this background in my response to your comments > below. > > Sue > > > -----Original Message----- > From: Alissa Cooper [mailto:alissa@cooperw.in] > Sent: Thursday, August 18, 2016 12:54 PM > To: Joel Halpern > Cc: Susan Hares; Juergen Schoenwaelder; i2rs@ietf.org; > i2rs-chairs@ietf.org; Kathleen Moriarty; IESG; jhaas@pfrc.org; > 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) > > Jumping in here because this is relevant to my DISCUSS, hope nobody minds > (but if you do, I can go back to the other thread). > > >> On Aug 18, 2016, at 10:30 AM, Joel Halpern > wrote: > >> > >> Let me try a different take approach to this particular question. > >> > >> Let me start by putting aside the question of where things are marked, > and come back to that afterwards. > >> > >> There are a number of cases that I2RS has been asked to cover of high > rate telemetry data. This may be BGP update information, it may be > frequent information about line card activity. There are other cases, so= me > of which have been documented. > >> > >> While not completely insensitive, the operators have made clear that > they see protecting this data as unnecessary. While I would hope over ti= me > to move to a domain where all of it is protect, that is not trivial. As > the I2RS Architecture points out, it is expected that what we describe as= a > single I2RS >communication between a client and agent is actually > associated with multiple channels of communication. > >> > >> Now, if you want to say that the I2RS protocol requirements cannot > allow for unprotected channels, I guess we have disconnect between the IE= SG > and the WG. > >> > >> If we say that we can allow for unprotected channels, we then get to > the question of which data can be sent over such channels. While > architecturally I agree with Juergen that the model is a bad place to > specify it, the obverse is also true. Not having some limits on what can > be sent unprotected >causes concern about insufficient protection. If I > recall correctly, earlier security reviews called us to task for being to= o > broad in what we allowed. > >> > >> So, if the IESG wants us to just allow it anywhere, because the model > is an awkward place to define the limitation, I can live with that. What= I > can't live with is being told both that the model is a bad place to defin= e > it and that there must be restrictions on what is sent unprotected, > >> without any proposal on how we are to move forward. > > > Thank you Joel, this explanation helps me a lot. I think there is a > disconnect about how the restrictions are expressed. From reading the ema= il > traffic about this document, it strikes me that trying to express the > restrictions programmatically doesn=E2=80=99t make much sense in this cas= e. > > I agree with Juergen that it will be challenging to make a judgment a > priori in order to bake a restriction into a data model, because data tha= t > is considered sensitive enough to warrant a secure transport in one > deployment may not be considered sensitive in another deployment. > > So for any data elements where there is any question at all about > whether they might be sensitive (i.e., any data elements that are not > already routinely made public), > > I would expect data model authors to end up indicating that they may be > sent over either secure or insecure transport, which renders the indicati= on > not useful. > > Perhaps it would make more sense then to just enumerate in the text the > cases that motivate the inclusion of protocol support for insecure > transport: > > > > 1. For conveyance of information that is already routinely made public. > > 2. For line card activity data where there is no likely upgrade path to > support secure transports in the foreseeable future. > > > > Then the normative requirements would be on clients and agents to use > secure transports unless those clients and agents are deployed where eith= er > of the operational circumstances above necessitate otherwise. > > Alissa > > Point 1: > I disagree with Juergen on the difficulty in specifying the sections of > the yang modules. I have provided a suggested solution in: > https://tools.ietf.org/html/draft-hares-i2rs-protocol- > strawman-03#section-4.5.2. > > Given the mount schema functionality, we can mount ephemeral state module > which augment non-ephemeral state modules which are "in-secure only". > > Point 2: > I am willing to put an enumeration of the use cases in the protocol > requirement, but I would like to understand the purpose for the > enumeration. We are not doing a use case, but a requirements document. > This information appears to be a "use case" rather than a technical > description. What purpose are you looking for this enumeration to > server. Are you looking for the enumeration in SEC-REQ-08? > > Point 3: Could you review -08.txt on this topic, especially the text > below. Given your comments, I believe I should change the last line to a > MUST. > New/ The default mode of transport is > secure so data models MUST clearly annotate what data nodes can be > passed over an insecure connection. > / > > Sue > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > As to the normative requirements (-08.txt) version: > > Section 3: > > I2RS allows the use of an insecure transport for portions of data > models that clearly indicate the use of an insecure transport. > Operators deploying I2RS must determine if they want to populate and > deploy the portions of the data model which use insecure transports. > > In Section 3.2 in version -08.txt > > SEC-REQ-08: The I2RS protocol MUST be able to transfer data over a > secure transport and optionally MAY be able to transfer data over a > non-secure transport. A secure transport MUST provide data > confidentiality, data integrity, and replay prevention. > > The default I2RS transport is a secure transport. > > 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. > > The configuration of ephemeral data in the I2RS Agent by the I2RS > client SHOULD be done over a secure transport. It is anticipated > that the passing of most I2RS ephemeral state operational status > SHOULD be done over a secure transport. As > [I-D.ietf-i2rs-ephemeral-state] notes, a data model MUST indicate > whether the transport exchanging the data between I2RS client and > I2RS agent is secure or insecure. > > The default mode of transport is > secure so data models SHOULD clearly annotate what data nodes can be > passed over an insecure connection. > > > > > Yours, > > Joel > > > > -----Original Message----- > > From: Susan Hares [mailto:shares@ndzh.com] > > Sent: Thursday, August 18, 2016 9:17 AM > > To: 'Juergen Schoenwaelder' > > Cc: i2rs@ietf.org; i2rs-chairs@ietf.org; 'Kathleen Moriarty' > > ; 'The IESG' ; > > jhaas@pfrc.org; > > 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) > > > > Juergen and Kathleen: > > > > Let me proceed with two examples: BGP route views data model and the > event for the web-service data. > > > > The content of these data models are designated as exposed to public. > The routing system only populates the proposed BGP route views data model > with the data destined for the BGP looking glass. The policy on the > routing system indicates what information gets transferred. The data mod= el > is completely available to the public. The Yang Doctors are going to > review this by seeing the whole model is public and available via > non-secure means. > > The security people are going to review this seeing that the whole mode= l > is public, and available via an unprotect means. The fact the data model > is all public should simplify the review. > > > > An event from the I2RS RIB that a web-service route is up is the second > case. The I2RS RIB has an event based on policy that indicates a > web-service route is up. The yang-1.1 doctors must review the content of > the event text to see it does not break privacy or provide too much > > information The event mechanisms will need to work over secure > transport > > and insecure transport. Most of the data will go over the secure > transport event stream. However, a small amount of information may go ove= r > the insecure transport stream. > > > > First, let me know if my use cases are understandable. Second, let me > know if you disagree with this use cases. > > > > Fyi - IESG approved the architecture with the insecure stream. > > > > Sue > > > > -----Original Message----- > > From: Juergen Schoenwaelder > > [mailto:j.schoenwaelder@jacobs-university.de] > > Sent: Thursday, August 18, 2016 9:06 AM > > To: Susan Hares > > Cc: i2rs@ietf.org; i2rs-chairs@ietf.org; 'Kathleen Moriarty'; 'The > > IESG'; jhaas@pfrc.org; > > 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) > > > > I just do not know on which basis a data model writer can decide whethe= r > a data object can be exposed in an unprotected way. How are YANG doctors > going to review this? How are security directorate people going to judge > this? But as promised, I leave (still puzzled) now. > > > > /js > > > > On Thu, Aug 18, 2016 at 09:00:14AM -0400, Susan Hares wrote: > >> Juergen: > >> > >> Yes, we seem to disagree on the value of making it hardwired in the > model. > >> For me, the value is a common understanding of deployment > >> distribution > > such > >> as the route-views. Since the operators argued strongly for this > point, > > I > >> think the best idea is to get it working in code and then see if the > >> deployment matches the requests. > >> > >> Sue > >> > >> -----Original Message----- > >> From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Juergen > >> Schoenwaelder > >> Sent: Thursday, August 18, 2016 8:14 AM > >> To: Susan Hares > >> Cc: i2rs@ietf.org; i2rs-chairs@ietf.org; 'Kathleen Moriarty'; 'The > >> IESG'; jhaas@pfrc.org; > >> 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) > >> > >> Sue, > >> > >> I still do not see why the 'mode of exposure' of data benefits from > >> being hard-wired in the data model. For me, it is a situational and > >> deployment specific question. But I shut up here since I aired this > >> concern before (and we simply seem to disagree). > >> > >> /js > >> > >> On Thu, Aug 18, 2016 at 08:07:18AM -0400, Susan Hares wrote: > >>> Juergen: > >>> > >>> My example is the looking glass servers for the BGP route views > >>> project > >>> (http://www.routeviews.org/) or a route indicating the presence of a > >>> web-server that is public. For the BGP I2RS route, a yang model cou= ld > >>> replace the looking glass function, and provide events for these > looking > >>> glass functions. For the web-server route, an event be sent when > > that > >>> one route is added. > >>> > >>> Sue > >>> > >>> > >>> -----Original Message----- > >>> From: Juergen Schoenwaelder > >>> [mailto:j.schoenwaelder@jacobs-university.de] > >>> Sent: Thursday, August 18, 2016 3:32 AM > >>> To: Susan Hares > >>> Cc: 'Kathleen Moriarty'; 'The IESG'; jhaas@pfrc.org; i2rs@ietf.org; > >>> i2rs-chairs@ietf.org; > >>> 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 Wed, Aug 17, 2016 at 09:16:48PM -0400, Susan Hares wrote: > >>>> ------------------------------------------------------------------ > >>>> -- > >>>> -- > >>>> COMMENT: > >>>> ------------------------------------------------------------------ > >>>> -- > >>>> -- > >>>> > >>>>> Section 3: > >>>>> Can you clarify the second to last sentence? Do you mean there > >>>>> are > >>> sections that indicate an insecure transport should be used? > >>>>> I2RS allows the use of an > >>>>> insecure transport for portions of data models that clearly > >>>>> indicate insecure transport. > >>>> > >>>>> Perhaps: > >>>>> I2RS allows the use of an > >>>>> insecure transport for portions of data models that clearly > >>>>> indicate the use of an insecure transport. > >>> > >>> I still wonder how a data model writer can reasonably decide whether > >>> a piece of information can be shipped safely over an insecure > >>> transport since this decision often depends on the specifics of a > >>> deployment > >> situation. > >>> > >>> /js > >>> > >>> PS: I hope we do not end up with defining data multiple times (once > >>> for insecure transport and once for secured transports). > >>> > >>> -- > >>> Juergen Schoenwaelder Jacobs University Bremen gGmbH > >>> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | German= y > >>> Fax: +49 421 200 3103 > >>> > >>> _______________________________________________ > >>> i2rs mailing list > >>> i2rs@ietf.org > >>> https://www.ietf.org/mailman/listinfo/i2rs > >> > >> -- > >> Juergen Schoenwaelder Jacobs University Bremen gGmbH > >> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > >> Fax: +49 421 200 3103 > >> > >> _______________________________________________ > >> i2rs mailing list > >> i2rs@ietf.org > >> https://www.ietf.org/mailman/listinfo/i2rs > >> > > > > -- > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > > Fax: +49 421 200 3103 > > > > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs > > > > > --94eb2c123794ead881053a5ed459 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

I guess we disagree on how easy it = will be for the IETF to
decide all instances of certain objects c= an be read using
nonsecure protocols.=C2=A0 This seems like a log= of effort for
something the operator should be deciding anyway.<= /div>


Andy


<= /div>


On Thu, Aug 18, 2016 at 1:05 PM, Susan Hares <= ;shares@ndzh.com&g= t; wrote:

Andy:

=C2=A0

If we create a yang data model that is insecure, and mou= nt on another data model =E2=80=93 does it have the same issue as module au= gmentation?=C2=A0 =C2=A0Of course, we could create a mount point for all in= secure data modules, and all data placed under that mount point =E2=80=93 w= ould be insecure.=C2=A0

=C2=A0

For the BGP route-views use case, this would = make it clear that data had to be transformed to be insecure transmission.= =C2=A0=C2=A0

=C2=A0

Sue

=C2=A0

From: Andy Bierman [mailto:andy@yumaworks.com] Sent: Thursday, August 18, 2016 4:02 PM
To: Susan Hares<= br>Cc: Alissa Cooper; Joel Halpern; i2rs@ietf.org; Juergen Schoenwaelder; i2rs-chairs@ietf.org; Kathl= een Moriarty; IESG; Jeffrey Haas; draft-ietf-i2rs-protoco= l-security-requirements@ietf.org
Subject: Re: [i2rs] Kat= hleen Moriarty's Discuss on draft-ietf-i2rs-protocol-security-requ= irements-07: (with DISCUSS and COMMENT)

=C2=A0

=C2= =A0

=C2=A0

On Thu, Aug 18, 2016 at 12:44 PM, Susan Hares <shares@ndzh.com> wrot= e:

Andy:

=C2=A0

Thank you =E2=80=93 I thou= ght it was on whether we could implement insecure transport in a Yang modul= e.

=C2=A0

The requirement tex= t you are working with is:

<= span style=3D"font-size:11.0pt;font-family:"Calibri","sans-s= erif"">=C2=A0

=C2=A0 = =C2=A0SEC-REQ-08: The I2RS protocol MUST be able to transfer data over a=C2=A0 =C2=A0secure transport and optionally MAY be able to transfer data = over a
=C2=A0 =C2=A0non-secure transport.

=C2=A0

I do not understand why approving the ok for non-secure tran= sport for some modules means the following to you:

=C2=A0<= /u>

=E2=80=9C the IETF = needs to agree that there could never possibly be any deployment that would= not want to allow exposure of the data.

Not now. Not 20 years from now.= =E2=80=9D

= =C2=A0

<= /u>=C2=A0

=C2=A0<= /p>

As I understand it, this requirement h= as another requirement associated with it

that says the data has to be identified as OK-for-nonsecu= re-transport.

=C2= =A0

An extension in the data mo= del says that all instances of the object in

all possible deployments cannot be considered sensisti= ve and therefore

needs d= isclosure protection.

=C2=A0

It may seem like ev= en a simple octet counter is safe to send in the clear,

but not if that opens up correlation attack= s. =C2=A0(e.g., I can send data to some

host.=C2=A0 I can see that index 455992 is incrementing the= in-octets counters

in a= way that strongly correlates to my test traffic.=C2=A0 Therefore I can lea= rn

that arbitrary index = 455992 is really John Doe or really suite #14, etc.

=

=C2=A0

=C2=A0

I had thoug= ht that the security-directorate and other reviewers would look at each mod= ule that is insecure, and =C2=A0consider whether it was reasonable for the = use case at this time.=C2=A0 =C2=A0This is what I understood from Russ Hous= ley=E2=80=99s first review of this technology.=C2=A0 Since like you, I beli= eve the operator is going to =C2=A0configure what modules are allowed on sy= stems.=C2=A0 =C2=A0I agree that this requirement provides a full scope of t= he work, but implementers will require network operators to configure these= features on.

=C2=A0

Sue

= =C2=A0

Andy

=C2=A0

=C2=A0

=C2=A0

From: Andy Bierman [m= ailto:andy@yumawork= s.com]
Sent: Thursday, August 18, 2016 2:53 PM
To:= Susan Hares
Cc: Alissa Cooper; Joel Halpern; i2rs@ietf.org; Juergen Schoenwaelder; <= a href=3D"mailto:i2rs-chairs@ietf.org" target=3D"_blank">i2rs-chairs@ietf.o= rg; Kathleen Moriarty; IESG; Jeffrey Haas; draft-ietf= -i2rs-protocol-security-requirements@ietf.org
Subject: R= e: [i2rs] Kathleen Moriarty's Discuss on draft-ietf-i2rs-protocol-= security-requirements-07: (with DISCUSS and COMMENT)

=C2=A0

Hi,

=C2=A0

=

I did not think Juergen's comment was= about running code.

=C2= =A0

In order for a data = node to get the "ok-for-nonsecure-transports" approval<= /u>

in an IETF module, the IETF needs = to agree that there could never possibly be

any deployment that would not want to allow exposure of= the data.

Not now. Not = 20 years from now.

=C2= =A0

I can see a vendor m= aking that decision for their own proprietary modules,

but it seems less likely for standard module= s.

=C2=A0<= /p>

Seems like the operator is going to ha= ve to configure what is allowed

for nonsecure transport anyway, so just let them decide.<= /u>

I don't really object to the e= xtension or the requirement.

It doesn't help much but it doesn't hurt much either.

=C2=A0

=C2=A0

Andy

=C2=A0<= /u>

=C2=A0

=C2=A0

On Thu, Aug 18, 2016 at 11:35 AM, Susan Hares <shares@ndzh.com> wrote:

Alissa:

Just a little input y= ou may not know.=C2=A0 My background is 15 years (1995-2010)=C2=A0 developi= ng a routing/switching platform (denoted as GateD) which was sold to over 2= 00 companies.=C2=A0 =C2=A0We developed XML and a binary XML based product t= hat configured this product.=C2=A0 It could do 100K configuration lines and= reboot in less than a second on most hardware.=C2=A0 We also provide statu= s messages in secure streams and non-secure streams.=C2=A0 =C2=A0 I sold ea= rly version of this code to companies that Alia has worked for=C2=A0 - so s= he has personal viewed the code.=C2=A0 =C2=A0At the height of our work, our= development team ran to 50 people which I directed (First as VP of Enginee= ring, and then as CTO). It is due to this level of experience that Alia sel= ected me for the co-chair.=C2=A0 =C2=A0Russ White has understood Cisco'= s process, and has also directed software development teams for routing.
In order to freshen my direct experience with I2RS on open source work= , I am working on a publically available work in Quagga based on the confD = product suggested by Cisco.

In contrast, Juergen is a university pro= fessor who has worked on proto-types.=C2=A0 =C2=A0He is not working on an i= mplementation.=C2=A0 =C2=A0I hope he will.

I hope you will consider = this background in my response to your comments below.

Sue

-----Original Message-----
From: Alissa Cooper [mailto:alissa@cooperw.in]
Sent: Thu= rsday, August 18, 2016 12:54 PM
To: Joel Halpern
Cc: Susan Hares; Jue= rgen Schoenwaelder; i2rs= @ietf.org; i2= rs-chairs@ietf.org; Kathleen Moriarty; IESG; jhaas@pfrc.org; 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)

Jumping in here because= this is relevant to my DISCUSS, hope nobody minds (but if you do, I can go= back to the other thread).

>> On Aug 18, 2016, at 10:30 AM, J= oel Halpern <joel.halpern@ericsson.com> wrote:
>>
>> Let me= try a different take approach to this particular question.
>>
= >> Let me start by putting aside the question of where things are mar= ked, and come back to that afterwards.
>>
>> There are a = number of cases that I2RS has been asked to cover of high rate telemetry da= ta.=C2=A0 This may be BGP update information, it may be frequent informatio= n about line card activity.=C2=A0 There are other cases, some of which have= been documented.
>>
>> While not completely insensitive,= the operators have made clear that they see protecting this data as unnece= ssary.=C2=A0 While I would hope over time to move to a domain where all of = it is protect, that is not trivial.=C2=A0 As the I2RS Architecture points o= ut, it is expected that what we describe as a single I2RS >communication= between a client and agent is actually associated with multiple channels o= f communication.
>>
>> Now, if you want to say that the I= 2RS protocol requirements cannot allow for unprotected channels, I guess we= have disconnect between the IESG and the WG.
>>
>> If we= say that we can allow for unprotected channels, we then get to the questio= n of which data can be sent over such channels.=C2=A0 While architecturally= I agree with Juergen that the model is a bad place to specify it, the obve= rse is also true.=C2=A0 Not having some limits on what can be sent unprotec= ted >causes concern about insufficient protection.=C2=A0 If I recall cor= rectly, earlier security reviews called us to task for being too broad in w= hat we allowed.
>>
>> So, if the IESG wants us to just al= low it anywhere, because the model is an awkward place to define the limita= tion, I can live with that.=C2=A0 What I can't live with is being told = both that the model is a bad place to define it and that there must be rest= rictions on what is sent unprotected,
>> without any proposal on h= ow we are to move forward.

> Thank you Joel, this explanation hel= ps me a lot. I think there is a disconnect about how the restrictions are e= xpressed. From reading the email traffic about this document, it strikes me= that trying to express the restrictions programmatically doesn=E2=80=99t m= ake much sense in this case.
> I agree with Juergen that it will be c= hallenging to make a judgment a priori in order to bake a restriction into = a data model, because data that is considered sensitive enough to warrant a= secure transport in one deployment may not be considered sensitive in anot= her deployment.
> So for any data elements where there is any questio= n at all about whether they might be sensitive (i.e., any data elements tha= t are not already routinely made public),
> I would expect data model= authors to end up indicating that they may be sent over either secure or i= nsecure transport, which renders the indication not useful.
> Perhaps= it would make more sense then to just enumerate in the text the cases that= motivate the inclusion of protocol support for insecure transport:
>=
> 1. For conveyance of information that is already routinely made pu= blic.
> 2. For line card activity data where there is no likely upgra= de path to support secure transports in the foreseeable future.
>
= > Then the normative requirements would be on clients and agents to use = secure transports unless those clients and agents are deployed where either= of the operational circumstances above necessitate otherwise.
> Alis= sa

Point 1:
I disagree with Juergen on the difficulty in specifyi= ng the sections of the yang modules.=C2=A0 I have provided a suggested solu= tion in:
https://tools.ietf.org/html/= draft-hares-i2rs-protocol-strawman-03#section-4.5.2.

G= iven the mount schema functionality, we can mount ephemeral state module wh= ich augment non-ephemeral state modules which are "in-secure only"= ;.

Point 2:
I am willing to put an enumeration of the use cases i= n the protocol requirement, but I would like to understand the purpose for = the enumeration.=C2=A0 =C2=A0We are not doing a use case, but a requirement= s document.=C2=A0 This information appears to be a "use case" rat= her than a technical description.=C2=A0 =C2=A0What purpose are you looking = for this enumeration to server.=C2=A0 Are you looking for the enumeration i= n SEC-REQ-08?

Point 3: Could you review -08.txt on this topic, espec= ially the text below.=C2=A0 Given your comments, I believe I should change = the last line to a MUST.
New/=C2=A0 =C2=A0The default mode of transport = is
=C2=A0 =C2=A0secure so data models MUST clearly annotate what data no= des can be
=C2=A0 =C2=A0passed over an insecure connection.
/

= Sue

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
As = to the normative requirements (-08.txt) version:

Section 3:

= =C2=A0 =C2=A0I2RS allows the use of an insecure transport for portions of d= ata
=C2=A0 =C2=A0models that clearly indicate the use of an insecure tra= nsport.
=C2=A0 =C2=A0Operators deploying I2RS must determine if they wan= t to populate and
=C2=A0 =C2=A0deploy the portions of the data model whi= ch use insecure transports.

In Section 3.2 in version -08.txt
=C2=A0 =C2=A0SEC-REQ-08: The I2RS protocol MUST be able to transfer data o= ver a
=C2=A0 =C2=A0secure transport and optionally MAY be able to transf= er data over a
=C2=A0 =C2=A0non-secure transport.=C2=A0 A secure transpo= rt MUST provide data
=C2=A0 =C2=A0confidentiality, data integrity, and r= eplay prevention.

=C2=A0 =C2=A0The default I2RS transport is a secur= e transport.

=C2=A0 =C2=A0A non-secure transport can be used for pub= lishing telemetry data or
=C2=A0 =C2=A0other operational state that was = specifically indicated to non-
=C2=A0 =C2=A0confidential in the data mod= el in the Yang syntax.

=C2=A0 =C2=A0The configuration of ephemeral d= ata in the I2RS Agent by the I2RS
=C2=A0 =C2=A0client SHOULD be done ove= r a secure transport.=C2=A0 It is anticipated
=C2=A0 =C2=A0that the pass= ing of most I2RS ephemeral state operational status
=C2=A0 =C2=A0SHOULD = be done over a secure transport.=C2=A0 As
=C2=A0 =C2=A0[I-D.ietf-i2rs-ep= hemeral-state] notes,=C2=A0 a data model MUST indicate
=C2=A0 =C2= =A0whether the transport exchanging the data between I2RS client and
=C2= =A0 =C2=A0I2RS agent is secure or insecure.

=C2=A0 =C2=A0The default= mode of transport is
=C2=A0 =C2=A0secure so data models SHOULD clearly = annotate what data nodes can be
=C2=A0 =C2=A0passed over an insecure con= nection.

>
> Yours,
> Joel
>
> -----Origi= nal Message-----
> From: Susan Hares [mailto:shares@ndzh.com]
> Sent: Thursday, A= ugust 18, 2016 9:17 AM
> To: 'Juergen Schoenwaelder' <j.sch= oenwaelder@jacobs-university.de>
> Cc: i2rs@ietf.org; i2rs-chairs@ietf.org; 'Kathleen = Moriarty'
> <Kathleen.Moriarty.ietf@gmail.com>; 'Th= e IESG' <iesg@iet= f.org>;
> = jhaas@pfrc.org;
> draft-ietf-i2rs-protocol-security-requirements@ietf.org
> Subject: RE: [i2rs] Kathleen Mo= riarty's Discuss on
> draft-ietf-i2rs-protocol-security-requ= irements-07: (with DISCUSS and
> COMMENT)
>
> Juergen and= Kathleen:
>
> Let me proceed with two examples: BGP route view= s data model and the event for the web-service data.
>
> The co= ntent of these data models are designated as exposed to public.=C2=A0 The r= outing system only populates the proposed BGP route views data model with t= he data destined for the BGP looking glass.=C2=A0 The policy on the routing= system indicates what information gets transferred.=C2=A0 The data model i= s completely available to the public.=C2=A0 The Yang Doctors are going to r= eview this by seeing the whole model is public and available via non-secure= means.
> The security people are going to review this seeing that th= e whole model is public, and available via an unprotect means.=C2=A0 The fa= ct the data model is all public should simplify the review.
>
>= An event from the I2RS RIB that a web-service route is up is the second ca= se.=C2=A0 The I2RS RIB has an event based on policy that indicates a web-se= rvice route is up.=C2=A0 The yang-1.1 doctors must review the content of th= e event text to see it does not break privacy or provide too much
> i= nformation=C2=A0 =C2=A0The event mechanisms will need to work over secure t= ransport
> and insecure transport.=C2=A0 Most of the data will go ove= r the secure transport event stream. However, a small amount of information= may go over the insecure transport stream.
>
> First, let me k= now if my use cases are understandable.=C2=A0 Second, let me know if you di= sagree with this use cases.
>
> Fyi -=C2=A0 IESG approved the a= rchitecture with the insecure stream.
>
> Sue
>
> -= ----Original Message-----
> From: Juergen Schoenwaelder
> [mail= to:j.schoenwaelder@jacobs-university.de]
> Sent: Thursday, Au= gust 18, 2016 9:06 AM
> To: Susan Hares
> Cc: i2rs@ietf.org; i2rs-chairs@ietf.org; 'Kathleen= Moriarty'; 'The
> IESG'; jhaas@pfrc.org;
> draft-ie= tf-i2rs-protocol-security-requirements@ietf.org
> Subject: R= e: [i2rs] Kathleen Moriarty's Discuss on
> draft-ietf-i2rs-protoc= ol-security-requirements-07: (with DISCUSS and
> COMMENT)
>= ;
> I just do not know on which basis a data model writer can decide = whether a data object can be exposed in an unprotected way. How are YANG do= ctors going to review this? How are security directorate people going to ju= dge this? But as promised, I leave (still puzzled) now.
>
> /js=
>
> On Thu, Aug 18, 2016 at 09:00:14AM -0400, Susan Hares wrot= e:
>> Juergen:
>>
>> Yes, we seem to disagree on= the value of making it hardwired in the model.
>> For me, the val= ue is a common understanding of deployment
>> distribution
>= such
>> as the route-views.=C2=A0 =C2=A0Since the operators argue= d strongly for this point,
> I
>> think the best idea is to = get it working in code and then see if the
>> deployment matches t= he requests.
>>
>> Sue
>>
>> -----Origi= nal Message-----
>> From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Jue= rgen
>> Schoenwaelder
>> Sent: Thursday, August 18, 2016 = 8:14 AM
>> To: Susan Hares
>> Cc: i2rs@ietf.org; i2rs-chairs@ietf.org; 'Kathleen Moria= rty'; 'The
>> IESG'; jhaas@pfrc.org;
>> draft-= ietf-i2rs-protocol-security-requirements@ietf.org
>> Subj= ect: Re: [i2rs] Kathleen Moriarty's Discuss on
>> draft-ietf-i= 2rs-protocol-security-requirements-07: (with DISCUSS and
>> C= OMMENT)
>>
>> Sue,
>>
>> I still do not= see why the 'mode of exposure' of data benefits from
>> b= eing hard-wired in the data model. For me, it is a situational and
>&= gt; deployment specific question. But I shut up here since I aired this
= >> concern before (and we simply seem to disagree).
>>
&g= t;> /js
>>
>> On Thu, Aug 18, 2016 at 08:07:18AM -0400= , Susan Hares wrote:
>>> Juergen:
>>>
>>&g= t; My example is the looking glass servers for the BGP route views
>&= gt;> project
>>> (http://www.routeviews.org/) or a route indicating the pr= esence of a
>>> web-server that is public.=C2=A0 =C2=A0For the = BGP I2RS route, a yang model could
>>> replace the looking glas= s function, and provide events for these looking
>>> glass func= tions.=C2=A0 =C2=A0 For the web-server route,=C2=A0 an event be sent when> that
>>> one route is added.
>>>
>>= > Sue
>>>
>>>
>>> -----Original Mess= age-----
>>> From: Juergen Schoenwaelder
>>> [mailt= o:j.schoenwaelder@jacobs-university.de]
>>> Sent: Thurs= day, August 18, 2016 3:32 AM
>>> To: Susan Hares
>>>= ; Cc: 'Kathleen Moriarty'; 'The IESG'; jhaas@pfrc.org; i2rs@ietf.org;
>>> i2rs-chairs@ietf.org;
= >>> draft-ietf-i2rs-protocol-security-requi= rements@ietf.org
>>> Subject: Re: [i2rs] Kathleen Moriarty&= #39;s Discuss on
>>> draft-ietf-i2rs-protocol-security-req= uirements-07: (with DISCUSS and
>>> COMMENT)
>>>>>> On Wed, Aug 17, 2016 at 09:16:48PM -0400, Susan Hares wrote:<= br>>>>> --------------------------------------------------= ----------------
>>>> --
>>>> --
>= >>> COMMENT:
>>>> ------------------------------------------------------------------
>>>> --
>&= gt;>> --
>>>>
>>>>> Section 3:
&g= t;>>>> Can you clarify the second to last sentence?=C2=A0 Do yo= u mean there
>>>>> are
>>> sections that indi= cate an insecure transport should be used?
>>>>>=C2=A0 I2= RS allows the use of an
>>>>> insecure transport for port= ions of data models that clearly
>>>>> indicate=C2=A0 ins= ecure transport.
>>>>
>>>>> Perhaps:
&g= t;>>>> I2RS allows the use of an
>>>>> insecu= re transport for portions of data models that clearly
>>>>&g= t; indicate the use of an=C2=A0 insecure transport.
>>>
>= >> I still wonder how a data model writer can reasonably decide wheth= er
>>> a piece of information can be shipped safely over an ins= ecure
>>> transport since this decision often depends on the sp= ecifics of a
>>> deployment
>> situation.
>>&= gt;
>>> /js
>>>
>>> PS: I hope we do no= t end up with defining data multiple times (once
>>>=C2=A0 =C2= =A0 for insecure transport and once for secured transports).
>>>= ;
>>> --
>>> Juergen Schoenwaelder=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0Jacobs University Bremen gGmbH
>>> Phon= e: +49 421 200 3587=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Campus Ring 1 | 28759 = Bremen | Germany
>>> Fax:=C2=A0 =C2=A0+49 421 200 3103=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0<http://www.jacobs-university.de/>
>>= ;>
>>> _______________________________________________<= br>>>> i2rs mailing list
>>> i2rs@ietf.org
>>> https://www.ietf.= org/mailman/listinfo/i2rs
>>
>> --
>> J= uergen Schoenwaelder=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Jacobs Univers= ity Bremen gGmbH
>> Phone: +49 421 200 3587=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0Campus Ring 1 | 28759 Bremen | Germany
>> Fax:=C2=A0 = =C2=A0+49 421 200 3103=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<http://www.jacobs-univ= ersity.de/>
>>
>> _______________________________________________
>> i2rs mailing list
>> i2rs@ietf.org
>> https://= www.ietf.org/mailman/listinfo/i2rs
>>
>
> --<= br>> Juergen Schoenwaelder=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Jacob= s University Bremen gGmbH
> Phone: +49 421 200 3587=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0Campus Ring 1 | 28759 Bremen | Germany
> Fax:=C2=A0 = =C2=A0+49 421 200 3103=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<http://www.jacobs-univ= ersity.de/>
>


________________________________= _______________
i2rs mailing list
i2rs@ietf.org
https://www.ietf.org/mailman/listin= fo/i2rs

=C2=A0<= /u>

= =C2=A0


--94eb2c123794ead881053a5ed459-- From nobody Fri Aug 19 04:02:32 2016 Return-Path: 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 D473312D692 for ; Thu, 18 Aug 2016 14:28:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.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 FErEZkBwW6gL for ; Thu, 18 Aug 2016 14:28:03 -0700 (PDT) Received: from mail-ua0-x22b.google.com (mail-ua0-x22b.google.com [IPv6:2607:f8b0:400c:c08::22b]) (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 1065C12D675 for ; Thu, 18 Aug 2016 14:27:59 -0700 (PDT) Received: by mail-ua0-x22b.google.com with SMTP id n59so49755012uan.2 for ; Thu, 18 Aug 2016 14:27:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Cmb5wRdyWSG8rsJi7posOxo+bs+6D2e8gwhsAU0rvPU=; b=oEBLfIje99zhArbGQZodrj7vHc3M/G1B225ZsNZdHZcL6xeWbaJ5e0LHk8c6sojYU/ AAkji1cHXAtvjKSEBpgfJDK+tC/jJgs0DeSQizlsEnryYpbqB/p157y/LyXqI2qQ8pB6 rFM7A1+gJPWTXI2cjfmYfkjYZLRsjxWfB6q83AYD4RxlnaABx+AsfFv+N1fT6Jpi4h/L lHpjgcj3EtRA71TgG7Be9HwXmKSHNEQcKGf37mMMC7DtGsvZ+BVCzK/c7LyOA9wGQfbJ UF9+yypLqSLDC5lZKx4JAR2X38wqvfxNXXJ/tNfocytmMO/iXsTx7eTeVpo819FZ+1Ai NOoQ== 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; bh=Cmb5wRdyWSG8rsJi7posOxo+bs+6D2e8gwhsAU0rvPU=; b=QqV1flS7ziVeEpI/50twD3sO3s1/b6TFTimPmq7pw3Z6pJrUwnYB6iQAcR4QSNWkCA pnaXL4QUMkh80rzwxPZD0q2U4WJihJY9lKX6xPw4LuKRzIdgU1Q9n9pTlSRKTrHW+FaE eIJBobgnC+POzFY2bP494q+P7KEq63UvJUcdcaHmPHjfn5YqcJMKzBI+gLpJVsWF/YAc H3N2bUhhJ/KyRFigEwjVl5NIpQWFX66cljO51QG2eXeJsqHd0A+xih9KMVzgwS2ophbL 6z28sm9OJ+dd9LJkBCve61NIyrnshViNSo2tSNYNHJuffHIjqWnnApKakZRKTOUtWWKR qeeQ== X-Gm-Message-State: AEkoousrtvLQ8m75tpwg63Jqu7XlcwmFzPRJ6dEmmKjqdKzVBCzWGnY2I9H2OEXhu0sUReEqV7gYrHh4Xw6L9A== X-Received: by 10.31.136.70 with SMTP id k67mr2295893vkd.13.1471555678015; Thu, 18 Aug 2016 14:27:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.4.198 with HTTP; Thu, 18 Aug 2016 14:27:57 -0700 (PDT) In-Reply-To: <00dc01d1f988$f2cec280$d86c4780$@ndzh.com> References: <147146974235.23784.4389421535496134619.idtracker@ietfa.amsl.com> <013b01d1f8ee$31fa09b0$95ee1d10$@ndzh.com> <20160818073203.GA4338@elstar.local> <04b501d1f949$116c63e0$34452ba0$@ndzh.com> <20160818121405.GA5282@elstar.local> <051301d1f950$7739c670$65ad5350$@ndzh.com> <20160818130555.GA5366@elstar.local> <051701d1f952$c4ae0b30$4e0a2190$@ndzh.com> <6BCE198E4EAEFC4CAB45D75826EFB0761525CCD7@eusaamb101.ericsson.se> <003801d1f97f$3d16eb10$b744c130$@ndzh.com> <00dc01d1f988$f2cec280$d86c4780$@ndzh.com> From: Andy Bierman Date: Thu, 18 Aug 2016 14:27:57 -0700 Message-ID: To: Susan Hares Content-Type: multipart/alternative; boundary=001a11440bb674b0c6053a5f418b Archived-At: X-Mailman-Approved-At: Fri, 19 Aug 2016 04:02:25 -0700 Cc: "i2rs@ietf.org" , Alissa Cooper , Juergen Schoenwaelder , 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) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Aug 2016 21:28:07 -0000 --001a11440bb674b0c6053a5f418b Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, Aug 18, 2016 at 12:44 PM, Susan Hares wrote: > Andy: > > > > Thank you =E2=80=93 I thought it was on whether we could implement insecu= re > transport in a Yang module. > > > > The requirement text you are working with is: > > > > SEC-REQ-08: The I2RS protocol MUST be able to transfer data over a > secure transport and optionally MAY be able to transfer data over a > non-secure transport. > > > I do not understand why approving the ok for non-secure transport for some > modules means the following to you: > > > > *=E2=80=9C the IETF needs to agree that there could never possibly be any > deployment that would not want to allow exposure of the data.* > > *Not now. Not 20 years from now.=E2=80=9D* > > > I see your point now. This draft makes no mention of the YANG data model marking objects that can be nonsecure. SEC-REQ-08 is fine. The other requirement (sorry I don't have the number) is the one that should be removed. Andy I had thought that the security-directorate and other reviewers would look > at each module that is insecure, and consider whether it was reasonable > for the use case at this time. This is what I understood from Russ > Housley=E2=80=99s first review of this technology. Since like you, I bel= ieve the > operator is going to configure what modules are allowed on systems. I > agree that this requirement provides a full scope of the work, but > implementers will require network operators to configure these features o= n. > > > > Sue > > > > > > *From:* Andy Bierman [mailto:andy@yumaworks.com] > *Sent:* Thursday, August 18, 2016 2:53 PM > *To:* Susan Hares > *Cc:* Alissa Cooper; Joel Halpern; i2rs@ietf.org; Juergen Schoenwaelder; > i2rs-chairs@ietf.org; Kathleen Moriarty; IESG; Jeffrey Haas; > 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) > > > > Hi, > > > > I did not think Juergen's comment was about running code. > > > > In order for a data node to get the "ok-for-nonsecure-transports" approva= l > > in an IETF module, the IETF needs to agree that there could never possibl= y > be > > any deployment that would not want to allow exposure of the data. > > Not now. Not 20 years from now. > > > > I can see a vendor making that decision for their own proprietary modules= , > > but it seems less likely for standard modules. > > > > Seems like the operator is going to have to configure what is allowed > > for nonsecure transport anyway, so just let them decide. > > I don't really object to the extension or the requirement. > > It doesn't help much but it doesn't hurt much either. > > > > > > Andy > > > > > > > > On Thu, Aug 18, 2016 at 11:35 AM, Susan Hares wrote: > > Alissa: > > Just a little input you may not know. My background is 15 years > (1995-2010) developing a routing/switching platform (denoted as GateD) > which was sold to over 200 companies. We developed XML and a binary XML > based product that configured this product. It could do 100K configurati= on > lines and reboot in less than a second on most hardware. We also provide > status messages in secure streams and non-secure streams. I sold early > version of this code to companies that Alia has worked for - so she has > personal viewed the code. At the height of our work, our development te= am > ran to 50 people which I directed (First as VP of Engineering, and then a= s > CTO). It is due to this level of experience that Alia selected me for the > co-chair. Russ White has understood Cisco's process, and has also > directed software development teams for routing. > > In order to freshen my direct experience with I2RS on open source work, I > am working on a publically available work in Quagga based on the confD > product suggested by Cisco. > > In contrast, Juergen is a university professor who has worked on > proto-types. He is not working on an implementation. I hope he will. > > I hope you will consider this background in my response to your comments > below. > > Sue > > > -----Original Message----- > From: Alissa Cooper [mailto:alissa@cooperw.in] > Sent: Thursday, August 18, 2016 12:54 PM > To: Joel Halpern > Cc: Susan Hares; Juergen Schoenwaelder; i2rs@ietf.org; > i2rs-chairs@ietf.org; Kathleen Moriarty; IESG; jhaas@pfrc.org; > 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) > > Jumping in here because this is relevant to my DISCUSS, hope nobody minds > (but if you do, I can go back to the other thread). > > >> On Aug 18, 2016, at 10:30 AM, Joel Halpern > wrote: > >> > >> Let me try a different take approach to this particular question. > >> > >> Let me start by putting aside the question of where things are marked, > and come back to that afterwards. > >> > >> There are a number of cases that I2RS has been asked to cover of high > rate telemetry data. This may be BGP update information, it may be > frequent information about line card activity. There are other cases, so= me > of which have been documented. > >> > >> While not completely insensitive, the operators have made clear that > they see protecting this data as unnecessary. While I would hope over ti= me > to move to a domain where all of it is protect, that is not trivial. As > the I2RS Architecture points out, it is expected that what we describe as= a > single I2RS >communication between a client and agent is actually > associated with multiple channels of communication. > >> > >> Now, if you want to say that the I2RS protocol requirements cannot > allow for unprotected channels, I guess we have disconnect between the IE= SG > and the WG. > >> > >> If we say that we can allow for unprotected channels, we then get to > the question of which data can be sent over such channels. While > architecturally I agree with Juergen that the model is a bad place to > specify it, the obverse is also true. Not having some limits on what can > be sent unprotected >causes concern about insufficient protection. If I > recall correctly, earlier security reviews called us to task for being to= o > broad in what we allowed. > >> > >> So, if the IESG wants us to just allow it anywhere, because the model > is an awkward place to define the limitation, I can live with that. What= I > can't live with is being told both that the model is a bad place to defin= e > it and that there must be restrictions on what is sent unprotected, > >> without any proposal on how we are to move forward. > > > Thank you Joel, this explanation helps me a lot. I think there is a > disconnect about how the restrictions are expressed. From reading the ema= il > traffic about this document, it strikes me that trying to express the > restrictions programmatically doesn=E2=80=99t make much sense in this cas= e. > > I agree with Juergen that it will be challenging to make a judgment a > priori in order to bake a restriction into a data model, because data tha= t > is considered sensitive enough to warrant a secure transport in one > deployment may not be considered sensitive in another deployment. > > So for any data elements where there is any question at all about > whether they might be sensitive (i.e., any data elements that are not > already routinely made public), > > I would expect data model authors to end up indicating that they may be > sent over either secure or insecure transport, which renders the indicati= on > not useful. > > Perhaps it would make more sense then to just enumerate in the text the > cases that motivate the inclusion of protocol support for insecure > transport: > > > > 1. For conveyance of information that is already routinely made public. > > 2. For line card activity data where there is no likely upgrade path to > support secure transports in the foreseeable future. > > > > Then the normative requirements would be on clients and agents to use > secure transports unless those clients and agents are deployed where eith= er > of the operational circumstances above necessitate otherwise. > > Alissa > > Point 1: > I disagree with Juergen on the difficulty in specifying the sections of > the yang modules. I have provided a suggested solution in: > https://tools.ietf.org/html/draft-hares-i2rs-protocol-strawm > an-03#section-4.5.2. > > Given the mount schema functionality, we can mount ephemeral state module > which augment non-ephemeral state modules which are "in-secure only". > > Point 2: > I am willing to put an enumeration of the use cases in the protocol > requirement, but I would like to understand the purpose for the > enumeration. We are not doing a use case, but a requirements document. > This information appears to be a "use case" rather than a technical > description. What purpose are you looking for this enumeration to > server. Are you looking for the enumeration in SEC-REQ-08? > > Point 3: Could you review -08.txt on this topic, especially the text > below. Given your comments, I believe I should change the last line to a > MUST. > New/ The default mode of transport is > secure so data models MUST clearly annotate what data nodes can be > passed over an insecure connection. > / > > Sue > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > As to the normative requirements (-08.txt) version: > > Section 3: > > I2RS allows the use of an insecure transport for portions of data > models that clearly indicate the use of an insecure transport. > Operators deploying I2RS must determine if they want to populate and > deploy the portions of the data model which use insecure transports. > > In Section 3.2 in version -08.txt > > SEC-REQ-08: The I2RS protocol MUST be able to transfer data over a > secure transport and optionally MAY be able to transfer data over a > non-secure transport. A secure transport MUST provide data > confidentiality, data integrity, and replay prevention. > > The default I2RS transport is a secure transport. > > 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. > > The configuration of ephemeral data in the I2RS Agent by the I2RS > client SHOULD be done over a secure transport. It is anticipated > that the passing of most I2RS ephemeral state operational status > SHOULD be done over a secure transport. As > [I-D.ietf-i2rs-ephemeral-state] notes, a data model MUST indicate > whether the transport exchanging the data between I2RS client and > I2RS agent is secure or insecure. > > The default mode of transport is > secure so data models SHOULD clearly annotate what data nodes can be > passed over an insecure connection. > > > > > Yours, > > Joel > > > > -----Original Message----- > > From: Susan Hares [mailto:shares@ndzh.com] > > Sent: Thursday, August 18, 2016 9:17 AM > > To: 'Juergen Schoenwaelder' > > Cc: i2rs@ietf.org; i2rs-chairs@ietf.org; 'Kathleen Moriarty' > > ; 'The IESG' ; > > jhaas@pfrc.org; > > 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) > > > > Juergen and Kathleen: > > > > Let me proceed with two examples: BGP route views data model and the > event for the web-service data. > > > > The content of these data models are designated as exposed to public. > The routing system only populates the proposed BGP route views data model > with the data destined for the BGP looking glass. The policy on the > routing system indicates what information gets transferred. The data mod= el > is completely available to the public. The Yang Doctors are going to > review this by seeing the whole model is public and available via > non-secure means. > > The security people are going to review this seeing that the whole mode= l > is public, and available via an unprotect means. The fact the data model > is all public should simplify the review. > > > > An event from the I2RS RIB that a web-service route is up is the second > case. The I2RS RIB has an event based on policy that indicates a > web-service route is up. The yang-1.1 doctors must review the content of > the event text to see it does not break privacy or provide too much > > information The event mechanisms will need to work over secure > transport > > and insecure transport. Most of the data will go over the secure > transport event stream. However, a small amount of information may go ove= r > the insecure transport stream. > > > > First, let me know if my use cases are understandable. Second, let me > know if you disagree with this use cases. > > > > Fyi - IESG approved the architecture with the insecure stream. > > > > Sue > > > > -----Original Message----- > > From: Juergen Schoenwaelder > > [mailto:j.schoenwaelder@jacobs-university.de] > > Sent: Thursday, August 18, 2016 9:06 AM > > To: Susan Hares > > Cc: i2rs@ietf.org; i2rs-chairs@ietf.org; 'Kathleen Moriarty'; 'The > > IESG'; jhaas@pfrc.org; > > 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) > > > > I just do not know on which basis a data model writer can decide whethe= r > a data object can be exposed in an unprotected way. How are YANG doctors > going to review this? How are security directorate people going to judge > this? But as promised, I leave (still puzzled) now. > > > > /js > > > > On Thu, Aug 18, 2016 at 09:00:14AM -0400, Susan Hares wrote: > >> Juergen: > >> > >> Yes, we seem to disagree on the value of making it hardwired in the > model. > >> For me, the value is a common understanding of deployment > >> distribution > > such > >> as the route-views. Since the operators argued strongly for this > point, > > I > >> think the best idea is to get it working in code and then see if the > >> deployment matches the requests. > >> > >> Sue > >> > >> -----Original Message----- > >> From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Juergen > >> Schoenwaelder > >> Sent: Thursday, August 18, 2016 8:14 AM > >> To: Susan Hares > >> Cc: i2rs@ietf.org; i2rs-chairs@ietf.org; 'Kathleen Moriarty'; 'The > >> IESG'; jhaas@pfrc.org; > >> 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) > >> > >> Sue, > >> > >> I still do not see why the 'mode of exposure' of data benefits from > >> being hard-wired in the data model. For me, it is a situational and > >> deployment specific question. But I shut up here since I aired this > >> concern before (and we simply seem to disagree). > >> > >> /js > >> > >> On Thu, Aug 18, 2016 at 08:07:18AM -0400, Susan Hares wrote: > >>> Juergen: > >>> > >>> My example is the looking glass servers for the BGP route views > >>> project > >>> (http://www.routeviews.org/) or a route indicating the presence of a > >>> web-server that is public. For the BGP I2RS route, a yang model cou= ld > >>> replace the looking glass function, and provide events for these > looking > >>> glass functions. For the web-server route, an event be sent when > > that > >>> one route is added. > >>> > >>> Sue > >>> > >>> > >>> -----Original Message----- > >>> From: Juergen Schoenwaelder > >>> [mailto:j.schoenwaelder@jacobs-university.de] > >>> Sent: Thursday, August 18, 2016 3:32 AM > >>> To: Susan Hares > >>> Cc: 'Kathleen Moriarty'; 'The IESG'; jhaas@pfrc.org; i2rs@ietf.org; > >>> i2rs-chairs@ietf.org; > >>> 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 Wed, Aug 17, 2016 at 09:16:48PM -0400, Susan Hares wrote: > >>>> ------------------------------------------------------------------ > >>>> -- > >>>> -- > >>>> COMMENT: > >>>> ------------------------------------------------------------------ > >>>> -- > >>>> -- > >>>> > >>>>> Section 3: > >>>>> Can you clarify the second to last sentence? Do you mean there > >>>>> are > >>> sections that indicate an insecure transport should be used? > >>>>> I2RS allows the use of an > >>>>> insecure transport for portions of data models that clearly > >>>>> indicate insecure transport. > >>>> > >>>>> Perhaps: > >>>>> I2RS allows the use of an > >>>>> insecure transport for portions of data models that clearly > >>>>> indicate the use of an insecure transport. > >>> > >>> I still wonder how a data model writer can reasonably decide whether > >>> a piece of information can be shipped safely over an insecure > >>> transport since this decision often depends on the specifics of a > >>> deployment > >> situation. > >>> > >>> /js > >>> > >>> PS: I hope we do not end up with defining data multiple times (once > >>> for insecure transport and once for secured transports). > >>> > >>> -- > >>> Juergen Schoenwaelder Jacobs University Bremen gGmbH > >>> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | German= y > >>> Fax: +49 421 200 3103 > >>> > >>> _______________________________________________ > >>> i2rs mailing list > >>> i2rs@ietf.org > >>> https://www.ietf.org/mailman/listinfo/i2rs > >> > >> -- > >> Juergen Schoenwaelder Jacobs University Bremen gGmbH > >> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > >> Fax: +49 421 200 3103 > >> > >> _______________________________________________ > >> i2rs mailing list > >> i2rs@ietf.org > >> https://www.ietf.org/mailman/listinfo/i2rs > >> > > > > -- > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > > Fax: +49 421 200 3103 > > > > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs > > > --001a11440bb674b0c6053a5f418b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Aug 18, 2016 at 12:44 PM, Susan Hares <shares@ndzh.com> wrote:

Andy:

=C2=A0=

Thank you =E2=80=93 I though= t it was on whether we could implement insecure transport in a Yang module.=

=C2=A0=

The requirement text = you are working with is:

=C2=A0

=C2=A0 =C2= =A0SEC-REQ-08: The I2RS protocol MUST be able to transfer data over a
= =C2=A0 =C2=A0secure transport and optionally MAY be able to transfer data o= ver a
=C2=A0 =C2=A0non-secure transport.

=C2=A0=C2=A0

I do not understand why approving the ok for n= on-secure transport for some modules means the following to you: =

=C2= =A0

=E2= =80=9C the IETF needs to agree that there could never possibly be any deplo= yment that would not want to allow exposure of the data.

Not now. Not 20 = years from now.=E2=80=9D

=C2=A0



I see your point now.
This draft makes no = mention of the YANG data model marking objects that can be nonsecure.
=


SEC-REQ-08 is fine.
The other = requirement (sorry I don't have the number) is the one that
s= hould be removed.


Andy

<= p class=3D"MsoNormal">I had thought that the security-director= ate and other reviewers would look at each module that is insecure, and =C2= =A0consider whether it was reasonable for the use case at this time.=C2=A0 = =C2=A0This is what I understood from Russ Housley=E2=80=99s first review of= this technology.=C2=A0 Since like you, I believe the operator is going to = =C2=A0configure what modules are allowed on systems.=C2=A0 =C2=A0I agree th= at this requirement provides a full scope of the work, but implementers wil= l require network operators to configure these features on. <= /span>

=C2=A0

Sue

=C2=A0

=C2=A0=

From: Andy= Bierman [mailto:an= dy@yumaworks.com]
Sent: Thursday, August 18, 2016 2:53 PMTo: Susan Hares
Cc: Alissa Cooper; Joel Halpern; i2rs@ietf.org; Juergen Scho= enwaelder; i2rs-c= hairs@ietf.org; Kathleen Moriarty; IESG; Jeffrey Haas; draft-ietf-i2rs-protocol-security-requirements@ietf.org
Su= bject: Re: [i2rs] Kathleen Moriarty's Discuss on draft-ietf-i2rs-pr= otocol-security-requirements-07: (with DISCUSS and COMMENT)<= /u>

=C2=A0

Hi,

=C2= =A0

I did not think Juergen'= ;s comment was about running code.

=C2=A0

In ord= er for a data node to get the "ok-for-nonsecure-transports" appro= val

in an IETF module, t= he IETF needs to agree that there could never possibly be

=

any deployment that would not want to all= ow exposure of the data.

Not now. Not 20 years from now.

=C2=A0

I can se= e a vendor making that decision for their own proprietary modules,

but it seems less likely for sta= ndard modules.

= =C2=A0

Seems like the operator = is going to have to configure what is allowed

<= p class=3D"MsoNormal">for nonsecure transport anyway, so just let them deci= de.

I don't really o= bject to the extension or the requirement.

It doesn't help much but it doesn't hurt much ei= ther.

=C2=A0

=C2=A0

=

Andy

=C2=A0

=C2=A0=

=C2=A0

=

On Thu, Aug 18, 2016 at 11:35 AM, Susan Hares &= lt;shares@ndzh.com= > wrote:

Alissa:

Just a l= ittle input you may not know.=C2=A0 My background is 15 years (1995-2010)= =C2=A0 developing a routing/switching platform (denoted as GateD) which was= sold to over 200 companies.=C2=A0 =C2=A0We developed XML and a binary XML = based product that configured this product.=C2=A0 It could do 100K configur= ation lines and reboot in less than a second on most hardware.=C2=A0 We als= o provide status messages in secure streams and non-secure streams.=C2=A0 = =C2=A0 I sold early version of this code to companies that Alia has worked = for=C2=A0 - so she has personal viewed the code.=C2=A0 =C2=A0At the height = of our work, our development team ran to 50 people which I directed (First = as VP of Engineering, and then as CTO). It is due to this level of experien= ce that Alia selected me for the co-chair.=C2=A0 =C2=A0Russ White has under= stood Cisco's process, and has also directed software development teams= for routing.

In order to freshen my direct experience with I2RS on = open source work, I am working on a publically available work in Quagga bas= ed on the confD product suggested by Cisco.

In contrast, Juergen is = a university professor who has worked on proto-types.=C2=A0 =C2=A0He is not= working on an implementation.=C2=A0 =C2=A0I hope he will.

I hope yo= u will consider this background in my response to your comments below.
<= br>Sue


-----Original Message-----
From: Alissa Cooper [mailto= :alissa@cooperw.in]
Sent: Thursday, August 18, 2016 12:54 PM
To: Joel Halpern
Cc: = Susan Hares; Juergen Schoenwaelder; i2rs@ietf.org; i2rs-chairs@ietf.org; Kathleen Moriarty; IESG; jhaas@pfrc.org; draft-ietf-i2rs-protocol-security-requirements@ietf.org
Su= bject: Re: [i2rs] Kathleen Moriarty's Discuss on draft-ietf-i2rs-protoc= ol-security-requirements-07: (with DISCUSS and COMMENT)

Jumping= in here because this is relevant to my DISCUSS, hope nobody minds (but if = you do, I can go back to the other thread).

>> On Aug 18, 2016= , at 10:30 AM, Joel Halpern <joel.halpern@ericsson.com> wrote:
>>>> Let me try a different take approach to this particular question.=
>>
>> Let me start by putting aside the question of wher= e things are marked, and come back to that afterwards.
>>
>&= gt; There are a number of cases that I2RS has been asked to cover of high r= ate telemetry data.=C2=A0 This may be BGP update information, it may be fre= quent information about line card activity.=C2=A0 There are other cases, so= me of which have been documented.
>>
>> While not complet= ely insensitive, the operators have made clear that they see protecting thi= s data as unnecessary.=C2=A0 While I would hope over time to move to a doma= in where all of it is protect, that is not trivial.=C2=A0 As the I2RS Archi= tecture points out, it is expected that what we describe as a single I2RS &= gt;communication between a client and agent is actually associated with mul= tiple channels of communication.
>>
>> Now, if you want t= o say that the I2RS protocol requirements cannot allow for unprotected chan= nels, I guess we have disconnect between the IESG and the WG.
>>>> If we say that we can allow for unprotected channels, we then ge= t to the question of which data can be sent over such channels.=C2=A0 While= architecturally I agree with Juergen that the model is a bad place to spec= ify it, the obverse is also true.=C2=A0 Not having some limits on what can = be sent unprotected >causes concern about insufficient protection.=C2=A0= If I recall correctly, earlier security reviews called us to task for bein= g too broad in what we allowed.
>>
>> So, if the IESG wan= ts us to just allow it anywhere, because the model is an awkward place to d= efine the limitation, I can live with that.=C2=A0 What I can't live wit= h is being told both that the model is a bad place to define it and that th= ere must be restrictions on what is sent unprotected,
>> without a= ny proposal on how we are to move forward.

> Thank you Joel, this= explanation helps me a lot. I think there is a disconnect about how the re= strictions are expressed. From reading the email traffic about this documen= t, it strikes me that trying to express the restrictions programmatically d= oesn=E2=80=99t make much sense in this case.
> I agree with Juergen t= hat it will be challenging to make a judgment a priori in order to bake a r= estriction into a data model, because data that is considered sensitive eno= ugh to warrant a secure transport in one deployment may not be considered s= ensitive in another deployment.
> So for any data elements where ther= e is any question at all about whether they might be sensitive (i.e., any d= ata elements that are not already routinely made public),
> I would e= xpect data model authors to end up indicating that they may be sent over ei= ther secure or insecure transport, which renders the indication not useful.=
> Perhaps it would make more sense then to just enumerate in the tex= t the cases that motivate the inclusion of protocol support for insecure tr= ansport:
>
> 1. For conveyance of information that is already r= outinely made public.
> 2. For line card activity data where there is= no likely upgrade path to support secure transports in the foreseeable fut= ure.
>
> Then the normative requirements would be on clients an= d agents to use secure transports unless those clients and agents are deplo= yed where either of the operational circumstances above necessitate otherwi= se.
> Alissa

Point 1:
I disagree with Juergen on the diffic= ulty in specifying the sections of the yang modules.=C2=A0 I have provided = a suggested solution in:
https://tool= s.ietf.org/html/draft-hares-i2rs-protocol-strawman-03#section-4.5= .2.

Given the mount schema functionality, we can mount ephemeral= state module which augment non-ephemeral state modules which are "in-= secure only".

Point 2:
I am willing to put an enumeration of= the use cases in the protocol requirement, but I would like to understand = the purpose for the enumeration.=C2=A0 =C2=A0We are not doing a use case, b= ut a requirements document.=C2=A0 This information appears to be a "us= e case" rather than a technical description.=C2=A0 =C2=A0What purpose = are you looking for this enumeration to server.=C2=A0 Are you looking for t= he enumeration in SEC-REQ-08?

Point 3: Could you review -08.txt on t= his topic, especially the text below.=C2=A0 Given your comments, I believe = I should change the last line to a MUST.
New/=C2=A0 =C2=A0The default mo= de of transport is
=C2=A0 =C2=A0secure so data models MUST clearly annot= ate what data nodes can be
=C2=A0 =C2=A0passed over an insecure connecti= on.
/

Sue

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D
As to the normative requirements (-08.txt) version:

Sec= tion 3:

=C2=A0 =C2=A0I2RS allows the use of an insecure transport fo= r portions of data
=C2=A0 =C2=A0models that clearly indicate the use of = an insecure transport.
=C2=A0 =C2=A0Operators deploying I2RS must determ= ine if they want to populate and
=C2=A0 =C2=A0deploy the portions of the= data model which use insecure transports.

In Section 3.2 in version= -08.txt

=C2=A0 =C2=A0SEC-REQ-08: The I2RS protocol MUST be able to = transfer data over a
=C2=A0 =C2=A0secure transport and optionally MAY be= able to transfer data over a
=C2=A0 =C2=A0non-secure transport.=C2=A0 A= secure transport MUST provide data
=C2=A0 =C2=A0confidentiality, data i= ntegrity, and replay prevention.

=C2=A0 =C2=A0The default I2RS trans= port is a secure transport.

=C2=A0 =C2=A0A non-secure transport can = be used for publishing telemetry data or
=C2=A0 =C2=A0other operational = state that was specifically indicated to non-
=C2=A0 =C2=A0confidential = in the data model in the Yang syntax.

=C2=A0 =C2=A0The configuration= of ephemeral data in the I2RS Agent by the I2RS
=C2=A0 =C2=A0client SHO= ULD be done over a secure transport.=C2=A0 It is anticipated
=C2=A0 =C2= =A0that the passing of most I2RS ephemeral state operational status
=C2= =A0 =C2=A0SHOULD be done over a secure transport.=C2=A0 As
=C2=A0 =C2=A0= [I-D.ietf-i2rs-ephemeral-state] notes,=C2=A0 a data model MUST indicat= e
=C2=A0 =C2=A0whether the transport exchanging the data between I2RS cl= ient and
=C2=A0 =C2=A0I2RS agent is secure or insecure.

=C2=A0 = =C2=A0The default mode of transport is
=C2=A0 =C2=A0secure so data model= s SHOULD clearly annotate what data nodes can be
=C2=A0 =C2=A0passed ove= r an insecure connection.

>
> Yours,
> Joel
>> -----Original Message-----
> From: Susan Hares [mailto:shares@ndzh.com]
> = Sent: Thursday, August 18, 2016 9:17 AM
> To: 'Juergen Schoenwael= der' <j.schoenwaelder@jacobs-university.de>
> Cc: <= a href=3D"mailto:i2rs@ietf.org" target=3D"_blank">i2rs@ietf.org; i2rs-chairs@ietf.org; 'Kathleen Moriarty'
> <Kathleen.Moriarty.ietf@gmail.com= >; 'The IESG' <iesg@ietf.org>;
> jhaas@pfrc.org;
> draft-ietf-i= 2rs-protocol-security-requirements@ietf.org
> Subject: RE: [= i2rs] Kathleen Moriarty's Discuss on
> draft-ietf-i2rs-protocol-s= ecurity-requirements-07: (with DISCUSS and
> COMMENT)
>> Juergen and Kathleen:
>
> Let me proceed with two example= s: BGP route views data model and the event for the web-service data.
&g= t;
> The content of these data models are designated as exposed to pu= blic.=C2=A0 The routing system only populates the proposed BGP route views = data model with the data destined for the BGP looking glass.=C2=A0 The poli= cy on the routing system indicates what information gets transferred.=C2=A0= The data model is completely available to the public.=C2=A0 The Yang Docto= rs are going to review this by seeing the whole model is public and availab= le via non-secure means.
> The security people are going to review th= is seeing that the whole model is public, and available via an unprotect me= ans.=C2=A0 The fact the data model is all public should simplify the review= .
>
> An event from the I2RS RIB that a web-service route is up= is the second case.=C2=A0 The I2RS RIB has an event based on policy that i= ndicates a web-service route is up.=C2=A0 The yang-1.1 doctors must review = the content of the event text to see it does not break privacy or provide t= oo much
> information=C2=A0 =C2=A0The event mechanisms will need to w= ork over secure transport
> and insecure transport.=C2=A0 Most of the= data will go over the secure transport event stream. However, a small amou= nt of information may go over the insecure transport stream.
>
>= ; First, let me know if my use cases are understandable.=C2=A0 Second, let = me know if you disagree with this use cases.
>
> Fyi -=C2=A0 IE= SG approved the architecture with the insecure stream.
>
> Sue<= br>>
> -----Original Message-----
> From: Juergen Schoenwael= der
> [mailto:j.schoenwaelder@jacobs-university.de]
> S= ent: Thursday, August 18, 2016 9:06 AM
> To: Susan Hares
> Cc: = i2rs@ietf.org; i2rs-chairs@ietf.org; 'Kathleen Moriarty'; 'The
> IESG'; jhaas@pfrc.org;
> draft-ietf-i2rs-protocol-security-requirements@ietf.org
> Subject: Re: [i2rs] Kathleen Moriarty's Discuss on
> dr= aft-ietf-i2rs-protocol-security-requirements-07: (with DISCUSS and
= > COMMENT)
>
> I just do not know on which basis a data mode= l writer can decide whether a data object can be exposed in an unprotected = way. How are YANG doctors going to review this? How are security directorat= e people going to judge this? But as promised, I leave (still puzzled) now.=
>
> /js
>
> On Thu, Aug 18, 2016 at 09:00:14AM -04= 00, Susan Hares wrote:
>> Juergen:
>>
>> Yes, we= seem to disagree on the value of making it hardwired in the model.
>= > For me, the value is a common understanding of deployment
>> = distribution
> such
>> as the route-views.=C2=A0 =C2=A0Since= the operators argued strongly for this point,
> I
>> think = the best idea is to get it working in code and then see if the
>> = deployment matches the requests.
>>
>> Sue
>>>> -----Original Message-----
>> From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Juergen
>> Schoenwaelder
>> Sent: Thursd= ay, August 18, 2016 8:14 AM
>> To: Susan Hares
>> Cc: i2rs@ietf.org; i2rs-chairs@ietf.org= ; 'Kathleen Moriarty'; 'The
>> IESG'; jhaas@pfrc.org;
>> draft-ietf-i2rs-protocol-security-requirements@ietf.org=
>> Subject: Re: [i2rs] Kathleen Moriarty's Discuss on
= >> draft-ietf-i2rs-protocol-security-requirements-07: (with DISC= USS and
>> COMMENT)
>>
>> Sue,
>>
&g= t;> I still do not see why the 'mode of exposure' of data benefi= ts from
>> being hard-wired in the data model. For me, it is a sit= uational and
>> deployment specific question. But I shut up here s= ince I aired this
>> concern before (and we simply seem to disagre= e).
>>
>> /js
>>
>> On Thu, Aug 18, 201= 6 at 08:07:18AM -0400, Susan Hares wrote:
>>> Juergen:
>&= gt;>
>>> My example is the looking glass servers for the BGP= route views
>>> project
>>> (http://www.routeviews.org/) or a ro= ute indicating the presence of a
>>> web-server that is public.= =C2=A0 =C2=A0For the BGP I2RS route, a yang model could
>>> rep= lace the looking glass function, and provide events for these looking
&g= t;>> glass functions.=C2=A0 =C2=A0 For the web-server route,=C2=A0 an= event be sent when
> that
>>> one route is added.
>= ;>>
>>> Sue
>>>
>>>
>>&g= t; -----Original Message-----
>>> From: Juergen Schoenwaelder>>> [mailto:j.schoenwaelder@jacobs-university.de]
>= ;>> Sent: Thursday, August 18, 2016 3:32 AM
>>> To: Susan= Hares
>>> Cc: 'Kathleen Moriarty'; 'The IESG';= jhaas@pfrc.org; i2rs@ietf.org;
>= >> i2rs-cha= irs@ietf.org;
>>> draft-ietf-i2rs-protoco= l-security-requirements@ietf.org
>>> Subject: Re: [i2r= s] Kathleen Moriarty's Discuss on
>>> draft-ietf-i2rs-proto= col-security-requirements-07: (with DISCUSS and
>>> COMMEN= T)
>>>
>>> On Wed, Aug 17, 2016 at 09:16:48PM -0400= , Susan Hares wrote:
>>>> ------------------------------------------------------------------
>>>> --
>&g= t;>> --
>>>> COMMENT:
>>>> ------------= ------------------------------------------------------
>>= ;>> --
>>>> --
>>>>
>>>>= > Section 3:
>>>>> Can you clarify the second to last = sentence?=C2=A0 Do you mean there
>>>>> are
>>&g= t; sections that indicate an insecure transport should be used?
>>= >>>=C2=A0 I2RS allows the use of an
>>>>> insecu= re transport for portions of data models that clearly
>>>>&g= t; indicate=C2=A0 insecure transport.
>>>>
>>>&g= t;> Perhaps:
>>>>> I2RS allows the use of an
>&g= t;>>> insecure transport for portions of data models that clearly<= br>>>>>> indicate the use of an=C2=A0 insecure transport.>>>
>>> I still wonder how a data model writer can re= asonably decide whether
>>> a piece of information can be shipp= ed safely over an insecure
>>> transport since this decision of= ten depends on the specifics of a
>>> deployment
>> si= tuation.
>>>
>>> /js
>>>
>>>= ; PS: I hope we do not end up with defining data multiple times (once
&g= t;>>=C2=A0 =C2=A0 for insecure transport and once for secured transpo= rts).
>>>
>>> --
>>> Juergen Schoenwael= der=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Jacobs University Bremen gGmbH<= br>>>> Phone: +49 421 200 3587=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Ca= mpus Ring 1 | 28759 Bremen | Germany
>>> Fax:=C2=A0 =C2=A0+49 4= 21 200 3103=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<http://www.jacobs-university.de/<= /a>>
>>>
>>> ______________________________= _________________
>>> i2rs mailing list
>>> i2rs@ietf.org
>>&g= t; https://www.ietf.org/mailman/listinfo/i2rs
>>
>>= ; --
>> Juergen Schoenwaelder=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0Jacobs University Bremen gGmbH
>> Phone: +49 421 200 3587=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Campus Ring 1 | 28759 Bremen | Germany
&g= t;> Fax:=C2=A0 =C2=A0+49 421 200 3103=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0&= lt;http://ww= w.jacobs-university.de/>
>>
>> ______________= _________________________________
>> i2rs mailing list
>= ;> i2rs@ietf.org<= br>>> https://www.ietf.org/mailman/listinfo/i2rs
>>=
>
> --
> Juergen Schoenwaelder=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0Jacobs University Bremen gGmbH
> Phone: +49 421 200 = 3587=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Campus Ring 1 | 28759 Bremen | German= y
> Fax:=C2=A0 =C2=A0+49 421 200 3103=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0<http:= //www.jacobs-university.de/>
>


_______________= ________________________________
i2rs mailing list
i2rs@ietf.org
https://www.ietf.o= rg/mailman/listinfo/i2rs

=C2=A0


--001a11440bb674b0c6053a5f418b-- From nobody Fri Aug 19 04:02:36 2016 Return-Path: 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 5DEE212D771; Thu, 18 Aug 2016 15:10:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.147 X-Spam-Level: X-Spam-Status: No, score=-8.147 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.247] 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 exD_PST_VX11; Thu, 18 Aug 2016 15:10:31 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) (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 7176712D73A; Thu, 18 Aug 2016 15:10:31 -0700 (PDT) Received: from mbp.local ([IPv6:2601:647:4201:9e61:3d1e:d801:e85c:a5d0]) (authenticated bits=0) by nagasaki.bogus.com (8.15.2/8.15.2) with ESMTPSA id u7IMAL48090470 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT); Thu, 18 Aug 2016 22:10:21 GMT (envelope-from joelja@bogus.com) X-Authentication-Warning: nagasaki.bogus.com: Host [IPv6:2601:647:4201:9e61:3d1e:d801:e85c:a5d0] claimed to be mbp.local To: Susan Hares , "'Alissa Cooper'" , "'Joel Halpern'" References: <147146974235.23784.4389421535496134619.idtracker@ietfa.amsl.com> <013b01d1f8ee$31fa09b0$95ee1d10$@ndzh.com> <20160818073203.GA4338@elstar.local> <04b501d1f949$116c63e0$34452ba0$@ndzh.com> <20160818121405.GA5282@elstar.local> <051301d1f950$7739c670$65ad5350$@ndzh.com> <20160818130555.GA5366@elstar.local> <051701d1f952$c4ae0b30$4e0a2190$@ndzh.com> <6BCE198E4EAEFC4CAB45D75826EFB0761525CCD7@eusaamb101.ericsson.se> <010f01d1f98a$8c17ad20$a4470760$@ndzh.com> From: joel jaeggli Message-ID: <2d31e3aa-db61-aabd-334c-41874d2156a0@bogus.com> Date: Thu, 18 Aug 2016 15:10:20 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:47.0) Gecko/20100101 Thunderbird/47.0 MIME-Version: 1.0 In-Reply-To: <010f01d1f98a$8c17ad20$a4470760$@ndzh.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ILnHrRb9HWDiIHddH4NWrQ2f1qkhpTkvm" Archived-At: X-Mailman-Approved-At: Fri, 19 Aug 2016 04:02:24 -0700 Cc: i2rs@ietf.org, 'Juergen Schoenwaelder' , i2rs-chairs@ietf.org, 'Kathleen Moriarty' , 'IESG' , jhaas@pfrc.org, 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Aug 2016 22:10:34 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --ILnHrRb9HWDiIHddH4NWrQ2f1qkhpTkvm Content-Type: multipart/mixed; boundary="42mF0CVGNbSnu8v3WpT1U41UmAFrKPGok" From: joel jaeggli To: Susan Hares , 'Alissa Cooper' , 'Joel Halpern' Cc: i2rs@ietf.org, 'Juergen Schoenwaelder' , i2rs-chairs@ietf.org, 'Kathleen Moriarty' , 'IESG' , jhaas@pfrc.org, draft-ietf-i2rs-protocol-security-requirements@ietf.org Message-ID: <2d31e3aa-db61-aabd-334c-41874d2156a0@bogus.com> Subject: Re: [i2rs] Kathleen Moriarty's Discuss on draft-ietf-i2rs-protocol-security-requirements-07: (with DISCUSS and COMMENT) References: <147146974235.23784.4389421535496134619.idtracker@ietfa.amsl.com> <013b01d1f8ee$31fa09b0$95ee1d10$@ndzh.com> <20160818073203.GA4338@elstar.local> <04b501d1f949$116c63e0$34452ba0$@ndzh.com> <20160818121405.GA5282@elstar.local> <051301d1f950$7739c670$65ad5350$@ndzh.com> <20160818130555.GA5366@elstar.local> <051701d1f952$c4ae0b30$4e0a2190$@ndzh.com> <6BCE198E4EAEFC4CAB45D75826EFB0761525CCD7@eusaamb101.ericsson.se> <010f01d1f98a$8c17ad20$a4470760$@ndzh.com> In-Reply-To: <010f01d1f98a$8c17ad20$a4470760$@ndzh.com> --42mF0CVGNbSnu8v3WpT1U41UmAFrKPGok Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 8/18/16 12:56 PM, Susan Hares wrote: > Alissa:=20 > > A follow-up email on this topic. Joel suggests that I missing your que= stion. Are you asking who is in a position to determine that certain dat= a is reasonable to send unprotected? =20 > Are you asking if it is the operator, the data model designer, or our o= riginal WG designing the protocol?=20 > > If this is the case, the final authority is the owner of the data - the= operator. The closer the operator works with vendors who supply code a= nd standardize it, the better the vendors understand the need. It is hop= ed that the vendors and the operators will help I2RS or other WG to defin= e these data modules. We hope the security people from these operators a= nd security people from vendors and research will validate the security n= eeds. We believe we have a sense from the WG discussions on the categor= ies I mentioned: a) publically available data (route-views), b) events = specific to operators that are public, and c) interface/data that can be = seen publically (IXP ports or MEF exchange ports)=20 > > Personally, I also want to be very careful with any data that can be li= nked to a person. To me, this must be done over a secure transport. =20 > > Does this help? Like Joel - I am proactively answering you, but confus= ed on what you want me to change. =20 Another joel here, Conceptually an I2RS system resembles the distributed control and forwarding architecture of a large routers. Likewise is possible to conceive of router(s) where the I2RS architecture is the control plane. If it appropriate to carry controller-plane programming or accounting information around internally in such a system for reasons of convenience or performance then architects will probably do that. I don't see as desirable, exposing my distributed control-plane to the potential for information leakage or compromise when it's distributed across the internet, At the same time if it's a big sheetmetal box with 12 linecards and internal network stashed away in a VRF, or a bunch of software blobs running on the same machine, I might be inclined to treat them differently. Respecting SEC-REQ-09 I can imagine it being appropriate to do both at the same time with the same data to different clients > > Sue=20 > > -----Original Message----- > From: Alissa Cooper [mailto:alissa@cooperw.in]=20 > Sent: Thursday, August 18, 2016 12:54 PM > To: Joel Halpern > Cc: Susan Hares; Juergen Schoenwaelder; i2rs@ietf.org; i2rs-chairs@ietf= =2Eorg; Kathleen Moriarty; IESG; jhaas@pfrc.org; draft-ietf-i2rs-protocol= -security-requirements@ietf.org > Subject: Re: [i2rs] Kathleen Moriarty's Discuss on draft-ietf-i2rs-prot= ocol-security-requirements-07: (with DISCUSS and COMMENT) > > Jumping in here because this is relevant to my DISCUSS, hope nobody min= ds (but if you do, I can go back to the other thread). > >> On Aug 18, 2016, at 10:30 AM, Joel Halpern = wrote: >> >> Let me try a different take approach to this particular question. >> >> Let me start by putting aside the question of where things are marked,= and come back to that afterwards. >> >> There are a number of cases that I2RS has been asked to cover of high = rate telemetry data. This may be BGP update information, it may be frequ= ent information about line card activity. There are other cases, some of= which have been documented. >> >> While not completely insensitive, the operators have made clear that t= hey see protecting this data as unnecessary. While I would hope over tim= e to move to a domain where all of it is protect, that is not trivial. A= s the I2RS Architecture points out, it is expected that what we describe = as a single I2RS communication between a client and agent is actually ass= ociated with multiple channels of communication. >> >> Now, if you want to say that the I2RS protocol requirements cannot all= ow for unprotected channels, I guess we have disconnect between the IESG = and the WG. >> >> If we say that we can allow for unprotected channels, we then get to t= he question of which data can be sent over such channels. While architec= turally I agree with Juergen that the model is a bad place to specify it,= the obverse is also true. Not having some limits on what can be sent un= protected causes concern about insufficient protection. If I recall corr= ectly, earlier security reviews called us to task for being too broad in = what we allowed. >> >> So, if the IESG wants us to just allow it anywhere, because the model = is an awkward place to define the limitation, I can live with that. What= I can't live with is being told both that the model is a bad place to de= fine it and that there must be restrictions on what is sent unprotected, = without any proposal on how we are to move forward. > Thank you Joel, this explanation helps me a lot. I think there is a dis= connect about how the restrictions are expressed. From reading the email = traffic about this document, it strikes me that trying to express the res= trictions programmatically doesn=E2=80=99t make much sense in this case. = I agree with Juergen that it will be challenging to make a judgment a pri= ori in order to bake a restriction into a data model, because data that i= s considered sensitive enough to warrant a secure transport in one deploy= ment may not be considered sensitive in another deployment. So for any da= ta elements where there is any question at all about whether they might b= e sensitive (i.e., any data elements that are not already routinely made = public), I would expect data model authors to end up indicating that they= may be sent over either secure or insecure transport, which renders the = indication not useful. > > Perhaps it would make more sense then to just enumerate in the text the= cases that motivate the inclusion of protocol support for insecure trans= port: > > 1. For conveyance of information that is already routinely made public.= > 2. For line card activity data where there is no likely upgrade path to= support secure transports in the foreseeable future. > > Then the normative requirements would be on clients and agents to use s= ecure transports unless those clients and agents are deployed where eithe= r of the operational circumstances above necessitate otherwise. > > Alissa > >> Yours, >> Joel >> >> -----Original Message----- >> From: Susan Hares [mailto:shares@ndzh.com] >> Sent: Thursday, August 18, 2016 9:17 AM >> To: 'Juergen Schoenwaelder' >> Cc: i2rs@ietf.org; i2rs-chairs@ietf.org; 'Kathleen Moriarty'=20 >> ; 'The IESG' ;=20 >> jhaas@pfrc.org;=20 >> draft-ietf-i2rs-protocol-security-requirements@ietf.org >> Subject: RE: [i2rs] Kathleen Moriarty's Discuss on=20 >> draft-ietf-i2rs-protocol-security-requirements-07: (with DISCUSS and=20 >> COMMENT) >> >> Juergen and Kathleen:=20 >> >> Let me proceed with two examples: BGP route views data model and the e= vent for the web-service data. =20 >> >> The content of these data models are designated as exposed to public. = The routing system only populates the proposed BGP route views data mode= l with the data destined for the BGP looking glass. The policy on the ro= uting system indicates what information gets transferred. The data model= is completely available to the public. The Yang Doctors are going to re= view this by seeing the whole model is public and available via non-secur= e means. >> The security people are going to review this seeing that the whole mod= el is public, and available via an unprotect means. The fact the data mo= del is all public should simplify the review.=20 >> >> An event from the I2RS RIB that a web-service route is up is the secon= d case. The I2RS RIB has an event based on policy that indicates a web-s= ervice route is up. The yang-1.1 doctors must review the content of the = event text to see it does not break privacy or provide too much >> information The event mechanisms will need to work over secure trans= port >> and insecure transport. Most of the data will go over the secure tran= sport event stream. However, a small amount of information may go over th= e insecure transport stream.=20 >> >> First, let me know if my use cases are understandable. Second, let me= know if you disagree with this use cases.=20 >> >> Fyi - IESG approved the architecture with the insecure stream.=20 >> >> Sue >> >> -----Original Message----- >> From: Juergen Schoenwaelder=20 >> [mailto:j.schoenwaelder@jacobs-university.de] >> Sent: Thursday, August 18, 2016 9:06 AM >> To: Susan Hares >> Cc: i2rs@ietf.org; i2rs-chairs@ietf.org; 'Kathleen Moriarty'; 'The=20 >> IESG'; jhaas@pfrc.org;=20 >> 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) >> >> I just do not know on which basis a data model writer can decide wheth= er a data object can be exposed in an unprotected way. How are YANG docto= rs going to review this? How are security directorate people going to jud= ge this? But as promised, I leave (still puzzled) now. >> >> /js >> >> On Thu, Aug 18, 2016 at 09:00:14AM -0400, Susan Hares wrote: >>> Juergen:=20 >>> >>> Yes, we seem to disagree on the value of making it hardwired in the m= odel. >>> For me, the value is a common understanding of deployment=20 >>> distribution >> such >>> as the route-views. Since the operators argued strongly for this po= int, >> I >>> think the best idea is to get it working in code and then see if the = >>> deployment matches the requests. >>> >>> Sue >>> >>> -----Original Message----- >>> From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Juergen=20 >>> Schoenwaelder >>> Sent: Thursday, August 18, 2016 8:14 AM >>> To: Susan Hares >>> Cc: i2rs@ietf.org; i2rs-chairs@ietf.org; 'Kathleen Moriarty'; 'The=20 >>> IESG'; jhaas@pfrc.org;=20 >>> 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) >>> >>> Sue, >>> >>> I still do not see why the 'mode of exposure' of data benefits from=20 >>> being hard-wired in the data model. For me, it is a situational and=20 >>> deployment specific question. But I shut up here since I aired this=20 >>> concern before (and we simply seem to disagree). >>> >>> /js >>> >>> On Thu, Aug 18, 2016 at 08:07:18AM -0400, Susan Hares wrote: >>>> Juergen:=20 >>>> >>>> My example is the looking glass servers for the BGP route views=20 >>>> project >>>> (http://www.routeviews.org/) or a route indicating the presence of a= >>>> web-server that is public. For the BGP I2RS route, a yang model co= uld >>>> replace the looking glass function, and provide events for these loo= king >>>> glass functions. For the web-server route, an event be sent when= >> that >>>> one route is added. =20 >>>> >>>> Sue >>>> >>>> >>>> -----Original Message----- >>>> From: Juergen Schoenwaelder >>>> [mailto:j.schoenwaelder@jacobs-university.de] >>>> Sent: Thursday, August 18, 2016 3:32 AM >>>> To: Susan Hares >>>> Cc: 'Kathleen Moriarty'; 'The IESG'; jhaas@pfrc.org; i2rs@ietf.org; = >>>> i2rs-chairs@ietf.org;=20 >>>> 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 Wed, Aug 17, 2016 at 09:16:48PM -0400, Susan Hares wrote: >>>>> ------------------------------------------------------------------ >>>>> -- >>>>> -- >>>>> COMMENT: >>>>> ------------------------------------------------------------------ >>>>> -- >>>>> -- >>>>> >>>>>> Section 3:=20 >>>>>> Can you clarify the second to last sentence? Do you mean there=20 >>>>>> are >>>> sections that indicate an insecure transport should be used? >>>>>> I2RS allows the use of an >>>>>> insecure transport for portions of data models that clearly=20 >>>>>> indicate insecure transport. >>>>>> Perhaps: >>>>>> I2RS allows the use of an >>>>>> insecure transport for portions of data models that clearly=20 >>>>>> indicate the use of an insecure transport. >>>> I still wonder how a data model writer can reasonably decide whether= =20 >>>> a piece of information can be shipped safely over an insecure=20 >>>> transport since this decision often depends on the specifics of a=20 >>>> deployment >>> situation. >>>> /js >>>> >>>> PS: I hope we do not end up with defining data multiple times (once >>>> for insecure transport and once for secured transports). >>>> >>>> --=20 >>>> Juergen Schoenwaelder Jacobs University Bremen gGmbH >>>> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germa= ny >>>> Fax: +49 421 200 3103 >>>> >>>> _______________________________________________ >>>> i2rs mailing list >>>> i2rs@ietf.org >>>> https://www.ietf.org/mailman/listinfo/i2rs >>> --=20 >>> Juergen Schoenwaelder Jacobs University Bremen gGmbH >>> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | German= y >>> Fax: +49 421 200 3103 >>> >>> _______________________________________________ >>> i2rs mailing list >>> i2rs@ietf.org >>> https://www.ietf.org/mailman/listinfo/i2rs >>> >> --=20 >> Juergen Schoenwaelder Jacobs University Bremen gGmbH >> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany= >> Fax: +49 421 200 3103 >> > > --42mF0CVGNbSnu8v3WpT1U41UmAFrKPGok-- --ILnHrRb9HWDiIHddH4NWrQ2f1qkhpTkvm Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2 Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAle2Mk0ACgkQ8AA1q7Z/VrIf0QCdEUvCK5gvj0TNggIaa6FmTWp5 decAniuKm0Y2+5dRjokVtYb+XsrdTqx2 =p+6f -----END PGP SIGNATURE----- --ILnHrRb9HWDiIHddH4NWrQ2f1qkhpTkvm-- From nobody Fri Aug 19 04:02:50 2016 Return-Path: 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 28EF412D0FE; Thu, 18 Aug 2016 17:47:10 -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 oRnb-_Y61V9e; Thu, 18 Aug 2016 17:47:06 -0700 (PDT) Received: from mail-ua0-x231.google.com (mail-ua0-x231.google.com [IPv6:2607:f8b0:400c:c08::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 6C11A12D5C6; Thu, 18 Aug 2016 17:47:04 -0700 (PDT) Received: by mail-ua0-x231.google.com with SMTP id k90so56045128uak.1; Thu, 18 Aug 2016 17:47:04 -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=qsNcdqWAERUYoyjtjdQxfU5sf/Z5e11+FV+//SsGooM=; b=pV7KDRF4lT6PlhjV/OuhJmNpaDPmXHz2fqGFojQa4WMcpghNFvDj/Ed4srJ0inXoy9 LBrucj0UD7gBX7/o75Cbq2UyxO6SVnM77I9SMPjiGq4L1dFslHz+gwKEUyAeZLqzlLo4 iO7pG1GH5/ChkVgbHTznUTa6Gc3/h4rsmQB1yMXzDxN3D2Hm9jAD9Q4VVQj+7lT3oAw2 xYyUELP0wzjsSlxj6UcMcytddMRAI7tSK/JimKLXuP/ler5AqyeWo0n9wbotorWw3hWi T+s+M1+zwPpdkvGi3jndULuVLtKDkSMlNOIX1U/fR24MIqqp5gkELntfYqNcszmCkImo AIdg== 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=qsNcdqWAERUYoyjtjdQxfU5sf/Z5e11+FV+//SsGooM=; b=lVrXi/dS6d+J/OpNWm84qHfvSYPDAhtRJkoUC6TYwxaBMDCGbJ9zZwieSGN7TOHD6E Ep3wrxVh2e7L8oG67ceGzh+X/3hdQ/VBnYbJSYDlPCN8uJVBlvz7CnPQYiI11rYnf0VE 9mGs3R6IZxa+TusIuOyiR+oTHB2OJpbym8Dz45JrlEEU/XxZYbH0EeCQoUzZkk2d6M2R dnyjru6VXxKPKVLgB9uZ/4k+qAcYxjlQzGe9Kg6MMOeFdMCGqzYbeNzpwGHB0Sx6Vk/9 QyCMZqh5krSobFP+TpifFsy+l2mv7jve1ca1MGUbY0F+Umjs2v2GU89jj1DZnS4Mgj4F 1/lw== X-Gm-Message-State: AEkoous+CRi1oT1PraMEIS/z0y22xfJNuaCxN0Ec5MyHBSuxm8Qli8dU9hNs576ixAt4RwfF2uC7KxEa+BpntA== X-Received: by 10.31.110.65 with SMTP id j62mr2646182vkc.81.1471567623293; Thu, 18 Aug 2016 17:47:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.1.228 with HTTP; Thu, 18 Aug 2016 17:47:02 -0700 (PDT) In-Reply-To: <012e01d1f98b$ec9d09a0$c5d71ce0$@ndzh.com> References: <147146974235.23784.4389421535496134619.idtracker@ietfa.amsl.com> <013b01d1f8ee$31fa09b0$95ee1d10$@ndzh.com> <20160818073203.GA4338@elstar.local> <04b501d1f949$116c63e0$34452ba0$@ndzh.com> <20160818121405.GA5282@elstar.local> <051301d1f950$7739c670$65ad5350$@ndzh.com> <20160818130555.GA5366@elstar.local> <051701d1f952$c4ae0b30$4e0a2190$@ndzh.com> <6BCE198E4EAEFC4CAB45D75826EFB0761525CCD7@eusaamb101.ericsson.se> <003801d1f97f$3d16eb10$b744c130$@ndzh.com> <00dc01d1f988$f2cec280$d86c4780$@ndzh.com> <012e01d1f98b$ec9d09a0$c5d71ce0$@ndzh.com> From: Kathleen Moriarty Date: Thu, 18 Aug 2016 20:47:02 -0400 Message-ID: To: Susan Hares Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: X-Mailman-Approved-At: Fri, 19 Aug 2016 04:02:24 -0700 Cc: i2rs@ietf.org, Alissa Cooper , Juergen Schoenwaelder , Andy Bierman , 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) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Aug 2016 00:47:10 -0000 I think there are some easy tweaks that could make everyone happy. We should be focusing on MTI, not MTU for requirements so that operators can make decisions as needed. I think we can all agree with that statement. We are worried about a few areas of text in the document, namely where the data model can trigger the use of an insecure transport. The default is a secure transport for the protocol, so that is MTI across the board. One of the sections that causes concern is the following: Section 3: (I think the latest proposed text) I2RS allows the use of an insecure transport for portions of data models that clearly indicate the use of an insecure transport. Operators deploying I2RS must determine if they want to populate and deploy the portions of the data model which use insecure transports. Which doesn't exactly meet the stated requirement in Section 3.2: In Section 3.2 in version -08.txt SEC-REQ-08: The I2RS protocol MUST be able to transfer data over a secure transport and optionally MAY be able to transfer data over a non-secure transport. A secure transport MUST provide data confidentiality, data integrity, and replay prevention. I think if we reword the text in section 3 as follows, the requirement for support of a secure transport will be clear, a way to mark the data model for the possible use of insecure transport is possible (decision of the operator). How about: I2RS allows the use of an insecure transport for portions of data models that clearly indicate data confidentiality and integrity protection may not be necessary. Operators deploying I2RS must determine if they want to populate and deploy the portions of the data model with a configuration option to use insecure transports. I understand this changes your requirements a bit and your implementation, but is this a way that we could allow some operators to operate in a secure mode for this data if they choose and also allow MTU to be less than the default? If that's agreeable - with the other ADs too - then some more text in section 3.2 needs to be tweaked in a similar way. The text in section 3.2 is closer to what I am proposing, you have the sent= ence: 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. This talks about the data being marked in terms of a need for confidentiality (should be integrity too as I could corrupt a clear text stream in a way that is not detectable) instead of explicitly stating that the transport should be insecure. If the data model had a attribute that had this marking (operator driven), I think that's an improvement. How about: A non-secure transport can be used for publishing telemetry data or other operational state that was specifically indicated as non- confidential and does not require integrity protection through an option provided in the data model. I think this text allows for the WG goal of using a data model to indicate the transport option, but for it to be an operator driven decision in case some operators prefer to use transport encryption for this section of the data model... or things change and they all decide this is a good idea. I'll get back to the other responses to my comments and discuss in a separate message (possibly tomorrow). If this alters discussions from other threads, please point me to the thread and I'll catch up. Thanks, Kathleen On Thu, Aug 18, 2016 at 4:05 PM, Susan Hares wrote: > Andy: > > > > If we create a yang data model that is insecure, and mount on another dat= a > model =E2=80=93 does it have the same issue as module augmentation? Of = course, we > could create a mount point for all insecure data modules, and all data > placed under that mount point =E2=80=93 would be insecure. > > > > For the BGP route-views use case, this would make it clear that data had = to > be transformed to be insecure transmission. > > > > Sue > > > > From: Andy Bierman [mailto:andy@yumaworks.com] > Sent: Thursday, August 18, 2016 4:02 PM > > > To: Susan Hares > Cc: Alissa Cooper; Joel Halpern; i2rs@ietf.org; Juergen Schoenwaelder; > i2rs-chairs@ietf.org; Kathleen Moriarty; IESG; Jeffrey Haas; > 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 Thu, Aug 18, 2016 at 12:44 PM, Susan Hares wrote: > > Andy: > > > > Thank you =E2=80=93 I thought it was on whether we could implement insecu= re > transport in a Yang module. > > > > The requirement text you are working with is: > > > > SEC-REQ-08: The I2RS protocol MUST be able to transfer data over a > secure transport and optionally MAY be able to transfer data over a > non-secure transport. > > > > I do not understand why approving the ok for non-secure transport for som= e > modules means the following to you: > > > > =E2=80=9C the IETF needs to agree that there could never possibly be any = deployment > that would not want to allow exposure of the data. > > Not now. Not 20 years from now.=E2=80=9D > > > > > > > > As I understand it, this requirement has another requirement associated w= ith > it > > that says the data has to be identified as OK-for-nonsecure-transport. > > > > An extension in the data model says that all instances of the object in > > all possible deployments cannot be considered sensistive and therefore > > needs disclosure protection. > > > > It may seem like even a simple octet counter is safe to send in the clear= , > > but not if that opens up correlation attacks. (e.g., I can send data to > some > > host. I can see that index 455992 is incrementing the in-octets counters > > in a way that strongly correlates to my test traffic. Therefore I can le= arn > > that arbitrary index 455992 is really John Doe or really suite #14, etc. > > > > > > I had thought that the security-directorate and other reviewers would loo= k > at each module that is insecure, and consider whether it was reasonable = for > the use case at this time. This is what I understood from Russ Housley= =E2=80=99s > first review of this technology. Since like you, I believe the operator = is > going to configure what modules are allowed on systems. I agree that t= his > requirement provides a full scope of the work, but implementers will requ= ire > network operators to configure these features on. > > > > Sue > > > > Andy > > > > > > > > From: Andy Bierman [mailto:andy@yumaworks.com] > Sent: Thursday, August 18, 2016 2:53 PM > To: Susan Hares > Cc: Alissa Cooper; Joel Halpern; i2rs@ietf.org; Juergen Schoenwaelder; > i2rs-chairs@ietf.org; Kathleen Moriarty; IESG; Jeffrey Haas; > 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) > > > > Hi, > > > > I did not think Juergen's comment was about running code. > > > > In order for a data node to get the "ok-for-nonsecure-transports" approva= l > > in an IETF module, the IETF needs to agree that there could never possibl= y > be > > any deployment that would not want to allow exposure of the data. > > Not now. Not 20 years from now. > > > > I can see a vendor making that decision for their own proprietary modules= , > > but it seems less likely for standard modules. > > > > Seems like the operator is going to have to configure what is allowed > > for nonsecure transport anyway, so just let them decide. > > I don't really object to the extension or the requirement. > > It doesn't help much but it doesn't hurt much either. > > > > > > Andy > > > > > > > > On Thu, Aug 18, 2016 at 11:35 AM, Susan Hares wrote: > > Alissa: > > Just a little input you may not know. My background is 15 years (1995-20= 10) > developing a routing/switching platform (denoted as GateD) which was sold= to > over 200 companies. We developed XML and a binary XML based product tha= t > configured this product. It could do 100K configuration lines and reboot= in > less than a second on most hardware. We also provide status messages in > secure streams and non-secure streams. I sold early version of this co= de > to companies that Alia has worked for - so she has personal viewed the > code. At the height of our work, our development team ran to 50 people > which I directed (First as VP of Engineering, and then as CTO). It is due= to > this level of experience that Alia selected me for the co-chair. Russ > White has understood Cisco's process, and has also directed software > development teams for routing. > > In order to freshen my direct experience with I2RS on open source work, I= am > working on a publically available work in Quagga based on the confD produ= ct > suggested by Cisco. > > In contrast, Juergen is a university professor who has worked on > proto-types. He is not working on an implementation. I hope he will. > > I hope you will consider this background in my response to your comments > below. > > Sue > > > -----Original Message----- > From: Alissa Cooper [mailto:alissa@cooperw.in] > Sent: Thursday, August 18, 2016 12:54 PM > To: Joel Halpern > Cc: Susan Hares; Juergen Schoenwaelder; i2rs@ietf.org; i2rs-chairs@ietf.o= rg; > Kathleen Moriarty; IESG; jhaas@pfrc.org; > 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) > > Jumping in here because this is relevant to my DISCUSS, hope nobody minds > (but if you do, I can go back to the other thread). > >>> On Aug 18, 2016, at 10:30 AM, Joel Halpern >>> wrote: >>> >>> Let me try a different take approach to this particular question. >>> >>> Let me start by putting aside the question of where things are marked, >>> and come back to that afterwards. >>> >>> There are a number of cases that I2RS has been asked to cover of high >>> rate telemetry data. This may be BGP update information, it may be fre= quent >>> information about line card activity. There are other cases, some of w= hich >>> have been documented. >>> >>> While not completely insensitive, the operators have made clear that th= ey >>> see protecting this data as unnecessary. While I would hope over time = to >>> move to a domain where all of it is protect, that is not trivial. As t= he >>> I2RS Architecture points out, it is expected that what we describe as a >>> single I2RS >communication between a client and agent is actually assoc= iated >>> with multiple channels of communication. >>> >>> Now, if you want to say that the I2RS protocol requirements cannot allo= w >>> for unprotected channels, I guess we have disconnect between the IESG a= nd >>> the WG. >>> >>> If we say that we can allow for unprotected channels, we then get to th= e >>> question of which data can be sent over such channels. While >>> architecturally I agree with Juergen that the model is a bad place to >>> specify it, the obverse is also true. Not having some limits on what c= an be >>> sent unprotected >causes concern about insufficient protection. If I r= ecall >>> correctly, earlier security reviews called us to task for being too bro= ad in >>> what we allowed. >>> >>> So, if the IESG wants us to just allow it anywhere, because the model i= s >>> an awkward place to define the limitation, I can live with that. What = I >>> can't live with is being told both that the model is a bad place to def= ine >>> it and that there must be restrictions on what is sent unprotected, >>> without any proposal on how we are to move forward. > >> Thank you Joel, this explanation helps me a lot. I think there is a >> disconnect about how the restrictions are expressed. From reading the em= ail >> traffic about this document, it strikes me that trying to express the >> restrictions programmatically doesn=E2=80=99t make much sense in this ca= se. >> I agree with Juergen that it will be challenging to make a judgment a >> priori in order to bake a restriction into a data model, because data th= at >> is considered sensitive enough to warrant a secure transport in one >> deployment may not be considered sensitive in another deployment. >> So for any data elements where there is any question at all about whethe= r >> they might be sensitive (i.e., any data elements that are not already >> routinely made public), >> I would expect data model authors to end up indicating that they may be >> sent over either secure or insecure transport, which renders the indicat= ion >> not useful. >> Perhaps it would make more sense then to just enumerate in the text the >> cases that motivate the inclusion of protocol support for insecure >> transport: >> >> 1. For conveyance of information that is already routinely made public. >> 2. For line card activity data where there is no likely upgrade path to >> support secure transports in the foreseeable future. >> >> Then the normative requirements would be on clients and agents to use >> secure transports unless those clients and agents are deployed where eit= her >> of the operational circumstances above necessitate otherwise. >> Alissa > > Point 1: > I disagree with Juergen on the difficulty in specifying the sections of t= he > yang modules. I have provided a suggested solution in: > https://tools.ietf.org/html/draft-hares-i2rs-protocol-strawman-03#section= -4.5.2. > > Given the mount schema functionality, we can mount ephemeral state module > which augment non-ephemeral state modules which are "in-secure only". > > Point 2: > I am willing to put an enumeration of the use cases in the protocol > requirement, but I would like to understand the purpose for the enumerati= on. > We are not doing a use case, but a requirements document. This informati= on > appears to be a "use case" rather than a technical description. What > purpose are you looking for this enumeration to server. Are you looking = for > the enumeration in SEC-REQ-08? > > Point 3: Could you review -08.txt on this topic, especially the text belo= w. > Given your comments, I believe I should change the last line to a MUST. > New/ The default mode of transport is > secure so data models MUST clearly annotate what data nodes can be > passed over an insecure connection. > / > > Sue > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > As to the normative requirements (-08.txt) version: > > Section 3: > > I2RS allows the use of an insecure transport for portions of data > models that clearly indicate the use of an insecure transport. > Operators deploying I2RS must determine if they want to populate and > deploy the portions of the data model which use insecure transports. > > In Section 3.2 in version -08.txt > > SEC-REQ-08: The I2RS protocol MUST be able to transfer data over a > secure transport and optionally MAY be able to transfer data over a > non-secure transport. A secure transport MUST provide data > confidentiality, data integrity, and replay prevention. > > The default I2RS transport is a secure transport. > > 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. > > The configuration of ephemeral data in the I2RS Agent by the I2RS > client SHOULD be done over a secure transport. It is anticipated > that the passing of most I2RS ephemeral state operational status > SHOULD be done over a secure transport. As > [I-D.ietf-i2rs-ephemeral-state] notes, a data model MUST indicate > whether the transport exchanging the data between I2RS client and > I2RS agent is secure or insecure. > > The default mode of transport is > secure so data models SHOULD clearly annotate what data nodes can be > passed over an insecure connection. > >> >> Yours, >> Joel >> >> -----Original Message----- >> From: Susan Hares [mailto:shares@ndzh.com] >> Sent: Thursday, August 18, 2016 9:17 AM >> To: 'Juergen Schoenwaelder' >> Cc: i2rs@ietf.org; i2rs-chairs@ietf.org; 'Kathleen Moriarty' >> ; 'The IESG' ; >> jhaas@pfrc.org; >> 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) >> >> Juergen and Kathleen: >> >> Let me proceed with two examples: BGP route views data model and the eve= nt >> for the web-service data. >> >> The content of these data models are designated as exposed to public. T= he >> routing system only populates the proposed BGP route views data model wi= th >> the data destined for the BGP looking glass. The policy on the routing >> system indicates what information gets transferred. The data model is >> completely available to the public. The Yang Doctors are going to revie= w >> this by seeing the whole model is public and available via non-secure me= ans. >> The security people are going to review this seeing that the whole model >> is public, and available via an unprotect means. The fact the data mode= l is >> all public should simplify the review. >> >> An event from the I2RS RIB that a web-service route is up is the second >> case. The I2RS RIB has an event based on policy that indicates a >> web-service route is up. The yang-1.1 doctors must review the content o= f >> the event text to see it does not break privacy or provide too much >> information The event mechanisms will need to work over secure transpo= rt >> and insecure transport. Most of the data will go over the secure >> transport event stream. However, a small amount of information may go ov= er >> the insecure transport stream. >> >> First, let me know if my use cases are understandable. Second, let me >> know if you disagree with this use cases. >> >> Fyi - IESG approved the architecture with the insecure stream. >> >> Sue >> >> -----Original Message----- >> From: Juergen Schoenwaelder >> [mailto:j.schoenwaelder@jacobs-university.de] >> Sent: Thursday, August 18, 2016 9:06 AM >> To: Susan Hares >> Cc: i2rs@ietf.org; i2rs-chairs@ietf.org; 'Kathleen Moriarty'; 'The >> IESG'; jhaas@pfrc.org; >> 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) >> >> I just do not know on which basis a data model writer can decide whether= a >> data object can be exposed in an unprotected way. How are YANG doctors g= oing >> to review this? How are security directorate people going to judge this?= But >> as promised, I leave (still puzzled) now. >> >> /js >> >> On Thu, Aug 18, 2016 at 09:00:14AM -0400, Susan Hares wrote: >>> Juergen: >>> >>> Yes, we seem to disagree on the value of making it hardwired in the >>> model. >>> For me, the value is a common understanding of deployment >>> distribution >> such >>> as the route-views. Since the operators argued strongly for this poin= t, >> I >>> think the best idea is to get it working in code and then see if the >>> deployment matches the requests. >>> >>> Sue >>> >>> -----Original Message----- >>> From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Juergen >>> Schoenwaelder >>> Sent: Thursday, August 18, 2016 8:14 AM >>> To: Susan Hares >>> Cc: i2rs@ietf.org; i2rs-chairs@ietf.org; 'Kathleen Moriarty'; 'The >>> IESG'; jhaas@pfrc.org; >>> 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) >>> >>> Sue, >>> >>> I still do not see why the 'mode of exposure' of data benefits from >>> being hard-wired in the data model. For me, it is a situational and >>> deployment specific question. But I shut up here since I aired this >>> concern before (and we simply seem to disagree). >>> >>> /js >>> >>> On Thu, Aug 18, 2016 at 08:07:18AM -0400, Susan Hares wrote: >>>> Juergen: >>>> >>>> My example is the looking glass servers for the BGP route views >>>> project >>>> (http://www.routeviews.org/) or a route indicating the presence of a >>>> web-server that is public. For the BGP I2RS route, a yang model coul= d >>>> replace the looking glass function, and provide events for these looki= ng >>>> glass functions. For the web-server route, an event be sent when >> that >>>> one route is added. >>>> >>>> Sue >>>> >>>> >>>> -----Original Message----- >>>> From: Juergen Schoenwaelder >>>> [mailto:j.schoenwaelder@jacobs-university.de] >>>> Sent: Thursday, August 18, 2016 3:32 AM >>>> To: Susan Hares >>>> Cc: 'Kathleen Moriarty'; 'The IESG'; jhaas@pfrc.org; i2rs@ietf.org; >>>> i2rs-chairs@ietf.org; >>>> 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 Wed, Aug 17, 2016 at 09:16:48PM -0400, Susan Hares wrote: >>>>> ------------------------------------------------------------------ >>>>> -- >>>>> -- >>>>> COMMENT: >>>>> ------------------------------------------------------------------ >>>>> -- >>>>> -- >>>>> >>>>>> Section 3: >>>>>> Can you clarify the second to last sentence? Do you mean there >>>>>> are >>>> sections that indicate an insecure transport should be used? >>>>>> I2RS allows the use of an >>>>>> insecure transport for portions of data models that clearly >>>>>> indicate insecure transport. >>>>> >>>>>> Perhaps: >>>>>> I2RS allows the use of an >>>>>> insecure transport for portions of data models that clearly >>>>>> indicate the use of an insecure transport. >>>> >>>> I still wonder how a data model writer can reasonably decide whether >>>> a piece of information can be shipped safely over an insecure >>>> transport since this decision often depends on the specifics of a >>>> deployment >>> situation. >>>> >>>> /js >>>> >>>> PS: I hope we do not end up with defining data multiple times (once >>>> for insecure transport and once for secured transports). >>>> >>>> -- >>>> Juergen Schoenwaelder Jacobs University Bremen gGmbH >>>> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany >>>> Fax: +49 421 200 3103 >>>> >>>> _______________________________________________ >>>> i2rs mailing list >>>> i2rs@ietf.org >>>> https://www.ietf.org/mailman/listinfo/i2rs >>> >>> -- >>> Juergen Schoenwaelder Jacobs University Bremen gGmbH >>> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany >>> Fax: +49 421 200 3103 >>> >>> _______________________________________________ >>> i2rs mailing list >>> i2rs@ietf.org >>> https://www.ietf.org/mailman/listinfo/i2rs >>> >> >> -- >> Juergen Schoenwaelder Jacobs University Bremen gGmbH >> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany >> Fax: +49 421 200 3103 >> > > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs > > > > --=20 Best regards, Kathleen From nobody Fri Aug 19 04:51:08 2016 Return-Path: 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 7750312DEC1; Fri, 19 Aug 2016 04:51:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.738 X-Spam-Level: * X-Spam-Status: No, score=1.738 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, RDNS_NONE=0.793] autolearn=no 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 RyLsjtzosI5Z; Fri, 19 Aug 2016 04:50:57 -0700 (PDT) Received: from hickoryhill-consulting.com (unknown [50.245.122.97]) (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 6F09D12DEB8; Fri, 19 Aug 2016 04:50:57 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=184.157.82.170; From: "Susan Hares" To: , "'Juergen Schoenwaelder'" References: <013b01d1f8ee$31fa09b0$95ee1d10$@ndzh.com> <20160818073203.GA4338@elstar.local> <04b501d1f949$116c63e0$34452ba0$@ndzh.com> <20160818121405.GA5282@elstar.local> <051301d1f950$7739c670$65ad5350$@ndzh.com> <20160818130555.GA5366@elstar.local> <051701d1f952$c4ae0b30$4e0a2190$@ndzh.com> <6BCE198E4EAEFC4CAB45D75826EFB0761525CCD7@eusaamb101.ericsson.se> <003801d1f97f$3d16eb10$b744c130$@ndzh.com> <20160819085756.GA6759@elstar.local> <7F7EDE0F-792A-4292-9FE1-B31BC4AE40BB@gmail.com> In-Reply-To: <7F7EDE0F-792A-4292-9FE1-B31BC4AE40BB@gmail.com> Date: Fri, 19 Aug 2016 07:49:40 -0400 Message-ID: <026e01d1fa0f$c54f7f70$4fee7e50$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJ/RF5y8kBC7R3sO+auWKe566R2lwEcb/3KAg+ndAACAypBUwGJSPf4Amiv8FwDJLAGjQJqExQkAqfTovACEJToAwFDCzFbAU1UlTCeRc4oYA== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: i2rs@ietf.org, 'Alissa Cooper' , i2rs-chairs@ietf.org, 'IESG' , jhaas@pfrc.org, '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) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Aug 2016 11:51:00 -0000 Kathleen:=20 The intent of the text is the following:=20 1) operators have a configuration knob that sets non-secure transport or = secure transport for portions of data model marked as non-secure.=20 The operators always have the choice to use secure transport. Some = operators have indicated they will always use secure transport.,=20 =20 2) The data model are clearly marked with the sections of the data = model that can be sent over non-secure transport. =20 The WG does not want configuration to be sent or some operational = state to be sent over a non-secure transport.=20 The WG is more restrictive than your comment. I would prefer to keep = this restriction. =20 I realize that Juergen does not want to mark the data models. He's = repeated this viewpoint for 3 years. His viewpoint was declared in the = "rough" in the I2RS Consensus. The I2RS WG is setting requirements for = the NETCONF/NETMOD WG. =20 It is the IESG choice to say to the I2RS WG that their opinion is in the = rough, and provide technical reasons why.=20 Sue=20 -----Original Message----- From: kathleen.moriarty.ietf@gmail.com = [mailto:kathleen.moriarty.ietf@gmail.com]=20 Sent: Friday, August 19, 2016 6:47 AM To: Juergen Schoenwaelder Cc: Susan Hares; Alissa Cooper; Joel Halpern; i2rs@ietf.org; = i2rs-chairs@ietf.org; IESG; jhaas@pfrc.org; = 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) Sent from my iPhone > On Aug 19, 2016, at 4:57 AM, Juergen Schoenwaelder = wrote: >=20 > I repeat my technical argument: While there may be deployments where=20 > non-secure transports may be reasonable to use, defining these=20 > situations statically as part of data model schemas does not follow=20 > established practices. The IETF has a long tradition of standardizing=20 > data models that can be used in a variety of operational contexts and=20 > I do not see reasons why we should move away from that basic approach. What I proposed just adds a trigger so operators can make that decision = and can automate it. This isn't new for IETF protocols. I'm proposing = this since it seems it was a working group decision to allow for = automation. Is that not the case? Kathleen=20 >=20 > /js >=20 >> On Thu, Aug 18, 2016 at 02:35:03PM -0400, Susan Hares wrote: >> Alissa:=20 >>=20 >> Just a little input you may not know. My background is 15 years = (1995-2010) developing a routing/switching platform (denoted as GateD) = which was sold to over 200 companies. We developed XML and a binary = XML based product that configured this product. It could do 100K = configuration lines and reboot in less than a second on most hardware. = We also provide status messages in secure streams and non-secure = streams. I sold early version of this code to companies that Alia has = worked for - so she has personal viewed the code. At the height of = our work, our development team ran to 50 people which I directed (First = as VP of Engineering, and then as CTO). It is due to this level of = experience that Alia selected me for the co-chair. Russ White has = understood Cisco's process, and has also directed software development = teams for routing.=20 >>=20 >> In order to freshen my direct experience with I2RS on open source = work, I am working on a publically available work in Quagga based on the = confD product suggested by Cisco.=20 >>=20 >> In contrast, Juergen is a university professor who has worked on = proto-types. He is not working on an implementation. I hope he will. = >>=20 >> I hope you will consider this background in my response to your = comments below.=20 >>=20 >> Sue >>=20 >>=20 >> -----Original Message----- >> From: Alissa Cooper [mailto:alissa@cooperw.in] >> Sent: Thursday, August 18, 2016 12:54 PM >> To: Joel Halpern >> Cc: Susan Hares; Juergen Schoenwaelder; i2rs@ietf.org;=20 >> i2rs-chairs@ietf.org; Kathleen Moriarty; IESG; jhaas@pfrc.org;=20 >> draft-ietf-i2rs-protocol-security-requirements@ietf.org >> Subject: Re: [i2rs] Kathleen Moriarty's Discuss on=20 >> draft-ietf-i2rs-protocol-security-requirements-07: (with DISCUSS and=20 >> COMMENT) >>=20 >> Jumping in here because this is relevant to my DISCUSS, hope nobody = minds (but if you do, I can go back to the other thread). >>=20 >>>> On Aug 18, 2016, at 10:30 AM, Joel Halpern = wrote: >>>>=20 >>>> Let me try a different take approach to this particular question. >>>>=20 >>>> Let me start by putting aside the question of where things are = marked, and come back to that afterwards. >>>>=20 >>>> There are a number of cases that I2RS has been asked to cover of = high rate telemetry data. This may be BGP update information, it may be = frequent information about line card activity. There are other cases, = some of which have been documented. >>>>=20 >>>> While not completely insensitive, the operators have made clear = that they see protecting this data as unnecessary. While I would hope = over time to move to a domain where all of it is protect, that is not = trivial. As the I2RS Architecture points out, it is expected that what = we describe as a single I2RS >communication between a client and agent = is actually associated with multiple channels of communication. >>>>=20 >>>> Now, if you want to say that the I2RS protocol requirements cannot = allow for unprotected channels, I guess we have disconnect between the = IESG and the WG. >>>>=20 >>>> If we say that we can allow for unprotected channels, we then get = to the question of which data can be sent over such channels. While = architecturally I agree with Juergen that the model is a bad place to = specify it, the obverse is also true. Not having some limits on what = can be sent unprotected >causes concern about insufficient protection. = If I recall correctly, earlier security reviews called us to task for = being too broad in what we allowed. >>>>=20 >>>> So, if the IESG wants us to just allow it anywhere, because the=20 >>>> model is an awkward place to define the limitation, I can live with = that. What I can't live with is being told both that the model is a bad = place to define it and that there must be restrictions on what is sent = unprotected, without any proposal on how we are to move forward. >>=20 >>> Thank you Joel, this explanation helps me a lot. I think there is a = disconnect about how the restrictions are expressed. From reading the = email traffic about this document, it strikes me that trying to express = the restrictions programmatically doesn=E2=80=99t make much sense in = this case.=20 >>> I agree with Juergen that it will be challenging to make a judgment = a priori in order to bake a restriction into a data model, because data = that is considered sensitive enough to warrant a secure transport in one = deployment may not be considered sensitive in another deployment.=20 >>> So for any data elements where there is any question at all about=20 >>> whether they might be sensitive (i.e., any data elements that are = not already routinely made public), I would expect data model authors to = end up indicating that they may be sent over either secure or insecure = transport, which renders the indication not useful. >>> Perhaps it would make more sense then to just enumerate in the text = the cases that motivate the inclusion of protocol support for insecure = transport: >>>=20 >>> 1. For conveyance of information that is already routinely made = public. >>> 2. For line card activity data where there is no likely upgrade path = to support secure transports in the foreseeable future. >>>=20 >>> Then the normative requirements would be on clients and agents to = use secure transports unless those clients and agents are deployed where = either of the operational circumstances above necessitate otherwise. >>> Alissa >>=20 >> Point 1:=20 >> I disagree with Juergen on the difficulty in specifying the sections = of the yang modules. I have provided a suggested solution in:=20 >> = https://tools.ietf.org/html/draft-hares-i2rs-protocol-strawman-03#section= -4.5.2. =20 >>=20 >> Given the mount schema functionality, we can mount ephemeral state = module which augment non-ephemeral state modules which are "in-secure = only". =20 >>=20 >> Point 2:=20 >> I am willing to put an enumeration of the use cases in the protocol = requirement, but I would like to understand the purpose for the = enumeration. We are not doing a use case, but a requirements document. = This information appears to be a "use case" rather than a technical = description. What purpose are you looking for this enumeration to = server. Are you looking for the enumeration in SEC-REQ-08?=20 >>=20 >> Point 3: Could you review -08.txt on this topic, especially the text = below. Given your comments, I believe I should change the last line to = a MUST.=20 >> New/ The default mode of transport is >> secure so data models MUST clearly annotate what data nodes can be >> passed over an insecure connection. >> / >>=20 >> Sue >>=20 >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> As to the normative requirements (-08.txt) version:=20 >>=20 >> Section 3:=20 >>=20 >> I2RS allows the use of an insecure transport for portions of data >> models that clearly indicate the use of an insecure transport. >> Operators deploying I2RS must determine if they want to populate = and >> deploy the portions of the data model which use insecure = transports. >>=20 >> In Section 3.2 in version -08.txt >>=20 >> SEC-REQ-08: The I2RS protocol MUST be able to transfer data over a >> secure transport and optionally MAY be able to transfer data over a >> non-secure transport. A secure transport MUST provide data >> confidentiality, data integrity, and replay prevention. >>=20 >> The default I2RS transport is a secure transport. >>=20 >> 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. >>=20 >> The configuration of ephemeral data in the I2RS Agent by the I2RS >> client SHOULD be done over a secure transport. It is anticipated >> that the passing of most I2RS ephemeral state operational status >> SHOULD be done over a secure transport. As >> [I-D.ietf-i2rs-ephemeral-state] notes, a data model MUST indicate >> whether the transport exchanging the data between I2RS client and >> I2RS agent is secure or insecure. =20 >>=20 >> The default mode of transport is >> secure so data models SHOULD clearly annotate what data nodes can = be >> passed over an insecure connection. >>=20 >>>=20 >>> Yours, >>> Joel >>>=20 >>> -----Original Message----- >>> From: Susan Hares [mailto:shares@ndzh.com] >>> Sent: Thursday, August 18, 2016 9:17 AM >>> To: 'Juergen Schoenwaelder' >>> Cc: i2rs@ietf.org; i2rs-chairs@ietf.org; 'Kathleen Moriarty'=20 >>> ; 'The IESG' ;=20 >>> jhaas@pfrc.org;=20 >>> 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) >>>=20 >>> Juergen and Kathleen:=20 >>>=20 >>> Let me proceed with two examples: BGP route views data model and the = event for the web-service data. =20 >>>=20 >>> The content of these data models are designated as exposed to = public. The routing system only populates the proposed BGP route views = data model with the data destined for the BGP looking glass. The policy = on the routing system indicates what information gets transferred. The = data model is completely available to the public. The Yang Doctors are = going to review this by seeing the whole model is public and available = via non-secure means. >>> The security people are going to review this seeing that the whole = model is public, and available via an unprotect means. The fact the = data model is all public should simplify the review.=20 >>>=20 >>> An event from the I2RS RIB that a web-service route is up is the = second case. The I2RS RIB has an event based on policy that indicates a = web-service route is up. The yang-1.1 doctors must review the content = of the event text to see it does not break privacy or provide too much >>> information The event mechanisms will need to work over secure = transport >>> and insecure transport. Most of the data will go over the secure = transport event stream. However, a small amount of information may go = over the insecure transport stream.=20 >>>=20 >>> First, let me know if my use cases are understandable. Second, let = me know if you disagree with this use cases.=20 >>>=20 >>> Fyi - IESG approved the architecture with the insecure stream.=20 >>>=20 >>> Sue >>>=20 >>> -----Original Message----- >>> From: Juergen Schoenwaelder >>> [mailto:j.schoenwaelder@jacobs-university.de] >>> Sent: Thursday, August 18, 2016 9:06 AM >>> To: Susan Hares >>> Cc: i2rs@ietf.org; i2rs-chairs@ietf.org; 'Kathleen Moriarty'; 'The=20 >>> IESG'; jhaas@pfrc.org;=20 >>> 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) >>>=20 >>> I just do not know on which basis a data model writer can decide = whether a data object can be exposed in an unprotected way. How are YANG = doctors going to review this? How are security directorate people going = to judge this? But as promised, I leave (still puzzled) now. >>>=20 >>> /js >>>=20 >>>> On Thu, Aug 18, 2016 at 09:00:14AM -0400, Susan Hares wrote: >>>> Juergen:=20 >>>>=20 >>>> Yes, we seem to disagree on the value of making it hardwired in the = model. >>>> For me, the value is a common understanding of deployment=20 >>>> distribution >>> such >>>> as the route-views. Since the operators argued strongly for this = point, >>> I >>>> think the best idea is to get it working in code and then see if=20 >>>> the deployment matches the requests. >>>>=20 >>>> Sue >>>>=20 >>>> -----Original Message----- >>>> From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Juergen=20 >>>> Schoenwaelder >>>> Sent: Thursday, August 18, 2016 8:14 AM >>>> To: Susan Hares >>>> Cc: i2rs@ietf.org; i2rs-chairs@ietf.org; 'Kathleen Moriarty'; 'The=20 >>>> IESG'; jhaas@pfrc.org;=20 >>>> 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=20 >>>> and >>>> COMMENT) >>>>=20 >>>> Sue, >>>>=20 >>>> I still do not see why the 'mode of exposure' of data benefits from = >>>> being hard-wired in the data model. For me, it is a situational and = >>>> deployment specific question. But I shut up here since I aired this = >>>> concern before (and we simply seem to disagree). >>>>=20 >>>> /js >>>>=20 >>>>> On Thu, Aug 18, 2016 at 08:07:18AM -0400, Susan Hares wrote: >>>>> Juergen:=20 >>>>>=20 >>>>> My example is the looking glass servers for the BGP route views=20 >>>>> project >>>>> (http://www.routeviews.org/) or a route indicating the presence of = a >>>>> web-server that is public. For the BGP I2RS route, a yang model = could >>>>> replace the looking glass function, and provide events for these = looking >>>>> glass functions. For the web-server route, an event be sent = when >>> that >>>>> one route is added. =20 >>>>>=20 >>>>> Sue >>>>>=20 >>>>>=20 >>>>> -----Original Message----- >>>>> From: Juergen Schoenwaelder >>>>> [mailto:j.schoenwaelder@jacobs-university.de] >>>>> Sent: Thursday, August 18, 2016 3:32 AM >>>>> To: Susan Hares >>>>> Cc: 'Kathleen Moriarty'; 'The IESG'; jhaas@pfrc.org;=20 >>>>> i2rs@ietf.org; i2rs-chairs@ietf.org;=20 >>>>> 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=20 >>>>> and >>>>> COMMENT) >>>>>=20 >>>>>> On Wed, Aug 17, 2016 at 09:16:48PM -0400, Susan Hares wrote: >>>>>> ----------------------------------------------------------------- >>>>>> - >>>>>> -- >>>>>> -- >>>>>> COMMENT: >>>>>> ----------------------------------------------------------------- >>>>>> - >>>>>> -- >>>>>> -- >>>>>>=20 >>>>>>> Section 3:=20 >>>>>>> Can you clarify the second to last sentence? Do you mean there=20 >>>>>>> are >>>>> sections that indicate an insecure transport should be used? >>>>>>> I2RS allows the use of an >>>>>>> insecure transport for portions of data models that clearly=20 >>>>>>> indicate insecure transport. >>>>>>=20 >>>>>>> Perhaps: >>>>>>> I2RS allows the use of an >>>>>>> insecure transport for portions of data models that clearly=20 >>>>>>> indicate the use of an insecure transport. >>>>>=20 >>>>> I still wonder how a data model writer can reasonably decide=20 >>>>> whether a piece of information can be shipped safely over an=20 >>>>> insecure transport since this decision often depends on the=20 >>>>> specifics of a deployment >>>> situation. >>>>>=20 >>>>> /js >>>>>=20 >>>>> PS: I hope we do not end up with defining data multiple times = (once >>>>> for insecure transport and once for secured transports). >>>>>=20 >>>>> --=20 >>>>> Juergen Schoenwaelder Jacobs University Bremen gGmbH >>>>> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | = Germany >>>>> Fax: +49 421 200 3103 >>>>>=20 >>>>> _______________________________________________ >>>>> i2rs mailing list >>>>> i2rs@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/i2rs >>>>=20 >>>> --=20 >>>> Juergen Schoenwaelder Jacobs University Bremen gGmbH >>>> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | = Germany >>>> Fax: +49 421 200 3103 >>>>=20 >>>> _______________________________________________ >>>> i2rs mailing list >>>> i2rs@ietf.org >>>> https://www.ietf.org/mailman/listinfo/i2rs >>>=20 >>> --=20 >>> Juergen Schoenwaelder Jacobs University Bremen gGmbH >>> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | = Germany >>> Fax: +49 421 200 3103 >=20 > --=20 > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 From nobody Fri Aug 19 04:59:50 2016 Return-Path: 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 E908412DA77 for ; Fri, 19 Aug 2016 04:38:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 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_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=labn.net 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 OkaEHlo7ywEf for ; Fri, 19 Aug 2016 04:38:51 -0700 (PDT) Received: from qproxy1-pub.mail.unifiedlayer.com (qproxy1-pub.mail.unifiedlayer.com [173.254.64.10]) by ietfa.amsl.com (Postfix) with SMTP id 8078E12D913 for ; Fri, 19 Aug 2016 04:38:51 -0700 (PDT) Received: (qmail 20903 invoked by uid 0); 19 Aug 2016 11:38:47 -0000 Received: from unknown (HELO cmgw4) (10.0.90.85) by qproxy1.mail.unifiedlayer.com with SMTP; 19 Aug 2016 11:38:47 -0000 Received: from box313.bluehost.com ([69.89.31.113]) by cmgw4 with id YzZh1t00h2SSUrH01zZktu; Fri, 19 Aug 2016 05:33:47 -0600 X-Authority-Analysis: v=2.1 cv=TIHWFTVa c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=IkcTkHD0fZMA:10 a=-NfooI8aBGcA:10 a=uEJ9t1CZtbIA:10 a=7z1cN_iqozsA:10 a=48vgC7mUAAAA:8 a=Tg0nUI2_AAAA:8 a=0FD05c-RAAAA:8 a=1sjgXBK7AAAA:8 a=pGLkceISAAAA:8 a=PityYCoGAAAA:8 a=j3Z76cjpAAAA:8 a=RzLYdYIfM884ZKPC9EAA:9 a=MxPSGBJ5XHfFAuoO:21 a=wmFQfz-CgDm3vf4d:21 a=QEXdDO2ut3YA:10 a=FvgKqOQ44qUA:10 a=JrSEOxZJtCQA:10 a=-FEs8UIgK8oA:10 a=NWVoK91CQyQA:10 a=w1C3t2QeGrPiZgrLijVG:22 a=qRfHG-2J1AYadgyPbmI5:22 a=l1rpMCqCXRGZwUSuRcM3:22 a=qowbMnUzjQcM5iyYROrS:22 a=6kGIvZw6iX1k4Y-7sg4_:22 a=ZO5f8yik10I_Qaw9TOeb:22 a=9ZYBcOd_X9kS2t7VFny2:22 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version :Date:Message-ID:From:Cc:References:To:Subject; bh=0Z2NOBK4KtTQmaBMFQ45cvaDYdkTki2wQNv1bF3RvZ8=; b=B8iEFXcO3zRBnTAXJS7hKteupd pcyUkIBzdMsXU76i5epTFMe35mYkrUA+1o7ZoGw5scU/SbQH7lHEII5eq13BIWn0IeNNKQmzR1ixE RH++48R9lV442zR+aW59wrqZ1; Received: from box313.bluehost.com ([69.89.31.113]:60373 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.86_2) (envelope-from ) id 1bai3R-0008HG-Gb; Fri, 19 Aug 2016 05:33:41 -0600 To: Susan Hares , 'Juergen Schoenwaelder' References: <013b01d1f8ee$31fa09b0$95ee1d10$@ndzh.com> <20160818073203.GA4338@elstar.local> <04b501d1f949$116c63e0$34452ba0$@ndzh.com> <20160818121405.GA5282@elstar.local> <051301d1f950$7739c670$65ad5350$@ndzh.com> <20160818130555.GA5366@elstar.local> <051701d1f952$c4ae0b30$4e0a2190$@ndzh.com> <6BCE198E4EAEFC4CAB45D75826EFB0761525CCD7@eusaamb101.ericsson.se> <003801d1f97f$3d16eb10$b744c130$@ndzh.com> <20160819085756.GA6759@elstar.local> <01e501d1fa07$6d613fe0$4823bfa0$@ndzh.com> From: Lou Berger Message-ID: <9c53ff98-3268-f6e2-fbe6-862fc3948794@labn.net> Date: Fri, 19 Aug 2016 07:33:36 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <01e501d1fa07$6d613fe0$4823bfa0$@ndzh.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - box313.bluehost.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - labn.net X-Source-IP: 69.89.31.113 X-Exim-ID: 1bai3R-0008HG-Gb X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: box313.bluehost.com ([127.0.0.1]) [69.89.31.113]:60373 X-Source-Auth: lberger@labn.net X-Email-Count: 0 X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ== Archived-At: X-Mailman-Approved-At: Fri, 19 Aug 2016 04:59:48 -0700 Cc: i2rs@ietf.org, 'Alissa Cooper' , i2rs-chairs@ietf.org, 'Kathleen Moriarty' , 'IESG' , jhaas@pfrc.org, '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) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Aug 2016 11:38:56 -0000 Sue, I don't see Juergen as arguing against model access via non-secure transport. I read his point as that the transport security requirements don't belong scattered within a data model. I have to say that from a model complexity (definition, process, review, implementation - take your pick) , language and NETMOD co-chair perspective, his comment resonates with me. I think this makes the key text: The default mode of transport is secure so data models SHOULD clearly annotate what data nodes can be passed over an insecure connection. As this isn't a MUST, I personally think we can live with the text and we can debate the issue further in the context of specific solutions. I would strongly object to this being changed to a MUST, or if the document is changed to make transport (security) requirements identified within data models a requirement. Lou On 8/19/2016 6:49 AM, Susan Hares wrote: > Juergen: > > You have laid out the two options: a) link the data-model to the non-secure transport, and b) do not link the data to the non-secure transport. I agree with you that past models did not link past SNMP MIB data model to the transport. Existing NETCONF models do not link it to the transport. As you have indicated, you disagreed in the I2RS WG and we found consensus was to include the non-secure transport. > > I2RS was created to build things as an interface to the routing environment. The operators clearly informed the I2RS group of this need during the requirement setting phase prior to the time I was chair. The reason I continue to press for this capability is their input, and the existing use cases I listed previously in this mail: > > a) public information - BGP route views, > b) specific well know up events - such as public-web site up > c) specific network service events - interface to particular public LAN up. > > As you know, we do not have any I2RS data models that specify this feature at this time. I suspect after we get through this lengthy requirement phase, the operators may begin to specify new models that have this feature. > > Sue > > -----Original Message----- > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de] > Sent: Friday, August 19, 2016 4:58 AM > To: Susan Hares > Cc: 'Alissa Cooper'; 'Joel Halpern'; i2rs@ietf.org; i2rs-chairs@ietf.org; 'Kathleen Moriarty'; 'IESG'; jhaas@pfrc.org; 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) > > I repeat my technical argument: While there may be deployments where non-secure transports may be reasonable to use, defining these situations statically as part of data model schemas does not follow established practices. The IETF has a long tradition of standardizing data models that can be used in a variety of operational contexts and I do not see reasons why we should move away from that basic approach. > > /js > > On Thu, Aug 18, 2016 at 02:35:03PM -0400, Susan Hares wrote: >> Alissa: >> >> Just a little input you may not know. My background is 15 years (1995-2010) developing a routing/switching platform (denoted as GateD) which was sold to over 200 companies. We developed XML and a binary XML based product that configured this product. It could do 100K configuration lines and reboot in less than a second on most hardware. We also provide status messages in secure streams and non-secure streams. I sold early version of this code to companies that Alia has worked for - so she has personal viewed the code. At the height of our work, our development team ran to 50 people which I directed (First as VP of Engineering, and then as CTO). It is due to this level of experience that Alia selected me for the co-chair. Russ White has understood Cisco's process, and has also directed software development teams for routing. >> >> In order to freshen my direct experience with I2RS on open source work, I am working on a publically available work in Quagga based on the confD product suggested by Cisco. >> >> In contrast, Juergen is a university professor who has worked on proto-types. He is not working on an implementation. I hope he will. >> >> I hope you will consider this background in my response to your comments below. >> >> Sue >> >> >> -----Original Message----- >> From: Alissa Cooper [mailto:alissa@cooperw.in] >> Sent: Thursday, August 18, 2016 12:54 PM >> To: Joel Halpern >> Cc: Susan Hares; Juergen Schoenwaelder; i2rs@ietf.org; >> i2rs-chairs@ietf.org; Kathleen Moriarty; IESG; jhaas@pfrc.org; >> 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) >> >> Jumping in here because this is relevant to my DISCUSS, hope nobody minds (but if you do, I can go back to the other thread). >> >>>> On Aug 18, 2016, at 10:30 AM, Joel Halpern wrote: >>>> >>>> Let me try a different take approach to this particular question. >>>> >>>> Let me start by putting aside the question of where things are marked, and come back to that afterwards. >>>> >>>> There are a number of cases that I2RS has been asked to cover of high rate telemetry data. This may be BGP update information, it may be frequent information about line card activity. There are other cases, some of which have been documented. >>>> >>>> While not completely insensitive, the operators have made clear that they see protecting this data as unnecessary. While I would hope over time to move to a domain where all of it is protect, that is not trivial. As the I2RS Architecture points out, it is expected that what we describe as a single I2RS >communication between a client and agent is actually associated with multiple channels of communication. >>>> >>>> Now, if you want to say that the I2RS protocol requirements cannot allow for unprotected channels, I guess we have disconnect between the IESG and the WG. >>>> >>>> If we say that we can allow for unprotected channels, we then get to the question of which data can be sent over such channels. While architecturally I agree with Juergen that the model is a bad place to specify it, the obverse is also true. Not having some limits on what can be sent unprotected >causes concern about insufficient protection. If I recall correctly, earlier security reviews called us to task for being too broad in what we allowed. >>>> >>>> So, if the IESG wants us to just allow it anywhere, because the >>>> model is an awkward place to define the limitation, I can live with that. What I can't live with is being told both that the model is a bad place to define it and that there must be restrictions on what is sent unprotected, without any proposal on how we are to move forward. >>> Thank you Joel, this explanation helps me a lot. I think there is a disconnect about how the restrictions are expressed. From reading the email traffic about this document, it strikes me that trying to express the restrictions programmatically doesn’t make much sense in this case. >>> I agree with Juergen that it will be challenging to make a judgment a priori in order to bake a restriction into a data model, because data that is considered sensitive enough to warrant a secure transport in one deployment may not be considered sensitive in another deployment. >>> So for any data elements where there is any question at all about >>> whether they might be sensitive (i.e., any data elements that are not already routinely made public), I would expect data model authors to end up indicating that they may be sent over either secure or insecure transport, which renders the indication not useful. >>> Perhaps it would make more sense then to just enumerate in the text the cases that motivate the inclusion of protocol support for insecure transport: >>> >>> 1. For conveyance of information that is already routinely made public. >>> 2. For line card activity data where there is no likely upgrade path to support secure transports in the foreseeable future. >>> >>> Then the normative requirements would be on clients and agents to use secure transports unless those clients and agents are deployed where either of the operational circumstances above necessitate otherwise. >>> Alissa >> Point 1: >> I disagree with Juergen on the difficulty in specifying the sections of the yang modules. I have provided a suggested solution in: >> https://tools.ietf.org/html/draft-hares-i2rs-protocol-strawman-03#section-4.5.2. >> >> Given the mount schema functionality, we can mount ephemeral state module which augment non-ephemeral state modules which are "in-secure only". >> >> Point 2: >> I am willing to put an enumeration of the use cases in the protocol requirement, but I would like to understand the purpose for the enumeration. We are not doing a use case, but a requirements document. This information appears to be a "use case" rather than a technical description. What purpose are you looking for this enumeration to server. Are you looking for the enumeration in SEC-REQ-08? >> >> Point 3: Could you review -08.txt on this topic, especially the text below. Given your comments, I believe I should change the last line to a MUST. >> New/ The default mode of transport is >> secure so data models MUST clearly annotate what data nodes can be >> passed over an insecure connection. >> / >> >> Sue >> >> =================== >> As to the normative requirements (-08.txt) version: >> >> Section 3: >> >> I2RS allows the use of an insecure transport for portions of data >> models that clearly indicate the use of an insecure transport. >> Operators deploying I2RS must determine if they want to populate and >> deploy the portions of the data model which use insecure transports. >> >> In Section 3.2 in version -08.txt >> >> SEC-REQ-08: The I2RS protocol MUST be able to transfer data over a >> secure transport and optionally MAY be able to transfer data over a >> non-secure transport. A secure transport MUST provide data >> confidentiality, data integrity, and replay prevention. >> >> The default I2RS transport is a secure transport. >> >> 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. >> >> The configuration of ephemeral data in the I2RS Agent by the I2RS >> client SHOULD be done over a secure transport. It is anticipated >> that the passing of most I2RS ephemeral state operational status >> SHOULD be done over a secure transport. As >> [I-D.ietf-i2rs-ephemeral-state] notes, a data model MUST indicate >> whether the transport exchanging the data between I2RS client and >> I2RS agent is secure or insecure. >> >> The default mode of transport is >> secure so data models SHOULD clearly annotate what data nodes can be >> passed over an insecure connection. >> >>> Yours, >>> Joel >>> >>> -----Original Message----- >>> From: Susan Hares [mailto:shares@ndzh.com] >>> Sent: Thursday, August 18, 2016 9:17 AM >>> To: 'Juergen Schoenwaelder' >>> Cc: i2rs@ietf.org; i2rs-chairs@ietf.org; 'Kathleen Moriarty' >>> ; 'The IESG' ; >>> jhaas@pfrc.org; >>> 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) >>> >>> Juergen and Kathleen: >>> >>> Let me proceed with two examples: BGP route views data model and the event for the web-service data. >>> >>> The content of these data models are designated as exposed to public. The routing system only populates the proposed BGP route views data model with the data destined for the BGP looking glass. The policy on the routing system indicates what information gets transferred. The data model is completely available to the public. The Yang Doctors are going to review this by seeing the whole model is public and available via non-secure means. >>> The security people are going to review this seeing that the whole model is public, and available via an unprotect means. The fact the data model is all public should simplify the review. >>> >>> An event from the I2RS RIB that a web-service route is up is the second case. The I2RS RIB has an event based on policy that indicates a web-service route is up. The yang-1.1 doctors must review the content of the event text to see it does not break privacy or provide too much >>> information The event mechanisms will need to work over secure transport >>> and insecure transport. Most of the data will go over the secure transport event stream. However, a small amount of information may go over the insecure transport stream. >>> >>> First, let me know if my use cases are understandable. Second, let me know if you disagree with this use cases. >>> >>> Fyi - IESG approved the architecture with the insecure stream. >>> >>> Sue >>> >>> -----Original Message----- >>> From: Juergen Schoenwaelder >>> [mailto:j.schoenwaelder@jacobs-university.de] >>> Sent: Thursday, August 18, 2016 9:06 AM >>> To: Susan Hares >>> Cc: i2rs@ietf.org; i2rs-chairs@ietf.org; 'Kathleen Moriarty'; 'The >>> IESG'; jhaas@pfrc.org; >>> 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) >>> >>> I just do not know on which basis a data model writer can decide whether a data object can be exposed in an unprotected way. How are YANG doctors going to review this? How are security directorate people going to judge this? But as promised, I leave (still puzzled) now. >>> >>> /js >>> >>> On Thu, Aug 18, 2016 at 09:00:14AM -0400, Susan Hares wrote: >>>> Juergen: >>>> >>>> Yes, we seem to disagree on the value of making it hardwired in the model. >>>> For me, the value is a common understanding of deployment >>>> distribution >>> such >>>> as the route-views. Since the operators argued strongly for this point, >>> I >>>> think the best idea is to get it working in code and then see if >>>> the deployment matches the requests. >>>> >>>> Sue >>>> >>>> -----Original Message----- >>>> From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Juergen >>>> Schoenwaelder >>>> Sent: Thursday, August 18, 2016 8:14 AM >>>> To: Susan Hares >>>> Cc: i2rs@ietf.org; i2rs-chairs@ietf.org; 'Kathleen Moriarty'; 'The >>>> IESG'; jhaas@pfrc.org; >>>> 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) >>>> >>>> Sue, >>>> >>>> I still do not see why the 'mode of exposure' of data benefits from >>>> being hard-wired in the data model. For me, it is a situational and >>>> deployment specific question. But I shut up here since I aired this >>>> concern before (and we simply seem to disagree). >>>> >>>> /js >>>> >>>> On Thu, Aug 18, 2016 at 08:07:18AM -0400, Susan Hares wrote: >>>>> Juergen: >>>>> >>>>> My example is the looking glass servers for the BGP route views >>>>> project >>>>> (http://www.routeviews.org/) or a route indicating the presence of a >>>>> web-server that is public. For the BGP I2RS route, a yang model could >>>>> replace the looking glass function, and provide events for these looking >>>>> glass functions. For the web-server route, an event be sent when >>> that >>>>> one route is added. >>>>> >>>>> Sue >>>>> >>>>> >>>>> -----Original Message----- >>>>> From: Juergen Schoenwaelder >>>>> [mailto:j.schoenwaelder@jacobs-university.de] >>>>> Sent: Thursday, August 18, 2016 3:32 AM >>>>> To: Susan Hares >>>>> Cc: 'Kathleen Moriarty'; 'The IESG'; jhaas@pfrc.org; >>>>> i2rs@ietf.org; i2rs-chairs@ietf.org; >>>>> 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 Wed, Aug 17, 2016 at 09:16:48PM -0400, Susan Hares wrote: >>>>>> ----------------------------------------------------------------- >>>>>> - >>>>>> -- >>>>>> -- >>>>>> COMMENT: >>>>>> ----------------------------------------------------------------- >>>>>> - >>>>>> -- >>>>>> -- >>>>>> >>>>>>> Section 3: >>>>>>> Can you clarify the second to last sentence? Do you mean there >>>>>>> are >>>>> sections that indicate an insecure transport should be used? >>>>>>> I2RS allows the use of an >>>>>>> insecure transport for portions of data models that clearly >>>>>>> indicate insecure transport. >>>>>>> Perhaps: >>>>>>> I2RS allows the use of an >>>>>>> insecure transport for portions of data models that clearly >>>>>>> indicate the use of an insecure transport. >>>>> I still wonder how a data model writer can reasonably decide >>>>> whether a piece of information can be shipped safely over an >>>>> insecure transport since this decision often depends on the >>>>> specifics of a deployment >>>> situation. >>>>> /js >>>>> >>>>> PS: I hope we do not end up with defining data multiple times (once >>>>> for insecure transport and once for secured transports). >>>>> >>>>> -- >>>>> Juergen Schoenwaelder Jacobs University Bremen gGmbH >>>>> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany >>>>> Fax: +49 421 200 3103 >>>>> >>>>> _______________________________________________ >>>>> i2rs mailing list >>>>> i2rs@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/i2rs >>>> -- >>>> Juergen Schoenwaelder Jacobs University Bremen gGmbH >>>> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany >>>> Fax: +49 421 200 3103 >>>> >>>> _______________________________________________ >>>> i2rs mailing list >>>> i2rs@ietf.org >>>> https://www.ietf.org/mailman/listinfo/i2rs >>>> >>> -- >>> Juergen Schoenwaelder Jacobs University Bremen gGmbH >>> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany >>> Fax: +49 421 200 3103 >>> >> From nobody Fri Aug 19 04:59:53 2016 Return-Path: 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 3805D12DDFE; Fri, 19 Aug 2016 04:40:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.738 X-Spam-Level: * X-Spam-Status: No, score=1.738 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, RDNS_NONE=0.793] autolearn=no 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 f0CBkOLQLT_L; Fri, 19 Aug 2016 04:40:45 -0700 (PDT) Received: from hickoryhill-consulting.com (unknown [50.245.122.97]) (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 76A2812DA77; Fri, 19 Aug 2016 04:40:44 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=184.157.82.170; From: "Susan Hares" To: "'Kathleen Moriarty'" References: <147146974235.23784.4389421535496134619.idtracker@ietfa.amsl.com> <013b01d1f8ee$31fa09b0$95ee1d10$@ndzh.com> <20160818073203.GA4338@elstar.local> <04b501d1f949$116c63e0$34452ba0$@ndzh.com> <20160818121405.GA5282@elstar.local> <051301d1f950$7739c670$65ad5350$@ndzh.com> <20160818130555.GA5366@elstar.local> <051701d1f952$c4ae0b30$4e0a2190$@ndzh.com> <6BCE198E4EAEFC4CAB45D75826EFB0761525CCD7@eusaamb101.ericsson.se> <003801d1f97f$3d16eb10$b744c130$@ndzh.com> <00dc01d1f988$f2cec280$d86c4780$@ndzh.com> <012e01d1f98b$ec9d09a0$c5d71ce0$@ndzh.com> In-Reply-To: Date: Fri, 19 Aug 2016 07:39:22 -0400 Message-ID: <026c01d1fa0e$551e72c0$ff5b5840$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIa7Lz6VgZw6h2A0uGNzOgAA2Ic8QJ/RF5yARxv/coCD6d0AAIDKkFTAYlI9/gCaK/wXAMksAaNAmoTFCQCp9Oi8AIQlOgDAIZjbI0CaGRfrQGPw5JeAkOaiKwBgcGFUp7M2hJg Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: X-Mailman-Approved-At: Fri, 19 Aug 2016 04:59:48 -0700 Cc: i2rs@ietf.org, 'Alissa Cooper' , 'Juergen Schoenwaelder' , 'Andy Bierman' , 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) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Aug 2016 11:40:47 -0000 Kathleen:=20 Thank you for your suggestions. See below for the modification.=20 Sue=20 -----Original Message----- From: Kathleen Moriarty [mailto:kathleen.moriarty.ietf@gmail.com]=20 Sent: Thursday, August 18, 2016 8:47 PM To: Susan Hares Cc: Andy Bierman; Alissa Cooper; Joel Halpern; i2rs@ietf.org; Juergen = Schoenwaelder; i2rs-chairs@ietf.org; IESG; Jeffrey Haas; = 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) I think there are some easy tweaks that could make everyone happy. We = should be focusing on MTI, not MTU for requirements so that operators = can make decisions as needed. I think we can all agree with that = statement. We are worried about a few areas of text in the document, = namely where the data model can trigger the use of an insecure = transport. The default is a secure transport for the protocol, so that = is MTI across the board. One of the sections that causes concern is the = following: [please define: MTI/MTU]=20 >Section 3: (I think the latest proposed text) > > I2RS allows the use of an insecure transport for portions of data > models that clearly indicate the use of an insecure transport. > Operators deploying I2RS must determine if they want to populate and > deploy the portions of the data model which use insecure transports. The latest text from -08.txt is:=20 >The security for the I2RS protocol requires mutually authenticated I2RS = >clients and I2RS agents. The I2RS client and I2RS agent using the I2RS=20 >protocol MUST be able to exchange data over a secure transport. =20 >Optionally, the I2RS Client and I2RS agent MAY operate on a non-secure=20 >transport to transfer a specific set of non-confidential data =20 Alvaro made the point this text was redundant. I agreed and suggested it = be removed -09.txt. Does this satisfy you. =20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >Which doesn't exactly meet the stated requirement in Section 3.2: > >In Section 3.2 in version -08.txt > > SEC-REQ-08: The I2RS protocol MUST be able to transfer data over a > secure transport and optionally MAY be able to transfer data over a > non-secure transport. A secure transport MUST provide data > confidentiality, data integrity, and replay prevention. > I think if we reword the text in section 3 as follows, the requirement = for support of a secure transport will be clear, a way to mark the data = model for the possible use of insecure > transport is possible (decision = of the operator). >=20 > How about: > I2RS allows the use of an insecure transport for portions of data > models that clearly indicate data confidentiality and integrity = protection may not be necessary. > Operators deploying I2RS must determine if they want to populate = and > deploy the portions of the data model with a configuration option to = use insecure transports. >=20 > I understand this changes your requirements a bit and your = implementation, but is this a way that we could allow some operators to = operate in a secure mode for this data if they choose and also allow MTU = to be less than the default? >=20 Sue: Would removal of this text work instead? As Alvaro pointed out, it = is redundant to SEC-REQ-08.=20 I agreed to remove that text which results in:=20 The Start of section 3 would be:=20 The security for the I2RS protocol requires mutually authenticated I2RS clients and I2RS agents communicating over a secure transport. =20 The I2RS protocol MUST be able to provide atomicity of an I2RS transaction, but it is not required to have multi-message atomicity and roll-back mechanism transactions. Multiple messages transactions may be impacted by the interdependency of data. This section discusses the details of these security requirements. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >If that's agreeable - with the other ADs too - then some more text in = section 3.2 needs to be tweaked in a similar way. > >The text in section 3.2 is closer to what I am proposing, you have the = sentence: > > 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. > >This talks about the data being marked in terms of a need for = confidentiality (should be integrity too as I could corrupt a clear text = stream in a way that is not detectable) instead >of explicitly stating = that the transport should be insecure. If the data model had a = attribute that had this marking (operator driven), I think that's an = improvement. >How about: > > A non-secure transport can be used for publishing telemetry data or > other operational state that was specifically indicated as non- > confidential and does not require integrity protection through an > option provided in the data model. > >I think this text allows for the WG goal of using a data model to = indicate the transport option, but for it to be an operator driven = decision in case some operators prefer to use >transport encryption for = this section of the data model... or things change and they all decide = this is a good idea. Technical point: The phrase:=20 SEC-REQ-08: The I2RS protocol MUST be able to transfer data over a secure transport and optionally MAY be able to transfer data over a non-secure transport. This text always implied to the WG that the operator could always elect = to send the non-secure marked portion of a data model over secure = transport. Therefore, I am happy you want to emphasize this technical = issue in the text. I think we are aligned on this higher issue. = However, this alternate text has a problem.=20 Textual comments: The reason we stated: =20 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. And=20 The default mode of transport is secure so data models SHOULD clearly annotate what data nodes can be passed over an insecure connection. Is to provide precise requirements for the NETCONF/NETMOD WG with whom = the I2RS WG to whom the=20 I2RS WG will send these initial comments. Your text does not provide = that precise instruction.=20 How about this version for SEC-REQ-08: SEC-REQ-08: The I2RS protocol MUST be able to transfer data over a secure transport and optionally MAY be able to transfer data over a non-secure transport. A secure transport MUST provide data confidentiality, data integrity, and replay prevention. The default I2RS transport is a secure transport. =20 =20 A non-secure transport may optionally 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. =20 Since the non-secure transport is optional, an operator may set an = option=20 to send the data marked "non-secure" in the Yang syntax=20 over a secure transport. =20 The following are further restrictions on this optionally non-secure = transport:=20 1) The configuration of ephemeral data in the I2RS Agent by the I2RS client SHOULD be done over a secure transport. =20 2) It is anticipated that the passing of most I2RS ephemeral state = operational status SHOULD be done over a secure transport. =20 3) As [I-D.ietf-i2rs-ephemeral-state] notes data model MUST indicate whether the transport exchanging the data between I2RS client and I2RS agent is secure or insecure. The default mode of transport is secure so data models SHOULD clearly annotate what data nodes can be passed over an insecure connection. =20 ------- Does this refinement of the text make it clear the operator can always = turn=20 on the secure transport?=20 > I'll get back to the other responses to my comments and discuss in a = separate message (possibly tomorrow). > > If this alters discussions from other threads, please point me to the = thread and I'll catch up. I've pointed you at Alvaro message.=20 ------------------ Thanks, Kathleen Thank you Kathleen. This helped! On Thu, Aug 18, 2016 at 4:05 PM, Susan Hares wrote: > Andy: > > > > If we create a yang data model that is insecure, and mount on another = data > model =E2=80=93 does it have the same issue as module augmentation? = Of course, we > could create a mount point for all insecure data modules, and all data = > placed under that mount point =E2=80=93 would be insecure. > > > > For the BGP route-views use case, this would make it clear that data=20 > had to be transformed to be insecure transmission. > > > > Sue > > > > From: Andy Bierman [mailto:andy@yumaworks.com] > Sent: Thursday, August 18, 2016 4:02 PM > > > To: Susan Hares > Cc: Alissa Cooper; Joel Halpern; i2rs@ietf.org; Juergen Schoenwaelder; = > i2rs-chairs@ietf.org; Kathleen Moriarty; IESG; Jeffrey Haas;=20 > 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 Thu, Aug 18, 2016 at 12:44 PM, Susan Hares wrote: > > Andy: > > > > Thank you =E2=80=93 I thought it was on whether we could implement = insecure=20 > transport in a Yang module. > > > > The requirement text you are working with is: > > > > SEC-REQ-08: The I2RS protocol MUST be able to transfer data over a > secure transport and optionally MAY be able to transfer data over a > non-secure transport. > > > > I do not understand why approving the ok for non-secure transport for=20 > some modules means the following to you: > > > > =E2=80=9C the IETF needs to agree that there could never possibly be = any=20 > deployment that would not want to allow exposure of the data. > > Not now. Not 20 years from now.=E2=80=9D > > > > > > > > As I understand it, this requirement has another requirement=20 > associated with it > > that says the data has to be identified as OK-for-nonsecure-transport. > > > > An extension in the data model says that all instances of the object=20 > in > > all possible deployments cannot be considered sensistive and therefore > > needs disclosure protection. > > > > It may seem like even a simple octet counter is safe to send in the=20 > clear, > > but not if that opens up correlation attacks. (e.g., I can send data=20 > to some > > host. I can see that index 455992 is incrementing the in-octets=20 > counters > > in a way that strongly correlates to my test traffic. Therefore I can = > learn > > that arbitrary index 455992 is really John Doe or really suite #14, = etc. > > > > > > I had thought that the security-directorate and other reviewers would=20 > look at each module that is insecure, and consider whether it was = reasonable for > the use case at this time. This is what I understood from Russ = Housley=E2=80=99s > first review of this technology. Since like you, I believe the = operator is > going to configure what modules are allowed on systems. I agree = that this > requirement provides a full scope of the work, but implementers will=20 > require network operators to configure these features on. > > > > Sue > > > > Andy > > > > > > > > From: Andy Bierman [mailto:andy@yumaworks.com] > Sent: Thursday, August 18, 2016 2:53 PM > To: Susan Hares > Cc: Alissa Cooper; Joel Halpern; i2rs@ietf.org; Juergen Schoenwaelder; = > i2rs-chairs@ietf.org; Kathleen Moriarty; IESG; Jeffrey Haas;=20 > 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) > > > > Hi, > > > > I did not think Juergen's comment was about running code. > > > > In order for a data node to get the "ok-for-nonsecure-transports"=20 > approval > > in an IETF module, the IETF needs to agree that there could never=20 > possibly be > > any deployment that would not want to allow exposure of the data. > > Not now. Not 20 years from now. > > > > I can see a vendor making that decision for their own proprietary=20 > modules, > > but it seems less likely for standard modules. > > > > Seems like the operator is going to have to configure what is allowed > > for nonsecure transport anyway, so just let them decide. > > I don't really object to the extension or the requirement. > > It doesn't help much but it doesn't hurt much either. > > > > > > Andy > > > > > > > > On Thu, Aug 18, 2016 at 11:35 AM, Susan Hares wrote: > > Alissa: > > Just a little input you may not know. My background is 15 years=20 > (1995-2010) developing a routing/switching platform (denoted as GateD) = which was sold to > over 200 companies. We developed XML and a binary XML based product = that > configured this product. It could do 100K configuration lines and=20 > reboot in less than a second on most hardware. We also provide status = messages in > secure streams and non-secure streams. I sold early version of this = code > to companies that Alia has worked for - so she has personal viewed = the > code. At the height of our work, our development team ran to 50 = people > which I directed (First as VP of Engineering, and then as CTO). It is = due to > this level of experience that Alia selected me for the co-chair. = Russ > White has understood Cisco's process, and has also directed software=20 > development teams for routing. > > In order to freshen my direct experience with I2RS on open source=20 > work, I am working on a publically available work in Quagga based on=20 > the confD product suggested by Cisco. > > In contrast, Juergen is a university professor who has worked on > proto-types. He is not working on an implementation. I hope he = will. > > I hope you will consider this background in my response to your=20 > comments below. > > Sue > > > -----Original Message----- > From: Alissa Cooper [mailto:alissa@cooperw.in] > Sent: Thursday, August 18, 2016 12:54 PM > To: Joel Halpern > Cc: Susan Hares; Juergen Schoenwaelder; i2rs@ietf.org;=20 > i2rs-chairs@ietf.org; Kathleen Moriarty; IESG; jhaas@pfrc.org;=20 > 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) > > Jumping in here because this is relevant to my DISCUSS, hope nobody=20 > minds (but if you do, I can go back to the other thread). > >>> On Aug 18, 2016, at 10:30 AM, Joel Halpern=20 >>> >>> wrote: >>> >>> Let me try a different take approach to this particular question. >>> >>> Let me start by putting aside the question of where things are=20 >>> marked, and come back to that afterwards. >>> >>> There are a number of cases that I2RS has been asked to cover of=20 >>> high rate telemetry data. This may be BGP update information, it=20 >>> may be frequent information about line card activity. There are=20 >>> other cases, some of which have been documented. >>> >>> While not completely insensitive, the operators have made clear that = >>> they see protecting this data as unnecessary. While I would hope=20 >>> over time to move to a domain where all of it is protect, that is=20 >>> not trivial. As the I2RS Architecture points out, it is expected=20 >>> that what we describe as a single I2RS >communication between a=20 >>> client and agent is actually associated with multiple channels of = communication. >>> >>> Now, if you want to say that the I2RS protocol requirements cannot=20 >>> allow for unprotected channels, I guess we have disconnect between=20 >>> the IESG and the WG. >>> >>> If we say that we can allow for unprotected channels, we then get to = >>> the question of which data can be sent over such channels. While=20 >>> architecturally I agree with Juergen that the model is a bad place=20 >>> to specify it, the obverse is also true. Not having some limits on=20 >>> what can be sent unprotected >causes concern about insufficient=20 >>> protection. If I recall correctly, earlier security reviews called=20 >>> us to task for being too broad in what we allowed. >>> >>> So, if the IESG wants us to just allow it anywhere, because the=20 >>> model is an awkward place to define the limitation, I can live with=20 >>> that. What I can't live with is being told both that the model is a = >>> bad place to define it and that there must be restrictions on what=20 >>> is sent unprotected, without any proposal on how we are to move = forward. > >> Thank you Joel, this explanation helps me a lot. I think there is a=20 >> disconnect about how the restrictions are expressed. From reading the = >> email traffic about this document, it strikes me that trying to=20 >> express the restrictions programmatically doesn=E2=80=99t make much = sense in this case. >> I agree with Juergen that it will be challenging to make a judgment a = >> priori in order to bake a restriction into a data model, because data = >> that is considered sensitive enough to warrant a secure transport in=20 >> one deployment may not be considered sensitive in another deployment. >> So for any data elements where there is any question at all about=20 >> whether they might be sensitive (i.e., any data elements that are not = >> already routinely made public), I would expect data model authors to=20 >> end up indicating that they may be sent over either secure or=20 >> insecure transport, which renders the indication not useful. >> Perhaps it would make more sense then to just enumerate in the text=20 >> the cases that motivate the inclusion of protocol support for=20 >> insecure >> transport: >> >> 1. For conveyance of information that is already routinely made = public. >> 2. For line card activity data where there is no likely upgrade path=20 >> to support secure transports in the foreseeable future. >> >> Then the normative requirements would be on clients and agents to use = >> secure transports unless those clients and agents are deployed where=20 >> either of the operational circumstances above necessitate otherwise. >> Alissa > > Point 1: > I disagree with Juergen on the difficulty in specifying the sections=20 > of the yang modules. I have provided a suggested solution in: > = https://tools.ietf.org/html/draft-hares-i2rs-protocol-strawman-03#section= -4.5.2. > > Given the mount schema functionality, we can mount ephemeral state=20 > module which augment non-ephemeral state modules which are "in-secure = only". > > Point 2: > I am willing to put an enumeration of the use cases in the protocol=20 > requirement, but I would like to understand the purpose for the = enumeration. > We are not doing a use case, but a requirements document. This = information > appears to be a "use case" rather than a technical description. What > purpose are you looking for this enumeration to server. Are you=20 > looking for the enumeration in SEC-REQ-08? > > Point 3: Could you review -08.txt on this topic, especially the text = below. > Given your comments, I believe I should change the last line to a = MUST. > New/ The default mode of transport is > secure so data models MUST clearly annotate what data nodes can be > passed over an insecure connection. > / > > Sue > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > As to the normative requirements (-08.txt) version: > > Section 3: > > I2RS allows the use of an insecure transport for portions of data > models that clearly indicate the use of an insecure transport. > Operators deploying I2RS must determine if they want to populate = and > deploy the portions of the data model which use insecure = transports. > > In Section 3.2 in version -08.txt > > SEC-REQ-08: The I2RS protocol MUST be able to transfer data over a > secure transport and optionally MAY be able to transfer data over a > non-secure transport. A secure transport MUST provide data > confidentiality, data integrity, and replay prevention. > > The default I2RS transport is a secure transport. > > 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. > > The configuration of ephemeral data in the I2RS Agent by the I2RS > client SHOULD be done over a secure transport. It is anticipated > that the passing of most I2RS ephemeral state operational status > SHOULD be done over a secure transport. As > [I-D.ietf-i2rs-ephemeral-state] notes, a data model MUST indicate > whether the transport exchanging the data between I2RS client and > I2RS agent is secure or insecure. > > The default mode of transport is > secure so data models SHOULD clearly annotate what data nodes can = be > passed over an insecure connection. > >> >> Yours, >> Joel >> >> -----Original Message----- >> From: Susan Hares [mailto:shares@ndzh.com] >> Sent: Thursday, August 18, 2016 9:17 AM >> To: 'Juergen Schoenwaelder' >> Cc: i2rs@ietf.org; i2rs-chairs@ietf.org; 'Kathleen Moriarty' >> ; 'The IESG' ;=20 >> jhaas@pfrc.org;=20 >> 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) >> >> Juergen and Kathleen: >> >> Let me proceed with two examples: BGP route views data model and the=20 >> event for the web-service data. >> >> The content of these data models are designated as exposed to public. = =20 >> The routing system only populates the proposed BGP route views data=20 >> model with the data destined for the BGP looking glass. The policy=20 >> on the routing system indicates what information gets transferred. =20 >> The data model is completely available to the public. The Yang=20 >> Doctors are going to review this by seeing the whole model is public = and available via non-secure means. >> The security people are going to review this seeing that the whole=20 >> model is public, and available via an unprotect means. The fact the=20 >> data model is all public should simplify the review. >> >> An event from the I2RS RIB that a web-service route is up is the=20 >> second case. The I2RS RIB has an event based on policy that=20 >> indicates a web-service route is up. The yang-1.1 doctors must=20 >> review the content of the event text to see it does not break privacy = or provide too much >> information The event mechanisms will need to work over secure = transport >> and insecure transport. Most of the data will go over the secure=20 >> transport event stream. However, a small amount of information may go = >> over the insecure transport stream. >> >> First, let me know if my use cases are understandable. Second, let=20 >> me know if you disagree with this use cases. >> >> Fyi - IESG approved the architecture with the insecure stream. >> >> Sue >> >> -----Original Message----- >> From: Juergen Schoenwaelder >> [mailto:j.schoenwaelder@jacobs-university.de] >> Sent: Thursday, August 18, 2016 9:06 AM >> To: Susan Hares >> Cc: i2rs@ietf.org; i2rs-chairs@ietf.org; 'Kathleen Moriarty'; 'The=20 >> IESG'; jhaas@pfrc.org;=20 >> 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) >> >> I just do not know on which basis a data model writer can decide=20 >> whether a data object can be exposed in an unprotected way. How are=20 >> YANG doctors going to review this? How are security directorate=20 >> people going to judge this? But as promised, I leave (still puzzled) = now. >> >> /js >> >> On Thu, Aug 18, 2016 at 09:00:14AM -0400, Susan Hares wrote: >>> Juergen: >>> >>> Yes, we seem to disagree on the value of making it hardwired in the=20 >>> model. >>> For me, the value is a common understanding of deployment=20 >>> distribution >> such >>> as the route-views. Since the operators argued strongly for this = point, >> I >>> think the best idea is to get it working in code and then see if the = >>> deployment matches the requests. >>> >>> Sue >>> >>> -----Original Message----- >>> From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Juergen=20 >>> Schoenwaelder >>> Sent: Thursday, August 18, 2016 8:14 AM >>> To: Susan Hares >>> Cc: i2rs@ietf.org; i2rs-chairs@ietf.org; 'Kathleen Moriarty'; 'The=20 >>> IESG'; jhaas@pfrc.org;=20 >>> 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) >>> >>> Sue, >>> >>> I still do not see why the 'mode of exposure' of data benefits from=20 >>> being hard-wired in the data model. For me, it is a situational and=20 >>> deployment specific question. But I shut up here since I aired this=20 >>> concern before (and we simply seem to disagree). >>> >>> /js >>> >>> On Thu, Aug 18, 2016 at 08:07:18AM -0400, Susan Hares wrote: >>>> Juergen: >>>> >>>> My example is the looking glass servers for the BGP route views=20 >>>> project >>>> (http://www.routeviews.org/) or a route indicating the presence of = a >>>> web-server that is public. For the BGP I2RS route, a yang model = could >>>> replace the looking glass function, and provide events for these = looking >>>> glass functions. For the web-server route, an event be sent = when >> that >>>> one route is added. >>>> >>>> Sue >>>> >>>> >>>> -----Original Message----- >>>> From: Juergen Schoenwaelder >>>> [mailto:j.schoenwaelder@jacobs-university.de] >>>> Sent: Thursday, August 18, 2016 3:32 AM >>>> To: Susan Hares >>>> Cc: 'Kathleen Moriarty'; 'The IESG'; jhaas@pfrc.org; i2rs@ietf.org; = >>>> i2rs-chairs@ietf.org;=20 >>>> 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=20 >>>> and >>>> COMMENT) >>>> >>>> On Wed, Aug 17, 2016 at 09:16:48PM -0400, Susan Hares wrote: >>>>> ------------------------------------------------------------------ >>>>> -- >>>>> -- >>>>> COMMENT: >>>>> ------------------------------------------------------------------ >>>>> -- >>>>> -- >>>>> >>>>>> Section 3: >>>>>> Can you clarify the second to last sentence? Do you mean there=20 >>>>>> are >>>> sections that indicate an insecure transport should be used? >>>>>> I2RS allows the use of an >>>>>> insecure transport for portions of data models that clearly=20 >>>>>> indicate insecure transport. >>>>> >>>>>> Perhaps: >>>>>> I2RS allows the use of an >>>>>> insecure transport for portions of data models that clearly=20 >>>>>> indicate the use of an insecure transport. >>>> >>>> I still wonder how a data model writer can reasonably decide=20 >>>> whether a piece of information can be shipped safely over an=20 >>>> insecure transport since this decision often depends on the=20 >>>> specifics of a deployment >>> situation. >>>> >>>> /js >>>> >>>> PS: I hope we do not end up with defining data multiple times (once >>>> for insecure transport and once for secured transports). >>>> >>>> -- >>>> Juergen Schoenwaelder Jacobs University Bremen gGmbH >>>> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | = Germany >>>> Fax: +49 421 200 3103 >>>> >>>> _______________________________________________ >>>> i2rs mailing list >>>> i2rs@ietf.org >>>> https://www.ietf.org/mailman/listinfo/i2rs >>> >>> -- >>> Juergen Schoenwaelder Jacobs University Bremen gGmbH >>> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | = Germany >>> Fax: +49 421 200 3103 >>> >>> _______________________________________________ >>> i2rs mailing list >>> i2rs@ietf.org >>> https://www.ietf.org/mailman/listinfo/i2rs >>> >> >> -- >> Juergen Schoenwaelder Jacobs University Bremen gGmbH >> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | = Germany >> Fax: +49 421 200 3103 >> > > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs > > > > --=20 Best regards, Kathleen From nobody Fri Aug 19 05:09:58 2016 Return-Path: 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 616BF12D5C7; Fri, 19 Aug 2016 05:08:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.738 X-Spam-Level: * X-Spam-Status: No, score=1.738 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, RDNS_NONE=0.793] autolearn=no 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 zv6V4mvRnSUN; Fri, 19 Aug 2016 05:08:47 -0700 (PDT) Received: from hickoryhill-consulting.com (unknown [50.245.122.97]) (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 B58C0126FDC; Fri, 19 Aug 2016 05:08:46 -0700 (PDT) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=184.157.82.170; From: "Susan Hares" To: "'Lou Berger'" , "'Juergen Schoenwaelder'" References: <013b01d1f8ee$31fa09b0$95ee1d10$@ndzh.com> <20160818073203.GA4338@elstar.local> <04b501d1f949$116c63e0$34452ba0$@ndzh.com> <20160818121405.GA5282@elstar.local> <051301d1f950$7739c670$65ad5350$@ndzh.com> <20160818130555.GA5366@elstar.local> <051701d1f952$c4ae0b30$4e0a2190$@ndzh.com> <6BCE198E4EAEFC4CAB45D75826EFB0761525CCD7@eusaamb101.ericsson.se> <003801d1f97f$3d16eb10$b744c130$@ndzh.com> <20160819085756.GA6759@elstar.local> <01e501d1fa07$6d613fe0$4823bfa0$@ndzh.com> <9c53ff98-3268-f6e2-fbe6-862fc3948794@labn.net> In-Reply-To: <9c53ff98-3268-f6e2-fbe6-862fc3948794@labn.net> Date: Fri, 19 Aug 2016 08:07:12 -0400 Message-ID: <027a01d1fa12$3879b270$a96d1750$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJ/RF5y8kBC7R3sO+auWKe566R2lwEcb/3KAg+ndAACAypBUwGJSPf4Amiv8FwDJLAGjQJqExQkAqfTovACEJToAwFDCzFbAlTVyfQCrq8/9J4oH36w Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: X-Mailman-Approved-At: Fri, 19 Aug 2016 05:09:57 -0700 Cc: i2rs@ietf.org, 'Alissa Cooper' , i2rs-chairs@ietf.org, 'Kathleen Moriarty' , 'IESG' , jhaas@pfrc.org, '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) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Aug 2016 12:08:49 -0000 Lou:=20 I am clear that Juergen does not want not want to place transport = requirements within the data model for NETMOD. His opinion was = considered in the rough for the I2RS WG. If this requirement is a = problem for NETCONF/NETMOD, the text currently says:=20 REQ-SEC-09 states:=20 The default mode of transport is secure so data models SHOULD clearly = annotate what data nodes can be passed over an insecure connection. However, if this means the NETCONF/NETMOD WG will not even entertain = proposal for marking the insecure functions in yang text -- then the two = WG (I2RS/NETMOD) have a problem and should stop this standardization = process going forward. =20 Sue=20 -----Original Message----- From: Lou Berger [mailto:lberger@labn.net]=20 Sent: Friday, August 19, 2016 7:34 AM To: Susan Hares; 'Juergen Schoenwaelder' Cc: i2rs@ietf.org; 'Alissa Cooper'; i2rs-chairs@ietf.org; 'Kathleen = Moriarty'; 'IESG'; jhaas@pfrc.org; '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) Sue, I don't see Juergen as arguing against model access via non-secure = transport. I read his point as that the transport security requirements = don't belong scattered within a data model. I have to say that from a model complexity (definition, process, review, = implementation - take your pick) , language and NETMOD co-chair = perspective, his comment resonates with me. I think this makes the key text: The default mode of transport is secure so data models SHOULD clearly annotate what data nodes can be passed over an insecure connection. As this isn't a MUST, I personally think we can live with the text and = we can debate the issue further in the context of specific solutions. I = would strongly object to this being changed to a MUST, or if the = document is changed to make transport (security) requirements identified = within data models a requirement. Lou On 8/19/2016 6:49 AM, Susan Hares wrote: > Juergen: > > You have laid out the two options: a) link the data-model to the = non-secure transport, and b) do not link the data to the non-secure = transport. I agree with you that past models did not link past SNMP = MIB data model to the transport. Existing NETCONF models do not link it = to the transport. As you have indicated, you disagreed in the I2RS WG = and we found consensus was to include the non-secure transport.=20 > > I2RS was created to build things as an interface to the routing = environment. The operators clearly informed the I2RS group of this = need during the requirement setting phase prior to the time I was chair. = The reason I continue to press for this capability is their input, and = the existing use cases I listed previously in this mail: > > a) public information - BGP route views, > b) specific well know up events - such as public-web site up > c) specific network service events - interface to particular public = LAN up.=20 > > As you know, we do not have any I2RS data models that specify this = feature at this time. I suspect after we get through this lengthy = requirement phase, the operators may begin to specify new models that = have this feature. =20 > > Sue > > -----Original Message----- > From: Juergen Schoenwaelder=20 > [mailto:j.schoenwaelder@jacobs-university.de] > Sent: Friday, August 19, 2016 4:58 AM > To: Susan Hares > Cc: 'Alissa Cooper'; 'Joel Halpern'; i2rs@ietf.org;=20 > i2rs-chairs@ietf.org; 'Kathleen Moriarty'; 'IESG'; jhaas@pfrc.org;=20 > draft-ietf-i2rs-protocol-security-requirements@ietf.org > Subject: Re: [i2rs] Kathleen Moriarty's Discuss on=20 > draft-ietf-i2rs-protocol-security-requirements-07: (with DISCUSS and=20 > COMMENT) > > I repeat my technical argument: While there may be deployments where = non-secure transports may be reasonable to use, defining these = situations statically as part of data model schemas does not follow = established practices. The IETF has a long tradition of standardizing = data models that can be used in a variety of operational contexts and I = do not see reasons why we should move away from that basic approach. > > /js > > On Thu, Aug 18, 2016 at 02:35:03PM -0400, Susan Hares wrote: >> Alissa:=20 >> >> Just a little input you may not know. My background is 15 years = (1995-2010) developing a routing/switching platform (denoted as GateD) = which was sold to over 200 companies. We developed XML and a binary = XML based product that configured this product. It could do 100K = configuration lines and reboot in less than a second on most hardware. = We also provide status messages in secure streams and non-secure = streams. I sold early version of this code to companies that Alia has = worked for - so she has personal viewed the code. At the height of = our work, our development team ran to 50 people which I directed (First = as VP of Engineering, and then as CTO). It is due to this level of = experience that Alia selected me for the co-chair. Russ White has = understood Cisco's process, and has also directed software development = teams for routing.=20 >> >> In order to freshen my direct experience with I2RS on open source = work, I am working on a publically available work in Quagga based on the = confD product suggested by Cisco.=20 >> >> In contrast, Juergen is a university professor who has worked on = proto-types. He is not working on an implementation. I hope he will. = >> >> I hope you will consider this background in my response to your = comments below.=20 >> >> Sue >> >> >> -----Original Message----- >> From: Alissa Cooper [mailto:alissa@cooperw.in] >> Sent: Thursday, August 18, 2016 12:54 PM >> To: Joel Halpern >> Cc: Susan Hares; Juergen Schoenwaelder; i2rs@ietf.org;=20 >> i2rs-chairs@ietf.org; Kathleen Moriarty; IESG; jhaas@pfrc.org;=20 >> 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) >> >> Jumping in here because this is relevant to my DISCUSS, hope nobody = minds (but if you do, I can go back to the other thread). >> >>>> On Aug 18, 2016, at 10:30 AM, Joel Halpern = wrote: >>>> >>>> Let me try a different take approach to this particular question. >>>> >>>> Let me start by putting aside the question of where things are = marked, and come back to that afterwards. >>>> >>>> There are a number of cases that I2RS has been asked to cover of = high rate telemetry data. This may be BGP update information, it may be = frequent information about line card activity. There are other cases, = some of which have been documented. >>>> >>>> While not completely insensitive, the operators have made clear = that they see protecting this data as unnecessary. While I would hope = over time to move to a domain where all of it is protect, that is not = trivial. As the I2RS Architecture points out, it is expected that what = we describe as a single I2RS >communication between a client and agent = is actually associated with multiple channels of communication. >>>> >>>> Now, if you want to say that the I2RS protocol requirements cannot = allow for unprotected channels, I guess we have disconnect between the = IESG and the WG. >>>> >>>> If we say that we can allow for unprotected channels, we then get = to the question of which data can be sent over such channels. While = architecturally I agree with Juergen that the model is a bad place to = specify it, the obverse is also true. Not having some limits on what = can be sent unprotected >causes concern about insufficient protection. = If I recall correctly, earlier security reviews called us to task for = being too broad in what we allowed. >>>> >>>> So, if the IESG wants us to just allow it anywhere, because the=20 >>>> model is an awkward place to define the limitation, I can live with = that. What I can't live with is being told both that the model is a bad = place to define it and that there must be restrictions on what is sent = unprotected, without any proposal on how we are to move forward. >>> Thank you Joel, this explanation helps me a lot. I think there is a = disconnect about how the restrictions are expressed. From reading the = email traffic about this document, it strikes me that trying to express = the restrictions programmatically doesn=E2=80=99t make much sense in = this case.=20 >>> I agree with Juergen that it will be challenging to make a judgment = a priori in order to bake a restriction into a data model, because data = that is considered sensitive enough to warrant a secure transport in one = deployment may not be considered sensitive in another deployment.=20 >>> So for any data elements where there is any question at all about=20 >>> whether they might be sensitive (i.e., any data elements that are = not already routinely made public), I would expect data model authors to = end up indicating that they may be sent over either secure or insecure = transport, which renders the indication not useful. >>> Perhaps it would make more sense then to just enumerate in the text = the cases that motivate the inclusion of protocol support for insecure = transport: >>> >>> 1. For conveyance of information that is already routinely made = public. >>> 2. For line card activity data where there is no likely upgrade path = to support secure transports in the foreseeable future. >>> >>> Then the normative requirements would be on clients and agents to = use secure transports unless those clients and agents are deployed where = either of the operational circumstances above necessitate otherwise. >>> Alissa >> Point 1:=20 >> I disagree with Juergen on the difficulty in specifying the sections = of the yang modules. I have provided a suggested solution in:=20 >> = https://tools.ietf.org/html/draft-hares-i2rs-protocol-strawman-03#section= -4.5.2. =20 >> >> Given the mount schema functionality, we can mount ephemeral state = module which augment non-ephemeral state modules which are "in-secure = only". =20 >> >> Point 2:=20 >> I am willing to put an enumeration of the use cases in the protocol = requirement, but I would like to understand the purpose for the = enumeration. We are not doing a use case, but a requirements document. = This information appears to be a "use case" rather than a technical = description. What purpose are you looking for this enumeration to = server. Are you looking for the enumeration in SEC-REQ-08?=20 >> >> Point 3: Could you review -08.txt on this topic, especially the text = below. Given your comments, I believe I should change the last line to = a MUST.=20 >> New/ The default mode of transport is >> secure so data models MUST clearly annotate what data nodes can be >> passed over an insecure connection. >> / >> >> Sue >> >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> As to the normative requirements (-08.txt) version:=20 >> >> Section 3:=20 >> =20 >> I2RS allows the use of an insecure transport for portions of data >> models that clearly indicate the use of an insecure transport. >> Operators deploying I2RS must determine if they want to populate = and >> deploy the portions of the data model which use insecure = transports. >> >> In Section 3.2 in version -08.txt >> >> SEC-REQ-08: The I2RS protocol MUST be able to transfer data over a >> secure transport and optionally MAY be able to transfer data over = a >> non-secure transport. A secure transport MUST provide data >> confidentiality, data integrity, and replay prevention. >> >> The default I2RS transport is a secure transport. >> >> 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. >> >> The configuration of ephemeral data in the I2RS Agent by the I2RS >> client SHOULD be done over a secure transport. It is anticipated >> that the passing of most I2RS ephemeral state operational status >> SHOULD be done over a secure transport. As >> [I-D.ietf-i2rs-ephemeral-state] notes, a data model MUST indicate >> whether the transport exchanging the data between I2RS client and >> I2RS agent is secure or insecure. =20 >> >> The default mode of transport is >> secure so data models SHOULD clearly annotate what data nodes can = be >> passed over an insecure connection. >> >>> Yours, >>> Joel >>> >>> -----Original Message----- >>> From: Susan Hares [mailto:shares@ndzh.com] >>> Sent: Thursday, August 18, 2016 9:17 AM >>> To: 'Juergen Schoenwaelder' >>> Cc: i2rs@ietf.org; i2rs-chairs@ietf.org; 'Kathleen Moriarty'=20 >>> ; 'The IESG' ;=20 >>> jhaas@pfrc.org;=20 >>> 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) >>> >>> Juergen and Kathleen:=20 >>> >>> Let me proceed with two examples: BGP route views data model and the = event for the web-service data. =20 >>> >>> The content of these data models are designated as exposed to = public. The routing system only populates the proposed BGP route views = data model with the data destined for the BGP looking glass. The policy = on the routing system indicates what information gets transferred. The = data model is completely available to the public. The Yang Doctors are = going to review this by seeing the whole model is public and available = via non-secure means. >>> The security people are going to review this seeing that the whole = model is public, and available via an unprotect means. The fact the = data model is all public should simplify the review.=20 >>> >>> An event from the I2RS RIB that a web-service route is up is the = second case. The I2RS RIB has an event based on policy that indicates a = web-service route is up. The yang-1.1 doctors must review the content = of the event text to see it does not break privacy or provide too much >>> information The event mechanisms will need to work over secure = transport >>> and insecure transport. Most of the data will go over the secure = transport event stream. However, a small amount of information may go = over the insecure transport stream.=20 >>> >>> First, let me know if my use cases are understandable. Second, let = me know if you disagree with this use cases.=20 >>> >>> Fyi - IESG approved the architecture with the insecure stream.=20 >>> >>> Sue >>> >>> -----Original Message----- >>> From: Juergen Schoenwaelder >>> [mailto:j.schoenwaelder@jacobs-university.de] >>> Sent: Thursday, August 18, 2016 9:06 AM >>> To: Susan Hares >>> Cc: i2rs@ietf.org; i2rs-chairs@ietf.org; 'Kathleen Moriarty'; 'The=20 >>> IESG'; jhaas@pfrc.org;=20 >>> 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) >>> >>> I just do not know on which basis a data model writer can decide = whether a data object can be exposed in an unprotected way. How are YANG = doctors going to review this? How are security directorate people going = to judge this? But as promised, I leave (still puzzled) now. >>> >>> /js >>> >>> On Thu, Aug 18, 2016 at 09:00:14AM -0400, Susan Hares wrote: >>>> Juergen:=20 >>>> >>>> Yes, we seem to disagree on the value of making it hardwired in the = model. >>>> For me, the value is a common understanding of deployment=20 >>>> distribution >>> such >>>> as the route-views. Since the operators argued strongly for this = point, >>> I >>>> think the best idea is to get it working in code and then see if=20 >>>> the deployment matches the requests. >>>> >>>> Sue >>>> >>>> -----Original Message----- >>>> From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Juergen=20 >>>> Schoenwaelder >>>> Sent: Thursday, August 18, 2016 8:14 AM >>>> To: Susan Hares >>>> Cc: i2rs@ietf.org; i2rs-chairs@ietf.org; 'Kathleen Moriarty'; 'The=20 >>>> IESG'; jhaas@pfrc.org;=20 >>>> 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=20 >>>> and >>>> COMMENT) >>>> >>>> Sue, >>>> >>>> I still do not see why the 'mode of exposure' of data benefits from = >>>> being hard-wired in the data model. For me, it is a situational and = >>>> deployment specific question. But I shut up here since I aired this = >>>> concern before (and we simply seem to disagree). >>>> >>>> /js >>>> >>>> On Thu, Aug 18, 2016 at 08:07:18AM -0400, Susan Hares wrote: >>>>> Juergen:=20 >>>>> >>>>> My example is the looking glass servers for the BGP route views=20 >>>>> project >>>>> (http://www.routeviews.org/) or a route indicating the presence of = a >>>>> web-server that is public. For the BGP I2RS route, a yang model = could >>>>> replace the looking glass function, and provide events for these = looking >>>>> glass functions. For the web-server route, an event be sent = when >>> that >>>>> one route is added. =20 >>>>> >>>>> Sue >>>>> >>>>> >>>>> -----Original Message----- >>>>> From: Juergen Schoenwaelder >>>>> [mailto:j.schoenwaelder@jacobs-university.de] >>>>> Sent: Thursday, August 18, 2016 3:32 AM >>>>> To: Susan Hares >>>>> Cc: 'Kathleen Moriarty'; 'The IESG'; jhaas@pfrc.org;=20 >>>>> i2rs@ietf.org; i2rs-chairs@ietf.org;=20 >>>>> 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=20 >>>>> and >>>>> COMMENT) >>>>> >>>>> On Wed, Aug 17, 2016 at 09:16:48PM -0400, Susan Hares wrote: >>>>>> ----------------------------------------------------------------- >>>>>> - >>>>>> -- >>>>>> -- >>>>>> COMMENT: >>>>>> ----------------------------------------------------------------- >>>>>> - >>>>>> -- >>>>>> -- >>>>>> >>>>>>> Section 3:=20 >>>>>>> Can you clarify the second to last sentence? Do you mean there=20 >>>>>>> are >>>>> sections that indicate an insecure transport should be used? >>>>>>> I2RS allows the use of an >>>>>>> insecure transport for portions of data models that clearly=20 >>>>>>> indicate insecure transport. >>>>>>> Perhaps: >>>>>>> I2RS allows the use of an >>>>>>> insecure transport for portions of data models that clearly=20 >>>>>>> indicate the use of an insecure transport. >>>>> I still wonder how a data model writer can reasonably decide=20 >>>>> whether a piece of information can be shipped safely over an=20 >>>>> insecure transport since this decision often depends on the=20 >>>>> specifics of a deployment >>>> situation. >>>>> /js >>>>> >>>>> PS: I hope we do not end up with defining data multiple times = (once >>>>> for insecure transport and once for secured transports). >>>>> >>>>> --=20 >>>>> Juergen Schoenwaelder Jacobs University Bremen gGmbH >>>>> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | = Germany >>>>> Fax: +49 421 200 3103 >>>>> >>>>> _______________________________________________ >>>>> i2rs mailing list >>>>> i2rs@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/i2rs >>>> --=20 >>>> Juergen Schoenwaelder Jacobs University Bremen gGmbH >>>> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | = Germany >>>> Fax: +49 421 200 3103 >>>> >>>> _______________________________________________ >>>> i2rs mailing list >>>> i2rs@ietf.org >>>> https://www.ietf.org/mailman/listinfo/i2rs >>>> >>> --=20 >>> Juergen Schoenwaelder Jacobs University Bremen gGmbH >>> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | = Germany >>> Fax: +49 421 200 3103 >>> >> From nobody Fri Aug 19 05:46:40 2016 Return-Path: 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 A804B12D0DD for ; Fri, 19 Aug 2016 05:32:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 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_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=labn.net 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 HyDhLfXZQG2k for ; Fri, 19 Aug 2016 05:32:10 -0700 (PDT) Received: from qproxy1-pub.mail.unifiedlayer.com (qproxy1-pub.mail.unifiedlayer.com [173.254.64.10]) by ietfa.amsl.com (Postfix) with SMTP id 2D3F312D0DF for ; Fri, 19 Aug 2016 05:32:08 -0700 (PDT) Received: (qmail 21468 invoked by uid 0); 19 Aug 2016 12:25:28 -0000 Received: from unknown (HELO cmgw3) (10.0.90.84) by qproxy1.mail.unifiedlayer.com with SMTP; 19 Aug 2016 12:25:28 -0000 Received: from box313.bluehost.com ([69.89.31.113]) by cmgw3 with id Z0LN1t00W2SSUrH010LR6m; Fri, 19 Aug 2016 06:20:28 -0600 X-Authority-Analysis: v=2.1 cv=LOD1Hvm9 c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=IkcTkHD0fZMA:10 a=-NfooI8aBGcA:10 a=uEJ9t1CZtbIA:10 a=7z1cN_iqozsA:10 a=wU2YTnxGAAAA:8 a=48vgC7mUAAAA:8 a=Tg0nUI2_AAAA:8 a=0FD05c-RAAAA:8 a=1sjgXBK7AAAA:8 a=pGLkceISAAAA:8 a=PityYCoGAAAA:8 a=j3Z76cjpAAAA:8 a=waqyYZ1HuuxT3SLEkRUA:9 a=8-fKiKKv2LwgcqhF:21 a=lQixNVdf6IyhhwCD:21 a=QEXdDO2ut3YA:10 a=FvgKqOQ44qUA:10 a=JrSEOxZJtCQA:10 a=-FEs8UIgK8oA:10 a=NWVoK91CQyQA:10 a=Yz9wTY_ffGCQnEDHKrcv:22 a=w1C3t2QeGrPiZgrLijVG:22 a=qRfHG-2J1AYadgyPbmI5:22 a=l1rpMCqCXRGZwUSuRcM3:22 a=qowbMnUzjQcM5iyYROrS:22 a=6kGIvZw6iX1k4Y-7sg4_:22 a=ZO5f8yik10I_Qaw9TOeb:22 a=9ZYBcOd_X9kS2t7VFny2:22 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version :Date:Message-ID:From:Cc:References:To:Subject; bh=SrFdfkLrBsuI2GP9lGeeQw7EJ3m/EXFZ3xBl0DRi61o=; b=aZAyGGgFtm+kiiwDusSYUqn3TL SZbvRJHooj6j7RRQ7Nx1DkDjVnMUyTCwO8E0GrgrhvYe1q7+jeGKoAEUOeZraEu7ijcZdNt3+Atsi k4fw2Ixn98G0bcc/oXr3hd+c5; Received: from box313.bluehost.com ([69.89.31.113]:42238 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.86_2) (envelope-from ) id 1baimc-0006Uz-Qw; Fri, 19 Aug 2016 06:20:23 -0600 To: Susan Hares , 'Juergen Schoenwaelder' References: <013b01d1f8ee$31fa09b0$95ee1d10$@ndzh.com> <20160818073203.GA4338@elstar.local> <04b501d1f949$116c63e0$34452ba0$@ndzh.com> <20160818121405.GA5282@elstar.local> <051301d1f950$7739c670$65ad5350$@ndzh.com> <20160818130555.GA5366@elstar.local> <051701d1f952$c4ae0b30$4e0a2190$@ndzh.com> <6BCE198E4EAEFC4CAB45D75826EFB0761525CCD7@eusaamb101.ericsson.se> <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> From: Lou Berger Message-ID: Date: Fri, 19 Aug 2016 08:20:16 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <027a01d1fa12$3879b270$a96d1750$@ndzh.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - box313.bluehost.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - labn.net X-Source-IP: 69.89.31.113 X-Exim-ID: 1baimc-0006Uz-Qw X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: box313.bluehost.com ([127.0.0.1]) [69.89.31.113]:42238 X-Source-Auth: lberger@labn.net X-Email-Count: 0 X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ== Archived-At: X-Mailman-Approved-At: Fri, 19 Aug 2016 05:46:39 -0700 Cc: i2rs@ietf.org, 'Alissa Cooper' , i2rs-chairs@ietf.org, 'Kathleen Moriarty' , 'IESG' , jhaas@pfrc.org, '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) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Aug 2016 12:32:12 -0000 Sue, My message said three things: 1) Juergen's comment resonates with me. 2) I think the current text is acceptable. 3) I see changing the SHOULD to a MUST as problematic. I understood one of the other messages on this thread proposing this change which is what triggered my message. If I misunderstood that message, feel free to interpret my message as supporting the current text in question. Note that I am only speaking for myself (including in my role as NETMOD co-chair) and not representing the consensus opinion of any WG. Lou On 8/19/2016 8:07 AM, Susan Hares wrote: > Lou: > > I am clear that Juergen does not want not want to place transport requirements within the data model for NETMOD. His opinion was considered in the rough for the I2RS WG. If this requirement is a problem for NETCONF/NETMOD, the text currently says: > > REQ-SEC-09 states: > > The default mode of transport is secure so data models SHOULD clearly annotate what data nodes can be > passed over an insecure connection. > > However, if this means the NETCONF/NETMOD WG will not even entertain proposal for marking the insecure functions in yang text -- then the two WG (I2RS/NETMOD) have a problem and should stop this standardization process going forward. > > Sue > > > -----Original Message----- > From: Lou Berger [mailto:lberger@labn.net] > Sent: Friday, August 19, 2016 7:34 AM > To: Susan Hares; 'Juergen Schoenwaelder' > Cc: i2rs@ietf.org; 'Alissa Cooper'; i2rs-chairs@ietf.org; 'Kathleen Moriarty'; 'IESG'; jhaas@pfrc.org; '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) > > Sue, > > I don't see Juergen as arguing against model access via non-secure transport. I read his point as that the transport security requirements don't belong scattered within a data model. > > I have to say that from a model complexity (definition, process, review, implementation - take your pick) , language and NETMOD co-chair perspective, his comment resonates with me. > > I think this makes the key text: > > The default mode of transport is > secure so data models SHOULD clearly annotate what data nodes can be > passed over an insecure connection. > > > As this isn't a MUST, I personally think we can live with the text and we can debate the issue further in the context of specific solutions. I would strongly object to this being changed to a MUST, or if the document is changed to make transport (security) requirements identified within data models a requirement. > > Lou > > On 8/19/2016 6:49 AM, Susan Hares wrote: >> Juergen: >> >> You have laid out the two options: a) link the data-model to the non-secure transport, and b) do not link the data to the non-secure transport. I agree with you that past models did not link past SNMP MIB data model to the transport. Existing NETCONF models do not link it to the transport. As you have indicated, you disagreed in the I2RS WG and we found consensus was to include the non-secure transport. >> >> I2RS was created to build things as an interface to the routing environment. The operators clearly informed the I2RS group of this need during the requirement setting phase prior to the time I was chair. The reason I continue to press for this capability is their input, and the existing use cases I listed previously in this mail: >> >> a) public information - BGP route views, >> b) specific well know up events - such as public-web site up >> c) specific network service events - interface to particular public LAN up. >> >> As you know, we do not have any I2RS data models that specify this feature at this time. I suspect after we get through this lengthy requirement phase, the operators may begin to specify new models that have this feature. >> >> Sue >> >> -----Original Message----- >> From: Juergen Schoenwaelder >> [mailto:j.schoenwaelder@jacobs-university.de] >> Sent: Friday, August 19, 2016 4:58 AM >> To: Susan Hares >> Cc: 'Alissa Cooper'; 'Joel Halpern'; i2rs@ietf.org; >> i2rs-chairs@ietf.org; 'Kathleen Moriarty'; 'IESG'; jhaas@pfrc.org; >> 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) >> >> I repeat my technical argument: While there may be deployments where non-secure transports may be reasonable to use, defining these situations statically as part of data model schemas does not follow established practices. The IETF has a long tradition of standardizing data models that can be used in a variety of operational contexts and I do not see reasons why we should move away from that basic approach. >> >> /js >> >> On Thu, Aug 18, 2016 at 02:35:03PM -0400, Susan Hares wrote: >>> Alissa: >>> >>> Just a little input you may not know. My background is 15 years (1995-2010) developing a routing/switching platform (denoted as GateD) which was sold to over 200 companies. We developed XML and a binary XML based product that configured this product. It could do 100K configuration lines and reboot in less than a second on most hardware. We also provide status messages in secure streams and non-secure streams. I sold early version of this code to companies that Alia has worked for - so she has personal viewed the code. At the height of our work, our development team ran to 50 people which I directed (First as VP of Engineering, and then as CTO). It is due to this level of experience that Alia selected me for the co-chair. Russ White has understood Cisco's process, and has also directed software development teams for routing. >>> >>> In order to freshen my direct experience with I2RS on open source work, I am working on a publically available work in Quagga based on the confD product suggested by Cisco. >>> >>> In contrast, Juergen is a university professor who has worked on proto-types. He is not working on an implementation. I hope he will. >>> >>> I hope you will consider this background in my response to your comments below. >>> >>> Sue >>> >>> >>> -----Original Message----- >>> From: Alissa Cooper [mailto:alissa@cooperw.in] >>> Sent: Thursday, August 18, 2016 12:54 PM >>> To: Joel Halpern >>> Cc: Susan Hares; Juergen Schoenwaelder; i2rs@ietf.org; >>> i2rs-chairs@ietf.org; Kathleen Moriarty; IESG; jhaas@pfrc.org; >>> 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) >>> >>> Jumping in here because this is relevant to my DISCUSS, hope nobody minds (but if you do, I can go back to the other thread). >>> >>>>> On Aug 18, 2016, at 10:30 AM, Joel Halpern wrote: >>>>> >>>>> Let me try a different take approach to this particular question. >>>>> >>>>> Let me start by putting aside the question of where things are marked, and come back to that afterwards. >>>>> >>>>> There are a number of cases that I2RS has been asked to cover of high rate telemetry data. This may be BGP update information, it may be frequent information about line card activity. There are other cases, some of which have been documented. >>>>> >>>>> While not completely insensitive, the operators have made clear that they see protecting this data as unnecessary. While I would hope over time to move to a domain where all of it is protect, that is not trivial. As the I2RS Architecture points out, it is expected that what we describe as a single I2RS >communication between a client and agent is actually associated with multiple channels of communication. >>>>> >>>>> Now, if you want to say that the I2RS protocol requirements cannot allow for unprotected channels, I guess we have disconnect between the IESG and the WG. >>>>> >>>>> If we say that we can allow for unprotected channels, we then get to the question of which data can be sent over such channels. While architecturally I agree with Juergen that the model is a bad place to specify it, the obverse is also true. Not having some limits on what can be sent unprotected >causes concern about insufficient protection. If I recall correctly, earlier security reviews called us to task for being too broad in what we allowed. >>>>> >>>>> So, if the IESG wants us to just allow it anywhere, because the >>>>> model is an awkward place to define the limitation, I can live with that. What I can't live with is being told both that the model is a bad place to define it and that there must be restrictions on what is sent unprotected, without any proposal on how we are to move forward. >>>> Thank you Joel, this explanation helps me a lot. I think there is a disconnect about how the restrictions are expressed. From reading the email traffic about this document, it strikes me that trying to express the restrictions programmatically doesn’t make much sense in this case. >>>> I agree with Juergen that it will be challenging to make a judgment a priori in order to bake a restriction into a data model, because data that is considered sensitive enough to warrant a secure transport in one deployment may not be considered sensitive in another deployment. >>>> So for any data elements where there is any question at all about >>>> whether they might be sensitive (i.e., any data elements that are not already routinely made public), I would expect data model authors to end up indicating that they may be sent over either secure or insecure transport, which renders the indication not useful. >>>> Perhaps it would make more sense then to just enumerate in the text the cases that motivate the inclusion of protocol support for insecure transport: >>>> >>>> 1. For conveyance of information that is already routinely made public. >>>> 2. For line card activity data where there is no likely upgrade path to support secure transports in the foreseeable future. >>>> >>>> Then the normative requirements would be on clients and agents to use secure transports unless those clients and agents are deployed where either of the operational circumstances above necessitate otherwise. >>>> Alissa >>> Point 1: >>> I disagree with Juergen on the difficulty in specifying the sections of the yang modules. I have provided a suggested solution in: >>> https://tools.ietf.org/html/draft-hares-i2rs-protocol-strawman-03#section-4.5.2. >>> >>> Given the mount schema functionality, we can mount ephemeral state module which augment non-ephemeral state modules which are "in-secure only". >>> >>> Point 2: >>> I am willing to put an enumeration of the use cases in the protocol requirement, but I would like to understand the purpose for the enumeration. We are not doing a use case, but a requirements document. This information appears to be a "use case" rather than a technical description. What purpose are you looking for this enumeration to server. Are you looking for the enumeration in SEC-REQ-08? >>> >>> Point 3: Could you review -08.txt on this topic, especially the text below. Given your comments, I believe I should change the last line to a MUST. >>> New/ The default mode of transport is >>> secure so data models MUST clearly annotate what data nodes can be >>> passed over an insecure connection. >>> / >>> >>> Sue >>> >>> =================== >>> As to the normative requirements (-08.txt) version: >>> >>> Section 3: >>> >>> I2RS allows the use of an insecure transport for portions of data >>> models that clearly indicate the use of an insecure transport. >>> Operators deploying I2RS must determine if they want to populate and >>> deploy the portions of the data model which use insecure transports. >>> >>> In Section 3.2 in version -08.txt >>> >>> SEC-REQ-08: The I2RS protocol MUST be able to transfer data over a >>> secure transport and optionally MAY be able to transfer data over a >>> non-secure transport. A secure transport MUST provide data >>> confidentiality, data integrity, and replay prevention. >>> >>> The default I2RS transport is a secure transport. >>> >>> 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. >>> >>> The configuration of ephemeral data in the I2RS Agent by the I2RS >>> client SHOULD be done over a secure transport. It is anticipated >>> that the passing of most I2RS ephemeral state operational status >>> SHOULD be done over a secure transport. As >>> [I-D.ietf-i2rs-ephemeral-state] notes, a data model MUST indicate >>> whether the transport exchanging the data between I2RS client and >>> I2RS agent is secure or insecure. >>> >>> The default mode of transport is >>> secure so data models SHOULD clearly annotate what data nodes can be >>> passed over an insecure connection. >>> >>>> Yours, >>>> Joel >>>> >>>> -----Original Message----- >>>> From: Susan Hares [mailto:shares@ndzh.com] >>>> Sent: Thursday, August 18, 2016 9:17 AM >>>> To: 'Juergen Schoenwaelder' >>>> Cc: i2rs@ietf.org; i2rs-chairs@ietf.org; 'Kathleen Moriarty' >>>> ; 'The IESG' ; >>>> jhaas@pfrc.org; >>>> 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) >>>> >>>> Juergen and Kathleen: >>>> >>>> Let me proceed with two examples: BGP route views data model and the event for the web-service data. >>>> >>>> The content of these data models are designated as exposed to public. The routing system only populates the proposed BGP route views data model with the data destined for the BGP looking glass. The policy on the routing system indicates what information gets transferred. The data model is completely available to the public. The Yang Doctors are going to review this by seeing the whole model is public and available via non-secure means. >>>> The security people are going to review this seeing that the whole model is public, and available via an unprotect means. The fact the data model is all public should simplify the review. >>>> >>>> An event from the I2RS RIB that a web-service route is up is the second case. The I2RS RIB has an event based on policy that indicates a web-service route is up. The yang-1.1 doctors must review the content of the event text to see it does not break privacy or provide too much >>>> information The event mechanisms will need to work over secure transport >>>> and insecure transport. Most of the data will go over the secure transport event stream. However, a small amount of information may go over the insecure transport stream. >>>> >>>> First, let me know if my use cases are understandable. Second, let me know if you disagree with this use cases. >>>> >>>> Fyi - IESG approved the architecture with the insecure stream. >>>> >>>> Sue >>>> >>>> -----Original Message----- >>>> From: Juergen Schoenwaelder >>>> [mailto:j.schoenwaelder@jacobs-university.de] >>>> Sent: Thursday, August 18, 2016 9:06 AM >>>> To: Susan Hares >>>> Cc: i2rs@ietf.org; i2rs-chairs@ietf.org; 'Kathleen Moriarty'; 'The >>>> IESG'; jhaas@pfrc.org; >>>> 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) >>>> >>>> I just do not know on which basis a data model writer can decide whether a data object can be exposed in an unprotected way. How are YANG doctors going to review this? How are security directorate people going to judge this? But as promised, I leave (still puzzled) now. >>>> >>>> /js >>>> >>>> On Thu, Aug 18, 2016 at 09:00:14AM -0400, Susan Hares wrote: >>>>> Juergen: >>>>> >>>>> Yes, we seem to disagree on the value of making it hardwired in the model. >>>>> For me, the value is a common understanding of deployment >>>>> distribution >>>> such >>>>> as the route-views. Since the operators argued strongly for this point, >>>> I >>>>> think the best idea is to get it working in code and then see if >>>>> the deployment matches the requests. >>>>> >>>>> Sue >>>>> >>>>> -----Original Message----- >>>>> From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Juergen >>>>> Schoenwaelder >>>>> Sent: Thursday, August 18, 2016 8:14 AM >>>>> To: Susan Hares >>>>> Cc: i2rs@ietf.org; i2rs-chairs@ietf.org; 'Kathleen Moriarty'; 'The >>>>> IESG'; jhaas@pfrc.org; >>>>> 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) >>>>> >>>>> Sue, >>>>> >>>>> I still do not see why the 'mode of exposure' of data benefits from >>>>> being hard-wired in the data model. For me, it is a situational and >>>>> deployment specific question. But I shut up here since I aired this >>>>> concern before (and we simply seem to disagree). >>>>> >>>>> /js >>>>> >>>>> On Thu, Aug 18, 2016 at 08:07:18AM -0400, Susan Hares wrote: >>>>>> Juergen: >>>>>> >>>>>> My example is the looking glass servers for the BGP route views >>>>>> project >>>>>> (http://www.routeviews.org/) or a route indicating the presence of a >>>>>> web-server that is public. For the BGP I2RS route, a yang model could >>>>>> replace the looking glass function, and provide events for these looking >>>>>> glass functions. For the web-server route, an event be sent when >>>> that >>>>>> one route is added. >>>>>> >>>>>> Sue >>>>>> >>>>>> >>>>>> -----Original Message----- >>>>>> From: Juergen Schoenwaelder >>>>>> [mailto:j.schoenwaelder@jacobs-university.de] >>>>>> Sent: Thursday, August 18, 2016 3:32 AM >>>>>> To: Susan Hares >>>>>> Cc: 'Kathleen Moriarty'; 'The IESG'; jhaas@pfrc.org; >>>>>> i2rs@ietf.org; i2rs-chairs@ietf.org; >>>>>> 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 Wed, Aug 17, 2016 at 09:16:48PM -0400, Susan Hares wrote: >>>>>>> ----------------------------------------------------------------- >>>>>>> - >>>>>>> -- >>>>>>> -- >>>>>>> COMMENT: >>>>>>> ----------------------------------------------------------------- >>>>>>> - >>>>>>> -- >>>>>>> -- >>>>>>> >>>>>>>> Section 3: >>>>>>>> Can you clarify the second to last sentence? Do you mean there >>>>>>>> are >>>>>> sections that indicate an insecure transport should be used? >>>>>>>> I2RS allows the use of an >>>>>>>> insecure transport for portions of data models that clearly >>>>>>>> indicate insecure transport. >>>>>>>> Perhaps: >>>>>>>> I2RS allows the use of an >>>>>>>> insecure transport for portions of data models that clearly >>>>>>>> indicate the use of an insecure transport. >>>>>> I still wonder how a data model writer can reasonably decide >>>>>> whether a piece of information can be shipped safely over an >>>>>> insecure transport since this decision often depends on the >>>>>> specifics of a deployment >>>>> situation. >>>>>> /js >>>>>> >>>>>> PS: I hope we do not end up with defining data multiple times (once >>>>>> for insecure transport and once for secured transports). >>>>>> >>>>>> -- >>>>>> Juergen Schoenwaelder Jacobs University Bremen gGmbH >>>>>> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany >>>>>> Fax: +49 421 200 3103 >>>>>> >>>>>> _______________________________________________ >>>>>> i2rs mailing list >>>>>> i2rs@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/i2rs >>>>> -- >>>>> Juergen Schoenwaelder Jacobs University Bremen gGmbH >>>>> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany >>>>> Fax: +49 421 200 3103 >>>>> >>>>> _______________________________________________ >>>>> i2rs mailing list >>>>> i2rs@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/i2rs >>>>> >>>> -- >>>> Juergen Schoenwaelder Jacobs University Bremen gGmbH >>>> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany >>>> Fax: +49 421 200 3103 >>>> > > > From nobody Fri Aug 19 05:58:38 2016 Return-Path: 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 C51B612D957; Fri, 19 Aug 2016 05:47:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.738 X-Spam-Level: * X-Spam-Status: No, score=1.738 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, RDNS_NONE=0.793] autolearn=no 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 MwbLbTU8RJSN; Fri, 19 Aug 2016 05:47:45 -0700 (PDT) Received: from hickoryhill-consulting.com (unknown [50.245.122.97]) (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 9269712D955; Fri, 19 Aug 2016 05:47:44 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=184.157.82.170; From: "Susan Hares" To: "'Lou Berger'" , "'Juergen Schoenwaelder'" References: <013b01d1f8ee$31fa09b0$95ee1d10$@ndzh.com> <20160818073203.GA4338@elstar.local> <04b501d1f949$116c63e0$34452ba0$@ndzh.com> <20160818121405.GA5282@elstar.local> <051301d1f950$7739c670$65ad5350$@ndzh.com> <20160818130555.GA5366@elstar.local> <051701d1f952$c4ae0b30$4e0a2190$@ndzh.com> <6BCE198E4EAEFC4CAB45D75826EFB0761525CCD7@eusaamb101.ericsson.se> <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> In-Reply-To: Date: Fri, 19 Aug 2016 08:45:25 -0400 Message-ID: <029801d1fa17$8ef8b1f0$acea15d0$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJ/RF5y8kBC7R3sO+auWKe566R2lwEcb/3KAg+ndAACAypBUwGJSPf4Amiv8FwDJLAGjQJqExQkAqfTovACEJToAwFDCzFbAlTVyfQCrq8/9AJKcpLBAq9whFOeAF44MA== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: X-Mailman-Approved-At: Fri, 19 Aug 2016 05:58:36 -0700 Cc: i2rs@ietf.org, 'Alissa Cooper' , i2rs-chairs@ietf.org, 'Kathleen Moriarty' , 'IESG' , jhaas@pfrc.org, '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) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Aug 2016 12:47:48 -0000 Lou:=20 Ok, Thank you for noting these three points. For the IESG, the proposed = text to Kathleen still works. If Kathleen ACKS my message and text, = then I will upload this text in version 9. I also hear the silence = regarding NETMOD WG considering these proposals.=20 Sue =20 -----Original Message----- From: Lou Berger [mailto:lberger@labn.net]=20 Sent: Friday, August 19, 2016 8:20 AM To: Susan Hares; 'Juergen Schoenwaelder' Cc: i2rs@ietf.org; 'Alissa Cooper'; i2rs-chairs@ietf.org; 'Kathleen = Moriarty'; 'IESG'; jhaas@pfrc.org; '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) Sue, My message said three things: 1) Juergen's comment resonates with me. =20 2) I think the current text is acceptable. 3) I see changing the SHOULD to a MUST as problematic. I understood one of the other messages on this thread proposing this change which is what triggered my message. If I misunderstood that message, feel free to interpret my message as supporting the current = text in question. Note that I am only speaking for myself (including in my role as NETMOD co-chair) and not representing the consensus opinion of any WG. Lou On 8/19/2016 8:07 AM, Susan Hares wrote: > Lou:=20 > > I am clear that Juergen does not want not want to place transport = requirements within the data model for NETMOD. His opinion was = considered in the rough for the I2RS WG. If this requirement is a = problem for NETCONF/NETMOD, the text currently says:=20 > > REQ-SEC-09 states:=20 > > The default mode of transport is secure so data models SHOULD = clearly annotate what data nodes can be > passed over an insecure connection. > > However, if this means the NETCONF/NETMOD WG will not even entertain = proposal for marking the insecure functions in yang text -- then the two = WG (I2RS/NETMOD) have a problem and should stop this standardization = process going forward. =20 > > Sue > > > -----Original Message----- > From: Lou Berger [mailto:lberger@labn.net] > Sent: Friday, August 19, 2016 7:34 AM > To: Susan Hares; 'Juergen Schoenwaelder' > Cc: i2rs@ietf.org; 'Alissa Cooper'; i2rs-chairs@ietf.org; 'Kathleen=20 > Moriarty'; 'IESG'; jhaas@pfrc.org; 'Joel Halpern';=20 > draft-ietf-i2rs-protocol-security-requirements@ietf.org > Subject: Re: [i2rs] Kathleen Moriarty's Discuss on=20 > draft-ietf-i2rs-protocol-security-requirements-07: (with DISCUSS and=20 > COMMENT) > > Sue, > > I don't see Juergen as arguing against model access via non-secure = transport. I read his point as that the transport security requirements = don't belong scattered within a data model. > > I have to say that from a model complexity (definition, process, = review, implementation - take your pick) , language and NETMOD co-chair = perspective, his comment resonates with me. > > I think this makes the key text: > > The default mode of transport is > secure so data models SHOULD clearly annotate what data nodes can = be > passed over an insecure connection. > > > As this isn't a MUST, I personally think we can live with the text and = we can debate the issue further in the context of specific solutions. I = would strongly object to this being changed to a MUST, or if the = document is changed to make transport (security) requirements identified = within data models a requirement. > > Lou > > On 8/19/2016 6:49 AM, Susan Hares wrote: >> Juergen: >> >> You have laid out the two options: a) link the data-model to the = non-secure transport, and b) do not link the data to the non-secure = transport. I agree with you that past models did not link past SNMP = MIB data model to the transport. Existing NETCONF models do not link it = to the transport. As you have indicated, you disagreed in the I2RS WG = and we found consensus was to include the non-secure transport.=20 >> >> I2RS was created to build things as an interface to the routing = environment. The operators clearly informed the I2RS group of this = need during the requirement setting phase prior to the time I was chair. = The reason I continue to press for this capability is their input, and = the existing use cases I listed previously in this mail: >> >> a) public information - BGP route views, >> b) specific well know up events - such as public-web site up >> c) specific network service events - interface to particular public = LAN up.=20 >> >> As you know, we do not have any I2RS data models that specify this = feature at this time. I suspect after we get through this lengthy = requirement phase, the operators may begin to specify new models that = have this feature. =20 >> >> Sue >> >> -----Original Message----- >> From: Juergen Schoenwaelder >> [mailto:j.schoenwaelder@jacobs-university.de] >> Sent: Friday, August 19, 2016 4:58 AM >> To: Susan Hares >> Cc: 'Alissa Cooper'; 'Joel Halpern'; i2rs@ietf.org;=20 >> i2rs-chairs@ietf.org; 'Kathleen Moriarty'; 'IESG'; jhaas@pfrc.org;=20 >> 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) >> >> I repeat my technical argument: While there may be deployments where = non-secure transports may be reasonable to use, defining these = situations statically as part of data model schemas does not follow = established practices. The IETF has a long tradition of standardizing = data models that can be used in a variety of operational contexts and I = do not see reasons why we should move away from that basic approach. >> >> /js >> >> On Thu, Aug 18, 2016 at 02:35:03PM -0400, Susan Hares wrote: >>> Alissa:=20 >>> >>> Just a little input you may not know. My background is 15 years = (1995-2010) developing a routing/switching platform (denoted as GateD) = which was sold to over 200 companies. We developed XML and a binary = XML based product that configured this product. It could do 100K = configuration lines and reboot in less than a second on most hardware. = We also provide status messages in secure streams and non-secure = streams. I sold early version of this code to companies that Alia has = worked for - so she has personal viewed the code. At the height of = our work, our development team ran to 50 people which I directed (First = as VP of Engineering, and then as CTO). It is due to this level of = experience that Alia selected me for the co-chair. Russ White has = understood Cisco's process, and has also directed software development = teams for routing.=20 >>> >>> In order to freshen my direct experience with I2RS on open source = work, I am working on a publically available work in Quagga based on the = confD product suggested by Cisco.=20 >>> >>> In contrast, Juergen is a university professor who has worked on = proto-types. He is not working on an implementation. I hope he will. = >>> >>> I hope you will consider this background in my response to your = comments below.=20 >>> >>> Sue >>> >>> >>> -----Original Message----- >>> From: Alissa Cooper [mailto:alissa@cooperw.in] >>> Sent: Thursday, August 18, 2016 12:54 PM >>> To: Joel Halpern >>> Cc: Susan Hares; Juergen Schoenwaelder; i2rs@ietf.org;=20 >>> i2rs-chairs@ietf.org; Kathleen Moriarty; IESG; jhaas@pfrc.org;=20 >>> 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) >>> >>> Jumping in here because this is relevant to my DISCUSS, hope nobody = minds (but if you do, I can go back to the other thread). >>> >>>>> On Aug 18, 2016, at 10:30 AM, Joel Halpern = wrote: >>>>> >>>>> Let me try a different take approach to this particular question. >>>>> >>>>> Let me start by putting aside the question of where things are = marked, and come back to that afterwards. >>>>> >>>>> There are a number of cases that I2RS has been asked to cover of = high rate telemetry data. This may be BGP update information, it may be = frequent information about line card activity. There are other cases, = some of which have been documented. >>>>> >>>>> While not completely insensitive, the operators have made clear = that they see protecting this data as unnecessary. While I would hope = over time to move to a domain where all of it is protect, that is not = trivial. As the I2RS Architecture points out, it is expected that what = we describe as a single I2RS >communication between a client and agent = is actually associated with multiple channels of communication. >>>>> >>>>> Now, if you want to say that the I2RS protocol requirements cannot = allow for unprotected channels, I guess we have disconnect between the = IESG and the WG. >>>>> >>>>> If we say that we can allow for unprotected channels, we then get = to the question of which data can be sent over such channels. While = architecturally I agree with Juergen that the model is a bad place to = specify it, the obverse is also true. Not having some limits on what = can be sent unprotected >causes concern about insufficient protection. = If I recall correctly, earlier security reviews called us to task for = being too broad in what we allowed. >>>>> >>>>> So, if the IESG wants us to just allow it anywhere, because the=20 >>>>> model is an awkward place to define the limitation, I can live = with that. What I can't live with is being told both that the model is = a bad place to define it and that there must be restrictions on what is = sent unprotected, without any proposal on how we are to move forward. >>>> Thank you Joel, this explanation helps me a lot. I think there is a = disconnect about how the restrictions are expressed. From reading the = email traffic about this document, it strikes me that trying to express = the restrictions programmatically doesn=E2=80=99t make much sense in = this case.=20 >>>> I agree with Juergen that it will be challenging to make a judgment = a priori in order to bake a restriction into a data model, because data = that is considered sensitive enough to warrant a secure transport in one = deployment may not be considered sensitive in another deployment.=20 >>>> So for any data elements where there is any question at all about=20 >>>> whether they might be sensitive (i.e., any data elements that are = not already routinely made public), I would expect data model authors to = end up indicating that they may be sent over either secure or insecure = transport, which renders the indication not useful. >>>> Perhaps it would make more sense then to just enumerate in the text = the cases that motivate the inclusion of protocol support for insecure = transport: >>>> >>>> 1. For conveyance of information that is already routinely made = public. >>>> 2. For line card activity data where there is no likely upgrade = path to support secure transports in the foreseeable future. >>>> >>>> Then the normative requirements would be on clients and agents to = use secure transports unless those clients and agents are deployed where = either of the operational circumstances above necessitate otherwise. >>>> Alissa >>> Point 1:=20 >>> I disagree with Juergen on the difficulty in specifying the sections = of the yang modules. I have provided a suggested solution in:=20 >>> = https://tools.ietf.org/html/draft-hares-i2rs-protocol-strawman-03#section= -4.5.2. =20 >>> >>> Given the mount schema functionality, we can mount ephemeral state = module which augment non-ephemeral state modules which are "in-secure = only". =20 >>> >>> Point 2:=20 >>> I am willing to put an enumeration of the use cases in the protocol = requirement, but I would like to understand the purpose for the = enumeration. We are not doing a use case, but a requirements document. = This information appears to be a "use case" rather than a technical = description. What purpose are you looking for this enumeration to = server. Are you looking for the enumeration in SEC-REQ-08?=20 >>> >>> Point 3: Could you review -08.txt on this topic, especially the text = below. Given your comments, I believe I should change the last line to = a MUST.=20 >>> New/ The default mode of transport is >>> secure so data models MUST clearly annotate what data nodes can = be >>> passed over an insecure connection. >>> / >>> >>> Sue >>> >>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>> As to the normative requirements (-08.txt) version:=20 >>> >>> Section 3:=20 >>> =20 >>> I2RS allows the use of an insecure transport for portions of data >>> models that clearly indicate the use of an insecure transport. >>> Operators deploying I2RS must determine if they want to populate = and >>> deploy the portions of the data model which use insecure = transports. >>> >>> In Section 3.2 in version -08.txt >>> >>> SEC-REQ-08: The I2RS protocol MUST be able to transfer data over = a >>> secure transport and optionally MAY be able to transfer data over = a >>> non-secure transport. A secure transport MUST provide data >>> confidentiality, data integrity, and replay prevention. >>> >>> The default I2RS transport is a secure transport. >>> >>> 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. >>> >>> The configuration of ephemeral data in the I2RS Agent by the I2RS >>> client SHOULD be done over a secure transport. It is anticipated >>> that the passing of most I2RS ephemeral state operational status >>> SHOULD be done over a secure transport. As >>> [I-D.ietf-i2rs-ephemeral-state] notes, a data model MUST = indicate >>> whether the transport exchanging the data between I2RS client and >>> I2RS agent is secure or insecure. =20 >>> >>> The default mode of transport is >>> secure so data models SHOULD clearly annotate what data nodes can = be >>> passed over an insecure connection. >>> >>>> Yours, >>>> Joel >>>> >>>> -----Original Message----- >>>> From: Susan Hares [mailto:shares@ndzh.com] >>>> Sent: Thursday, August 18, 2016 9:17 AM >>>> To: 'Juergen Schoenwaelder' >>>> Cc: i2rs@ietf.org; i2rs-chairs@ietf.org; 'Kathleen Moriarty'=20 >>>> ; 'The IESG' ;=20 >>>> jhaas@pfrc.org;=20 >>>> 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=20 >>>> and >>>> COMMENT) >>>> >>>> Juergen and Kathleen:=20 >>>> >>>> Let me proceed with two examples: BGP route views data model and = the event for the web-service data. =20 >>>> >>>> The content of these data models are designated as exposed to = public. The routing system only populates the proposed BGP route views = data model with the data destined for the BGP looking glass. The policy = on the routing system indicates what information gets transferred. The = data model is completely available to the public. The Yang Doctors are = going to review this by seeing the whole model is public and available = via non-secure means. >>>> The security people are going to review this seeing that the whole = model is public, and available via an unprotect means. The fact the = data model is all public should simplify the review.=20 >>>> >>>> An event from the I2RS RIB that a web-service route is up is the = second case. The I2RS RIB has an event based on policy that indicates a = web-service route is up. The yang-1.1 doctors must review the content = of the event text to see it does not break privacy or provide too much >>>> information The event mechanisms will need to work over secure = transport >>>> and insecure transport. Most of the data will go over the secure = transport event stream. However, a small amount of information may go = over the insecure transport stream.=20 >>>> >>>> First, let me know if my use cases are understandable. Second, let = me know if you disagree with this use cases.=20 >>>> >>>> Fyi - IESG approved the architecture with the insecure stream.=20 >>>> >>>> Sue >>>> >>>> -----Original Message----- >>>> From: Juergen Schoenwaelder >>>> [mailto:j.schoenwaelder@jacobs-university.de] >>>> Sent: Thursday, August 18, 2016 9:06 AM >>>> To: Susan Hares >>>> Cc: i2rs@ietf.org; i2rs-chairs@ietf.org; 'Kathleen Moriarty'; 'The=20 >>>> IESG'; jhaas@pfrc.org;=20 >>>> 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=20 >>>> and >>>> COMMENT) >>>> >>>> I just do not know on which basis a data model writer can decide = whether a data object can be exposed in an unprotected way. How are YANG = doctors going to review this? How are security directorate people going = to judge this? But as promised, I leave (still puzzled) now. >>>> >>>> /js >>>> >>>> On Thu, Aug 18, 2016 at 09:00:14AM -0400, Susan Hares wrote: >>>>> Juergen:=20 >>>>> >>>>> Yes, we seem to disagree on the value of making it hardwired in = the model. >>>>> For me, the value is a common understanding of deployment=20 >>>>> distribution >>>> such >>>>> as the route-views. Since the operators argued strongly for this = point, >>>> I >>>>> think the best idea is to get it working in code and then see if=20 >>>>> the deployment matches the requests. >>>>> >>>>> Sue >>>>> >>>>> -----Original Message----- >>>>> From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Juergen=20 >>>>> Schoenwaelder >>>>> Sent: Thursday, August 18, 2016 8:14 AM >>>>> To: Susan Hares >>>>> Cc: i2rs@ietf.org; i2rs-chairs@ietf.org; 'Kathleen Moriarty'; 'The = >>>>> IESG'; jhaas@pfrc.org;=20 >>>>> 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=20 >>>>> and >>>>> COMMENT) >>>>> >>>>> Sue, >>>>> >>>>> I still do not see why the 'mode of exposure' of data benefits=20 >>>>> from being hard-wired in the data model. For me, it is a=20 >>>>> situational and deployment specific question. But I shut up here=20 >>>>> since I aired this concern before (and we simply seem to = disagree). >>>>> >>>>> /js >>>>> >>>>> On Thu, Aug 18, 2016 at 08:07:18AM -0400, Susan Hares wrote: >>>>>> Juergen:=20 >>>>>> >>>>>> My example is the looking glass servers for the BGP route views=20 >>>>>> project >>>>>> (http://www.routeviews.org/) or a route indicating the presence = of a >>>>>> web-server that is public. For the BGP I2RS route, a yang model = could >>>>>> replace the looking glass function, and provide events for these = looking >>>>>> glass functions. For the web-server route, an event be sent = when >>>> that >>>>>> one route is added. =20 >>>>>> >>>>>> Sue >>>>>> >>>>>> >>>>>> -----Original Message----- >>>>>> From: Juergen Schoenwaelder >>>>>> [mailto:j.schoenwaelder@jacobs-university.de] >>>>>> Sent: Thursday, August 18, 2016 3:32 AM >>>>>> To: Susan Hares >>>>>> Cc: 'Kathleen Moriarty'; 'The IESG'; jhaas@pfrc.org;=20 >>>>>> i2rs@ietf.org; i2rs-chairs@ietf.org;=20 >>>>>> 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=20 >>>>>> and >>>>>> COMMENT) >>>>>> >>>>>> On Wed, Aug 17, 2016 at 09:16:48PM -0400, Susan Hares wrote: >>>>>>> ---------------------------------------------------------------- >>>>>>> - >>>>>>> - >>>>>>> -- >>>>>>> -- >>>>>>> COMMENT: >>>>>>> ---------------------------------------------------------------- >>>>>>> - >>>>>>> - >>>>>>> -- >>>>>>> -- >>>>>>> >>>>>>>> Section 3:=20 >>>>>>>> Can you clarify the second to last sentence? Do you mean there = >>>>>>>> are >>>>>> sections that indicate an insecure transport should be used? >>>>>>>> I2RS allows the use of an >>>>>>>> insecure transport for portions of data models that clearly=20 >>>>>>>> indicate insecure transport. >>>>>>>> Perhaps: >>>>>>>> I2RS allows the use of an >>>>>>>> insecure transport for portions of data models that clearly=20 >>>>>>>> indicate the use of an insecure transport. >>>>>> I still wonder how a data model writer can reasonably decide=20 >>>>>> whether a piece of information can be shipped safely over an=20 >>>>>> insecure transport since this decision often depends on the=20 >>>>>> specifics of a deployment >>>>> situation. >>>>>> /js >>>>>> >>>>>> PS: I hope we do not end up with defining data multiple times = (once >>>>>> for insecure transport and once for secured transports). >>>>>> >>>>>> --=20 >>>>>> Juergen Schoenwaelder Jacobs University Bremen gGmbH >>>>>> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | = Germany >>>>>> Fax: +49 421 200 3103 = >>>>>> >>>>>> _______________________________________________ >>>>>> i2rs mailing list >>>>>> i2rs@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/i2rs >>>>> --=20 >>>>> Juergen Schoenwaelder Jacobs University Bremen gGmbH >>>>> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | = Germany >>>>> Fax: +49 421 200 3103 >>>>> >>>>> _______________________________________________ >>>>> i2rs mailing list >>>>> i2rs@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/i2rs >>>>> >>>> --=20 >>>> Juergen Schoenwaelder Jacobs University Bremen gGmbH >>>> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | = Germany >>>> Fax: +49 421 200 3103 >>>> > > > From nobody Fri Aug 19 06:29:26 2016 Return-Path: X-Original-To: i2rs@ietf.org Delivered-To: i2rs@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A98912B059; Fri, 19 Aug 2016 06:29:21 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.29.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147161336103.24252.15552997879059032916.idtracker@ietfa.amsl.com> Date: Fri, 19 Aug 2016 06:29:21 -0700 Archived-At: Cc: i2rs@ietf.org Subject: [i2rs] I-D Action: draft-ietf-i2rs-protocol-security-requirements-09.txt X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Aug 2016 13:29:21 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Interface to the Routing System of the IETF. Title : I2RS Security Related Requirements Authors : Susan Hares Daniel Migault Joel Halpern Filename : draft-ietf-i2rs-protocol-security-requirements-09.txt Pages : 11 Date : 2016-08-19 Abstract: This presents security-related requirements for the I2RS protocol for mutual authentication, transport protocols, data transfer and transactions. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-i2rs-protocol-security-requirements/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-i2rs-protocol-security-requirements-09 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-i2rs-protocol-security-requirements-09 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Aug 19 06:29:49 2016 Return-Path: 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 A08DC12D98F; Fri, 19 Aug 2016 06:08:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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, HTML_MESSAGE=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 L2sp6NMnxVfs; Fri, 19 Aug 2016 06:08:31 -0700 (PDT) Received: from mail-yb0-x22f.google.com (mail-yb0-x22f.google.com [IPv6:2607:f8b0:4002:c09::22f]) (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 30DEA12D9B9; Fri, 19 Aug 2016 06:08:11 -0700 (PDT) Received: by mail-yb0-x22f.google.com with SMTP id b59so2467703ybi.0; Fri, 19 Aug 2016 06:08:11 -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; bh=m1WiyN7eu4hboa0YJJW8QrKkOhWfikZvdOBL5XNXylg=; b=JVcfsqxNdDbN2wWhjlfwZWuTvQNSSwEbptvYp+L8iGfnSCVcnBOXYwfdS2YxTHbe9N EXDw2tRK/iG2vuRHvvaYSYQTnyVB1PN+OWKFqrAdEsK6JSjF5Up31s+liTCTkDAu7qt2 tgRcYg5I0RYd+s0Q4C0sQ3rInM0leaCFUj2pZuDvkIXNp5M6UEMiWlBz5I1SgHOOC5ed umQjG1xLGaiME8ksA0eRbUi6DAddRQnUKem2bOKxDofFR3Ylqw1vNqxKc3LFMhDUxGFc FqamwXrb3eLgOaS6ohtGEYphihbQcrzaBuscjP62rnta3PoOMu/LfydOVrEk5ZSF7g3X nb/w== 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; bh=m1WiyN7eu4hboa0YJJW8QrKkOhWfikZvdOBL5XNXylg=; b=dPfbDdNBc9yJH3UOIQaWS8+I3iZnw3J5Op5LERU8BTT53/e+0wGoJ3dkmDk4X5gdKm D9MHlHnFeG5z4/FvRsh8IT9iFAjXU1JEgrM+9Va4e/xGBRVfxC6jDfg83me48Uygf2hK 5POPXBvQ5eU17d2L75+H4pg/hLU6RzKX8/l2r7AlYwIz6xDRbE3voQCxrKKmREugEJVj nv1y4qQ1Xxf6goI74VWkod6lVZegenhT9NZG7RCYdjiRJDncSnq3vbr9tYK1RrttpEOy S3KthkZqsNqwC9OjYzcRvCae720PIME7UFHZA49peZhQexKpqu9qnxxqF/9CJ5IRmHDf GADQ== X-Gm-Message-State: AEkoousDKy8qiWZegDXcGLdxZmR2TFnapU2uFjt+F/c8C6dHvYY+UD/Fd1RykFnnx7LRSZaghgPBTDM3BFz4cQ== X-Received: by 10.37.164.38 with SMTP id f35mr5900916ybi.98.1471612090459; Fri, 19 Aug 2016 06:08:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.210.195 with HTTP; Fri, 19 Aug 2016 06:08:09 -0700 (PDT) In-Reply-To: References: <147146974235.23784.4389421535496134619.idtracker@ietfa.amsl.com> <013b01d1f8ee$31fa09b0$95ee1d10$@ndzh.com> <20160818073203.GA4338@elstar.local> <04b501d1f949$116c63e0$34452ba0$@ndzh.com> <20160818121405.GA5282@elstar.local> <051301d1f950$7739c670$65ad5350$@ndzh.com> <20160818130555.GA5366@elstar.local> <051701d1f952$c4ae0b30$4e0a2190$@ndzh.com> <6BCE198E4EAEFC4CAB45D75826EFB0761525CCD7@eusaamb101.ericsson.se> <003801d1f97f$3d16eb10$b744c130$@ndzh.com> <00dc01d1f988$f2cec280$d86c4780$@ndzh.com> From: Spencer Dawkins at IETF Date: Fri, 19 Aug 2016 08:08:09 -0500 Message-ID: To: Andy Bierman Content-Type: multipart/alternative; boundary=94eb2c138950e62b54053a6c6365 Archived-At: X-Mailman-Approved-At: Fri, 19 Aug 2016 06:29:47 -0700 Cc: "i2rs@ietf.org" , Alissa Cooper , Juergen Schoenwaelder , i2rs-chairs@ietf.org, Kathleen Moriarty , IESG , Jeffrey Haas , Joel Halpern , Susan Hares , 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Aug 2016 13:08:32 -0000 --94eb2c138950e62b54053a6c6365 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Dear All, On Thu, Aug 18, 2016 at 3:02 PM, Andy Bierman wrote: > > > On Thu, Aug 18, 2016 at 12:44 PM, Susan Hares wrote: > >> Andy: >> >> >> >> Thank you =E2=80=93 I thought it was on whether we could implement insec= ure >> transport in a Yang module. >> >> >> >> The requirement text you are working with is: >> >> >> >> SEC-REQ-08: The I2RS protocol MUST be able to transfer data over a >> secure transport and optionally MAY be able to transfer data over a >> non-secure transport. >> >> >> >> I do not understand why approving the ok for non-secure transport for >> some modules means the following to you: >> >> >> >> *=E2=80=9C the IETF needs to agree that there could never possibly be an= y >> deployment that would not want to allow exposure of the data.* >> >> *Not now. Not 20 years from now.=E2=80=9D* >> >> >> > > > As I understand it, this requirement has another requirement associated > with it > that says the data has to be identified as OK-for-nonsecure-transport. > > An extension in the data model says that all instances of the object in > all possible deployments cannot be considered sensistive and therefore > needs disclosure protection. > > It may seem like even a simple octet counter is safe to send in the clear= , > but not if that opens up correlation attacks. (e.g., I can send data to > some > host. I can see that index 455992 is incrementing the in-octets counters > in a way that strongly correlates to my test traffic. Therefore I can > learn > that arbitrary index 455992 is really John Doe or really suite #14, etc. > Since Kathleen asked what other ADs were thinking ... I'm current on this thread, as of the time I'm sending my note, but replying to Andy's note because it's poking where I am poking. So, if (say) an octet counter is considered safe to send in the clear, and a Yang model that reflects that is approved and widely deployed, and then someone realizes that it's not safe to send in the clear, is that a big deal to fix, and get the updated Yang model widely deployed? My opinion on this point has a lot to do with how hard it is to recover if a Yang model gets this wrong ... My apologies for not understanding enough about Yang and I2RS to be able to answer my own question, of course. Thanks, Spencer --94eb2c138950e62b54053a6c6365 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Dear All,

On Thu, Aug 18, 2016 at 3:02 PM, Andy Bierman &l= t;andy@yumaworks.co= m> wrote:
=

On Thu, Aug 18, 2016 at 12:44 PM, Susan Hares <<= a href=3D"mailto:shares@ndzh.com" target=3D"_blank">shares@ndzh.com>= wrote:

Andy:

=C2=A0=

Thank you =E2=80=93 I th= ought it was on whether we could implement insecure transport in a Yang mod= ule.

= =C2=A0

The requirement= text you are working with is:

=C2=A0

=C2= =A0 =C2=A0SEC-REQ-08: The I2RS protocol MUST be able to transfer data over = a
=C2=A0 =C2=A0secure transport and optionally MAY be able to transfer d= ata over a
=C2=A0 =C2=A0non-secure transport.

=C2=A0

I do not understand why approving the ok for non-secure= transport for some modules means the following to you:

=C2=A0

=E2=80=9C the = IETF needs to agree that there could never possibly be any deployment that = would not want to allow exposure of the data.

<= p class=3D"MsoNormal">Not now. Not 20 years from = now.=E2=80=9D

=C2=A0


As I understand it, this requirement has another require= ment associated with it
that says the data has to be identified a= s OK-for-nonsecure-transport.

An extension in the = data model says that all instances of the object in
all possible = deployments cannot be considered sensistive and therefore
needs d= isclosure protection.

It may seem like even a simp= le octet counter is safe to send in the clear,
but not if that op= ens up correlation attacks. =C2=A0(e.g., I can send data to some
= host.=C2=A0 I can see that index 455992 is incrementing the in-octets count= ers
in a way that strongly correlates to my test traffic.=C2=A0 T= herefore I can learn
that arbitrary index 455992 is really John D= oe or really suite #14, etc.

<= /div>
Since Kathleen asked what other ADs were thinking ...
<= br>
I'm current on this thread, as of the time I'm sendin= g my note, but replying to Andy's note because it's poking where I = am poking.

So, if (say) an octet counter is consid= ered safe to send in the clear, and a Yang model that reflects that is appr= oved and widely deployed, and then someone realizes that it's not safe = to send in the clear, is that a big deal to fix, and get the updated Yang m= odel widely deployed?=C2=A0

My opinion on this poi= nt has a lot to do with how hard it is to recover if a Yang model gets this= wrong ...

My apologies for not understanding enou= gh about Yang and I2RS to be able to answer my own question, of course.

Thanks,

Spencer=C2=A0
<= /div>
--94eb2c138950e62b54053a6c6365-- From nobody Fri Aug 19 06:29:52 2016 Return-Path: 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 BD42812D9FC; Fri, 19 Aug 2016 06:22:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.739 X-Spam-Level: * X-Spam-Status: No, score=1.739 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, RDNS_NONE=0.793] autolearn=no 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 h-hya9p6rI7D; Fri, 19 Aug 2016 06:22:10 -0700 (PDT) Received: from hickoryhill-consulting.com (unknown [50.245.122.97]) (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 AB0CC12DA1D; Fri, 19 Aug 2016 06:21:13 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=184.157.82.170; From: "Susan Hares" To: "'Spencer Dawkins at IETF'" , "'Andy Bierman'" References: <147146974235.23784.4389421535496134619.idtracker@ietfa.amsl.com> <013b01d1f8ee$31fa09b0$95ee1d10$@ndzh.com> <20160818073203.GA4338@elstar.local> <04b501d1f949$116c63e0$34452ba0$@ndzh.com> <20160818121405.GA5282@elstar.local> <051301d1f950$7739c670$65ad5350$@ndzh.com> <20160818130555.GA5366@elstar.local> <051701d1f952$c4ae0b30$4e0a2190$@ndzh.com> <6BCE198E4EAEFC4CAB45D75826EFB0761525CCD7@eusaamb101.ericsson.se> <003801d1f97f$3d16eb10$b744c130$@ndzh.com> <00dc01d1f988$f2cec280$d86c4780$@ndzh.com> In-Reply-To: Date: Fri, 19 Aug 2016 09:19:57 -0400 Message-ID: <02b201d1fa1c$620e07d0$262a1770$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_02B3_01D1F9FA.DB005F70" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIa7Lz6VgZw6h2A0uGNzOgAA2Ic8QJ/RF5yARxv/coCD6d0AAIDKkFTAYlI9/gCaK/wXAMksAaNAmoTFCQCp9Oi8AIQlOgDAIZjbI0CaGRfrQGPw5JeAjmooLWe2V2hAA== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: X-Mailman-Approved-At: Fri, 19 Aug 2016 06:29:48 -0700 Cc: i2rs@ietf.org, 'Alissa Cooper' , 'Juergen Schoenwaelder' , 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) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Aug 2016 13:22:11 -0000 This is a multipart message in MIME format. ------=_NextPart_000_02B3_01D1F9FA.DB005F70 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Spencer:=20 =20 You as asking if: =20 1) Can Yang Models be revised? - there is a revision tag on the = Yang model.=20 2) How long it takes to deploy revised models in the Internet, and = old-models to be timed out? This is an operational question on yang = models that no one has experience to determine. Andy suggest that the = deployment time is 20 years (the Age of the Commercial internet = =E2=80=93 1996 -2016) rather than the age of the Internet (1987-2016). =20 =20 However, the real question you should have asked is: Can operators = deploy models which are marked as =E2=80=9Cnon-secure transport=E2=80=9D = with a secure transport? =20 =20 The answer is yes. In fact, several operators in I2RS stated that all = I2RS protocol communication needed to be secure. Therefore, if the = people found out that a model was problematic to be insecure =E2=80=93 = operators and vendors would simply turn the deployment knob switch that = says =E2=80=93 deploy this always with a secure transport rather than = optionally allow an insecure transport. =20 =20 Now, the real problem is if the IESG has been cycling on this concept = =E2=80=93 the text needs to change. I=E2=80=99m going to go ahead and = release a version-09.txt that tries to make this very clear. Please = comment on that text to help make this clear.=20 =20 Sue=20 =20 =20 From: Spencer Dawkins at IETF [mailto:spencerdawkins.ietf@gmail.com]=20 Sent: Friday, August 19, 2016 9:08 AM To: Andy Bierman Cc: Susan Hares; i2rs@ietf.org; Alissa Cooper; Juergen Schoenwaelder; = 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) =20 Dear All, =20 On Thu, Aug 18, 2016 at 3:02 PM, Andy Bierman = wrote: =20 =20 On Thu, Aug 18, 2016 at 12:44 PM, Susan Hares wrote: Andy: =20 Thank you =E2=80=93 I thought it was on whether we could implement = insecure transport in a Yang module.=20 =20 The requirement text you are working with is: =20 SEC-REQ-08: The I2RS protocol MUST be able to transfer data over a secure transport and optionally MAY be able to transfer data over a non-secure transport. =20 I do not understand why approving the ok for non-secure transport for = some modules means the following to you:=20 =20 =E2=80=9C the IETF needs to agree that there could never possibly be any = deployment that would not want to allow exposure of the data. Not now. Not 20 years from now.=E2=80=9D =20 =20 =20 As I understand it, this requirement has another requirement associated = with it that says the data has to be identified as OK-for-nonsecure-transport. =20 An extension in the data model says that all instances of the object in all possible deployments cannot be considered sensistive and therefore needs disclosure protection. =20 It may seem like even a simple octet counter is safe to send in the = clear, but not if that opens up correlation attacks. (e.g., I can send data to = some host. I can see that index 455992 is incrementing the in-octets = counters in a way that strongly correlates to my test traffic. Therefore I can = learn that arbitrary index 455992 is really John Doe or really suite #14, etc. =20 Since Kathleen asked what other ADs were thinking ... =20 I'm current on this thread, as of the time I'm sending my note, but = replying to Andy's note because it's poking where I am poking. =20 So, if (say) an octet counter is considered safe to send in the clear, = and a Yang model that reflects that is approved and widely deployed, and = then someone realizes that it's not safe to send in the clear, is that a = big deal to fix, and get the updated Yang model widely deployed?=20 =20 My opinion on this point has a lot to do with how hard it is to recover = if a Yang model gets this wrong ... =20 My apologies for not understanding enough about Yang and I2RS to be able = to answer my own question, of course. =20 Thanks, =20 Spencer=20 ------=_NextPart_000_02B3_01D1F9FA.DB005F70 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Spencer:

 

You as asking if:

 

1)      = Can Yang Models be revised? =C2=A0- there is a revision tag on the = Yang model.

2)      = How long it takes to deploy revised models in the Internet, and = old-models to be timed out?=C2=A0 This is an operational question on = yang models that no one has experience to determine. =C2=A0=C2=A0Andy = suggest that the deployment time is 20 years (the Age of the Commercial = internet =E2=80=93 1996 -2016) rather than the age of the Internet = (1987-2016).=C2=A0

 

However, the real question you should have asked is: Can operators = deploy models which are marked as =E2=80=9Cnon-secure transport=E2=80=9D = with a =C2=A0secure transport?=C2=A0

 

The answer is yes.=C2=A0 In fact, several operators in I2RS stated = that all I2RS protocol communication needed to be secure. = =C2=A0=C2=A0=C2=A0Therefore, if the people found out that a model was = problematic to be insecure =E2=80=93 operators and vendors would simply = turn the deployment knob switch that says =E2=80=93 deploy this always = with a secure transport rather than optionally allow an insecure = transport.=C2=A0 =C2=A0=C2=A0

 

Now, the real problem is if the IESG has been cycling on this concept = =E2=80=93 the text needs to change.=C2=A0=C2=A0 I=E2=80=99m going to go = ahead and release a version-09.txt that tries to make this very = clear.=C2=A0=C2=A0 Please comment on that text to help make this clear. =

 

Sue

 

 

From:= = Spencer Dawkins at IETF [mailto:spencerdawkins.ietf@gmail.com] =
Sent: Friday, August 19, 2016 9:08 AM
To: Andy = Bierman
Cc: Susan Hares; i2rs@ietf.org; Alissa Cooper; Juergen = Schoenwaelder; 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)

 

Dear = All,

 

On Thu, = Aug 18, 2016 at 3:02 PM, Andy Bierman <andy@yumaworks.com> = wrote:

 

 

On Thu, = Aug 18, 2016 at 12:44 PM, Susan Hares <shares@ndzh.com> = wrote:

Andy:

 

Thank you = =E2=80=93 I thought it was on whether we could implement insecure = transport in a Yang module.

 

The = requirement text you are working with is:

 

  =  SEC-REQ-08: The I2RS protocol MUST be able to transfer data over = a
   secure transport and optionally MAY be able to = transfer data over a
   non-secure = transport.

 

I do not = understand why approving the ok for non-secure transport for some = modules means the following to you:

 

=E2= =80=9C the IETF needs to agree that there could never possibly be any = deployment that would not want to allow exposure of the = data.

N= ot now. Not 20 years from now.=E2=80=9D

 

 

 

As I understand it, this requirement has another = requirement associated with it

that says the data has to be identified as = OK-for-nonsecure-transport.

 

An extension in the data model says that all instances = of the object in

all = possible deployments cannot be considered sensistive and = therefore

needs disclosure = protection.

 

It may seem like even a simple octet counter is safe = to send in the clear,

but = not if that opens up correlation attacks.  (e.g., I can send data = to some

host.  I can = see that index 455992 is incrementing the in-octets = counters

in a way that = strongly correlates to my test traffic.  Therefore I can = learn

that arbitrary index = 455992 is really John Doe or really suite #14, = etc.

 

Since Kathleen asked what other ADs were thinking = ...

 

I'm current on this thread, as of the time I'm sending = my note, but replying to Andy's note because it's poking where I am = poking.

 

So, if (say) an octet counter is considered safe to = send in the clear, and a Yang model that reflects that is approved and = widely deployed, and then someone realizes that it's not safe to send in = the clear, is that a big deal to fix, and get the updated Yang model = widely deployed? 

 

My opinion on this point has a lot to do with how hard = it is to recover if a Yang model gets this wrong = ...

 

My apologies for not understanding enough about Yang = and I2RS to be able to answer my own question, of = course.

 

Thanks,

 

Spencer 

------=_NextPart_000_02B3_01D1F9FA.DB005F70-- From nobody Fri Aug 19 06:52:08 2016 Return-Path: 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 ED05512DA30; Fri, 19 Aug 2016 06:31:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.739 X-Spam-Level: * X-Spam-Status: No, score=1.739 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, RDNS_NONE=0.793] autolearn=no 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 jAsEvopzmNLa; Fri, 19 Aug 2016 06:31:57 -0700 (PDT) Received: from hickoryhill-consulting.com (unknown [50.245.122.97]) (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 2F11012DA01; Fri, 19 Aug 2016 06:31:24 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=184.157.82.170; From: "Susan Hares" To: "'Spencer Dawkins at IETF'" , "'Andy Bierman'" References: <147146974235.23784.4389421535496134619.idtracker@ietfa.amsl.com> <013b01d1f8ee$31fa09b0$95ee1d10$@ndzh.com> <20160818073203.GA4338@elstar.local> <04b501d1f949$116c63e0$34452ba0$@ndzh.com> <20160818121405.GA5282@elstar.local> <051301d1f950$7739c670$65ad5350$@ndzh.com> <20160818130555.GA5366@elstar.local> <051701d1f952$c4ae0b30$4e0a2190$@ndzh.com> <6BCE198E4EAEFC4CAB45D75826EFB0761525CCD7@eusaamb101.ericsson.se> <003801d1f97f$3d16eb10$b744c130$@ndzh.com> <00dc01d1f988$f2cec280$d86c4780$@ndzh.com> <02b201d1fa1c$620e07d0$262a1770$@ndzh.com> In-Reply-To: <02b201d1fa1c$620e07d0$262a1770$@ndzh.com> Date: Fri, 19 Aug 2016 09:30:05 -0400 Message-ID: <02ca01d1fa1d$ccd71ba0$668552e0$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_02CB_01D1F9FC.45C70240" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIa7Lz6VgZw6h2A0uGNzOgAA2Ic8QJ/RF5yARxv/coCD6d0AAIDKkFTAYlI9/gCaK/wXAMksAaNAmoTFCQCp9Oi8AIQlOgDAIZjbI0CaGRfrQGPw5JeAjmooLUBU45vXJ7OxVXA Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: X-Mailman-Approved-At: Fri, 19 Aug 2016 06:52:08 -0700 Cc: i2rs@ietf.org, 'Alissa Cooper' , 'Juergen Schoenwaelder' , 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) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Aug 2016 13:31:59 -0000 This is a multipart message in MIME format. ------=_NextPart_000_02CB_01D1F9FC.45C70240 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Spencer:=20 =20 Let me clarify one thing. The deployment of new Yang modules can be = sent with any software update cycle. A software update cycle takes = hours in some environments and months in others. The question is what = is the longest a yang module can stay the network. Andy suggests 20+ = years (probably based on SNMP deployments). =20 =20 I have posted version -09.txt. =20 =20 Sue=20 =20 From: Susan Hares [mailto:shares@ndzh.com]=20 Sent: Friday, August 19, 2016 9:20 AM To: 'Spencer Dawkins at IETF'; 'Andy Bierman' Cc: i2rs@ietf.org; 'Alissa Cooper'; 'Juergen Schoenwaelder'; = 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) =20 Spencer:=20 =20 You as asking if: =20 1) Can Yang Models be revised? - there is a revision tag on the = Yang model.=20 2) How long it takes to deploy revised models in the Internet, and = old-models to be timed out? This is an operational question on yang = models that no one has experience to determine. Andy suggest that the = deployment time is 20 years (the Age of the Commercial internet = =E2=80=93 1996 -2016) rather than the age of the Internet (1987-2016). =20 =20 However, the real question you should have asked is: Can operators = deploy models which are marked as =E2=80=9Cnon-secure transport=E2=80=9D = with a secure transport? =20 =20 The answer is yes. In fact, several operators in I2RS stated that all = I2RS protocol communication needed to be secure. Therefore, if the = people found out that a model was problematic to be insecure =E2=80=93 = operators and vendors would simply turn the deployment knob switch that = says =E2=80=93 deploy this always with a secure transport rather than = optionally allow an insecure transport. =20 =20 Now, the real problem is if the IESG has been cycling on this concept = =E2=80=93 the text needs to change. I=E2=80=99ve release a = version-09.txt that tries to make this very clear. Please comment on = that text to help make this clear.=20 =20 Sue=20 =20 =20 From: Spencer Dawkins at IETF [mailto:spencerdawkins.ietf@gmail.com]=20 Sent: Friday, August 19, 2016 9:08 AM To: Andy Bierman Cc: Susan Hares; i2rs@ietf.org; Alissa Cooper; Juergen Schoenwaelder; = 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) =20 Dear All, =20 On Thu, Aug 18, 2016 at 3:02 PM, Andy Bierman = wrote: =20 =20 On Thu, Aug 18, 2016 at 12:44 PM, Susan Hares wrote: Andy: =20 Thank you =E2=80=93 I thought it was on whether we could implement = insecure transport in a Yang module.=20 =20 The requirement text you are working with is: =20 SEC-REQ-08: The I2RS protocol MUST be able to transfer data over a secure transport and optionally MAY be able to transfer data over a non-secure transport. =20 I do not understand why approving the ok for non-secure transport for = some modules means the following to you:=20 =20 =E2=80=9C the IETF needs to agree that there could never possibly be any = deployment that would not want to allow exposure of the data. Not now. Not 20 years from now.=E2=80=9D =20 =20 =20 As I understand it, this requirement has another requirement associated = with it that says the data has to be identified as OK-for-nonsecure-transport. =20 An extension in the data model says that all instances of the object in all possible deployments cannot be considered sensistive and therefore needs disclosure protection. =20 It may seem like even a simple octet counter is safe to send in the = clear, but not if that opens up correlation attacks. (e.g., I can send data to = some host. I can see that index 455992 is incrementing the in-octets = counters in a way that strongly correlates to my test traffic. Therefore I can = learn that arbitrary index 455992 is really John Doe or really suite #14, etc. =20 Since Kathleen asked what other ADs were thinking ... =20 I'm current on this thread, as of the time I'm sending my note, but = replying to Andy's note because it's poking where I am poking. =20 So, if (say) an octet counter is considered safe to send in the clear, = and a Yang model that reflects that is approved and widely deployed, and = then someone realizes that it's not safe to send in the clear, is that a = big deal to fix, and get the updated Yang model widely deployed?=20 =20 My opinion on this point has a lot to do with how hard it is to recover = if a Yang model gets this wrong ... =20 My apologies for not understanding enough about Yang and I2RS to be able = to answer my own question, of course. =20 Thanks, =20 Spencer=20 ------=_NextPart_000_02CB_01D1F9FC.45C70240 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Spencer:

 

Let me clarify one thing.=C2=A0=C2=A0 The deployment of new Yang = modules can be sent with any software update cycle.=C2=A0 A software = update cycle takes hours in some environments and months in = others.=C2=A0 The question is what is the longest a yang module can stay = the network.=C2=A0 Andy suggests 20+ years (probably based on SNMP = deployments).=C2=A0

 

I have posted version -09.txt.=C2=A0=C2=A0

 

Sue

 

From:= = Susan Hares [mailto:shares@ndzh.com]
Sent: Friday, August 19, = 2016 9:20 AM
To: 'Spencer Dawkins at IETF'; 'Andy = Bierman'
Cc: i2rs@ietf.org; 'Alissa Cooper'; 'Juergen = Schoenwaelder'; 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)

 

Spencer:

 

You as asking if:

 

1)      = Can Yang Models be revised?  - there is a revision tag on the = Yang model.

2)      = How long it takes to deploy revised models in the Internet, and = old-models to be timed out?  This is an operational question on = yang models that no one has experience to determine.   Andy = suggest that the deployment time is 20 years (the Age of the Commercial = internet =E2=80=93 1996 -2016) rather than the age of the Internet = (1987-2016). 

 

However, the real question you should have asked is: Can operators = deploy models which are marked as =E2=80=9Cnon-secure transport=E2=80=9D = with a  secure transport? 

 

The answer is yes.  In fact, several operators in I2RS stated = that all I2RS protocol communication needed to be secure. =    Therefore, if the people found out that a model was = problematic to be insecure =E2=80=93 operators and vendors would simply = turn the deployment knob switch that says =E2=80=93 deploy this always = with a secure transport rather than optionally allow an insecure = transport.    

 

Now, the real problem is if the IESG has been cycling on this concept = =E2=80=93 the text needs to change.   I=E2=80=99ve release a version-09.txt that tries to make this very = clear.   Please comment on that text to help make this clear. =

 

Sue

 

 

From:= = Spencer Dawkins at IETF [mailto:spencerdawkins.ietf@= gmail.com]
Sent: Friday, August 19, 2016 9:08 = AM
To: Andy Bierman
Cc: Susan Hares; i2rs@ietf.org; Alissa Cooper; Juergen = Schoenwaelder; i2rs-chairs@ietf.org; Kathleen = Moriarty; IESG; Jeffrey Haas; Joel Halpern; d= raft-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)

 

Dear = All,

 

On Thu, = Aug 18, 2016 at 3:02 PM, Andy Bierman <andy@yumaworks.com> = wrote:

 

 

On Thu, = Aug 18, 2016 at 12:44 PM, Susan Hares <shares@ndzh.com> = wrote:

Andy:

 

Thank you = =E2=80=93 I thought it was on whether we could implement insecure = transport in a Yang module.

 

The = requirement text you are working with is:

 

  =  SEC-REQ-08: The I2RS protocol MUST be able to transfer data over = a
   secure transport and optionally MAY be able to = transfer data over a
   non-secure = transport.

 

I do not = understand why approving the ok for non-secure transport for some = modules means the following to you:

 

=E2= =80=9C the IETF needs to agree that there could never possibly be any = deployment that would not want to allow exposure of the = data.

N= ot now. Not 20 years from now.=E2=80=9D

 

 

 

As I understand it, this requirement has another = requirement associated with it

that says the data has to be identified as = OK-for-nonsecure-transport.

 

An extension in the data model says that all instances = of the object in

all = possible deployments cannot be considered sensistive and = therefore

needs disclosure = protection.

 

It may seem like even a simple octet counter is safe = to send in the clear,

but = not if that opens up correlation attacks.  (e.g., I can send data = to some

host.  I can = see that index 455992 is incrementing the in-octets = counters

in a way that = strongly correlates to my test traffic.  Therefore I can = learn

that arbitrary index = 455992 is really John Doe or really suite #14, = etc.

 

Since Kathleen asked what other ADs were thinking = ...

 

I'm current on this thread, as of the time I'm sending = my note, but replying to Andy's note because it's poking where I am = poking.

 

So, if (say) an octet counter is considered safe to = send in the clear, and a Yang model that reflects that is approved and = widely deployed, and then someone realizes that it's not safe to send in = the clear, is that a big deal to fix, and get the updated Yang model = widely deployed? 

 

My opinion on this point has a lot to do with how hard = it is to recover if a Yang model gets this wrong = ...

 

My apologies for not understanding enough about Yang = and I2RS to be able to answer my own question, of = course.

 

Thanks,

 

Spencer 

------=_NextPart_000_02CB_01D1F9FC.45C70240-- From nobody Fri Aug 19 08:01:36 2016 Return-Path: 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 9276E12DA73; Fri, 19 Aug 2016 07:13:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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, HTML_MESSAGE=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 oOEsmq3T1R3v; Fri, 19 Aug 2016 07:13:28 -0700 (PDT) Received: from mail-yw0-x234.google.com (mail-yw0-x234.google.com [IPv6:2607:f8b0:4002:c05::234]) (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 A2DB712DA9C; Fri, 19 Aug 2016 07:13:20 -0700 (PDT) Received: by mail-yw0-x234.google.com with SMTP id j12so13398179ywb.2; Fri, 19 Aug 2016 07:13:20 -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; bh=0JQRKWOOXdMN0kYs5q0pfF2ku89mHv+sCeOIXk9Z/Ho=; b=MW0kRmSm16t0KFn21DDL9o4rxRtIPDmBdTVjDxaYWYcqOBTvlbnKUjOABduLlSa1wr Jo6h6SXImRXUqBjKND3AZ1LBBFT0+cw+TEN1t0HHLBOWqOmjowJ8ZiyDH6df4Cffnyz1 ZM4J+7+eLo95XaNE1O6J/HBJGjSTb6VXjwCGn0cGaxnpFeHinYdeZDPXHRfPg983Gpoq Otv8DY/ZwLCnJcaVDNqeirgf6r0ve1mB9UK7Dl8QhC3oFzaTqmGgzCSJIUGk5tN9BkC2 xuXpst1lGFEm2ncph9RSn3kLTlpsB73vnCcJncdmKfbfahlkPLFql+ezI06oyFkrmz6z +w5Q== 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; bh=0JQRKWOOXdMN0kYs5q0pfF2ku89mHv+sCeOIXk9Z/Ho=; b=iaouGDHBU5EwCAyCyiGMbrDU3+BqP192uBD1Togm+17ucmGdY8ry6/Uaq9V9dg5J+s E/MSJubDdSWZIKzsj/XLXGX51vvgnHWzMzB+8I48YuowLdxmqxw5bARPnqgnpDuIiVei xzzLlTzuxbGBil/fdX5wrl7Z0ctfeu7jce8U6UbEa9+6eFuyM9YocrhQTpHk0drnXzEw Ak4qXE8LVDt8VIftlGb31v6kAtBs1CrUibXZ0n0PXG4XyORyGPzGtJTGMZ1raEDm1B4G C/zU/89Y7PRvGuR1ZRTzGVxtMTxmFlz1UYGWrKwyMJUvzYxXj/0OOo99I+Z8489sGhjN v9NA== X-Gm-Message-State: AEkoouu5tw6gLlZVv50XPC3+pMr/Kf0yx8/NBvXtfy5EUKceBoBwUWmuXwSJKsY7Yunx+JVVMgX5Q9mUUH/54Q== X-Received: by 10.129.82.130 with SMTP id g124mr6591162ywb.208.1471615999859; Fri, 19 Aug 2016 07:13:19 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.210.195 with HTTP; Fri, 19 Aug 2016 07:13:18 -0700 (PDT) In-Reply-To: <02b201d1fa1c$620e07d0$262a1770$@ndzh.com> References: <147146974235.23784.4389421535496134619.idtracker@ietfa.amsl.com> <013b01d1f8ee$31fa09b0$95ee1d10$@ndzh.com> <20160818073203.GA4338@elstar.local> <04b501d1f949$116c63e0$34452ba0$@ndzh.com> <20160818121405.GA5282@elstar.local> <051301d1f950$7739c670$65ad5350$@ndzh.com> <20160818130555.GA5366@elstar.local> <051701d1f952$c4ae0b30$4e0a2190$@ndzh.com> <6BCE198E4EAEFC4CAB45D75826EFB0761525CCD7@eusaamb101.ericsson.se> <003801d1f97f$3d16eb10$b744c130$@ndzh.com> <00dc01d1f988$f2cec280$d86c4780$@ndzh.com> <02b201d1fa1c$620e07d0$262a1770$@ndzh.com> From: Spencer Dawkins at IETF Date: Fri, 19 Aug 2016 09:13:18 -0500 Message-ID: To: Susan Hares Content-Type: multipart/alternative; boundary=001a114dc320eae445053a6d4c24 Archived-At: X-Mailman-Approved-At: Fri, 19 Aug 2016 08:01:35 -0700 Cc: i2rs@ietf.org, Alissa Cooper , Juergen Schoenwaelder , Andy Bierman , 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) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Aug 2016 14:13:31 -0000 --001a114dc320eae445053a6d4c24 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, Susan, On Fri, Aug 19, 2016 at 8:19 AM, Susan Hares wrote: > Spencer: > > > > You as asking if: > > > > 1) Can Yang Models be revised? - there is a revision tag on the > Yang model. > > 2) How long it takes to deploy revised models in the Internet, and > old-models to be timed out? This is an operational question on yang mode= ls > that no one has experience to determine. Andy suggest that the deployme= nt > time is 20 years (the Age of the Commercial internet =E2=80=93 1996 -2016= ) rather > than the age of the Internet (1987-2016). > > > > However, the real question you should have asked is: Can operators deploy > models which are marked as =E2=80=9Cnon-secure transport=E2=80=9D with a = secure transport? > I understood that part. My question was how long it would likely take them to switch to a secure transport if they had deployed a model with an insecure transport and figured out that was problematic. Thanks for the explanation. It was helpful. Spencer > The answer is yes. In fact, several operators in I2RS stated that all > I2RS protocol communication needed to be secure. Therefore, if the > people found out that a model was problematic to be insecure =E2=80=93 op= erators > and vendors would simply turn the deployment knob switch that says =E2=80= =93 deploy > this always with a secure transport rather than optionally allow an > insecure transport. > > > > Now, the real problem is if the IESG has been cycling on this concept =E2= =80=93 > the text needs to change. I=E2=80=99m going to go ahead and release a > version-09.txt that tries to make this very clear. Please comment on th= at > text to help make this clear. > > > > Sue > > > > > > *From:* Spencer Dawkins at IETF [mailto:spencerdawkins.ietf@gmail.com] > *Sent:* Friday, August 19, 2016 9:08 AM > *To:* Andy Bierman > *Cc:* Susan Hares; i2rs@ietf.org; Alissa Cooper; Juergen Schoenwaelder; > 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) > > > > Dear All, > > > > On Thu, Aug 18, 2016 at 3:02 PM, Andy Bierman wrote: > > > > > > On Thu, Aug 18, 2016 at 12:44 PM, Susan Hares wrote: > > Andy: > > > > Thank you =E2=80=93 I thought it was on whether we could implement insecu= re > transport in a Yang module. > > > > The requirement text you are working with is: > > > > SEC-REQ-08: The I2RS protocol MUST be able to transfer data over a > secure transport and optionally MAY be able to transfer data over a > non-secure transport. > > > > I do not understand why approving the ok for non-secure transport for som= e > modules means the following to you: > > > > *=E2=80=9C the IETF needs to agree that there could never possibly be any > deployment that would not want to allow exposure of the data.* > > *Not now. Not 20 years from now.=E2=80=9D* > > > > > > > > As I understand it, this requirement has another requirement associated > with it > > that says the data has to be identified as OK-for-nonsecure-transport. > > > > An extension in the data model says that all instances of the object in > > all possible deployments cannot be considered sensistive and therefore > > needs disclosure protection. > > > > It may seem like even a simple octet counter is safe to send in the clear= , > > but not if that opens up correlation attacks. (e.g., I can send data to > some > > host. I can see that index 455992 is incrementing the in-octets counters > > in a way that strongly correlates to my test traffic. Therefore I can > learn > > that arbitrary index 455992 is really John Doe or really suite #14, etc. > > > > Since Kathleen asked what other ADs were thinking ... > > > > I'm current on this thread, as of the time I'm sending my note, but > replying to Andy's note because it's poking where I am poking. > > > > So, if (say) an octet counter is considered safe to send in the clear, an= d > a Yang model that reflects that is approved and widely deployed, and then > someone realizes that it's not safe to send in the clear, is that a big > deal to fix, and get the updated Yang model widely deployed? > > > > My opinion on this point has a lot to do with how hard it is to recover i= f > a Yang model gets this wrong ... > > > > My apologies for not understanding enough about Yang and I2RS to be able > to answer my own question, of course. > > > > Thanks, > > > > Spencer > --001a114dc320eae445053a6d4c24 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi, Susan,

On Fri, Aug 19, 2016 at 8:19 AM, Susan Hares &l= t;shares@ndzh.com&= gt; wrote:

Spencer:

=C2=A0

You as asking if:

=C2=A0

1)=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = Can Yang Models be revised? =C2=A0- there is a r= evision tag on the Yang model.

2)=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 How long it takes to deploy revised models in the Internet= , and old-models to be timed out?=C2=A0 This is an operational question on = yang models that no one has experience to determine. =C2=A0=C2=A0Andy sugge= st that the deployment time is 20 years (the Age of the Commercial internet= =E2=80=93 1996 -2016) rather than the age of the Internet (1987-2016).=C2= =A0

=C2=A0

However, the real question you should have asked is: Can operator= s deploy models which are marked as =E2=80=9Cnon-secure transport=E2=80=9D = with a =C2=A0secure transport?=C2=A0


=
I understood that part. My question was how long it would likely= take them to switch to a secure transport if they had deployed a model wit= h an insecure transport and figured out that was problematic.
Thanks for the explanation. It was helpful.

Spencer
=C2=A0

T= he answer is yes.=C2=A0 In fact, several operators in I2RS stated that all = I2RS protocol communication needed to be secure. =C2=A0=C2=A0=C2=A0Therefor= e, if the people found out that a model was problematic to be insecure =E2= =80=93 operators and vendors would simply turn the deployment knob switch t= hat says =E2=80=93 deploy this always with a secure transport rather than o= ptionally allow an insecure transport. =C2=A0 =C2=A0

=C2=A0

Now, the real problem is if the= IESG has been cycling on this concept =E2=80=93 the text needs to change.= =C2=A0=C2=A0 I=E2=80=99m going to go ahead and release a version-09.txt tha= t tries to make this very clear.=C2=A0=C2=A0 Please comment on that text to= help make this clear.

=C2=A0

Sue

=C2=A0

=C2=A0

From: Spencer Dawki= ns at IETF [mailto:spencerdawkins.ietf@gmail.com]
Sent: Friday= , August 19, 2016 9:08 AM
To: Andy Bierman
Cc: Susan Ha= res; i2rs@ietf.org; = Alissa Cooper; Juergen Schoenwaelder; i2rs-chairs@ietf.org; Kathleen Moriarty; IESG; Jef= frey Haas; Joel Halpern; draft-ietf-i2rs-protocol-se= curity-requirements@ietf.org
Subject: Re: [i= 2rs] Kathleen Moriarty's Discuss on draft-ietf-i2rs-protocol-secur= ity-requirements-07: (with DISCUSS and COMMENT)=

=C2=A0

Dear All,

=C2=A0

On Thu, Aug 18, = 2016 at 3:02 PM, Andy Bierman <andy@yumaworks.com> wrote:

=C2=A0

<= /u>=C2=A0

On Thu, Aug 18, 2016 at 12:= 44 PM, Susan Hares <shares@ndzh.com> wrote:

Andy:

=C2=A0

Thank you =E2=80=93 I thought it was on whether we could implement insec= ure transport in a Yang module.

=C2=A0

The requirement text you are working with is:

=C2=A0

=C2=A0 =C2=A0SEC-REQ-08: The I2RS protocol MUST be able= to transfer data over a
=C2=A0 =C2=A0secure transport and optionally MA= Y be able to transfer data over a
=C2=A0 =C2=A0non-secure transport.<= /u>

=C2=A0

I do not understand why approving= the ok for non-secure transport for some modules means the following to yo= u:

=C2=A0

=E2=80=9C the IETF needs to agree that there could never possibly b= e any deployment that would not want to allow exposure of the data.<= /i>

Not n= ow. Not 20 years from now.=E2=80=9D

=C2=A0

=C2=A0

=C2=A0

As I understa= nd it, this requirement has another requirement associated with it

that says the data has to be ide= ntified as OK-for-nonsecure-transport.

=C2=A0

An= extension in the data model says that all instances of the object in

all possible deployments cann= ot be considered sensistive and therefore

needs disclosure protection.

=

=C2=A0

It may seem like even a simple octet counter is safe to send in the c= lear,

but not if that op= ens up correlation attacks. =C2=A0(e.g., I can send data to some<= /u>

host.=C2=A0 I can see that index 4= 55992 is incrementing the in-octets counters

in a way that strongly correlates to my test traffic.= =C2=A0 Therefore I can learn

that arbitrary index 455992 is really John Doe or really suite #14, et= c.

= =C2=A0

Since Kathleen asked= what other ADs were thinking ...

=C2=A0

I'm= current on this thread, as of the time I'm sending my note, but replyi= ng to Andy's note because it's poking where I am poking.<= /u>

=C2=A0

So, if (say) an octet counter is considered safe to= send in the clear, and a Yang model that reflects that is approved and wid= ely deployed, and then someone realizes that it's not safe to send in t= he clear, is that a big deal to fix, and get the updated Yang model widely = deployed?=C2=A0

= =C2=A0

My opinion on this point= has a lot to do with how hard it is to recover if a Yang model gets this w= rong ...

=C2=A0

My apologies for not understandi= ng enough about Yang and I2RS to be able to answer my own question, of cour= se.

=C2=A0=

Thanks,

<= p class=3D"MsoNormal">=C2=A0

Spencer=C2=A0


--001a114dc320eae445053a6d4c24-- From nobody Fri Aug 19 08:01:40 2016 Return-Path: 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 985FF12DAB5 for ; Fri, 19 Aug 2016 07:24:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.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 g97UEOmI7Rs3 for ; Fri, 19 Aug 2016 07:24:01 -0700 (PDT) Received: from mail-ua0-x22c.google.com (mail-ua0-x22c.google.com [IPv6:2607:f8b0:400c:c08::22c]) (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 C908C12DAF0 for ; Fri, 19 Aug 2016 07:23:49 -0700 (PDT) Received: by mail-ua0-x22c.google.com with SMTP id 74so82555011uau.0 for ; Fri, 19 Aug 2016 07:23:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=EzGXsbkKq12UMAtMxhdc/S/p+3SuNp/mySQnNypwmBw=; b=2DETF28v0tazSdoiHgNl9RecTZRKZvYYb3n7v9pPgso60rjBRwA+iGY6sNak/ouOkK Pu2I8hLgVquJfMpNLcaWdfFAoL7Z3tXyR+4Xkw8efGoDXTkq41RBebQxDMWrFFfCGBI6 viNkSRrU+cojwEn3Ni3h1C8mI44XKV+q7hpViNSmmE1lca68om/WpiKmBxRsm5Uv8jc+ AqvtpRDkpSuFSLtJHxkM65KKiwCoqt1G1XZ4tzlIlReOqZ4sIfylHahzmtjuPg50dSQw Us7gscic+sUoMtrxp99bi/299ika1ts+mmVT8FqvGiOnjvQ0O51nCzKe9bqk5e0hNCEn eY+Q== 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; bh=EzGXsbkKq12UMAtMxhdc/S/p+3SuNp/mySQnNypwmBw=; b=A8Xf22dcfXITfpD8vk/NV9MxY6NTehi5YSlSMxkzsP2K0gvkl7RQnV47fqByhSVGeA NRf8gwz9YLG/GatbySLFQ9xmp6skb+7JZPLdSe7M4zCNgE/lVcYIudSyIUBmWzL/VAvG 5yXFbJouQrv0N1x9nCJ+4+a/I/+QYFZPOD7libf/UAQsbuCN32fmzCQyKdCwEzv2qmWf 6jIO3r/nA0CpHUEfrKLD/UwucAbRAlGNIi/VzkAzvNjXXSjGC2cavb/m2F6EKZKFoiHX pOJIfU1x6U/m1ODjdU+vSVudwLlE9zz0ehMFBdH2AOKd8PY7CdItHklLruCDNetTei5j 5nxg== X-Gm-Message-State: AEkoouvSX/FM91sKoIDFbj2e7bvrEU2bVCvbI3J5lW/x8LJtB+nXFQOBFdfS4WX5c50qCRstfCdvFkfdN6xUVw== X-Received: by 10.31.192.202 with SMTP id q193mr3500553vkf.44.1471616628665; Fri, 19 Aug 2016 07:23:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.4.198 with HTTP; Fri, 19 Aug 2016 07:23:47 -0700 (PDT) In-Reply-To: References: <013b01d1f8ee$31fa09b0$95ee1d10$@ndzh.com> <20160818073203.GA4338@elstar.local> <04b501d1f949$116c63e0$34452ba0$@ndzh.com> <20160818121405.GA5282@elstar.local> <051301d1f950$7739c670$65ad5350$@ndzh.com> <20160818130555.GA5366@elstar.local> <051701d1f952$c4ae0b30$4e0a2190$@ndzh.com> <6BCE198E4EAEFC4CAB45D75826EFB0761525CCD7@eusaamb101.ericsson.se> <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> From: Andy Bierman Date: Fri, 19 Aug 2016 07:23:47 -0700 Message-ID: To: Lou Berger Content-Type: multipart/alternative; boundary=001a114398de65c404053a6d7225 Archived-At: X-Mailman-Approved-At: Fri, 19 Aug 2016 08:01:35 -0700 Cc: "i2rs@ietf.org" , Alissa Cooper , Juergen Schoenwaelder , i2rs-chairs@ietf.org, Kathleen Moriarty , IESG , Jeffrey Haas , Joel Halpern , Susan Hares , 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Aug 2016 14:24:05 -0000 --001a114398de65c404053a6d7225 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, I agree with Juergen. There are already too many details that need consensus to move a YANG module forward in the IETF. It takes too long already. 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? Standardized insecure access is a big change from what we have done for 30 years. There could be a good reason why we left this out of scope all this time. Andy On Fri, Aug 19, 2016 at 5:20 AM, Lou Berger wrote: > > Sue, > > My message said three things: > > 1) Juergen's comment resonates with me. > > 2) I think the current text is acceptable. > > 3) I see changing the SHOULD to a MUST as problematic. > I understood one of the other messages on this thread proposing this > change which is what triggered my message. If I misunderstood that > message, feel free to interpret my message as supporting the current > text in question. > > Note that I am only speaking for myself (including in my role as NETMOD > co-chair) and not representing the consensus opinion of any WG. > > Lou > On 8/19/2016 8:07 AM, Susan Hares wrote: > > Lou: > > > > I am clear that Juergen does not want not want to place transport > requirements within the data model for NETMOD. His opinion was considere= d > in the rough for the I2RS WG. If this requirement is a problem for > NETCONF/NETMOD, the text currently says: > > > > REQ-SEC-09 states: > > > > The default mode of transport is secure so data models SHOULD clearly > annotate what data nodes can be > > passed over an insecure connection. > > > > However, if this means the NETCONF/NETMOD WG will not even entertain > proposal for marking the insecure functions in yang text -- then the two = WG > (I2RS/NETMOD) have a problem and should stop this standardization process > going forward. > > > > Sue > > > > > > -----Original Message----- > > From: Lou Berger [mailto:lberger@labn.net] > > Sent: Friday, August 19, 2016 7:34 AM > > To: Susan Hares; 'Juergen Schoenwaelder' > > Cc: i2rs@ietf.org; 'Alissa Cooper'; i2rs-chairs@ietf.org; 'Kathleen > Moriarty'; 'IESG'; jhaas@pfrc.org; '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) > > > > Sue, > > > > I don't see Juergen as arguing against model access via non-secure > transport. I read his point as that the transport security requirements > don't belong scattered within a data model. > > > > I have to say that from a model complexity (definition, process, review= , > implementation - take your pick) , language and NETMOD co-chair > perspective, his comment resonates with me. > > > > I think this makes the key text: > > > > The default mode of transport is > > secure so data models SHOULD clearly annotate what data nodes can be > > passed over an insecure connection. > > > > > > As this isn't a MUST, I personally think we can live with the text and > we can debate the issue further in the context of specific solutions. I > would strongly object to this being changed to a MUST, or if the document > is changed to make transport (security) requirements identified within da= ta > models a requirement. > > > > Lou > > > > On 8/19/2016 6:49 AM, Susan Hares wrote: > >> Juergen: > >> > >> You have laid out the two options: a) link the data-model to the > non-secure transport, and b) do not link the data to the non-secure > transport. I agree with you that past models did not link past SNMP MIB > data model to the transport. Existing NETCONF models do not link it to t= he > transport. As you have indicated, you disagreed in the I2RS WG and we > found consensus was to include the non-secure transport. > >> > >> I2RS was created to build things as an interface to the routing > environment. The operators clearly informed the I2RS group of this need > during the requirement setting phase prior to the time I was chair. The > reason I continue to press for this capability is their input, and the > existing use cases I listed previously in this mail: > >> > >> a) public information - BGP route views, > >> b) specific well know up events - such as public-web site up > >> c) specific network service events - interface to particular public LA= N > up. > >> > >> As you know, we do not have any I2RS data models that specify this > feature at this time. I suspect after we get through this lengthy > requirement phase, the operators may begin to specify new models that hav= e > this feature. > >> > >> Sue > >> > >> -----Original Message----- > >> From: Juergen Schoenwaelder > >> [mailto:j.schoenwaelder@jacobs-university.de] > >> Sent: Friday, August 19, 2016 4:58 AM > >> To: Susan Hares > >> Cc: 'Alissa Cooper'; 'Joel Halpern'; i2rs@ietf.org; > >> i2rs-chairs@ietf.org; 'Kathleen Moriarty'; 'IESG'; jhaas@pfrc.org; > >> 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) > >> > >> I repeat my technical argument: While there may be deployments where > non-secure transports may be reasonable to use, defining these situations > statically as part of data model schemas does not follow established > practices. The IETF has a long tradition of standardizing data models tha= t > can be used in a variety of operational contexts and I do not see reasons > why we should move away from that basic approach. > >> > >> /js > >> > >> On Thu, Aug 18, 2016 at 02:35:03PM -0400, Susan Hares wrote: > >>> Alissa: > >>> > >>> Just a little input you may not know. My background is 15 years > (1995-2010) developing a routing/switching platform (denoted as GateD) > which was sold to over 200 companies. We developed XML and a binary XML > based product that configured this product. It could do 100K configurati= on > lines and reboot in less than a second on most hardware. We also provide > status messages in secure streams and non-secure streams. I sold early > version of this code to companies that Alia has worked for - so she has > personal viewed the code. At the height of our work, our development te= am > ran to 50 people which I directed (First as VP of Engineering, and then a= s > CTO). It is due to this level of experience that Alia selected me for the > co-chair. Russ White has understood Cisco's process, and has also > directed software development teams for routing. > >>> > >>> In order to freshen my direct experience with I2RS on open source > work, I am working on a publically available work in Quagga based on the > confD product suggested by Cisco. > >>> > >>> In contrast, Juergen is a university professor who has worked on > proto-types. He is not working on an implementation. I hope he will. > >>> > >>> I hope you will consider this background in my response to your > comments below. > >>> > >>> Sue > >>> > >>> > >>> -----Original Message----- > >>> From: Alissa Cooper [mailto:alissa@cooperw.in] > >>> Sent: Thursday, August 18, 2016 12:54 PM > >>> To: Joel Halpern > >>> Cc: Susan Hares; Juergen Schoenwaelder; i2rs@ietf.org; > >>> i2rs-chairs@ietf.org; Kathleen Moriarty; IESG; jhaas@pfrc.org; > >>> 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) > >>> > >>> Jumping in here because this is relevant to my DISCUSS, hope nobody > minds (but if you do, I can go back to the other thread). > >>> > >>>>> On Aug 18, 2016, at 10:30 AM, Joel Halpern < > joel.halpern@ericsson.com> wrote: > >>>>> > >>>>> Let me try a different take approach to this particular question. > >>>>> > >>>>> Let me start by putting aside the question of where things are > marked, and come back to that afterwards. > >>>>> > >>>>> There are a number of cases that I2RS has been asked to cover of > high rate telemetry data. This may be BGP update information, it may be > frequent information about line card activity. There are other cases, so= me > of which have been documented. > >>>>> > >>>>> While not completely insensitive, the operators have made clear tha= t > they see protecting this data as unnecessary. While I would hope over ti= me > to move to a domain where all of it is protect, that is not trivial. As > the I2RS Architecture points out, it is expected that what we describe as= a > single I2RS >communication between a client and agent is actually > associated with multiple channels of communication. > >>>>> > >>>>> Now, if you want to say that the I2RS protocol requirements cannot > allow for unprotected channels, I guess we have disconnect between the IE= SG > and the WG. > >>>>> > >>>>> If we say that we can allow for unprotected channels, we then get t= o > the question of which data can be sent over such channels. While > architecturally I agree with Juergen that the model is a bad place to > specify it, the obverse is also true. Not having some limits on what can > be sent unprotected >causes concern about insufficient protection. If I > recall correctly, earlier security reviews called us to task for being to= o > broad in what we allowed. > >>>>> > >>>>> So, if the IESG wants us to just allow it anywhere, because the > >>>>> model is an awkward place to define the limitation, I can live with > that. What I can't live with is being told both that the model is a bad > place to define it and that there must be restrictions on what is sent > unprotected, without any proposal on how we are to move forward. > >>>> Thank you Joel, this explanation helps me a lot. I think there is a > disconnect about how the restrictions are expressed. From reading the ema= il > traffic about this document, it strikes me that trying to express the > restrictions programmatically doesn=E2=80=99t make much sense in this cas= e. > >>>> I agree with Juergen that it will be challenging to make a judgment = a > priori in order to bake a restriction into a data model, because data tha= t > is considered sensitive enough to warrant a secure transport in one > deployment may not be considered sensitive in another deployment. > >>>> So for any data elements where there is any question at all about > >>>> whether they might be sensitive (i.e., any data elements that are no= t > already routinely made public), I would expect data model authors to end = up > indicating that they may be sent over either secure or insecure transport= , > which renders the indication not useful. > >>>> Perhaps it would make more sense then to just enumerate in the text > the cases that motivate the inclusion of protocol support for insecure > transport: > >>>> > >>>> 1. For conveyance of information that is already routinely made > public. > >>>> 2. For line card activity data where there is no likely upgrade path > to support secure transports in the foreseeable future. > >>>> > >>>> Then the normative requirements would be on clients and agents to us= e > secure transports unless those clients and agents are deployed where eith= er > of the operational circumstances above necessitate otherwise. > >>>> Alissa > >>> Point 1: > >>> I disagree with Juergen on the difficulty in specifying the sections > of the yang modules. I have provided a suggested solution in: > >>> https://tools.ietf.org/html/draft-hares-i2rs-protocol- > strawman-03#section-4.5.2. > >>> > >>> Given the mount schema functionality, we can mount ephemeral state > module which augment non-ephemeral state modules which are "in-secure onl= y". > >>> > >>> Point 2: > >>> I am willing to put an enumeration of the use cases in the protocol > requirement, but I would like to understand the purpose for the > enumeration. We are not doing a use case, but a requirements document. > This information appears to be a "use case" rather than a technical > description. What purpose are you looking for this enumeration to > server. Are you looking for the enumeration in SEC-REQ-08? > >>> > >>> Point 3: Could you review -08.txt on this topic, especially the text > below. Given your comments, I believe I should change the last line to a > MUST. > >>> New/ The default mode of transport is > >>> secure so data models MUST clearly annotate what data nodes can be > >>> passed over an insecure connection. > >>> / > >>> > >>> Sue > >>> > >>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >>> As to the normative requirements (-08.txt) version: > >>> > >>> Section 3: > >>> > >>> I2RS allows the use of an insecure transport for portions of data > >>> models that clearly indicate the use of an insecure transport. > >>> Operators deploying I2RS must determine if they want to populate a= nd > >>> deploy the portions of the data model which use insecure transport= s. > >>> > >>> In Section 3.2 in version -08.txt > >>> > >>> SEC-REQ-08: The I2RS protocol MUST be able to transfer data over a > >>> secure transport and optionally MAY be able to transfer data over = a > >>> non-secure transport. A secure transport MUST provide data > >>> confidentiality, data integrity, and replay prevention. > >>> > >>> The default I2RS transport is a secure transport. > >>> > >>> A non-secure transport can be used for publishing telemetry data o= r > >>> other operational state that was specifically indicated to non- > >>> confidential in the data model in the Yang syntax. > >>> > >>> The configuration of ephemeral data in the I2RS Agent by the I2RS > >>> client SHOULD be done over a secure transport. It is anticipated > >>> that the passing of most I2RS ephemeral state operational status > >>> SHOULD be done over a secure transport. As > >>> [I-D.ietf-i2rs-ephemeral-state] notes, a data model MUST indicate > >>> whether the transport exchanging the data between I2RS client and > >>> I2RS agent is secure or insecure. > >>> > >>> The default mode of transport is > >>> secure so data models SHOULD clearly annotate what data nodes can = be > >>> passed over an insecure connection. > >>> > >>>> Yours, > >>>> Joel > >>>> > >>>> -----Original Message----- > >>>> From: Susan Hares [mailto:shares@ndzh.com] > >>>> Sent: Thursday, August 18, 2016 9:17 AM > >>>> To: 'Juergen Schoenwaelder' > >>>> Cc: i2rs@ietf.org; i2rs-chairs@ietf.org; 'Kathleen Moriarty' > >>>> ; 'The IESG' ; > >>>> jhaas@pfrc.org; > >>>> 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) > >>>> > >>>> Juergen and Kathleen: > >>>> > >>>> Let me proceed with two examples: BGP route views data model and the > event for the web-service data. > >>>> > >>>> The content of these data models are designated as exposed to > public. The routing system only populates the proposed BGP route views > data model with the data destined for the BGP looking glass. The policy = on > the routing system indicates what information gets transferred. The data > model is completely available to the public. The Yang Doctors are going = to > review this by seeing the whole model is public and available via > non-secure means. > >>>> The security people are going to review this seeing that the whole > model is public, and available via an unprotect means. The fact the data > model is all public should simplify the review. > >>>> > >>>> An event from the I2RS RIB that a web-service route is up is the > second case. The I2RS RIB has an event based on policy that indicates a > web-service route is up. The yang-1.1 doctors must review the content of > the event text to see it does not break privacy or provide too much > >>>> information The event mechanisms will need to work over secure > transport > >>>> and insecure transport. Most of the data will go over the secure > transport event stream. However, a small amount of information may go ove= r > the insecure transport stream. > >>>> > >>>> First, let me know if my use cases are understandable. Second, let > me know if you disagree with this use cases. > >>>> > >>>> Fyi - IESG approved the architecture with the insecure stream. > >>>> > >>>> Sue > >>>> > >>>> -----Original Message----- > >>>> From: Juergen Schoenwaelder > >>>> [mailto:j.schoenwaelder@jacobs-university.de] > >>>> Sent: Thursday, August 18, 2016 9:06 AM > >>>> To: Susan Hares > >>>> Cc: i2rs@ietf.org; i2rs-chairs@ietf.org; 'Kathleen Moriarty'; 'The > >>>> IESG'; jhaas@pfrc.org; > >>>> 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) > >>>> > >>>> I just do not know on which basis a data model writer can decide > whether a data object can be exposed in an unprotected way. How are YANG > doctors going to review this? How are security directorate people going t= o > judge this? But as promised, I leave (still puzzled) now. > >>>> > >>>> /js > >>>> > >>>> On Thu, Aug 18, 2016 at 09:00:14AM -0400, Susan Hares wrote: > >>>>> Juergen: > >>>>> > >>>>> Yes, we seem to disagree on the value of making it hardwired in the > model. > >>>>> For me, the value is a common understanding of deployment > >>>>> distribution > >>>> such > >>>>> as the route-views. Since the operators argued strongly for this > point, > >>>> I > >>>>> think the best idea is to get it working in code and then see if > >>>>> the deployment matches the requests. > >>>>> > >>>>> Sue > >>>>> > >>>>> -----Original Message----- > >>>>> From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Juergen > >>>>> Schoenwaelder > >>>>> Sent: Thursday, August 18, 2016 8:14 AM > >>>>> To: Susan Hares > >>>>> Cc: i2rs@ietf.org; i2rs-chairs@ietf.org; 'Kathleen Moriarty'; 'The > >>>>> IESG'; jhaas@pfrc.org; > >>>>> 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) > >>>>> > >>>>> Sue, > >>>>> > >>>>> I still do not see why the 'mode of exposure' of data benefits from > >>>>> being hard-wired in the data model. For me, it is a situational and > >>>>> deployment specific question. But I shut up here since I aired this > >>>>> concern before (and we simply seem to disagree). > >>>>> > >>>>> /js > >>>>> > >>>>> On Thu, Aug 18, 2016 at 08:07:18AM -0400, Susan Hares wrote: > >>>>>> Juergen: > >>>>>> > >>>>>> My example is the looking glass servers for the BGP route views > >>>>>> project > >>>>>> (http://www.routeviews.org/) or a route indicating the presence of > a > >>>>>> web-server that is public. For the BGP I2RS route, a yang model > could > >>>>>> replace the looking glass function, and provide events for these > looking > >>>>>> glass functions. For the web-server route, an event be sent wh= en > >>>> that > >>>>>> one route is added. > >>>>>> > >>>>>> Sue > >>>>>> > >>>>>> > >>>>>> -----Original Message----- > >>>>>> From: Juergen Schoenwaelder > >>>>>> [mailto:j.schoenwaelder@jacobs-university.de] > >>>>>> Sent: Thursday, August 18, 2016 3:32 AM > >>>>>> To: Susan Hares > >>>>>> Cc: 'Kathleen Moriarty'; 'The IESG'; jhaas@pfrc.org; > >>>>>> i2rs@ietf.org; i2rs-chairs@ietf.org; > >>>>>> 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 Wed, Aug 17, 2016 at 09:16:48PM -0400, Susan Hares wrote: > >>>>>>> ----------------------------------------------------------------- > >>>>>>> - > >>>>>>> -- > >>>>>>> -- > >>>>>>> COMMENT: > >>>>>>> ----------------------------------------------------------------- > >>>>>>> - > >>>>>>> -- > >>>>>>> -- > >>>>>>> > >>>>>>>> Section 3: > >>>>>>>> Can you clarify the second to last sentence? Do you mean there > >>>>>>>> are > >>>>>> sections that indicate an insecure transport should be used? > >>>>>>>> I2RS allows the use of an > >>>>>>>> insecure transport for portions of data models that clearly > >>>>>>>> indicate insecure transport. > >>>>>>>> Perhaps: > >>>>>>>> I2RS allows the use of an > >>>>>>>> insecure transport for portions of data models that clearly > >>>>>>>> indicate the use of an insecure transport. > >>>>>> I still wonder how a data model writer can reasonably decide > >>>>>> whether a piece of information can be shipped safely over an > >>>>>> insecure transport since this decision often depends on the > >>>>>> specifics of a deployment > >>>>> situation. > >>>>>> /js > >>>>>> > >>>>>> PS: I hope we do not end up with defining data multiple times (onc= e > >>>>>> for insecure transport and once for secured transports). > >>>>>> > >>>>>> -- > >>>>>> Juergen Schoenwaelder Jacobs University Bremen gGmbH > >>>>>> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | > Germany > >>>>>> Fax: +49 421 200 3103 > >>>>>> > >>>>>> _______________________________________________ > >>>>>> i2rs mailing list > >>>>>> i2rs@ietf.org > >>>>>> https://www.ietf.org/mailman/listinfo/i2rs > >>>>> -- > >>>>> Juergen Schoenwaelder Jacobs University Bremen gGmbH > >>>>> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | > Germany > >>>>> Fax: +49 421 200 3103 > >>>>> > >>>>> _______________________________________________ > >>>>> i2rs mailing list > >>>>> i2rs@ietf.org > >>>>> https://www.ietf.org/mailman/listinfo/i2rs > >>>>> > >>>> -- > >>>> Juergen Schoenwaelder Jacobs University Bremen gGmbH > >>>> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germa= ny > >>>> Fax: +49 421 200 3103 > >>>> > > > > > > > > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs > --001a114398de65c404053a6d7225 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

I agree with Juergen.
The= re are already too many details that need consensus to move
a YAN= G module forward in the IETF.=C2=A0 It takes too long already.
We could have been tagging MIB objects all along, but we don&#= 39;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 decid= e this
debate in a WG? Does SEC-DIR really want to be flooded wit= h review
requests so they become a bottleneck in YANG RFC publica= tion process?

Standardized insecure access is a bi= g change from what we have done
for 30 years.=C2=A0 There could b= e a good reason why we left this out of scope
all this time.


Andy


On Fri, Aug 19, 2016 at 5= :20 AM, Lou Berger <lberger@labn.net> wrote:

Sue,

My message said three things:

1) Juergen's comment resonates with me.

2) I think the current text is acceptable.

3) I see changing the SHOULD to a MUST as problematic.
I understood one of the other messages on this thread proposing this
change which is what triggered my message.=C2=A0 =C2=A0If I misunderstood t= hat
message, feel free to interpret my message as supporting the current
text in question.

Note that I am only speaking for myself (including in my role as NETMOD
co-chair) and not representing the consensus opinion of any WG.

Lou
On 8/19/2016 8:07 AM, Susan Hares wrote:
> Lou:
>
> I am clear that Juergen does not want not want to place transport requ= irements within the data model for NETMOD.=C2=A0 His opinion was considered= in the rough for the I2RS WG. If this requirement is a problem for NETCONF= /NETMOD,=C2=A0 the text currently says:
>
> REQ-SEC-09 states:
>
>=C2=A0 =C2=A0The default mode of transport is secure so data models SHO= ULD clearly annotate what data nodes can be
>=C2=A0 =C2=A0 passed over an insecure connection.
>
> However, if this means the NETCONF/NETMOD WG will not even entertain p= roposal for marking the insecure functions in yang text -- then the two WG = (I2RS/NETMOD) have a problem and should stop this standardization process g= oing forward.
>
> Sue
>
>
> -----Original Message-----
> From: Lou Berger [mailto:lberger@l= abn.net]
> Sent: Friday, August 19, 2016 7:34 AM
> To: Susan Hares; 'Juergen Schoenwaelder'
> Cc: i2rs@ietf.org; 'Alissa Co= oper'; i2rs-chairs@ietf.org= ; 'Kathleen Moriarty'; 'IESG'; jhaas@pfrc.org; '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)
>
> Sue,
>
>=C2=A0 =C2=A0 =C2=A0I don't see Juergen as arguing against model ac= cess via non-secure transport. I read his point as that the transport secur= ity requirements don't belong scattered within a data model.
>
> I have to say that from a model complexity (definition, process, revie= w, implementation - take your pick) , language and NETMOD co-chair perspect= ive, his comment resonates with me.
>
> I think this makes the key text:
>
>=C2=A0 =C2=A0 The default mode of transport is
>=C2=A0 =C2=A0 secure so data models SHOULD clearly annotate what data n= odes can be
>=C2=A0 =C2=A0 passed over an insecure connection.
>
>
> As this isn't a MUST, I personally think we can live with the text= and we can debate the issue further in the context of specific solutions.= =C2=A0 I would strongly object to this being changed to a MUST, or if the d= ocument is changed to make transport (security) requirements identified wit= hin data models a requirement.
>
> Lou
>
> On 8/19/2016 6:49 AM, Susan Hares wrote:
>> Juergen:
>>
>> You have laid out the two options:=C2=A0 =C2=A0a) link the data-mo= del to the non-secure transport, and b) do not link the data to the non-sec= ure transport.=C2=A0 =C2=A0I agree with you that past models did not link p= ast SNMP MIB data model to the transport.=C2=A0 Existing NETCONF models do = not link it to the transport.=C2=A0 =C2=A0As you have indicated, you disagr= eed in the I2RS WG and we found consensus was to include the non-secure tra= nsport.
>>
>> I2RS was created to build things as an interface to the routing en= vironment.=C2=A0 =C2=A0The operators clearly informed the I2RS group of thi= s need during the requirement setting phase prior to the time I was chair.= =C2=A0 The reason I continue to press for this capability is their input, a= nd the existing use cases I listed previously in this mail:
>>
>> a) public information - BGP route views,
>> b) specific well know up events - such as public-web site up
>> c) specific network service events - interface to particular publi= c LAN up.
>>
>> As you know, we do not have any I2RS data models that specify this= feature at this time.=C2=A0 =C2=A0I suspect after we get through this leng= thy requirement phase, the operators may begin to specify new models that h= ave this feature.
>>
>> Sue
>>
>> -----Original Message-----
>> From: Juergen Schoenwaelder
>> [mailto:j.= schoenwaelder@jacobs-university.de]
>> Sent: Friday, August 19, 2016 4:58 AM
>> To: Susan Hares
>> Cc: 'Alissa Cooper'; 'Joel Halpern'; i2rs@ietf.org;
>> i2rs-chairs@ietf.org; = 'Kathleen Moriarty'; 'IESG'; jhaas@pfrc.org;
>> draft-ietf-i2rs-protocol-security-requirements@ietf.org >> Subject: Re: [i2rs] Kathleen Moriarty's Discuss on
>> draft-ietf-i2rs-protocol-security-requirements-07: (with DISC= USS and
>> COMMENT)
>>
>> I repeat my technical argument: While there may be deployments whe= re non-secure transports may be reasonable to use, defining these situation= s statically as part of data model schemas does not follow established prac= tices. The IETF has a long tradition of standardizing data models that can = be used in a variety of operational contexts and I do not see reasons why w= e should move away from that basic approach.
>>
>> /js
>>
>> On Thu, Aug 18, 2016 at 02:35:03PM -0400, Susan Hares wrote:
>>> Alissa:
>>>
>>> Just a little input you may not know.=C2=A0 My background is 1= 5 years (1995-2010)=C2=A0 developing a routing/switching platform (denoted = as GateD) which was sold to over 200 companies.=C2=A0 =C2=A0We developed XM= L and a binary XML based product that configured this product.=C2=A0 It cou= ld do 100K configuration lines and reboot in less than a second on most har= dware.=C2=A0 We also provide status messages in secure streams and non-secu= re streams.=C2=A0 =C2=A0 I sold early version of this code to companies tha= t Alia has worked for=C2=A0 - so she has personal viewed the code.=C2=A0 = =C2=A0At the height of our work, our development team ran to 50 people whic= h I directed (First as VP of Engineering, and then as CTO). It is due to th= is level of experience that Alia selected me for the co-chair.=C2=A0 =C2=A0= Russ White has understood Cisco's process, and has also directed softwa= re development teams for routing.
>>>
>>> In order to freshen my direct experience with I2RS on open sou= rce work, I am working on a publically available work in Quagga based on th= e confD product suggested by Cisco.
>>>
>>> In contrast, Juergen is a university professor who has worked = on proto-types.=C2=A0 =C2=A0He is not working on an implementation.=C2=A0 = =C2=A0I hope he will.
>>>
>>> I hope you will consider this background in my response to you= r comments below.
>>>
>>> Sue
>>>
>>>
>>> -----Original Message-----
>>> From: Alissa Cooper [mailto:alissa@cooperw.in]
>>> Sent: Thursday, August 18, 2016 12:54 PM
>>> To: Joel Halpern
>>> Cc: Susan Hares; Juergen Schoenwaelder; i2rs@ietf.org;
>>> i2rs-chairs@ietf.org; Kathleen Moriarty; IESG; jhaas@pfrc.o= rg;
>>> 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)
>>>
>>> Jumping in here because this is relevant to my DISCUSS, hope n= obody minds (but if you do, I can go back to the other thread).
>>>
>>>>> On Aug 18, 2016, at 10:30 AM, Joel Halpern <joel.halpern@ericsson.com> wro= te:
>>>>>
>>>>> Let me try a different take approach to this particula= r question.
>>>>>
>>>>> Let me start by putting aside the question of where th= ings are marked, and come back to that afterwards.
>>>>>
>>>>> There are a number of cases that I2RS has been asked t= o cover of high rate telemetry data.=C2=A0 This may be BGP update informati= on, it may be frequent information about line card activity.=C2=A0 There ar= e other cases, some of which have been documented.
>>>>>
>>>>> While not completely insensitive, the operators have m= ade clear that they see protecting this data as unnecessary.=C2=A0 While I = would hope over time to move to a domain where all of it is protect, that i= s not trivial.=C2=A0 As the I2RS Architecture points out, it is expected th= at what we describe as a single I2RS >communication between a client and= agent is actually associated with multiple channels of communication.
>>>>>
>>>>> Now, if you want to say that the I2RS protocol require= ments cannot allow for unprotected channels, I guess we have disconnect bet= ween the IESG and the WG.
>>>>>
>>>>> If we say that we can allow for unprotected channels, = we then get to the question of which data can be sent over such channels.= =C2=A0 While architecturally I agree with Juergen that the model is a bad p= lace to specify it, the obverse is also true.=C2=A0 Not having some limits = on what can be sent unprotected >causes concern about insufficient prote= ction.=C2=A0 If I recall correctly, earlier security reviews called us to t= ask for being too broad in what we allowed.
>>>>>
>>>>> So, if the IESG wants us to just allow it anywhere, be= cause the
>>>>> model is an awkward place to define the limitation, I = can live with that.=C2=A0 What I can't live with is being told both tha= t the model is a bad place to define it and that there must be restrictions= on what is sent unprotected, without any proposal on how we are to move fo= rward.
>>>> Thank you Joel, this explanation helps me a lot. I think t= here is a disconnect about how the restrictions are expressed. From reading= the email traffic about this document, it strikes me that trying to expres= s the restrictions programmatically doesn=E2=80=99t make much sense in this= case.
>>>> I agree with Juergen that it will be challenging to make a= judgment a priori in order to bake a restriction into a data model, becaus= e data that is considered sensitive enough to warrant a secure transport in= one deployment may not be considered sensitive in another deployment.
>>>> So for any data elements where there is any question at al= l about
>>>> whether they might be sensitive (i.e., any data elements t= hat are not already routinely made public), I would expect data model autho= rs to end up indicating that they may be sent over either secure or insecur= e transport, which renders the indication not useful.
>>>> Perhaps it would make more sense then to just enumerate in= the text the cases that motivate the inclusion of protocol support for ins= ecure transport:
>>>>
>>>> 1. For conveyance of information that is already routinely= made public.
>>>> 2. For line card activity data where there is no likely up= grade path to support secure transports in the foreseeable future.
>>>>
>>>> Then the normative requirements would be on clients and ag= ents to use secure transports unless those clients and agents are deployed = where either of the operational circumstances above necessitate otherwise.<= br> >>>> Alissa
>>> Point 1:
>>> I disagree with Juergen on the difficulty in specifying the se= ctions of the yang modules.=C2=A0 I have provided a suggested solution in:<= br> >>> https://= tools.ietf.org/html/draft-hares-i2rs-protocol-strawman-03#section= -4.5.2.
>>>
>>> Given the mount schema functionality, we can mount ephemeral s= tate module which augment non-ephemeral state modules which are "in-se= cure only".
>>>
>>> Point 2:
>>> I am willing to put an enumeration of the use cases in the pro= tocol requirement, but I would like to understand the purpose for the enume= ration.=C2=A0 =C2=A0We are not doing a use case, but a requirements documen= t.=C2=A0 This information appears to be a "use case" rather than = a technical description.=C2=A0 =C2=A0What purpose are you looking for this = enumeration to server.=C2=A0 Are you looking for the enumeration in SEC-REQ= -08?
>>>
>>> Point 3: Could you review -08.txt on this topic, especially th= e text below.=C2=A0 Given your comments, I believe I should change the last= line to a MUST.
>>> New/=C2=A0 =C2=A0The default mode of transport is
>>>=C2=A0 =C2=A0 secure so data models MUST clearly annotate what = data nodes can be
>>>=C2=A0 =C2=A0 passed over an insecure connection.
>>> /
>>>
>>> Sue
>>>
>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>>> As to the normative requirements (-08.txt) version:
>>>
>>> Section 3:
>>>
>>>=C2=A0 =C2=A0 I2RS allows the use of an insecure transport for = portions of data
>>>=C2=A0 =C2=A0 models that clearly indicate the use of an insecu= re transport.
>>>=C2=A0 =C2=A0 Operators deploying I2RS must determine if they w= ant to populate and
>>>=C2=A0 =C2=A0 deploy the portions of the data model which use i= nsecure transports.
>>>
>>> In Section 3.2 in version -08.txt
>>>
>>>=C2=A0 =C2=A0 SEC-REQ-08: The I2RS protocol MUST be able to tra= nsfer data over a
>>>=C2=A0 =C2=A0 secure transport and optionally MAY be able to tr= ansfer data over a
>>>=C2=A0 =C2=A0 non-secure transport.=C2=A0 A secure transport MU= ST provide data
>>>=C2=A0 =C2=A0 confidentiality, data integrity, and replay preve= ntion.
>>>
>>>=C2=A0 =C2=A0 The default I2RS transport is a secure transport.=
>>>
>>>=C2=A0 =C2=A0 A non-secure transport can be used for publishing= telemetry data or
>>>=C2=A0 =C2=A0 other operational state that was specifically ind= icated to non-
>>>=C2=A0 =C2=A0 confidential in the data model in the Yang syntax= .
>>>
>>>=C2=A0 =C2=A0 The configuration of ephemeral data in the I2RS A= gent by the I2RS
>>>=C2=A0 =C2=A0 client SHOULD be done over a secure transport.=C2= =A0 It is anticipated
>>>=C2=A0 =C2=A0 that the passing of most I2RS ephemeral state ope= rational status
>>>=C2=A0 =C2=A0 SHOULD be done over a secure transport.=C2=A0 As<= br> >>>=C2=A0 =C2=A0 [I-D.ietf-i2rs-ephemeral-state] notes,=C2=A0= a data model MUST indicate
>>>=C2=A0 =C2=A0 whether the transport exchanging the data between= I2RS client and
>>>=C2=A0 =C2=A0 I2RS agent is secure or insecure.
>>>
>>>=C2=A0 =C2=A0 The default mode of transport is
>>>=C2=A0 =C2=A0 secure so data models SHOULD clearly annotate wha= t data nodes can be
>>>=C2=A0 =C2=A0 passed over an insecure connection.
>>>
>>>> Yours,
>>>> Joel
>>>>
>>>> -----Original Message-----
>>>> From: Susan Hares [mailto:shares@ndzh.com]
>>>> Sent: Thursday, August 18, 2016 9:17 AM
>>>> To: 'Juergen Schoenwaelder' <j.schoenwaelder@jacobs-universit= y.de>
>>>> Cc: i2rs@ietf.org; i2rs-chairs@ietf.org; 'Kathle= en Moriarty'
>>>> <Ka= thleen.Moriarty.ietf@gmail.com>; 'The IESG' <iesg@ietf.org>;
>>>> jhaas@pfrc.org;
>>>> draft-ietf-i2rs-protocol-security-requirements@ietf.o= rg
>>>> Subject: RE: [i2rs] Kathleen Moriarty's Discuss on
>>>> draft-ietf-i2rs-protocol-security-requirements-07: (w= ith DISCUSS and
>>>> COMMENT)
>>>>
>>>> Juergen and Kathleen:
>>>>
>>>> Let me proceed with two examples: BGP route views data mod= el and the event for the web-service data.
>>>>
>>>> The content of these data models are designated as exposed= to public.=C2=A0 The routing system only populates the proposed BGP route = views data model with the data destined for the BGP looking glass.=C2=A0 Th= e policy on the routing system indicates what information gets transferred.= =C2=A0 The data model is completely available to the public.=C2=A0 The Yang= Doctors are going to review this by seeing the whole model is public and a= vailable via non-secure means.
>>>> The security people are going to review this seeing that t= he whole model is public, and available via an unprotect means.=C2=A0 The f= act the data model is all public should simplify the review.
>>>>
>>>> An event from the I2RS RIB that a web-service route is up = is the second case.=C2=A0 The I2RS RIB has an event based on policy that in= dicates a web-service route is up.=C2=A0 The yang-1.1 doctors must review t= he content of the event text to see it does not break privacy or provide to= o much
>>>> information=C2=A0 =C2=A0The event mechanisms will need to = work over secure transport
>>>> and insecure transport.=C2=A0 Most of the data will go ove= r the secure transport event stream. However, a small amount of information= may go over the insecure transport stream.
>>>>
>>>> First, let me know if my use cases are understandable.=C2= =A0 Second, let me know if you disagree with this use cases.
>>>>
>>>> Fyi -=C2=A0 IESG approved the architecture with the insecu= re stream.
>>>>
>>>> Sue
>>>>
>>>> -----Original Message-----
>>>> From: Juergen Schoenwaelder
>>>> [mailto:j.schoenwaelder@jacobs-university.de]
>>>> Sent: Thursday, August 18, 2016 9:06 AM
>>>> To: Susan Hares
>>>> Cc: i2rs@ietf.org; i2rs-chairs@ietf.org; 'Kathle= en Moriarty'; 'The
>>>> IESG'; jhaas@pfrc.or= g;
>>>> draft-ietf-i2rs-protocol-security-requirements@ietf.o= rg
>>>> Subject: Re: [i2rs] Kathleen Moriarty's Discuss on
>>>> draft-ietf-i2rs-protocol-security-requirements-07: (w= ith DISCUSS and
>>>> COMMENT)
>>>>
>>>> I just do not know on which basis a data model writer can = decide whether a data object can be exposed in an unprotected way. How are = YANG doctors going to review this? How are security directorate people goin= g to judge this? But as promised, I leave (still puzzled) now.
>>>>
>>>> /js
>>>>
>>>> On Thu, Aug 18, 2016 at 09:00:14AM -0400, Susan Hares wrot= e:
>>>>> Juergen:
>>>>>
>>>>> Yes, we seem to disagree on the value of making it har= dwired in the model.
>>>>> For me, the value is a common understanding of deploym= ent
>>>>> distribution
>>>> such
>>>>> as the route-views.=C2=A0 =C2=A0Since the operators ar= gued strongly for this point,
>>>> I
>>>>> think the best idea is to get it working in code and t= hen see if
>>>>> the deployment matches the requests.
>>>>>
>>>>> Sue
>>>>>
>>>>> -----Original Message-----
>>>>> From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Juergen
>>>>> Schoenwaelder
>>>>> Sent: Thursday, August 18, 2016 8:14 AM
>>>>> To: Susan Hares
>>>>> Cc: i2rs@ietf.org= ; i2rs-chairs@ietf.org; 'Ka= thleen Moriarty'; 'The
>>>>> IESG'; jhaas@pfr= c.org;
>>>>> draft-ietf-i2rs-protocol-security-requirements@ie= tf.org
>>>>> Subject: Re: [i2rs] Kathleen Moriarty's Discuss on=
>>>>> draft-ietf-i2rs-protocol-security-requirements-07= : (with DISCUSS
>>>>> and
>>>>> COMMENT)
>>>>>
>>>>> Sue,
>>>>>
>>>>> I still do not see why the 'mode of exposure' = of data benefits from
>>>>> being hard-wired in the data model. For me, it is a si= tuational and
>>>>> deployment specific question. But I shut up here since= I aired this
>>>>> concern before (and we simply seem to disagree).
>>>>>
>>>>> /js
>>>>>
>>>>> On Thu, Aug 18, 2016 at 08:07:18AM -0400, Susan Hares = wrote:
>>>>>> Juergen:
>>>>>>
>>>>>> My example is the looking glass servers for the BG= P route views
>>>>>> project
>>>>>> (http://www.routeviews.org/) or a route indic= ating the presence of a
>>>>>> web-server that is public.=C2=A0 =C2=A0For the BGP= I2RS route, a yang model could
>>>>>> replace the looking glass function, and provide ev= ents for these looking
>>>>>> glass functions.=C2=A0 =C2=A0 For the web-server r= oute,=C2=A0 an event be sent when
>>>> that
>>>>>> one route is added.
>>>>>>
>>>>>> Sue
>>>>>>
>>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Juergen Schoenwaelder
>>>>>> [mailto:j.schoenwaelder@jacobs-university.de]
>>>>>> Sent: Thursday, August 18, 2016 3:32 AM
>>>>>> To: Susan Hares
>>>>>> Cc: 'Kathleen Moriarty'; 'The IESG'= ;; jhaas@pfrc.org;
>>>>>> i2rs@ietf.org= ; i2rs-chairs@ietf.org;
>>>>>> draft-ietf-i2rs-protocol-security-requirement= s@ietf.org
>>>>>> Subject: Re: [i2rs] Kathleen Moriarty's Discus= s on
>>>>>> draft-ietf-i2rs-protocol-security-requirement= s-07: (with DISCUSS
>>>>>> and
>>>>>> COMMENT)
>>>>>>
>>>>>> On Wed, Aug 17, 2016 at 09:16:48PM -0400, Susan Ha= res wrote:
>>>>>>> -----------------------------------------= ------------------------
>>>>>>> -
>>>>>>> --
>>>>>>> --
>>>>>>> COMMENT:
>>>>>>> -----------------------------------------= ------------------------
>>>>>>> -
>>>>>>> --
>>>>>>> --
>>>>>>>
>>>>>>>> Section 3:
>>>>>>>> Can you clarify the second to last sentenc= e?=C2=A0 Do you mean there
>>>>>>>> are
>>>>>> sections that indicate an insecure transport shoul= d be used?
>>>>>>>>=C2=A0 I2RS allows the use of an
>>>>>>>> insecure transport for portions of data mo= dels that clearly
>>>>>>>> indicate=C2=A0 insecure transport.
>>>>>>>> Perhaps:
>>>>>>>> I2RS allows the use of an
>>>>>>>> insecure transport for portions of data mo= dels that clearly
>>>>>>>> indicate the use of an=C2=A0 insecure tran= sport.
>>>>>> I still wonder how a data model writer can reasona= bly decide
>>>>>> whether a piece of information can be shipped safe= ly over an
>>>>>> insecure transport since this decision often depen= ds on the
>>>>>> specifics of a deployment
>>>>> situation.
>>>>>> /js
>>>>>>
>>>>>> PS: I hope we do not end up with defining data mul= tiple times (once
>>>>>>=C2=A0 =C2=A0 for insecure transport and once for s= ecured transports).
>>>>>>
>>>>>> --
>>>>>> Juergen Schoenwaelder=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0Jacobs University Bremen gGmbH
>>>>>> Phone: +49 421 200 3587=C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0Campus Ring 1 | 28759 Bremen | Germany
>>>>>> Fax:=C2=A0 =C2=A0+49 421 200 3103=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0<http://www.jacobs-university.de/> >>>>>>
>>>>>> _____________________________________________= __
>>>>>> i2rs mailing list
>>>>>> i2rs@ietf.org=
>>>>>> https://www.ietf.org/mailman/listinfo/i2rs
>>>>> --
>>>>> Juergen Schoenwaelder=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0Jacobs University Bremen gGmbH
>>>>> Phone: +49 421 200 3587=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0Campus Ring 1 | 28759 Bremen | Germany
>>>>> Fax:=C2=A0 =C2=A0+49 421 200 3103=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0<http://www.jacobs-university.de/>
>>>>>
>>>>> _______________________________________________ >>>>> i2rs mailing list
>>>>> i2rs@ietf.org
>>>>> https://www.ietf.org/mailman/lis= tinfo/i2rs
>>>>>
>>>> --
>>>> Juergen Schoenwaelder=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0Jacobs University Bremen gGmbH
>>>> Phone: +49 421 200 3587=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0C= ampus Ring 1 | 28759 Bremen | Germany
>>>> Fax:=C2=A0 =C2=A0+49 421 200 3103=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0<http://www.jacobs-university.de/>
>>>>
>
>
>


_______________________________________________
i2rs mailing list
i2rs@ietf.org
https://www.ietf.org/mailman/listinfo/i2rs

--001a114398de65c404053a6d7225-- From nobody Fri Aug 19 08:28:09 2016 Return-Path: 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 055F112B04B; Fri, 19 Aug 2016 08:01:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.739 X-Spam-Level: * X-Spam-Status: No, score=1.739 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, RDNS_NONE=0.793] autolearn=no 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 p3TX4xRaOv7N; Fri, 19 Aug 2016 08:01:05 -0700 (PDT) Received: from hickoryhill-consulting.com (unknown [50.245.122.97]) (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 261C612D145; Fri, 19 Aug 2016 08:01:05 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=184.157.82.170; From: "Susan Hares" To: "'Andy Bierman'" , "'Lou Berger'" References: <013b01d1f8ee$31fa09b0$95ee1d10$@ndzh.com> <20160818073203.GA4338@elstar.local> <04b501d1f949$116c63e0$34452ba0$@ndzh.com> <20160818121405.GA5282@elstar.local> <051301d1f950$7739c670$65ad5350$@ndzh.com> <20160818130555.GA5366@elstar.local> <051701d1f952$c4ae0b30$4e0a2190$@ndzh.com> <6BCE198E4EAEFC4CAB45D75826EFB0761525CCD7@eusaamb101.ericsson.se> <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> In-Reply-To: Date: Fri, 19 Aug 2016 10:59:23 -0400 Message-ID: <036801d1fa2a$466e9e00$d34bda00$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0369_01D1FA08.BF638DB0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJ/RF5y8kBC7R3sO+auWKe566R2lwEcb/3KAg+ndAACAypBUwGJSPf4Amiv8FwDJLAGjQJqExQkAqfTovACEJToAwFDCzFbAlTVyfQCrq8/9AJKcpLBAq9whFMCDwN3eZ3wDEuA Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: X-Mailman-Approved-At: Fri, 19 Aug 2016 08:28:08 -0700 Cc: i2rs@ietf.org, 'Alissa Cooper' , 'Juergen Schoenwaelder' , 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) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Aug 2016 15:01:10 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0369_01D1FA08.BF638DB0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Andy:=20 =20 Thank you for your comments. Perhaps you can provide for the IESG the = list of things that are needed to move a Yang module forward in the = IETF. =20 =20 Sue=20 =20 From: Andy Bierman [mailto:andy@yumaworks.com]=20 Sent: Friday, August 19, 2016 10:24 AM To: Lou Berger Cc: Susan Hares; Juergen Schoenwaelder; 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) =20 Hi, =20 I agree with Juergen. There are already too many details that need consensus to move a YANG module forward in the IETF. It takes too long already. =20 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?" =20 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? =20 Standardized insecure access is a big change from what we have done for 30 years. There could be a good reason why we left this out of = scope all this time. =20 =20 Andy =20 =20 On Fri, Aug 19, 2016 at 5:20 AM, Lou Berger wrote: Sue, My message said three things: 1) Juergen's comment resonates with me. 2) I think the current text is acceptable. 3) I see changing the SHOULD to a MUST as problematic. I understood one of the other messages on this thread proposing this change which is what triggered my message. If I misunderstood that message, feel free to interpret my message as supporting the current text in question. Note that I am only speaking for myself (including in my role as NETMOD co-chair) and not representing the consensus opinion of any WG. Lou On 8/19/2016 8:07 AM, Susan Hares wrote: > Lou: > > I am clear that Juergen does not want not want to place transport = requirements within the data model for NETMOD. His opinion was = considered in the rough for the I2RS WG. If this requirement is a = problem for NETCONF/NETMOD, the text currently says: > > REQ-SEC-09 states: > > The default mode of transport is secure so data models SHOULD = clearly annotate what data nodes can be > passed over an insecure connection. > > However, if this means the NETCONF/NETMOD WG will not even entertain = proposal for marking the insecure functions in yang text -- then the two = WG (I2RS/NETMOD) have a problem and should stop this standardization = process going forward. > > Sue > > > -----Original Message----- > From: Lou Berger [mailto:lberger@labn.net] > Sent: Friday, August 19, 2016 7:34 AM > To: Susan Hares; 'Juergen Schoenwaelder' > Cc: i2rs@ietf.org; 'Alissa Cooper'; i2rs-chairs@ietf.org; 'Kathleen = Moriarty'; 'IESG'; jhaas@pfrc.org; '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) > > Sue, > > I don't see Juergen as arguing against model access via non-secure = transport. I read his point as that the transport security requirements = don't belong scattered within a data model. > > I have to say that from a model complexity (definition, process, = review, implementation - take your pick) , language and NETMOD co-chair = perspective, his comment resonates with me. > > I think this makes the key text: > > The default mode of transport is > secure so data models SHOULD clearly annotate what data nodes can = be > passed over an insecure connection. > > > As this isn't a MUST, I personally think we can live with the text and = we can debate the issue further in the context of specific solutions. I = would strongly object to this being changed to a MUST, or if the = document is changed to make transport (security) requirements identified = within data models a requirement. > > Lou > > On 8/19/2016 6:49 AM, Susan Hares wrote: >> Juergen: >> >> You have laid out the two options: a) link the data-model to the = non-secure transport, and b) do not link the data to the non-secure = transport. I agree with you that past models did not link past SNMP = MIB data model to the transport. Existing NETCONF models do not link it = to the transport. As you have indicated, you disagreed in the I2RS WG = and we found consensus was to include the non-secure transport. >> >> I2RS was created to build things as an interface to the routing = environment. The operators clearly informed the I2RS group of this = need during the requirement setting phase prior to the time I was chair. = The reason I continue to press for this capability is their input, and = the existing use cases I listed previously in this mail: >> >> a) public information - BGP route views, >> b) specific well know up events - such as public-web site up >> c) specific network service events - interface to particular public = LAN up. >> >> As you know, we do not have any I2RS data models that specify this = feature at this time. I suspect after we get through this lengthy = requirement phase, the operators may begin to specify new models that = have this feature. >> >> Sue >> >> -----Original Message----- >> From: Juergen Schoenwaelder >> [mailto:j.schoenwaelder@jacobs-university.de] >> Sent: Friday, August 19, 2016 4:58 AM >> To: Susan Hares >> Cc: 'Alissa Cooper'; 'Joel Halpern'; i2rs@ietf.org; >> i2rs-chairs@ietf.org; 'Kathleen Moriarty'; 'IESG'; jhaas@pfrc.org; >> 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) >> >> I repeat my technical argument: While there may be deployments where = non-secure transports may be reasonable to use, defining these = situations statically as part of data model schemas does not follow = established practices. The IETF has a long tradition of standardizing = data models that can be used in a variety of operational contexts and I = do not see reasons why we should move away from that basic approach. >> >> /js >> >> On Thu, Aug 18, 2016 at 02:35:03PM -0400, Susan Hares wrote: >>> Alissa: >>> >>> Just a little input you may not know. My background is 15 years = (1995-2010) developing a routing/switching platform (denoted as GateD) = which was sold to over 200 companies. We developed XML and a binary = XML based product that configured this product. It could do 100K = configuration lines and reboot in less than a second on most hardware. = We also provide status messages in secure streams and non-secure = streams. I sold early version of this code to companies that Alia has = worked for - so she has personal viewed the code. At the height of = our work, our development team ran to 50 people which I directed (First = as VP of Engineering, and then as CTO). It is due to this level of = experience that Alia selected me for the co-chair. Russ White has = understood Cisco's process, and has also directed software development = teams for routing. >>> >>> In order to freshen my direct experience with I2RS on open source = work, I am working on a publically available work in Quagga based on the = confD product suggested by Cisco. >>> >>> In contrast, Juergen is a university professor who has worked on = proto-types. He is not working on an implementation. I hope he will. >>> >>> I hope you will consider this background in my response to your = comments below. >>> >>> Sue >>> >>> >>> -----Original Message----- >>> From: Alissa Cooper [mailto:alissa@cooperw.in] >>> Sent: Thursday, August 18, 2016 12:54 PM >>> To: Joel Halpern >>> Cc: Susan Hares; Juergen Schoenwaelder; i2rs@ietf.org; >>> i2rs-chairs@ietf.org; Kathleen Moriarty; IESG; jhaas@pfrc.org; >>> 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) >>> >>> Jumping in here because this is relevant to my DISCUSS, hope nobody = minds (but if you do, I can go back to the other thread). >>> >>>>> On Aug 18, 2016, at 10:30 AM, Joel Halpern = wrote: >>>>> >>>>> Let me try a different take approach to this particular question. >>>>> >>>>> Let me start by putting aside the question of where things are = marked, and come back to that afterwards. >>>>> >>>>> There are a number of cases that I2RS has been asked to cover of = high rate telemetry data. This may be BGP update information, it may be = frequent information about line card activity. There are other cases, = some of which have been documented. >>>>> >>>>> While not completely insensitive, the operators have made clear = that they see protecting this data as unnecessary. While I would hope = over time to move to a domain where all of it is protect, that is not = trivial. As the I2RS Architecture points out, it is expected that what = we describe as a single I2RS >communication between a client and agent = is actually associated with multiple channels of communication. >>>>> >>>>> Now, if you want to say that the I2RS protocol requirements cannot = allow for unprotected channels, I guess we have disconnect between the = IESG and the WG. >>>>> >>>>> If we say that we can allow for unprotected channels, we then get = to the question of which data can be sent over such channels. While = architecturally I agree with Juergen that the model is a bad place to = specify it, the obverse is also true. Not having some limits on what = can be sent unprotected >causes concern about insufficient protection. = If I recall correctly, earlier security reviews called us to task for = being too broad in what we allowed. >>>>> >>>>> So, if the IESG wants us to just allow it anywhere, because the >>>>> model is an awkward place to define the limitation, I can live = with that. What I can't live with is being told both that the model is = a bad place to define it and that there must be restrictions on what is = sent unprotected, without any proposal on how we are to move forward. >>>> Thank you Joel, this explanation helps me a lot. I think there is a = disconnect about how the restrictions are expressed. From reading the = email traffic about this document, it strikes me that trying to express = the restrictions programmatically doesn=E2=80=99t make much sense in = this case. >>>> I agree with Juergen that it will be challenging to make a judgment = a priori in order to bake a restriction into a data model, because data = that is considered sensitive enough to warrant a secure transport in one = deployment may not be considered sensitive in another deployment. >>>> So for any data elements where there is any question at all about >>>> whether they might be sensitive (i.e., any data elements that are = not already routinely made public), I would expect data model authors to = end up indicating that they may be sent over either secure or insecure = transport, which renders the indication not useful. >>>> Perhaps it would make more sense then to just enumerate in the text = the cases that motivate the inclusion of protocol support for insecure = transport: >>>> >>>> 1. For conveyance of information that is already routinely made = public. >>>> 2. For line card activity data where there is no likely upgrade = path to support secure transports in the foreseeable future. >>>> >>>> Then the normative requirements would be on clients and agents to = use secure transports unless those clients and agents are deployed where = either of the operational circumstances above necessitate otherwise. >>>> Alissa >>> Point 1: >>> I disagree with Juergen on the difficulty in specifying the sections = of the yang modules. I have provided a suggested solution in: >>> = https://tools.ietf.org/html/draft-hares-i2rs-protocol-strawman-03#section= -4.5.2. >>> >>> Given the mount schema functionality, we can mount ephemeral state = module which augment non-ephemeral state modules which are "in-secure = only". >>> >>> Point 2: >>> I am willing to put an enumeration of the use cases in the protocol = requirement, but I would like to understand the purpose for the = enumeration. We are not doing a use case, but a requirements document. = This information appears to be a "use case" rather than a technical = description. What purpose are you looking for this enumeration to = server. Are you looking for the enumeration in SEC-REQ-08? >>> >>> Point 3: Could you review -08.txt on this topic, especially the text = below. Given your comments, I believe I should change the last line to = a MUST. >>> New/ The default mode of transport is >>> secure so data models MUST clearly annotate what data nodes can = be >>> passed over an insecure connection. >>> / >>> >>> Sue >>> >>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>> As to the normative requirements (-08.txt) version: >>> >>> Section 3: >>> >>> I2RS allows the use of an insecure transport for portions of data >>> models that clearly indicate the use of an insecure transport. >>> Operators deploying I2RS must determine if they want to populate = and >>> deploy the portions of the data model which use insecure = transports. >>> >>> In Section 3.2 in version -08.txt >>> >>> SEC-REQ-08: The I2RS protocol MUST be able to transfer data over = a >>> secure transport and optionally MAY be able to transfer data over = a >>> non-secure transport. A secure transport MUST provide data >>> confidentiality, data integrity, and replay prevention. >>> >>> The default I2RS transport is a secure transport. >>> >>> 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. >>> >>> The configuration of ephemeral data in the I2RS Agent by the I2RS >>> client SHOULD be done over a secure transport. It is anticipated >>> that the passing of most I2RS ephemeral state operational status >>> SHOULD be done over a secure transport. As >>> [I-D.ietf-i2rs-ephemeral-state] notes, a data model MUST = indicate >>> whether the transport exchanging the data between I2RS client and >>> I2RS agent is secure or insecure. >>> >>> The default mode of transport is >>> secure so data models SHOULD clearly annotate what data nodes can = be >>> passed over an insecure connection. >>> >>>> Yours, >>>> Joel >>>> >>>> -----Original Message----- >>>> From: Susan Hares [mailto:shares@ndzh.com] >>>> Sent: Thursday, August 18, 2016 9:17 AM >>>> To: 'Juergen Schoenwaelder' >>>> Cc: i2rs@ietf.org; i2rs-chairs@ietf.org; 'Kathleen Moriarty' >>>> ; 'The IESG' ; >>>> jhaas@pfrc.org; >>>> 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) >>>> >>>> Juergen and Kathleen: >>>> >>>> Let me proceed with two examples: BGP route views data model and = the event for the web-service data. >>>> >>>> The content of these data models are designated as exposed to = public. The routing system only populates the proposed BGP route views = data model with the data destined for the BGP looking glass. The policy = on the routing system indicates what information gets transferred. The = data model is completely available to the public. The Yang Doctors are = going to review this by seeing the whole model is public and available = via non-secure means. >>>> The security people are going to review this seeing that the whole = model is public, and available via an unprotect means. The fact the = data model is all public should simplify the review. >>>> >>>> An event from the I2RS RIB that a web-service route is up is the = second case. The I2RS RIB has an event based on policy that indicates a = web-service route is up. The yang-1.1 doctors must review the content = of the event text to see it does not break privacy or provide too much >>>> information The event mechanisms will need to work over secure = transport >>>> and insecure transport. Most of the data will go over the secure = transport event stream. However, a small amount of information may go = over the insecure transport stream. >>>> >>>> First, let me know if my use cases are understandable. Second, let = me know if you disagree with this use cases. >>>> >>>> Fyi - IESG approved the architecture with the insecure stream. >>>> >>>> Sue >>>> >>>> -----Original Message----- >>>> From: Juergen Schoenwaelder >>>> [mailto:j.schoenwaelder@jacobs-university.de] >>>> Sent: Thursday, August 18, 2016 9:06 AM >>>> To: Susan Hares >>>> Cc: i2rs@ietf.org; i2rs-chairs@ietf.org; 'Kathleen Moriarty'; 'The >>>> IESG'; jhaas@pfrc.org; >>>> 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) >>>> >>>> I just do not know on which basis a data model writer can decide = whether a data object can be exposed in an unprotected way. How are YANG = doctors going to review this? How are security directorate people going = to judge this? But as promised, I leave (still puzzled) now. >>>> >>>> /js >>>> >>>> On Thu, Aug 18, 2016 at 09:00:14AM -0400, Susan Hares wrote: >>>>> Juergen: >>>>> >>>>> Yes, we seem to disagree on the value of making it hardwired in = the model. >>>>> For me, the value is a common understanding of deployment >>>>> distribution >>>> such >>>>> as the route-views. Since the operators argued strongly for this = point, >>>> I >>>>> think the best idea is to get it working in code and then see if >>>>> the deployment matches the requests. >>>>> >>>>> Sue >>>>> >>>>> -----Original Message----- >>>>> From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Juergen >>>>> Schoenwaelder >>>>> Sent: Thursday, August 18, 2016 8:14 AM >>>>> To: Susan Hares >>>>> Cc: i2rs@ietf.org; i2rs-chairs@ietf.org; 'Kathleen Moriarty'; 'The >>>>> IESG'; jhaas@pfrc.org; >>>>> 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) >>>>> >>>>> Sue, >>>>> >>>>> I still do not see why the 'mode of exposure' of data benefits = from >>>>> being hard-wired in the data model. For me, it is a situational = and >>>>> deployment specific question. But I shut up here since I aired = this >>>>> concern before (and we simply seem to disagree). >>>>> >>>>> /js >>>>> >>>>> On Thu, Aug 18, 2016 at 08:07:18AM -0400, Susan Hares wrote: >>>>>> Juergen: >>>>>> >>>>>> My example is the looking glass servers for the BGP route views >>>>>> project >>>>>> (http://www.routeviews.org/) or a route indicating the presence = of a >>>>>> web-server that is public. For the BGP I2RS route, a yang model = could >>>>>> replace the looking glass function, and provide events for these = looking >>>>>> glass functions. For the web-server route, an event be sent = when >>>> that >>>>>> one route is added. >>>>>> >>>>>> Sue >>>>>> >>>>>> >>>>>> -----Original Message----- >>>>>> From: Juergen Schoenwaelder >>>>>> [mailto:j.schoenwaelder@jacobs-university.de] >>>>>> Sent: Thursday, August 18, 2016 3:32 AM >>>>>> To: Susan Hares >>>>>> Cc: 'Kathleen Moriarty'; 'The IESG'; jhaas@pfrc.org; >>>>>> i2rs@ietf.org; i2rs-chairs@ietf.org; >>>>>> 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 Wed, Aug 17, 2016 at 09:16:48PM -0400, Susan Hares wrote: >>>>>>> = ----------------------------------------------------------------- >>>>>>> - >>>>>>> -- >>>>>>> -- >>>>>>> COMMENT: >>>>>>> = ----------------------------------------------------------------- >>>>>>> - >>>>>>> -- >>>>>>> -- >>>>>>> >>>>>>>> Section 3: >>>>>>>> Can you clarify the second to last sentence? Do you mean there >>>>>>>> are >>>>>> sections that indicate an insecure transport should be used? >>>>>>>> I2RS allows the use of an >>>>>>>> insecure transport for portions of data models that clearly >>>>>>>> indicate insecure transport. >>>>>>>> Perhaps: >>>>>>>> I2RS allows the use of an >>>>>>>> insecure transport for portions of data models that clearly >>>>>>>> indicate the use of an insecure transport. >>>>>> I still wonder how a data model writer can reasonably decide >>>>>> whether a piece of information can be shipped safely over an >>>>>> insecure transport since this decision often depends on the >>>>>> specifics of a deployment >>>>> situation. >>>>>> /js >>>>>> >>>>>> PS: I hope we do not end up with defining data multiple times = (once >>>>>> for insecure transport and once for secured transports). >>>>>> >>>>>> -- >>>>>> Juergen Schoenwaelder Jacobs University Bremen gGmbH >>>>>> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | = Germany >>>>>> Fax: +49 421 200 3103 = >>>>>> >>>>>> _______________________________________________ >>>>>> i2rs mailing list >>>>>> i2rs@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/i2rs >>>>> -- >>>>> Juergen Schoenwaelder Jacobs University Bremen gGmbH >>>>> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | = Germany >>>>> Fax: +49 421 200 3103 >>>>> >>>>> _______________________________________________ >>>>> i2rs mailing list >>>>> i2rs@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/i2rs >>>>> >>>> -- >>>> Juergen Schoenwaelder Jacobs University Bremen gGmbH >>>> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | = Germany >>>> Fax: +49 421 200 3103 >>>> > > > _______________________________________________ i2rs mailing list i2rs@ietf.org https://www.ietf.org/mailman/listinfo/i2rs =20 ------=_NextPart_000_0369_01D1FA08.BF638DB0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Andy:

 

Thank you for your comments.=C2=A0=C2=A0 Perhaps you can provide for = the IESG the list of things that are needed to move a Yang module = forward in the IETF.=C2=A0=C2=A0

 

Sue

 

From:= = Andy Bierman [mailto:andy@yumaworks.com]
Sent: Friday, August = 19, 2016 10:24 AM
To: Lou Berger
Cc: Susan Hares; = Juergen Schoenwaelder; 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)

 

Hi,

 

I = agree with Juergen.

There = are already too many details that need consensus to = move

a YANG module forward = in the IETF.  It takes too long = already.

 

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?

 

Standardized insecure access is a big change from what = we have done

for 30 = years.  There could be a good reason why we left this out of = scope

all this = time.

 

 

Andy

 

 

On Fri, = Aug 19, 2016 at 5:20 AM, Lou Berger <lberger@labn.net> wrote:


Sue,

My message said three = things:

1) Juergen's comment resonates with me.

2) I think = the current text is acceptable.

3) I see changing the SHOULD to a = MUST as problematic.
I understood one of the other messages on this = thread proposing this
change which is what triggered my = message.   If I misunderstood that
message, feel free to = interpret my message as supporting the current
text in = question.

Note that I am only speaking for myself (including in = my role as NETMOD
co-chair) and not representing the consensus = opinion of any WG.

Lou
On 8/19/2016 8:07 AM, Susan Hares = wrote:
> Lou:
>
> I am clear that Juergen does not = want not want to place transport requirements within the data model for = NETMOD.  His opinion was considered in the rough for the I2RS WG. = If this requirement is a problem for NETCONF/NETMOD,  the text = currently says:
>
> REQ-SEC-09 states:
>
>  =  The default mode of transport is secure so data models SHOULD = clearly annotate what data nodes can be
>    passed over = an insecure connection.
>
> However, if this means the = NETCONF/NETMOD WG will not even entertain proposal for marking the = insecure functions in yang text -- then the two WG (I2RS/NETMOD) have a = problem and should stop this standardization process going = forward.
>
> Sue
>
>
> -----Original = Message-----
> From: Lou Berger [mailto:lberger@labn.net]
> Sent: = Friday, August 19, 2016 7:34 AM
> To: Susan Hares; 'Juergen = Schoenwaelder'
> Cc: i2rs@ietf.org; 'Alissa Cooper'; i2rs-chairs@ietf.org; 'Kathleen = Moriarty'; 'IESG'; jhaas@pfrc.org; = 'Joel Halpern'; d= raft-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)
>
> Sue,
>
>     I don't = see Juergen as arguing against model access via non-secure transport. I = read his point as that the transport security requirements don't belong = scattered within a data model.
>
> I have to say that from a = model complexity (definition, process, review, implementation - take = your pick) , language and NETMOD co-chair perspective, his comment = resonates with me.
>
> I think this makes the key = text:
>
>    The default mode of transport = is
>    secure so data models SHOULD clearly annotate = what data nodes can be
>    passed over an insecure = connection.
>
>
> As this isn't a MUST, I personally = think we can live with the text and we can debate the issue further in = the context of specific solutions.  I would strongly object to this = being changed to a MUST, or if the document is changed to make transport = (security) requirements identified within data models a = requirement.
>
> Lou
>
> On 8/19/2016 6:49 AM, = Susan Hares wrote:
>> Juergen:
>>
>> You have = laid out the two options:   a) link the data-model to the = non-secure transport, and b) do not link the data to the non-secure = transport.   I agree with you that past models did not link = past SNMP MIB data model to the transport.  Existing NETCONF models = do not link it to the transport.   As you have indicated, you = disagreed in the I2RS WG and we found consensus was to include the = non-secure transport.
>>
>> I2RS was created to build = things as an interface to the routing environment.   The = operators clearly informed the I2RS group of this need during the = requirement setting phase prior to the time I was chair.  The = reason I continue to press for this capability is their input, and the = existing use cases I listed previously in this = mail:
>>
>> a) public information - BGP route = views,
>> b) specific well know up events - such as public-web = site up
>> c) specific network service events - interface to = particular public LAN up.
>>
>> As you know, we do not = have any I2RS data models that specify this feature at this time.  =  I suspect after we get through this lengthy requirement phase, the = operators may begin to specify new models that have this = feature.
>>
>> Sue
>>
>> = -----Original Message-----
>> From: Juergen = Schoenwaelder
>> [mailto:j.schoenwaelder@jaco= bs-university.de]
>> Sent: Friday, August 19, 2016 4:58 = AM
>> To: Susan Hares
>> Cc: 'Alissa Cooper'; 'Joel = Halpern'; i2rs@ietf.org;
>> i2rs-chairs@ietf.org; 'Kathleen = Moriarty'; 'IESG'; jhaas@pfrc.org;
>> d= raft-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)
>>
>> I repeat my technical = argument: While there may be deployments where non-secure transports may = be reasonable to use, defining these situations statically as part of = data model schemas does not follow established practices. The IETF has a = long tradition of standardizing data models that can be used in a = variety of operational contexts and I do not see reasons why we should = move away from that basic approach.
>>
>> = /js
>>
>> On Thu, Aug 18, 2016 at 02:35:03PM -0400, = Susan Hares wrote:
>>> = Alissa:
>>>
>>> Just a little input you may not = know.  My background is 15 years (1995-2010)  developing a = routing/switching platform (denoted as GateD) which was sold to over 200 = companies.   We developed XML and a binary XML based product = that configured this product.  It could do 100K configuration lines = and reboot in less than a second on most hardware.  We also provide = status messages in secure streams and non-secure streams.    I = sold early version of this code to companies that Alia has worked = for  - so she has personal viewed the code.   At the = height of our work, our development team ran to 50 people which I = directed (First as VP of Engineering, and then as CTO). It is due to = this level of experience that Alia selected me for the co-chair.  =  Russ White has understood Cisco's process, and has also directed = software development teams for routing.
>>>
>>> = In order to freshen my direct experience with I2RS on open source work, = I am working on a publically available work in Quagga based on the confD = product suggested by Cisco.
>>>
>>> In contrast, = Juergen is a university professor who has worked on proto-types.  =  He is not working on an implementation.   I hope he = will.
>>>
>>> I hope you will consider this = background in my response to your comments = below.
>>>
>>> = Sue
>>>
>>>
>>> -----Original = Message-----
>>> From: Alissa Cooper [mailto:alissa@cooperw.in]
>>> = Sent: Thursday, August 18, 2016 12:54 PM
>>> To: Joel = Halpern
>>> Cc: Susan Hares; Juergen Schoenwaelder; i2rs@ietf.org;
>>> i2rs-chairs@ietf.org; Kathleen = Moriarty; IESG; jhaas@pfrc.org;
>>> d= raft-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)
>>>
>>> Jumping in = here because this is relevant to my DISCUSS, hope nobody minds (but if = you do, I can go back to the other = thread).
>>>
>>>>> On Aug 18, 2016, at = 10:30 AM, Joel Halpern <joel.halpern@ericsson.com&g= t; wrote:
>>>>>
>>>>> Let me try a = different take approach to this particular = question.
>>>>>
>>>>> Let me start = by putting aside the question of where things are marked, and come back = to that afterwards.
>>>>>
>>>>> = There are a number of cases that I2RS has been asked to cover of high = rate telemetry data.  This may be BGP update information, it may be = frequent information about line card activity.  There are other = cases, some of which have been = documented.
>>>>>
>>>>> While not = completely insensitive, the operators have made clear that they see = protecting this data as unnecessary.  While I would hope over time = to move to a domain where all of it is protect, that is not = trivial.  As the I2RS Architecture points out, it is expected that = what we describe as a single I2RS >communication between a client and = agent is actually associated with multiple channels of = communication.
>>>>>
>>>>> Now, if = you want to say that the I2RS protocol requirements cannot allow for = unprotected channels, I guess we have disconnect between the IESG and = the WG.
>>>>>
>>>>> If we say that = we can allow for unprotected channels, we then get to the question of = which data can be sent over such channels.  While architecturally I = agree with Juergen that the model is a bad place to specify it, the = obverse is also true.  Not having some limits on what can be sent = unprotected >causes concern about insufficient protection.  If I = recall correctly, earlier security reviews called us to task for being = too broad in what we = allowed.
>>>>>
>>>>> So, if the IESG = wants us to just allow it anywhere, because the
>>>>> = model is an awkward place to define the limitation, I can live with = that.  What I can't live with is being told both that the model is = a bad place to define it and that there must be restrictions on what is = sent unprotected, without any proposal on how we are to move = forward.
>>>> Thank you Joel, this explanation helps me a = lot. I think there is a disconnect about how the restrictions are = expressed. From reading the email traffic about this document, it = strikes me that trying to express the restrictions programmatically = doesn=E2=80=99t make much sense in this case.
>>>> I = agree with Juergen that it will be challenging to make a judgment a = priori in order to bake a restriction into a data model, because data = that is considered sensitive enough to warrant a secure transport in one = deployment may not be considered sensitive in another = deployment.
>>>> So for any data elements where there is = any question at all about
>>>> whether they might be = sensitive (i.e., any data elements that are not already routinely made = public), I would expect data model authors to end up indicating that = they may be sent over either secure or insecure transport, which renders = the indication not useful.
>>>> Perhaps it would make = more sense then to just enumerate in the text the cases that motivate = the inclusion of protocol support for insecure = transport:
>>>>
>>>> 1. For conveyance of = information that is already routinely made public.
>>>> = 2. For line card activity data where there is no likely upgrade path to = support secure transports in the foreseeable = future.
>>>>
>>>> Then the normative = requirements would be on clients and agents to use secure transports = unless those clients and agents are deployed where either of the = operational circumstances above necessitate = otherwise.
>>>> Alissa
>>> Point = 1:
>>> I disagree with Juergen on the difficulty in = specifying the sections of the yang modules.  I have provided a = suggested solution in:
>>> https://tools.ietf.org/html/draft-hares-i2rs-protocol-s= trawman-03#section-4.5.2.
>>>
>>> Given the = mount schema functionality, we can mount ephemeral state module which = augment non-ephemeral state modules which are "in-secure = only".
>>>
>>> Point 2:
>>> I = am willing to put an enumeration of the use cases in the protocol = requirement, but I would like to understand the purpose for the = enumeration.   We are not doing a use case, but a requirements = document.  This information appears to be a "use case" = rather than a technical description.   What purpose are you = looking for this enumeration to server.  Are you looking for the = enumeration in SEC-REQ-08?
>>>
>>> Point 3: = Could you review -08.txt on this topic, especially the text below.  = Given your comments, I believe I should change the last line to a = MUST.
>>> New/   The default mode of transport = is
>>>    secure so data models MUST clearly = annotate what data nodes can be
>>>    passed over = an insecure connection.
>>> = /
>>>
>>> Sue
>>>
>>> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>>>= As to the normative requirements (-08.txt) = version:
>>>
>>> Section = 3:
>>>
>>>    I2RS allows the use of = an insecure transport for portions of data
>>>    = models that clearly indicate the use of an insecure = transport.
>>>    Operators deploying I2RS must = determine if they want to populate and
>>>    = deploy the portions of the data model which use insecure = transports.
>>>
>>> In Section 3.2 in version = -08.txt
>>>
>>>    SEC-REQ-08: The = I2RS protocol MUST be able to transfer data over a
>>>  =   secure transport and optionally MAY be able to transfer data over = a
>>>    non-secure transport.  A secure = transport MUST provide data
>>>    = confidentiality, data integrity, and replay = prevention.
>>>
>>>    The default = I2RS transport is a secure = transport.
>>>
>>>    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.
>>>
>>>    The configuration = of ephemeral data in the I2RS Agent by the I2RS
>>>  =   client SHOULD be done over a secure transport.  It is = anticipated
>>>    that the passing of most I2RS = ephemeral state operational status
>>>    SHOULD = be done over a secure transport.  As
>>>    = [I-D.ietf-i2rs-ephemeral-state] notes,  a data model MUST = indicate
>>>    whether the transport exchanging = the data between I2RS client and
>>>    I2RS agent = is secure or insecure.
>>>
>>>    The = default mode of transport is
>>>    secure so data = models SHOULD clearly annotate what data nodes can = be
>>>    passed over an insecure = connection.
>>>
>>>> = Yours,
>>>> Joel
>>>>
>>>> = -----Original Message-----
>>>> From: Susan Hares = [mailto:shares@ndzh.com]
>>>> = Sent: Thursday, August 18, 2016 9:17 AM
>>>> To: 'Juergen = Schoenwaelder' <j.schoenwaelder@jaco= bs-university.de>
>>>> Cc: i2rs@ietf.org; i2rs-chairs@ietf.org; 'Kathleen = Moriarty'
>>>> <Kathleen.Moriarty.ietf@g= mail.com>; 'The IESG' <iesg@ietf.org>;
>>>> = jhaas@pfrc.org;
>>>> = d= raft-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)
>>>>
>>>> = Juergen and Kathleen:
>>>>
>>>> Let me = proceed with two examples: BGP route views data model and the event for = the web-service data.
>>>>
>>>> The = content of these data models are designated as exposed to public.  = The routing system only populates the proposed BGP route views data = model with the data destined for the BGP looking glass.  The policy = on the routing system indicates what information gets transferred.  = The data model is completely available to the public.  The Yang = Doctors are going to review this by seeing the whole model is public and = available via non-secure means.
>>>> The security people = are going to review this seeing that the whole model is public, and = available via an unprotect means.  The fact the data model is all = public should simplify the = review.
>>>>
>>>> An event from the I2RS = RIB that a web-service route is up is the second case.  The I2RS = RIB has an event based on policy that indicates a web-service route is = up.  The yang-1.1 doctors must review the content of the event text = to see it does not break privacy or provide too much
>>>> = information   The event mechanisms will need to work over = secure transport
>>>> and insecure transport.  Most = of the data will go over the secure transport event stream. However, a = small amount of information may go over the insecure transport = stream.
>>>>
>>>> First, let me know if my = use cases are understandable.  Second, let me know if you disagree = with this use cases.
>>>>
>>>> Fyi -  = IESG approved the architecture with the insecure = stream.
>>>>
>>>> = Sue
>>>>
>>>> -----Original = Message-----
>>>> From: Juergen = Schoenwaelder
>>>> [mailto:j.schoenwaelder@jaco= bs-university.de]
>>>> Sent: Thursday, August 18, = 2016 9:06 AM
>>>> To: Susan Hares
>>>> Cc: = i2rs@ietf.org; i2rs-chairs@ietf.org; 'Kathleen = Moriarty'; 'The
>>>> IESG'; jhaas@pfrc.org;
>>>> = d= raft-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)
>>>>
>>>> = I just do not know on which basis a data model writer can decide whether = a data object can be exposed in an unprotected way. How are YANG doctors = going to review this? How are security directorate people going to judge = this? But as promised, I leave (still puzzled) = now.
>>>>
>>>> = /js
>>>>
>>>> On Thu, Aug 18, 2016 at = 09:00:14AM -0400, Susan Hares wrote:
>>>>> = Juergen:
>>>>>
>>>>> Yes, we seem to = disagree on the value of making it hardwired in the = model.
>>>>> For me, the value is a common = understanding of deployment
>>>>> = distribution
>>>> such
>>>>> as the = route-views.   Since the operators argued strongly for this = point,
>>>> I
>>>>> think the best idea = is to get it working in code and then see if
>>>>> the = deployment matches the = requests.
>>>>>
>>>>> = Sue
>>>>>
>>>>> -----Original = Message-----
>>>>> From: i2rs [mailto:i2rs-bounces@ietf.org] On = Behalf Of Juergen
>>>>> = Schoenwaelder
>>>>> Sent: Thursday, August 18, 2016 = 8:14 AM
>>>>> To: Susan Hares
>>>>> = Cc: i2rs@ietf.org; i2rs-chairs@ietf.org; 'Kathleen = Moriarty'; 'The
>>>>> IESG'; jhaas@pfrc.org;
>>>>>= ; d= raft-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)
>>>>>
>>>>> = Sue,
>>>>>
>>>>> I still do not see = why the 'mode of exposure' of data benefits from
>>>>> = being hard-wired in the data model. For me, it is a situational = and
>>>>> deployment specific question. But I shut up = here since I aired this
>>>>> concern before (and we = simply seem to = disagree).
>>>>>
>>>>> = /js
>>>>>
>>>>> On Thu, Aug 18, 2016 = at 08:07:18AM -0400, Susan Hares wrote:
>>>>>> = Juergen:
>>>>>>
>>>>>> My = example is the looking glass servers for the BGP route = views
>>>>>> project
>>>>>> = (http://www.routeviews.org/) or a route indicating = the presence of a
>>>>>> web-server that is = public.   For the BGP I2RS route, a yang model = could
>>>>>> replace the looking glass function, = and provide events for these looking
>>>>>> glass = functions.    For the web-server route,  an event be sent = when
>>>> that
>>>>>> one route is = added.
>>>>>>
>>>>>> = Sue
>>>>>>
>>>>>>
>>&g= t;>>> -----Original Message-----
>>>>>> = From: Juergen Schoenwaelder
>>>>>> [mailto:j.schoenwaelder@jaco= bs-university.de]
>>>>>> Sent: Thursday, August = 18, 2016 3:32 AM
>>>>>> To: Susan = Hares
>>>>>> Cc: 'Kathleen Moriarty'; 'The IESG'; = jhaas@pfrc.org;
>>>>>= ;> i2rs@ietf.org; i2rs-chairs@ietf.org;
>>= ;>>>> d= raft-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 Wed, = Aug 17, 2016 at 09:16:48PM -0400, Susan Hares = wrote:
>>>>>>> = -----------------------------------------------------------------
>= >>>>>> -
>>>>>>> = --
>>>>>>> --
>>>>>>> = COMMENT:
>>>>>>> = -----------------------------------------------------------------
>= >>>>>> -
>>>>>>> = --
>>>>>>> = --
>>>>>>>
>>>>>>>> = Section 3:
>>>>>>>> Can you clarify the = second to last sentence?  Do you mean = there
>>>>>>>> = are
>>>>>> sections that indicate an insecure = transport should be used?
>>>>>>>>  I2RS = allows the use of an
>>>>>>>> insecure = transport for portions of data models that = clearly
>>>>>>>> indicate  insecure = transport.
>>>>>>>> = Perhaps:
>>>>>>>> I2RS allows the use of = an
>>>>>>>> insecure transport for portions = of data models that clearly
>>>>>>>> indicate = the use of an  insecure transport.
>>>>>> I = still wonder how a data model writer can reasonably = decide
>>>>>> whether a piece of information can be = shipped safely over an
>>>>>> insecure transport = since this decision often depends on the
>>>>>> = specifics of a deployment
>>>>> = situation.
>>>>>> = /js
>>>>>>
>>>>>> PS: I hope = we do not end up with defining data multiple times = (once
>>>>>>    for insecure transport = and once for secured = transports).
>>>>>>
>>>>>> = --
>>>>>> 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/>
>>>= ;>>>
>>>>>> = _______________________________________________
>>>>>&g= t; i2rs mailing list
>>>>>> i2rs@ietf.org
>>>>>&g= t; https://www.ietf.org/mailman/listinfo/i2rs
>&= gt;>>> --
>>>>> 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/>
>>>= ;>>
>>>>> = _______________________________________________
>>>>> = i2rs mailing list
>>>>> i2rs@ietf.org
>>>>> = https://www.ietf.org/mailman/listinfo/i2rs
>&= gt;>>>
>>>> --
>>>> 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/>
>>>= ;>
>
>
>


________________________________= _______________
i2rs mailing list
i2rs@ietf.org
https://www.ietf.org/mailman/listinfo/i2rs

 

------=_NextPart_000_0369_01D1FA08.BF638DB0-- From nobody Fri Aug 19 08:28:11 2016 Return-Path: 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 904FA12B04B; Fri, 19 Aug 2016 08:03:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.739 X-Spam-Level: * X-Spam-Status: No, score=1.739 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, RDNS_NONE=0.793] autolearn=no 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 JWA4CLQUHW2P; Fri, 19 Aug 2016 08:03:38 -0700 (PDT) Received: from hickoryhill-consulting.com (unknown [50.245.122.97]) (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 6A86012D5CB; Fri, 19 Aug 2016 08:03:27 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=184.157.82.170; From: "Susan Hares" To: "'Spencer Dawkins at IETF'" References: <147146974235.23784.4389421535496134619.idtracker@ietfa.amsl.com> <013b01d1f8ee$31fa09b0$95ee1d10$@ndzh.com> <20160818073203.GA4338@elstar.local> <04b501d1f949$116c63e0$34452ba0$@ndzh.com> <20160818121405.GA5282@elstar.local> <051301d1f950$7739c670$65ad5350$@ndzh.com> <20160818130555.GA5366@elstar.local> <051701d1f952$c4ae0b30$4e0a2190$@ndzh.com> <6BCE198E4EAEFC4CAB45D75826EFB0761525CCD7@eusaamb101.ericsson.se> <003801d1f97f$3d16eb10$b744c130$@ndzh.com> <00dc01d1f988$f2cec280$d86c4780$@ndzh.com> <02b201d1fa1c$620e07d0$262a1770$@ndzh.com> In-Reply-To: Date: Fri, 19 Aug 2016 11:02:10 -0400 Message-ID: <037501d1fa2a$a970fde0$fc52f9a0$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0376_01D1FA09.22626B20" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIa7Lz6VgZw6h2A0uGNzOgAA2Ic8QJ/RF5yARxv/coCD6d0AAIDKkFTAYlI9/gCaK/wXAMksAaNAmoTFCQCp9Oi8AIQlOgDAIZjbI0CaGRfrQGPw5JeAjmooLUBU45vXAKYJpUpnroeyiA= Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: X-Mailman-Approved-At: Fri, 19 Aug 2016 08:28:08 -0700 Cc: i2rs@ietf.org, 'Alissa Cooper' , 'Juergen Schoenwaelder' , 'Andy Bierman' , 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) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Aug 2016 15:03:40 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0376_01D1FA09.22626B20 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Spencer:=20 =20 Thank you for asking. The time it would take is the time to move the = configuration knob to =E2=80=9Calways transport-secure=E2=80=9D for this = model.=20 =20 Sue=20 =20 From: Spencer Dawkins at IETF [mailto:spencerdawkins.ietf@gmail.com]=20 Sent: Friday, August 19, 2016 10:13 AM To: Susan Hares Cc: Andy Bierman; i2rs@ietf.org; Alissa Cooper; Juergen Schoenwaelder; = 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) =20 Hi, Susan, =20 On Fri, Aug 19, 2016 at 8:19 AM, Susan Hares wrote: Spencer:=20 =20 You as asking if: =20 1) Can Yang Models be revised? - there is a revision tag on the = Yang model.=20 2) How long it takes to deploy revised models in the Internet, and = old-models to be timed out? This is an operational question on yang = models that no one has experience to determine. Andy suggest that the = deployment time is 20 years (the Age of the Commercial internet = =E2=80=93 1996 -2016) rather than the age of the Internet (1987-2016). =20 =20 However, the real question you should have asked is: Can operators = deploy models which are marked as =E2=80=9Cnon-secure transport=E2=80=9D = with a secure transport?=20 =20 I understood that part. My question was how long it would likely take = them to switch to a secure transport if they had deployed a model with = an insecure transport and figured out that was problematic. =20 Thanks for the explanation. It was helpful. =20 Spencer =20 The answer is yes. In fact, several operators in I2RS stated that all = I2RS protocol communication needed to be secure. Therefore, if the = people found out that a model was problematic to be insecure =E2=80=93 = operators and vendors would simply turn the deployment knob switch that = says =E2=80=93 deploy this always with a secure transport rather than = optionally allow an insecure transport. =20 =20 Now, the real problem is if the IESG has been cycling on this concept = =E2=80=93 the text needs to change. I=E2=80=99m going to go ahead and = release a version-09.txt that tries to make this very clear. Please = comment on that text to help make this clear.=20 =20 Sue=20 =20 =20 From: Spencer Dawkins at IETF [mailto:spencerdawkins.ietf@gmail.com]=20 Sent: Friday, August 19, 2016 9:08 AM To: Andy Bierman Cc: Susan Hares; i2rs@ietf.org; Alissa Cooper; Juergen Schoenwaelder; = 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) =20 Dear All, =20 On Thu, Aug 18, 2016 at 3:02 PM, Andy Bierman = wrote: =20 =20 On Thu, Aug 18, 2016 at 12:44 PM, Susan Hares wrote: Andy: =20 Thank you =E2=80=93 I thought it was on whether we could implement = insecure transport in a Yang module.=20 =20 The requirement text you are working with is: =20 SEC-REQ-08: The I2RS protocol MUST be able to transfer data over a secure transport and optionally MAY be able to transfer data over a non-secure transport. =20 I do not understand why approving the ok for non-secure transport for = some modules means the following to you:=20 =20 =E2=80=9C the IETF needs to agree that there could never possibly be any = deployment that would not want to allow exposure of the data. Not now. Not 20 years from now.=E2=80=9D =20 =20 =20 As I understand it, this requirement has another requirement associated = with it that says the data has to be identified as OK-for-nonsecure-transport. =20 An extension in the data model says that all instances of the object in all possible deployments cannot be considered sensistive and therefore needs disclosure protection. =20 It may seem like even a simple octet counter is safe to send in the = clear, but not if that opens up correlation attacks. (e.g., I can send data to = some host. I can see that index 455992 is incrementing the in-octets = counters in a way that strongly correlates to my test traffic. Therefore I can = learn that arbitrary index 455992 is really John Doe or really suite #14, etc. =20 Since Kathleen asked what other ADs were thinking ... =20 I'm current on this thread, as of the time I'm sending my note, but = replying to Andy's note because it's poking where I am poking. =20 So, if (say) an octet counter is considered safe to send in the clear, = and a Yang model that reflects that is approved and widely deployed, and = then someone realizes that it's not safe to send in the clear, is that a = big deal to fix, and get the updated Yang model widely deployed?=20 =20 My opinion on this point has a lot to do with how hard it is to recover = if a Yang model gets this wrong ... =20 My apologies for not understanding enough about Yang and I2RS to be able = to answer my own question, of course. =20 Thanks, =20 Spencer=20 =20 ------=_NextPart_000_0376_01D1FA09.22626B20 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Spencer:

 

Thank you for asking.=C2=A0 The time it would take is the time to = move the configuration knob to =E2=80=9Calways transport-secure=E2=80=9D = for this model.

 

Sue

 

From:= = Spencer Dawkins at IETF [mailto:spencerdawkins.ietf@gmail.com] =
Sent: Friday, August 19, 2016 10:13 AM
To: Susan = Hares
Cc: Andy Bierman; i2rs@ietf.org; Alissa Cooper; Juergen = Schoenwaelder; 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)

 

Hi, = Susan,

 

On Fri, = Aug 19, 2016 at 8:19 AM, Susan Hares <shares@ndzh.com> wrote:

Spencer:

 

You as asking if:

 

1)      = Can Yang Models be revised?  - there is a revision tag on the = Yang model.

2)      = How long it takes to deploy revised models in the Internet, and = old-models to be timed out?  This is an operational question on = yang models that no one has experience to determine.   Andy = suggest that the deployment time is 20 years (the Age of the Commercial = internet =E2=80=93 1996 -2016) rather than the age of the Internet = (1987-2016). 

 

However, the real question you should have asked is: Can operators = deploy models which are marked as =E2=80=9Cnon-secure transport=E2=80=9D = with a  secure transport? 

 

I = understood that part. My question was how long it would likely take them = to switch to a secure transport if they had deployed a model with an = insecure transport and figured out that was = problematic.

 

Thanks for the explanation. It was = helpful.

 

Spencer

 

The answer is yes.  In fact, several operators in I2RS stated = that all I2RS protocol communication needed to be secure. =    Therefore, if the people found out that a model was = problematic to be insecure =E2=80=93 operators and vendors would simply = turn the deployment knob switch that says =E2=80=93 deploy this always = with a secure transport rather than optionally allow an insecure = transport.    

 

Now, the real problem is if the IESG has been cycling on this concept = =E2=80=93 the text needs to change.   I=E2=80=99m going to go = ahead and release a version-09.txt that tries to make this very = clear.   Please comment on that text to help make this clear. =

 

Sue

 

 

From:= = Spencer Dawkins at IETF [mailto:spencerdawkins.ietf@gmail.com]
Sent: = Friday, August 19, 2016 9:08 AM
To: Andy Bierman
Cc: = Susan Hares; i2rs@ietf.org; Alissa Cooper; Juergen = Schoenwaelder; 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)

 <= /o:p>

Dear = All,

 <= /o:p>

On Thu, Aug = 18, 2016 at 3:02 PM, Andy Bierman <andy@yumaworks.com> = wrote:

 <= /o:p>

 <= /o:p>

On Thu, Aug = 18, 2016 at 12:44 PM, Susan Hares <shares@ndzh.com> = wrote:

Andy:

 

Thank you = =E2=80=93 I thought it was on whether we could implement insecure = transport in a Yang module.

 

The = requirement text you are working with is:

 

  =  SEC-REQ-08: The I2RS protocol MUST be able to transfer data over = a
   secure transport and optionally MAY be able to = transfer data over a
   non-secure = transport.

 

I do not = understand why approving the ok for non-secure transport for some = modules means the following to you:

 

=E2= =80=9C the IETF needs to agree that there could never possibly be any = deployment that would not want to allow exposure of the = data.

N= ot now. Not 20 years from now.=E2=80=9D

 

 <= /o:p>

 <= /o:p>

As I = understand it, this requirement has another requirement associated with = it

that says = the data has to be identified as = OK-for-nonsecure-transport.

 <= /o:p>

An = extension in the data model says that all instances of the object = in

all = possible deployments cannot be considered sensistive and = therefore

needs = disclosure protection.

 <= /o:p>

It may seem = like even a simple octet counter is safe to send in the = clear,

but not if = that opens up correlation attacks.  (e.g., I can send data to = some

host.  = I can see that index 455992 is incrementing the in-octets = counters

in a way = that strongly correlates to my test traffic.  Therefore I can = learn

that = arbitrary index 455992 is really John Doe or really suite #14, = etc.

 <= /o:p>

Since = Kathleen asked what other ADs were thinking = ...

 <= /o:p>

I'm current = on this thread, as of the time I'm sending my note, but replying to = Andy's note because it's poking where I am = poking.

 <= /o:p>

So, if = (say) an octet counter is considered safe to send in the clear, and a = Yang model that reflects that is approved and widely deployed, and then = someone realizes that it's not safe to send in the clear, is that a big = deal to fix, and get the updated Yang model widely = deployed? 

 <= /o:p>

My opinion = on this point has a lot to do with how hard it is to recover if a Yang = model gets this wrong ...

 <= /o:p>

My = apologies for not understanding enough about Yang and I2RS to be able to = answer my own question, of course.

 <= /o:p>

Thanks,=

 <= /o:p>

Spencer = ;

 

------=_NextPart_000_0376_01D1FA09.22626B20-- From nobody Fri Aug 19 08:28:14 2016 Return-Path: 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 2E37712DB8D; Fri, 19 Aug 2016 08:26:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1 X-Spam-Level: X-Spam-Status: No, score=-1 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, FREEMAIL_REPLY=1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no 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 t5g34AvaK3IT; Fri, 19 Aug 2016 08:26:45 -0700 (PDT) Received: from mail-ua0-x22d.google.com (mail-ua0-x22d.google.com [IPv6:2607:f8b0:400c:c08::22d]) (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 5301A12DB66; Fri, 19 Aug 2016 08:26:45 -0700 (PDT) Received: by mail-ua0-x22d.google.com with SMTP id 74so85792749uau.0; Fri, 19 Aug 2016 08:26:45 -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=W2auIdJjFacNVrIhJbPMbhI5PnivPdCTw8tDm8dXVjw=; b=mp/pJ0aUuaG5/XKTdAAn7ZUk4iFT6PedcUzmVy/13+yBR3RzXa+lnq57l81l0ddh9d eYKQZCdhDFaaOEJRxNUT5pwrtpi/+0nOuC5j0Vg7bkomZfKAezy+LZL7NVczKfBjX4dT dsDo2b+XEZpvcwKRarbUQLvp1PHmdzU0tTzazjxdAjQJDROqcJ27Qpupx9eF/9GyvNUl SjXwbXjmz0EhpVX2KrsoFup8kbqhNb20puGoxSK+A5LGYQXI1+chORqeyHBkiQ5Dqzq8 6J+MqZMoyZo8iZn66yL3S2kDo3ozot/Xqdt1ogrhpcbT2cerISUV/yXDdMPTjnZTISYp St6g== 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=W2auIdJjFacNVrIhJbPMbhI5PnivPdCTw8tDm8dXVjw=; b=O8OglsaigQJa4e/AU5Sq9OiyqGrrGEDZoH0A/hPeJeqxSk8jj72t2ktGDpKxqc76oM +x4ABiH+eAw7kUkH4buSoOK6rgl6rd0wrdXBUILW6Tc4KVDOjsTmYllBVYLtM6rQlLMW 0uMyRVwo3z8pq78PWN5znqD3Cf0rbFFMl8RkFrOcTsZgso04PvtgShCMgajcKRP0To5d PXbaCbC5Lx94svzsIkzmpkibeIZJoxUfEvCfQSa1qpdz0+cH5Fj1dXEbqh3DlnNM5m51 kKERiipeVb4rT3DqXLXLjOPIPOSLmApEYcjZGCagON0SSDOrPgVX5rCwwecJug+Jize9 aUlg== X-Gm-Message-State: AEkooutBvbGF7CTf/k+vvM1la0wFloioUx4j4hRW/FDjDh4DU1XYpNhaCsvKSSYh92SrbjnN+QQ5BAWqiE7Vpw== X-Received: by 10.31.174.141 with SMTP id x135mr4294328vke.25.1471620404310; Fri, 19 Aug 2016 08:26:44 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.1.228 with HTTP; Fri, 19 Aug 2016 08:26:43 -0700 (PDT) In-Reply-To: <037501d1fa2a$a970fde0$fc52f9a0$@ndzh.com> References: <147146974235.23784.4389421535496134619.idtracker@ietfa.amsl.com> <013b01d1f8ee$31fa09b0$95ee1d10$@ndzh.com> <20160818073203.GA4338@elstar.local> <04b501d1f949$116c63e0$34452ba0$@ndzh.com> <20160818121405.GA5282@elstar.local> <051301d1f950$7739c670$65ad5350$@ndzh.com> <20160818130555.GA5366@elstar.local> <051701d1f952$c4ae0b30$4e0a2190$@ndzh.com> <6BCE198E4EAEFC4CAB45D75826EFB0761525CCD7@eusaamb101.ericsson.se> <003801d1f97f$3d16eb10$b744c130$@ndzh.com> <00dc01d1f988$f2cec280$d86c4780$@ndzh.com> <02b201d1fa1c$620e07d0$262a1770$@ndzh.com> <037501d1fa2a$a970fde0$fc52f9a0$@ndzh.com> From: Kathleen Moriarty Date: Fri, 19 Aug 2016 11:26:43 -0400 Message-ID: To: Susan Hares Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: X-Mailman-Approved-At: Fri, 19 Aug 2016 08:28:07 -0700 Cc: i2rs@ietf.org, Alissa Cooper , Juergen Schoenwaelder , i2rs-chairs@ietf.org, Andy Bierman , Spencer Dawkins at IETF , Jeffrey Haas , Joel Halpern , draft-ietf-i2rs-protocol-security-requirements@ietf.org, IESG 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Aug 2016 15:26:47 -0000 On Fri, Aug 19, 2016 at 11:02 AM, Susan Hares wrote: > Spencer: > > > > Thank you for asking. The time it would take is the time to move the > configuration knob to =E2=80=9Calways transport-secure=E2=80=9D for this = model. Why does the knob in the data model have to be set only one way? Couldn't an attribute be used that you could change the setting for that attribute rather than update the entire YANG module or is that not possible in YANG? Couldn't this be a setting? Thanks, Kathleen > > > > Sue > > > > From: Spencer Dawkins at IETF [mailto:spencerdawkins.ietf@gmail.com] > Sent: Friday, August 19, 2016 10:13 AM > To: Susan Hares > Cc: Andy Bierman; i2rs@ietf.org; Alissa Cooper; Juergen Schoenwaelder; > 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) > > > > Hi, Susan, > > > > On Fri, Aug 19, 2016 at 8:19 AM, Susan Hares wrote: > > Spencer: > > > > You as asking if: > > > > 1) Can Yang Models be revised? - there is a revision tag on the Yan= g > model. > > 2) How long it takes to deploy revised models in the Internet, and > old-models to be timed out? This is an operational question on yang mode= ls > that no one has experience to determine. Andy suggest that the deployme= nt > time is 20 years (the Age of the Commercial internet =E2=80=93 1996 -2016= ) rather > than the age of the Internet (1987-2016). > > > > However, the real question you should have asked is: Can operators deploy > models which are marked as =E2=80=9Cnon-secure transport=E2=80=9D with a = secure transport? > > > > I understood that part. My question was how long it would likely take the= m > to switch to a secure transport if they had deployed a model with an > insecure transport and figured out that was problematic. > > > > Thanks for the explanation. It was helpful. > > > > Spencer > > > > The answer is yes. In fact, several operators in I2RS stated that all I2= RS > protocol communication needed to be secure. Therefore, if the people > found out that a model was problematic to be insecure =E2=80=93 operators= and > vendors would simply turn the deployment knob switch that says =E2=80=93 = deploy this > always with a secure transport rather than optionally allow an insecure > transport. > > > > Now, the real problem is if the IESG has been cycling on this concept =E2= =80=93 the > text needs to change. I=E2=80=99m going to go ahead and release a versi= on-09.txt > that tries to make this very clear. Please comment on that text to help > make this clear. > > > > Sue > > > > > > From: Spencer Dawkins at IETF [mailto:spencerdawkins.ietf@gmail.com] > Sent: Friday, August 19, 2016 9:08 AM > To: Andy Bierman > Cc: Susan Hares; i2rs@ietf.org; Alissa Cooper; Juergen Schoenwaelder; > 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) > > > > Dear All, > > > > On Thu, Aug 18, 2016 at 3:02 PM, Andy Bierman wrote: > > > > > > On Thu, Aug 18, 2016 at 12:44 PM, Susan Hares wrote: > > Andy: > > > > Thank you =E2=80=93 I thought it was on whether we could implement insecu= re > transport in a Yang module. > > > > The requirement text you are working with is: > > > > SEC-REQ-08: The I2RS protocol MUST be able to transfer data over a > secure transport and optionally MAY be able to transfer data over a > non-secure transport. > > > > I do not understand why approving the ok for non-secure transport for som= e > modules means the following to you: > > > > =E2=80=9C the IETF needs to agree that there could never possibly be any = deployment > that would not want to allow exposure of the data. > > Not now. Not 20 years from now.=E2=80=9D > > > > > > > > As I understand it, this requirement has another requirement associated w= ith > it > > that says the data has to be identified as OK-for-nonsecure-transport. > > > > An extension in the data model says that all instances of the object in > > all possible deployments cannot be considered sensistive and therefore > > needs disclosure protection. > > > > It may seem like even a simple octet counter is safe to send in the clear= , > > but not if that opens up correlation attacks. (e.g., I can send data to > some > > host. I can see that index 455992 is incrementing the in-octets counters > > in a way that strongly correlates to my test traffic. Therefore I can le= arn > > that arbitrary index 455992 is really John Doe or really suite #14, etc. > > > > Since Kathleen asked what other ADs were thinking ... > > > > I'm current on this thread, as of the time I'm sending my note, but reply= ing > to Andy's note because it's poking where I am poking. > > > > So, if (say) an octet counter is considered safe to send in the clear, an= d a > Yang model that reflects that is approved and widely deployed, and then > someone realizes that it's not safe to send in the clear, is that a big d= eal > to fix, and get the updated Yang model widely deployed? > > > > My opinion on this point has a lot to do with how hard it is to recover i= f a > Yang model gets this wrong ... > > > > My apologies for not understanding enough about Yang and I2RS to be able = to > answer my own question, of course. > > > > Thanks, > > > > Spencer > > --=20 Best regards, Kathleen From nobody Fri Aug 19 09:02:31 2016 Return-Path: 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 5526212DB93 for ; Fri, 19 Aug 2016 08:43:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.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 k94D6Se6WGcj for ; Fri, 19 Aug 2016 08:43:35 -0700 (PDT) Received: from mail-ua0-x22b.google.com (mail-ua0-x22b.google.com [IPv6:2607:f8b0:400c:c08::22b]) (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 3E4FF12DB89 for ; Fri, 19 Aug 2016 08:43:24 -0700 (PDT) Received: by mail-ua0-x22b.google.com with SMTP id n59so86400129uan.2 for ; Fri, 19 Aug 2016 08:43:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=38AR1G+pqE3eaetmJ5klURwL0ygZjWkbUkUOYKMd0xQ=; b=GELQlkx+1tORq0/DGgNUsX925FYnrIb9P8NoT0F5YwHXMKTiNuDr5AVTCHcOXXm8pL scWH2JsIYMM7J2bzmRHrRYEF01P5VxjXmur7jcGtExqAs97XI/I9KhPhUKSGKT4Qh9Of dV7gGuNaRFuHrBr5ZVpxOl5jm3WyudYFA1/qlGqbb1ezwtPYLjm0fDkNYbaWyP0bVylq 4Zu7WD4pIcvc3yvyCiouxYmyzpjVvJTz1FJ63XChrm8ylSGg1gNph3YwDMjEM/4oxww0 HADNDuwq8HlfTdRqu3hp5xKHRH2IAcr2SqEfuPJbIzjiykhYOlXs11P0UDG38aupN6RS tAqg== 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; bh=38AR1G+pqE3eaetmJ5klURwL0ygZjWkbUkUOYKMd0xQ=; b=H29rvuCmS1g/aL+wUeazAi6r90ruFiZE/4szm8VivCcAeL9s53nV5sc2OMR0B7wJkd U4AvexLfO+1gO9nxonbrHn5qkLDzk/W30EjT73uYjO6gk7G/fTGzV0rw9+Uj7730NngD nATmay9q/aWg8pXhXRGimsEojkjKL6qO2iIqgPC0OckShEbYeWihCMRxKAzyhQHggaoa WqzwvhFH1KMOVL6u3yP+p4R5TRLcp1gUk2J0LNpk6OXQBnCZoeNDXsgqcMrDpp4Vv9M8 9sOhaENUzcgAJvAqS2se7Pw6KmlmQyNZSWFd5ih9O3MCsov5TEr6JNfAcDL7/XwmIX8n REMA== X-Gm-Message-State: AEkoouvGO3YgLV4SMuF2H7OazIEcwXfrtHdtR+iHpdhr+Vn5D1HpGKQtDoKZGoYHHl4/3zBD3V5+rBaqSevwUg== X-Received: by 10.176.3.72 with SMTP id 66mr4398191uat.105.1471621403180; Fri, 19 Aug 2016 08:43:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.4.198 with HTTP; Fri, 19 Aug 2016 08:43:22 -0700 (PDT) In-Reply-To: <036801d1fa2a$466e9e00$d34bda00$@ndzh.com> References: <013b01d1f8ee$31fa09b0$95ee1d10$@ndzh.com> <20160818073203.GA4338@elstar.local> <04b501d1f949$116c63e0$34452ba0$@ndzh.com> <20160818121405.GA5282@elstar.local> <051301d1f950$7739c670$65ad5350$@ndzh.com> <20160818130555.GA5366@elstar.local> <051701d1f952$c4ae0b30$4e0a2190$@ndzh.com> <6BCE198E4EAEFC4CAB45D75826EFB0761525CCD7@eusaamb101.ericsson.se> <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> <036801d1fa2a$466e9e00$d34bda00$@ndzh.com> From: Andy Bierman Date: Fri, 19 Aug 2016 08:43:22 -0700 Message-ID: To: Susan Hares Content-Type: multipart/alternative; boundary=001a113f2694fb292e053a6e8e16 Archived-At: X-Mailman-Approved-At: Fri, 19 Aug 2016 09:02:25 -0700 Cc: "i2rs@ietf.org" , Alissa Cooper , Juergen Schoenwaelder , i2rs-chairs@ietf.org, Kathleen Moriarty , IESG , Jeffrey Haas , Joel Halpern , Lou Berger , 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Aug 2016 15:43:39 -0000 --001a113f2694fb292e053a6e8e16 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, That is simple. There needs to be consensus on the syntax and semantics of each statement in the YANG module. Since security is MTI and MTU for NETCONF and RESTCONF, there is no point debating which objects are OK without security. Andy On Fri, Aug 19, 2016 at 7:59 AM, Susan Hares wrote: > Andy: > > > > Thank you for your comments. Perhaps you can provide for the IESG the > list of things that are needed to move a Yang module forward in the IETF. > > > > Sue > > > > *From:* Andy Bierman [mailto:andy@yumaworks.com] > *Sent:* Friday, August 19, 2016 10:24 AM > *To:* Lou Berger > *Cc:* Susan Hares; Juergen Schoenwaelder; 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) > > > > Hi, > > > > I agree with Juergen. > > There are already too many details that need consensus to move > > a YANG module forward in the IETF. It takes too long already. > > > > 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? > > > > Standardized insecure access is a big change from what we have done > > for 30 years. There could be a good reason why we left this out of scope > > all this time. > > > > > > Andy > > > > > > On Fri, Aug 19, 2016 at 5:20 AM, Lou Berger wrote: > > > Sue, > > My message said three things: > > 1) Juergen's comment resonates with me. > > 2) I think the current text is acceptable. > > 3) I see changing the SHOULD to a MUST as problematic. > I understood one of the other messages on this thread proposing this > change which is what triggered my message. If I misunderstood that > message, feel free to interpret my message as supporting the current > text in question. > > Note that I am only speaking for myself (including in my role as NETMOD > co-chair) and not representing the consensus opinion of any WG. > > Lou > On 8/19/2016 8:07 AM, Susan Hares wrote: > > Lou: > > > > I am clear that Juergen does not want not want to place transport > requirements within the data model for NETMOD. His opinion was considere= d > in the rough for the I2RS WG. If this requirement is a problem for > NETCONF/NETMOD, the text currently says: > > > > REQ-SEC-09 states: > > > > The default mode of transport is secure so data models SHOULD clearly > annotate what data nodes can be > > passed over an insecure connection. > > > > However, if this means the NETCONF/NETMOD WG will not even entertain > proposal for marking the insecure functions in yang text -- then the two = WG > (I2RS/NETMOD) have a problem and should stop this standardization process > going forward. > > > > Sue > > > > > > -----Original Message----- > > From: Lou Berger [mailto:lberger@labn.net] > > Sent: Friday, August 19, 2016 7:34 AM > > To: Susan Hares; 'Juergen Schoenwaelder' > > Cc: i2rs@ietf.org; 'Alissa Cooper'; i2rs-chairs@ietf.org; 'Kathleen > Moriarty'; 'IESG'; jhaas@pfrc.org; '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) > > > > Sue, > > > > I don't see Juergen as arguing against model access via non-secure > transport. I read his point as that the transport security requirements > don't belong scattered within a data model. > > > > I have to say that from a model complexity (definition, process, review= , > implementation - take your pick) , language and NETMOD co-chair > perspective, his comment resonates with me. > > > > I think this makes the key text: > > > > The default mode of transport is > > secure so data models SHOULD clearly annotate what data nodes can be > > passed over an insecure connection. > > > > > > As this isn't a MUST, I personally think we can live with the text and > we can debate the issue further in the context of specific solutions. I > would strongly object to this being changed to a MUST, or if the document > is changed to make transport (security) requirements identified within da= ta > models a requirement. > > > > Lou > > > > On 8/19/2016 6:49 AM, Susan Hares wrote: > >> Juergen: > >> > >> You have laid out the two options: a) link the data-model to the > non-secure transport, and b) do not link the data to the non-secure > transport. I agree with you that past models did not link past SNMP MIB > data model to the transport. Existing NETCONF models do not link it to t= he > transport. As you have indicated, you disagreed in the I2RS WG and we > found consensus was to include the non-secure transport. > >> > >> I2RS was created to build things as an interface to the routing > environment. The operators clearly informed the I2RS group of this need > during the requirement setting phase prior to the time I was chair. The > reason I continue to press for this capability is their input, and the > existing use cases I listed previously in this mail: > >> > >> a) public information - BGP route views, > >> b) specific well know up events - such as public-web site up > >> c) specific network service events - interface to particular public LA= N > up. > >> > >> As you know, we do not have any I2RS data models that specify this > feature at this time. I suspect after we get through this lengthy > requirement phase, the operators may begin to specify new models that hav= e > this feature. > >> > >> Sue > >> > >> -----Original Message----- > >> From: Juergen Schoenwaelder > >> [mailto:j.schoenwaelder@jacobs-university.de] > >> Sent: Friday, August 19, 2016 4:58 AM > >> To: Susan Hares > >> Cc: 'Alissa Cooper'; 'Joel Halpern'; i2rs@ietf.org; > >> i2rs-chairs@ietf.org; 'Kathleen Moriarty'; 'IESG'; jhaas@pfrc.org; > >> 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) > >> > >> I repeat my technical argument: While there may be deployments where > non-secure transports may be reasonable to use, defining these situations > statically as part of data model schemas does not follow established > practices. The IETF has a long tradition of standardizing data models tha= t > can be used in a variety of operational contexts and I do not see reasons > why we should move away from that basic approach. > >> > >> /js > >> > >> On Thu, Aug 18, 2016 at 02:35:03PM -0400, Susan Hares wrote: > >>> Alissa: > >>> > >>> Just a little input you may not know. My background is 15 years > (1995-2010) developing a routing/switching platform (denoted as GateD) > which was sold to over 200 companies. We developed XML and a binary XML > based product that configured this product. It could do 100K configurati= on > lines and reboot in less than a second on most hardware. We also provide > status messages in secure streams and non-secure streams. I sold early > version of this code to companies that Alia has worked for - so she has > personal viewed the code. At the height of our work, our development te= am > ran to 50 people which I directed (First as VP of Engineering, and then a= s > CTO). It is due to this level of experience that Alia selected me for the > co-chair. Russ White has understood Cisco's process, and has also > directed software development teams for routing. > >>> > >>> In order to freshen my direct experience with I2RS on open source > work, I am working on a publically available work in Quagga based on the > confD product suggested by Cisco. > >>> > >>> In contrast, Juergen is a university professor who has worked on > proto-types. He is not working on an implementation. I hope he will. > >>> > >>> I hope you will consider this background in my response to your > comments below. > >>> > >>> Sue > >>> > >>> > >>> -----Original Message----- > >>> From: Alissa Cooper [mailto:alissa@cooperw.in] > >>> Sent: Thursday, August 18, 2016 12:54 PM > >>> To: Joel Halpern > >>> Cc: Susan Hares; Juergen Schoenwaelder; i2rs@ietf.org; > >>> i2rs-chairs@ietf.org; Kathleen Moriarty; IESG; jhaas@pfrc.org; > >>> 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) > >>> > >>> Jumping in here because this is relevant to my DISCUSS, hope nobody > minds (but if you do, I can go back to the other thread). > >>> > >>>>> On Aug 18, 2016, at 10:30 AM, Joel Halpern < > joel.halpern@ericsson.com> wrote: > >>>>> > >>>>> Let me try a different take approach to this particular question. > >>>>> > >>>>> Let me start by putting aside the question of where things are > marked, and come back to that afterwards. > >>>>> > >>>>> There are a number of cases that I2RS has been asked to cover of > high rate telemetry data. This may be BGP update information, it may be > frequent information about line card activity. There are other cases, so= me > of which have been documented. > >>>>> > >>>>> While not completely insensitive, the operators have made clear tha= t > they see protecting this data as unnecessary. While I would hope over ti= me > to move to a domain where all of it is protect, that is not trivial. As > the I2RS Architecture points out, it is expected that what we describe as= a > single I2RS >communication between a client and agent is actually > associated with multiple channels of communication. > >>>>> > >>>>> Now, if you want to say that the I2RS protocol requirements cannot > allow for unprotected channels, I guess we have disconnect between the IE= SG > and the WG. > >>>>> > >>>>> If we say that we can allow for unprotected channels, we then get t= o > the question of which data can be sent over such channels. While > architecturally I agree with Juergen that the model is a bad place to > specify it, the obverse is also true. Not having some limits on what can > be sent unprotected >causes concern about insufficient protection. If I > recall correctly, earlier security reviews called us to task for being to= o > broad in what we allowed. > >>>>> > >>>>> So, if the IESG wants us to just allow it anywhere, because the > >>>>> model is an awkward place to define the limitation, I can live with > that. What I can't live with is being told both that the model is a bad > place to define it and that there must be restrictions on what is sent > unprotected, without any proposal on how we are to move forward. > >>>> Thank you Joel, this explanation helps me a lot. I think there is a > disconnect about how the restrictions are expressed. From reading the ema= il > traffic about this document, it strikes me that trying to express the > restrictions programmatically doesn=E2=80=99t make much sense in this cas= e. > >>>> I agree with Juergen that it will be challenging to make a judgment = a > priori in order to bake a restriction into a data model, because data tha= t > is considered sensitive enough to warrant a secure transport in one > deployment may not be considered sensitive in another deployment. > >>>> So for any data elements where there is any question at all about > >>>> whether they might be sensitive (i.e., any data elements that are no= t > already routinely made public), I would expect data model authors to end = up > indicating that they may be sent over either secure or insecure transport= , > which renders the indication not useful. > >>>> Perhaps it would make more sense then to just enumerate in the text > the cases that motivate the inclusion of protocol support for insecure > transport: > >>>> > >>>> 1. For conveyance of information that is already routinely made > public. > >>>> 2. For line card activity data where there is no likely upgrade path > to support secure transports in the foreseeable future. > >>>> > >>>> Then the normative requirements would be on clients and agents to us= e > secure transports unless those clients and agents are deployed where eith= er > of the operational circumstances above necessitate otherwise. > >>>> Alissa > >>> Point 1: > >>> I disagree with Juergen on the difficulty in specifying the sections > of the yang modules. I have provided a suggested solution in: > >>> https://tools.ietf.org/html/draft-hares-i2rs-protocol- > strawman-03#section-4.5.2. > >>> > >>> Given the mount schema functionality, we can mount ephemeral state > module which augment non-ephemeral state modules which are "in-secure onl= y". > >>> > >>> Point 2: > >>> I am willing to put an enumeration of the use cases in the protocol > requirement, but I would like to understand the purpose for the > enumeration. We are not doing a use case, but a requirements document. > This information appears to be a "use case" rather than a technical > description. What purpose are you looking for this enumeration to > server. Are you looking for the enumeration in SEC-REQ-08? > >>> > >>> Point 3: Could you review -08.txt on this topic, especially the text > below. Given your comments, I believe I should change the last line to a > MUST. > >>> New/ The default mode of transport is > >>> secure so data models MUST clearly annotate what data nodes can be > >>> passed over an insecure connection. > >>> / > >>> > >>> Sue > >>> > >>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >>> As to the normative requirements (-08.txt) version: > >>> > >>> Section 3: > >>> > >>> I2RS allows the use of an insecure transport for portions of data > >>> models that clearly indicate the use of an insecure transport. > >>> Operators deploying I2RS must determine if they want to populate a= nd > >>> deploy the portions of the data model which use insecure transport= s. > >>> > >>> In Section 3.2 in version -08.txt > >>> > >>> SEC-REQ-08: The I2RS protocol MUST be able to transfer data over a > >>> secure transport and optionally MAY be able to transfer data over = a > >>> non-secure transport. A secure transport MUST provide data > >>> confidentiality, data integrity, and replay prevention. > >>> > >>> The default I2RS transport is a secure transport. > >>> > >>> A non-secure transport can be used for publishing telemetry data o= r > >>> other operational state that was specifically indicated to non- > >>> confidential in the data model in the Yang syntax. > >>> > >>> The configuration of ephemeral data in the I2RS Agent by the I2RS > >>> client SHOULD be done over a secure transport. It is anticipated > >>> that the passing of most I2RS ephemeral state operational status > >>> SHOULD be done over a secure transport. As > >>> [I-D.ietf-i2rs-ephemeral-state] notes, a data model MUST indicate > >>> whether the transport exchanging the data between I2RS client and > >>> I2RS agent is secure or insecure. > >>> > >>> The default mode of transport is > >>> secure so data models SHOULD clearly annotate what data nodes can = be > >>> passed over an insecure connection. > >>> > >>>> Yours, > >>>> Joel > >>>> > >>>> -----Original Message----- > >>>> From: Susan Hares [mailto:shares@ndzh.com] > >>>> Sent: Thursday, August 18, 2016 9:17 AM > >>>> To: 'Juergen Schoenwaelder' > >>>> Cc: i2rs@ietf.org; i2rs-chairs@ietf.org; 'Kathleen Moriarty' > >>>> ; 'The IESG' ; > >>>> jhaas@pfrc.org; > >>>> 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) > >>>> > >>>> Juergen and Kathleen: > >>>> > >>>> Let me proceed with two examples: BGP route views data model and the > event for the web-service data. > >>>> > >>>> The content of these data models are designated as exposed to > public. The routing system only populates the proposed BGP route views > data model with the data destined for the BGP looking glass. The policy = on > the routing system indicates what information gets transferred. The data > model is completely available to the public. The Yang Doctors are going = to > review this by seeing the whole model is public and available via > non-secure means. > >>>> The security people are going to review this seeing that the whole > model is public, and available via an unprotect means. The fact the data > model is all public should simplify the review. > >>>> > >>>> An event from the I2RS RIB that a web-service route is up is the > second case. The I2RS RIB has an event based on policy that indicates a > web-service route is up. The yang-1.1 doctors must review the content of > the event text to see it does not break privacy or provide too much > >>>> information The event mechanisms will need to work over secure > transport > >>>> and insecure transport. Most of the data will go over the secure > transport event stream. However, a small amount of information may go ove= r > the insecure transport stream. > >>>> > >>>> First, let me know if my use cases are understandable. Second, let > me know if you disagree with this use cases. > >>>> > >>>> Fyi - IESG approved the architecture with the insecure stream. > >>>> > >>>> Sue > >>>> > >>>> -----Original Message----- > >>>> From: Juergen Schoenwaelder > >>>> [mailto:j.schoenwaelder@jacobs-university.de] > >>>> Sent: Thursday, August 18, 2016 9:06 AM > >>>> To: Susan Hares > >>>> Cc: i2rs@ietf.org; i2rs-chairs@ietf.org; 'Kathleen Moriarty'; 'The > >>>> IESG'; jhaas@pfrc.org; > >>>> 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) > >>>> > >>>> I just do not know on which basis a data model writer can decide > whether a data object can be exposed in an unprotected way. How are YANG > doctors going to review this? How are security directorate people going t= o > judge this? But as promised, I leave (still puzzled) now. > >>>> > >>>> /js > >>>> > >>>> On Thu, Aug 18, 2016 at 09:00:14AM -0400, Susan Hares wrote: > >>>>> Juergen: > >>>>> > >>>>> Yes, we seem to disagree on the value of making it hardwired in the > model. > >>>>> For me, the value is a common understanding of deployment > >>>>> distribution > >>>> such > >>>>> as the route-views. Since the operators argued strongly for this > point, > >>>> I > >>>>> think the best idea is to get it working in code and then see if > >>>>> the deployment matches the requests. > >>>>> > >>>>> Sue > >>>>> > >>>>> -----Original Message----- > >>>>> From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Juergen > >>>>> Schoenwaelder > >>>>> Sent: Thursday, August 18, 2016 8:14 AM > >>>>> To: Susan Hares > >>>>> Cc: i2rs@ietf.org; i2rs-chairs@ietf.org; 'Kathleen Moriarty'; 'The > >>>>> IESG'; jhaas@pfrc.org; > >>>>> 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) > >>>>> > >>>>> Sue, > >>>>> > >>>>> I still do not see why the 'mode of exposure' of data benefits from > >>>>> being hard-wired in the data model. For me, it is a situational and > >>>>> deployment specific question. But I shut up here since I aired this > >>>>> concern before (and we simply seem to disagree). > >>>>> > >>>>> /js > >>>>> > >>>>> On Thu, Aug 18, 2016 at 08:07:18AM -0400, Susan Hares wrote: > >>>>>> Juergen: > >>>>>> > >>>>>> My example is the looking glass servers for the BGP route views > >>>>>> project > >>>>>> (http://www.routeviews.org/) or a route indicating the presence of > a > >>>>>> web-server that is public. For the BGP I2RS route, a yang model > could > >>>>>> replace the looking glass function, and provide events for these > looking > >>>>>> glass functions. For the web-server route, an event be sent wh= en > >>>> that > >>>>>> one route is added. > >>>>>> > >>>>>> Sue > >>>>>> > >>>>>> > >>>>>> -----Original Message----- > >>>>>> From: Juergen Schoenwaelder > >>>>>> [mailto:j.schoenwaelder@jacobs-university.de] > >>>>>> Sent: Thursday, August 18, 2016 3:32 AM > >>>>>> To: Susan Hares > >>>>>> Cc: 'Kathleen Moriarty'; 'The IESG'; jhaas@pfrc.org; > >>>>>> i2rs@ietf.org; i2rs-chairs@ietf.org; > >>>>>> 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 Wed, Aug 17, 2016 at 09:16:48PM -0400, Susan Hares wrote: > >>>>>>> ----------------------------------------------------------------- > >>>>>>> - > >>>>>>> -- > >>>>>>> -- > >>>>>>> COMMENT: > >>>>>>> ----------------------------------------------------------------- > >>>>>>> - > >>>>>>> -- > >>>>>>> -- > >>>>>>> > >>>>>>>> Section 3: > >>>>>>>> Can you clarify the second to last sentence? Do you mean there > >>>>>>>> are > >>>>>> sections that indicate an insecure transport should be used? > >>>>>>>> I2RS allows the use of an > >>>>>>>> insecure transport for portions of data models that clearly > >>>>>>>> indicate insecure transport. > >>>>>>>> Perhaps: > >>>>>>>> I2RS allows the use of an > >>>>>>>> insecure transport for portions of data models that clearly > >>>>>>>> indicate the use of an insecure transport. > >>>>>> I still wonder how a data model writer can reasonably decide > >>>>>> whether a piece of information can be shipped safely over an > >>>>>> insecure transport since this decision often depends on the > >>>>>> specifics of a deployment > >>>>> situation. > >>>>>> /js > >>>>>> > >>>>>> PS: I hope we do not end up with defining data multiple times (onc= e > >>>>>> for insecure transport and once for secured transports). > >>>>>> > >>>>>> -- > >>>>>> Juergen Schoenwaelder Jacobs University Bremen gGmbH > >>>>>> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | > Germany > >>>>>> Fax: +49 421 200 3103 > >>>>>> > >>>>>> _______________________________________________ > >>>>>> i2rs mailing list > >>>>>> i2rs@ietf.org > >>>>>> https://www.ietf.org/mailman/listinfo/i2rs > >>>>> -- > >>>>> Juergen Schoenwaelder Jacobs University Bremen gGmbH > >>>>> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | > Germany > >>>>> Fax: +49 421 200 3103 > >>>>> > >>>>> _______________________________________________ > >>>>> i2rs mailing list > >>>>> i2rs@ietf.org > >>>>> https://www.ietf.org/mailman/listinfo/i2rs > >>>>> > >>>> -- > >>>> Juergen Schoenwaelder Jacobs University Bremen gGmbH > >>>> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germa= ny > >>>> Fax: +49 421 200 3103 > >>>> > > > > > > > > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs > > > --001a113f2694fb292e053a6e8e16 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

That is simple.
There nee= ds to be consensus on the syntax and semantics of each
statement = in the YANG module.

Since security is MTI and MTU = for NETCONF and RESTCONF, there
is no point debating which object= s are OK without security.

Andy



On Fri, Aug 19, 2016 at 7:59 AM, Susan Hares <shares@ndzh.com><= /span> wrote:

Andy:

=C2=A0

Thank you for your comments.=C2=A0=C2=A0 Perhaps you can pr= ovide for the IESG the list of things that are needed to move a Yang module= forward in the IETF.=C2=A0=C2=A0

=C2=A0

Sue

=C2=A0

From: Andy B= ierman [mailto:andy= @yumaworks.com]
Sent: Friday, August 19, 2016 10:24 AM
To: Lou Berger
Cc: Susan Hares; Juergen Schoenwaelder; i2rs@ietf.org; Alissa Coo= per; 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-ie= tf-i2rs-protocol-security-requirements-07: (with DISCUSS and COMMENT)<= u>

=C2=A0

Hi,

=C2=A0

I agree with Juerge= n.

There are already too= many details that need consensus to move

a YANG module forward in the IETF.=C2=A0 It takes too lon= g already.

=C2=A0=

We could have been tagging MIB= objects all along, but we don't.

Imagine if there was a debate for every single OBJECT-TYPE m= acro

"is this leaf = OK for noAuth/noPriv?"

=C2=A0

Are there eve= n 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?

=C2=A0

Standardized insecure access is a big change f= rom what we have done

fo= r 30 years.=C2=A0 There could be a good reason why we left this out of scop= e

all this time.<= u>

=C2=A0

<= div>

=C2=A0

Andy

= =C2=A0

=C2=A0

On Fri, Aug 19, 2016 at 5:20 AM, Lou Berg= er <lberger@labn.n= et> wrote:


Sue,

M= y message said three things:

1) Juergen's comment resonates with= me.

2) I think the current text is acceptable.

3) I see chan= ging the SHOULD to a MUST as problematic.
I understood one of the other = messages on this thread proposing this
change which is what triggered my= message.=C2=A0 =C2=A0If I misunderstood that
message, feel free to inte= rpret my message as supporting the current
text in question.

Note= that I am only speaking for myself (including in my role as NETMOD
co-c= hair) and not representing the consensus opinion of any WG.

Lou
O= n 8/19/2016 8:07 AM, Susan Hares wrote:
> Lou:
>
> I am c= lear that Juergen does not want not want to place transport requirements wi= thin the data model for NETMOD.=C2=A0 His opinion was considered in the rou= gh for the I2RS WG. If this requirement is a problem for NETCONF/NETMOD,=C2= =A0 the text currently says:
>
> REQ-SEC-09 states:
>
= >=C2=A0 =C2=A0The default mode of transport is secure so data models SHO= ULD clearly annotate what data nodes can be
>=C2=A0 =C2=A0 passed ove= r an insecure connection.
>
> However, if this means the NETCON= F/NETMOD WG will not even entertain proposal for marking the insecure funct= ions in yang text -- then the two WG (I2RS/NETMOD) have a problem and shoul= d stop this standardization process going forward.
>
> Sue
&= gt;
>
> -----Original Message-----
> From: Lou Berger [ma= ilto:lberger@labn.net= ]
> Sent: Friday, August 19, 2016 7:34 AM
> To: Susan Hares= ; 'Juergen Schoenwaelder'
> Cc: i2rs@ietf.org; 'Alissa Cooper'; i2rs-chairs@ietf.org= ; 'Kathleen Moriarty'; 'IESG'; jhaas@pfrc.org; '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)>
> Sue,
>
>=C2=A0 =C2=A0 =C2=A0I don't see Juerg= en as arguing against model access via non-secure transport. I read his poi= nt as that the transport security requirements don't belong scattered w= ithin a data model.
>
> I have to say that from a model complex= ity (definition, process, review, implementation - take your pick) , langua= ge and NETMOD co-chair perspective, his comment resonates with me.
><= br>> I think this makes the key text:
>
>=C2=A0 =C2=A0 The d= efault mode of transport is
>=C2=A0 =C2=A0 secure so data models SHOU= LD clearly annotate what data nodes can be
>=C2=A0 =C2=A0 passed over= an insecure connection.
>
>
> As this isn't a MUST, = I personally think we can live with the text and we can debate the issue fu= rther in the context of specific solutions.=C2=A0 I would strongly object t= o this being changed to a MUST, or if the document is changed to make trans= port (security) requirements identified within data models a requirement.>
> Lou
>
> On 8/19/2016 6:49 AM, Susan Hares wrote:=
>> Juergen:
>>
>> You have laid out the two opt= ions:=C2=A0 =C2=A0a) link the data-model to the non-secure transport, and b= ) do not link the data to the non-secure transport.=C2=A0 =C2=A0I agree wit= h you that past models did not link past SNMP MIB data model to the transpo= rt.=C2=A0 Existing NETCONF models do not link it to the transport.=C2=A0 = =C2=A0As you have indicated, you disagreed in the I2RS WG and we found cons= ensus was to include the non-secure transport.
>>
>> I2RS= was created to build things as an interface to the routing environment.=C2= =A0 =C2=A0The operators clearly informed the I2RS group of this need during= the requirement setting phase prior to the time I was chair.=C2=A0 The rea= son I continue to press for this capability is their input, and the existin= g use cases I listed previously in this mail:
>>
>> a) pu= blic information - BGP route views,
>> b) specific well know up ev= ents - such as public-web site up
>> c) specific network service e= vents - interface to particular public LAN up.
>>
>> As y= ou know, we do not have any I2RS data models that specify this feature at t= his time.=C2=A0 =C2=A0I suspect after we get through this lengthy requireme= nt phase, the operators may begin to specify new models that have this feat= ure.
>>
>> Sue
>>
>> -----Original Mess= age-----
>> From: Juergen Schoenwaelder
>> [mailto:j.schoe= nwaelder@jacobs-university.de]
>> Sent: Friday, August 19= , 2016 4:58 AM
>> To: Susan Hares
>> Cc: 'Alissa Coop= er'; 'Joel Halpern'; i2rs@ietf.org;
>> i2rs-chairs@ietf.org; 'Kathleen Moriarty'= ;; 'IESG'; jhaa= s@pfrc.org;
>> draft-ietf-i2rs-protocol-security-requirements@ietf.org
>> Subject: Re: [i2rs] Kathlee= n Moriarty's Discuss on
>> draft-ietf-i2rs-protocol-secur= ity-requirements-07: (with DISCUSS and
>> COMMENT)
>>
= >> I repeat my technical argument: While there may be deployments whe= re non-secure transports may be reasonable to use, defining these situation= s statically as part of data model schemas does not follow established prac= tices. The IETF has a long tradition of standardizing data models that can = be used in a variety of operational contexts and I do not see reasons why w= e should move away from that basic approach.
>>
>> /js>>
>> On Thu, Aug 18, 2016 at 02:35:03PM -0400, Susan Hares= wrote:
>>> Alissa:
>>>
>>> Just a litt= le input you may not know.=C2=A0 My background is 15 years (1995-2010)=C2= =A0 developing a routing/switching platform (denoted as GateD) which was so= ld to over 200 companies.=C2=A0 =C2=A0We developed XML and a binary XML bas= ed product that configured this product.=C2=A0 It could do 100K configurati= on lines and reboot in less than a second on most hardware.=C2=A0 We also p= rovide status messages in secure streams and non-secure streams.=C2=A0 =C2= =A0 I sold early version of this code to companies that Alia has worked for= =C2=A0 - so she has personal viewed the code.=C2=A0 =C2=A0At the height of = our work, our development team ran to 50 people which I directed (First as = VP of Engineering, and then as CTO). It is due to this level of experience = that Alia selected me for the co-chair.=C2=A0 =C2=A0Russ White has understo= od Cisco's process, and has also directed software development teams fo= r routing.
>>>
>>> In order to freshen my direct ex= perience with I2RS on open source work, I am working on a publically availa= ble work in Quagga based on the confD product suggested by Cisco.
>&g= t;>
>>> In contrast, Juergen is a university professor who h= as worked on proto-types.=C2=A0 =C2=A0He is not working on an implementatio= n.=C2=A0 =C2=A0I hope he will.
>>>
>>> I hope you w= ill consider this background in my response to your comments below.
>= >>
>>> Sue
>>>
>>>
>>>= ; -----Original Message-----
>>> From: Alissa Cooper [mailto:alissa@cooperw.in]=
>>> Sent: Thursday, August 18, 2016 12:54 PM
>>> T= o: Joel Halpern
>>> Cc: Susan Hares; Juergen Schoenwaelder; i2rs@ietf.org;
>&= gt;> i2rs-chai= rs@ietf.org; Kathleen Moriarty; IESG; jhaas@pfrc.org;
>>> dr= aft-ietf-i2rs-protocol-security-requirements@ietf.org
>>&= gt; Subject: Re: [i2rs] Kathleen Moriarty's Discuss on
>>> = draft-ietf-i2rs-protocol-security-requirements-07: (with DISCUSS and>>> COMMENT)
>>>
>>> Jumping in here bec= ause this is relevant to my DISCUSS, hope nobody minds (but if you do, I ca= n go back to the other thread).
>>>
>>>>> On = Aug 18, 2016, at 10:30 AM, Joel Halpern <joel.halpern@ericsson.com> wrote:>>>>>
>>>>> Let me try a different take a= pproach to this particular question.
>>>>>
>>>= ;>> Let me start by putting aside the question of where things are ma= rked, and come back to that afterwards.
>>>>>
>>= >>> There are a number of cases that I2RS has been asked to cover = of high rate telemetry data.=C2=A0 This may be BGP update information, it m= ay be frequent information about line card activity.=C2=A0 There are other = cases, some of which have been documented.
>>>>>
>&= gt;>>> While not completely insensitive, the operators have made c= lear that they see protecting this data as unnecessary.=C2=A0 While I would= hope over time to move to a domain where all of it is protect, that is not= trivial.=C2=A0 As the I2RS Architecture points out, it is expected that wh= at we describe as a single I2RS >communication between a client and agen= t is actually associated with multiple channels of communication.
>&g= t;>>>
>>>>> Now, if you want to say that the I2R= S protocol requirements cannot allow for unprotected channels, I guess we h= ave disconnect between the IESG and the WG.
>>>>>
>= >>>> If we say that we can allow for unprotected channels, we t= hen get to the question of which data can be sent over such channels.=C2=A0= While architecturally I agree with Juergen that the model is a bad place t= o specify it, the obverse is also true.=C2=A0 Not having some limits on wha= t can be sent unprotected >causes concern about insufficient protection.= =C2=A0 If I recall correctly, earlier security reviews called us to task fo= r being too broad in what we allowed.
>>>>>
>>&g= t;>> So, if the IESG wants us to just allow it anywhere, because the<= br>>>>>> model is an awkward place to define the limitation,= I can live with that.=C2=A0 What I can't live with is being told both = that the model is a bad place to define it and that there must be restricti= ons on what is sent unprotected, without any proposal on how we are to move= forward.
>>>> Thank you Joel, this explanation helps me a l= ot. I think there is a disconnect about how the restrictions are expressed.= From reading the email traffic about this document, it strikes me that try= ing to express the restrictions programmatically doesn=E2=80=99t make much = sense in this case.
>>>> I agree with Juergen that it will b= e challenging to make a judgment a priori in order to bake a restriction in= to a data model, because data that is considered sensitive enough to warran= t a secure transport in one deployment may not be considered sensitive in a= nother deployment.
>>>> So for any data elements where there= is any question at all about
>>>> whether they might be sen= sitive (i.e., any data elements that are not already routinely made public)= , I would expect data model authors to end up indicating that they may be s= ent over either secure or insecure transport, which renders the indication = not useful.
>>>> Perhaps it would make more sense then to ju= st enumerate in the text the cases that motivate the inclusion of protocol = support for insecure transport:
>>>>
>>>> 1. = For conveyance of information that is already routinely made public.
>= ;>>> 2. For line card activity data where there is no likely upgra= de path to support secure transports in the foreseeable future.
>>= >>
>>>> Then the normative requirements would be on cl= ients and agents to use secure transports unless those clients and agents a= re deployed where either of the operational circumstances above necessitate= otherwise.
>>>> Alissa
>>> Point 1:
>>= > I disagree with Juergen on the difficulty in specifying the sections o= f the yang modules.=C2=A0 I have provided a suggested solution in:
>&= gt;> https://tools.ietf.org/html/draft-hares-i2rs-protocol-strawman-03#section-4.5.2.
>>&= gt;
>>> Given the mount schema functionality, we can mount ephe= meral state module which augment non-ephemeral state modules which are &quo= t;in-secure only".
>>>
>>> Point 2:
>>= ;> I am willing to put an enumeration of the use cases in the protocol r= equirement, but I would like to understand the purpose for the enumeration.= =C2=A0 =C2=A0We are not doing a use case, but a requirements document.=C2= =A0 This information appears to be a "use case" rather than a tec= hnical description.=C2=A0 =C2=A0What purpose are you looking for this enume= ration to server.=C2=A0 Are you looking for the enumeration in SEC-REQ-08?<= br>>>>
>>> Point 3: Could you review -08.txt on this t= opic, especially the text below.=C2=A0 Given your comments, I believe I sho= uld change the last line to a MUST.
>>> New/=C2=A0 =C2=A0The de= fault mode of transport is
>>>=C2=A0 =C2=A0 secure so data mode= ls MUST clearly annotate what data nodes can be
>>>=C2=A0 =C2= =A0 passed over an insecure connection.
>>> /
>>>>>> Sue
>>>
>>> =3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>>> As to the normative requi= rements (-08.txt) version:
>>>
>>> Section 3:
&g= t;>>
>>>=C2=A0 =C2=A0 I2RS allows the use of an insecure = transport for portions of data
>>>=C2=A0 =C2=A0 models that cle= arly indicate the use of an insecure transport.
>>>=C2=A0 =C2= =A0 Operators deploying I2RS must determine if they want to populate and>>>=C2=A0 =C2=A0 deploy the portions of the data model which use = insecure transports.
>>>
>>> In Section 3.2 in vers= ion -08.txt
>>>
>>>=C2=A0 =C2=A0 SEC-REQ-08: The I2= RS protocol MUST be able to transfer data over a
>>>=C2=A0 =C2= =A0 secure transport and optionally MAY be able to transfer data over a
= >>>=C2=A0 =C2=A0 non-secure transport.=C2=A0 A secure transport MU= ST provide data
>>>=C2=A0 =C2=A0 confidentiality, data integrit= y, and replay prevention.
>>>
>>>=C2=A0 =C2=A0 The = default I2RS transport is a secure transport.
>>>
>>&g= t;=C2=A0 =C2=A0 A non-secure transport can be used for publishing telemetry= data or
>>>=C2=A0 =C2=A0 other operational state that was spec= ifically indicated to non-
>>>=C2=A0 =C2=A0 confidential in the= data model in the Yang syntax.
>>>
>>>=C2=A0 =C2= =A0 The configuration of ephemeral data in the I2RS Agent by the I2RS
&g= t;>>=C2=A0 =C2=A0 client SHOULD be done over a secure transport.=C2= =A0 It is anticipated
>>>=C2=A0 =C2=A0 that the passing of most= I2RS ephemeral state operational status
>>>=C2=A0 =C2=A0 SHOUL= D be done over a secure transport.=C2=A0 As
>>>=C2=A0 =C2=A0 [I= -D.ietf-i2rs-ephemeral-state] notes,=C2=A0 a data model MUST indicate<= br>>>>=C2=A0 =C2=A0 whether the transport exchanging the data betw= een I2RS client and
>>>=C2=A0 =C2=A0 I2RS agent is secure or in= secure.
>>>
>>>=C2=A0 =C2=A0 The default mode of tr= ansport is
>>>=C2=A0 =C2=A0 secure so data models SHOULD clearl= y annotate what data nodes can be
>>>=C2=A0 =C2=A0 passed over = an insecure connection.
>>>
>>>> Yours,
>&= gt;>> Joel
>>>>
>>>> -----Original Mess= age-----
>>>> From: Susan Hares [mailto:shares@ndzh.com]
>>>> S= ent: Thursday, August 18, 2016 9:17 AM
>>>> To: 'Juergen= Schoenwaelder' <j.schoenwaelder@jacobs-university.de>>>>> Cc: i2= rs@ietf.org; = i2rs-chairs@ietf.org; 'Kathleen Moriarty'
>>>> &= lt;Ka= thleen.Moriarty.ietf@gmail.com>; 'The IESG' <iesg@ietf.org>;
>&= gt;>> jhaas@pfrc.= org;
>>>> draft-ietf-i2rs-protocol-security-requirements@ietf.org
>>>> Subject: RE: [i2rs= ] Kathleen Moriarty's Discuss on
>>>> draft-ietf-i2rs-pr= otocol-security-requirements-07: (with DISCUSS and
>>>>= COMMENT)
>>>>
>>>> Juergen and Kathleen:
= >>>>
>>>> Let me proceed with two examples: BGP = route views data model and the event for the web-service data.
>>&= gt;>
>>>> The content of these data models are designated= as exposed to public.=C2=A0 The routing system only populates the proposed= BGP route views data model with the data destined for the BGP looking glas= s.=C2=A0 The policy on the routing system indicates what information gets t= ransferred.=C2=A0 The data model is completely available to the public.=C2= =A0 The Yang Doctors are going to review this by seeing the whole model is = public and available via non-secure means.
>>>> The security= people are going to review this seeing that the whole model is public, and= available via an unprotect means.=C2=A0 The fact the data model is all pub= lic should simplify the review.
>>>>
>>>> An = event from the I2RS RIB that a web-service route is up is the second case.= =C2=A0 The I2RS RIB has an event based on policy that indicates a web-servi= ce route is up.=C2=A0 The yang-1.1 doctors must review the content of the e= vent text to see it does not break privacy or provide too much
>>&= gt;> information=C2=A0 =C2=A0The event mechanisms will need to work over= secure transport
>>>> and insecure transport.=C2=A0 Most of= the data will go over the secure transport event stream. However, a small = amount of information may go over the insecure transport stream.
>>= ;>>
>>>> First, let me know if my use cases are unders= tandable.=C2=A0 Second, let me know if you disagree with this use cases.>>>>
>>>> Fyi -=C2=A0 IESG approved the archite= cture with the insecure stream.
>>>>
>>>> Sue=
>>>>
>>>> -----Original Message-----
>= >>> From: Juergen Schoenwaelder
>>>> [mailto:j.schoe= nwaelder@jacobs-university.de]
>>>> Sent: Thursday,= August 18, 2016 9:06 AM
>>>> To: Susan Hares
>>>= ;> Cc: i2rs@ietf.org<= /a>; i2rs-chairs@= ietf.org; 'Kathleen Moriarty'; 'The
>>>> IES= G'; jhaas@pfrc.org<= /a>;
>>>> draft-ietf-i2rs-protocol-se= curity-requirements@ietf.org
>>>> Subject: Re: [i2rs] Ka= thleen Moriarty's Discuss on
>>>> draft-ietf-i2rs-protoc= ol-security-requirements-07: (with DISCUSS and
>>>> COM= MENT)
>>>>
>>>> I just do not know on which b= asis a data model writer can decide whether a data object can be exposed in= an unprotected way. How are YANG doctors going to review this? How are sec= urity directorate people going to judge this? But as promised, I leave (sti= ll puzzled) now.
>>>>
>>>> /js
>>>= ;>
>>>> On Thu, Aug 18, 2016 at 09:00:14AM -0400, Susan H= ares wrote:
>>>>> Juergen:
>>>>>
>= ;>>>> Yes, we seem to disagree on the value of making it hardwi= red in the model.
>>>>> For me, the value is a common und= erstanding of deployment
>>>>> distribution
>>&g= t;> such
>>>>> as the route-views.=C2=A0 =C2=A0Since t= he operators argued strongly for this point,
>>>> I
>&= gt;>>> think the best idea is to get it working in code and then s= ee if
>>>>> the deployment matches the requests.
>&= gt;>>>
>>>>> Sue
>>>>>
>= >>>> -----Original Message-----
>>>>> From: i= 2rs [mailto:i2rs= -bounces@ietf.org] On Behalf Of Juergen
>>>>> Schoenw= aelder
>>>>> Sent: Thursday, August 18, 2016 8:14 AM
&= gt;>>>> To: Susan Hares
>>>>> Cc: i2rs@ietf.org; i2rs-chairs@ietf.org; 'Ka= thleen Moriarty'; 'The
>>>>> IESG'; jhaas@pfrc.org;
>>= ;>>> draft-ietf-i2rs-protocol-security-requ= irements@ietf.org
>>>>> Subject: Re: [i2rs] Kathleen = Moriarty's Discuss on
>>>>> draft-ietf-i2rs-protocol-= security-requirements-07: (with DISCUSS
>>>>> and>>>>> COMMENT)
>>>>>
>>>>&= gt; Sue,
>>>>>
>>>>> I still do not see= why the 'mode of exposure' of data benefits from
>>>&g= t;> being hard-wired in the data model. For me, it is a situational and<= br>>>>>> deployment specific question. But I shut up here si= nce I aired this
>>>>> concern before (and we simply seem= to disagree).
>>>>>
>>>>> /js
>&= gt;>>>
>>>>> On Thu, Aug 18, 2016 at 08:07:18AM = -0400, Susan Hares wrote:
>>>>>> Juergen:
>>&= gt;>>>
>>>>>> My example is the looking glass= servers for the BGP route views
>>>>>> project
>= ;>>>>> (http://www.routeviews.org/) or a route indicating the presence of = a
>>>>>> web-server that is public.=C2=A0 =C2=A0For th= e BGP I2RS route, a yang model could
>>>>>> replace th= e looking glass function, and provide events for these looking
>>&= gt;>>> glass functions.=C2=A0 =C2=A0 For the web-server route,=C2= =A0 an event be sent when
>>>> that
>>>>>&= gt; one route is added.
>>>>>>
>>>>>= > Sue
>>>>>>
>>>>>>
>>= ;>>>> -----Original Message-----
>>>>>> Fr= om: Juergen Schoenwaelder
>>>>>> [mailto:j.schoenwaelde= r@jacobs-university.de]
>>>>>> Sent: Thursday= , August 18, 2016 3:32 AM
>>>>>> To: Susan Hares
&g= t;>>>>> Cc: 'Kathleen Moriarty'; 'The IESG';= jhaas@pfrc.org;>>>>>> i2rs@ietf.org; i2rs-chairs@ietf.org;
>>>>>> draft-ietf-i2rs-protocol-security-requirements@ietf.org
>&g= t;>>>> Subject: Re: [i2rs] Kathleen Moriarty's Discuss on>>>>>> draft-ietf-i2rs-protocol-security-requireme= nts-07: (with DISCUSS
>>>>>> and
>>>>&g= t;> COMMENT)
>>>>>>
>>>>>> On = Wed, Aug 17, 2016 at 09:16:48PM -0400, Susan Hares wrote:
>>>&g= t;>>> -------------------------------------------------------= ----------
>>>>>>> -
>>>>>&g= t;> --
>>>>>>> --
>>>>>>>= ; COMMENT:
>>>>>>> -----------------------------------------------------------------
>>>>>>>= -
>>>>>>> --
>>>>>>> -->>>>>>>
>>>>>>>> Section 3= :
>>>>>>>> Can you clarify the second to last se= ntence?=C2=A0 Do you mean there
>>>>>>>> are
= >>>>>> sections that indicate an insecure transport shoul= d be used?
>>>>>>>>=C2=A0 I2RS allows the use of= an
>>>>>>>> insecure transport for portions of = data models that clearly
>>>>>>>> indicate=C2=A0= insecure transport.
>>>>>>>> Perhaps:
>&g= t;>>>>>> I2RS allows the use of an
>>>>>= ;>>> insecure transport for portions of data models that clearly>>>>>>>> indicate the use of an=C2=A0 insecure tr= ansport.
>>>>>> I still wonder how a data model writer= can reasonably decide
>>>>>> whether a piece of infor= mation can be shipped safely over an
>>>>>> insecure t= ransport since this decision often depends on the
>>>>>&g= t; specifics of a deployment
>>>>> situation.
>>= >>>> /js
>>>>>>
>>>>>>= ; PS: I hope we do not end up with defining data multiple times (once
&g= t;>>>>>=C2=A0 =C2=A0 for insecure transport and once for sec= ured transports).
>>>>>>
>>>>>> -= -
>>>>>> Juergen Schoenwaelder=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0Jacobs University Bremen gGmbH
>>>>>>= Phone: +49 421 200 3587=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Campus Ring 1 | 2= 8759 Bremen | Germany
>>>>>> Fax:=C2=A0 =C2=A0+49 421 = 200 3103=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<http://www.jacobs-university.de/= >
>>>>>>
>>>>>> ______________= _________________________________
>>>>>> i2rs mai= ling list
>>>>>> i2rs@ietf.org
>>>>>> https://www.ietf.= org/mailman/listinfo/i2rs
>>>>> --
>>&g= t;>> Juergen Schoenwaelder=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Ja= cobs University Bremen gGmbH
>>>>> Phone: +49 421 200 358= 7=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Campus Ring 1 | 28759 Bremen | Germany>>>>> Fax:=C2=A0 =C2=A0+49 421 200 3103=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0<http://www.jacobs-university.de/>
>>>>&= gt;
>>>>> __________________________________________= _____
>>>>> i2rs mailing list
>>>>> i2rs@ietf.org
>&g= t;>>> https://www.ietf.org/mailman/listinfo/i2rs
>>= ;>>>
>>>> --
>>>> Juergen Schoenwael= der=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Jacobs University Bremen gGmbH<= br>>>>> Phone: +49 421 200 3587=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0Campus Ring 1 | 28759 Bremen | Germany
>>>> Fax:=C2=A0 = =C2=A0+49 421 200 3103=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<http://www.jacobs-univ= ersity.de/>
>>>>
>
>
>


_= ______________________________________________
i2rs mailing listi2rs@ietf.org
http= s://www.ietf.org/mailman/listinfo/i2rs

=C2=A0

<= /div>
--001a113f2694fb292e053a6e8e16-- From nobody Fri Aug 19 09:02:35 2016 Return-Path: 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 5036212DB39; Fri, 19 Aug 2016 08:44:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.739 X-Spam-Level: * X-Spam-Status: No, score=1.739 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, RDNS_NONE=0.793] autolearn=no 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 tV9xbUmjKsjM; Fri, 19 Aug 2016 08:44:01 -0700 (PDT) Received: from hickoryhill-consulting.com (unknown [50.245.122.97]) (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 ECF0D12DB20; Fri, 19 Aug 2016 08:43:59 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=184.157.82.170; From: "Susan Hares" To: "'Andy Bierman'" , "'Lou Berger'" References: <013b01d1f8ee$31fa09b0$95ee1d10$@ndzh.com> <20160818073203.GA4338@elstar.local> <04b501d1f949$116c63e0$34452ba0$@ndzh.com> <20160818121405.GA5282@elstar.local> <051301d1f950$7739c670$65ad5350$@ndzh.com> <20160818130555.GA5366@elstar.local> <051701d1f952$c4ae0b30$4e0a2190$@ndzh.com> <6BCE198E4EAEFC4CAB45D75826EFB0761525CCD7@eusaamb101.ericsson.se> <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> <036801d1fa2a$466e9e00$d34bda00$@ndzh.com> In-Reply-To: <036801d1fa2a$466e9e00$d34bda00$@ndzh.com> Date: Fri, 19 Aug 2016 11:42:21 -0400 Message-ID: <001501d1fa30$46d0ac70$d4720550$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0016_01D1FA0E.BFC43C90" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJ/RF5y8kBC7R3sO+auWKe566R2lwEcb/3KAg+ndAACAypBUwGJSPf4Amiv8FwDJLAGjQJqExQkAqfTovACEJToAwFDCzFbAlTVyfQCrq8/9AJKcpLBAq9whFMCDwN3eQIvrQjwnd6Y5GA= Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: X-Mailman-Approved-At: Fri, 19 Aug 2016 09:02:25 -0700 Cc: i2rs@ietf.org, 'Alissa Cooper' , 'Juergen Schoenwaelder' , 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) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Aug 2016 15:44:06 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0016_01D1FA0E.BFC43C90 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Andy:=20 =20 I have been thinking about your question for 30 minutes. Let me put = down a few of my personal opinions:=20 =20 1) Most (99%) of the ephemeral data models will not allow = non-secure transport.=20 2) If any ephemeral data models have an insecure section, the = review and consensus for a standards model should take longer.=20 I hope we can streamline the normal Yang model review. [It would be = nice to streamline features additions for NETCONF/RESTCONF as well]. =20 =20 3) I prefer to have the non-secure sections of a data model moved = to a separate date model, and the data model marked as insecure. =20 [I do not know if we could use the library function to mark the data = model in meta-language.] However, until we complete the mount schema work =E2=80=93 I do not know = if this is workable.=20 =20 Would it help if I changed version -08 to=20 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=20 Operational state that was specifically indicated to be = non-confidential in the data model. / =20 Sue=20 =20 =20 From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Susan Hares Sent: Friday, August 19, 2016 10:59 AM To: 'Andy Bierman'; 'Lou Berger' Cc: i2rs@ietf.org; 'Alissa Cooper'; 'Juergen Schoenwaelder'; = 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) =20 Andy:=20 =20 Thank you for your comments. Perhaps you can provide for the IESG the = list of things that are needed to move a Yang module forward in the = IETF. =20 =20 Sue=20 =20 From: Andy Bierman [mailto:andy@yumaworks.com]=20 Sent: Friday, August 19, 2016 10:24 AM To: Lou Berger Cc: Susan Hares; Juergen Schoenwaelder; 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) =20 Hi, =20 I agree with Juergen. There are already too many details that need consensus to move a YANG module forward in the IETF. It takes too long already. =20 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?" =20 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? =20 Standardized insecure access is a big change from what we have done for 30 years. There could be a good reason why we left this out of = scope all this time. =20 =20 Andy =20 =20 On Fri, Aug 19, 2016 at 5:20 AM, Lou Berger wrote: Sue, My message said three things: 1) Juergen's comment resonates with me. 2) I think the current text is acceptable. 3) I see changing the SHOULD to a MUST as problematic. I understood one of the other messages on this thread proposing this change which is what triggered my message. If I misunderstood that message, feel free to interpret my message as supporting the current text in question. Note that I am only speaking for myself (including in my role as NETMOD co-chair) and not representing the consensus opinion of any WG. Lou On 8/19/2016 8:07 AM, Susan Hares wrote: > Lou: > > I am clear that Juergen does not want not want to place transport = requirements within the data model for NETMOD. His opinion was = considered in the rough for the I2RS WG. If this requirement is a = problem for NETCONF/NETMOD, the text currently says: > > REQ-SEC-09 states: > > The default mode of transport is secure so data models SHOULD = clearly annotate what data nodes can be > passed over an insecure connection. > > However, if this means the NETCONF/NETMOD WG will not even entertain = proposal for marking the insecure functions in yang text -- then the two = WG (I2RS/NETMOD) have a problem and should stop this standardization = process going forward. > > Sue > > > -----Original Message----- > From: Lou Berger [mailto:lberger@labn.net] > Sent: Friday, August 19, 2016 7:34 AM > To: Susan Hares; 'Juergen Schoenwaelder' > Cc: i2rs@ietf.org; 'Alissa Cooper'; i2rs-chairs@ietf.org; 'Kathleen = Moriarty'; 'IESG'; jhaas@pfrc.org; '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) > > Sue, > > I don't see Juergen as arguing against model access via non-secure = transport. I read his point as that the transport security requirements = don't belong scattered within a data model. > > I have to say that from a model complexity (definition, process, = review, implementation - take your pick) , language and NETMOD co-chair = perspective, his comment resonates with me. > > I think this makes the key text: > > The default mode of transport is > secure so data models SHOULD clearly annotate what data nodes can = be > passed over an insecure connection. > > > As this isn't a MUST, I personally think we can live with the text and = we can debate the issue further in the context of specific solutions. I = would strongly object to this being changed to a MUST, or if the = document is changed to make transport (security) requirements identified = within data models a requirement. > > Lou > > On 8/19/2016 6:49 AM, Susan Hares wrote: >> Juergen: >> >> You have laid out the two options: a) link the data-model to the = non-secure transport, and b) do not link the data to the non-secure = transport. I agree with you that past models did not link past SNMP = MIB data model to the transport. Existing NETCONF models do not link it = to the transport. As you have indicated, you disagreed in the I2RS WG = and we found consensus was to include the non-secure transport. >> >> I2RS was created to build things as an interface to the routing = environment. The operators clearly informed the I2RS group of this = need during the requirement setting phase prior to the time I was chair. = The reason I continue to press for this capability is their input, and = the existing use cases I listed previously in this mail: >> >> a) public information - BGP route views, >> b) specific well know up events - such as public-web site up >> c) specific network service events - interface to particular public = LAN up. >> >> As you know, we do not have any I2RS data models that specify this = feature at this time. I suspect after we get through this lengthy = requirement phase, the operators may begin to specify new models that = have this feature. >> >> Sue >> >> -----Original Message----- >> From: Juergen Schoenwaelder >> [mailto:j.schoenwaelder@jacobs-university.de] >> Sent: Friday, August 19, 2016 4:58 AM >> To: Susan Hares >> Cc: 'Alissa Cooper'; 'Joel Halpern'; i2rs@ietf.org; >> i2rs-chairs@ietf.org; 'Kathleen Moriarty'; 'IESG'; jhaas@pfrc.org; >> 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) >> >> I repeat my technical argument: While there may be deployments where = non-secure transports may be reasonable to use, defining these = situations statically as part of data model schemas does not follow = established practices. The IETF has a long tradition of standardizing = data models that can be used in a variety of operational contexts and I = do not see reasons why we should move away from that basic approach. >> >> /js >> >> On Thu, Aug 18, 2016 at 02:35:03PM -0400, Susan Hares wrote: >>> Alissa: >>> >>> Just a little input you may not know. My background is 15 years = (1995-2010) developing a routing/switching platform (denoted as GateD) = which was sold to over 200 companies. We developed XML and a binary = XML based product that configured this product. It could do 100K = configuration lines and reboot in less than a second on most hardware. = We also provide status messages in secure streams and non-secure = streams. I sold early version of this code to companies that Alia has = worked for - so she has personal viewed the code. At the height of = our work, our development team ran to 50 people which I directed (First = as VP of Engineering, and then as CTO). It is due to this level of = experience that Alia selected me for the co-chair. Russ White has = understood Cisco's process, and has also directed software development = teams for routing. >>> >>> In order to freshen my direct experience with I2RS on open source = work, I am working on a publically available work in Quagga based on the = confD product suggested by Cisco. >>> >>> In contrast, Juergen is a university professor who has worked on = proto-types. He is not working on an implementation. I hope he will. >>> >>> I hope you will consider this background in my response to your = comments below. >>> >>> Sue >>> >>> >>> -----Original Message----- >>> From: Alissa Cooper [mailto:alissa@cooperw.in] >>> Sent: Thursday, August 18, 2016 12:54 PM >>> To: Joel Halpern >>> Cc: Susan Hares; Juergen Schoenwaelder; i2rs@ietf.org; >>> i2rs-chairs@ietf.org; Kathleen Moriarty; IESG; jhaas@pfrc.org; >>> 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) >>> >>> Jumping in here because this is relevant to my DISCUSS, hope nobody = minds (but if you do, I can go back to the other thread). >>> >>>>> On Aug 18, 2016, at 10:30 AM, Joel Halpern = wrote: >>>>> >>>>> Let me try a different take approach to this particular question. >>>>> >>>>> Let me start by putting aside the question of where things are = marked, and come back to that afterwards. >>>>> >>>>> There are a number of cases that I2RS has been asked to cover of = high rate telemetry data. This may be BGP update information, it may be = frequent information about line card activity. There are other cases, = some of which have been documented. >>>>> >>>>> While not completely insensitive, the operators have made clear = that they see protecting this data as unnecessary. While I would hope = over time to move to a domain where all of it is protect, that is not = trivial. As the I2RS Architecture points out, it is expected that what = we describe as a single I2RS >communication between a client and agent = is actually associated with multiple channels of communication. >>>>> >>>>> Now, if you want to say that the I2RS protocol requirements cannot = allow for unprotected channels, I guess we have disconnect between the = IESG and the WG. >>>>> >>>>> If we say that we can allow for unprotected channels, we then get = to the question of which data can be sent over such channels. While = architecturally I agree with Juergen that the model is a bad place to = specify it, the obverse is also true. Not having some limits on what = can be sent unprotected >causes concern about insufficient protection. = If I recall correctly, earlier security reviews called us to task for = being too broad in what we allowed. >>>>> >>>>> So, if the IESG wants us to just allow it anywhere, because the >>>>> model is an awkward place to define the limitation, I can live = with that. What I can't live with is being told both that the model is = a bad place to define it and that there must be restrictions on what is = sent unprotected, without any proposal on how we are to move forward. >>>> Thank you Joel, this explanation helps me a lot. I think there is a = disconnect about how the restrictions are expressed. From reading the = email traffic about this document, it strikes me that trying to express = the restrictions programmatically doesn=E2=80=99t make much sense in = this case. >>>> I agree with Juergen that it will be challenging to make a judgment = a priori in order to bake a restriction into a data model, because data = that is considered sensitive enough to warrant a secure transport in one = deployment may not be considered sensitive in another deployment. >>>> So for any data elements where there is any question at all about >>>> whether they might be sensitive (i.e., any data elements that are = not already routinely made public), I would expect data model authors to = end up indicating that they may be sent over either secure or insecure = transport, which renders the indication not useful. >>>> Perhaps it would make more sense then to just enumerate in the text = the cases that motivate the inclusion of protocol support for insecure = transport: >>>> >>>> 1. For conveyance of information that is already routinely made = public. >>>> 2. For line card activity data where there is no likely upgrade = path to support secure transports in the foreseeable future. >>>> >>>> Then the normative requirements would be on clients and agents to = use secure transports unless those clients and agents are deployed where = either of the operational circumstances above necessitate otherwise. >>>> Alissa >>> Point 1: >>> I disagree with Juergen on the difficulty in specifying the sections = of the yang modules. I have provided a suggested solution in: >>> = https://tools.ietf.org/html/draft-hares-i2rs-protocol-strawman-03#section= -4.5.2. >>> >>> Given the mount schema functionality, we can mount ephemeral state = module which augment non-ephemeral state modules which are "in-secure = only". >>> >>> Point 2: >>> I am willing to put an enumeration of the use cases in the protocol = requirement, but I would like to understand the purpose for the = enumeration. We are not doing a use case, but a requirements document. = This information appears to be a "use case" rather than a technical = description. What purpose are you looking for this enumeration to = server. Are you looking for the enumeration in SEC-REQ-08? >>> >>> Point 3: Could you review -08.txt on this topic, especially the text = below. Given your comments, I believe I should change the last line to = a MUST. >>> New/ The default mode of transport is >>> secure so data models MUST clearly annotate what data nodes can = be >>> passed over an insecure connection. >>> / >>> >>> Sue >>> >>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>> As to the normative requirements (-08.txt) version: >>> >>> Section 3: >>> >>> I2RS allows the use of an insecure transport for portions of data >>> models that clearly indicate the use of an insecure transport. >>> Operators deploying I2RS must determine if they want to populate = and >>> deploy the portions of the data model which use insecure = transports. >>> >>> In Section 3.2 in version -08.txt >>> >>> SEC-REQ-08: The I2RS protocol MUST be able to transfer data over = a >>> secure transport and optionally MAY be able to transfer data over = a >>> non-secure transport. A secure transport MUST provide data >>> confidentiality, data integrity, and replay prevention. >>> >>> The default I2RS transport is a secure transport. >>> >>> 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. >>> >>> The configuration of ephemeral data in the I2RS Agent by the I2RS >>> client SHOULD be done over a secure transport. It is anticipated >>> that the passing of most I2RS ephemeral state operational status >>> SHOULD be done over a secure transport. As >>> [I-D.ietf-i2rs-ephemeral-state] notes, a data model MUST = indicate >>> whether the transport exchanging the data between I2RS client and >>> I2RS agent is secure or insecure. >>> >>> The default mode of transport is >>> secure so data models SHOULD clearly annotate what data nodes can = be >>> passed over an insecure connection. >>> >>>> Yours, >>>> Joel >>>> >>>> -----Original Message----- >>>> From: Susan Hares [mailto:shares@ndzh.com] >>>> Sent: Thursday, August 18, 2016 9:17 AM >>>> To: 'Juergen Schoenwaelder' >>>> Cc: i2rs@ietf.org; i2rs-chairs@ietf.org; 'Kathleen Moriarty' >>>> ; 'The IESG' ; >>>> jhaas@pfrc.org; >>>> 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) >>>> >>>> Juergen and Kathleen: >>>> >>>> Let me proceed with two examples: BGP route views data model and = the event for the web-service data. >>>> >>>> The content of these data models are designated as exposed to = public. The routing system only populates the proposed BGP route views = data model with the data destined for the BGP looking glass. The policy = on the routing system indicates what information gets transferred. The = data model is completely available to the public. The Yang Doctors are = going to review this by seeing the whole model is public and available = via non-secure means. >>>> The security people are going to review this seeing that the whole = model is public, and available via an unprotect means. The fact the = data model is all public should simplify the review. >>>> >>>> An event from the I2RS RIB that a web-service route is up is the = second case. The I2RS RIB has an event based on policy that indicates a = web-service route is up. The yang-1.1 doctors must review the content = of the event text to see it does not break privacy or provide too much >>>> information The event mechanisms will need to work over secure = transport >>>> and insecure transport. Most of the data will go over the secure = transport event stream. However, a small amount of information may go = over the insecure transport stream. >>>> >>>> First, let me know if my use cases are understandable. Second, let = me know if you disagree with this use cases. >>>> >>>> Fyi - IESG approved the architecture with the insecure stream. >>>> >>>> Sue >>>> >>>> -----Original Message----- >>>> From: Juergen Schoenwaelder >>>> [mailto:j.schoenwaelder@jacobs-university.de] >>>> Sent: Thursday, August 18, 2016 9:06 AM >>>> To: Susan Hares >>>> Cc: i2rs@ietf.org; i2rs-chairs@ietf.org; 'Kathleen Moriarty'; 'The >>>> IESG'; jhaas@pfrc.org; >>>> 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) >>>> >>>> I just do not know on which basis a data model writer can decide = whether a data object can be exposed in an unprotected way. How are YANG = doctors going to review this? How are security directorate people going = to judge this? But as promised, I leave (still puzzled) now. >>>> >>>> /js >>>> >>>> On Thu, Aug 18, 2016 at 09:00:14AM -0400, Susan Hares wrote: >>>>> Juergen: >>>>> >>>>> Yes, we seem to disagree on the value of making it hardwired in = the model. >>>>> For me, the value is a common understanding of deployment >>>>> distribution >>>> such >>>>> as the route-views. Since the operators argued strongly for this = point, >>>> I >>>>> think the best idea is to get it working in code and then see if >>>>> the deployment matches the requests. >>>>> >>>>> Sue >>>>> >>>>> -----Original Message----- >>>>> From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Juergen >>>>> Schoenwaelder >>>>> Sent: Thursday, August 18, 2016 8:14 AM >>>>> To: Susan Hares >>>>> Cc: i2rs@ietf.org; i2rs-chairs@ietf.org; 'Kathleen Moriarty'; 'The >>>>> IESG'; jhaas@pfrc.org; >>>>> 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) >>>>> >>>>> Sue, >>>>> >>>>> I still do not see why the 'mode of exposure' of data benefits = from >>>>> being hard-wired in the data model. For me, it is a situational = and >>>>> deployment specific question. But I shut up here since I aired = this >>>>> concern before (and we simply seem to disagree). >>>>> >>>>> /js >>>>> >>>>> On Thu, Aug 18, 2016 at 08:07:18AM -0400, Susan Hares wrote: >>>>>> Juergen: >>>>>> >>>>>> My example is the looking glass servers for the BGP route views >>>>>> project >>>>>> (http://www.routeviews.org/) or a route indicating the presence = of a >>>>>> web-server that is public. For the BGP I2RS route, a yang model = could >>>>>> replace the looking glass function, and provide events for these = looking >>>>>> glass functions. For the web-server route, an event be sent = when >>>> that >>>>>> one route is added. >>>>>> >>>>>> Sue >>>>>> >>>>>> >>>>>> -----Original Message----- >>>>>> From: Juergen Schoenwaelder >>>>>> [mailto:j.schoenwaelder@jacobs-university.de] >>>>>> Sent: Thursday, August 18, 2016 3:32 AM >>>>>> To: Susan Hares >>>>>> Cc: 'Kathleen Moriarty'; 'The IESG'; jhaas@pfrc.org; >>>>>> i2rs@ietf.org; i2rs-chairs@ietf.org; >>>>>> 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 Wed, Aug 17, 2016 at 09:16:48PM -0400, Susan Hares wrote: >>>>>>> = ----------------------------------------------------------------- >>>>>>> - >>>>>>> -- >>>>>>> -- >>>>>>> COMMENT: >>>>>>> = ----------------------------------------------------------------- >>>>>>> - >>>>>>> -- >>>>>>> -- >>>>>>> >>>>>>>> Section 3: >>>>>>>> Can you clarify the second to last sentence? Do you mean there >>>>>>>> are >>>>>> sections that indicate an insecure transport should be used? >>>>>>>> I2RS allows the use of an >>>>>>>> insecure transport for portions of data models that clearly >>>>>>>> indicate insecure transport. >>>>>>>> Perhaps: >>>>>>>> I2RS allows the use of an >>>>>>>> insecure transport for portions of data models that clearly >>>>>>>> indicate the use of an insecure transport. >>>>>> I still wonder how a data model writer can reasonably decide >>>>>> whether a piece of information can be shipped safely over an >>>>>> insecure transport since this decision often depends on the >>>>>> specifics of a deployment >>>>> situation. >>>>>> /js >>>>>> >>>>>> PS: I hope we do not end up with defining data multiple times = (once >>>>>> for insecure transport and once for secured transports). >>>>>> >>>>>> -- >>>>>> Juergen Schoenwaelder Jacobs University Bremen gGmbH >>>>>> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | = Germany >>>>>> Fax: +49 421 200 3103 = >>>>>> >>>>>> _______________________________________________ >>>>>> i2rs mailing list >>>>>> i2rs@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/i2rs >>>>> -- >>>>> Juergen Schoenwaelder Jacobs University Bremen gGmbH >>>>> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | = Germany >>>>> Fax: +49 421 200 3103 >>>>> >>>>> _______________________________________________ >>>>> i2rs mailing list >>>>> i2rs@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/i2rs >>>>> >>>> -- >>>> Juergen Schoenwaelder Jacobs University Bremen gGmbH >>>> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | = Germany >>>> Fax: +49 421 200 3103 >>>> > > > _______________________________________________ i2rs mailing list i2rs@ietf.org https://www.ietf.org/mailman/listinfo/i2rs =20 ------=_NextPart_000_0016_01D1FA0E.BFC43C90 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Andy:

 

I have been thinking about your question for 30 minutes.=C2=A0=C2=A0 = Let me put down a few of my personal opinions:

=C2=A0

1)      = Most (99%) of the ephemeral data models will not allow non-secure = transport.

2)      = =C2=A0If any ephemeral data models have an insecure section, the = review and consensus for a standards model should take longer. =

I hope we can streamline the normal Yang model review.=C2=A0 [It = would be nice to streamline features additions for NETCONF/RESTCONF as = well]. =C2=A0

 

3)      = I prefer to have the non-secure sections of a data model moved to a = separate date model, and the data model marked as insecure. = =C2=A0

[I do not know if we could use the library function to mark the data = model in meta-language.]

However, until we complete the mount schema work =E2=80=93 I do not = know if this is workable.

 

Would it help if I changed version -08 to

Old/

=C2=A0=C2=A0 A non-secure transport can be used for = publishing telemetry data or

=C2=A0=C2=A0 other operational state that was = specifically indicated to non-

=C2=A0=C2=A0 confidential in the data model in the = Yang syntax. /

New:/

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 A non-secure transport can be used for = publishing telemetry data or other

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0Operational state that was specifically = indicated to be non-confidential in the data = model.

=C2=A0=C2=A0=C2=A0 /

 

Sue

 

 

From:= = i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Susan = Hares
Sent: Friday, August 19, 2016 10:59 AM
To: = 'Andy Bierman'; 'Lou Berger'
Cc: i2rs@ietf.org; 'Alissa = Cooper'; 'Juergen Schoenwaelder'; 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)

 

Andy:

 

Thank you for your comments.   Perhaps you can provide for = the IESG the list of things that are needed to move a Yang module = forward in the IETF.  

 

Sue

 

From:= = Andy Bierman [mailto:andy@yumaworks.com] =
Sent: Friday, August 19, 2016 10:24 AM
To: Lou = Berger
Cc: Susan Hares; Juergen Schoenwaelder; i2rs@ietf.org; Alissa Cooper; i2rs-chairs@ietf.org; Kathleen = Moriarty; IESG; Jeffrey Haas; Joel Halpern; d= raft-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)

 

Hi,

 

I = agree with Juergen.

There = are already too many details that need consensus to = move

a YANG module forward = in the IETF.  It takes too long = already.

 

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?

 

Standardized insecure access is a big change from what = we have done

for 30 = years.  There could be a good reason why we left this out of = scope

all this = time.

 

 

Andy

 

 

On Fri, = Aug 19, 2016 at 5:20 AM, Lou Berger <lberger@labn.net> wrote:


Sue,

My message said three = things:

1) Juergen's comment resonates with me.

2) I think = the current text is acceptable.

3) I see changing the SHOULD to a = MUST as problematic.
I understood one of the other messages on this = thread proposing this
change which is what triggered my = message.   If I misunderstood that
message, feel free to = interpret my message as supporting the current
text in = question.

Note that I am only speaking for myself (including in = my role as NETMOD
co-chair) and not representing the consensus = opinion of any WG.

Lou
On 8/19/2016 8:07 AM, Susan Hares = wrote:
> Lou:
>
> I am clear that Juergen does not = want not want to place transport requirements within the data model for = NETMOD.  His opinion was considered in the rough for the I2RS WG. = If this requirement is a problem for NETCONF/NETMOD,  the text = currently says:
>
> REQ-SEC-09 states:
>
>  =  The default mode of transport is secure so data models SHOULD = clearly annotate what data nodes can be
>    passed over = an insecure connection.
>
> However, if this means the = NETCONF/NETMOD WG will not even entertain proposal for marking the = insecure functions in yang text -- then the two WG (I2RS/NETMOD) have a = problem and should stop this standardization process going = forward.
>
> Sue
>
>
> -----Original = Message-----
> From: Lou Berger [mailto:lberger@labn.net]
> Sent: = Friday, August 19, 2016 7:34 AM
> To: Susan Hares; 'Juergen = Schoenwaelder'
> Cc: i2rs@ietf.org; 'Alissa Cooper'; i2rs-chairs@ietf.org; 'Kathleen = Moriarty'; 'IESG'; jhaas@pfrc.org; = 'Joel Halpern'; d= raft-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)
>
> Sue,
>
>     I don't = see Juergen as arguing against model access via non-secure transport. I = read his point as that the transport security requirements don't belong = scattered within a data model.
>
> I have to say that from a = model complexity (definition, process, review, implementation - take = your pick) , language and NETMOD co-chair perspective, his comment = resonates with me.
>
> I think this makes the key = text:
>
>    The default mode of transport = is
>    secure so data models SHOULD clearly annotate = what data nodes can be
>    passed over an insecure = connection.
>
>
> As this isn't a MUST, I personally = think we can live with the text and we can debate the issue further in = the context of specific solutions.  I would strongly object to this = being changed to a MUST, or if the document is changed to make transport = (security) requirements identified within data models a = requirement.
>
> Lou
>
> On 8/19/2016 6:49 AM, = Susan Hares wrote:
>> Juergen:
>>
>> You have = laid out the two options:   a) link the data-model to the = non-secure transport, and b) do not link the data to the non-secure = transport.   I agree with you that past models did not link = past SNMP MIB data model to the transport.  Existing NETCONF models = do not link it to the transport.   As you have indicated, you = disagreed in the I2RS WG and we found consensus was to include the = non-secure transport.
>>
>> I2RS was created to build = things as an interface to the routing environment.   The = operators clearly informed the I2RS group of this need during the = requirement setting phase prior to the time I was chair.  The = reason I continue to press for this capability is their input, and the = existing use cases I listed previously in this = mail:
>>
>> a) public information - BGP route = views,
>> b) specific well know up events - such as public-web = site up
>> c) specific network service events - interface to = particular public LAN up.
>>
>> As you know, we do not = have any I2RS data models that specify this feature at this time.  =  I suspect after we get through this lengthy requirement phase, the = operators may begin to specify new models that have this = feature.
>>
>> Sue
>>
>> = -----Original Message-----
>> From: Juergen = Schoenwaelder
>> [mailto:j.schoenwaelder@jaco= bs-university.de]
>> Sent: Friday, August 19, 2016 4:58 = AM
>> To: Susan Hares
>> Cc: 'Alissa Cooper'; 'Joel = Halpern'; i2rs@ietf.org;
>> i2rs-chairs@ietf.org; 'Kathleen = Moriarty'; 'IESG'; jhaas@pfrc.org;
>> d= raft-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)
>>
>> I repeat my technical = argument: While there may be deployments where non-secure transports may = be reasonable to use, defining these situations statically as part of = data model schemas does not follow established practices. The IETF has a = long tradition of standardizing data models that can be used in a = variety of operational contexts and I do not see reasons why we should = move away from that basic approach.
>>
>> = /js
>>
>> On Thu, Aug 18, 2016 at 02:35:03PM -0400, = Susan Hares wrote:
>>> = Alissa:
>>>
>>> Just a little input you may not = know.  My background is 15 years (1995-2010)  developing a = routing/switching platform (denoted as GateD) which was sold to over 200 = companies.   We developed XML and a binary XML based product = that configured this product.  It could do 100K configuration lines = and reboot in less than a second on most hardware.  We also provide = status messages in secure streams and non-secure streams.    I = sold early version of this code to companies that Alia has worked = for  - so she has personal viewed the code.   At the = height of our work, our development team ran to 50 people which I = directed (First as VP of Engineering, and then as CTO). It is due to = this level of experience that Alia selected me for the co-chair.  =  Russ White has understood Cisco's process, and has also directed = software development teams for routing.
>>>
>>> = In order to freshen my direct experience with I2RS on open source work, = I am working on a publically available work in Quagga based on the confD = product suggested by Cisco.
>>>
>>> In contrast, = Juergen is a university professor who has worked on proto-types.  =  He is not working on an implementation.   I hope he = will.
>>>
>>> I hope you will consider this = background in my response to your comments = below.
>>>
>>> = Sue
>>>
>>>
>>> -----Original = Message-----
>>> From: Alissa Cooper [mailto:alissa@cooperw.in]
>>> = Sent: Thursday, August 18, 2016 12:54 PM
>>> To: Joel = Halpern
>>> Cc: Susan Hares; Juergen Schoenwaelder; i2rs@ietf.org;
>>> i2rs-chairs@ietf.org; Kathleen = Moriarty; IESG; jhaas@pfrc.org;
>>> d= raft-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)
>>>
>>> Jumping in = here because this is relevant to my DISCUSS, hope nobody minds (but if = you do, I can go back to the other = thread).
>>>
>>>>> On Aug 18, 2016, at = 10:30 AM, Joel Halpern <joel.halpern@ericsson.com&g= t; wrote:
>>>>>
>>>>> Let me try a = different take approach to this particular = question.
>>>>>
>>>>> Let me start = by putting aside the question of where things are marked, and come back = to that afterwards.
>>>>>
>>>>> = There are a number of cases that I2RS has been asked to cover of high = rate telemetry data.  This may be BGP update information, it may be = frequent information about line card activity.  There are other = cases, some of which have been = documented.
>>>>>
>>>>> While not = completely insensitive, the operators have made clear that they see = protecting this data as unnecessary.  While I would hope over time = to move to a domain where all of it is protect, that is not = trivial.  As the I2RS Architecture points out, it is expected that = what we describe as a single I2RS >communication between a client and = agent is actually associated with multiple channels of = communication.
>>>>>
>>>>> Now, if = you want to say that the I2RS protocol requirements cannot allow for = unprotected channels, I guess we have disconnect between the IESG and = the WG.
>>>>>
>>>>> If we say that = we can allow for unprotected channels, we then get to the question of = which data can be sent over such channels.  While architecturally I = agree with Juergen that the model is a bad place to specify it, the = obverse is also true.  Not having some limits on what can be sent = unprotected >causes concern about insufficient protection.  If I = recall correctly, earlier security reviews called us to task for being = too broad in what we = allowed.
>>>>>
>>>>> So, if the IESG = wants us to just allow it anywhere, because the
>>>>> = model is an awkward place to define the limitation, I can live with = that.  What I can't live with is being told both that the model is = a bad place to define it and that there must be restrictions on what is = sent unprotected, without any proposal on how we are to move = forward.
>>>> Thank you Joel, this explanation helps me a = lot. I think there is a disconnect about how the restrictions are = expressed. From reading the email traffic about this document, it = strikes me that trying to express the restrictions programmatically = doesn=E2=80=99t make much sense in this case.
>>>> I = agree with Juergen that it will be challenging to make a judgment a = priori in order to bake a restriction into a data model, because data = that is considered sensitive enough to warrant a secure transport in one = deployment may not be considered sensitive in another = deployment.
>>>> So for any data elements where there is = any question at all about
>>>> whether they might be = sensitive (i.e., any data elements that are not already routinely made = public), I would expect data model authors to end up indicating that = they may be sent over either secure or insecure transport, which renders = the indication not useful.
>>>> Perhaps it would make = more sense then to just enumerate in the text the cases that motivate = the inclusion of protocol support for insecure = transport:
>>>>
>>>> 1. For conveyance of = information that is already routinely made public.
>>>> = 2. For line card activity data where there is no likely upgrade path to = support secure transports in the foreseeable = future.
>>>>
>>>> Then the normative = requirements would be on clients and agents to use secure transports = unless those clients and agents are deployed where either of the = operational circumstances above necessitate = otherwise.
>>>> Alissa
>>> Point = 1:
>>> I disagree with Juergen on the difficulty in = specifying the sections of the yang modules.  I have provided a = suggested solution in:
>>> https://tools.ietf.org/html/draft-hares-i2rs-protocol-s= trawman-03#section-4.5.2.
>>>
>>> Given the = mount schema functionality, we can mount ephemeral state module which = augment non-ephemeral state modules which are "in-secure = only".
>>>
>>> Point 2:
>>> I = am willing to put an enumeration of the use cases in the protocol = requirement, but I would like to understand the purpose for the = enumeration.   We are not doing a use case, but a requirements = document.  This information appears to be a "use case" = rather than a technical description.   What purpose are you = looking for this enumeration to server.  Are you looking for the = enumeration in SEC-REQ-08?
>>>
>>> Point 3: = Could you review -08.txt on this topic, especially the text below.  = Given your comments, I believe I should change the last line to a = MUST.
>>> New/   The default mode of transport = is
>>>    secure so data models MUST clearly = annotate what data nodes can be
>>>    passed over = an insecure connection.
>>> = /
>>>
>>> Sue
>>>
>>> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>>>= As to the normative requirements (-08.txt) = version:
>>>
>>> Section = 3:
>>>
>>>    I2RS allows the use of = an insecure transport for portions of data
>>>    = models that clearly indicate the use of an insecure = transport.
>>>    Operators deploying I2RS must = determine if they want to populate and
>>>    = deploy the portions of the data model which use insecure = transports.
>>>
>>> In Section 3.2 in version = -08.txt
>>>
>>>    SEC-REQ-08: The = I2RS protocol MUST be able to transfer data over a
>>>  =   secure transport and optionally MAY be able to transfer data over = a
>>>    non-secure transport.  A secure = transport MUST provide data
>>>    = confidentiality, data integrity, and replay = prevention.
>>>
>>>    The default = I2RS transport is a secure = transport.
>>>
>>>    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.
>>>
>>>    The configuration = of ephemeral data in the I2RS Agent by the I2RS
>>>  =   client SHOULD be done over a secure transport.  It is = anticipated
>>>    that the passing of most I2RS = ephemeral state operational status
>>>    SHOULD = be done over a secure transport.  As
>>>    = [I-D.ietf-i2rs-ephemeral-state] notes,  a data model MUST = indicate
>>>    whether the transport exchanging = the data between I2RS client and
>>>    I2RS agent = is secure or insecure.
>>>
>>>    The = default mode of transport is
>>>    secure so data = models SHOULD clearly annotate what data nodes can = be
>>>    passed over an insecure = connection.
>>>
>>>> = Yours,
>>>> Joel
>>>>
>>>> = -----Original Message-----
>>>> From: Susan Hares = [mailto:shares@ndzh.com]
>>>> = Sent: Thursday, August 18, 2016 9:17 AM
>>>> To: 'Juergen = Schoenwaelder' <j.schoenwaelder@jaco= bs-university.de>
>>>> Cc: i2rs@ietf.org; i2rs-chairs@ietf.org; 'Kathleen = Moriarty'
>>>> <Kathleen.Moriarty.ietf@g= mail.com>; 'The IESG' <iesg@ietf.org>;
>>>> = jhaas@pfrc.org;
>>>> = d= raft-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)
>>>>
>>>> = Juergen and Kathleen:
>>>>
>>>> Let me = proceed with two examples: BGP route views data model and the event for = the web-service data.
>>>>
>>>> The = content of these data models are designated as exposed to public.  = The routing system only populates the proposed BGP route views data = model with the data destined for the BGP looking glass.  The policy = on the routing system indicates what information gets transferred.  = The data model is completely available to the public.  The Yang = Doctors are going to review this by seeing the whole model is public and = available via non-secure means.
>>>> The security people = are going to review this seeing that the whole model is public, and = available via an unprotect means.  The fact the data model is all = public should simplify the = review.
>>>>
>>>> An event from the I2RS = RIB that a web-service route is up is the second case.  The I2RS = RIB has an event based on policy that indicates a web-service route is = up.  The yang-1.1 doctors must review the content of the event text = to see it does not break privacy or provide too much
>>>> = information   The event mechanisms will need to work over = secure transport
>>>> and insecure transport.  Most = of the data will go over the secure transport event stream. However, a = small amount of information may go over the insecure transport = stream.
>>>>
>>>> First, let me know if my = use cases are understandable.  Second, let me know if you disagree = with this use cases.
>>>>
>>>> Fyi -  = IESG approved the architecture with the insecure = stream.
>>>>
>>>> = Sue
>>>>
>>>> -----Original = Message-----
>>>> From: Juergen = Schoenwaelder
>>>> [mailto:j.schoenwaelder@jaco= bs-university.de]
>>>> Sent: Thursday, August 18, = 2016 9:06 AM
>>>> To: Susan Hares
>>>> Cc: = i2rs@ietf.org; i2rs-chairs@ietf.org; 'Kathleen = Moriarty'; 'The
>>>> IESG'; jhaas@pfrc.org;
>>>> = d= raft-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)
>>>>
>>>> = I just do not know on which basis a data model writer can decide whether = a data object can be exposed in an unprotected way. How are YANG doctors = going to review this? How are security directorate people going to judge = this? But as promised, I leave (still puzzled) = now.
>>>>
>>>> = /js
>>>>
>>>> On Thu, Aug 18, 2016 at = 09:00:14AM -0400, Susan Hares wrote:
>>>>> = Juergen:
>>>>>
>>>>> Yes, we seem to = disagree on the value of making it hardwired in the = model.
>>>>> For me, the value is a common = understanding of deployment
>>>>> = distribution
>>>> such
>>>>> as the = route-views.   Since the operators argued strongly for this = point,
>>>> I
>>>>> think the best idea = is to get it working in code and then see if
>>>>> the = deployment matches the = requests.
>>>>>
>>>>> = Sue
>>>>>
>>>>> -----Original = Message-----
>>>>> From: i2rs [mailto:i2rs-bounces@ietf.org] On = Behalf Of Juergen
>>>>> = Schoenwaelder
>>>>> Sent: Thursday, August 18, 2016 = 8:14 AM
>>>>> To: Susan Hares
>>>>> = Cc: i2rs@ietf.org; i2rs-chairs@ietf.org; 'Kathleen = Moriarty'; 'The
>>>>> IESG'; jhaas@pfrc.org;
>>>>>= ; d= raft-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)
>>>>>
>>>>> = Sue,
>>>>>
>>>>> I still do not see = why the 'mode of exposure' of data benefits from
>>>>> = being hard-wired in the data model. For me, it is a situational = and
>>>>> deployment specific question. But I shut up = here since I aired this
>>>>> concern before (and we = simply seem to = disagree).
>>>>>
>>>>> = /js
>>>>>
>>>>> On Thu, Aug 18, 2016 = at 08:07:18AM -0400, Susan Hares wrote:
>>>>>> = Juergen:
>>>>>>
>>>>>> My = example is the looking glass servers for the BGP route = views
>>>>>> project
>>>>>> = (http://www.routeviews.org/) or a route indicating = the presence of a
>>>>>> web-server that is = public.   For the BGP I2RS route, a yang model = could
>>>>>> replace the looking glass function, = and provide events for these looking
>>>>>> glass = functions.    For the web-server route,  an event be sent = when
>>>> that
>>>>>> one route is = added.
>>>>>>
>>>>>> = Sue
>>>>>>
>>>>>>
>>&g= t;>>> -----Original Message-----
>>>>>> = From: Juergen Schoenwaelder
>>>>>> [mailto:j.schoenwaelder@jaco= bs-university.de]
>>>>>> Sent: Thursday, August = 18, 2016 3:32 AM
>>>>>> To: Susan = Hares
>>>>>> Cc: 'Kathleen Moriarty'; 'The IESG'; = jhaas@pfrc.org;
>>>>>= ;> i2rs@ietf.org; i2rs-chairs@ietf.org;
>>= ;>>>> d= raft-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 Wed, = Aug 17, 2016 at 09:16:48PM -0400, Susan Hares = wrote:
>>>>>>> = -----------------------------------------------------------------
>= >>>>>> -
>>>>>>> = --
>>>>>>> --
>>>>>>> = COMMENT:
>>>>>>> = -----------------------------------------------------------------
>= >>>>>> -
>>>>>>> = --
>>>>>>> = --
>>>>>>>
>>>>>>>> = Section 3:
>>>>>>>> Can you clarify the = second to last sentence?  Do you mean = there
>>>>>>>> = are
>>>>>> sections that indicate an insecure = transport should be used?
>>>>>>>>  I2RS = allows the use of an
>>>>>>>> insecure = transport for portions of data models that = clearly
>>>>>>>> indicate  insecure = transport.
>>>>>>>> = Perhaps:
>>>>>>>> I2RS allows the use of = an
>>>>>>>> insecure transport for portions = of data models that clearly
>>>>>>>> indicate = the use of an  insecure transport.
>>>>>> I = still wonder how a data model writer can reasonably = decide
>>>>>> whether a piece of information can be = shipped safely over an
>>>>>> insecure transport = since this decision often depends on the
>>>>>> = specifics of a deployment
>>>>> = situation.
>>>>>> = /js
>>>>>>
>>>>>> PS: I hope = we do not end up with defining data multiple times = (once
>>>>>>    for insecure transport = and once for secured = transports).
>>>>>>
>>>>>> = --
>>>>>> 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/>
>>>= ;>>>
>>>>>> = _______________________________________________
>>>>>&g= t; i2rs mailing list
>>>>>> i2rs@ietf.org
>>>>>&g= t; https://www.ietf.org/mailman/listinfo/i2rs
>&= gt;>>> --
>>>>> 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/>
>>>= ;>>
>>>>> = _______________________________________________
>>>>> = i2rs mailing list
>>>>> i2rs@ietf.org
>>>>> = https://www.ietf.org/mailman/listinfo/i2rs
>&= gt;>>>
>>>> --
>>>> 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/>
>>>= ;>
>
>
>


________________________________= _______________
i2rs mailing list
i2rs@ietf.org
https://www.ietf.org/mailman/listinfo/i2rs

 

------=_NextPart_000_0016_01D1FA0E.BFC43C90-- From nobody Fri Aug 19 09:07:16 2016 Return-Path: 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 3FA9D12D53B; Fri, 19 Aug 2016 09:02:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.738 X-Spam-Level: * X-Spam-Status: No, score=1.738 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, RDNS_NONE=0.793] autolearn=no 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 gLrvJkHbDWPX; Fri, 19 Aug 2016 09:02:21 -0700 (PDT) Received: from hickoryhill-consulting.com (unknown [50.245.122.97]) (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 BFA3D12B04C; Fri, 19 Aug 2016 09:02:20 -0700 (PDT) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=184.157.82.170; From: "Susan Hares" To: "'Kathleen Moriarty'" References: <147146974235.23784.4389421535496134619.idtracker@ietfa.amsl.com> <013b01d1f8ee$31fa09b0$95ee1d10$@ndzh.com> <20160818073203.GA4338@elstar.local> <04b501d1f949$116c63e0$34452ba0$@ndzh.com> <20160818121405.GA5282@elstar.local> <051301d1f950$7739c670$65ad5350$@ndzh.com> <20160818130555.GA5366@elstar.local> <051701d1f952$c4ae0b30$4e0a2190$@ndzh.com> <6BCE198E4EAEFC4CAB45D75826EFB0761525CCD7@eusaamb101.ericsson.se> <003801d1f97f$3d16eb10$b744c130$@ndzh.com> <00dc01d1f988$f2cec280$d86c4780$@ndzh.com> <02b201d1fa1c$620e07d0$262a1770$@ndzh.com> <037501d1fa2a$a970fde0$fc52f9a0$@ndzh.com> In-Reply-To: Date: Fri, 19 Aug 2016 12:01:02 -0400 Message-ID: <004d01d1fa32$e30d3f20$a927bd60$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIa7Lz6VgZw6h2A0uGNzOgAA2Ic8QJ/RF5yARxv/coCD6d0AAIDKkFTAYlI9/gCaK/wXAMksAaNAmoTFCQCp9Oi8AIQlOgDAIZjbI0CaGRfrQGPw5JeAjmooLUBU45vXAKYJpUpAop25V4CQIq52p6T0n8A Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: X-Mailman-Approved-At: Fri, 19 Aug 2016 09:07:15 -0700 Cc: i2rs@ietf.org, 'Alissa Cooper' , 'Juergen Schoenwaelder' , i2rs-chairs@ietf.org, 'Andy Bierman' , 'IESG' , 'Spencer Dawkins at IETF' , '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) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Aug 2016 16:02:23 -0000 Kathleen:=20 First of all, I agree software knobs can always be set to multiple = settings in vendor settings. These settings may expand beyond standard = models, and operators may set these knobs as they wish. =20 As a security person, do you really want a standardized knob that says = "run this model over non-secure transport"? I do not want non-secure = transport used for configuration and most operational status. Corrupted = data in the MGT plane can corrupt data traffic in the network. The bar = for non-secure transport has to be very high with lots of warnings. = Therefore an operator having a switch to change attribute (such as a = configuration attribute) from a secure transport to a non-secure = transport - should be discouraged. Yang 1.1 has three places to indicate:=20 1) Attribute - on the yang syntax on an attribute (leaf node or leaf = list), or portion of a schema,=20 2) model - meta-data on yang modules contained in library.=20 3) mount points - where multiple modules are mounted. =20 [Andy or Juergen may provide more details on meta-data on yang module = libraries. Lada or Lou can provide more details on mount points. ] Early in our discussion, NETCONF/NETMOD asked us to be specific in our = requirements. In the final discussion, we put Yang syntax so the level = could be attribute to provide the level of check you indicated. It = could go to any of these places if it works,.=20 Does this discussion help? Sue=20 -----Original Message----- From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Kathleen Moriarty Sent: Friday, August 19, 2016 11:27 AM To: Susan Hares Cc: i2rs@ietf.org; Alissa Cooper; Juergen Schoenwaelder; = i2rs-chairs@ietf.org; Andy Bierman; Spencer Dawkins at IETF; Jeffrey = Haas; Joel Halpern; = draft-ietf-i2rs-protocol-security-requirements@ietf.org; IESG 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 11:02 AM, Susan Hares wrote: > Spencer: > > > > Thank you for asking. The time it would take is the time to move the=20 > configuration knob to =E2=80=9Calways transport-secure=E2=80=9D for = this model. Why does the knob in the data model have to be set only one way? Couldn't an attribute be used that you could change the setting for that = attribute rather than update the entire YANG module or is that not = possible in YANG? Couldn't this be a setting? Thanks, Kathleen > > > > Sue > > > > From: Spencer Dawkins at IETF [mailto:spencerdawkins.ietf@gmail.com] > Sent: Friday, August 19, 2016 10:13 AM > To: Susan Hares > Cc: Andy Bierman; i2rs@ietf.org; Alissa Cooper; Juergen Schoenwaelder; = > i2rs-chairs@ietf.org; Kathleen Moriarty; IESG; Jeffrey Haas; Joel=20 > 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) > > > > Hi, Susan, > > > > On Fri, Aug 19, 2016 at 8:19 AM, Susan Hares wrote: > > Spencer: > > > > You as asking if: > > > > 1) Can Yang Models be revised? - there is a revision tag on the = Yang > model. > > 2) How long it takes to deploy revised models in the Internet, = and > old-models to be timed out? This is an operational question on yang = models > that no one has experience to determine. Andy suggest that the = deployment > time is 20 years (the Age of the Commercial internet =E2=80=93 1996 = -2016)=20 > rather than the age of the Internet (1987-2016). > > > > However, the real question you should have asked is: Can operators=20 > deploy models which are marked as =E2=80=9Cnon-secure = transport=E2=80=9D with a secure transport? > > > > I understood that part. My question was how long it would likely take=20 > them to switch to a secure transport if they had deployed a model with = > an insecure transport and figured out that was problematic. > > > > Thanks for the explanation. It was helpful. > > > > Spencer > > > > The answer is yes. In fact, several operators in I2RS stated that all = I2RS > protocol communication needed to be secure. Therefore, if the = people > found out that a model was problematic to be insecure =E2=80=93 = operators and=20 > vendors would simply turn the deployment knob switch that says = =E2=80=93=20 > deploy this always with a secure transport rather than optionally=20 > allow an insecure transport. > > > > Now, the real problem is if the IESG has been cycling on this concept = =E2=80=93 the > text needs to change. I=E2=80=99m going to go ahead and release a = version-09.txt > that tries to make this very clear. Please comment on that text to = help > make this clear. > > > > Sue > > > > > > From: Spencer Dawkins at IETF [mailto:spencerdawkins.ietf@gmail.com] > Sent: Friday, August 19, 2016 9:08 AM > To: Andy Bierman > Cc: Susan Hares; i2rs@ietf.org; Alissa Cooper; Juergen Schoenwaelder;=20 > i2rs-chairs@ietf.org; Kathleen Moriarty; IESG; Jeffrey Haas; Joel=20 > 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) > > > > Dear All, > > > > On Thu, Aug 18, 2016 at 3:02 PM, Andy Bierman = wrote: > > > > > > On Thu, Aug 18, 2016 at 12:44 PM, Susan Hares wrote: > > Andy: > > > > Thank you =E2=80=93 I thought it was on whether we could implement = insecure=20 > transport in a Yang module. > > > > The requirement text you are working with is: > > > > SEC-REQ-08: The I2RS protocol MUST be able to transfer data over a > secure transport and optionally MAY be able to transfer data over a > non-secure transport. > > > > I do not understand why approving the ok for non-secure transport for=20 > some modules means the following to you: > > > > =E2=80=9C the IETF needs to agree that there could never possibly be = any=20 > deployment that would not want to allow exposure of the data. > > Not now. Not 20 years from now.=E2=80=9D > > > > > > > > As I understand it, this requirement has another requirement=20 > associated with it > > that says the data has to be identified as OK-for-nonsecure-transport. > > > > An extension in the data model says that all instances of the object=20 > in > > all possible deployments cannot be considered sensistive and therefore > > needs disclosure protection. > > > > It may seem like even a simple octet counter is safe to send in the=20 > clear, > > but not if that opens up correlation attacks. (e.g., I can send data=20 > to some > > host. I can see that index 455992 is incrementing the in-octets=20 > counters > > in a way that strongly correlates to my test traffic. Therefore I can = > learn > > that arbitrary index 455992 is really John Doe or really suite #14, = etc. > > > > Since Kathleen asked what other ADs were thinking ... > > > > I'm current on this thread, as of the time I'm sending my note, but=20 > replying to Andy's note because it's poking where I am poking. > > > > So, if (say) an octet counter is considered safe to send in the clear, = > and a Yang model that reflects that is approved and widely deployed,=20 > and then someone realizes that it's not safe to send in the clear, is=20 > that a big deal to fix, and get the updated Yang model widely = deployed? > > > > My opinion on this point has a lot to do with how hard it is to=20 > recover if a Yang model gets this wrong ... > > > > My apologies for not understanding enough about Yang and I2RS to be=20 > able to answer my own question, of course. > > > > Thanks, > > > > Spencer > > --=20 Best regards, Kathleen _______________________________________________ i2rs mailing list i2rs@ietf.org https://www.ietf.org/mailman/listinfo/i2rs From nobody Fri Aug 19 09:07:19 2016 Return-Path: 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 64F1B12B04C; Fri, 19 Aug 2016 09:05:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.739 X-Spam-Level: * X-Spam-Status: No, score=1.739 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, RDNS_NONE=0.793] autolearn=no 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 6SWssr58Jo4y; Fri, 19 Aug 2016 09:05:13 -0700 (PDT) Received: from hickoryhill-consulting.com (unknown [50.245.122.97]) (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 2589E12B00F; Fri, 19 Aug 2016 09:05:09 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=184.157.82.170; From: "Susan Hares" To: "'Andy Bierman'" References: <013b01d1f8ee$31fa09b0$95ee1d10$@ndzh.com> <20160818073203.GA4338@elstar.local> <04b501d1f949$116c63e0$34452ba0$@ndzh.com> <20160818121405.GA5282@elstar.local> <051301d1f950$7739c670$65ad5350$@ndzh.com> <20160818130555.GA5366@elstar.local> <051701d1f952$c4ae0b30$4e0a2190$@ndzh.com> <6BCE198E4EAEFC4CAB45D75826EFB0761525CCD7@eusaamb101.ericsson.se> <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> <036801d1fa2a$466e9e00$d34bda00$@ndzh.com> In-Reply-To: Date: Fri, 19 Aug 2016 12:03:33 -0400 Message-ID: <005501d1fa33$3d36e960$b7a4bc20$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0056_01D1FA11.B62C0020" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJ/RF5y8kBC7R3sO+auWKe566R2lwEcb/3KAg+ndAACAypBUwGJSPf4Amiv8FwDJLAGjQJqExQkAqfTovACEJToAwFDCzFbAlTVyfQCrq8/9AJKcpLBAq9whFMCDwN3eQIvrQjwAY0nrpqd0jfF8A== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: X-Mailman-Approved-At: Fri, 19 Aug 2016 09:07:15 -0700 Cc: i2rs@ietf.org, 'Alissa Cooper' , 'Juergen Schoenwaelder' , i2rs-chairs@ietf.org, 'Kathleen Moriarty' , 'IESG' , 'Jeffrey Haas' , 'Joel Halpern' , 'Lou Berger' , 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Aug 2016 16:05:16 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0056_01D1FA11.B62C0020 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Andy/Kathleen:=20 =20 What do MTI and MTU standard for? =20 =20 Sue=20 =20 From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Andy Bierman Sent: Friday, August 19, 2016 11:43 AM To: Susan Hares Cc: i2rs@ietf.org; Alissa Cooper; Juergen Schoenwaelder; = i2rs-chairs@ietf.org; Kathleen Moriarty; IESG; Jeffrey Haas; Joel = Halpern; Lou Berger; = 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) =20 Hi, =20 That is simple. There needs to be consensus on the syntax and semantics of each statement in the YANG module. =20 Since security is MTI and MTU for NETCONF and RESTCONF, there is no point debating which objects are OK without security. =20 Andy =20 =20 =20 On Fri, Aug 19, 2016 at 7:59 AM, Susan Hares wrote: Andy:=20 =20 Thank you for your comments. Perhaps you can provide for the IESG the = list of things that are needed to move a Yang module forward in the = IETF. =20 =20 Sue=20 =20 From: Andy Bierman [mailto:andy@yumaworks.com]=20 Sent: Friday, August 19, 2016 10:24 AM To: Lou Berger Cc: Susan Hares; Juergen Schoenwaelder; 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) =20 Hi, =20 I agree with Juergen. There are already too many details that need consensus to move a YANG module forward in the IETF. It takes too long already. =20 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?" =20 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? =20 Standardized insecure access is a big change from what we have done for 30 years. There could be a good reason why we left this out of = scope all this time. =20 =20 Andy =20 =20 On Fri, Aug 19, 2016 at 5:20 AM, Lou Berger wrote: Sue, My message said three things: 1) Juergen's comment resonates with me. 2) I think the current text is acceptable. 3) I see changing the SHOULD to a MUST as problematic. I understood one of the other messages on this thread proposing this change which is what triggered my message. If I misunderstood that message, feel free to interpret my message as supporting the current text in question. Note that I am only speaking for myself (including in my role as NETMOD co-chair) and not representing the consensus opinion of any WG. Lou On 8/19/2016 8:07 AM, Susan Hares wrote: > Lou: > > I am clear that Juergen does not want not want to place transport = requirements within the data model for NETMOD. His opinion was = considered in the rough for the I2RS WG. If this requirement is a = problem for NETCONF/NETMOD, the text currently says: > > REQ-SEC-09 states: > > The default mode of transport is secure so data models SHOULD = clearly annotate what data nodes can be > passed over an insecure connection. > > However, if this means the NETCONF/NETMOD WG will not even entertain = proposal for marking the insecure functions in yang text -- then the two = WG (I2RS/NETMOD) have a problem and should stop this standardization = process going forward. > > Sue > > > -----Original Message----- > From: Lou Berger [mailto:lberger@labn.net] > Sent: Friday, August 19, 2016 7:34 AM > To: Susan Hares; 'Juergen Schoenwaelder' > Cc: i2rs@ietf.org; 'Alissa Cooper'; i2rs-chairs@ietf.org; 'Kathleen = Moriarty'; 'IESG'; jhaas@pfrc.org; '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) > > Sue, > > I don't see Juergen as arguing against model access via non-secure = transport. I read his point as that the transport security requirements = don't belong scattered within a data model. > > I have to say that from a model complexity (definition, process, = review, implementation - take your pick) , language and NETMOD co-chair = perspective, his comment resonates with me. > > I think this makes the key text: > > The default mode of transport is > secure so data models SHOULD clearly annotate what data nodes can = be > passed over an insecure connection. > > > As this isn't a MUST, I personally think we can live with the text and = we can debate the issue further in the context of specific solutions. I = would strongly object to this being changed to a MUST, or if the = document is changed to make transport (security) requirements identified = within data models a requirement. > > Lou > > On 8/19/2016 6:49 AM, Susan Hares wrote: >> Juergen: >> >> You have laid out the two options: a) link the data-model to the = non-secure transport, and b) do not link the data to the non-secure = transport. I agree with you that past models did not link past SNMP = MIB data model to the transport. Existing NETCONF models do not link it = to the transport. As you have indicated, you disagreed in the I2RS WG = and we found consensus was to include the non-secure transport. >> >> I2RS was created to build things as an interface to the routing = environment. The operators clearly informed the I2RS group of this = need during the requirement setting phase prior to the time I was chair. = The reason I continue to press for this capability is their input, and = the existing use cases I listed previously in this mail: >> >> a) public information - BGP route views, >> b) specific well know up events - such as public-web site up >> c) specific network service events - interface to particular public = LAN up. >> >> As you know, we do not have any I2RS data models that specify this = feature at this time. I suspect after we get through this lengthy = requirement phase, the operators may begin to specify new models that = have this feature. >> >> Sue >> >> -----Original Message----- >> From: Juergen Schoenwaelder >> [mailto:j.schoenwaelder@jacobs-university.de] >> Sent: Friday, August 19, 2016 4:58 AM >> To: Susan Hares >> Cc: 'Alissa Cooper'; 'Joel Halpern'; i2rs@ietf.org; >> i2rs-chairs@ietf.org; 'Kathleen Moriarty'; 'IESG'; jhaas@pfrc.org; >> 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) >> >> I repeat my technical argument: While there may be deployments where = non-secure transports may be reasonable to use, defining these = situations statically as part of data model schemas does not follow = established practices. The IETF has a long tradition of standardizing = data models that can be used in a variety of operational contexts and I = do not see reasons why we should move away from that basic approach. >> >> /js >> >> On Thu, Aug 18, 2016 at 02:35:03PM -0400, Susan Hares wrote: >>> Alissa: >>> >>> Just a little input you may not know. My background is 15 years = (1995-2010) developing a routing/switching platform (denoted as GateD) = which was sold to over 200 companies. We developed XML and a binary = XML based product that configured this product. It could do 100K = configuration lines and reboot in less than a second on most hardware. = We also provide status messages in secure streams and non-secure = streams. I sold early version of this code to companies that Alia has = worked for - so she has personal viewed the code. At the height of = our work, our development team ran to 50 people which I directed (First = as VP of Engineering, and then as CTO). It is due to this level of = experience that Alia selected me for the co-chair. Russ White has = understood Cisco's process, and has also directed software development = teams for routing. >>> >>> In order to freshen my direct experience with I2RS on open source = work, I am working on a publically available work in Quagga based on the = confD product suggested by Cisco. >>> >>> In contrast, Juergen is a university professor who has worked on = proto-types. He is not working on an implementation. I hope he will. >>> >>> I hope you will consider this background in my response to your = comments below. >>> >>> Sue >>> >>> >>> -----Original Message----- >>> From: Alissa Cooper [mailto:alissa@cooperw.in] >>> Sent: Thursday, August 18, 2016 12:54 PM >>> To: Joel Halpern >>> Cc: Susan Hares; Juergen Schoenwaelder; i2rs@ietf.org; >>> i2rs-chairs@ietf.org; Kathleen Moriarty; IESG; jhaas@pfrc.org; >>> 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) >>> >>> Jumping in here because this is relevant to my DISCUSS, hope nobody = minds (but if you do, I can go back to the other thread). >>> >>>>> On Aug 18, 2016, at 10:30 AM, Joel Halpern = wrote: >>>>> >>>>> Let me try a different take approach to this particular question. >>>>> >>>>> Let me start by putting aside the question of where things are = marked, and come back to that afterwards. >>>>> >>>>> There are a number of cases that I2RS has been asked to cover of = high rate telemetry data. This may be BGP update information, it may be = frequent information about line card activity. There are other cases, = some of which have been documented. >>>>> >>>>> While not completely insensitive, the operators have made clear = that they see protecting this data as unnecessary. While I would hope = over time to move to a domain where all of it is protect, that is not = trivial. As the I2RS Architecture points out, it is expected that what = we describe as a single I2RS >communication between a client and agent = is actually associated with multiple channels of communication. >>>>> >>>>> Now, if you want to say that the I2RS protocol requirements cannot = allow for unprotected channels, I guess we have disconnect between the = IESG and the WG. >>>>> >>>>> If we say that we can allow for unprotected channels, we then get = to the question of which data can be sent over such channels. While = architecturally I agree with Juergen that the model is a bad place to = specify it, the obverse is also true. Not having some limits on what = can be sent unprotected >causes concern about insufficient protection. = If I recall correctly, earlier security reviews called us to task for = being too broad in what we allowed. >>>>> >>>>> So, if the IESG wants us to just allow it anywhere, because the >>>>> model is an awkward place to define the limitation, I can live = with that. What I can't live with is being told both that the model is = a bad place to define it and that there must be restrictions on what is = sent unprotected, without any proposal on how we are to move forward. >>>> Thank you Joel, this explanation helps me a lot. I think there is a = disconnect about how the restrictions are expressed. From reading the = email traffic about this document, it strikes me that trying to express = the restrictions programmatically doesn=E2=80=99t make much sense in = this case. >>>> I agree with Juergen that it will be challenging to make a judgment = a priori in order to bake a restriction into a data model, because data = that is considered sensitive enough to warrant a secure transport in one = deployment may not be considered sensitive in another deployment. >>>> So for any data elements where there is any question at all about >>>> whether they might be sensitive (i.e., any data elements that are = not already routinely made public), I would expect data model authors to = end up indicating that they may be sent over either secure or insecure = transport, which renders the indication not useful. >>>> Perhaps it would make more sense then to just enumerate in the text = the cases that motivate the inclusion of protocol support for insecure = transport: >>>> >>>> 1. For conveyance of information that is already routinely made = public. >>>> 2. For line card activity data where there is no likely upgrade = path to support secure transports in the foreseeable future. >>>> >>>> Then the normative requirements would be on clients and agents to = use secure transports unless those clients and agents are deployed where = either of the operational circumstances above necessitate otherwise. >>>> Alissa >>> Point 1: >>> I disagree with Juergen on the difficulty in specifying the sections = of the yang modules. I have provided a suggested solution in: >>> = https://tools.ietf.org/html/draft-hares-i2rs-protocol-strawman-03#section= -4.5.2. >>> >>> Given the mount schema functionality, we can mount ephemeral state = module which augment non-ephemeral state modules which are "in-secure = only". >>> >>> Point 2: >>> I am willing to put an enumeration of the use cases in the protocol = requirement, but I would like to understand the purpose for the = enumeration. We are not doing a use case, but a requirements document. = This information appears to be a "use case" rather than a technical = description. What purpose are you looking for this enumeration to = server. Are you looking for the enumeration in SEC-REQ-08? >>> >>> Point 3: Could you review -08.txt on this topic, especially the text = below. Given your comments, I believe I should change the last line to = a MUST. >>> New/ The default mode of transport is >>> secure so data models MUST clearly annotate what data nodes can = be >>> passed over an insecure connection. >>> / >>> >>> Sue >>> >>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>> As to the normative requirements (-08.txt) version: >>> >>> Section 3: >>> >>> I2RS allows the use of an insecure transport for portions of data >>> models that clearly indicate the use of an insecure transport. >>> Operators deploying I2RS must determine if they want to populate = and >>> deploy the portions of the data model which use insecure = transports. >>> >>> In Section 3.2 in version -08.txt >>> >>> SEC-REQ-08: The I2RS protocol MUST be able to transfer data over = a >>> secure transport and optionally MAY be able to transfer data over = a >>> non-secure transport. A secure transport MUST provide data >>> confidentiality, data integrity, and replay prevention. >>> >>> The default I2RS transport is a secure transport. >>> >>> 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. >>> >>> The configuration of ephemeral data in the I2RS Agent by the I2RS >>> client SHOULD be done over a secure transport. It is anticipated >>> that the passing of most I2RS ephemeral state operational status >>> SHOULD be done over a secure transport. As >>> [I-D.ietf-i2rs-ephemeral-state] notes, a data model MUST = indicate >>> whether the transport exchanging the data between I2RS client and >>> I2RS agent is secure or insecure. >>> >>> The default mode of transport is >>> secure so data models SHOULD clearly annotate what data nodes can = be >>> passed over an insecure connection. >>> >>>> Yours, >>>> Joel >>>> >>>> -----Original Message----- >>>> From: Susan Hares [mailto:shares@ndzh.com] >>>> Sent: Thursday, August 18, 2016 9:17 AM >>>> To: 'Juergen Schoenwaelder' >>>> Cc: i2rs@ietf.org; i2rs-chairs@ietf.org; 'Kathleen Moriarty' >>>> ; 'The IESG' ; >>>> jhaas@pfrc.org; >>>> 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) >>>> >>>> Juergen and Kathleen: >>>> >>>> Let me proceed with two examples: BGP route views data model and = the event for the web-service data. >>>> >>>> The content of these data models are designated as exposed to = public. The routing system only populates the proposed BGP route views = data model with the data destined for the BGP looking glass. The policy = on the routing system indicates what information gets transferred. The = data model is completely available to the public. The Yang Doctors are = going to review this by seeing the whole model is public and available = via non-secure means. >>>> The security people are going to review this seeing that the whole = model is public, and available via an unprotect means. The fact the = data model is all public should simplify the review. >>>> >>>> An event from the I2RS RIB that a web-service route is up is the = second case. The I2RS RIB has an event based on policy that indicates a = web-service route is up. The yang-1.1 doctors must review the content = of the event text to see it does not break privacy or provide too much >>>> information The event mechanisms will need to work over secure = transport >>>> and insecure transport. Most of the data will go over the secure = transport event stream. However, a small amount of information may go = over the insecure transport stream. >>>> >>>> First, let me know if my use cases are understandable. Second, let = me know if you disagree with this use cases. >>>> >>>> Fyi - IESG approved the architecture with the insecure stream. >>>> >>>> Sue >>>> >>>> -----Original Message----- >>>> From: Juergen Schoenwaelder >>>> [mailto:j.schoenwaelder@jacobs-university.de] >>>> Sent: Thursday, August 18, 2016 9:06 AM >>>> To: Susan Hares >>>> Cc: i2rs@ietf.org; i2rs-chairs@ietf.org; 'Kathleen Moriarty'; 'The >>>> IESG'; jhaas@pfrc.org; >>>> 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) >>>> >>>> I just do not know on which basis a data model writer can decide = whether a data object can be exposed in an unprotected way. How are YANG = doctors going to review this? How are security directorate people going = to judge this? But as promised, I leave (still puzzled) now. >>>> >>>> /js >>>> >>>> On Thu, Aug 18, 2016 at 09:00:14AM -0400, Susan Hares wrote: >>>>> Juergen: >>>>> >>>>> Yes, we seem to disagree on the value of making it hardwired in = the model. >>>>> For me, the value is a common understanding of deployment >>>>> distribution >>>> such >>>>> as the route-views. Since the operators argued strongly for this = point, >>>> I >>>>> think the best idea is to get it working in code and then see if >>>>> the deployment matches the requests. >>>>> >>>>> Sue >>>>> >>>>> -----Original Message----- >>>>> From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Juergen >>>>> Schoenwaelder >>>>> Sent: Thursday, August 18, 2016 8:14 AM >>>>> To: Susan Hares >>>>> Cc: i2rs@ietf.org; i2rs-chairs@ietf.org; 'Kathleen Moriarty'; 'The >>>>> IESG'; jhaas@pfrc.org; >>>>> 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) >>>>> >>>>> Sue, >>>>> >>>>> I still do not see why the 'mode of exposure' of data benefits = from >>>>> being hard-wired in the data model. For me, it is a situational = and >>>>> deployment specific question. But I shut up here since I aired = this >>>>> concern before (and we simply seem to disagree). >>>>> >>>>> /js >>>>> >>>>> On Thu, Aug 18, 2016 at 08:07:18AM -0400, Susan Hares wrote: >>>>>> Juergen: >>>>>> >>>>>> My example is the looking glass servers for the BGP route views >>>>>> project >>>>>> (http://www.routeviews.org/) or a route indicating the presence = of a >>>>>> web-server that is public. For the BGP I2RS route, a yang model = could >>>>>> replace the looking glass function, and provide events for these = looking >>>>>> glass functions. For the web-server route, an event be sent = when >>>> that >>>>>> one route is added. >>>>>> >>>>>> Sue >>>>>> >>>>>> >>>>>> -----Original Message----- >>>>>> From: Juergen Schoenwaelder >>>>>> [mailto:j.schoenwaelder@jacobs-university.de] >>>>>> Sent: Thursday, August 18, 2016 3:32 AM >>>>>> To: Susan Hares >>>>>> Cc: 'Kathleen Moriarty'; 'The IESG'; jhaas@pfrc.org; >>>>>> i2rs@ietf.org; i2rs-chairs@ietf.org; >>>>>> 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 Wed, Aug 17, 2016 at 09:16:48PM -0400, Susan Hares wrote: >>>>>>> = ----------------------------------------------------------------- >>>>>>> - >>>>>>> -- >>>>>>> -- >>>>>>> COMMENT: >>>>>>> = ----------------------------------------------------------------- >>>>>>> - >>>>>>> -- >>>>>>> -- >>>>>>> >>>>>>>> Section 3: >>>>>>>> Can you clarify the second to last sentence? Do you mean there >>>>>>>> are >>>>>> sections that indicate an insecure transport should be used? >>>>>>>> I2RS allows the use of an >>>>>>>> insecure transport for portions of data models that clearly >>>>>>>> indicate insecure transport. >>>>>>>> Perhaps: >>>>>>>> I2RS allows the use of an >>>>>>>> insecure transport for portions of data models that clearly >>>>>>>> indicate the use of an insecure transport. >>>>>> I still wonder how a data model writer can reasonably decide >>>>>> whether a piece of information can be shipped safely over an >>>>>> insecure transport since this decision often depends on the >>>>>> specifics of a deployment >>>>> situation. >>>>>> /js >>>>>> >>>>>> PS: I hope we do not end up with defining data multiple times = (once >>>>>> for insecure transport and once for secured transports). >>>>>> >>>>>> -- >>>>>> Juergen Schoenwaelder Jacobs University Bremen gGmbH >>>>>> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | = Germany >>>>>> Fax: +49 421 200 3103 = >>>>>> >>>>>> _______________________________________________ >>>>>> i2rs mailing list >>>>>> i2rs@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/i2rs >>>>> -- >>>>> Juergen Schoenwaelder Jacobs University Bremen gGmbH >>>>> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | = Germany >>>>> Fax: +49 421 200 3103 >>>>> >>>>> _______________________________________________ >>>>> i2rs mailing list >>>>> i2rs@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/i2rs >>>>> >>>> -- >>>> Juergen Schoenwaelder Jacobs University Bremen gGmbH >>>> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | = Germany >>>> Fax: +49 421 200 3103 >>>> > > > _______________________________________________ i2rs mailing list i2rs@ietf.org https://www.ietf.org/mailman/listinfo/i2rs =20 =20 ------=_NextPart_000_0056_01D1FA11.B62C0020 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Andy/Kathleen:

 

What do MTI and MTU standard for?=C2=A0

 

Sue

 

From:= = i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Andy = Bierman
Sent: Friday, August 19, 2016 11:43 AM
To: = Susan Hares
Cc: i2rs@ietf.org; Alissa Cooper; Juergen = Schoenwaelder; i2rs-chairs@ietf.org; Kathleen Moriarty; IESG; Jeffrey = Haas; Joel Halpern; Lou Berger; = 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)

 

Hi,

 

That is simple.

There needs to be consensus on the syntax and = semantics of each

statement in the YANG = module.

 

Since security is MTI and MTU for NETCONF and = RESTCONF, there

is no = point debating which objects are OK without = security.

 

Andy

 

 

 

On Fri, = Aug 19, 2016 at 7:59 AM, Susan Hares <shares@ndzh.com> = wrote:

Andy:

 

Thank you for your comments.   Perhaps you can provide for = the IESG the list of things that are needed to move a Yang module = forward in the IETF.  

 

Sue

 

From:= = Andy Bierman [mailto:andy@yumaworks.com]
Sent: Friday, = August 19, 2016 10:24 AM
To: Lou Berger
Cc: Susan = Hares; Juergen Schoenwaelder; 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)

 <= /o:p>

Hi,

 <= /o:p>

I agree = with Juergen.

There are = already too many details that need consensus to = move

a YANG = module forward in the IETF.  It takes too long = already.

 <= /o:p>

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?"

 <= /o:p>

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?

 <= /o:p>

Standardized= insecure access is a big change from what we have = done

for 30 = years.  There could be a good reason why we left this out of = scope

all this = time.

 <= /o:p>

 <= /o:p>

Andy

 <= /o:p>

 <= /o:p>

On Fri, Aug = 19, 2016 at 5:20 AM, Lou Berger <lberger@labn.net> wrote:


Sue,
=
My message said three things:

1) Juergen's comment resonates = with me.

2) I think the current text is acceptable.

3) I = see changing the SHOULD to a MUST as problematic.
I understood one of = the other messages on this thread proposing this
change which is what = triggered my message.   If I misunderstood that
message, = feel free to interpret my message as supporting the current
text in = question.

Note that I am only speaking for myself (including in = my role as NETMOD
co-chair) and not representing the consensus = opinion of any WG.

Lou
On 8/19/2016 8:07 AM, Susan Hares = wrote:
> Lou:
>
> I am clear that Juergen does not = want not want to place transport requirements within the data model for = NETMOD.  His opinion was considered in the rough for the I2RS WG. = If this requirement is a problem for NETCONF/NETMOD,  the text = currently says:
>
> REQ-SEC-09 states:
>
>  =  The default mode of transport is secure so data models SHOULD = clearly annotate what data nodes can be
>    passed over = an insecure connection.
>
> However, if this means the = NETCONF/NETMOD WG will not even entertain proposal for marking the = insecure functions in yang text -- then the two WG (I2RS/NETMOD) have a = problem and should stop this standardization process going = forward.
>
> Sue
>
>
> -----Original = Message-----
> From: Lou Berger [mailto:lberger@labn.net]
> Sent: Friday, August 19, = 2016 7:34 AM
> To: Susan Hares; 'Juergen Schoenwaelder'
> = Cc: i2rs@ietf.org; 'Alissa Cooper'; i2rs-chairs@ietf.org; 'Kathleen Moriarty'; 'IESG'; = jhaas@pfrc.org; = '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)
>
> Sue,
>
>     I don't = see Juergen as arguing against model access via non-secure transport. I = read his point as that the transport security requirements don't belong = scattered within a data model.
>
> I have to say that from a = model complexity (definition, process, review, implementation - take = your pick) , language and NETMOD co-chair perspective, his comment = resonates with me.
>
> I think this makes the key = text:
>
>    The default mode of transport = is
>    secure so data models SHOULD clearly annotate = what data nodes can be
>    passed over an insecure = connection.
>
>
> As this isn't a MUST, I personally = think we can live with the text and we can debate the issue further in = the context of specific solutions.  I would strongly object to this = being changed to a MUST, or if the document is changed to make transport = (security) requirements identified within data models a = requirement.
>
> Lou
>
> On 8/19/2016 6:49 AM, = Susan Hares wrote:
>> Juergen:
>>
>> You have = laid out the two options:   a) link the data-model to the = non-secure transport, and b) do not link the data to the non-secure = transport.   I agree with you that past models did not link = past SNMP MIB data model to the transport.  Existing NETCONF models = do not link it to the transport.   As you have indicated, you = disagreed in the I2RS WG and we found consensus was to include the = non-secure transport.
>>
>> I2RS was created to build = things as an interface to the routing environment.   The = operators clearly informed the I2RS group of this need during the = requirement setting phase prior to the time I was chair.  The = reason I continue to press for this capability is their input, and the = existing use cases I listed previously in this = mail:
>>
>> a) public information - BGP route = views,
>> b) specific well know up events - such as public-web = site up
>> c) specific network service events - interface to = particular public LAN up.
>>
>> As you know, we do not = have any I2RS data models that specify this feature at this time.  =  I suspect after we get through this lengthy requirement phase, the = operators may begin to specify new models that have this = feature.
>>
>> Sue
>>
>> = -----Original Message-----
>> From: Juergen = Schoenwaelder
>> [mailto:j.schoenwaelder@jacobs-university.de]
>> = Sent: Friday, August 19, 2016 4:58 AM
>> To: Susan = Hares
>> Cc: 'Alissa Cooper'; 'Joel Halpern'; i2rs@ietf.org;
>> i2rs-chairs@ietf.org; 'Kathleen Moriarty'; 'IESG'; = jhaas@pfrc.org;
>> 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)
>>
>> I repeat my = technical argument: While there may be deployments where non-secure = transports may be reasonable to use, defining these situations = statically as part of data model schemas does not follow established = practices. The IETF has a long tradition of standardizing data models = that can be used in a variety of operational contexts and I do not see = reasons why we should move away from that basic = approach.
>>
>> /js
>>
>> On Thu, = Aug 18, 2016 at 02:35:03PM -0400, Susan Hares wrote:
>>> = Alissa:
>>>
>>> Just a little input you may not = know.  My background is 15 years (1995-2010)  developing a = routing/switching platform (denoted as GateD) which was sold to over 200 = companies.   We developed XML and a binary XML based product = that configured this product.  It could do 100K configuration lines = and reboot in less than a second on most hardware.  We also provide = status messages in secure streams and non-secure streams.    I = sold early version of this code to companies that Alia has worked = for  - so she has personal viewed the code.   At the = height of our work, our development team ran to 50 people which I = directed (First as VP of Engineering, and then as CTO). It is due to = this level of experience that Alia selected me for the co-chair.  =  Russ White has understood Cisco's process, and has also directed = software development teams for routing.
>>>
>>> = In order to freshen my direct experience with I2RS on open source work, = I am working on a publically available work in Quagga based on the confD = product suggested by Cisco.
>>>
>>> In contrast, = Juergen is a university professor who has worked on proto-types.  =  He is not working on an implementation.   I hope he = will.
>>>
>>> I hope you will consider this = background in my response to your comments = below.
>>>
>>> = Sue
>>>
>>>
>>> -----Original = Message-----
>>> From: Alissa Cooper [mailto:alissa@cooperw.in]
>>> Sent: Thursday, = August 18, 2016 12:54 PM
>>> To: Joel = Halpern
>>> Cc: Susan Hares; Juergen Schoenwaelder; i2rs@ietf.org;
>>> i2rs-chairs@ietf.org; Kathleen Moriarty; IESG; jhaas@pfrc.org;
>>> 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)
>>>
>>> Jumping in here because this is = relevant to my DISCUSS, hope nobody minds (but if you do, I can go back = to the other thread).
>>>
>>>>> On Aug 18, = 2016, at 10:30 AM, Joel Halpern <joel.halpern@ericsson.com> = wrote:
>>>>>
>>>>> Let me try a = different take approach to this particular = question.
>>>>>
>>>>> Let me start = by putting aside the question of where things are marked, and come back = to that afterwards.
>>>>>
>>>>> = There are a number of cases that I2RS has been asked to cover of high = rate telemetry data.  This may be BGP update information, it may be = frequent information about line card activity.  There are other = cases, some of which have been = documented.
>>>>>
>>>>> While not = completely insensitive, the operators have made clear that they see = protecting this data as unnecessary.  While I would hope over time = to move to a domain where all of it is protect, that is not = trivial.  As the I2RS Architecture points out, it is expected that = what we describe as a single I2RS >communication between a client and = agent is actually associated with multiple channels of = communication.
>>>>>
>>>>> Now, if = you want to say that the I2RS protocol requirements cannot allow for = unprotected channels, I guess we have disconnect between the IESG and = the WG.
>>>>>
>>>>> If we say that = we can allow for unprotected channels, we then get to the question of = which data can be sent over such channels.  While architecturally I = agree with Juergen that the model is a bad place to specify it, the = obverse is also true.  Not having some limits on what can be sent = unprotected >causes concern about insufficient protection.  If I = recall correctly, earlier security reviews called us to task for being = too broad in what we = allowed.
>>>>>
>>>>> So, if the IESG = wants us to just allow it anywhere, because the
>>>>> = model is an awkward place to define the limitation, I can live with = that.  What I can't live with is being told both that the model is = a bad place to define it and that there must be restrictions on what is = sent unprotected, without any proposal on how we are to move = forward.
>>>> Thank you Joel, this explanation helps me a = lot. I think there is a disconnect about how the restrictions are = expressed. From reading the email traffic about this document, it = strikes me that trying to express the restrictions programmatically = doesn=E2=80=99t make much sense in this case.
>>>> I = agree with Juergen that it will be challenging to make a judgment a = priori in order to bake a restriction into a data model, because data = that is considered sensitive enough to warrant a secure transport in one = deployment may not be considered sensitive in another = deployment.
>>>> So for any data elements where there is = any question at all about
>>>> whether they might be = sensitive (i.e., any data elements that are not already routinely made = public), I would expect data model authors to end up indicating that = they may be sent over either secure or insecure transport, which renders = the indication not useful.
>>>> Perhaps it would make = more sense then to just enumerate in the text the cases that motivate = the inclusion of protocol support for insecure = transport:
>>>>
>>>> 1. For conveyance of = information that is already routinely made public.
>>>> = 2. For line card activity data where there is no likely upgrade path to = support secure transports in the foreseeable = future.
>>>>
>>>> Then the normative = requirements would be on clients and agents to use secure transports = unless those clients and agents are deployed where either of the = operational circumstances above necessitate = otherwise.
>>>> Alissa
>>> Point = 1:
>>> I disagree with Juergen on the difficulty in = specifying the sections of the yang modules.  I have provided a = suggested solution in:
>>> https://tools.ietf.org/html/draft-hares-i2rs-protocol-s= trawman-03#section-4.5.2.
>>>
>>> Given the = mount schema functionality, we can mount ephemeral state module which = augment non-ephemeral state modules which are "in-secure = only".
>>>
>>> Point 2:
>>> I = am willing to put an enumeration of the use cases in the protocol = requirement, but I would like to understand the purpose for the = enumeration.   We are not doing a use case, but a requirements = document.  This information appears to be a "use case" = rather than a technical description.   What purpose are you = looking for this enumeration to server.  Are you looking for the = enumeration in SEC-REQ-08?
>>>
>>> Point 3: = Could you review -08.txt on this topic, especially the text below.  = Given your comments, I believe I should change the last line to a = MUST.
>>> New/   The default mode of transport = is
>>>    secure so data models MUST clearly = annotate what data nodes can be
>>>    passed over = an insecure connection.
>>> = /
>>>
>>> Sue
>>>
>>> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>>>= As to the normative requirements (-08.txt) = version:
>>>
>>> Section = 3:
>>>
>>>    I2RS allows the use of = an insecure transport for portions of data
>>>    = models that clearly indicate the use of an insecure = transport.
>>>    Operators deploying I2RS must = determine if they want to populate and
>>>    = deploy the portions of the data model which use insecure = transports.
>>>
>>> In Section 3.2 in version = -08.txt
>>>
>>>    SEC-REQ-08: The = I2RS protocol MUST be able to transfer data over a
>>>  =   secure transport and optionally MAY be able to transfer data over = a
>>>    non-secure transport.  A secure = transport MUST provide data
>>>    = confidentiality, data integrity, and replay = prevention.
>>>
>>>    The default = I2RS transport is a secure = transport.
>>>
>>>    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.
>>>
>>>    The configuration = of ephemeral data in the I2RS Agent by the I2RS
>>>  =   client SHOULD be done over a secure transport.  It is = anticipated
>>>    that the passing of most I2RS = ephemeral state operational status
>>>    SHOULD = be done over a secure transport.  As
>>>    = [I-D.ietf-i2rs-ephemeral-state] notes,  a data model MUST = indicate
>>>    whether the transport exchanging = the data between I2RS client and
>>>    I2RS agent = is secure or insecure.
>>>
>>>    The = default mode of transport is
>>>    secure so data = models SHOULD clearly annotate what data nodes can = be
>>>    passed over an insecure = connection.
>>>
>>>> = Yours,
>>>> Joel
>>>>
>>>> = -----Original Message-----
>>>> From: Susan Hares = [mailto:shares@ndzh.com]
>>>> Sent: = Thursday, August 18, 2016 9:17 AM
>>>> To: 'Juergen = Schoenwaelder' <j.schoenwaelder@jacobs-university.de>
>>= ;>> Cc: i2rs@ietf.org; i2rs-chairs@ietf.org; 'Kathleen = Moriarty'
>>>> <Kathleen.Moriarty.ietf@gmail.com>; 'The IESG' = <iesg@ietf.org>;
>>>> jhaas@pfrc.org;
>>>> 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)
>>>>
>>>> = Juergen and Kathleen:
>>>>
>>>> Let me = proceed with two examples: BGP route views data model and the event for = the web-service data.
>>>>
>>>> The = content of these data models are designated as exposed to public.  = The routing system only populates the proposed BGP route views data = model with the data destined for the BGP looking glass.  The policy = on the routing system indicates what information gets transferred.  = The data model is completely available to the public.  The Yang = Doctors are going to review this by seeing the whole model is public and = available via non-secure means.
>>>> The security people = are going to review this seeing that the whole model is public, and = available via an unprotect means.  The fact the data model is all = public should simplify the = review.
>>>>
>>>> An event from the I2RS = RIB that a web-service route is up is the second case.  The I2RS = RIB has an event based on policy that indicates a web-service route is = up.  The yang-1.1 doctors must review the content of the event text = to see it does not break privacy or provide too much
>>>> = information   The event mechanisms will need to work over = secure transport
>>>> and insecure transport.  Most = of the data will go over the secure transport event stream. However, a = small amount of information may go over the insecure transport = stream.
>>>>
>>>> First, let me know if my = use cases are understandable.  Second, let me know if you disagree = with this use cases.
>>>>
>>>> Fyi -  = IESG approved the architecture with the insecure = stream.
>>>>
>>>> = Sue
>>>>
>>>> -----Original = Message-----
>>>> From: Juergen = Schoenwaelder
>>>> [mailto:j.schoenwaelder@jacobs-university.de]
>>&g= t;> Sent: Thursday, August 18, 2016 9:06 AM
>>>> To: = Susan Hares
>>>> Cc: i2rs@ietf.org; i2rs-chairs@ietf.org; 'Kathleen Moriarty'; = 'The
>>>> IESG'; jhaas@pfrc.org;
>>>> 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)
>>>>
>>>> = I just do not know on which basis a data model writer can decide whether = a data object can be exposed in an unprotected way. How are YANG doctors = going to review this? How are security directorate people going to judge = this? But as promised, I leave (still puzzled) = now.
>>>>
>>>> = /js
>>>>
>>>> On Thu, Aug 18, 2016 at = 09:00:14AM -0400, Susan Hares wrote:
>>>>> = Juergen:
>>>>>
>>>>> Yes, we seem to = disagree on the value of making it hardwired in the = model.
>>>>> For me, the value is a common = understanding of deployment
>>>>> = distribution
>>>> such
>>>>> as the = route-views.   Since the operators argued strongly for this = point,
>>>> I
>>>>> think the best idea = is to get it working in code and then see if
>>>>> the = deployment matches the = requests.
>>>>>
>>>>> = Sue
>>>>>
>>>>> -----Original = Message-----
>>>>> From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of = Juergen
>>>>> Schoenwaelder
>>>>> = Sent: Thursday, August 18, 2016 8:14 AM
>>>>> To: = Susan Hares
>>>>> Cc: i2rs@ietf.org; i2rs-chairs@ietf.org; 'Kathleen Moriarty'; = 'The
>>>>> IESG'; jhaas@pfrc.org;
>>>>> 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)
>>>>>
>>>>> = Sue,
>>>>>
>>>>> I still do not see = why the 'mode of exposure' of data benefits from
>>>>> = being hard-wired in the data model. For me, it is a situational = and
>>>>> deployment specific question. But I shut up = here since I aired this
>>>>> concern before (and we = simply seem to = disagree).
>>>>>
>>>>> = /js
>>>>>
>>>>> On Thu, Aug 18, 2016 = at 08:07:18AM -0400, Susan Hares wrote:
>>>>>> = Juergen:
>>>>>>
>>>>>> My = example is the looking glass servers for the BGP route = views
>>>>>> project
>>>>>> = (http://www.routeviews.org/) or a route indicating = the presence of a
>>>>>> web-server that is = public.   For the BGP I2RS route, a yang model = could
>>>>>> replace the looking glass function, = and provide events for these looking
>>>>>> glass = functions.    For the web-server route,  an event be sent = when
>>>> that
>>>>>> one route is = added.
>>>>>>
>>>>>> = Sue
>>>>>>
>>>>>>
>>&g= t;>>> -----Original Message-----
>>>>>> = From: Juergen Schoenwaelder
>>>>>> [mailto:j.schoenwaelder@jacobs-university.de]
>>&g= t;>>> Sent: Thursday, August 18, 2016 3:32 = AM
>>>>>> To: Susan = Hares
>>>>>> Cc: 'Kathleen Moriarty'; 'The IESG'; = jhaas@pfrc.org;
>>>>>> i2rs@ietf.org; i2rs-chairs@ietf.org;
>>>>>> = 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 Wed, = Aug 17, 2016 at 09:16:48PM -0400, Susan Hares = wrote:
>>>>>>> = -----------------------------------------------------------------
>= >>>>>> -
>>>>>>> = --
>>>>>>> --
>>>>>>> = COMMENT:
>>>>>>> = -----------------------------------------------------------------
>= >>>>>> -
>>>>>>> = --
>>>>>>> = --
>>>>>>>
>>>>>>>> = Section 3:
>>>>>>>> Can you clarify the = second to last sentence?  Do you mean = there
>>>>>>>> = are
>>>>>> sections that indicate an insecure = transport should be used?
>>>>>>>>  I2RS = allows the use of an
>>>>>>>> insecure = transport for portions of data models that = clearly
>>>>>>>> indicate  insecure = transport.
>>>>>>>> = Perhaps:
>>>>>>>> I2RS allows the use of = an
>>>>>>>> insecure transport for portions = of data models that clearly
>>>>>>>> indicate = the use of an  insecure transport.
>>>>>> I = still wonder how a data model writer can reasonably = decide
>>>>>> whether a piece of information can be = shipped safely over an
>>>>>> insecure transport = since this decision often depends on the
>>>>>> = specifics of a deployment
>>>>> = situation.
>>>>>> = /js
>>>>>>
>>>>>> PS: I hope = we do not end up with defining data multiple times = (once
>>>>>>    for insecure transport = and once for secured = transports).
>>>>>>
>>>>>> = --
>>>>>> 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/>
>>>= ;>>>
>>>>>> = _______________________________________________
>>>>>&g= t; i2rs mailing list
>>>>>> i2rs@ietf.org
>>>>>> https://www.ietf.org/mailman/listinfo/i2rs
>&= gt;>>> --
>>>>> 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/>
>>>= ;>>
>>>>> = _______________________________________________
>>>>> = i2rs mailing list
>>>>> i2rs@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/i2rs
>&= gt;>>>
>>>> --
>>>> 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/>
>>>= ;>
>
>
>


________________________________= _______________
i2rs mailing list
i2rs@ietf.org
https://www.ietf.org/mailman/listinfo/i2rs

 <= /o:p>

 

------=_NextPart_000_0056_01D1FA11.B62C0020-- From nobody Fri Aug 19 09:15:17 2016 Return-Path: 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 4653112B00F; Fri, 19 Aug 2016 09:09:38 -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 j1Y5b92ZR3oX; Fri, 19 Aug 2016 09:09:35 -0700 (PDT) Received: from mail-ua0-x22e.google.com (mail-ua0-x22e.google.com [IPv6:2607:f8b0:400c:c08::22e]) (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 9A9EE12D125; Fri, 19 Aug 2016 09:09:35 -0700 (PDT) Received: by mail-ua0-x22e.google.com with SMTP id n59so87704699uan.2; Fri, 19 Aug 2016 09:09:35 -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=5booZwZQZaE9KKKP4m7zkEZBpvBoYcOU63Yk+sY2e0I=; b=0iNiYNrHRHR7gMZM2lFjG1RHQhHBXT/yTnURX9+lnQJAR/tx279UtqOiR+ij6q+z7f XTNgJeX5zcNVV+gWBWfoLTliKym8DmM/XH66wJnLeeEQLfnMZLgbYja8bc+aYeSYsLid 1aN8Fx99wrjYleIbxEr0T8XLHYPZUKGzTiVZ+N361DBpBI2Y2hRMocG/k/ZqbWe4aJsh zRIpRucMGfMBQtQx0t8/Io7jaAnKHgH35CGFDKNov/bXRqMnmckS0O4360W4pwjkVggH gYCEPTKVP8fkZnSNf7lAQy8xx6YFcafPz1z2Kaw871kl4OIuDr8FjN5SN0WWHzt2SDYX lqDQ== 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=5booZwZQZaE9KKKP4m7zkEZBpvBoYcOU63Yk+sY2e0I=; b=hXy5TusiwMYVzkwnrlgBpNd5o2JpFzwQ4SxR07GUrg/JFli/wAYO76P6Exd2BeUTxE L+gtH3ryG9bNOpCNp1L8tR5oBxY0t29dWZu3O9FkRwvgv3TSMd57a9uABw0PyXrDvGiB InHdrPu0Ee9/4fDllYWy8ccY+lzZwYAZvw2wxTIew5LAwItJ2JZcgvwnfnNYut7spXOn 9UVPckqxTqRMoh3OCLVgTgwf0vpmggYULtub8hKNIqtQpGHvZt9KTYk8Ansg4/0ewPUg Rb83Q1n4Lx5vyNruB+/Z3zq4ZUN0W3b3/f3gqT8sadT8uKA7d5i7th5vZTrkJoNAslQP dMwQ== X-Gm-Message-State: AEkoouuPr356d6vnYIghkA/LjFjrKRxZlXlSLYY5Dw5+oQR4i9HQb4H9pyZvHVY/EGqHgMCDcmEfAdlgsMAyOg== X-Received: by 10.31.80.135 with SMTP id e129mr2405110vkb.151.1471622974669; Fri, 19 Aug 2016 09:09:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.1.228 with HTTP; Fri, 19 Aug 2016 09:09:33 -0700 (PDT) In-Reply-To: <004d01d1fa32$e30d3f20$a927bd60$@ndzh.com> References: <147146974235.23784.4389421535496134619.idtracker@ietfa.amsl.com> <013b01d1f8ee$31fa09b0$95ee1d10$@ndzh.com> <20160818073203.GA4338@elstar.local> <04b501d1f949$116c63e0$34452ba0$@ndzh.com> <20160818121405.GA5282@elstar.local> <051301d1f950$7739c670$65ad5350$@ndzh.com> <20160818130555.GA5366@elstar.local> <051701d1f952$c4ae0b30$4e0a2190$@ndzh.com> <6BCE198E4EAEFC4CAB45D75826EFB0761525CCD7@eusaamb101.ericsson.se> <003801d1f97f$3d16eb10$b744c130$@ndzh.com> <00dc01d1f988$f2cec280$d86c4780$@ndzh.com> <02b201d1fa1c$620e07d0$262a1770$@ndzh.com> <037501d1fa2a$a970fde0$fc52f9a0$@ndzh.com> <004d01d1fa32$e30d3f20$a927bd60$@ndzh.com> From: Kathleen Moriarty Date: Fri, 19 Aug 2016 12:09:33 -0400 Message-ID: To: Susan Hares Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: X-Mailman-Approved-At: Fri, 19 Aug 2016 09:15:16 -0700 Cc: i2rs@ietf.org, Alissa Cooper , Juergen Schoenwaelder , i2rs-chairs@ietf.org, Andy Bierman , IESG , Spencer Dawkins at IETF , 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) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Aug 2016 16:09:38 -0000 Hi Sue, On Fri, Aug 19, 2016 at 12:01 PM, Susan Hares wrote: > Kathleen: > > First of all, I agree software knobs can always be set to multiple settin= gs in vendor settings. These settings may expand beyond standard models, a= nd operators may set these knobs as they wish. > > As a security person, do you really want a standardized knob that says "r= un this model over non-secure transport"? KM: What I had asked earlier was if you could set a flag to say the data wasn't confidential and didn't require integrity protection. The operator could decide how they want to treat the data in that circumstance and you might only put this flag in the data model in places that you think the trigger is needed. Kathleen I do not want non-secure transport used for configuration and most operational status. Corrupted data in the MGT plane can corrupt data traffic in the network. The bar for non-secure transport has to be very high with lots of warnings. Therefore an operator having a switch to change attribute (such as a configuration attribute) from a secure transport to a non-secure transport - should be discouraged. > > Yang 1.1 has three places to indicate: > 1) Attribute - on the yang syntax on an attribute (leaf node or leaf lis= t), or portion of a schema, > 2) model - meta-data on yang modules contained in library. > 3) mount points - where multiple modules are mounted. > > [Andy or Juergen may provide more details on meta-data on yang module lib= raries. Lada or Lou can provide more details on mount points. ] > > Early in our discussion, NETCONF/NETMOD asked us to be specific in our re= quirements. In the final discussion, we put Yang syntax so the level coul= d be attribute to provide the level of check you indicated. It could go t= o any of these places if it works,. > > Does this discussion help? > > Sue > > -----Original Message----- > From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Kathleen Moriarty > Sent: Friday, August 19, 2016 11:27 AM > To: Susan Hares > Cc: i2rs@ietf.org; Alissa Cooper; Juergen Schoenwaelder; i2rs-chairs@ietf= .org; Andy Bierman; Spencer Dawkins at IETF; Jeffrey Haas; Joel Halpern; dr= aft-ietf-i2rs-protocol-security-requirements@ietf.org; IESG > Subject: Re: [i2rs] Kathleen Moriarty's Discuss on draft-ietf-i2rs-protoc= ol-security-requirements-07: (with DISCUSS and COMMENT) > > On Fri, Aug 19, 2016 at 11:02 AM, Susan Hares wrote: >> Spencer: >> >> >> >> Thank you for asking. The time it would take is the time to move the >> configuration knob to =E2=80=9Calways transport-secure=E2=80=9D for this= model. > > Why does the knob in the data model have to be set only one way? > Couldn't an attribute be used that you could change the setting for that = attribute rather than update the entire YANG module or is that not possible= in YANG? Couldn't this be a setting? > > Thanks, > Kathleen > >> >> >> >> Sue >> >> >> >> From: Spencer Dawkins at IETF [mailto:spencerdawkins.ietf@gmail.com] >> Sent: Friday, August 19, 2016 10:13 AM >> To: Susan Hares >> Cc: Andy Bierman; i2rs@ietf.org; Alissa Cooper; Juergen Schoenwaelder; >> 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) >> >> >> >> Hi, Susan, >> >> >> >> On Fri, Aug 19, 2016 at 8:19 AM, Susan Hares wrote: >> >> Spencer: >> >> >> >> You as asking if: >> >> >> >> 1) Can Yang Models be revised? - there is a revision tag on the Ya= ng >> model. >> >> 2) How long it takes to deploy revised models in the Internet, and >> old-models to be timed out? This is an operational question on yang mod= els >> that no one has experience to determine. Andy suggest that the deploym= ent >> time is 20 years (the Age of the Commercial internet =E2=80=93 1996 -201= 6) >> rather than the age of the Internet (1987-2016). >> >> >> >> However, the real question you should have asked is: Can operators >> deploy models which are marked as =E2=80=9Cnon-secure transport=E2=80=9D= with a secure transport? >> >> >> >> I understood that part. My question was how long it would likely take >> them to switch to a secure transport if they had deployed a model with >> an insecure transport and figured out that was problematic. >> >> >> >> Thanks for the explanation. It was helpful. >> >> >> >> Spencer >> >> >> >> The answer is yes. In fact, several operators in I2RS stated that all I= 2RS >> protocol communication needed to be secure. Therefore, if the people >> found out that a model was problematic to be insecure =E2=80=93 operator= s and >> vendors would simply turn the deployment knob switch that says =E2=80=93 >> deploy this always with a secure transport rather than optionally >> allow an insecure transport. >> >> >> >> Now, the real problem is if the IESG has been cycling on this concept = =E2=80=93 the >> text needs to change. I=E2=80=99m going to go ahead and release a vers= ion-09.txt >> that tries to make this very clear. Please comment on that text to hel= p >> make this clear. >> >> >> >> Sue >> >> >> >> >> >> From: Spencer Dawkins at IETF [mailto:spencerdawkins.ietf@gmail.com] >> Sent: Friday, August 19, 2016 9:08 AM >> To: Andy Bierman >> Cc: Susan Hares; i2rs@ietf.org; Alissa Cooper; Juergen Schoenwaelder; >> 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) >> >> >> >> Dear All, >> >> >> >> On Thu, Aug 18, 2016 at 3:02 PM, Andy Bierman wrote= : >> >> >> >> >> >> On Thu, Aug 18, 2016 at 12:44 PM, Susan Hares wrote: >> >> Andy: >> >> >> >> Thank you =E2=80=93 I thought it was on whether we could implement insec= ure >> transport in a Yang module. >> >> >> >> The requirement text you are working with is: >> >> >> >> SEC-REQ-08: The I2RS protocol MUST be able to transfer data over a >> secure transport and optionally MAY be able to transfer data over a >> non-secure transport. >> >> >> >> I do not understand why approving the ok for non-secure transport for >> some modules means the following to you: >> >> >> >> =E2=80=9C the IETF needs to agree that there could never possibly be any >> deployment that would not want to allow exposure of the data. >> >> Not now. Not 20 years from now.=E2=80=9D >> >> >> >> >> >> >> >> As I understand it, this requirement has another requirement >> associated with it >> >> that says the data has to be identified as OK-for-nonsecure-transport. >> >> >> >> An extension in the data model says that all instances of the object >> in >> >> all possible deployments cannot be considered sensistive and therefore >> >> needs disclosure protection. >> >> >> >> It may seem like even a simple octet counter is safe to send in the >> clear, >> >> but not if that opens up correlation attacks. (e.g., I can send data >> to some >> >> host. I can see that index 455992 is incrementing the in-octets >> counters >> >> in a way that strongly correlates to my test traffic. Therefore I can >> learn >> >> that arbitrary index 455992 is really John Doe or really suite #14, etc. >> >> >> >> Since Kathleen asked what other ADs were thinking ... >> >> >> >> I'm current on this thread, as of the time I'm sending my note, but >> replying to Andy's note because it's poking where I am poking. >> >> >> >> So, if (say) an octet counter is considered safe to send in the clear, >> and a Yang model that reflects that is approved and widely deployed, >> and then someone realizes that it's not safe to send in the clear, is >> that a big deal to fix, and get the updated Yang model widely deployed? >> >> >> >> My opinion on this point has a lot to do with how hard it is to >> recover if a Yang model gets this wrong ... >> >> >> >> My apologies for not understanding enough about Yang and I2RS to be >> able to answer my own question, of course. >> >> >> >> Thanks, >> >> >> >> Spencer >> >> > > > > -- > > Best regards, > Kathleen > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs > --=20 Best regards, Kathleen From nobody Fri Aug 19 09:15:21 2016 Return-Path: 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 14CCF12D125; Fri, 19 Aug 2016 09:12:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.147 X-Spam-Level: X-Spam-Status: No, score=-8.147 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.247] 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 WiSsZ6-r3-Dw; Fri, 19 Aug 2016 09:12:40 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) (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 7998812D09B; Fri, 19 Aug 2016 09:12:40 -0700 (PDT) Received: from mb-2.local ([IPv6:2601:647:4201:9e61:a5a6:9f65:49b4:5665]) (authenticated bits=0) by nagasaki.bogus.com (8.15.2/8.15.2) with ESMTPSA id u7JGCTfL094634 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT); Fri, 19 Aug 2016 16:12:30 GMT (envelope-from joelja@bogus.com) X-Authentication-Warning: nagasaki.bogus.com: Host [IPv6:2601:647:4201:9e61:a5a6:9f65:49b4:5665] claimed to be mb-2.local To: Susan Hares , "'Andy Bierman'" References: <013b01d1f8ee$31fa09b0$95ee1d10$@ndzh.com> <20160818073203.GA4338@elstar.local> <04b501d1f949$116c63e0$34452ba0$@ndzh.com> <20160818121405.GA5282@elstar.local> <051301d1f950$7739c670$65ad5350$@ndzh.com> <20160818130555.GA5366@elstar.local> <051701d1f952$c4ae0b30$4e0a2190$@ndzh.com> <6BCE198E4EAEFC4CAB45D75826EFB0761525CCD7@eusaamb101.ericsson.se> <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> <036801d1fa2a$466e9e00$d34bda00$@ndzh.com> <005501d1fa33$3d36e960$b7a4bc20$@ndzh.com> From: joel jaeggli Message-ID: <82159be3-622a-e986-ac97-628313fa1d68@bogus.com> Date: Fri, 19 Aug 2016 09:12:26 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:47.0) Gecko/20100101 Thunderbird/47.0 MIME-Version: 1.0 In-Reply-To: <005501d1fa33$3d36e960$b7a4bc20$@ndzh.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="nX1bUIRId4uk6rV9ETvt0HqX1OkShSAcW" Archived-At: X-Mailman-Approved-At: Fri, 19 Aug 2016 09:15:16 -0700 Cc: i2rs@ietf.org, 'Alissa Cooper' , 'Juergen Schoenwaelder' , i2rs-chairs@ietf.org, 'Kathleen Moriarty' , 'IESG' , 'Jeffrey Haas' , 'Joel Halpern' , 'Lou Berger' , 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Aug 2016 16:12:44 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --nX1bUIRId4uk6rV9ETvt0HqX1OkShSAcW Content-Type: multipart/mixed; boundary="TLmGBBo9qOUxV3jTEefCLEnDMkbI5wmWm" From: joel jaeggli To: Susan Hares , 'Andy Bierman' Cc: i2rs@ietf.org, 'Alissa Cooper' , 'Juergen Schoenwaelder' , i2rs-chairs@ietf.org, 'Kathleen Moriarty' , 'IESG' , 'Jeffrey Haas' , 'Joel Halpern' , 'Lou Berger' , draft-ietf-i2rs-protocol-security-requirements@ietf.org Message-ID: <82159be3-622a-e986-ac97-628313fa1d68@bogus.com> Subject: Re: [i2rs] Kathleen Moriarty's Discuss on draft-ietf-i2rs-protocol-security-requirements-07: (with DISCUSS and COMMENT) References: <013b01d1f8ee$31fa09b0$95ee1d10$@ndzh.com> <20160818073203.GA4338@elstar.local> <04b501d1f949$116c63e0$34452ba0$@ndzh.com> <20160818121405.GA5282@elstar.local> <051301d1f950$7739c670$65ad5350$@ndzh.com> <20160818130555.GA5366@elstar.local> <051701d1f952$c4ae0b30$4e0a2190$@ndzh.com> <6BCE198E4EAEFC4CAB45D75826EFB0761525CCD7@eusaamb101.ericsson.se> <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> <036801d1fa2a$466e9e00$d34bda00$@ndzh.com> <005501d1fa33$3d36e960$b7a4bc20$@ndzh.com> In-Reply-To: <005501d1fa33$3d36e960$b7a4bc20$@ndzh.com> --TLmGBBo9qOUxV3jTEefCLEnDMkbI5wmWm Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 8/19/16 9:03 AM, Susan Hares wrote: > Andy/Kathleen: >=20 > =20 >=20 > What do MTI and MTU standard for?=20 Mandatory to implement / use > =20 >=20 > Sue >=20 > =20 >=20 > *From:*i2rs [mailto:i2rs-bounces@ietf.org] *On Behalf Of *Andy Bierman > *Sent:* Friday, August 19, 2016 11:43 AM > *To:* Susan Hares > *Cc:* i2rs@ietf.org; Alissa Cooper; Juergen Schoenwaelder; > i2rs-chairs@ietf.org; Kathleen Moriarty; IESG; Jeffrey Haas; Joel > Halpern; Lou Berger; draft-ietf-i2rs-protocol-security-requirements@iet= f.org > *Subject:* Re: [i2rs] Kathleen Moriarty's Discuss on > draft-ietf-i2rs-protocol-security-requirements-07: (with DISCUSS and > COMMENT) >=20 > =20 >=20 > Hi, >=20 > =20 >=20 > That is simple. >=20 > There needs to be consensus on the syntax and semantics of each >=20 > statement in the YANG module. >=20 > =20 >=20 > Since security is MTI and MTU for NETCONF and RESTCONF, there >=20 > is no point debating which objects are OK without security. >=20 > =20 >=20 > Andy >=20 > =20 >=20 > =20 >=20 > =20 >=20 > On Fri, Aug 19, 2016 at 7:59 AM, Susan Hares > wrote: >=20 > Andy: >=20 > =20 >=20 > Thank you for your comments. Perhaps you can provide for the IESG the= > list of things that are needed to move a Yang module forward in the IET= F. =20 >=20 > =20 >=20 > Sue >=20 > =20 >=20 > *From:*Andy Bierman [mailto:andy@yumaworks.com ] > *Sent:* Friday, August 19, 2016 10:24 AM > *To:* Lou Berger > *Cc:* Susan Hares; Juergen Schoenwaelder; 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) >=20 > =20 >=20 > Hi, >=20 > =20 >=20 > I agree with Juergen. >=20 > There are already too many details that need consensus to move >=20 > a YANG module forward in the IETF. It takes too long already. >=20 > =20 >=20 > We could have been tagging MIB objects all along, but we don't. >=20 > Imagine if there was a debate for every single OBJECT-TYPE macro >=20 > "is this leaf OK for noAuth/noPriv?" >=20 > =20 >=20 > Are there even clear SEC-DIR guidelines on how one would decide this >=20 > debate in a WG? Does SEC-DIR really want to be flooded with review >=20 > requests so they become a bottleneck in YANG RFC publication process? >=20 > =20 >=20 > Standardized insecure access is a big change from what we have done >=20 > for 30 years. There could be a good reason why we left this out of sco= pe >=20 > all this time. >=20 > =20 >=20 > =20 >=20 > Andy >=20 > =20 >=20 > =20 >=20 > On Fri, Aug 19, 2016 at 5:20 AM, Lou Berger > wrote: >=20 >=20 > Sue, >=20 > My message said three things: >=20 > 1) Juergen's comment resonates with me. >=20 > 2) I think the current text is acceptable. >=20 > 3) I see changing the SHOULD to a MUST as problematic. > I understood one of the other messages on this thread proposing this > change which is what triggered my message. If I misunderstood that > message, feel free to interpret my message as supporting the current > text in question. >=20 > Note that I am only speaking for myself (including in my role as NETMOD= > co-chair) and not representing the consensus opinion of any WG. >=20 > Lou > On 8/19/2016 8:07 AM, Susan Hares wrote: >> Lou: >> >> I am clear that Juergen does not want not want to place transport > requirements within the data model for NETMOD. His opinion was > considered in the rough for the I2RS WG. If this requirement is a > problem for NETCONF/NETMOD, the text currently says: >> >> REQ-SEC-09 states: >> >> The default mode of transport is secure so data models SHOULD > clearly annotate what data nodes can be >> passed over an insecure connection. >> >> However, if this means the NETCONF/NETMOD WG will not even entertain > proposal for marking the insecure functions in yang text -- then the tw= o > WG (I2RS/NETMOD) have a problem and should stop this standardization > process going forward. >> >> Sue >> >> >> -----Original Message----- >> From: Lou Berger [mailto:lberger@labn.net ] >> Sent: Friday, August 19, 2016 7:34 AM >> To: Susan Hares; 'Juergen Schoenwaelder' >> Cc: i2rs@ietf.org ; 'Alissa Cooper'; > i2rs-chairs@ietf.org ; 'Kathleen Moriarty'= ; > 'IESG'; jhaas@pfrc.org ; '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) >> >> Sue, >> >> I don't see Juergen as arguing against model access via non-secure= > transport. I read his point as that the transport security requirements= > don't belong scattered within a data model. >> >> I have to say that from a model complexity (definition, process, > review, implementation - take your pick) , language and NETMOD co-chair= > perspective, his comment resonates with me. >> >> I think this makes the key text: >> >> The default mode of transport is >> secure so data models SHOULD clearly annotate what data nodes can b= e >> passed over an insecure connection. >> >> >> As this isn't a MUST, I personally think we can live with the text and= > we can debate the issue further in the context of specific solutions. = I > would strongly object to this being changed to a MUST, or if the > document is changed to make transport (security) requirements identifie= d > within data models a requirement. >> >> Lou >> >> On 8/19/2016 6:49 AM, Susan Hares wrote: >>> Juergen: >>> >>> You have laid out the two options: a) link the data-model to the > non-secure transport, and b) do not link the data to the non-secure > transport. I agree with you that past models did not link past SNMP > MIB data model to the transport. Existing NETCONF models do not link i= t > to the transport. As you have indicated, you disagreed in the I2RS WG= > and we found consensus was to include the non-secure transport. >>> >>> I2RS was created to build things as an interface to the routing > environment. The operators clearly informed the I2RS group of this > need during the requirement setting phase prior to the time I was > chair. The reason I continue to press for this capability is their > input, and the existing use cases I listed previously in this mail: >>> >>> a) public information - BGP route views, >>> b) specific well know up events - such as public-web site up >>> c) specific network service events - interface to particular public > LAN up. >>> >>> As you know, we do not have any I2RS data models that specify this > feature at this time. I suspect after we get through this lengthy > requirement phase, the operators may begin to specify new models that > have this feature. >>> >>> Sue >>> >>> -----Original Message----- >>> From: Juergen Schoenwaelder >>> [mailto:j.schoenwaelder@jacobs-university.de > ] >>> Sent: Friday, August 19, 2016 4:58 AM >>> To: Susan Hares >>> Cc: 'Alissa Cooper'; 'Joel Halpern'; i2rs@ietf.org > ; >>> i2rs-chairs@ietf.org ; 'Kathleen > Moriarty'; 'IESG'; jhaas@pfrc.org ; >>> 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) >>> >>> I repeat my technical argument: While there may be deployments where > non-secure transports may be reasonable to use, defining these > situations statically as part of data model schemas does not follow > established practices. The IETF has a long tradition of standardizing > data models that can be used in a variety of operational contexts and I= > do not see reasons why we should move away from that basic approach. >>> >>> /js >>> >>> On Thu, Aug 18, 2016 at 02:35:03PM -0400, Susan Hares wrote: >>>> Alissa: >>>> >>>> Just a little input you may not know. My background is 15 years > (1995-2010) developing a routing/switching platform (denoted as GateD)= > which was sold to over 200 companies. We developed XML and a binary > XML based product that configured this product. It could do 100K > configuration lines and reboot in less than a second on most hardware. = > We also provide status messages in secure streams and non-secure > streams. I sold early version of this code to companies that Alia ha= s > worked for - so she has personal viewed the code. At the height of > our work, our development team ran to 50 people which I directed (First= > as VP of Engineering, and then as CTO). It is due to this level of > experience that Alia selected me for the co-chair. Russ White has > understood Cisco's process, and has also directed software development > teams for routing. >>>> >>>> In order to freshen my direct experience with I2RS on open source > work, I am working on a publically available work in Quagga based on th= e > confD product suggested by Cisco. >>>> >>>> In contrast, Juergen is a university professor who has worked on > proto-types. He is not working on an implementation. I hope he will= =2E >>>> >>>> I hope you will consider this background in my response to your > comments below. >>>> >>>> Sue >>>> >>>> >>>> -----Original Message----- >>>> From: Alissa Cooper [mailto:alissa@cooperw.in > ] >>>> Sent: Thursday, August 18, 2016 12:54 PM >>>> To: Joel Halpern >>>> Cc: Susan Hares; Juergen Schoenwaelder; i2rs@ietf.org > ; >>>> i2rs-chairs@ietf.org ; Kathleen > Moriarty; IESG; jhaas@pfrc.org ; >>>> 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) >>>> >>>> Jumping in here because this is relevant to my DISCUSS, hope nobody > minds (but if you do, I can go back to the other thread). >>>> >>>>>> On Aug 18, 2016, at 10:30 AM, Joel Halpern > > wrote: >>>>>> >>>>>> Let me try a different take approach to this particular question. >>>>>> >>>>>> Let me start by putting aside the question of where things are > marked, and come back to that afterwards. >>>>>> >>>>>> There are a number of cases that I2RS has been asked to cover of > high rate telemetry data. This may be BGP update information, it may b= e > frequent information about line card activity. There are other cases, > some of which have been documented. >>>>>> >>>>>> While not completely insensitive, the operators have made clear > that they see protecting this data as unnecessary. While I would hope > over time to move to a domain where all of it is protect, that is not > trivial. As the I2RS Architecture points out, it is expected that what= > we describe as a single I2RS >communication between a client and agent > is actually associated with multiple channels of communication. >>>>>> >>>>>> Now, if you want to say that the I2RS protocol requirements cannot= > allow for unprotected channels, I guess we have disconnect between the > IESG and the WG. >>>>>> >>>>>> If we say that we can allow for unprotected channels, we then get > to the question of which data can be sent over such channels. While > architecturally I agree with Juergen that the model is a bad place to > specify it, the obverse is also true. Not having some limits on what > can be sent unprotected >causes concern about insufficient protection. = > If I recall correctly, earlier security reviews called us to task for > being too broad in what we allowed. >>>>>> >>>>>> So, if the IESG wants us to just allow it anywhere, because the >>>>>> model is an awkward place to define the limitation, I can live > with that. What I can't live with is being told both that the model is= > a bad place to define it and that there must be restrictions on what is= > sent unprotected, without any proposal on how we are to move forward. >>>>> Thank you Joel, this explanation helps me a lot. I think there is a= > disconnect about how the restrictions are expressed. From reading the > email traffic about this document, it strikes me that trying to express= > the restrictions programmatically doesn=E2=80=99t make much sense in th= is case. >>>>> I agree with Juergen that it will be challenging to make a judgment= > a priori in order to bake a restriction into a data model, because data= > that is considered sensitive enough to warrant a secure transport in on= e > deployment may not be considered sensitive in another deployment. >>>>> So for any data elements where there is any question at all about >>>>> whether they might be sensitive (i.e., any data elements that are > not already routinely made public), I would expect data model authors t= o > end up indicating that they may be sent over either secure or insecure > transport, which renders the indication not useful. >>>>> Perhaps it would make more sense then to just enumerate in the text= > the cases that motivate the inclusion of protocol support for insecure > transport: >>>>> >>>>> 1. For conveyance of information that is already routinely made pub= lic. >>>>> 2. For line card activity data where there is no likely upgrade > path to support secure transports in the foreseeable future. >>>>> >>>>> Then the normative requirements would be on clients and agents to > use secure transports unless those clients and agents are deployed wher= e > either of the operational circumstances above necessitate otherwise. >>>>> Alissa >>>> Point 1: >>>> I disagree with Juergen on the difficulty in specifying the sections= > of the yang modules. I have provided a suggested solution in: >>>> > https://tools.ietf.org/html/draft-hares-i2rs-protocol-strawman-03#secti= on-4.5.2. >>>> >>>> Given the mount schema functionality, we can mount ephemeral state > module which augment non-ephemeral state modules which are "in-secure o= nly". >>>> >>>> Point 2: >>>> I am willing to put an enumeration of the use cases in the protocol > requirement, but I would like to understand the purpose for the > enumeration. We are not doing a use case, but a requirements > document. This information appears to be a "use case" rather than a > technical description. What purpose are you looking for this > enumeration to server. Are you looking for the enumeration in SEC-REQ-= 08? >>>> >>>> Point 3: Could you review -08.txt on this topic, especially the text= > below. Given your comments, I believe I should change the last line to= > a MUST. >>>> New/ The default mode of transport is >>>> secure so data models MUST clearly annotate what data nodes can b= e >>>> passed over an insecure connection. >>>> / >>>> >>>> Sue >>>> >>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>>> As to the normative requirements (-08.txt) version: >>>> >>>> Section 3: >>>> >>>> I2RS allows the use of an insecure transport for portions of data= >>>> models that clearly indicate the use of an insecure transport. >>>> Operators deploying I2RS must determine if they want to populate = and >>>> deploy the portions of the data model which use insecure transpor= ts. >>>> >>>> In Section 3.2 in version -08.txt >>>> >>>> SEC-REQ-08: The I2RS protocol MUST be able to transfer data over = a >>>> secure transport and optionally MAY be able to transfer data over= a >>>> non-secure transport. A secure transport MUST provide data >>>> confidentiality, data integrity, and replay prevention. >>>> >>>> The default I2RS transport is a secure transport. >>>> >>>> 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. >>>> >>>> The configuration of ephemeral data in the I2RS Agent by the I2RS= >>>> client SHOULD be done over a secure transport. It is anticipated= >>>> that the passing of most I2RS ephemeral state operational status >>>> SHOULD be done over a secure transport. As >>>> [I-D.ietf-i2rs-ephemeral-state] notes, a data model MUST indicat= e >>>> whether the transport exchanging the data between I2RS client and= >>>> I2RS agent is secure or insecure. >>>> >>>> The default mode of transport is >>>> secure so data models SHOULD clearly annotate what data nodes can= be >>>> passed over an insecure connection. >>>> >>>>> Yours, >>>>> Joel >>>>> >>>>> -----Original Message----- >>>>> From: Susan Hares [mailto:shares@ndzh.com ]= >>>>> Sent: Thursday, August 18, 2016 9:17 AM >>>>> To: 'Juergen Schoenwaelder' > >>>>> Cc: i2rs@ietf.org ; i2rs-chairs@ietf.org > ; 'Kathleen Moriarty' >>>>> >; 'The IESG' >; >>>>> jhaas@pfrc.org ; >>>>> 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 an= d >>>>> COMMENT) >>>>> >>>>> Juergen and Kathleen: >>>>> >>>>> Let me proceed with two examples: BGP route views data model and > the event for the web-service data. >>>>> >>>>> The content of these data models are designated as exposed to > public. The routing system only populates the proposed BGP route views= > data model with the data destined for the BGP looking glass. The polic= y > on the routing system indicates what information gets transferred. The= > data model is completely available to the public. The Yang Doctors are= > going to review this by seeing the whole model is public and available > via non-secure means. >>>>> The security people are going to review this seeing that the whole > model is public, and available via an unprotect means. The fact the > data model is all public should simplify the review. >>>>> >>>>> An event from the I2RS RIB that a web-service route is up is the > second case. The I2RS RIB has an event based on policy that indicates = a > web-service route is up. The yang-1.1 doctors must review the content > of the event text to see it does not break privacy or provide too much >>>>> information The event mechanisms will need to work over secure > transport >>>>> and insecure transport. Most of the data will go over the secure > transport event stream. However, a small amount of information may go > over the insecure transport stream. >>>>> >>>>> First, let me know if my use cases are understandable. Second, let= > me know if you disagree with this use cases. >>>>> >>>>> Fyi - IESG approved the architecture with the insecure stream. >>>>> >>>>> Sue >>>>> >>>>> -----Original Message----- >>>>> From: Juergen Schoenwaelder >>>>> [mailto:j.schoenwaelder@jacobs-university.de > ] >>>>> Sent: Thursday, August 18, 2016 9:06 AM >>>>> To: Susan Hares >>>>> Cc: i2rs@ietf.org ; i2rs-chairs@ietf.org > ; 'Kathleen Moriarty'; 'The >>>>> IESG'; jhaas@pfrc.org ; >>>>> 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 an= d >>>>> COMMENT) >>>>> >>>>> I just do not know on which basis a data model writer can decide > whether a data object can be exposed in an unprotected way. How are YAN= G > doctors going to review this? How are security directorate people going= > to judge this? But as promised, I leave (still puzzled) now. >>>>> >>>>> /js >>>>> >>>>> On Thu, Aug 18, 2016 at 09:00:14AM -0400, Susan Hares wrote: >>>>>> Juergen: >>>>>> >>>>>> Yes, we seem to disagree on the value of making it hardwired in > the model. >>>>>> For me, the value is a common understanding of deployment >>>>>> distribution >>>>> such >>>>>> as the route-views. Since the operators argued strongly for this= > point, >>>>> I >>>>>> think the best idea is to get it working in code and then see if >>>>>> the deployment matches the requests. >>>>>> >>>>>> Sue >>>>>> >>>>>> -----Original Message----- >>>>>> From: i2rs [mailto:i2rs-bounces@ietf.org > ] On Behalf Of Juergen >>>>>> Schoenwaelder >>>>>> Sent: Thursday, August 18, 2016 8:14 AM >>>>>> To: Susan Hares >>>>>> Cc: i2rs@ietf.org ; i2rs-chairs@ietf.org > ; 'Kathleen Moriarty'; 'The >>>>>> IESG'; jhaas@pfrc.org ; >>>>>> 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) >>>>>> >>>>>> Sue, >>>>>> >>>>>> I still do not see why the 'mode of exposure' of data benefits fro= m >>>>>> being hard-wired in the data model. For me, it is a situational an= d >>>>>> deployment specific question. But I shut up here since I aired thi= s >>>>>> concern before (and we simply seem to disagree). >>>>>> >>>>>> /js >>>>>> >>>>>> On Thu, Aug 18, 2016 at 08:07:18AM -0400, Susan Hares wrote: >>>>>>> Juergen: >>>>>>> >>>>>>> My example is the looking glass servers for the BGP route views >>>>>>> project >>>>>>> (http://www.routeviews.org/) or a route indicating the presence o= f a >>>>>>> web-server that is public. For the BGP I2RS route, a yang model= > could >>>>>>> replace the looking glass function, and provide events for these > looking >>>>>>> glass functions. For the web-server route, an event be sent w= hen >>>>> that >>>>>>> one route is added. >>>>>>> >>>>>>> Sue >>>>>>> >>>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Juergen Schoenwaelder >>>>>>> [mailto:j.schoenwaelder@jacobs-university.de > ] >>>>>>> Sent: Thursday, August 18, 2016 3:32 AM >>>>>>> To: Susan Hares >>>>>>> Cc: 'Kathleen Moriarty'; 'The IESG'; jhaas@pfrc.org > ; >>>>>>> i2rs@ietf.org ; i2rs-chairs@ietf.org > ; >>>>>>> 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 Wed, Aug 17, 2016 at 09:16:48PM -0400, Susan Hares wrote: >>>>>>>> ----------------------------------------------------------------= - >>>>>>>> - >>>>>>>> -- >>>>>>>> -- >>>>>>>> COMMENT: >>>>>>>> ----------------------------------------------------------------= - >>>>>>>> - >>>>>>>> -- >>>>>>>> -- >>>>>>>> >>>>>>>>> Section 3: >>>>>>>>> Can you clarify the second to last sentence? Do you mean there= >>>>>>>>> are >>>>>>> sections that indicate an insecure transport should be used? >>>>>>>>> I2RS allows the use of an >>>>>>>>> insecure transport for portions of data models that clearly >>>>>>>>> indicate insecure transport. >>>>>>>>> Perhaps: >>>>>>>>> I2RS allows the use of an >>>>>>>>> insecure transport for portions of data models that clearly >>>>>>>>> indicate the use of an insecure transport. >>>>>>> I still wonder how a data model writer can reasonably decide >>>>>>> whether a piece of information can be shipped safely over an >>>>>>> insecure transport since this decision often depends on the >>>>>>> specifics of a deployment >>>>>> situation. >>>>>>> /js >>>>>>> >>>>>>> PS: I hope we do not end up with defining data multiple times (on= ce >>>>>>> for insecure transport and once for secured transports). >>>>>>> >>>>>>> -- >>>>>>> Juergen Schoenwaelder Jacobs University Bremen gGmbH >>>>>>> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | > Germany >>>>>>> Fax: +49 421 200 3103 >>>>>>> >>>>>>> _______________________________________________ >>>>>>> i2rs mailing list >>>>>>> i2rs@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/i2rs >>>>>> -- >>>>>> Juergen Schoenwaelder Jacobs University Bremen gGmbH >>>>>> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Ger= many >>>>>> Fax: +49 421 200 3103 = >>>>>> >>>>>> _______________________________________________ >>>>>> i2rs mailing list >>>>>> i2rs@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/i2rs >>>>>> >>>>> -- >>>>> Juergen Schoenwaelder Jacobs University Bremen gGmbH >>>>> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germ= any >>>>> Fax: +49 421 200 3103 >>>>> >> >> >> >=20 >=20 > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs >=20 > =20 >=20 > =20 >=20 --TLmGBBo9qOUxV3jTEefCLEnDMkbI5wmWm-- --nX1bUIRId4uk6rV9ETvt0HqX1OkShSAcW Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iEUEARECAAYFAle3L+wACgkQ8AA1q7Z/VrII5QCcD4J+t4+YqAE7u44Xz+AYH9+M FOQAmOVZN6+1MpSkHnFev/rH+m7Szb8= =iE9e -----END PGP SIGNATURE----- --nX1bUIRId4uk6rV9ETvt0HqX1OkShSAcW-- From nobody Fri Aug 19 09:15:25 2016 Return-Path: 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 79B9012D125; Fri, 19 Aug 2016 09:13:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.738 X-Spam-Level: * X-Spam-Status: No, score=1.738 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, RDNS_NONE=0.793] autolearn=no 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 CJkdgw1Ztihl; Fri, 19 Aug 2016 09:13:29 -0700 (PDT) Received: from hickoryhill-consulting.com (unknown [50.245.122.97]) (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 401D712D18A; Fri, 19 Aug 2016 09:13:28 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=184.157.82.170; From: "Susan Hares" To: "'Kathleen Moriarty'" References: <147146974235.23784.4389421535496134619.idtracker@ietfa.amsl.com> <013b01d1f8ee$31fa09b0$95ee1d10$@ndzh.com> <20160818073203.GA4338@elstar.local> <04b501d1f949$116c63e0$34452ba0$@ndzh.com> <20160818121405.GA5282@elstar.local> <051301d1f950$7739c670$65ad5350$@ndzh.com> <20160818130555.GA5366@elstar.local> <051701d1f952$c4ae0b30$4e0a2190$@ndzh.com> <6BCE198E4EAEFC4CAB45D75826EFB0761525CCD7@eusaamb101.ericsson.se> <003801d1f97f$3d16eb10$b744c130$@ndzh.com> <00dc01d1f988$f2cec280$d86c4780$@ndzh.com> <02b201d1fa1c$620e07d0$262a1770$@ndzh.com> <037501d1fa2a$a970fde0$fc52f9a0$@ndzh.com> <004 d01d1fa32$e30d 3f20$a927bd60$@ndzh.com> In-Reply-To: Date: Fri, 19 Aug 2016 12:12:10 -0400 Message-ID: <007801d1fa34$71141540$533c3fc0$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIa7Lz6VgZw6h2A0uGNzOgAA2Ic8QJ/RF5yARxv/coCD6d0AAIDKkFTAYlI9/gCaK/wXAMksAaNAmoTFCQCp9Oi8AIQlOgDAIZjbI0CaGRfrQGPw5JeAjmooLUBU45vXAKYJpUpAop25V4CQIq52gGudSksAidU2ZKedSuuMA== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: X-Mailman-Approved-At: Fri, 19 Aug 2016 09:15:16 -0700 Cc: i2rs@ietf.org, 'Alissa Cooper' , 'Juergen Schoenwaelder' , i2rs-chairs@ietf.org, 'Andy Bierman' , 'IESG' , 'Spencer Dawkins at IETF' , '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) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Aug 2016 16:13:31 -0000 Kathleen: Responding to:=20 KM: What I had asked earlier was if you could set a flag to say the data = wasn't confidential and didn't require integrity protection. The = operator could decide how they want to treat the data in that = circumstance and you might only put this flag in the data model in = places that you think the trigger is needed. Sue:=20 There is no mechanism to do this in Yang right now. There is a proposal = on how such a flag to be placed in the data model in places that need = this trigger in draft-hares-i2rs-protocol-strawman. Sue=20 -----Original Message----- From: Kathleen Moriarty [mailto:kathleen.moriarty.ietf@gmail.com]=20 Sent: Friday, August 19, 2016 12:10 PM To: Susan Hares Cc: i2rs@ietf.org; Alissa Cooper; Juergen Schoenwaelder; = i2rs-chairs@ietf.org; Andy Bierman; Spencer Dawkins at IETF; Jeffrey = Haas; Joel Halpern; = draft-ietf-i2rs-protocol-security-requirements@ietf.org; IESG Subject: Re: [i2rs] Kathleen Moriarty's Discuss on = draft-ietf-i2rs-protocol-security-requirements-07: (with DISCUSS and = COMMENT) Hi Sue, On Fri, Aug 19, 2016 at 12:01 PM, Susan Hares wrote: > Kathleen: > > First of all, I agree software knobs can always be set to multiple = settings in vendor settings. These settings may expand beyond standard = models, and operators may set these knobs as they wish. > > As a security person, do you really want a standardized knob that says = "run this model over non-secure transport"? KM: What I had asked earlier was if you could set a flag to say the data = wasn't confidential and didn't require integrity protection. The = operator could decide how they want to treat the data in that = circumstance and you might only put this flag in the data model in = places that you think the trigger is needed. Kathleen I do not want non-secure transport used for configuration and most = operational status. Corrupted data in the MGT plane can corrupt data traffic in the network. The bar for non-secure transport has to be very high with lots of warnings. Therefore an operator having a switch = to change attribute (such as a configuration attribute) from a secure = transport to a non-secure transport - should be discouraged. > > Yang 1.1 has three places to indicate: > 1) Attribute - on the yang syntax on an attribute (leaf node or leaf=20 > list), or portion of a schema, > 2) model - meta-data on yang modules contained in library. > 3) mount points - where multiple modules are mounted. > > [Andy or Juergen may provide more details on meta-data on yang module=20 > libraries. Lada or Lou can provide more details on mount points. ] > > Early in our discussion, NETCONF/NETMOD asked us to be specific in our = requirements. In the final discussion, we put Yang syntax so the level = could be attribute to provide the level of check you indicated. It = could go to any of these places if it works,. > > Does this discussion help? > > Sue > > -----Original Message----- > From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Kathleen=20 > Moriarty > Sent: Friday, August 19, 2016 11:27 AM > To: Susan Hares > Cc: i2rs@ietf.org; Alissa Cooper; Juergen Schoenwaelder;=20 > i2rs-chairs@ietf.org; Andy Bierman; Spencer Dawkins at IETF; Jeffrey=20 > Haas; Joel Halpern;=20 > draft-ietf-i2rs-protocol-security-requirements@ietf.org; IESG > Subject: Re: [i2rs] Kathleen Moriarty's Discuss on=20 > draft-ietf-i2rs-protocol-security-requirements-07: (with DISCUSS and=20 > COMMENT) > > On Fri, Aug 19, 2016 at 11:02 AM, Susan Hares wrote: >> Spencer: >> >> >> >> Thank you for asking. The time it would take is the time to move the = >> configuration knob to =E2=80=9Calways transport-secure=E2=80=9D for = this model. > > Why does the knob in the data model have to be set only one way? > Couldn't an attribute be used that you could change the setting for = that attribute rather than update the entire YANG module or is that not = possible in YANG? Couldn't this be a setting? > > Thanks, > Kathleen > >> >> >> >> Sue >> >> >> >> From: Spencer Dawkins at IETF [mailto:spencerdawkins.ietf@gmail.com] >> Sent: Friday, August 19, 2016 10:13 AM >> To: Susan Hares >> Cc: Andy Bierman; i2rs@ietf.org; Alissa Cooper; Juergen=20 >> Schoenwaelder; i2rs-chairs@ietf.org; Kathleen Moriarty; IESG; Jeffrey = >> Haas; Joel Halpern;=20 >> 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) >> >> >> >> Hi, Susan, >> >> >> >> On Fri, Aug 19, 2016 at 8:19 AM, Susan Hares wrote: >> >> Spencer: >> >> >> >> You as asking if: >> >> >> >> 1) Can Yang Models be revised? - there is a revision tag on the = Yang >> model. >> >> 2) How long it takes to deploy revised models in the Internet, = and >> old-models to be timed out? This is an operational question on yang = models >> that no one has experience to determine. Andy suggest that the = deployment >> time is 20 years (the Age of the Commercial internet =E2=80=93 1996 = -2016)=20 >> rather than the age of the Internet (1987-2016). >> >> >> >> However, the real question you should have asked is: Can operators=20 >> deploy models which are marked as =E2=80=9Cnon-secure = transport=E2=80=9D with a secure transport? >> >> >> >> I understood that part. My question was how long it would likely take = >> them to switch to a secure transport if they had deployed a model=20 >> with an insecure transport and figured out that was problematic. >> >> >> >> Thanks for the explanation. It was helpful. >> >> >> >> Spencer >> >> >> >> The answer is yes. In fact, several operators in I2RS stated that = all I2RS >> protocol communication needed to be secure. Therefore, if the = people >> found out that a model was problematic to be insecure =E2=80=93 = operators and=20 >> vendors would simply turn the deployment knob switch that says = =E2=80=93=20 >> deploy this always with a secure transport rather than optionally=20 >> allow an insecure transport. >> >> >> >> Now, the real problem is if the IESG has been cycling on this concept = =E2=80=93 the >> text needs to change. I=E2=80=99m going to go ahead and release a = version-09.txt >> that tries to make this very clear. Please comment on that text to = help >> make this clear. >> >> >> >> Sue >> >> >> >> >> >> From: Spencer Dawkins at IETF [mailto:spencerdawkins.ietf@gmail.com] >> Sent: Friday, August 19, 2016 9:08 AM >> To: Andy Bierman >> Cc: Susan Hares; i2rs@ietf.org; Alissa Cooper; Juergen Schoenwaelder; = >> i2rs-chairs@ietf.org; Kathleen Moriarty; IESG; Jeffrey Haas; Joel=20 >> 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) >> >> >> >> Dear All, >> >> >> >> On Thu, Aug 18, 2016 at 3:02 PM, Andy Bierman = wrote: >> >> >> >> >> >> On Thu, Aug 18, 2016 at 12:44 PM, Susan Hares = wrote: >> >> Andy: >> >> >> >> Thank you =E2=80=93 I thought it was on whether we could implement = insecure=20 >> transport in a Yang module. >> >> >> >> The requirement text you are working with is: >> >> >> >> SEC-REQ-08: The I2RS protocol MUST be able to transfer data over a >> secure transport and optionally MAY be able to transfer data over = a >> non-secure transport. >> >> >> >> I do not understand why approving the ok for non-secure transport for = >> some modules means the following to you: >> >> >> >> =E2=80=9C the IETF needs to agree that there could never possibly be = any=20 >> deployment that would not want to allow exposure of the data. >> >> Not now. Not 20 years from now.=E2=80=9D >> >> >> >> >> >> >> >> As I understand it, this requirement has another requirement=20 >> associated with it >> >> that says the data has to be identified as = OK-for-nonsecure-transport. >> >> >> >> An extension in the data model says that all instances of the object=20 >> in >> >> all possible deployments cannot be considered sensistive and=20 >> therefore >> >> needs disclosure protection. >> >> >> >> It may seem like even a simple octet counter is safe to send in the=20 >> clear, >> >> but not if that opens up correlation attacks. (e.g., I can send data = >> to some >> >> host. I can see that index 455992 is incrementing the in-octets=20 >> counters >> >> in a way that strongly correlates to my test traffic. Therefore I=20 >> can learn >> >> that arbitrary index 455992 is really John Doe or really suite #14, = etc. >> >> >> >> Since Kathleen asked what other ADs were thinking ... >> >> >> >> I'm current on this thread, as of the time I'm sending my note, but=20 >> replying to Andy's note because it's poking where I am poking. >> >> >> >> So, if (say) an octet counter is considered safe to send in the=20 >> clear, and a Yang model that reflects that is approved and widely=20 >> deployed, and then someone realizes that it's not safe to send in the = >> clear, is that a big deal to fix, and get the updated Yang model = widely deployed? >> >> >> >> My opinion on this point has a lot to do with how hard it is to=20 >> recover if a Yang model gets this wrong ... >> >> >> >> My apologies for not understanding enough about Yang and I2RS to be=20 >> able to answer my own question, of course. >> >> >> >> Thanks, >> >> >> >> Spencer >> >> > > > > -- > > Best regards, > Kathleen > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs > --=20 Best regards, Kathleen From nobody Fri Aug 19 10:01:37 2016 Return-Path: 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 BFFBA12B00D for ; Fri, 19 Aug 2016 09:32:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.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 isgr8wN5fyDB for ; Fri, 19 Aug 2016 09:32:24 -0700 (PDT) Received: from mail-ua0-x229.google.com (mail-ua0-x229.google.com [IPv6:2607:f8b0:400c:c08::229]) (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 E9CA612D0A7 for ; Fri, 19 Aug 2016 09:32:18 -0700 (PDT) Received: by mail-ua0-x229.google.com with SMTP id n59so88792554uan.2 for ; Fri, 19 Aug 2016 09:32:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=e5wGVEKvWarTDFQBgp00gxJSj1e82P78H/b1XkKB+3A=; b=Tw5ZoiVRaOd96xIrdEfYpc6uCFhH1GQCd7ELWwezkSkgRwk4sRT5W+6NjovHC6P4v1 21Y+aJB28btlE48lO4cXQa0Zm+Ic+WKhbRQdr/OWcrBoqOhqHssazEDN9Gai2b+Yg8cI hKYh+oFBErXPu4ctriok1dd8FlqsyAq9RrkFSzqpmMVgKGpGh1RbLA5xLmsSy85EFIYi jjbCp5rQPECdqXKn/W2gyB7yEgRHdobXfNoy6pHcM5eynM2SX6RF5v0FUDHTj9zScQ6i kS87TgSHNsRYCG+bbEcF8QP7gSdSDTgFIxbjgKj57n6RtPKTA/QvGWjzgfgc3W0SYOVm GA7g== 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; bh=e5wGVEKvWarTDFQBgp00gxJSj1e82P78H/b1XkKB+3A=; b=TP5+yHqM+kAj8uixP8u/L5FMaLrHMqXIFYQUqYGbYNc+18s7VCXi7NCCZgmneye887 8DPGVzBiHz/PkSVokXCZIdFv86I0LeKORSUH7wgtI6DhmP4PRI8W/C47F1ke8ZGomIz+ KbVuvRC/MG9+mIFy+FPD1cWnodv455Zk32fZp7DbqHU4rbxbS+wVyBcofYAQ5G4D6zjY yy+e8mApre/hxOvSvLZs5Ud2+7UCcoFVZavx9IoUtGEbHQFHiUX5G+NTuhjqcd7nPeAU JWkso2UdGZoHYcjbjGjponVvcDaeZ1RpSg6YTmdo0WZyL9T9RlE/HYi36xdtnO60cnDf VqtQ== X-Gm-Message-State: AEkoout6EGe4BQjAwHEThWvMgT7X++A8w+QKMrZuD2O0WwSIhRgJumbEqX7RqrtuYGgtIwUzuW+NBYnO98bwDQ== X-Received: by 10.31.139.207 with SMTP id n198mr4686706vkd.121.1471624337734; Fri, 19 Aug 2016 09:32:17 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.4.198 with HTTP; Fri, 19 Aug 2016 09:32:16 -0700 (PDT) In-Reply-To: <001501d1fa30$46d0ac70$d4720550$@ndzh.com> References: <013b01d1f8ee$31fa09b0$95ee1d10$@ndzh.com> <20160818073203.GA4338@elstar.local> <04b501d1f949$116c63e0$34452ba0$@ndzh.com> <20160818121405.GA5282@elstar.local> <051301d1f950$7739c670$65ad5350$@ndzh.com> <20160818130555.GA5366@elstar.local> <051701d1f952$c4ae0b30$4e0a2190$@ndzh.com> <6BCE198E4EAEFC4CAB45D75826EFB0761525CCD7@eusaamb101.ericsson.se> <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> <036801d1fa2a$466e9e00$d34bda00$@ndzh.com> <001501d1fa30$46d0ac70$d4720550$@ndzh.com> From: Andy Bierman Date: Fri, 19 Aug 2016 09:32:16 -0700 Message-ID: To: Susan Hares Content-Type: multipart/alternative; boundary=001a114584d0e4d711053a6f3d02 Archived-At: X-Mailman-Approved-At: Fri, 19 Aug 2016 10:01:33 -0700 Cc: "i2rs@ietf.org" , Alissa Cooper , Juergen Schoenwaelder , i2rs-chairs@ietf.org, Kathleen Moriarty , IESG , Jeffrey Haas , Joel Halpern , Lou Berger , 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Aug 2016 16:32:28 -0000 --001a114584d0e4d711053a6f3d02 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Fri, Aug 19, 2016 at 8:42 AM, Susan Hares wrote: > Andy: > > > > I have been thinking about your question for 30 minutes. Let me put dow= n > a few of my personal opinions: > > > > 1) Most (99%) of the ephemeral data models will not allow non-secure > transport. > > 2) If any ephemeral data models have an insecure section, the > review and consensus for a standards model should take longer. > > I hope we can streamline the normal Yang model review. [It would be nice > to streamline features additions for NETCONF/RESTCONF as well]. > > > I hope you are right that it will almost always be easy for a WG to decide this issue for each leaf. We already have "security tagging" in NACM, and this has not caused delays. This is the opposite decision -- Is this data so sensitive that the NACM default access control needs to block writes (nacm:default-deny-write) or block all access (nacm:default-deny-all)? These extensions are used in ietf-system.yang, not just in the NACM RFC. They can be used anywhere and a NACM implementation MUST enforce the extension semantics. If YANG Push had similar requirements (i.e, MUST NOT send data in the clear that is not tagged with the appropriate extension) and the review criteria is clear, then this approach should be OK. Andy 3) I prefer to have the non-secure sections of a data model moved to a > separate date model, and the data model marked as insecure. > > [I do not know if we could use the library function to mark the data mode= l > in meta-language.] > > However, until we complete the mount schema work =E2=80=93 I do not know = if this > is workable. > > > > Would it help if I changed version -08 to > > 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 be > non-confidential in the data model. > > / > > > > Sue > > > > > > *From:* i2rs [mailto:i2rs-bounces@ietf.org] *On Behalf Of *Susan Hares > *Sent:* Friday, August 19, 2016 10:59 AM > *To:* 'Andy Bierman'; 'Lou Berger' > *Cc:* i2rs@ietf.org; 'Alissa Cooper'; 'Juergen Schoenwaelder'; > 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) > > > > Andy: > > > > Thank you for your comments. Perhaps you can provide for the IESG the > list of things that are needed to move a Yang module forward in the IETF. > > > > Sue > > > > *From:* Andy Bierman [mailto:andy@yumaworks.com ] > *Sent:* Friday, August 19, 2016 10:24 AM > *To:* Lou Berger > *Cc:* Susan Hares; Juergen Schoenwaelder; 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) > > > > Hi, > > > > I agree with Juergen. > > There are already too many details that need consensus to move > > a YANG module forward in the IETF. It takes too long already. > > > > 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? > > > > Standardized insecure access is a big change from what we have done > > for 30 years. There could be a good reason why we left this out of scope > > all this time. > > > > > > Andy > > > > > > On Fri, Aug 19, 2016 at 5:20 AM, Lou Berger wrote: > > > Sue, > > My message said three things: > > 1) Juergen's comment resonates with me. > > 2) I think the current text is acceptable. > > 3) I see changing the SHOULD to a MUST as problematic. > I understood one of the other messages on this thread proposing this > change which is what triggered my message. If I misunderstood that > message, feel free to interpret my message as supporting the current > text in question. > > Note that I am only speaking for myself (including in my role as NETMOD > co-chair) and not representing the consensus opinion of any WG. > > Lou > On 8/19/2016 8:07 AM, Susan Hares wrote: > > Lou: > > > > I am clear that Juergen does not want not want to place transport > requirements within the data model for NETMOD. His opinion was considere= d > in the rough for the I2RS WG. If this requirement is a problem for > NETCONF/NETMOD, the text currently says: > > > > REQ-SEC-09 states: > > > > The default mode of transport is secure so data models SHOULD clearly > annotate what data nodes can be > > passed over an insecure connection. > > > > However, if this means the NETCONF/NETMOD WG will not even entertain > proposal for marking the insecure functions in yang text -- then the two = WG > (I2RS/NETMOD) have a problem and should stop this standardization process > going forward. > > > > Sue > > > > > > -----Original Message----- > > From: Lou Berger [mailto:lberger@labn.net] > > Sent: Friday, August 19, 2016 7:34 AM > > To: Susan Hares; 'Juergen Schoenwaelder' > > Cc: i2rs@ietf.org; 'Alissa Cooper'; i2rs-chairs@ietf.org; 'Kathleen > Moriarty'; 'IESG'; jhaas@pfrc.org; '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) > > > > Sue, > > > > I don't see Juergen as arguing against model access via non-secure > transport. I read his point as that the transport security requirements > don't belong scattered within a data model. > > > > I have to say that from a model complexity (definition, process, review= , > implementation - take your pick) , language and NETMOD co-chair > perspective, his comment resonates with me. > > > > I think this makes the key text: > > > > The default mode of transport is > > secure so data models SHOULD clearly annotate what data nodes can be > > passed over an insecure connection. > > > > > > As this isn't a MUST, I personally think we can live with the text and > we can debate the issue further in the context of specific solutions. I > would strongly object to this being changed to a MUST, or if the document > is changed to make transport (security) requirements identified within da= ta > models a requirement. > > > > Lou > > > > On 8/19/2016 6:49 AM, Susan Hares wrote: > >> Juergen: > >> > >> You have laid out the two options: a) link the data-model to the > non-secure transport, and b) do not link the data to the non-secure > transport. I agree with you that past models did not link past SNMP MIB > data model to the transport. Existing NETCONF models do not link it to t= he > transport. As you have indicated, you disagreed in the I2RS WG and we > found consensus was to include the non-secure transport. > >> > >> I2RS was created to build things as an interface to the routing > environment. The operators clearly informed the I2RS group of this need > during the requirement setting phase prior to the time I was chair. The > reason I continue to press for this capability is their input, and the > existing use cases I listed previously in this mail: > >> > >> a) public information - BGP route views, > >> b) specific well know up events - such as public-web site up > >> c) specific network service events - interface to particular public LA= N > up. > >> > >> As you know, we do not have any I2RS data models that specify this > feature at this time. I suspect after we get through this lengthy > requirement phase, the operators may begin to specify new models that hav= e > this feature. > >> > >> Sue > >> > >> -----Original Message----- > >> From: Juergen Schoenwaelder > >> [mailto:j.schoenwaelder@jacobs-university.de] > >> Sent: Friday, August 19, 2016 4:58 AM > >> To: Susan Hares > >> Cc: 'Alissa Cooper'; 'Joel Halpern'; i2rs@ietf.org; > >> i2rs-chairs@ietf.org; 'Kathleen Moriarty'; 'IESG'; jhaas@pfrc.org; > >> 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) > >> > >> I repeat my technical argument: While there may be deployments where > non-secure transports may be reasonable to use, defining these situations > statically as part of data model schemas does not follow established > practices. The IETF has a long tradition of standardizing data models tha= t > can be used in a variety of operational contexts and I do not see reasons > why we should move away from that basic approach. > >> > >> /js > >> > >> On Thu, Aug 18, 2016 at 02:35:03PM -0400, Susan Hares wrote: > >>> Alissa: > >>> > >>> Just a little input you may not know. My background is 15 years > (1995-2010) developing a routing/switching platform (denoted as GateD) > which was sold to over 200 companies. We developed XML and a binary XML > based product that configured this product. It could do 100K configurati= on > lines and reboot in less than a second on most hardware. We also provide > status messages in secure streams and non-secure streams. I sold early > version of this code to companies that Alia has worked for - so she has > personal viewed the code. At the height of our work, our development te= am > ran to 50 people which I directed (First as VP of Engineering, and then a= s > CTO). It is due to this level of experience that Alia selected me for the > co-chair. Russ White has understood Cisco's process, and has also > directed software development teams for routing. > >>> > >>> In order to freshen my direct experience with I2RS on open source > work, I am working on a publically available work in Quagga based on the > confD product suggested by Cisco. > >>> > >>> In contrast, Juergen is a university professor who has worked on > proto-types. He is not working on an implementation. I hope he will. > >>> > >>> I hope you will consider this background in my response to your > comments below. > >>> > >>> Sue > >>> > >>> > >>> -----Original Message----- > >>> From: Alissa Cooper [mailto:alissa@cooperw.in] > >>> Sent: Thursday, August 18, 2016 12:54 PM > >>> To: Joel Halpern > >>> Cc: Susan Hares; Juergen Schoenwaelder; i2rs@ietf.org; > >>> i2rs-chairs@ietf.org; Kathleen Moriarty; IESG; jhaas@pfrc.org; > >>> 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) > >>> > >>> Jumping in here because this is relevant to my DISCUSS, hope nobody > minds (but if you do, I can go back to the other thread). > >>> > >>>>> On Aug 18, 2016, at 10:30 AM, Joel Halpern < > joel.halpern@ericsson.com> wrote: > >>>>> > >>>>> Let me try a different take approach to this particular question. > >>>>> > >>>>> Let me start by putting aside the question of where things are > marked, and come back to that afterwards. > >>>>> > >>>>> There are a number of cases that I2RS has been asked to cover of > high rate telemetry data. This may be BGP update information, it may be > frequent information about line card activity. There are other cases, so= me > of which have been documented. > >>>>> > >>>>> While not completely insensitive, the operators have made clear tha= t > they see protecting this data as unnecessary. While I would hope over ti= me > to move to a domain where all of it is protect, that is not trivial. As > the I2RS Architecture points out, it is expected that what we describe as= a > single I2RS >communication between a client and agent is actually > associated with multiple channels of communication. > >>>>> > >>>>> Now, if you want to say that the I2RS protocol requirements cannot > allow for unprotected channels, I guess we have disconnect between the IE= SG > and the WG. > >>>>> > >>>>> If we say that we can allow for unprotected channels, we then get t= o > the question of which data can be sent over such channels. While > architecturally I agree with Juergen that the model is a bad place to > specify it, the obverse is also true. Not having some limits on what can > be sent unprotected >causes concern about insufficient protection. If I > recall correctly, earlier security reviews called us to task for being to= o > broad in what we allowed. > >>>>> > >>>>> So, if the IESG wants us to just allow it anywhere, because the > >>>>> model is an awkward place to define the limitation, I can live with > that. What I can't live with is being told both that the model is a bad > place to define it and that there must be restrictions on what is sent > unprotected, without any proposal on how we are to move forward. > >>>> Thank you Joel, this explanation helps me a lot. I think there is a > disconnect about how the restrictions are expressed. From reading the ema= il > traffic about this document, it strikes me that trying to express the > restrictions programmatically doesn=E2=80=99t make much sense in this cas= e. > >>>> I agree with Juergen that it will be challenging to make a judgment = a > priori in order to bake a restriction into a data model, because data tha= t > is considered sensitive enough to warrant a secure transport in one > deployment may not be considered sensitive in another deployment. > >>>> So for any data elements where there is any question at all about > >>>> whether they might be sensitive (i.e., any data elements that are no= t > already routinely made public), I would expect data model authors to end = up > indicating that they may be sent over either secure or insecure transport= , > which renders the indication not useful. > >>>> Perhaps it would make more sense then to just enumerate in the text > the cases that motivate the inclusion of protocol support for insecure > transport: > >>>> > >>>> 1. For conveyance of information that is already routinely made > public. > >>>> 2. For line card activity data where there is no likely upgrade path > to support secure transports in the foreseeable future. > >>>> > >>>> Then the normative requirements would be on clients and agents to us= e > secure transports unless those clients and agents are deployed where eith= er > of the operational circumstances above necessitate otherwise. > >>>> Alissa > >>> Point 1: > >>> I disagree with Juergen on the difficulty in specifying the sections > of the yang modules. I have provided a suggested solution in: > >>> https://tools.ietf.org/html/draft-hares-i2rs-protocol- > strawman-03#section-4.5.2. > >>> > >>> Given the mount schema functionality, we can mount ephemeral state > module which augment non-ephemeral state modules which are "in-secure onl= y". > >>> > >>> Point 2: > >>> I am willing to put an enumeration of the use cases in the protocol > requirement, but I would like to understand the purpose for the > enumeration. We are not doing a use case, but a requirements document. > This information appears to be a "use case" rather than a technical > description. What purpose are you looking for this enumeration to > server. Are you looking for the enumeration in SEC-REQ-08? > >>> > >>> Point 3: Could you review -08.txt on this topic, especially the text > below. Given your comments, I believe I should change the last line to a > MUST. > >>> New/ The default mode of transport is > >>> secure so data models MUST clearly annotate what data nodes can be > >>> passed over an insecure connection. > >>> / > >>> > >>> Sue > >>> > >>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >>> As to the normative requirements (-08.txt) version: > >>> > >>> Section 3: > >>> > >>> I2RS allows the use of an insecure transport for portions of data > >>> models that clearly indicate the use of an insecure transport. > >>> Operators deploying I2RS must determine if they want to populate a= nd > >>> deploy the portions of the data model which use insecure transport= s. > >>> > >>> In Section 3.2 in version -08.txt > >>> > >>> SEC-REQ-08: The I2RS protocol MUST be able to transfer data over a > >>> secure transport and optionally MAY be able to transfer data over = a > >>> non-secure transport. A secure transport MUST provide data > >>> confidentiality, data integrity, and replay prevention. > >>> > >>> The default I2RS transport is a secure transport. > >>> > >>> A non-secure transport can be used for publishing telemetry data o= r > >>> other operational state that was specifically indicated to non- > >>> confidential in the data model in the Yang syntax. > >>> > >>> The configuration of ephemeral data in the I2RS Agent by the I2RS > >>> client SHOULD be done over a secure transport. It is anticipated > >>> that the passing of most I2RS ephemeral state operational status > >>> SHOULD be done over a secure transport. As > >>> [I-D.ietf-i2rs-ephemeral-state] notes, a data model MUST indicate > >>> whether the transport exchanging the data between I2RS client and > >>> I2RS agent is secure or insecure. > >>> > >>> The default mode of transport is > >>> secure so data models SHOULD clearly annotate what data nodes can = be > >>> passed over an insecure connection. > >>> > >>>> Yours, > >>>> Joel > >>>> > >>>> -----Original Message----- > >>>> From: Susan Hares [mailto:shares@ndzh.com] > >>>> Sent: Thursday, August 18, 2016 9:17 AM > >>>> To: 'Juergen Schoenwaelder' > >>>> Cc: i2rs@ietf.org; i2rs-chairs@ietf.org; 'Kathleen Moriarty' > >>>> ; 'The IESG' ; > >>>> jhaas@pfrc.org; > >>>> 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) > >>>> > >>>> Juergen and Kathleen: > >>>> > >>>> Let me proceed with two examples: BGP route views data model and the > event for the web-service data. > >>>> > >>>> The content of these data models are designated as exposed to > public. The routing system only populates the proposed BGP route views > data model with the data destined for the BGP looking glass. The policy = on > the routing system indicates what information gets transferred. The data > model is completely available to the public. The Yang Doctors are going = to > review this by seeing the whole model is public and available via > non-secure means. > >>>> The security people are going to review this seeing that the whole > model is public, and available via an unprotect means. The fact the data > model is all public should simplify the review. > >>>> > >>>> An event from the I2RS RIB that a web-service route is up is the > second case. The I2RS RIB has an event based on policy that indicates a > web-service route is up. The yang-1.1 doctors must review the content of > the event text to see it does not break privacy or provide too much > >>>> information The event mechanisms will need to work over secure > transport > >>>> and insecure transport. Most of the data will go over the secure > transport event stream. However, a small amount of information may go ove= r > the insecure transport stream. > >>>> > >>>> First, let me know if my use cases are understandable. Second, let > me know if you disagree with this use cases. > >>>> > >>>> Fyi - IESG approved the architecture with the insecure stream. > >>>> > >>>> Sue > >>>> > >>>> -----Original Message----- > >>>> From: Juergen Schoenwaelder > >>>> [mailto:j.schoenwaelder@jacobs-university.de] > >>>> Sent: Thursday, August 18, 2016 9:06 AM > >>>> To: Susan Hares > >>>> Cc: i2rs@ietf.org; i2rs-chairs@ietf.org; 'Kathleen Moriarty'; 'The > >>>> IESG'; jhaas@pfrc.org; > >>>> 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) > >>>> > >>>> I just do not know on which basis a data model writer can decide > whether a data object can be exposed in an unprotected way. How are YANG > doctors going to review this? How are security directorate people going t= o > judge this? But as promised, I leave (still puzzled) now. > >>>> > >>>> /js > >>>> > >>>> On Thu, Aug 18, 2016 at 09:00:14AM -0400, Susan Hares wrote: > >>>>> Juergen: > >>>>> > >>>>> Yes, we seem to disagree on the value of making it hardwired in the > model. > >>>>> For me, the value is a common understanding of deployment > >>>>> distribution > >>>> such > >>>>> as the route-views. Since the operators argued strongly for this > point, > >>>> I > >>>>> think the best idea is to get it working in code and then see if > >>>>> the deployment matches the requests. > >>>>> > >>>>> Sue > >>>>> > >>>>> -----Original Message----- > >>>>> From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Juergen > >>>>> Schoenwaelder > >>>>> Sent: Thursday, August 18, 2016 8:14 AM > >>>>> To: Susan Hares > >>>>> Cc: i2rs@ietf.org; i2rs-chairs@ietf.org; 'Kathleen Moriarty'; 'The > >>>>> IESG'; jhaas@pfrc.org; > >>>>> 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) > >>>>> > >>>>> Sue, > >>>>> > >>>>> I still do not see why the 'mode of exposure' of data benefits from > >>>>> being hard-wired in the data model. For me, it is a situational and > >>>>> deployment specific question. But I shut up here since I aired this > >>>>> concern before (and we simply seem to disagree). > >>>>> > >>>>> /js > >>>>> > >>>>> On Thu, Aug 18, 2016 at 08:07:18AM -0400, Susan Hares wrote: > >>>>>> Juergen: > >>>>>> > >>>>>> My example is the looking glass servers for the BGP route views > >>>>>> project > >>>>>> (http://www.routeviews.org/) or a route indicating the presence of > a > >>>>>> web-server that is public. For the BGP I2RS route, a yang model > could > >>>>>> replace the looking glass function, and provide events for these > looking > >>>>>> glass functions. For the web-server route, an event be sent wh= en > >>>> that > >>>>>> one route is added. > >>>>>> > >>>>>> Sue > >>>>>> > >>>>>> > >>>>>> -----Original Message----- > >>>>>> From: Juergen Schoenwaelder > >>>>>> [mailto:j.schoenwaelder@jacobs-university.de] > >>>>>> Sent: Thursday, August 18, 2016 3:32 AM > >>>>>> To: Susan Hares > >>>>>> Cc: 'Kathleen Moriarty'; 'The IESG'; jhaas@pfrc.org; > >>>>>> i2rs@ietf.org; i2rs-chairs@ietf.org; > >>>>>> 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 Wed, Aug 17, 2016 at 09:16:48PM -0400, Susan Hares wrote: > >>>>>>> ----------------------------------------------------------------- > >>>>>>> - > >>>>>>> -- > >>>>>>> -- > >>>>>>> COMMENT: > >>>>>>> ----------------------------------------------------------------- > >>>>>>> - > >>>>>>> -- > >>>>>>> -- > >>>>>>> > >>>>>>>> Section 3: > >>>>>>>> Can you clarify the second to last sentence? Do you mean there > >>>>>>>> are > >>>>>> sections that indicate an insecure transport should be used? > >>>>>>>> I2RS allows the use of an > >>>>>>>> insecure transport for portions of data models that clearly > >>>>>>>> indicate insecure transport. > >>>>>>>> Perhaps: > >>>>>>>> I2RS allows the use of an > >>>>>>>> insecure transport for portions of data models that clearly > >>>>>>>> indicate the use of an insecure transport. > >>>>>> I still wonder how a data model writer can reasonably decide > >>>>>> whether a piece of information can be shipped safely over an > >>>>>> insecure transport since this decision often depends on the > >>>>>> specifics of a deployment > >>>>> situation. > >>>>>> /js > >>>>>> > >>>>>> PS: I hope we do not end up with defining data multiple times (onc= e > >>>>>> for insecure transport and once for secured transports). > >>>>>> > >>>>>> -- > >>>>>> Juergen Schoenwaelder Jacobs University Bremen gGmbH > >>>>>> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | > Germany > >>>>>> Fax: +49 421 200 3103 > >>>>>> > >>>>>> _______________________________________________ > >>>>>> i2rs mailing list > >>>>>> i2rs@ietf.org > >>>>>> https://www.ietf.org/mailman/listinfo/i2rs > >>>>> -- > >>>>> Juergen Schoenwaelder Jacobs University Bremen gGmbH > >>>>> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | > Germany > >>>>> Fax: +49 421 200 3103 > >>>>> > >>>>> _______________________________________________ > >>>>> i2rs mailing list > >>>>> i2rs@ietf.org > >>>>> https://www.ietf.org/mailman/listinfo/i2rs > >>>>> > >>>> -- > >>>> Juergen Schoenwaelder Jacobs University Bremen gGmbH > >>>> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germa= ny > >>>> Fax: +49 421 200 3103 > >>>> > > > > > > > > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs > > > --001a114584d0e4d711053a6f3d02 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Fri, Aug 19, 2016 at 8:42 AM, Susan Hares <shares@ndzh.com> wrote:

=C2=A0

I have been thinking about your question for 30 minutes.=C2= =A0=C2=A0 Let me put down a few of my personal opinions:

=C2=A0

1)=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Most (99%) of the ephemera= l data models will not allow non-secure transport.

2)=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0If any ephemeral data models hav= e an insecure section, the review and consensus for a standards model shoul= d take longer.

I hop= e we can streamline the normal Yang model review.=C2=A0 [It would be nice t= o streamline features additions for NETCONF/RESTCONF as well]. =C2=A0

=C2=A0


I hope you a= re right that it will almost always be easy for a WG
to decide th= is issue for each leaf.

We already have "secu= rity tagging" in NACM, and this has not caused delays.
This = is the opposite decision -- Is this data so sensitive that the NACM default=
access control needs to block writes (nacm:default-deny-write) o= r block all access
(nacm:default-deny-all)?

<= div>These extensions are used in ietf-system.yang, not just in the NACM RFC= .
They can be used anywhere and a NACM implementation MUST enforc= e
the extension semantics.

If YANG Push = had similar requirements (i.e, MUST NOT send data in the clear
th= at is not tagged with the appropriate extension) and the review criteria is= clear,
then this approach should be OK.


Andy


3)=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 I prefer to have the non-secure sections of a data = model moved to a separate date model, and the data model marked as insecure= . =C2=A0

[I do not kn= ow if we could use the library function to mark the data model in meta-lang= uage.]

However, until= we complete the mount schema work =E2=80=93 I do not know if this is worka= ble.

=C2=A0

Would it help if I changed version -08 to <= /p>

Old/

=C2=A0=C2=A0 A non-secure transport can= be used for publishing telemetry data or

=C2=A0=C2=A0 other operational state that was specific= ally indicated to non-

=C2=A0=C2=A0 confidential in the data model in the Yang syntax. /

New:/

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 A= non-secure transport can be used for publishing telemetry data or other

= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0Operational state that was specifically indic= ated to be non-confidential in the data model.

=C2=A0=C2=A0=C2=A0 /

= =C2=A0

S= ue

=C2=A0

=C2=A0

From: i2rs [mailto:i2rs-bounces@ietf.org] On= Behalf Of Susan Hares
Sent: Friday, August 19, 2016 10:59 AM=
To: 'Andy Bierman'; 'Lou Berger'
Cc: <= a href=3D"mailto:i2rs@ietf.org" target=3D"_blank">i2rs@ietf.org; 'A= lissa Cooper'; 'Juergen Schoenwaelder'; i2rs-chairs@ietf.org; 'Kathleen = Moriarty'; 'IESG'; 'Jeffrey Haas'; 'Joel Halpern= 9;; draft-ietf-i2rs-protocol-security-requirements@i= etf.org
Subject: Re: [i2rs] Kathleen Moriarty's Discuss o= n draft-ietf-i2rs-protocol-security-requirements-07: (with DISCUSS and= COMMENT)

=C2=A0

Andy: <= u>

<= u>=C2=A0

Thank you for your comments.=C2=A0=C2=A0 Perhaps you can provide for t= he IESG the list of things that are needed to move a Yang module forward in= the IETF.=C2=A0=C2=A0

=C2=A0

Sue

=C2=A0

From: Andy Bierman [mailto:andy@yumaworks.co= m]
Sent: Friday, August 19, 2016 10:24 AM
To: Lou = Berger
Cc: Susan Hares; Juergen Schoenwaelder; i2rs@ietf.org; Alissa Cooper; i2rs-chairs@ietf.org= ; Kathleen Moriarty; IESG; Jeffrey Haas; Joel Halpern; dr= aft-ietf-i2rs-protocol-security-requirements@ietf.org
Subjec= t: Re: [i2rs] Kathleen Moriarty's Discuss on draft-ietf-i2rs-protoc= ol-security-requirements-07: (with DISCUSS and COMMENT)<= /span>

=C2=A0

Hi,

=C2=A0=

I agree with Juergen.

There are already too many details = that need consensus to move

a YANG module forward in the IETF.=C2=A0 It takes too long already.<= /u>

=C2=A0

We could have been tagging MIB objects all a= long, but we don't.

= Imagine if there was a debate for every single OBJECT-TYPE macro<= /u>

"is this leaf OK for noAuth/n= oPriv?"

=C2= =A0

Are there even clear SEC-DI= R guidelines on how one would decide this

debate in a WG? Does SEC-DIR really want to be flooded wi= th review

requests so th= ey become a bottleneck in YANG RFC publication process?

=C2=A0

Standardized insecure access is a big change from what we ha= ve done

for 30 years.=C2= =A0 There could be a good reason why we left this out of scope

all this time.

=C2=A0

=C2=A0

An= dy

=C2=A0<= /p>

=C2=A0

On Fri, Aug 19, 2016 at 5:20 AM, Lou Berger <lberger@labn.net> wro= te:


Sue,

My message said= three things:

1) Juergen's comment resonates with me.

2)= I think the current text is acceptable.

3) I see changing the SHOUL= D to a MUST as problematic.
I understood one of the other messages on th= is thread proposing this
change which is what triggered my message.=C2= =A0 =C2=A0If I misunderstood that
message, feel free to interpret my mes= sage as supporting the current
text in question.

Note that I am o= nly speaking for myself (including in my role as NETMOD
co-chair) and no= t representing the consensus opinion of any WG.

Lou
On 8/19/2016 = 8:07 AM, Susan Hares wrote:
> Lou:
>
> I am clear that Ju= ergen does not want not want to place transport requirements within the dat= a model for NETMOD.=C2=A0 His opinion was considered in the rough for the I= 2RS WG. If this requirement is a problem for NETCONF/NETMOD,=C2=A0 the text= currently says:
>
> REQ-SEC-09 states:
>
>=C2=A0 = =C2=A0The default mode of transport is secure so data models SHOULD clearly= annotate what data nodes can be
>=C2=A0 =C2=A0 passed over an insecu= re connection.
>
> However, if this means the NETCONF/NETMOD WG= will not even entertain proposal for marking the insecure functions in yan= g text -- then the two WG (I2RS/NETMOD) have a problem and should stop this= standardization process going forward.
>
> Sue
>
>=
> -----Original Message-----
> From: Lou Berger [mailto:lberger@labn.net]
&g= t; Sent: Friday, August 19, 2016 7:34 AM
> To: Susan Hares; 'Juer= gen Schoenwaelder'
> Cc: i2rs@ietf.org; 'Alissa Cooper'; i2rs-chairs@ietf.org; 'Kathl= een Moriarty'; 'IESG'; jhaas@pfrc.org; 'Joel Halpern'; d= raft-ietf-i2rs-protocol-security-requirements@ietf.org
> Sub= ject: Re: [i2rs] Kathleen Moriarty's Discuss on draft-ietf-i2rs-protoco= l-security-requirements-07: (with DISCUSS and COMMENT)
>
>= Sue,
>
>=C2=A0 =C2=A0 =C2=A0I don't see Juergen as arguing= against model access via non-secure transport. I read his point as that th= e transport security requirements don't belong scattered within a data = model.
>
> I have to say that from a model complexity (definiti= on, process, review, implementation - take your pick) , language and NETMOD= co-chair perspective, his comment resonates with me.
>
> I thi= nk this makes the key text:
>
>=C2=A0 =C2=A0 The default mode o= f transport is
>=C2=A0 =C2=A0 secure so data models SHOULD clearly an= notate what data nodes can be
>=C2=A0 =C2=A0 passed over an insecure = connection.
>
>
> As this isn't a MUST, I personally = think we can live with the text and we can debate the issue further in the = context of specific solutions.=C2=A0 I would strongly object to this being = changed to a MUST, or if the document is changed to make transport (securit= y) requirements identified within data models a requirement.
>
>= ; Lou
>
> On 8/19/2016 6:49 AM, Susan Hares wrote:
>> = Juergen:
>>
>> You have laid out the two options:=C2=A0 = =C2=A0a) link the data-model to the non-secure transport, and b) do not lin= k the data to the non-secure transport.=C2=A0 =C2=A0I agree with you that p= ast models did not link past SNMP MIB data model to the transport.=C2=A0 Ex= isting NETCONF models do not link it to the transport.=C2=A0 =C2=A0As you h= ave indicated, you disagreed in the I2RS WG and we found consensus was to i= nclude the non-secure transport.
>>
>> I2RS was created t= o build things as an interface to the routing environment.=C2=A0 =C2=A0The = operators clearly informed the I2RS group of this need during the requireme= nt setting phase prior to the time I was chair.=C2=A0 The reason I continue= to press for this capability is their input, and the existing use cases I = listed previously in this mail:
>>
>> a) public informati= on - BGP route views,
>> b) specific well know up events - such as= public-web site up
>> c) specific network service events - interf= ace to particular public LAN up.
>>
>> As you know, we do= not have any I2RS data models that specify this feature at this time.=C2= =A0 =C2=A0I suspect after we get through this lengthy requirement phase, th= e operators may begin to specify new models that have this feature.
>= >
>> Sue
>>
>> -----Original Message-----
= >> From: Juergen Schoenwaelder
>> [mailto:j.schoenwaelder@jacobs-university.de]
>> Sent: Friday, August 19, 2016 4:58 = AM
>> To: Susan Hares
>> Cc: 'Alissa Cooper'; = 9;Joel Halpern'; i2r= s@ietf.org;
>> i2rs-chairs@ietf.org; 'Kathleen Moriarty'; 'IES= G'; jhaas@pfrc.org<= /a>;
>> draft-ietf-i2rs-protocol-security-r= equirements@ietf.org
>> Subject: Re: [i2rs] Kathleen Moriarty&= #39;s Discuss on
>> draft-ietf-i2rs-protocol-security-require= ments-07: (with DISCUSS and
>> COMMENT)
>>
>> I = repeat my technical argument: While there may be deployments where non-secu= re transports may be reasonable to use, defining these situations staticall= y as part of data model schemas does not follow established practices. The = IETF has a long tradition of standardizing data models that can be used in = a variety of operational contexts and I do not see reasons why we should mo= ve away from that basic approach.
>>
>> /js
>>>> On Thu, Aug 18, 2016 at 02:35:03PM -0400, Susan Hares wrote:
= >>> Alissa:
>>>
>>> Just a little input yo= u may not know.=C2=A0 My background is 15 years (1995-2010)=C2=A0 developin= g a routing/switching platform (denoted as GateD) which was sold to over 20= 0 companies.=C2=A0 =C2=A0We developed XML and a binary XML based product th= at configured this product.=C2=A0 It could do 100K configuration lines and = reboot in less than a second on most hardware.=C2=A0 We also provide status= messages in secure streams and non-secure streams.=C2=A0 =C2=A0 I sold ear= ly version of this code to companies that Alia has worked for=C2=A0 - so sh= e has personal viewed the code.=C2=A0 =C2=A0At the height of our work, our = development team ran to 50 people which I directed (First as VP of Engineer= ing, and then as CTO). It is due to this level of experience that Alia sele= cted me for the co-chair.=C2=A0 =C2=A0Russ White has understood Cisco's= process, and has also directed software development teams for routing.
= >>>
>>> In order to freshen my direct experience with = I2RS on open source work, I am working on a publically available work in Qu= agga based on the confD product suggested by Cisco.
>>>
>= >> In contrast, Juergen is a university professor who has worked on p= roto-types.=C2=A0 =C2=A0He is not working on an implementation.=C2=A0 =C2= =A0I hope he will.
>>>
>>> I hope you will consider= this background in my response to your comments below.
>>>
= >>> Sue
>>>
>>>
>>> -----Origi= nal Message-----
>>> From: Alissa Cooper [mailto:alissa@cooperw.in]
>>= > Sent: Thursday, August 18, 2016 12:54 PM
>>> To: Joel Halp= ern
>>> Cc: Susan Hares; Juergen Schoenwaelder; i2rs@ietf.org;
>>> i2rs-chairs@ietf.org<= /a>; Kathleen Moriarty; IESG; jhaas@pfrc.org;
>>> draft-ietf-i2r= s-protocol-security-requirements@ietf.org
>>> Subject:= Re: [i2rs] Kathleen Moriarty's Discuss on
>>> draft-ietf-i= 2rs-protocol-security-requirements-07: (with DISCUSS and
>>&g= t; COMMENT)
>>>
>>> Jumping in here because this is= relevant to my DISCUSS, hope nobody minds (but if you do, I can go back to= the other thread).
>>>
>>>>> On Aug 18, 2016= , at 10:30 AM, Joel Halpern <joel.halpern@ericsson.com> wrote:
>>>= ;>>
>>>>> Let me try a different take approach to t= his particular question.
>>>>>
>>>>> Le= t me start by putting aside the question of where things are marked, and co= me back to that afterwards.
>>>>>
>>>>>= There are a number of cases that I2RS has been asked to cover of high rate= telemetry data.=C2=A0 This may be BGP update information, it may be freque= nt information about line card activity.=C2=A0 There are other cases, some = of which have been documented.
>>>>>
>>>>&= gt; While not completely insensitive, the operators have made clear that th= ey see protecting this data as unnecessary.=C2=A0 While I would hope over t= ime to move to a domain where all of it is protect, that is not trivial.=C2= =A0 As the I2RS Architecture points out, it is expected that what we descri= be as a single I2RS >communication between a client and agent is actuall= y associated with multiple channels of communication.
>>>>&g= t;
>>>>> Now, if you want to say that the I2RS protocol r= equirements cannot allow for unprotected channels, I guess we have disconne= ct between the IESG and the WG.
>>>>>
>>>>= > If we say that we can allow for unprotected channels, we then get to t= he question of which data can be sent over such channels.=C2=A0 While archi= tecturally I agree with Juergen that the model is a bad place to specify it= , the obverse is also true.=C2=A0 Not having some limits on what can be sen= t unprotected >causes concern about insufficient protection.=C2=A0 If I = recall correctly, earlier security reviews called us to task for being too = broad in what we allowed.
>>>>>
>>>>> S= o, if the IESG wants us to just allow it anywhere, because the
>>&= gt;>> model is an awkward place to define the limitation, I can live = with that.=C2=A0 What I can't live with is being told both that the mod= el is a bad place to define it and that there must be restrictions on what = is sent unprotected, without any proposal on how we are to move forward.>>>> Thank you Joel, this explanation helps me a lot. I think = there is a disconnect about how the restrictions are expressed. From readin= g the email traffic about this document, it strikes me that trying to expre= ss the restrictions programmatically doesn=E2=80=99t make much sense in thi= s case.
>>>> I agree with Juergen that it will be challengin= g to make a judgment a priori in order to bake a restriction into a data mo= del, because data that is considered sensitive enough to warrant a secure t= ransport in one deployment may not be considered sensitive in another deplo= yment.
>>>> So for any data elements where there is any ques= tion at all about
>>>> whether they might be sensitive (i.e.= , any data elements that are not already routinely made public), I would ex= pect data model authors to end up indicating that they may be sent over eit= her secure or insecure transport, which renders the indication not useful.<= br>>>>> Perhaps it would make more sense then to just enumerate= in the text the cases that motivate the inclusion of protocol support for = insecure transport:
>>>>
>>>> 1. For conveyan= ce of information that is already routinely made public.
>>>>= ; 2. For line card activity data where there is no likely upgrade path to s= upport secure transports in the foreseeable future.
>>>>
= >>>> Then the normative requirements would be on clients and ag= ents to use secure transports unless those clients and agents are deployed = where either of the operational circumstances above necessitate otherwise.<= br>>>>> Alissa
>>> Point 1:
>>> I disag= ree with Juergen on the difficulty in specifying the sections of the yang m= odules.=C2=A0 I have provided a suggested solution in:
>>> https://tools.ietf.org/html/draft-hares= -i2rs-protocol-strawman-03#section-4.5.2.
>>>
>&= gt;> Given the mount schema functionality, we can mount ephemeral state = module which augment non-ephemeral state modules which are "in-secure = only".
>>>
>>> Point 2:
>>> I am w= illing to put an enumeration of the use cases in the protocol requirement, = but I would like to understand the purpose for the enumeration.=C2=A0 =C2= =A0We are not doing a use case, but a requirements document.=C2=A0 This inf= ormation appears to be a "use case" rather than a technical descr= iption.=C2=A0 =C2=A0What purpose are you looking for this enumeration to se= rver.=C2=A0 Are you looking for the enumeration in SEC-REQ-08?
>>&= gt;
>>> Point 3: Could you review -08.txt on this topic, especi= ally the text below.=C2=A0 Given your comments, I believe I should change t= he last line to a MUST.
>>> New/=C2=A0 =C2=A0The default mode o= f transport is
>>>=C2=A0 =C2=A0 secure so data models MUST clea= rly annotate what data nodes can be
>>>=C2=A0 =C2=A0 passed ove= r an insecure connection.
>>> /
>>>
>>>= Sue
>>>
>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D
>>> As to the normative requirements (-08= .txt) version:
>>>
>>> Section 3:
>>>>>>=C2=A0 =C2=A0 I2RS allows the use of an insecure transport fo= r portions of data
>>>=C2=A0 =C2=A0 models that clearly indicat= e the use of an insecure transport.
>>>=C2=A0 =C2=A0 Operators = deploying I2RS must determine if they want to populate and
>>>= =C2=A0 =C2=A0 deploy the portions of the data model which use insecure tran= sports.
>>>
>>> In Section 3.2 in version -08.txt>>>
>>>=C2=A0 =C2=A0 SEC-REQ-08: The I2RS protocol M= UST be able to transfer data over a
>>>=C2=A0 =C2=A0 secure tra= nsport and optionally MAY be able to transfer data over a
>>>= =C2=A0 =C2=A0 non-secure transport.=C2=A0 A secure transport MUST provide d= ata
>>>=C2=A0 =C2=A0 confidentiality, data integrity, and repla= y prevention.
>>>
>>>=C2=A0 =C2=A0 The default I2RS= transport is a secure transport.
>>>
>>>=C2=A0 =C2= =A0 A non-secure transport can be used for publishing telemetry data or
= >>>=C2=A0 =C2=A0 other operational state that was specifically ind= icated to non-
>>>=C2=A0 =C2=A0 confidential in the data model = in the Yang syntax.
>>>
>>>=C2=A0 =C2=A0 The config= uration of ephemeral data in the I2RS Agent by the I2RS
>>>=C2= =A0 =C2=A0 client SHOULD be done over a secure transport.=C2=A0 It is antic= ipated
>>>=C2=A0 =C2=A0 that the passing of most I2RS ephemeral= state operational status
>>>=C2=A0 =C2=A0 SHOULD be done over = a secure transport.=C2=A0 As
>>>=C2=A0 =C2=A0 [I-D.ietf-i2rs-ep= hemeral-state] notes,=C2=A0 a data model MUST indicate
>>>= =C2=A0 =C2=A0 whether the transport exchanging the data between I2RS client= and
>>>=C2=A0 =C2=A0 I2RS agent is secure or insecure.
>= >>
>>>=C2=A0 =C2=A0 The default mode of transport is
&= gt;>>=C2=A0 =C2=A0 secure so data models SHOULD clearly annotate what= data nodes can be
>>>=C2=A0 =C2=A0 passed over an insecure con= nection.
>>>
>>>> Yours,
>>>> Joe= l
>>>>
>>>> -----Original Message-----
>= ;>>> From: Susan Hares [mailto:shares@ndzh.com]
>>>> Sent: Thursday, = August 18, 2016 9:17 AM
>>>> To: 'Juergen Schoenwaelder&= #39; <j.schoenwaelder@jacobs-university.de>
>>>&g= t; Cc: i2rs@ietf.org= ; i2rs-chairs@iet= f.org; 'Kathleen Moriarty'
>>>> <Kathleen.Moriarty= .ietf@gmail.com>; 'The IESG' <iesg@ietf.org>;
>>>> jhaas@pfrc.org;
>= ;>>> draft-ietf-i2rs-protocol-security-requ= irements@ietf.org
>>>> Subject: RE: [i2rs] Kathleen Mori= arty's Discuss on
>>>> draft-ietf-i2rs-protocol-sec= urity-requirements-07: (with DISCUSS and
>>>> COMMENT)
&g= t;>>>
>>>> Juergen and Kathleen:
>>>>= ;
>>>> Let me proceed with two examples: BGP route views dat= a model and the event for the web-service data.
>>>>
>= >>> The content of these data models are designated as exposed to = public.=C2=A0 The routing system only populates the proposed BGP route view= s data model with the data destined for the BGP looking glass.=C2=A0 The po= licy on the routing system indicates what information gets transferred.=C2= =A0 The data model is completely available to the public.=C2=A0 The Yang Do= ctors are going to review this by seeing the whole model is public and avai= lable via non-secure means.
>>>> The security people are goi= ng to review this seeing that the whole model is public, and available via = an unprotect means.=C2=A0 The fact the data model is all public should simp= lify the review.
>>>>
>>>> An event from the = I2RS RIB that a web-service route is up is the second case.=C2=A0 The I2RS = RIB has an event based on policy that indicates a web-service route is up.= =C2=A0 The yang-1.1 doctors must review the content of the event text to se= e it does not break privacy or provide too much
>>>> informa= tion=C2=A0 =C2=A0The event mechanisms will need to work over secure transpo= rt
>>>> and insecure transport.=C2=A0 Most of the data will = go over the secure transport event stream. However, a small amount of infor= mation may go over the insecure transport stream.
>>>>
&g= t;>>> First, let me know if my use cases are understandable.=C2=A0= Second, let me know if you disagree with this use cases.
>>>&g= t;
>>>> Fyi -=C2=A0 IESG approved the architecture with the = insecure stream.
>>>>
>>>> Sue
>>>= ;>
>>>> -----Original Message-----
>>>> Fr= om: Juergen Schoenwaelder
>>>> [mailto:j.schoenwaelder@j= acobs-university.de]
>>>> Sent: Thursday, August 18, 201= 6 9:06 AM
>>>> To: Susan Hares
>>>> Cc: i2rs@ietf.org; i2rs-chairs@ietf.org; &= #39;Kathleen Moriarty'; 'The
>>>> IESG'; jhaas@pfrc.org;
>>= ;>> draft-ietf-i2rs-protocol-security-requirem= ents@ietf.org
>>>> Subject: Re: [i2rs] Kathleen Moriarty= 's Discuss on
>>>> draft-ietf-i2rs-protocol-securit= y-requirements-07: (with DISCUSS and
>>>> COMMENT)
>&g= t;>>
>>>> I just do not know on which basis a data mod= el writer can decide whether a data object can be exposed in an unprotected= way. How are YANG doctors going to review this? How are security directora= te people going to judge this? But as promised, I leave (still puzzled) now= .
>>>>
>>>> /js
>>>>
>&g= t;>> On Thu, Aug 18, 2016 at 09:00:14AM -0400, Susan Hares wrote:
= >>>>> Juergen:
>>>>>
>>>>&g= t; Yes, we seem to disagree on the value of making it hardwired in the mode= l.
>>>>> For me, the value is a common understanding of d= eployment
>>>>> distribution
>>>> such
= >>>>> as the route-views.=C2=A0 =C2=A0Since the operators ar= gued strongly for this point,
>>>> I
>>>>>= think the best idea is to get it working in code and then see if
>&g= t;>>> the deployment matches the requests.
>>>>>=
>>>>> Sue
>>>>>
>>>>>= ; -----Original Message-----
>>>>> From: i2rs [mailto:i2rs-bounces@ietf.o= rg] On Behalf Of Juergen
>>>>> Schoenwaelder
>&= gt;>>> Sent: Thursday, August 18, 2016 8:14 AM
>>>>= > To: Susan Hares
>>>>> Cc: i2rs@ietf.org; i2rs-chairs@ietf.org; 'Kathleen Moriarty= '; 'The
>>>>> IESG'; jhaas@pfrc.org;
>>>>> draft-ietf-i2rs-protocol-security-requirements@ietf.org=
>>>>> Subject: Re: [i2rs] Kathleen Moriarty's Di= scuss on
>>>>> draft-ietf-i2rs-protocol-security-req= uirements-07: (with DISCUSS
>>>>> and
>>>>= > COMMENT)
>>>>>
>>>>> Sue,
>&= gt;>>>
>>>>> I still do not see why the 'mod= e of exposure' of data benefits from
>>>>> being hard= -wired in the data model. For me, it is a situational and
>>>&g= t;> deployment specific question. But I shut up here since I aired this<= br>>>>>> concern before (and we simply seem to disagree).>>>>>
>>>>> /js
>>>>>>>>>> On Thu, Aug 18, 2016 at 08:07:18AM -0400, Susan Hare= s wrote:
>>>>>> Juergen:
>>>>>>>>>>>> My example is the looking glass servers for the = BGP route views
>>>>>> project
>>>>>= > (http://www.r= outeviews.org/) or a route indicating the presence of a
>>>= >>> web-server that is public.=C2=A0 =C2=A0For the BGP I2RS route,= a yang model could
>>>>>> replace the looking glass f= unction, and provide events for these looking
>>>>>> g= lass functions.=C2=A0 =C2=A0 For the web-server route,=C2=A0 an event be se= nt when
>>>> that
>>>>>> one route is a= dded.
>>>>>>
>>>>>> Sue
>&g= t;>>>>
>>>>>>
>>>>>> = -----Original Message-----
>>>>>> From: Juergen Schoen= waelder
>>>>>> [mailto:j.schoenwaelder@jacobs-univ= ersity.de]
>>>>>> Sent: Thursday, August 18, 2016 = 3:32 AM
>>>>>> To: Susan Hares
>>>>>= > Cc: 'Kathleen Moriarty'; 'The IESG'; jhaas@pfrc.org;
>>>>&= gt;> i2rs@ietf.org; i2rs-chairs@ie= tf.org;
>>>>>> draft-ietf-i2rs-p= rotocol-security-requirements@ietf.org
>>>>>>= Subject: Re: [i2rs] Kathleen Moriarty's Discuss on
>>>>= >> draft-ietf-i2rs-protocol-security-requirements-07: (with DISC= USS
>>>>>> and
>>>>>> COMMENT)>>>>>>
>>>>>> On Wed, Aug 17, 2016 = at 09:16:48PM -0400, Susan Hares wrote:
>>>>>>> ---= -------------------------------------------------------------->>>>>>> -
>>>>>>> --
>&= gt;>>>>> --
>>>>>>> COMMENT:
>= >>>>>> ---------------------------------------------= --------------------
>>>>>>> -
>>>= >>>> --
>>>>>>> --
>>>>&= gt;>>
>>>>>>>> Section 3:
>>>&= gt;>>>> Can you clarify the second to last sentence?=C2=A0 Do y= ou mean there
>>>>>>>> are
>>>>&g= t;> sections that indicate an insecure transport should be used?
>= >>>>>>>=C2=A0 I2RS allows the use of an
>>>= ;>>>>> insecure transport for portions of data models that c= learly
>>>>>>>> indicate=C2=A0 insecure transpor= t.
>>>>>>>> Perhaps:
>>>>>>= >> I2RS allows the use of an
>>>>>>>> inse= cure transport for portions of data models that clearly
>>>>= >>>> indicate the use of an=C2=A0 insecure transport.
>&g= t;>>>> I still wonder how a data model writer can reasonably de= cide
>>>>>> whether a piece of information can be ship= ped safely over an
>>>>>> insecure transport since thi= s decision often depends on the
>>>>>> specifics of a = deployment
>>>>> situation.
>>>>>> /= js
>>>>>>
>>>>>> PS: I hope we do= not end up with defining data multiple times (once
>>>>>= >=C2=A0 =C2=A0 for insecure transport and once for secured transports).<= br>>>>>>>
>>>>>> --
>>>&= gt;>> Juergen Schoenwaelder=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0J= acobs University Bremen gGmbH
>>>>>> Phone: +49 421 20= 0 3587=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Campus Ring 1 | 28759 Bremen | Germ= any
>>>>>> Fax:=C2=A0 =C2=A0+49 421 200 3103=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0<http://www.jacobs-university.de/>
>>&g= t;>>>
>>>>>> _______________________________________________
>>>>>> i2rs mailing list
>&= gt;>>>> i2rs= @ietf.org
>>>>>> https://www.ietf.org/mailman/l= istinfo/i2rs
>>>>> --
>>>>> Juergen= Schoenwaelder=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Jacobs University Br= emen gGmbH
>>>>> Phone: +49 421 200 3587=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0Campus Ring 1 | 28759 Bremen | Germany
>>>>= > Fax:=C2=A0 =C2=A0+49 421 200 3103=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<= ;http://www.= jacobs-university.de/>
>>>>>
>>>&= gt;> _______________________________________________
>>>= ;>> i2rs mailing list
>>>>> i2rs@ietf.org
>>>>> https:/= /www.ietf.org/mailman/listinfo/i2rs
>>>>>
>= ;>>> --
>>>> Juergen Schoenwaelder=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0Jacobs University Bremen gGmbH
>>>> = Phone: +49 421 200 3587=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Campus Ring 1 | 28= 759 Bremen | Germany
>>>> Fax:=C2=A0 =C2=A0+49 421 200 3103= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<http://www.jacobs-university.de/>
= >>>>
>
>
>


_______________________= ________________________
i2rs mailing list
i2rs@ietf.org
https://www.ietf.org/mailm= an/listinfo/i2rs

= =C2=A0


--001a114584d0e4d711053a6f3d02-- From nobody Fri Aug 19 10:01:40 2016 Return-Path: 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 A9C2812D0C6; Fri, 19 Aug 2016 09:57:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.739 X-Spam-Level: * X-Spam-Status: No, score=1.739 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, RDNS_NONE=0.793] autolearn=no 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 g4j3TySOkoar; Fri, 19 Aug 2016 09:57:39 -0700 (PDT) Received: from hickoryhill-consulting.com (unknown [50.245.122.97]) (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 901C812B025; Fri, 19 Aug 2016 09:57:38 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=184.157.82.170; From: "Susan Hares" To: "'Andy Bierman'" References: <013b01d1f8ee$31fa09b0$95ee1d10$@ndzh.com> <20160818073203.GA4338@elstar.local> <04b501d1f949$116c63e0$34452ba0$@ndzh.com> <20160818121405.GA5282@elstar.local> <051301d1f950$7739c670$65ad5350$@ndzh.com> <20160818130555.GA5366@elstar.local> <051701d1f952$c4ae0b30$4e0a2190$@ndzh.com> <6BCE198E4EAEFC4CAB45D75826EFB0761525CCD7@eusaamb101.ericsson.se> <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> <036801d1fa2a$466e9e00$d34bda00$@ndzh.com> <001501d1fa30$46d0ac70$d4720550$@ndzh.com> In-Reply-To: Date: Fri, 19 Aug 2016 12:55:53 -0400 Message-ID: <00e701d1fa3a$8cf41a70$a6dc4f50$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00E8_01D1FA19.05E7AA90" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJ/RF5y8kBC7R3sO+auWKe566R2lwEcb/3KAg+ndAACAypBUwGJSPf4Amiv8FwDJLAGjQJqExQkAqfTovACEJToAwFDCzFbAlTVyfQCrq8/9AJKcpLBAq9whFMCDwN3eQIvrQjwAMUBZUsCRhcJ253GViOg Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: X-Mailman-Approved-At: Fri, 19 Aug 2016 10:01:34 -0700 Cc: i2rs@ietf.org, 'Alissa Cooper' , 'Juergen Schoenwaelder' , i2rs-chairs@ietf.org, 'Kathleen Moriarty' , 'IESG' , 'Jeffrey Haas' , 'Joel Halpern' , 'Lou Berger' , 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Aug 2016 16:57:43 -0000 This is a multipart message in MIME format. ------=_NextPart_000_00E8_01D1FA19.05E7AA90 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Andy:=20 =20 The easy of reviewing per leaf =E2=80=93 is why I suggested the per = leaf. =20 I also agree it is important to mention this non-secure/secure = requirement to the PUSH work team we are both on.=20 =20 Should I change:=20 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:=20 / 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. / =20 =20 Sue=20 =20 From: Andy Bierman [mailto:andy@yumaworks.com]=20 Sent: Friday, August 19, 2016 12:32 PM To: Susan Hares Cc: Lou Berger; i2rs@ietf.org; Alissa Cooper; Juergen Schoenwaelder; = 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) =20 =20 =20 On Fri, Aug 19, 2016 at 8:42 AM, Susan Hares wrote: Andy:=20 =20 I have been thinking about your question for 30 minutes. Let me put = down a few of my personal opinions:=20 =20 1) Most (99%) of the ephemeral data models will not allow = non-secure transport.=20 2) If any ephemeral data models have an insecure section, the = review and consensus for a standards model should take longer.=20 I hope we can streamline the normal Yang model review. [It would be = nice to streamline features additions for NETCONF/RESTCONF as well]. =20 =20 =20 I hope you are right that it will almost always be easy for a WG to decide this issue for each leaf. =20 We already have "security tagging" in NACM, and this has not caused = delays. This is the opposite decision -- Is this data so sensitive that the NACM = default access control needs to block writes (nacm:default-deny-write) or block = all access (nacm:default-deny-all)? =20 These extensions are used in ietf-system.yang, not just in the NACM RFC. They can be used anywhere and a NACM implementation MUST enforce the extension semantics. =20 If YANG Push had similar requirements (i.e, MUST NOT send data in the = clear that is not tagged with the appropriate extension) and the review = criteria is clear, then this approach should be OK. =20 =20 Andy =20 =20 3) I prefer to have the non-secure sections of a data model moved = to a separate date model, and the data model marked as insecure. =20 [I do not know if we could use the library function to mark the data = model in meta-language.] However, until we complete the mount schema work =E2=80=93 I do not know = if this is workable.=20 =20 Would it help if I changed version -08 to=20 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=20 Operational state that was specifically indicated to be = non-confidential in the data model. / =20 Sue=20 =20 =20 From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Susan Hares Sent: Friday, August 19, 2016 10:59 AM To: 'Andy Bierman'; 'Lou Berger' Cc: i2rs@ietf.org; 'Alissa Cooper'; 'Juergen Schoenwaelder'; = 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) =20 Andy:=20 =20 Thank you for your comments. Perhaps you can provide for the IESG the = list of things that are needed to move a Yang module forward in the = IETF. =20 =20 Sue=20 =20 From: Andy Bierman [mailto:andy@yumaworks.com]=20 Sent: Friday, August 19, 2016 10:24 AM To: Lou Berger Cc: Susan Hares; Juergen Schoenwaelder; 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) =20 Hi, =20 I agree with Juergen. There are already too many details that need consensus to move a YANG module forward in the IETF. It takes too long already. =20 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?" =20 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? =20 Standardized insecure access is a big change from what we have done for 30 years. There could be a good reason why we left this out of = scope all this time. =20 =20 Andy =20 =20 On Fri, Aug 19, 2016 at 5:20 AM, Lou Berger wrote: Sue, My message said three things: 1) Juergen's comment resonates with me. 2) I think the current text is acceptable. 3) I see changing the SHOULD to a MUST as problematic. I understood one of the other messages on this thread proposing this change which is what triggered my message. If I misunderstood that message, feel free to interpret my message as supporting the current text in question. Note that I am only speaking for myself (including in my role as NETMOD co-chair) and not representing the consensus opinion of any WG. Lou On 8/19/2016 8:07 AM, Susan Hares wrote: > Lou: > > I am clear that Juergen does not want not want to place transport = requirements within the data model for NETMOD. His opinion was = considered in the rough for the I2RS WG. If this requirement is a = problem for NETCONF/NETMOD, the text currently says: > > REQ-SEC-09 states: > > The default mode of transport is secure so data models SHOULD = clearly annotate what data nodes can be > passed over an insecure connection. > > However, if this means the NETCONF/NETMOD WG will not even entertain = proposal for marking the insecure functions in yang text -- then the two = WG (I2RS/NETMOD) have a problem and should stop this standardization = process going forward. > > Sue > > > -----Original Message----- > From: Lou Berger [mailto:lberger@labn.net] > Sent: Friday, August 19, 2016 7:34 AM > To: Susan Hares; 'Juergen Schoenwaelder' > Cc: i2rs@ietf.org; 'Alissa Cooper'; i2rs-chairs@ietf.org; 'Kathleen = Moriarty'; 'IESG'; jhaas@pfrc.org; '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) > > Sue, > > I don't see Juergen as arguing against model access via non-secure = transport. I read his point as that the transport security requirements = don't belong scattered within a data model. > > I have to say that from a model complexity (definition, process, = review, implementation - take your pick) , language and NETMOD co-chair = perspective, his comment resonates with me. > > I think this makes the key text: > > The default mode of transport is > secure so data models SHOULD clearly annotate what data nodes can = be > passed over an insecure connection. > > > As this isn't a MUST, I personally think we can live with the text and = we can debate the issue further in the context of specific solutions. I = would strongly object to this being changed to a MUST, or if the = document is changed to make transport (security) requirements identified = within data models a requirement. > > Lou > > On 8/19/2016 6:49 AM, Susan Hares wrote: >> Juergen: >> >> You have laid out the two options: a) link the data-model to the = non-secure transport, and b) do not link the data to the non-secure = transport. I agree with you that past models did not link past SNMP = MIB data model to the transport. Existing NETCONF models do not link it = to the transport. As you have indicated, you disagreed in the I2RS WG = and we found consensus was to include the non-secure transport. >> >> I2RS was created to build things as an interface to the routing = environment. The operators clearly informed the I2RS group of this = need during the requirement setting phase prior to the time I was chair. = The reason I continue to press for this capability is their input, and = the existing use cases I listed previously in this mail: >> >> a) public information - BGP route views, >> b) specific well know up events - such as public-web site up >> c) specific network service events - interface to particular public = LAN up. >> >> As you know, we do not have any I2RS data models that specify this = feature at this time. I suspect after we get through this lengthy = requirement phase, the operators may begin to specify new models that = have this feature. >> >> Sue >> >> -----Original Message----- >> From: Juergen Schoenwaelder >> [mailto:j.schoenwaelder@jacobs-university.de] >> Sent: Friday, August 19, 2016 4:58 AM >> To: Susan Hares >> Cc: 'Alissa Cooper'; 'Joel Halpern'; i2rs@ietf.org; >> i2rs-chairs@ietf.org; 'Kathleen Moriarty'; 'IESG'; jhaas@pfrc.org; >> 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) >> >> I repeat my technical argument: While there may be deployments where = non-secure transports may be reasonable to use, defining these = situations statically as part of data model schemas does not follow = established practices. The IETF has a long tradition of standardizing = data models that can be used in a variety of operational contexts and I = do not see reasons why we should move away from that basic approach. >> >> /js >> >> On Thu, Aug 18, 2016 at 02:35:03PM -0400, Susan Hares wrote: >>> Alissa: >>> >>> Just a little input you may not know. My background is 15 years = (1995-2010) developing a routing/switching platform (denoted as GateD) = which was sold to over 200 companies. We developed XML and a binary = XML based product that configured this product. It could do 100K = configuration lines and reboot in less than a second on most hardware. = We also provide status messages in secure streams and non-secure = streams. I sold early version of this code to companies that Alia has = worked for - so she has personal viewed the code. At the height of = our work, our development team ran to 50 people which I directed (First = as VP of Engineering, and then as CTO). It is due to this level of = experience that Alia selected me for the co-chair. Russ White has = understood Cisco's process, and has also directed software development = teams for routing. >>> >>> In order to freshen my direct experience with I2RS on open source = work, I am working on a publically available work in Quagga based on the = confD product suggested by Cisco. >>> >>> In contrast, Juergen is a university professor who has worked on = proto-types. He is not working on an implementation. I hope he will. >>> >>> I hope you will consider this background in my response to your = comments below. >>> >>> Sue >>> >>> >>> -----Original Message----- >>> From: Alissa Cooper [mailto:alissa@cooperw.in] >>> Sent: Thursday, August 18, 2016 12:54 PM >>> To: Joel Halpern >>> Cc: Susan Hares; Juergen Schoenwaelder; i2rs@ietf.org; >>> i2rs-chairs@ietf.org; Kathleen Moriarty; IESG; jhaas@pfrc.org; >>> 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) >>> >>> Jumping in here because this is relevant to my DISCUSS, hope nobody = minds (but if you do, I can go back to the other thread). >>> >>>>> On Aug 18, 2016, at 10:30 AM, Joel Halpern = wrote: >>>>> >>>>> Let me try a different take approach to this particular question. >>>>> >>>>> Let me start by putting aside the question of where things are = marked, and come back to that afterwards. >>>>> >>>>> There are a number of cases that I2RS has been asked to cover of = high rate telemetry data. This may be BGP update information, it may be = frequent information about line card activity. There are other cases, = some of which have been documented. >>>>> >>>>> While not completely insensitive, the operators have made clear = that they see protecting this data as unnecessary. While I would hope = over time to move to a domain where all of it is protect, that is not = trivial. As the I2RS Architecture points out, it is expected that what = we describe as a single I2RS >communication between a client and agent = is actually associated with multiple channels of communication. >>>>> >>>>> Now, if you want to say that the I2RS protocol requirements cannot = allow for unprotected channels, I guess we have disconnect between the = IESG and the WG. >>>>> >>>>> If we say that we can allow for unprotected channels, we then get = to the question of which data can be sent over such channels. While = architecturally I agree with Juergen that the model is a bad place to = specify it, the obverse is also true. Not having some limits on what = can be sent unprotected >causes concern about insufficient protection. = If I recall correctly, earlier security reviews called us to task for = being too broad in what we allowed. >>>>> >>>>> So, if the IESG wants us to just allow it anywhere, because the >>>>> model is an awkward place to define the limitation, I can live = with that. What I can't live with is being told both that the model is = a bad place to define it and that there must be restrictions on what is = sent unprotected, without any proposal on how we are to move forward. >>>> Thank you Joel, this explanation helps me a lot. I think there is a = disconnect about how the restrictions are expressed. From reading the = email traffic about this document, it strikes me that trying to express = the restrictions programmatically doesn=E2=80=99t make much sense in = this case. >>>> I agree with Juergen that it will be challenging to make a judgment = a priori in order to bake a restriction into a data model, because data = that is considered sensitive enough to warrant a secure transport in one = deployment may not be considered sensitive in another deployment. >>>> So for any data elements where there is any question at all about >>>> whether they might be sensitive (i.e., any data elements that are = not already routinely made public), I would expect data model authors to = end up indicating that they may be sent over either secure or insecure = transport, which renders the indication not useful. >>>> Perhaps it would make more sense then to just enumerate in the text = the cases that motivate the inclusion of protocol support for insecure = transport: >>>> >>>> 1. For conveyance of information that is already routinely made = public. >>>> 2. For line card activity data where there is no likely upgrade = path to support secure transports in the foreseeable future. >>>> >>>> Then the normative requirements would be on clients and agents to = use secure transports unless those clients and agents are deployed where = either of the operational circumstances above necessitate otherwise. >>>> Alissa >>> Point 1: >>> I disagree with Juergen on the difficulty in specifying the sections = of the yang modules. I have provided a suggested solution in: >>> = https://tools.ietf.org/html/draft-hares-i2rs-protocol-strawman-03#section= -4.5.2. >>> >>> Given the mount schema functionality, we can mount ephemeral state = module which augment non-ephemeral state modules which are "in-secure = only". >>> >>> Point 2: >>> I am willing to put an enumeration of the use cases in the protocol = requirement, but I would like to understand the purpose for the = enumeration. We are not doing a use case, but a requirements document. = This information appears to be a "use case" rather than a technical = description. What purpose are you looking for this enumeration to = server. Are you looking for the enumeration in SEC-REQ-08? >>> >>> Point 3: Could you review -08.txt on this topic, especially the text = below. Given your comments, I believe I should change the last line to = a MUST. >>> New/ The default mode of transport is >>> secure so data models MUST clearly annotate what data nodes can = be >>> passed over an insecure connection. >>> / >>> >>> Sue >>> >>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>> As to the normative requirements (-08.txt) version: >>> >>> Section 3: >>> >>> I2RS allows the use of an insecure transport for portions of data >>> models that clearly indicate the use of an insecure transport. >>> Operators deploying I2RS must determine if they want to populate = and >>> deploy the portions of the data model which use insecure = transports. >>> >>> In Section 3.2 in version -08.txt >>> >>> SEC-REQ-08: The I2RS protocol MUST be able to transfer data over = a >>> secure transport and optionally MAY be able to transfer data over = a >>> non-secure transport. A secure transport MUST provide data >>> confidentiality, data integrity, and replay prevention. >>> >>> The default I2RS transport is a secure transport. >>> >>> 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. >>> >>> The configuration of ephemeral data in the I2RS Agent by the I2RS >>> client SHOULD be done over a secure transport. It is anticipated >>> that the passing of most I2RS ephemeral state operational status >>> SHOULD be done over a secure transport. As >>> [I-D.ietf-i2rs-ephemeral-state] notes, a data model MUST = indicate >>> whether the transport exchanging the data between I2RS client and >>> I2RS agent is secure or insecure. >>> >>> The default mode of transport is >>> secure so data models SHOULD clearly annotate what data nodes can = be >>> passed over an insecure connection. >>> >>>> Yours, >>>> Joel >>>> >>>> -----Original Message----- >>>> From: Susan Hares [mailto:shares@ndzh.com] >>>> Sent: Thursday, August 18, 2016 9:17 AM >>>> To: 'Juergen Schoenwaelder' >>>> Cc: i2rs@ietf.org; i2rs-chairs@ietf.org; 'Kathleen Moriarty' >>>> ; 'The IESG' ; >>>> jhaas@pfrc.org; >>>> 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) >>>> >>>> Juergen and Kathleen: >>>> >>>> Let me proceed with two examples: BGP route views data model and = the event for the web-service data. >>>> >>>> The content of these data models are designated as exposed to = public. The routing system only populates the proposed BGP route views = data model with the data destined for the BGP looking glass. The policy = on the routing system indicates what information gets transferred. The = data model is completely available to the public. The Yang Doctors are = going to review this by seeing the whole model is public and available = via non-secure means. >>>> The security people are going to review this seeing that the whole = model is public, and available via an unprotect means. The fact the = data model is all public should simplify the review. >>>> >>>> An event from the I2RS RIB that a web-service route is up is the = second case. The I2RS RIB has an event based on policy that indicates a = web-service route is up. The yang-1.1 doctors must review the content = of the event text to see it does not break privacy or provide too much >>>> information The event mechanisms will need to work over secure = transport >>>> and insecure transport. Most of the data will go over the secure = transport event stream. However, a small amount of information may go = over the insecure transport stream. >>>> >>>> First, let me know if my use cases are understandable. Second, let = me know if you disagree with this use cases. >>>> >>>> Fyi - IESG approved the architecture with the insecure stream. >>>> >>>> Sue >>>> >>>> -----Original Message----- >>>> From: Juergen Schoenwaelder >>>> [mailto:j.schoenwaelder@jacobs-university.de] >>>> Sent: Thursday, August 18, 2016 9:06 AM >>>> To: Susan Hares >>>> Cc: i2rs@ietf.org; i2rs-chairs@ietf.org; 'Kathleen Moriarty'; 'The >>>> IESG'; jhaas@pfrc.org; >>>> 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) >>>> >>>> I just do not know on which basis a data model writer can decide = whether a data object can be exposed in an unprotected way. How are YANG = doctors going to review this? How are security directorate people going = to judge this? But as promised, I leave (still puzzled) now. >>>> >>>> /js >>>> >>>> On Thu, Aug 18, 2016 at 09:00:14AM -0400, Susan Hares wrote: >>>>> Juergen: >>>>> >>>>> Yes, we seem to disagree on the value of making it hardwired in = the model. >>>>> For me, the value is a common understanding of deployment >>>>> distribution >>>> such >>>>> as the route-views. Since the operators argued strongly for this = point, >>>> I >>>>> think the best idea is to get it working in code and then see if >>>>> the deployment matches the requests. >>>>> >>>>> Sue >>>>> >>>>> -----Original Message----- >>>>> From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Juergen >>>>> Schoenwaelder >>>>> Sent: Thursday, August 18, 2016 8:14 AM >>>>> To: Susan Hares >>>>> Cc: i2rs@ietf.org; i2rs-chairs@ietf.org; 'Kathleen Moriarty'; 'The >>>>> IESG'; jhaas@pfrc.org; >>>>> 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) >>>>> >>>>> Sue, >>>>> >>>>> I still do not see why the 'mode of exposure' of data benefits = from >>>>> being hard-wired in the data model. For me, it is a situational = and >>>>> deployment specific question. But I shut up here since I aired = this >>>>> concern before (and we simply seem to disagree). >>>>> >>>>> /js >>>>> >>>>> On Thu, Aug 18, 2016 at 08:07:18AM -0400, Susan Hares wrote: >>>>>> Juergen: >>>>>> >>>>>> My example is the looking glass servers for the BGP route views >>>>>> project >>>>>> (http://www.routeviews.org/) or a route indicating the presence = of a >>>>>> web-server that is public. For the BGP I2RS route, a yang model = could >>>>>> replace the looking glass function, and provide events for these = looking >>>>>> glass functions. For the web-server route, an event be sent = when >>>> that >>>>>> one route is added. >>>>>> >>>>>> Sue >>>>>> >>>>>> >>>>>> -----Original Message----- >>>>>> From: Juergen Schoenwaelder >>>>>> [mailto:j.schoenwaelder@jacobs-university.de] >>>>>> Sent: Thursday, August 18, 2016 3:32 AM >>>>>> To: Susan Hares >>>>>> Cc: 'Kathleen Moriarty'; 'The IESG'; jhaas@pfrc.org; >>>>>> i2rs@ietf.org; i2rs-chairs@ietf.org; >>>>>> 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 Wed, Aug 17, 2016 at 09:16:48PM -0400, Susan Hares wrote: >>>>>>> = ----------------------------------------------------------------- >>>>>>> - >>>>>>> -- >>>>>>> -- >>>>>>> COMMENT: >>>>>>> = ----------------------------------------------------------------- >>>>>>> - >>>>>>> -- >>>>>>> -- >>>>>>> >>>>>>>> Section 3: >>>>>>>> Can you clarify the second to last sentence? Do you mean there >>>>>>>> are >>>>>> sections that indicate an insecure transport should be used? >>>>>>>> I2RS allows the use of an >>>>>>>> insecure transport for portions of data models that clearly >>>>>>>> indicate insecure transport. >>>>>>>> Perhaps: >>>>>>>> I2RS allows the use of an >>>>>>>> insecure transport for portions of data models that clearly >>>>>>>> indicate the use of an insecure transport. >>>>>> I still wonder how a data model writer can reasonably decide >>>>>> whether a piece of information can be shipped safely over an >>>>>> insecure transport since this decision often depends on the >>>>>> specifics of a deployment >>>>> situation. >>>>>> /js >>>>>> >>>>>> PS: I hope we do not end up with defining data multiple times = (once >>>>>> for insecure transport and once for secured transports). >>>>>> >>>>>> -- >>>>>> Juergen Schoenwaelder Jacobs University Bremen gGmbH >>>>>> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | = Germany >>>>>> Fax: +49 421 200 3103 = >>>>>> >>>>>> _______________________________________________ >>>>>> i2rs mailing list >>>>>> i2rs@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/i2rs >>>>> -- >>>>> Juergen Schoenwaelder Jacobs University Bremen gGmbH >>>>> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | = Germany >>>>> Fax: +49 421 200 3103 >>>>> >>>>> _______________________________________________ >>>>> i2rs mailing list >>>>> i2rs@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/i2rs >>>>> >>>> -- >>>> Juergen Schoenwaelder Jacobs University Bremen gGmbH >>>> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | = Germany >>>> Fax: +49 421 200 3103 >>>> > > > _______________________________________________ i2rs mailing list i2rs@ietf.org https://www.ietf.org/mailman/listinfo/i2rs =20 =20 ------=_NextPart_000_00E8_01D1FA19.05E7AA90 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Andy:

 

The easy of reviewing per leaf =E2=80=93 is why I suggested the per = leaf.=C2=A0

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: /

=C2=A0=C2=A0 A non-secure transport can be used for = publishing telemetry data or

=C2=A0=C2=A0 other operational state that was = specifically indicated to non-

=C2=A0=C2=A0 confidential in the data model in the = Yang syntax. /

New:

/ =C2=A0=C2=A0A non-secure transport can be used for = publishing telemetry data or

=C2=A0=C2=A0 other operational state that was = specifically indicated to non-

=C2=A0=C2=A0 confidential in the data model. = /

 

 

Sue

 

From:= = Andy Bierman [mailto:andy@yumaworks.com]
Sent: Friday, August = 19, 2016 12:32 PM
To: Susan Hares
Cc: Lou Berger; = i2rs@ietf.org; Alissa Cooper; Juergen Schoenwaelder; = 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 8:42 AM, Susan Hares <shares@ndzh.com> = wrote:

Andy:

 

I have been thinking about your question for 30 minutes.   = Let me put down a few of my personal opinions:

 

1)      = Most (99%) of the ephemeral data models will not allow non-secure = transport.

2)      =  If any ephemeral data models have an insecure section, the = review and consensus for a standards model should take longer. =

I hope we can streamline the normal Yang model review.  [It = would be nice to streamline features additions for NETCONF/RESTCONF as = well].  

 

 

I = hope you are right that it will almost always be easy for a = WG

to decide this issue = for each leaf.

 

We already have "security tagging" in NACM, = and this has not caused delays.

This is the opposite decision -- Is this data so = sensitive that the NACM default

access control needs to block writes = (nacm:default-deny-write) or block all = access

(nacm:default-deny-all)?

 

These extensions are used in ietf-system.yang, not = just in the NACM RFC.

They = can be used anywhere and a NACM implementation MUST = enforce

the extension = semantics.

 

If YANG Push had similar requirements (i.e, MUST NOT = send data in the clear

that is not tagged with the appropriate extension) and = the review criteria is clear,

then this approach should be = OK.

 

 

Andy

 

 

3)      = I prefer to have the non-secure sections of a data model moved to a = separate date model, and the data model marked as insecure. =  

[I do not know if we could use the library function to mark the data = model in meta-language.]

However, until we complete the mount schema work =E2=80=93 I do not = know if this is workable.

 

Would it help if I changed version -08 to

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 be non-confidential in the data = model.

    /

 

Sue

 

 

From:= = i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Susan = Hares
Sent: Friday, August 19, 2016 10:59 AM
To: = 'Andy Bierman'; 'Lou Berger'
Cc: i2rs@ietf.org; = 'Alissa Cooper'; 'Juergen Schoenwaelder'; 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)

 <= /o:p>

Andy:

 

Thank you for your comments.   Perhaps you can provide for = the IESG the list of things that are needed to move a Yang module = forward in the IETF.  

 

Sue

 

From:= = Andy Bierman [mailto:andy@yumaworks.com]
Sent: = Friday, August 19, 2016 10:24 AM
To: Lou Berger
Cc: = Susan Hares; Juergen Schoenwaelder; 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)

 <= /o:p>

Hi,

 <= /o:p>

I agree = with Juergen.

There are = already too many details that need consensus to = move

a YANG = module forward in the IETF.  It takes too long = already.

 <= /o:p>

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?"

 <= /o:p>

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?

 <= /o:p>

Standardized= insecure access is a big change from what we have = done

for 30 = years.  There could be a good reason why we left this out of = scope

all this = time.

 <= /o:p>

 <= /o:p>

Andy

 <= /o:p>

 <= /o:p>

On Fri, Aug = 19, 2016 at 5:20 AM, Lou Berger <lberger@labn.net> wrote:


Sue,
=
My message said three things:

1) Juergen's comment resonates = with me.

2) I think the current text is acceptable.

3) I = see changing the SHOULD to a MUST as problematic.
I understood one of = the other messages on this thread proposing this
change which is what = triggered my message.   If I misunderstood that
message, = feel free to interpret my message as supporting the current
text in = question.

Note that I am only speaking for myself (including in = my role as NETMOD
co-chair) and not representing the consensus = opinion of any WG.

Lou
On 8/19/2016 8:07 AM, Susan Hares = wrote:
> Lou:
>
> I am clear that Juergen does not = want not want to place transport requirements within the data model for = NETMOD.  His opinion was considered in the rough for the I2RS WG. = If this requirement is a problem for NETCONF/NETMOD,  the text = currently says:
>
> REQ-SEC-09 states:
>
>  =  The default mode of transport is secure so data models SHOULD = clearly annotate what data nodes can be
>    passed over = an insecure connection.
>
> However, if this means the = NETCONF/NETMOD WG will not even entertain proposal for marking the = insecure functions in yang text -- then the two WG (I2RS/NETMOD) have a = problem and should stop this standardization process going = forward.
>
> Sue
>
>
> -----Original = Message-----
> From: Lou Berger [mailto:lberger@labn.net]
> Sent: Friday, August 19, = 2016 7:34 AM
> To: Susan Hares; 'Juergen Schoenwaelder'
> = Cc: i2rs@ietf.org; 'Alissa Cooper'; i2rs-chairs@ietf.org; 'Kathleen Moriarty'; 'IESG'; = jhaas@pfrc.org; = '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)
>
> Sue,
>
>     I don't = see Juergen as arguing against model access via non-secure transport. I = read his point as that the transport security requirements don't belong = scattered within a data model.
>
> I have to say that from a = model complexity (definition, process, review, implementation - take = your pick) , language and NETMOD co-chair perspective, his comment = resonates with me.
>
> I think this makes the key = text:
>
>    The default mode of transport = is
>    secure so data models SHOULD clearly annotate = what data nodes can be
>    passed over an insecure = connection.
>
>
> As this isn't a MUST, I personally = think we can live with the text and we can debate the issue further in = the context of specific solutions.  I would strongly object to this = being changed to a MUST, or if the document is changed to make transport = (security) requirements identified within data models a = requirement.
>
> Lou
>
> On 8/19/2016 6:49 AM, = Susan Hares wrote:
>> Juergen:
>>
>> You have = laid out the two options:   a) link the data-model to the = non-secure transport, and b) do not link the data to the non-secure = transport.   I agree with you that past models did not link = past SNMP MIB data model to the transport.  Existing NETCONF models = do not link it to the transport.   As you have indicated, you = disagreed in the I2RS WG and we found consensus was to include the = non-secure transport.
>>
>> I2RS was created to build = things as an interface to the routing environment.   The = operators clearly informed the I2RS group of this need during the = requirement setting phase prior to the time I was chair.  The = reason I continue to press for this capability is their input, and the = existing use cases I listed previously in this = mail:
>>
>> a) public information - BGP route = views,
>> b) specific well know up events - such as public-web = site up
>> c) specific network service events - interface to = particular public LAN up.
>>
>> As you know, we do not = have any I2RS data models that specify this feature at this time.  =  I suspect after we get through this lengthy requirement phase, the = operators may begin to specify new models that have this = feature.
>>
>> Sue
>>
>> = -----Original Message-----
>> From: Juergen = Schoenwaelder
>> [mailto:j.schoenwaelder@jacobs-university.de]
>> = Sent: Friday, August 19, 2016 4:58 AM
>> To: Susan = Hares
>> Cc: 'Alissa Cooper'; 'Joel Halpern'; i2rs@ietf.org;
>> i2rs-chairs@ietf.org; 'Kathleen Moriarty'; 'IESG'; = jhaas@pfrc.org;
>> 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)
>>
>> I repeat my = technical argument: While there may be deployments where non-secure = transports may be reasonable to use, defining these situations = statically as part of data model schemas does not follow established = practices. The IETF has a long tradition of standardizing data models = that can be used in a variety of operational contexts and I do not see = reasons why we should move away from that basic = approach.
>>
>> /js
>>
>> On Thu, = Aug 18, 2016 at 02:35:03PM -0400, Susan Hares wrote:
>>> = Alissa:
>>>
>>> Just a little input you may not = know.  My background is 15 years (1995-2010)  developing a = routing/switching platform (denoted as GateD) which was sold to over 200 = companies.   We developed XML and a binary XML based product = that configured this product.  It could do 100K configuration lines = and reboot in less than a second on most hardware.  We also provide = status messages in secure streams and non-secure streams.    I = sold early version of this code to companies that Alia has worked = for  - so she has personal viewed the code.   At the = height of our work, our development team ran to 50 people which I = directed (First as VP of Engineering, and then as CTO). It is due to = this level of experience that Alia selected me for the co-chair.  =  Russ White has understood Cisco's process, and has also directed = software development teams for routing.
>>>
>>> = In order to freshen my direct experience with I2RS on open source work, = I am working on a publically available work in Quagga based on the confD = product suggested by Cisco.
>>>
>>> In contrast, = Juergen is a university professor who has worked on proto-types.  =  He is not working on an implementation.   I hope he = will.
>>>
>>> I hope you will consider this = background in my response to your comments = below.
>>>
>>> = Sue
>>>
>>>
>>> -----Original = Message-----
>>> From: Alissa Cooper [mailto:alissa@cooperw.in]
>>> Sent: Thursday, = August 18, 2016 12:54 PM
>>> To: Joel = Halpern
>>> Cc: Susan Hares; Juergen Schoenwaelder; i2rs@ietf.org;
>>> i2rs-chairs@ietf.org; Kathleen Moriarty; IESG; jhaas@pfrc.org;
>>> 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)
>>>
>>> Jumping in here because this is = relevant to my DISCUSS, hope nobody minds (but if you do, I can go back = to the other thread).
>>>
>>>>> On Aug 18, = 2016, at 10:30 AM, Joel Halpern <joel.halpern@ericsson.com> = wrote:
>>>>>
>>>>> Let me try a = different take approach to this particular = question.
>>>>>
>>>>> Let me start = by putting aside the question of where things are marked, and come back = to that afterwards.
>>>>>
>>>>> = There are a number of cases that I2RS has been asked to cover of high = rate telemetry data.  This may be BGP update information, it may be = frequent information about line card activity.  There are other = cases, some of which have been = documented.
>>>>>
>>>>> While not = completely insensitive, the operators have made clear that they see = protecting this data as unnecessary.  While I would hope over time = to move to a domain where all of it is protect, that is not = trivial.  As the I2RS Architecture points out, it is expected that = what we describe as a single I2RS >communication between a client and = agent is actually associated with multiple channels of = communication.
>>>>>
>>>>> Now, if = you want to say that the I2RS protocol requirements cannot allow for = unprotected channels, I guess we have disconnect between the IESG and = the WG.
>>>>>
>>>>> If we say that = we can allow for unprotected channels, we then get to the question of = which data can be sent over such channels.  While architecturally I = agree with Juergen that the model is a bad place to specify it, the = obverse is also true.  Not having some limits on what can be sent = unprotected >causes concern about insufficient protection.  If I = recall correctly, earlier security reviews called us to task for being = too broad in what we = allowed.
>>>>>
>>>>> So, if the IESG = wants us to just allow it anywhere, because the
>>>>> = model is an awkward place to define the limitation, I can live with = that.  What I can't live with is being told both that the model is = a bad place to define it and that there must be restrictions on what is = sent unprotected, without any proposal on how we are to move = forward.
>>>> Thank you Joel, this explanation helps me a = lot. I think there is a disconnect about how the restrictions are = expressed. From reading the email traffic about this document, it = strikes me that trying to express the restrictions programmatically = doesn=E2=80=99t make much sense in this case.
>>>> I = agree with Juergen that it will be challenging to make a judgment a = priori in order to bake a restriction into a data model, because data = that is considered sensitive enough to warrant a secure transport in one = deployment may not be considered sensitive in another = deployment.
>>>> So for any data elements where there is = any question at all about
>>>> whether they might be = sensitive (i.e., any data elements that are not already routinely made = public), I would expect data model authors to end up indicating that = they may be sent over either secure or insecure transport, which renders = the indication not useful.
>>>> Perhaps it would make = more sense then to just enumerate in the text the cases that motivate = the inclusion of protocol support for insecure = transport:
>>>>
>>>> 1. For conveyance of = information that is already routinely made public.
>>>> = 2. For line card activity data where there is no likely upgrade path to = support secure transports in the foreseeable = future.
>>>>
>>>> Then the normative = requirements would be on clients and agents to use secure transports = unless those clients and agents are deployed where either of the = operational circumstances above necessitate = otherwise.
>>>> Alissa
>>> Point = 1:
>>> I disagree with Juergen on the difficulty in = specifying the sections of the yang modules.  I have provided a = suggested solution in:
>>> https://tools.ietf.org/html/draft-hares-i2rs-protocol-s= trawman-03#section-4.5.2.
>>>
>>> Given the = mount schema functionality, we can mount ephemeral state module which = augment non-ephemeral state modules which are "in-secure = only".
>>>
>>> Point 2:
>>> I = am willing to put an enumeration of the use cases in the protocol = requirement, but I would like to understand the purpose for the = enumeration.   We are not doing a use case, but a requirements = document.  This information appears to be a "use case" = rather than a technical description.   What purpose are you = looking for this enumeration to server.  Are you looking for the = enumeration in SEC-REQ-08?
>>>
>>> Point 3: = Could you review -08.txt on this topic, especially the text below.  = Given your comments, I believe I should change the last line to a = MUST.
>>> New/   The default mode of transport = is
>>>    secure so data models MUST clearly = annotate what data nodes can be
>>>    passed over = an insecure connection.
>>> = /
>>>
>>> Sue
>>>
>>> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>>>= As to the normative requirements (-08.txt) = version:
>>>
>>> Section = 3:
>>>
>>>    I2RS allows the use of = an insecure transport for portions of data
>>>    = models that clearly indicate the use of an insecure = transport.
>>>    Operators deploying I2RS must = determine if they want to populate and
>>>    = deploy the portions of the data model which use insecure = transports.
>>>
>>> In Section 3.2 in version = -08.txt
>>>
>>>    SEC-REQ-08: The = I2RS protocol MUST be able to transfer data over a
>>>  =   secure transport and optionally MAY be able to transfer data over = a
>>>    non-secure transport.  A secure = transport MUST provide data
>>>    = confidentiality, data integrity, and replay = prevention.
>>>
>>>    The default = I2RS transport is a secure = transport.
>>>
>>>    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.
>>>
>>>    The configuration = of ephemeral data in the I2RS Agent by the I2RS
>>>  =   client SHOULD be done over a secure transport.  It is = anticipated
>>>    that the passing of most I2RS = ephemeral state operational status
>>>    SHOULD = be done over a secure transport.  As
>>>    = [I-D.ietf-i2rs-ephemeral-state] notes,  a data model MUST = indicate
>>>    whether the transport exchanging = the data between I2RS client and
>>>    I2RS agent = is secure or insecure.
>>>
>>>    The = default mode of transport is
>>>    secure so data = models SHOULD clearly annotate what data nodes can = be
>>>    passed over an insecure = connection.
>>>
>>>> = Yours,
>>>> Joel
>>>>
>>>> = -----Original Message-----
>>>> From: Susan Hares = [mailto:shares@ndzh.com]
>>>> Sent: = Thursday, August 18, 2016 9:17 AM
>>>> To: 'Juergen = Schoenwaelder' <j.schoenwaelder@jacobs-university.de>
>>= ;>> Cc: i2rs@ietf.org; i2rs-chairs@ietf.org; 'Kathleen = Moriarty'
>>>> <Kathleen.Moriarty.ietf@gmail.com>; 'The IESG' = <iesg@ietf.org>;
>>>> jhaas@pfrc.org;
>>>> 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)
>>>>
>>>> = Juergen and Kathleen:
>>>>
>>>> Let me = proceed with two examples: BGP route views data model and the event for = the web-service data.
>>>>
>>>> The = content of these data models are designated as exposed to public.  = The routing system only populates the proposed BGP route views data = model with the data destined for the BGP looking glass.  The policy = on the routing system indicates what information gets transferred.  = The data model is completely available to the public.  The Yang = Doctors are going to review this by seeing the whole model is public and = available via non-secure means.
>>>> The security people = are going to review this seeing that the whole model is public, and = available via an unprotect means.  The fact the data model is all = public should simplify the = review.
>>>>
>>>> An event from the I2RS = RIB that a web-service route is up is the second case.  The I2RS = RIB has an event based on policy that indicates a web-service route is = up.  The yang-1.1 doctors must review the content of the event text = to see it does not break privacy or provide too much
>>>> = information   The event mechanisms will need to work over = secure transport
>>>> and insecure transport.  Most = of the data will go over the secure transport event stream. However, a = small amount of information may go over the insecure transport = stream.
>>>>
>>>> First, let me know if my = use cases are understandable.  Second, let me know if you disagree = with this use cases.
>>>>
>>>> Fyi -  = IESG approved the architecture with the insecure = stream.
>>>>
>>>> = Sue
>>>>
>>>> -----Original = Message-----
>>>> From: Juergen = Schoenwaelder
>>>> [mailto:j.schoenwaelder@jacobs-university.de]
>>&g= t;> Sent: Thursday, August 18, 2016 9:06 AM
>>>> To: = Susan Hares
>>>> Cc: i2rs@ietf.org; i2rs-chairs@ietf.org; 'Kathleen Moriarty'; = 'The
>>>> IESG'; jhaas@pfrc.org;
>>>> 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)
>>>>
>>>> = I just do not know on which basis a data model writer can decide whether = a data object can be exposed in an unprotected way. How are YANG doctors = going to review this? How are security directorate people going to judge = this? But as promised, I leave (still puzzled) = now.
>>>>
>>>> = /js
>>>>
>>>> On Thu, Aug 18, 2016 at = 09:00:14AM -0400, Susan Hares wrote:
>>>>> = Juergen:
>>>>>
>>>>> Yes, we seem to = disagree on the value of making it hardwired in the = model.
>>>>> For me, the value is a common = understanding of deployment
>>>>> = distribution
>>>> such
>>>>> as the = route-views.   Since the operators argued strongly for this = point,
>>>> I
>>>>> think the best idea = is to get it working in code and then see if
>>>>> the = deployment matches the = requests.
>>>>>
>>>>> = Sue
>>>>>
>>>>> -----Original = Message-----
>>>>> From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of = Juergen
>>>>> Schoenwaelder
>>>>> = Sent: Thursday, August 18, 2016 8:14 AM
>>>>> To: = Susan Hares
>>>>> Cc: i2rs@ietf.org; i2rs-chairs@ietf.org; 'Kathleen Moriarty'; = 'The
>>>>> IESG'; jhaas@pfrc.org;
>>>>> 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)
>>>>>
>>>>> = Sue,
>>>>>
>>>>> I still do not see = why the 'mode of exposure' of data benefits from
>>>>> = being hard-wired in the data model. For me, it is a situational = and
>>>>> deployment specific question. But I shut up = here since I aired this
>>>>> concern before (and we = simply seem to = disagree).
>>>>>
>>>>> = /js
>>>>>
>>>>> On Thu, Aug 18, 2016 = at 08:07:18AM -0400, Susan Hares wrote:
>>>>>> = Juergen:
>>>>>>
>>>>>> My = example is the looking glass servers for the BGP route = views
>>>>>> project
>>>>>> = (http://www.routeviews.org/) or a route indicating = the presence of a
>>>>>> web-server that is = public.   For the BGP I2RS route, a yang model = could
>>>>>> replace the looking glass function, = and provide events for these looking
>>>>>> glass = functions.    For the web-server route,  an event be sent = when
>>>> that
>>>>>> one route is = added.
>>>>>>
>>>>>> = Sue
>>>>>>
>>>>>>
>>&g= t;>>> -----Original Message-----
>>>>>> = From: Juergen Schoenwaelder
>>>>>> [mailto:j.schoenwaelder@jacobs-university.de]
>>&g= t;>>> Sent: Thursday, August 18, 2016 3:32 = AM
>>>>>> To: Susan = Hares
>>>>>> Cc: 'Kathleen Moriarty'; 'The IESG'; = jhaas@pfrc.org;
>>>>>> i2rs@ietf.org; i2rs-chairs@ietf.org;
>>>>>> = 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 Wed, = Aug 17, 2016 at 09:16:48PM -0400, Susan Hares = wrote:
>>>>>>> = -----------------------------------------------------------------
>= >>>>>> -
>>>>>>> = --
>>>>>>> --
>>>>>>> = COMMENT:
>>>>>>> = -----------------------------------------------------------------
>= >>>>>> -
>>>>>>> = --
>>>>>>> = --
>>>>>>>
>>>>>>>> = Section 3:
>>>>>>>> Can you clarify the = second to last sentence?  Do you mean = there
>>>>>>>> = are
>>>>>> sections that indicate an insecure = transport should be used?
>>>>>>>>  I2RS = allows the use of an
>>>>>>>> insecure = transport for portions of data models that = clearly
>>>>>>>> indicate  insecure = transport.
>>>>>>>> = Perhaps:
>>>>>>>> I2RS allows the use of = an
>>>>>>>> insecure transport for portions = of data models that clearly
>>>>>>>> indicate = the use of an  insecure transport.
>>>>>> I = still wonder how a data model writer can reasonably = decide
>>>>>> whether a piece of information can be = shipped safely over an
>>>>>> insecure transport = since this decision often depends on the
>>>>>> = specifics of a deployment
>>>>> = situation.
>>>>>> = /js
>>>>>>
>>>>>> PS: I hope = we do not end up with defining data multiple times = (once
>>>>>>    for insecure transport = and once for secured = transports).
>>>>>>
>>>>>> = --
>>>>>> 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/>
>>>= ;>>>
>>>>>> = _______________________________________________
>>>>>&g= t; i2rs mailing list
>>>>>> i2rs@ietf.org
>>>>>> https://www.ietf.org/mailman/listinfo/i2rs
>&= gt;>>> --
>>>>> 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/>
>>>= ;>>
>>>>> = _______________________________________________
>>>>> = i2rs mailing list
>>>>> i2rs@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/i2rs
>&= gt;>>>
>>>> --
>>>> 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/>
>>>= ;>
>
>
>


________________________________= _______________
i2rs mailing list
i2rs@ietf.org
https://www.ietf.org/mailman/listinfo/i2rs

 <= /o:p>

 

------=_NextPart_000_00E8_01D1FA19.05E7AA90-- From nobody Fri Aug 19 10:37:09 2016 Return-Path: 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 454E912D7DD for ; Fri, 19 Aug 2016 10:37:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.149 X-Spam-Level: X-Spam-Status: No, score=-3.149 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.247, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=unavailable 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 4AHzNO0IfAcr for ; Fri, 19 Aug 2016 10:37:02 -0700 (PDT) Received: from kuehlewind.net (kuehlewind.net [83.169.45.111]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4030F12D7D4 for ; Fri, 19 Aug 2016 10:36:56 -0700 (PDT) Received: (qmail 15848 invoked from network); 19 Aug 2016 19:30:13 +0200 Received: from p5dec255c.dip0.t-ipconnect.de (HELO ?192.168.178.33?) (93.236.37.92) by kuehlewind.net with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 19 Aug 2016 19:30:13 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: "Mirja Kuehlewind (IETF)" In-Reply-To: <00c001d1f8e5$b5d94790$218bd6b0$@ndzh.com> Date: Fri, 19 Aug 2016 19:30:12 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <147142304704.12189.4149817417200297360.idtracker@ietfa.amsl.com> <00c001d1f8e5$b5d94790$218bd6b0$@ndzh.com> To: Susan Hares X-Mailer: Apple Mail (2.3124) Archived-At: Cc: jhaas@pfrc.org, i2rs@ietf.org, draft-ietf-i2rs-protocol-security-requirements@ietf.org, The IESG , i2rs-chairs@ietf.org Subject: Re: [i2rs] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft-i?= =?utf-8?q?etf-i2rs-protocol-security-requirements-06=3A_=28with_COMMENT?= =?utf-8?q?=29?= X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Aug 2016 17:37:04 -0000 Hi Sue, thanks for you replies and background information. Please see further = below. Mirja > Am 18.08.2016 um 02:15 schrieb Susan Hares : >=20 > Mirja:=20 >=20 > Thank you for the review. Please see the comments below. Your = comments are sensible, but the sections were put in place to provide = background for the multiple working groups utilizing these requirements. = Please let me know if I can answer additional questions.=20 >=20 > Sue Hares=20 >=20 > -----Original Message----- > From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Mirja = Kuehlewind > Sent: Wednesday, August 17, 2016 4:37 AM > To: The IESG > Cc: jhaas@pfrc.org; i2rs@ietf.org; i2rs-chairs@ietf.org; = draft-ietf-i2rs-protocol-security-requirements@ietf.org > Subject: [i2rs] Mirja K=C3=BChlewind's No Objection on = draft-ietf-i2rs-protocol-security-requirements-06: (with COMMENT) >=20 > Mirja K=C3=BChlewind has entered the following ballot position for > draft-ietf-i2rs-protocol-security-requirements-06: No Objection >=20 > When responding, please keep the subject line intact and reply to all = email addresses included in the To and CC lines. (Feel free to cut this = introductory paragraph, however.) >=20 >=20 > Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > = https://datatracker.ietf.org/doc/draft-ietf-i2rs-protocol-security-require= ments/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > A few comments: >=20 > 1) I don't think copy&paste from RFC4949 is necessary. I would = recommend to remove this part and just name the definitions that are = needed. >=20 > Sue: Initially, the WG and the authors ran into problems with security = words. We included definitions that seem to resolve issues for the WG = and those who will need to implemented in NETCONF/RESTCONF. =20 I understand that this helped the writing process and discussion in the = working group. However, I still advise to remove this from the final RFC = given that readers can easily check the referred RFC if needed and this = avoids text duplications (which e.g. makes updates very hard). >=20 > 2) The following sentence seems to indicate that the refernce to = RFC4949 should be normative. > "The transfer of data via the I2RS protocol has the property of data = integrity described in [RFC4949]." > As I don't think this is needed, I would recommend to rather spell out = the properties here in this sentence. Also, to be honstest I not sure = what this sentence tells me at all. So maybe stating clearing what you = mean (instead of just having the reference) would help anyway. >=20 >=20 > Sue: I have moved RFC4949 to normative. RFC4949 states data = integrity means: a) data has not been changed, destroyed or lost in an = unauthorized (or accidental) manner, and b) the information has not = been modified or destroyed in an unauthorized manner. This statement = covers man-in-the middle attacks or unauthorized changes. =20 Okay. I would still recommend to spell this simply out in the draft = instead of just giving the reference. >=20 >=20 > 3) To me it's not really clear why there are several requirments docs = (that also are connected and refer each other; see e.g. section 3.6 and = SEC-REQ-16). The actually context of this doc is only 4 pages (3.1-3.6). = Couldn't those docs be combined to one requirements doc? >=20 > Sue: This is a good process question for a re-use protocol. A re-use = protocol has a different process than a protocol created out of a single = WG.=20 >=20 > I2RS broke the requirements into pieces so that as we got agreement on = one piece, the NETCONF/RESTCONF team could begin to work on that piece. = For example, the pub/sub requirements (RFC7923) is already being worked = on in NETCONF. The I2RS ephemeral state requirements have been delayed = by the NETMOD/NETCONF discussions on opstate. If the IESG wishes, after = we have completed this work, we can compile these requirements into a = single document. This process focuses on running code and rough = consensus rather than a single review process for the IESG.=20 Thanks that's very useful background information. However, even though = I=E2=80=99m happy to hear that this process worked well, the question = for final publication in one or multiple RFCs is if there is a benefit = for the final reading audience. Given that these docs are rather short = so could be well structured in one RFC and have interdependencies I = don=E2=80=99t see this benefit. I=E2=80=99d rather would assume that a = reader would anyway need to look at multiple docs in any case which = would suggest to have one doc. As you=E2=80=99ve been mention the IESG review process, I=E2=80=99d like = to comment on this. There is some discussion in the IESG about how to = treat different documents differently as they might need a different = level of review (and consensus). However, from my perspective the main = goal is to speed up the publication process. For me the workload is = basically the same no matter if I read 3 drafts with 15 pages each or 1 = draft with 45 pages. So with respective to this discuss the question for = me would rather be if this doc must be published at RFC at all: Does a = document provide valuable information for future readers or is it just a = documentation of the wig=E2=80=99s working process? We in the IESG = didn=E2=80=99t conclude this discussion and therefore I did not and am = not intending to ask this question regarding this document. =20 >=20 > 4) Section 3.1 says: > "The I2RS architecture [I-D.ietf-i2rs-architecture] sets the following = requirements:" > Why is this needed is RFC7921 already sets these requirements? >=20 > Sue: What a logical and rational statement, but unfortunately this = assumption ran into problems in the working groups (NETMOD/NETCONF) who = reviewed the requirements. Therefore, this section is there to provide = explicit definitions that resolved inter-group (I2RS to NETCONF and I2RS = to NETMOD) questions on lists.=20 >=20 > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs >=20 From nobody Fri Aug 19 11:17:02 2016 Return-Path: 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 7C74712D86D; Fri, 19 Aug 2016 11:16:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.738 X-Spam-Level: * X-Spam-Status: No, score=1.738 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, RDNS_NONE=0.793] autolearn=no 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 xrJXZhMjfKtM; Fri, 19 Aug 2016 11:16:57 -0700 (PDT) Received: from hickoryhill-consulting.com (unknown [50.245.122.97]) (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 07A9612D976; Fri, 19 Aug 2016 11:16:56 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=184.157.82.170; From: "Susan Hares" To: "'Mirja Kuehlewind \(IETF\)'" References: <147142304704.12189.4149817417200297360.idtracker@ietfa.amsl.com> <00c001d1f8e5$b5d94790$218bd6b0$@ndzh.com> In-Reply-To: Date: Fri, 19 Aug 2016 14:15:45 -0400 Message-ID: <013701d1fa45$b58980f0$209c82d0$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQI+ckvMtsLj2hKLR4cahhlPTc8O8QCqBF3kAdtyuzWfY3CtUA== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: jhaas@pfrc.org, i2rs@ietf.org, draft-ietf-i2rs-protocol-security-requirements@ietf.org, 'The IESG' , i2rs-chairs@ietf.org Subject: Re: [i2rs] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft-i?= =?utf-8?q?etf-i2rs-protocol-security-requirements-06=3A_=28with_COMMENT?= =?utf-8?q?=29?= X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Aug 2016 18:16:59 -0000 Mirja:=20 Thank you for your reply. I have removed the text regarding RFC4949. I = believe version-08.txt resolves these comments.=20 Sue=20 -----Original Message----- From: Mirja Kuehlewind (IETF) [mailto:ietf@kuehlewind.net]=20 Sent: Friday, August 19, 2016 1:30 PM To: Susan Hares Cc: The IESG; jhaas@pfrc.org; i2rs@ietf.org; i2rs-chairs@ietf.org; = draft-ietf-i2rs-protocol-security-requirements@ietf.org Subject: Re: [i2rs] Mirja K=C3=BChlewind's No Objection on = draft-ietf-i2rs-protocol-security-requirements-06: (with COMMENT) Hi Sue, thanks for you replies and background information. Please see further = below. Mirja > Am 18.08.2016 um 02:15 schrieb Susan Hares : >=20 > Mirja:=20 >=20 > Thank you for the review. Please see the comments below. Your = comments are sensible, but the sections were put in place to provide = background for the multiple working groups utilizing these requirements. = Please let me know if I can answer additional questions.=20 >=20 > Sue Hares=20 >=20 > -----Original Message----- > From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Mirja = Kuehlewind > Sent: Wednesday, August 17, 2016 4:37 AM > To: The IESG > Cc: jhaas@pfrc.org; i2rs@ietf.org; i2rs-chairs@ietf.org; = draft-ietf-i2rs-protocol-security-requirements@ietf.org > Subject: [i2rs] Mirja K=C3=BChlewind's No Objection on = draft-ietf-i2rs-protocol-security-requirements-06: (with COMMENT) >=20 > Mirja K=C3=BChlewind has entered the following ballot position for > draft-ietf-i2rs-protocol-security-requirements-06: No Objection >=20 > When responding, please keep the subject line intact and reply to all = email addresses included in the To and CC lines. (Feel free to cut this = introductory paragraph, however.) >=20 >=20 > Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > = https://datatracker.ietf.org/doc/draft-ietf-i2rs-protocol-security-requir= ements/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: >> = ---------------------------------------------------------------------- >>=20 >> A few comments: >>=20 >> 1) I don't think copy&paste from RFC4949 is necessary. I would = recommend to remove this part and just name the definitions that are = needed. >>=20 >> Sue: Initially, the WG and the authors ran into problems with = security words. We included definitions that seem to resolve issues for = the WG and those who will need to >implemented in NETCONF/RESTCONF. =20 >I understand that this helped the writing process and discussion in the = working group. However, I still advise to remove this from the final RFC = given that readers can easily >check the referred RFC if needed and this = avoids text duplications (which e.g. makes updates very hard). Sue: I removed the RFC4949 cut and paste in version -08.txt. Can I = consider this item closed?=20 >>=20 >> 2) The following sentence seems to indicate that the refernce to = RFC4949 should be normative. >> "The transfer of data via the I2RS protocol has the property of data = integrity described in [RFC4949]." >> As I don't think this is needed, I would recommend to rather spell = out the properties here in this sentence. Also, to be honstest I not = sure what this sentence tells me at all.=20 >> So maybe stating clearing what you mean (instead of just having the = reference) would help anyway. >> >> Sue: I have moved RFC4949 to normative. RFC4949 states data = integrity means: a) data has not been changed, destroyed or lost in an = unauthorized (or accidental) manner,=20 >> and b) the information has not been modified or destroyed in an = unauthorized manner. This statement covers man-in-the middle attacks = or unauthorized changes. =20 > Okay. I would still recommend to spell this simply out in the draft = instead of just giving the reference. Sue: I removed this text.=20 =20 >> 3) To me it's not really clear why there are several requirments docs = (that also are connected and refer each other; see e.g. section 3.6 and = SEC-REQ-16).=20 >The actually context of this doc is only 4 pages (3.1-3.6). Couldn't = those docs be combined to one requirements doc? >=20 > Sue: This is a good process question for a re-use protocol. A re-use = protocol has a different process than a protocol created out of a single = WG.=20 >=20 >> I2RS broke the requirements into pieces so that as we got agreement = on one piece, the NETCONF/RESTCONF team could begin to work on that = piece. =20 >> For example, the pub/sub requirements (RFC7923) is already being = worked on in NETCONF. =20 >> The I2RS ephemeral state requirements have been delayed by the = NETMOD/NETCONF discussions on opstate. =20 >> If the IESG wishes, after we have completed this work, we can = compile these requirements into a single document. =20 >> This process focuses on running code and rough consensus rather than = a single review process for the IESG.=20 > Thanks that's very useful background information. However, even though = I=E2=80=99m happy to hear that this process worked well, the question = for=20 >final publication in one or multiple RFCs is if there is a benefit for = the final reading audience.=20 >Given that these docs are rather short so could be well structured in = one RFC and have interdependencies I don=E2=80=99t see this benefit.=20 > I=E2=80=99d rather would assume that a reader would anyway need to = look at multiple docs in any case which would suggest to have one doc. This is a non-normative section:=20 Perhaps I was unclear. The final reading audience includes the = following: NETCONF WG, NETMOD WG, vendors, prototype implementers, and = operators.=20 The final audience review begins as soon as you approve it. The = NETCONF/NETMOD WG will not consider it real until it is an RFC. =20 In a re-use protocol, we can begin work as soon as you approve the = requirements.=20 >>Given that these docs are rather short so could be well structured in = one RFC and have interdependencies I don=E2=80=99t see this benefit.=20 >> I=E2=80=99d rather would assume that a reader would anyway need to = look at multiple docs in any case which would suggest to have one doc. > As you=E2=80=99ve been mention the IESG review process, I=E2=80=99d = like to comment on this. There is some discussion in the IESG about how = to treat different documents differently as they=20 > might need a different level of review (and consensus). However, from = my perspective the main goal is to speed up the publication process. For = me the workload is basically the > same no matter if I read 3 drafts = with 15 pages each or 1 draft with 45 pages. So with respective to this = discuss the question for me would rather be if this doc > must be published at RFC at all: Does a document provide valuable = information for future readers or is it just a documentation of the = wig=E2=80=99s working process?=20 > We in the IESG didn=E2=80=99t conclude this discussion and therefore I = did not and am not intending to ask this question regarding this = document. =20 This is a meta-question on IESG process. And off-topic to the review of = the document. In your consider of the solution, I think you need to = reconsider the re-use protocols as different than other protocols. This = document must be published as an RFC or we cannot get NETCONF/NETMOD WG = to expand their protocols to include I2RS Features. =20 The Pub/SUB work in NETCONF/RESTCONF needs these requirements finalizer = to make progress. Fast approval of the requirements for a re-use = protocol is critical to the WG trying to re-use a protocol. =20 > 4) Section 3.1 says: > "The I2RS architecture [I-D.ietf-i2rs-architecture] sets the following = requirements:" > Why is this needed is RFC7921 already sets these requirements? >=20 > Sue: What a logical and rational statement, but unfortunately this = assumption ran into problems in the working groups (NETMOD/NETCONF) who = reviewed the requirements. >Therefore, this section is there to provide = explicit definitions that resolved inter-group (I2RS to NETCONF and I2RS = to NETMOD) questions on lists.=20 > _____________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs >=20 From nobody Fri Aug 19 11:19:02 2016 Return-Path: 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 A7C0312D984; Fri, 19 Aug 2016 11:18:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.738 X-Spam-Level: * X-Spam-Status: No, score=1.738 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, RDNS_NONE=0.793] autolearn=no 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 Nv8s9qjjuVVg; Fri, 19 Aug 2016 11:18:55 -0700 (PDT) Received: from hickoryhill-consulting.com (unknown [50.245.122.97]) (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 0F90612D91F; Fri, 19 Aug 2016 11:18:54 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=184.157.82.170; From: "Susan Hares" To: "'Mirja Kuehlewind \(IETF\)'" References: <147142304704.12189.4149817417200297360.idtracker@ietfa.amsl.com> <00c001d1f8e5$b5d94790$218bd6b0$@ndzh.com> In-Reply-To: Date: Fri, 19 Aug 2016 14:17:45 -0400 Message-ID: <013901d1fa45$fd328910$f7979b30$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQI+ckvMtsLj2hKLR4cahhlPTc8O8QCqBF3kAdtyuzWfY3toMA== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: jhaas@pfrc.org, i2rs@ietf.org, draft-ietf-i2rs-protocol-security-requirements@ietf.org, 'The IESG' , i2rs-chairs@ietf.org Subject: Re: [i2rs] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft-i?= =?utf-8?q?etf-i2rs-protocol-security-requirements-06=3A_=28with_COMMENT?= =?utf-8?q?=29?= X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Aug 2016 18:18:57 -0000 Mirja:=20 Thank you for your input. I believe version-08.txt resolves all your = comments, and I have answered your questions in another email. Sue=20 -----Original Message----- From: Mirja Kuehlewind (IETF) [mailto:ietf@kuehlewind.net]=20 Sent: Friday, August 19, 2016 1:30 PM To: Susan Hares Cc: The IESG; jhaas@pfrc.org; i2rs@ietf.org; i2rs-chairs@ietf.org; = draft-ietf-i2rs-protocol-security-requirements@ietf.org Subject: Re: [i2rs] Mirja K=C3=BChlewind's No Objection on = draft-ietf-i2rs-protocol-security-requirements-06: (with COMMENT) Hi Sue, thanks for you replies and background information. Please see further = below. Mirja > Am 18.08.2016 um 02:15 schrieb Susan Hares : >=20 > Mirja:=20 >=20 > Thank you for the review. Please see the comments below. Your = comments are sensible, but the sections were put in place to provide = background for the multiple working groups utilizing these requirements. = Please let me know if I can answer additional questions.=20 >=20 > Sue Hares=20 >=20 > -----Original Message----- > From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Mirja = Kuehlewind > Sent: Wednesday, August 17, 2016 4:37 AM > To: The IESG > Cc: jhaas@pfrc.org; i2rs@ietf.org; i2rs-chairs@ietf.org; = draft-ietf-i2rs-protocol-security-requirements@ietf.org > Subject: [i2rs] Mirja K=C3=BChlewind's No Objection on = draft-ietf-i2rs-protocol-security-requirements-06: (with COMMENT) >=20 > Mirja K=C3=BChlewind has entered the following ballot position for > draft-ietf-i2rs-protocol-security-requirements-06: No Objection >=20 > When responding, please keep the subject line intact and reply to all = email addresses included in the To and CC lines. (Feel free to cut this = introductory paragraph, however.) >=20 >=20 > Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > = https://datatracker.ietf.org/doc/draft-ietf-i2rs-protocol-security-requir= ements/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > A few comments: >=20 > 1) I don't think copy&paste from RFC4949 is necessary. I would = recommend to remove this part and just name the definitions that are = needed. >=20 > Sue: Initially, the WG and the authors ran into problems with security = words. We included definitions that seem to resolve issues for the WG = and those who will need to implemented in NETCONF/RESTCONF. =20 I understand that this helped the writing process and discussion in the = working group. However, I still advise to remove this from the final RFC = given that readers can easily check the referred RFC if needed and this = avoids text duplications (which e.g. makes updates very hard). >=20 > 2) The following sentence seems to indicate that the refernce to = RFC4949 should be normative. > "The transfer of data via the I2RS protocol has the property of data = integrity described in [RFC4949]." > As I don't think this is needed, I would recommend to rather spell out = the properties here in this sentence. Also, to be honstest I not sure = what this sentence tells me at all. So maybe stating clearing what you = mean (instead of just having the reference) would help anyway. >=20 >=20 > Sue: I have moved RFC4949 to normative. RFC4949 states data = integrity means: a) data has not been changed, destroyed or lost in an = unauthorized (or accidental) manner, and b) the information has not = been modified or destroyed in an unauthorized manner. This statement = covers man-in-the middle attacks or unauthorized changes. =20 Okay. I would still recommend to spell this simply out in the draft = instead of just giving the reference. >=20 >=20 > 3) To me it's not really clear why there are several requirments docs = (that also are connected and refer each other; see e.g. section 3.6 and = SEC-REQ-16). The actually context of this doc is only 4 pages (3.1-3.6). = Couldn't those docs be combined to one requirements doc? >=20 > Sue: This is a good process question for a re-use protocol. A re-use = protocol has a different process than a protocol created out of a single = WG.=20 >=20 > I2RS broke the requirements into pieces so that as we got agreement on = one piece, the NETCONF/RESTCONF team could begin to work on that piece. = For example, the pub/sub requirements (RFC7923) is already being worked = on in NETCONF. The I2RS ephemeral state requirements have been delayed = by the NETMOD/NETCONF discussions on opstate. If the IESG wishes, after = we have completed this work, we can compile these requirements into a = single document. This process focuses on running code and rough = consensus rather than a single review process for the IESG.=20 Thanks that's very useful background information. However, even though = I=E2=80=99m happy to hear that this process worked well, the question = for final publication in one or multiple RFCs is if there is a benefit = for the final reading audience. Given that these docs are rather short = so could be well structured in one RFC and have interdependencies I = don=E2=80=99t see this benefit. I=E2=80=99d rather would assume that a = reader would anyway need to look at multiple docs in any case which = would suggest to have one doc. As you=E2=80=99ve been mention the IESG review process, I=E2=80=99d like = to comment on this. There is some discussion in the IESG about how to = treat different documents differently as they might need a different = level of review (and consensus). However, from my perspective the main = goal is to speed up the publication process. For me the workload is = basically the same no matter if I read 3 drafts with 15 pages each or 1 = draft with 45 pages. So with respective to this discuss the question for = me would rather be if this doc must be published at RFC at all: Does a = document provide valuable information for future readers or is it just a = documentation of the wig=E2=80=99s working process? We in the IESG = didn=E2=80=99t conclude this discussion and therefore I did not and am = not intending to ask this question regarding this document. =20 >=20 > 4) Section 3.1 says: > "The I2RS architecture [I-D.ietf-i2rs-architecture] sets the following = requirements:" > Why is this needed is RFC7921 already sets these requirements? >=20 > Sue: What a logical and rational statement, but unfortunately this = assumption ran into problems in the working groups (NETMOD/NETCONF) who = reviewed the requirements. Therefore, this section is there to provide = explicit definitions that resolved inter-group (I2RS to NETCONF and I2RS = to NETMOD) questions on lists.=20 >=20 > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs >=20 From nobody Fri Aug 19 12:01:40 2016 Return-Path: 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 59B1C12D9DF for ; Fri, 19 Aug 2016 12:01:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.149 X-Spam-Level: X-Spam-Status: No, score=-3.149 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.247, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=unavailable 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 rJKx9hFO8I-t for ; Fri, 19 Aug 2016 12:01:37 -0700 (PDT) Received: from kuehlewind.net (kuehlewind.net [83.169.45.111]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D9C0C12D803 for ; Fri, 19 Aug 2016 12:01:29 -0700 (PDT) Received: (qmail 19614 invoked from network); 19 Aug 2016 20:54:47 +0200 Received: from p5dec255c.dip0.t-ipconnect.de (HELO ?192.168.178.33?) (93.236.37.92) by kuehlewind.net with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 19 Aug 2016 20:54:46 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: "Mirja Kuehlewind (IETF)" In-Reply-To: <013701d1fa45$b58980f0$209c82d0$@ndzh.com> Date: Fri, 19 Aug 2016 20:54:45 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <33A86029-D3D3-4BD6-9B48-2273F2632673@kuehlewind.net> References: <147142304704.12189.4149817417200297360.idtracker@ietfa.amsl.com> <00c001d1f8e5$b5d94790$218bd6b0$@ndzh.com> <013701d1fa45$b58980f0$209c82d0$@ndzh.com> To: Susan Hares X-Mailer: Apple Mail (2.3124) Archived-At: Cc: jhaas@pfrc.org, i2rs@ietf.org, The IESG , i2rs-chairs@ietf.org, draft-ietf-i2rs-protocol-security-requirements@ietf.org Subject: Re: [i2rs] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft-i?= =?utf-8?q?etf-i2rs-protocol-security-requirements-06=3A_=28with_COMMENT?= =?utf-8?q?=29?= X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Aug 2016 19:01:39 -0000 Hi Sue, thanks for addressing my comments!=20 The only remaining one is if this doc should be published as an own RFC = or merged with the other requirement documents. I mainly wanted to raise = this point for discussion and will leave the decision to the responsible = AD. Mirja > Am 19.08.2016 um 20:15 schrieb Susan Hares : >=20 > Mirja:=20 >=20 > Thank you for your reply. I have removed the text regarding RFC4949. = I believe version-08.txt resolves these comments.=20 >=20 > Sue=20 >=20 > -----Original Message----- > From: Mirja Kuehlewind (IETF) [mailto:ietf@kuehlewind.net]=20 > Sent: Friday, August 19, 2016 1:30 PM > To: Susan Hares > Cc: The IESG; jhaas@pfrc.org; i2rs@ietf.org; i2rs-chairs@ietf.org; = draft-ietf-i2rs-protocol-security-requirements@ietf.org > Subject: Re: [i2rs] Mirja K=C3=BChlewind's No Objection on = draft-ietf-i2rs-protocol-security-requirements-06: (with COMMENT) >=20 > Hi Sue, >=20 > thanks for you replies and background information. Please see further = below. >=20 > Mirja >=20 >> Am 18.08.2016 um 02:15 schrieb Susan Hares : >>=20 >> Mirja:=20 >>=20 >> Thank you for the review. Please see the comments below. Your = comments are sensible, but the sections were put in place to provide = background for the multiple working groups utilizing these requirements. = Please let me know if I can answer additional questions.=20 >>=20 >> Sue Hares=20 >>=20 >> -----Original Message----- >> From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Mirja = Kuehlewind >> Sent: Wednesday, August 17, 2016 4:37 AM >> To: The IESG >> Cc: jhaas@pfrc.org; i2rs@ietf.org; i2rs-chairs@ietf.org; = draft-ietf-i2rs-protocol-security-requirements@ietf.org >> Subject: [i2rs] Mirja K=C3=BChlewind's No Objection on = draft-ietf-i2rs-protocol-security-requirements-06: (with COMMENT) >>=20 >> Mirja K=C3=BChlewind has entered the following ballot position for >> draft-ietf-i2rs-protocol-security-requirements-06: No Objection >>=20 >> When responding, please keep the subject line intact and reply to all = email addresses included in the To and CC lines. (Feel free to cut this = introductory paragraph, however.) >>=20 >>=20 >> Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html >> for more information about IESG DISCUSS and COMMENT positions. >>=20 >>=20 >> The document, along with other ballot positions, can be found here: >> = https://datatracker.ietf.org/doc/draft-ietf-i2rs-protocol-security-require= ments/ >>=20 >>=20 >>=20 >> = ---------------------------------------------------------------------- >> COMMENT: >>> = ---------------------------------------------------------------------- >>>=20 >>> A few comments: >>>=20 >>> 1) I don't think copy&paste from RFC4949 is necessary. I would = recommend to remove this part and just name the definitions that are = needed. >>>=20 >>> Sue: Initially, the WG and the authors ran into problems with = security words. We included definitions that seem to resolve issues for = the WG and those who will need to >implemented in NETCONF/RESTCONF. =20 >=20 >> I understand that this helped the writing process and discussion in = the working group. However, I still advise to remove this from the final = RFC given that readers can easily >check the referred RFC if needed and = this avoids text duplications (which e.g. makes updates very hard). >=20 > Sue: I removed the RFC4949 cut and paste in version -08.txt. Can I = consider this item closed?=20 >=20 >>>=20 >>> 2) The following sentence seems to indicate that the refernce to = RFC4949 should be normative. >>> "The transfer of data via the I2RS protocol has the property of data = integrity described in [RFC4949]." >>> As I don't think this is needed, I would recommend to rather spell = out the properties here in this sentence. Also, to be honstest I not = sure what this sentence tells me at all.=20 >>> So maybe stating clearing what you mean (instead of just having the = reference) would help anyway. >>>=20 >>> Sue: I have moved RFC4949 to normative. RFC4949 states data = integrity means: a) data has not been changed, destroyed or lost in an = unauthorized (or accidental) manner,=20 >>> and b) the information has not been modified or destroyed in an = unauthorized manner. This statement covers man-in-the middle attacks = or unauthorized changes. =20 >=20 >> Okay. I would still recommend to spell this simply out in the draft = instead of just giving the reference. >=20 > Sue: I removed this text.=20 >=20 >>> 3) To me it's not really clear why there are several requirments = docs (that also are connected and refer each other; see e.g. section 3.6 = and SEC-REQ-16).=20 >> The actually context of this doc is only 4 pages (3.1-3.6). Couldn't = those docs be combined to one requirements doc? >>=20 >> Sue: This is a good process question for a re-use protocol. A = re-use protocol has a different process than a protocol created out of a = single WG.=20 >>=20 >>> I2RS broke the requirements into pieces so that as we got agreement = on one piece, the NETCONF/RESTCONF team could begin to work on that = piece. =20 >>> For example, the pub/sub requirements (RFC7923) is already being = worked on in NETCONF. =20 >>> The I2RS ephemeral state requirements have been delayed by the = NETMOD/NETCONF discussions on opstate. =20 >>> If the IESG wishes, after we have completed this work, we can = compile these requirements into a single document. =20 >>> This process focuses on running code and rough consensus rather than = a single review process for the IESG.=20 >=20 >> Thanks that's very useful background information. However, even = though I=E2=80=99m happy to hear that this process worked well, the = question for=20 >> final publication in one or multiple RFCs is if there is a benefit = for the final reading audience.=20 >> Given that these docs are rather short so could be well structured in = one RFC and have interdependencies I don=E2=80=99t see this benefit.=20 >> I=E2=80=99d rather would assume that a reader would anyway need to = look at multiple docs in any case which would suggest to have one doc. >=20 > This is a non-normative section:=20 >=20 > Perhaps I was unclear. The final reading audience includes the = following: NETCONF WG, NETMOD WG, vendors, prototype implementers, and = operators.=20 > The final audience review begins as soon as you approve it. The = NETCONF/NETMOD WG will not consider it real until it is an RFC. =20 > In a re-use protocol, we can begin work as soon as you approve the = requirements.=20 >=20 >>> Given that these docs are rather short so could be well structured = in one RFC and have interdependencies I don=E2=80=99t see this benefit.=20= >>> I=E2=80=99d rather would assume that a reader would anyway need to = look at multiple docs in any case which would suggest to have one doc. >=20 >> As you=E2=80=99ve been mention the IESG review process, I=E2=80=99d = like to comment on this. There is some discussion in the IESG about how = to treat different documents differently as they=20 >> might need a different level of review (and consensus). However, from = my perspective the main goal is to speed up the publication process. For = me the workload is basically the > same no matter if I read 3 drafts = with 15 pages each or 1 draft with 45 pages. So with respective to this = discuss the question for me would rather be if this doc >> must be published at RFC at all: Does a document provide valuable = information for future readers or is it just a documentation of the = wig=E2=80=99s working process?=20 >> We in the IESG didn=E2=80=99t conclude this discussion and therefore = I did not and am not intending to ask this question regarding this = document. >=20 > This is a meta-question on IESG process. And off-topic to the review = of the document. In your consider of the solution, I think you need to = reconsider the re-use protocols as different than other protocols. This = document must be published as an RFC or we cannot get NETCONF/NETMOD WG = to expand their protocols to include I2RS Features. =20 > The Pub/SUB work in NETCONF/RESTCONF needs these requirements = finalizer to make progress. Fast approval of the requirements for a = re-use protocol is critical to the WG trying to re-use a protocol. =20 >=20 >> 4) Section 3.1 says: >> "The I2RS architecture [I-D.ietf-i2rs-architecture] sets the = following requirements:" >> Why is this needed is RFC7921 already sets these requirements? >>=20 >> Sue: What a logical and rational statement, but unfortunately this = assumption ran into problems in the working groups (NETMOD/NETCONF) who = reviewed the requirements. >Therefore, this section is there to provide = explicit definitions that resolved inter-group (I2RS to NETCONF and I2RS = to NETMOD) questions on lists.=20 >> _____________________________________________ >> i2rs mailing list >> i2rs@ietf.org >> https://www.ietf.org/mailman/listinfo/i2rs >>=20 >=20 >=20 From nobody Fri Aug 19 13:11:34 2016 Return-Path: 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 C22B212B047; Fri, 19 Aug 2016 13:11:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.999 X-Spam-Level: X-Spam-Status: No, score=-101.999 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] 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 OMwNG3mQEIsE; Fri, 19 Aug 2016 13:11:14 -0700 (PDT) Received: from mail-ua0-x233.google.com (mail-ua0-x233.google.com [IPv6:2607:f8b0:400c:c08::233]) (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 30DE612D144; Fri, 19 Aug 2016 13:02:39 -0700 (PDT) Received: by mail-ua0-x233.google.com with SMTP id k90so98260013uak.1; Fri, 19 Aug 2016 13:02:39 -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; bh=+2JTS6tjaowr0Eukk+5uhOoRQS+XQE+H+XAhYkgCMOY=; b=qKp0elOmobnfe+lBAf3dESgEj3IpksWFHp61uDpYQejDoDp0CEXrEdr7bg8kWk6AgP PFEDP98dosa+r1zxEYBOx9zdH6U/gTz1OHbtM9XwqbiWXiBsvl0wHt8R92q/Yd0wu5jR s7xS5T1FvfE8cnTBSONlJXImy2L13H3d+5AX1PuO1/jQEs6Xnk+jTt+jSvbP5vM+ShbZ 9XVoYuQHLokQg+wu1DBtzfVz+vg0KIHVIk8/xdFruZlt2SSmkeVmaHs5Q17XX+6A7Dw1 qdKr6I4h0GxGJ2UWbf5cLNLx4tbtBvxRRgM31BjAihM2kXLf0KjBXNspvK2UUxhPVguf g1yw== 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; bh=+2JTS6tjaowr0Eukk+5uhOoRQS+XQE+H+XAhYkgCMOY=; b=Yes9HJERMqJAIfiKyh4ycxEH+/04kmjGkMzxX+ZzhM2CYPuMCg8Bha/I7BYGayxIkk 41jvJN/ZVsloHbabsDW6ug20lg3z66hwzYBX/BudDksPThlAFZ932d1rKR9U/BfRC38e J4B3vwirshYmFvC/OzhRqpOksFGRvIrI6oulerrmuqYQ1fDJnZJii/D2nBkA6RVbELyu lOtrEQdTJgpmhqDHhSWr00W5LwvKxFcbXKNWIqUL0zm4hzIccDIW6mT5eGh7bmWf1MEb xM1tpO+ErLdlCwuFvog2dTjlReozOeMbCmkRiQxz0q8n/Himj660wgCdaw7FI5MccJQg jsRw== X-Gm-Message-State: AEkoousRzGCF21JBQKc8mTeVcJlLue9TG9dkXNTMcctp4NFt7AASTQlwTac5DRxA62LguFLr6znHLpDlEERxsA== X-Received: by 10.176.65.40 with SMTP id j37mr4200404uad.116.1471636958198; Fri, 19 Aug 2016 13:02:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.50.7 with HTTP; Fri, 19 Aug 2016 13:02:37 -0700 (PDT) In-Reply-To: <33A86029-D3D3-4BD6-9B48-2273F2632673@kuehlewind.net> References: <147142304704.12189.4149817417200297360.idtracker@ietfa.amsl.com> <00c001d1f8e5$b5d94790$218bd6b0$@ndzh.com> <013701d1fa45$b58980f0$209c82d0$@ndzh.com> <33A86029-D3D3-4BD6-9B48-2273F2632673@kuehlewind.net> From: Alia Atlas Date: Fri, 19 Aug 2016 16:02:37 -0400 Message-ID: To: "Mirja Kuehlewind (IETF)" Content-Type: multipart/alternative; boundary=94eb2c122a9a21c225053a722e8f Archived-At: Cc: "i2rs@ietf.org" , i2rs-chairs@ietf.org, The IESG , Jeffrey Haas , Susan Hares , draft-ietf-i2rs-protocol-security-requirements@ietf.org Subject: Re: [i2rs] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft-i?= =?utf-8?q?etf-i2rs-protocol-security-requirements-06=3A_=28with_COMMENT?= =?utf-8?q?=29?= X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Aug 2016 20:11:27 -0000 --94eb2c122a9a21c225053a722e8f Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Mirja, On Fri, Aug 19, 2016 at 2:54 PM, Mirja Kuehlewind (IETF) < ietf@kuehlewind.net> wrote: > Hi Sue, > > thanks for addressing my comments! > > The only remaining one is if this doc should be published as an own RFC o= r > merged with the other requirement documents. I mainly wanted to raise thi= s > point for discussion and will leave the decision to the responsible AD. It needs to progress on its own. Thanks, Alia > Mirja > > > > Am 19.08.2016 um 20:15 schrieb Susan Hares : > > > > Mirja: > > > > Thank you for your reply. I have removed the text regarding RFC4949. = I > believe version-08.txt resolves these comments. > > > > Sue > > > > -----Original Message----- > > From: Mirja Kuehlewind (IETF) [mailto:ietf@kuehlewind.net] > > Sent: Friday, August 19, 2016 1:30 PM > > To: Susan Hares > > Cc: The IESG; jhaas@pfrc.org; i2rs@ietf.org; i2rs-chairs@ietf.org; > draft-ietf-i2rs-protocol-security-requirements@ietf.org > > Subject: Re: [i2rs] Mirja K=C3=BChlewind's No Objection on > draft-ietf-i2rs-protocol-security-requirements-06: (with COMMENT) > > > > Hi Sue, > > > > thanks for you replies and background information. Please see further > below. > > > > Mirja > > > >> Am 18.08.2016 um 02:15 schrieb Susan Hares : > >> > >> Mirja: > >> > >> Thank you for the review. Please see the comments below. Your > comments are sensible, but the sections were put in place to provide > background for the multiple working groups utilizing these requirements. > Please let me know if I can answer additional questions. > >> > >> Sue Hares > >> > >> -----Original Message----- > >> From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Mirja Kuehlewin= d > >> Sent: Wednesday, August 17, 2016 4:37 AM > >> To: The IESG > >> Cc: jhaas@pfrc.org; i2rs@ietf.org; i2rs-chairs@ietf.org; > draft-ietf-i2rs-protocol-security-requirements@ietf.org > >> Subject: [i2rs] Mirja K=C3=BChlewind's No Objection on > draft-ietf-i2rs-protocol-security-requirements-06: (with COMMENT) > >> > >> Mirja K=C3=BChlewind has entered the following ballot position for > >> draft-ietf-i2rs-protocol-security-requirements-06: No Objection > >> > >> When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > >> > >> > >> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria. > html > >> for more information about IESG DISCUSS and COMMENT positions. > >> > >> > >> The document, along with other ballot positions, can be found here: > >> https://datatracker.ietf.org/doc/draft-ietf-i2rs-protocol- > security-requirements/ > >> > >> > >> > >> ---------------------------------------------------------------------- > >> COMMENT: > >>> ---------------------------------------------------------------------= - > >>> > >>> A few comments: > >>> > >>> 1) I don't think copy&paste from RFC4949 is necessary. I would > recommend to remove this part and just name the definitions that are need= ed. > >>> > >>> Sue: Initially, the WG and the authors ran into problems with securit= y > words. We included definitions that seem to resolve issues for the WG an= d > those who will need to >implemented in NETCONF/RESTCONF. > > > >> I understand that this helped the writing process and discussion in th= e > working group. However, I still advise to remove this from the final RFC > given that readers can easily >check the referred RFC if needed and this > avoids text duplications (which e.g. makes updates very hard). > > > > Sue: I removed the RFC4949 cut and paste in version -08.txt. Can I > consider this item closed? > > > >>> > >>> 2) The following sentence seems to indicate that the refernce to > RFC4949 should be normative. > >>> "The transfer of data via the I2RS protocol has the property of data > integrity described in [RFC4949]." > >>> As I don't think this is needed, I would recommend to rather spell ou= t > the properties here in this sentence. Also, to be honstest I not sure wha= t > this sentence tells me at all. > >>> So maybe stating clearing what you mean (instead of just having the > reference) would help anyway. > >>> > >>> Sue: I have moved RFC4949 to normative. RFC4949 states data > integrity means: a) data has not been changed, destroyed or lost in an > unauthorized (or accidental) manner, > >>> and b) the information has not been modified or destroyed in an > unauthorized manner. This statement covers man-in-the middle attacks or > unauthorized changes. > > > >> Okay. I would still recommend to spell this simply out in the draft > instead of just giving the reference. > > > > Sue: I removed this text. > > > >>> 3) To me it's not really clear why there are several requirments docs > (that also are connected and refer each other; see e.g. section 3.6 and > SEC-REQ-16). > >> The actually context of this doc is only 4 pages (3.1-3.6). Couldn't > those docs be combined to one requirements doc? > >> > >> Sue: This is a good process question for a re-use protocol. A re-use > protocol has a different process than a protocol created out of a single = WG. > >> > >>> I2RS broke the requirements into pieces so that as we got agreement o= n > one piece, the NETCONF/RESTCONF team could begin to work on that piece. > >>> For example, the pub/sub requirements (RFC7923) is already being > worked on in NETCONF. > >>> The I2RS ephemeral state requirements have been delayed by the > NETMOD/NETCONF discussions on opstate. > >>> If the IESG wishes, after we have completed this work, we can compile > these requirements into a single document. > >>> This process focuses on running code and rough consensus rather than = a > single review process for the IESG. > > > >> Thanks that's very useful background information. However, even though > I=E2=80=99m happy to hear that this process worked well, the question for > >> final publication in one or multiple RFCs is if there is a benefit for > the final reading audience. > >> Given that these docs are rather short so could be well structured in > one RFC and have interdependencies I don=E2=80=99t see this benefit. > >> I=E2=80=99d rather would assume that a reader would anyway need to loo= k at > multiple docs in any case which would suggest to have one doc. > > > > This is a non-normative section: > > > > Perhaps I was unclear. The final reading audience includes the > following: NETCONF WG, NETMOD WG, vendors, prototype implementers, and > operators. > > The final audience review begins as soon as you approve it. The > NETCONF/NETMOD WG will not consider it real until it is an RFC. > > In a re-use protocol, we can begin work as soon as you approve the > requirements. > > > >>> Given that these docs are rather short so could be well structured in > one RFC and have interdependencies I don=E2=80=99t see this benefit. > >>> I=E2=80=99d rather would assume that a reader would anyway need to lo= ok at > multiple docs in any case which would suggest to have one doc. > > > >> As you=E2=80=99ve been mention the IESG review process, I=E2=80=99d li= ke to comment on > this. There is some discussion in the IESG about how to treat different > documents differently as they > >> might need a different level of review (and consensus). However, from > my perspective the main goal is to speed up the publication process. For = me > the workload is basically the > same no matter if I read 3 drafts with 15 > pages each or 1 draft with 45 pages. So with respective to this discuss t= he > question for me would rather be if this doc > >> must be published at RFC at all: Does a document provide valuable > information for future readers or is it just a documentation of the wig= =E2=80=99s > working process? > >> We in the IESG didn=E2=80=99t conclude this discussion and therefore I= did not > and am not intending to ask this question regarding this document. > > > > This is a meta-question on IESG process. And off-topic to the review o= f > the document. In your consider of the solution, I think you need to > reconsider the re-use protocols as different than other protocols. This > document must be published as an RFC or we cannot get NETCONF/NETMOD WG t= o > expand their protocols to include I2RS Features. > > The Pub/SUB work in NETCONF/RESTCONF needs these requirements finalizer > to make progress. Fast approval of the requirements for a re-use protoco= l > is critical to the WG trying to re-use a protocol. > > > >> 4) Section 3.1 says: > >> "The I2RS architecture [I-D.ietf-i2rs-architecture] sets the following > requirements:" > >> Why is this needed is RFC7921 already sets these requirements? > >> > >> Sue: What a logical and rational statement, but unfortunately this > assumption ran into problems in the working groups (NETMOD/NETCONF) who > reviewed the requirements. >Therefore, this section is there to provide > explicit definitions that resolved inter-group (I2RS to NETCONF and I2RS = to > NETMOD) questions on lists. > >> _____________________________________________ > >> i2rs mailing list > >> i2rs@ietf.org > >> https://www.ietf.org/mailman/listinfo/i2rs > >> > > > > > > --94eb2c122a9a21c225053a722e8f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Mirja,
On Fri, Aug 19, 2016 at 2:54 PM, Mirja Kuehlewind (IETF) <ietf@= kuehlewind.net> wrote:
Hi S= ue,

thanks for addressing my comments!

The only remaining one is if this doc should be published as an own RFC or = merged with the other requirement documents. I mainly wanted to raise this = point for discussion and will leave the decision to the responsible AD.

It needs to progress on its own.
Thanks,
Alia=C2=A0

=C2=A0
Mirja


> Am 19.08.2016 um 20:15 schrieb Susan Hares <shares@ndzh.com>:
>
> Mirja:
>
> Thank you for your reply.=C2=A0 I have removed the text regarding RFC4= 949.=C2=A0 I believe version-08.txt resolves these comments.
>
> Sue
>
> -----Original Message-----
> From: Mirja Kuehlewind (IETF) [mailto:ietf@kuehlewind.net]
> Sent: Friday, August 19, 2016 1:30 PM
> To: Susan Hares
> Cc: The IESG; jhaas@pfrc.org; i2rs@ietf.org; i2rs-chairs@ietf.org; draft-ietf-i2rs-protocol-secu= rity-requirements@ietf.org
> Subject: Re: [i2rs] Mirja K=C3=BChlewind's No Objection on draft-i= etf-i2rs-protocol-security-requirements-06: (with COMMENT)
>
> Hi Sue,
>
> thanks for you replies and background information. Please see further = below.
>
> Mirja
>
>> Am 18.08.2016 um 02:15 schrieb Susan Hares <shares@ndzh.com>:
>>
>> Mirja:
>>
>> Thank you for the review.=C2=A0 Please see the comments below.=C2= =A0 =C2=A0 Your comments are sensible, but the sections were put in place t= o provide background for the multiple working groups utilizing these requir= ements.=C2=A0 Please let me know if I can answer additional questions.
>>
>> Sue Hares
>>
>> -----Original Message-----
>> From: i2rs [mailto:i2rs-b= ounces@ietf.org] On Behalf Of Mirja Kuehlewind
>> Sent: Wednesday, August 17, 2016 4:37 AM
>> To: The IESG
>> Cc: jhaas@pfrc.org; i2rs@ietf.org; i2rs-chairs@ietf.org; draft-ietf-i2rs-protocol-security-= requirements@ietf.org
>> Subject: [i2rs] Mirja K=C3=BChlewind's No Objection on draft-i= etf-i2rs-protocol-security-requirements-06: (with COMMENT)
>>
>> Mirja K=C3=BChlewind has entered the following ballot position for=
>> draft-ietf-i2rs-protocol-security-requirements-06: No Objecti= on
>>
>> When responding, please keep the subject line intact and reply to = all email addresses included in the To and CC lines. (Feel free to cut this= introductory paragraph, however.)
>>
>>
>> Please refer to https://www.ietf.o= rg/iesg/statement/discuss-criteria.html
>> for more information about IESG DISCUSS and COMMENT positions.
>>
>>
>> The document, along with other ballot positions, can be found here= :
>> https://dat= atracker.ietf.org/doc/draft-ietf-i2rs-protocol-security-requireme= nts/
>>
>>
>>
>> ------------------------------------------------------------<= wbr>----------
>> COMMENT:
>>> ---------------------------------------------------------= -------------
>>>
>>> A few comments:
>>>
>>> 1) I don't think copy&paste from RFC4949 is necessary.= I would recommend to remove this part and just name the definitions that a= re needed.
>>>
>>> Sue: Initially, the WG and the authors ran into problems with = security words.=C2=A0 We included definitions that seem to resolve issues f= or the WG and those who will need to >implemented in NETCONF/RESTCONF. >
>> I understand that this helped the writing process and discussion i= n the working group. However, I still advise to remove this from the final = RFC given that readers can easily >check the referred RFC if needed and = this avoids text duplications (which e.g. makes updates very hard).
>
> Sue: I removed the RFC4949 cut and paste in version -08.txt.=C2=A0 =C2= =A0Can I consider this item closed?
>
>>>
>>> 2) The following sentence seems to indicate that the refernce = to RFC4949 should be normative.
>>> "The transfer of data via the I2RS protocol has the prope= rty of data integrity described in [RFC4949]."
>>> As I don't think this is needed, I would recommend to rath= er spell out the properties here in this sentence. Also, to be honstest I n= ot sure what this sentence tells me at all.
>>> So maybe stating clearing what you mean (instead of just havin= g the reference) would help anyway.
>>>
>>> Sue: I have moved RFC4949 to normative.=C2=A0 =C2=A0RFC4949 st= ates data integrity means: a) data has not been changed, destroyed or lost = in an unauthorized (or accidental) manner,
>>> and b) the information has not been modified or destroyed in a= n unauthorized manner.=C2=A0 =C2=A0This statement covers man-in-the middle = attacks or unauthorized changes.
>
>> Okay. I would still recommend to spell this simply out in the draf= t instead of just giving the reference.
>
> Sue: I removed this text.
>
>>> 3) To me it's not really clear why there are several requi= rments docs (that also are connected and refer each other; see e.g. section= 3.6 and SEC-REQ-16).
>> The actually context of this doc is only 4 pages (3.1-3.6). Couldn= 't those docs be combined to one requirements doc?
>>
>> Sue: This is a good process question for a re-use protocol.=C2=A0 = =C2=A0A re-use protocol has a different process than a protocol created out= of a single WG.
>>
>>> I2RS broke the requirements into pieces so that as we got agre= ement on one piece, the NETCONF/RESTCONF team could begin to work on that p= iece.
>>> For example, the pub/sub requirements (RFC7923) is already bei= ng worked on in NETCONF.
>>> The I2RS ephemeral state requirements have been delayed by the= NETMOD/NETCONF discussions on opstate.
>>> If the IESG wishes, after we have completed this work, we can = compile these requirements into a single document.
>>> This process focuses on running code and rough consensus rathe= r than a single review process for the IESG.
>
>> Thanks that's very useful background information. However, eve= n though I=E2=80=99m happy to hear that this process worked well, the quest= ion for
>> final publication in one or multiple RFCs is if there is a benefit= for the final reading audience.
>> Given that these docs are rather short so could be well structured= in one RFC and have interdependencies I don=E2=80=99t see this benefit. >> I=E2=80=99d rather would assume that a reader would anyway need to= look at multiple docs in any case which would suggest to have one doc.
>
> This is a non-normative section:
>
> Perhaps I was unclear.=C2=A0 The final reading audience includes the f= ollowing: NETCONF WG, NETMOD WG,=C2=A0 vendors, prototype implementers, and= operators.
> The final audience review begins as soon as you approve it.=C2=A0 The = NETCONF/NETMOD WG will not consider it real until it is an RFC.
> In a re-use protocol, we can begin work as soon as you approve the req= uirements.
>
>>> Given that these docs are rather short so could be well struct= ured in one RFC and have interdependencies I don=E2=80=99t see this benefit= .
>>> I=E2=80=99d rather would assume that a reader would anyway nee= d to look at multiple docs in any case which would suggest to have one doc.=
>
>> As you=E2=80=99ve been mention the IESG review process, I=E2=80=99= d like to comment on this. There is some discussion in the IESG about how t= o treat different documents differently as they
>> might need a different level of review (and consensus). However, f= rom my perspective the main goal is to speed up the publication process. Fo= r me the workload is basically the > same no matter if I read 3 drafts w= ith 15 pages each or 1 draft with 45 pages. So with respective to this disc= uss the question for me would rather be if this doc
>> must be published at RFC at all: Does a document provide valuable = information for future readers or is it just a documentation of the wig=E2= =80=99s working process?
>> We in the IESG didn=E2=80=99t conclude this discussion and therefo= re I did not and am not intending to ask this question regarding this docum= ent.
>
> This is a meta-question on IESG process.=C2=A0 And off-topic to the re= view of the document.=C2=A0 In your consider of the solution, I think you n= eed to reconsider the re-use protocols as different than other protocols.= =C2=A0 This document must be published as an RFC or we cannot get NETCONF/N= ETMOD WG to expand their protocols to include I2RS Features.
> The Pub/SUB work in NETCONF/RESTCONF needs these requirements finalize= r to make progress.=C2=A0 Fast approval of the requirements for a re-use pr= otocol is critical to the WG trying to re-use a protocol.
>
>> 4) Section 3.1 says:
>> "The I2RS architecture [I-D.ietf-i2rs-architecture] sets the = following requirements:"
>> Why is this needed is RFC7921 already sets these requirements?
>>
>> Sue:=C2=A0 What a logical and rational statement, but unfortunatel= y this assumption ran into problems in the working groups (NETMOD/NETCONF) = who reviewed the requirements.=C2=A0 >Therefore, this section is there t= o provide explicit definitions that resolved inter-group (I2RS to NETCONF a= nd I2RS to NETMOD) questions on lists.
>> _____________________________________________
>> i2rs mailing list
>> i2rs@ietf.org
>> https://www.ietf.org/mailman/listinfo/i2rs
>>
>
>


--94eb2c122a9a21c225053a722e8f-- From nobody Fri Aug 19 14:05:00 2016 Return-Path: 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 46C7D12D741; Fri, 19 Aug 2016 13:16:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.782 X-Spam-Level: X-Spam-Status: No, score=-4.782 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.247, SPF_SOFTFAIL=0.665] 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 4U4sdg1XpoEC; Fri, 19 Aug 2016 13:16:51 -0700 (PDT) Received: from oldperseverance.encs.concordia.ca (oldperseverance.encs.concordia.ca [132.205.96.92]) by ietfa.amsl.com (Postfix) with ESMTP id 7823E12D7DB; Fri, 19 Aug 2016 13:14:36 -0700 (PDT) Received: from [IPv6:::1] (bill@poise.encs.concordia.ca [132.205.2.209]) by oldperseverance.encs.concordia.ca (envelope-from william.atwood@concordia.ca) (8.13.7/8.13.7) with ESMTP id u7JKESZg008048; Fri, 19 Aug 2016 16:14:28 -0400 To: Susan Hares , "'Andy Bierman'" References: <013b01d1f8ee$31fa09b0$95ee1d10$@ndzh.com> <20160818073203.GA4338@elstar.local> <04b501d1f949$116c63e0$34452ba0$@ndzh.com> <20160818121405.GA5282@elstar.local> <051301d1f950$7739c670$65ad5350$@ndzh.com> <20160818130555.GA5366@elstar.local> <051701d1f952$c4ae0b30$4e0a2190$@ndzh.com> <6BCE198E4EAEFC4CAB45D75826EFB0761525CCD7@eusaamb101.ericsson.se> <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> <036801d1fa2a$466e9e00$d34bda00$@ndzh.com> <001501d1fa30$46d0ac70$d4720550$@ndzh.com> <00e701d1fa3a$8cf41a70$a6dc4f50$@ndzh.com> From: William Atwood Organization: Concordia University, Montreal Message-ID: Date: Fri, 19 Aug 2016 16:14:29 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <00e701d1fa3a$8cf41a70$a6dc4f50$@ndzh.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.58 on oldperseverance.encs.concordia.ca at 2016-08-19 16:14:31 EDT Archived-At: X-Mailman-Approved-At: Fri, 19 Aug 2016 14:04:58 -0700 Cc: i2rs@ietf.org, 'Alissa Cooper' , 'Juergen Schoenwaelder' , i2rs-chairs@ietf.org, 'Kathleen Moriarty' , 'IESG' , 'Jeffrey Haas' , 'Joel Halpern' , 'Lou Berger' , 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Aug 2016 20:16:57 -0000 See suggestion below:- On 19/08/2016 12:55 PM, Susan Hares wrote: > > New: > > / A non-secure transport can be used for publishing telemetry data or may > > other operational state that was specifically indicated to non- be non- > > confidential in the data model. / > > can = it is possible to do it may = you have permission to do it I offer two choices for the second correction: s/to/to be/ (as indicated) s/to/as/ (which is perhaps better than my first suggestion) Bill -- Dr. J.W. Atwood, Eng. tel: +1 (514) 848-2424 x3046 Distinguished Professor Emeritus fax: +1 (514) 848-2830 Department of Computer Science and Software Engineering Concordia University EV 3.185 email:william.atwood@concordia.ca 1455 de Maisonneuve Blvd. West http://users.encs.concordia.ca/~bill Montreal, Quebec Canada H3G 1M8 From nobody Fri Aug 19 14:05:03 2016 Return-Path: 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 C487012D7D0; Fri, 19 Aug 2016 13:29:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.999 X-Spam-Level: X-Spam-Status: No, score=-101.999 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] 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 LmO4EstffPFH; Fri, 19 Aug 2016 13:29:26 -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 50C6B12D781; Fri, 19 Aug 2016 13:29:26 -0700 (PDT) Received: by mail-ua0-x230.google.com with SMTP id 97so99158962uav.3; Fri, 19 Aug 2016 13:29:26 -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; bh=vCYJBZ/egpNBu9rDMrBzPA+fl+z8HORH5O46LxZfdR0=; b=h8Q4BhliNjnnmxKXgNBBJoJplkPflfS5kDvA2E8BmgZ3G97nT56EoruklPiqnBKAxt unghMLcOgxKvagUU6FBv7JEIPKDu3gd8WRlhyYiq2YVFHw4WUjgSavV7pxgShD4RX1O/ m43tVrAgmevoySE9WIz7X9kB7VIgaDqrh0QKK6curKSmiLA3oWUuG54x56bDJUVUilGy e+84FzfcuSh0xgkfRkAoulAC27wKF+faw0aQbSZQlKnQT0riiSUNvCelhnqdoGO66xDQ nhie6aHsvxUEQerqajXBFVCQdRqskBdTbUm6WPawuSPb7jdcaGVj6nSHPnQnK93ufqAK S4Lw== 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; bh=vCYJBZ/egpNBu9rDMrBzPA+fl+z8HORH5O46LxZfdR0=; b=eiHq2JlWBrneHui/k/hCNzmSYUxC7oPOjam4exi/KTnH82C0s7/tRwU5/zq33UJf58 8ATMu5HJKsgp7FUCHwUBc6sOZLxoMrSirQYeLmrXEyahpwQUZPTsqS+N2GTq7lJ9lbOA 7GppkbwDnZ1SuM+BE6EbYc/FNi/FQe2kJkkECd3HptI2FqZd+bg+jP+rlKzk088QOVVX I+0kiLflU8b8uPCk3hJCIgV0dvxoK0aa/CUtTCDL1iuKalEk8sRO60qdwgnuVAD5slY7 vFpQy2oHUNYz7HZaKGS1iataKERU0ucn66wE6mR6eNvgPkptg2GShl1ObATasNhWCz/3 Yf8g== X-Gm-Message-State: AEkoousdKh6yDR0l50gnmB6zT/7GRkvAIsefrmf6ytLcMrbBP2XfpoIXg5AVYunPQsWuqeHwznJS32k8lYbFxQ== X-Received: by 10.176.1.167 with SMTP id 36mr5261834ual.140.1471638565170; Fri, 19 Aug 2016 13:29:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.50.7 with HTTP; Fri, 19 Aug 2016 13:29:23 -0700 (PDT) In-Reply-To: References: <013b01d1f8ee$31fa09b0$95ee1d10$@ndzh.com> <20160818073203.GA4338@elstar.local> <04b501d1f949$116c63e0$34452ba0$@ndzh.com> <20160818121405.GA5282@elstar.local> <051301d1f950$7739c670$65ad5350$@ndzh.com> <20160818130555.GA5366@elstar.local> <051701d1f952$c4ae0b30$4e0a2190$@ndzh.com> <6BCE198E4EAEFC4CAB45D75826EFB0761525CCD7@eusaamb101.ericsson.se> <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> <036801d1fa2a$466e9e00$d34bda00$@ndzh.com> <001501d1fa30$46d0ac70$d4720550$@ndzh.com> From: Alia Atlas Date: Fri, 19 Aug 2016 16:29:23 -0400 Message-ID: To: Andy Bierman Content-Type: multipart/alternative; boundary=001a1135de1cea3415053a728d55 Archived-At: X-Mailman-Approved-At: Fri, 19 Aug 2016 14:04:58 -0700 Cc: "i2rs@ietf.org" , Alissa Cooper , Juergen Schoenwaelder , i2rs-chairs@ietf.org, Kathleen Moriarty , IESG , Jeffrey Haas , Joel Halpern , Lou Berger , Susan Hares , 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Aug 2016 20:29:32 -0000 --001a1135de1cea3415053a728d55 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable First, to be very clear. This document has WG consensus - confirmed over multiple WGLCs - in the I2RS WG. This thread is to resolve the concerns expressed by the ADs about specific aspects of this document. Second, by having a requirement for indicating in the model - whether for the whole model or per leaf - that the data may be sent over an insecure transport, this encourages limiting the standard use of an insecure transport to exactly those models or data that requires it for a given use-case. I do see this as limited to certain types of use-cases and the ability to mount a model differently allows the flexibility of describing a particular model as acceptable for insecure transport rather than requiring a leaf-by-leaf indication. The use of insecure transport is to accommodate use-cases that were not in the scope initially considered for NetConf/RestConf. Regards, Alia On Fri, Aug 19, 2016 at 12:32 PM, Andy Bierman wrote: > > > On Fri, Aug 19, 2016 at 8:42 AM, Susan Hares wrote: > >> Andy: >> >> >> >> I have been thinking about your question for 30 minutes. Let me put >> down a few of my personal opinions: >> >> >> >> 1) Most (99%) of the ephemeral data models will not allow >> non-secure transport. >> >> 2) If any ephemeral data models have an insecure section, the >> review and consensus for a standards model should take longer. >> >> I hope we can streamline the normal Yang model review. [It would be nic= e >> to streamline features additions for NETCONF/RESTCONF as well]. >> >> >> > > I hope you are right that it will almost always be easy for a WG > to decide this issue for each leaf. > > We already have "security tagging" in NACM, and this has not caused delay= s. > This is the opposite decision -- Is this data so sensitive that the NACM > default > access control needs to block writes (nacm:default-deny-write) or block > all access > (nacm:default-deny-all)? > > These extensions are used in ietf-system.yang, not just in the NACM RFC. > They can be used anywhere and a NACM implementation MUST enforce > the extension semantics. > > If YANG Push had similar requirements (i.e, MUST NOT send data in the cle= ar > that is not tagged with the appropriate extension) and the review criteri= a > is clear, > then this approach should be OK. > > > Andy > > > 3) I prefer to have the non-secure sections of a data model moved to >> a separate date model, and the data model marked as insecure. >> >> [I do not know if we could use the library function to mark the data >> model in meta-language.] >> >> However, until we complete the mount schema work =E2=80=93 I do not know= if this >> is workable. >> >> >> >> Would it help if I changed version -08 to >> >> 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 o= r >> other >> >> Operational state that was specifically indicated to be >> non-confidential in the data model. >> >> / >> >> >> >> Sue >> >> >> >> >> >> *From:* i2rs [mailto:i2rs-bounces@ietf.org] *On Behalf Of *Susan Hares >> *Sent:* Friday, August 19, 2016 10:59 AM >> *To:* 'Andy Bierman'; 'Lou Berger' >> *Cc:* i2rs@ietf.org; 'Alissa Cooper'; 'Juergen Schoenwaelder'; >> 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) >> >> >> >> Andy: >> >> >> >> Thank you for your comments. Perhaps you can provide for the IESG the >> list of things that are needed to move a Yang module forward in the IETF= . >> >> >> >> Sue >> >> >> >> *From:* Andy Bierman [mailto:andy@yumaworks.com ] >> *Sent:* Friday, August 19, 2016 10:24 AM >> *To:* Lou Berger >> *Cc:* Susan Hares; Juergen Schoenwaelder; 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) >> >> >> >> Hi, >> >> >> >> I agree with Juergen. >> >> There are already too many details that need consensus to move >> >> a YANG module forward in the IETF. It takes too long already. >> >> >> >> 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? >> >> >> >> Standardized insecure access is a big change from what we have done >> >> for 30 years. There could be a good reason why we left this out of scop= e >> >> all this time. >> >> >> >> >> >> Andy >> >> >> >> >> >> On Fri, Aug 19, 2016 at 5:20 AM, Lou Berger wrote: >> >> >> Sue, >> >> My message said three things: >> >> 1) Juergen's comment resonates with me. >> >> 2) I think the current text is acceptable. >> >> 3) I see changing the SHOULD to a MUST as problematic. >> I understood one of the other messages on this thread proposing this >> change which is what triggered my message. If I misunderstood that >> message, feel free to interpret my message as supporting the current >> text in question. >> >> Note that I am only speaking for myself (including in my role as NETMOD >> co-chair) and not representing the consensus opinion of any WG. >> >> Lou >> On 8/19/2016 8:07 AM, Susan Hares wrote: >> > Lou: >> > >> > I am clear that Juergen does not want not want to place transport >> requirements within the data model for NETMOD. His opinion was consider= ed >> in the rough for the I2RS WG. If this requirement is a problem for >> NETCONF/NETMOD, the text currently says: >> > >> > REQ-SEC-09 states: >> > >> > The default mode of transport is secure so data models SHOULD clearl= y >> annotate what data nodes can be >> > passed over an insecure connection. >> > >> > However, if this means the NETCONF/NETMOD WG will not even entertain >> proposal for marking the insecure functions in yang text -- then the two= WG >> (I2RS/NETMOD) have a problem and should stop this standardization proces= s >> going forward. >> > >> > Sue >> > >> > >> > -----Original Message----- >> > From: Lou Berger [mailto:lberger@labn.net] >> > Sent: Friday, August 19, 2016 7:34 AM >> > To: Susan Hares; 'Juergen Schoenwaelder' >> > Cc: i2rs@ietf.org; 'Alissa Cooper'; i2rs-chairs@ietf.org; 'Kathleen >> Moriarty'; 'IESG'; jhaas@pfrc.org; '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) >> > >> > Sue, >> > >> > I don't see Juergen as arguing against model access via non-secure >> transport. I read his point as that the transport security requirements >> don't belong scattered within a data model. >> > >> > I have to say that from a model complexity (definition, process, >> review, implementation - take your pick) , language and NETMOD co-chair >> perspective, his comment resonates with me. >> > >> > I think this makes the key text: >> > >> > The default mode of transport is >> > secure so data models SHOULD clearly annotate what data nodes can b= e >> > passed over an insecure connection. >> > >> > >> > As this isn't a MUST, I personally think we can live with the text and >> we can debate the issue further in the context of specific solutions. I >> would strongly object to this being changed to a MUST, or if the documen= t >> is changed to make transport (security) requirements identified within d= ata >> models a requirement. >> > >> > Lou >> > >> > On 8/19/2016 6:49 AM, Susan Hares wrote: >> >> Juergen: >> >> >> >> You have laid out the two options: a) link the data-model to the >> non-secure transport, and b) do not link the data to the non-secure >> transport. I agree with you that past models did not link past SNMP MI= B >> data model to the transport. Existing NETCONF models do not link it to = the >> transport. As you have indicated, you disagreed in the I2RS WG and we >> found consensus was to include the non-secure transport. >> >> >> >> I2RS was created to build things as an interface to the routing >> environment. The operators clearly informed the I2RS group of this nee= d >> during the requirement setting phase prior to the time I was chair. The >> reason I continue to press for this capability is their input, and the >> existing use cases I listed previously in this mail: >> >> >> >> a) public information - BGP route views, >> >> b) specific well know up events - such as public-web site up >> >> c) specific network service events - interface to particular public >> LAN up. >> >> >> >> As you know, we do not have any I2RS data models that specify this >> feature at this time. I suspect after we get through this lengthy >> requirement phase, the operators may begin to specify new models that ha= ve >> this feature. >> >> >> >> Sue >> >> >> >> -----Original Message----- >> >> From: Juergen Schoenwaelder >> >> [mailto:j.schoenwaelder@jacobs-university.de] >> >> Sent: Friday, August 19, 2016 4:58 AM >> >> To: Susan Hares >> >> Cc: 'Alissa Cooper'; 'Joel Halpern'; i2rs@ietf.org; >> >> i2rs-chairs@ietf.org; 'Kathleen Moriarty'; 'IESG'; jhaas@pfrc.org; >> >> 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) >> >> >> >> I repeat my technical argument: While there may be deployments where >> non-secure transports may be reasonable to use, defining these situation= s >> statically as part of data model schemas does not follow established >> practices. The IETF has a long tradition of standardizing data models th= at >> can be used in a variety of operational contexts and I do not see reason= s >> why we should move away from that basic approach. >> >> >> >> /js >> >> >> >> On Thu, Aug 18, 2016 at 02:35:03PM -0400, Susan Hares wrote: >> >>> Alissa: >> >>> >> >>> Just a little input you may not know. My background is 15 years >> (1995-2010) developing a routing/switching platform (denoted as GateD) >> which was sold to over 200 companies. We developed XML and a binary XM= L >> based product that configured this product. It could do 100K configurat= ion >> lines and reboot in less than a second on most hardware. We also provid= e >> status messages in secure streams and non-secure streams. I sold earl= y >> version of this code to companies that Alia has worked for - so she has >> personal viewed the code. At the height of our work, our development t= eam >> ran to 50 people which I directed (First as VP of Engineering, and then = as >> CTO). It is due to this level of experience that Alia selected me for th= e >> co-chair. Russ White has understood Cisco's process, and has also >> directed software development teams for routing. >> >>> >> >>> In order to freshen my direct experience with I2RS on open source >> work, I am working on a publically available work in Quagga based on the >> confD product suggested by Cisco. >> >>> >> >>> In contrast, Juergen is a university professor who has worked on >> proto-types. He is not working on an implementation. I hope he will. >> >>> >> >>> I hope you will consider this background in my response to your >> comments below. >> >>> >> >>> Sue >> >>> >> >>> >> >>> -----Original Message----- >> >>> From: Alissa Cooper [mailto:alissa@cooperw.in] >> >>> Sent: Thursday, August 18, 2016 12:54 PM >> >>> To: Joel Halpern >> >>> Cc: Susan Hares; Juergen Schoenwaelder; i2rs@ietf.org; >> >>> i2rs-chairs@ietf.org; Kathleen Moriarty; IESG; jhaas@pfrc.org; >> >>> 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) >> >>> >> >>> Jumping in here because this is relevant to my DISCUSS, hope nobody >> minds (but if you do, I can go back to the other thread). >> >>> >> >>>>> On Aug 18, 2016, at 10:30 AM, Joel Halpern < >> joel.halpern@ericsson.com> wrote: >> >>>>> >> >>>>> Let me try a different take approach to this particular question. >> >>>>> >> >>>>> Let me start by putting aside the question of where things are >> marked, and come back to that afterwards. >> >>>>> >> >>>>> There are a number of cases that I2RS has been asked to cover of >> high rate telemetry data. This may be BGP update information, it may be >> frequent information about line card activity. There are other cases, s= ome >> of which have been documented. >> >>>>> >> >>>>> While not completely insensitive, the operators have made clear >> that they see protecting this data as unnecessary. While I would hope o= ver >> time to move to a domain where all of it is protect, that is not trivial= . >> As the I2RS Architecture points out, it is expected that what we describ= e >> as a single I2RS >communication between a client and agent is actually >> associated with multiple channels of communication. >> >>>>> >> >>>>> Now, if you want to say that the I2RS protocol requirements cannot >> allow for unprotected channels, I guess we have disconnect between the I= ESG >> and the WG. >> >>>>> >> >>>>> If we say that we can allow for unprotected channels, we then get >> to the question of which data can be sent over such channels. While >> architecturally I agree with Juergen that the model is a bad place to >> specify it, the obverse is also true. Not having some limits on what ca= n >> be sent unprotected >causes concern about insufficient protection. If I >> recall correctly, earlier security reviews called us to task for being t= oo >> broad in what we allowed. >> >>>>> >> >>>>> So, if the IESG wants us to just allow it anywhere, because the >> >>>>> model is an awkward place to define the limitation, I can live wit= h >> that. What I can't live with is being told both that the model is a bad >> place to define it and that there must be restrictions on what is sent >> unprotected, without any proposal on how we are to move forward. >> >>>> Thank you Joel, this explanation helps me a lot. I think there is a >> disconnect about how the restrictions are expressed. From reading the em= ail >> traffic about this document, it strikes me that trying to express the >> restrictions programmatically doesn=E2=80=99t make much sense in this ca= se. >> >>>> I agree with Juergen that it will be challenging to make a judgment >> a priori in order to bake a restriction into a data model, because data >> that is considered sensitive enough to warrant a secure transport in one >> deployment may not be considered sensitive in another deployment. >> >>>> So for any data elements where there is any question at all about >> >>>> whether they might be sensitive (i.e., any data elements that are >> not already routinely made public), I would expect data model authors to >> end up indicating that they may be sent over either secure or insecure >> transport, which renders the indication not useful. >> >>>> Perhaps it would make more sense then to just enumerate in the text >> the cases that motivate the inclusion of protocol support for insecure >> transport: >> >>>> >> >>>> 1. For conveyance of information that is already routinely made >> public. >> >>>> 2. For line card activity data where there is no likely upgrade pat= h >> to support secure transports in the foreseeable future. >> >>>> >> >>>> Then the normative requirements would be on clients and agents to >> use secure transports unless those clients and agents are deployed where >> either of the operational circumstances above necessitate otherwise. >> >>>> Alissa >> >>> Point 1: >> >>> I disagree with Juergen on the difficulty in specifying the sections >> of the yang modules. I have provided a suggested solution in: >> >>> https://tools.ietf.org/html/draft-hares-i2rs-protocol-strawm >> an-03#section-4.5.2. >> >>> >> >>> Given the mount schema functionality, we can mount ephemeral state >> module which augment non-ephemeral state modules which are "in-secure on= ly". >> >>> >> >>> Point 2: >> >>> I am willing to put an enumeration of the use cases in the protocol >> requirement, but I would like to understand the purpose for the >> enumeration. We are not doing a use case, but a requirements document. >> This information appears to be a "use case" rather than a technical >> description. What purpose are you looking for this enumeration to >> server. Are you looking for the enumeration in SEC-REQ-08? >> >>> >> >>> Point 3: Could you review -08.txt on this topic, especially the text >> below. Given your comments, I believe I should change the last line to = a >> MUST. >> >>> New/ The default mode of transport is >> >>> secure so data models MUST clearly annotate what data nodes can b= e >> >>> passed over an insecure connection. >> >>> / >> >>> >> >>> Sue >> >>> >> >>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> >>> As to the normative requirements (-08.txt) version: >> >>> >> >>> Section 3: >> >>> >> >>> I2RS allows the use of an insecure transport for portions of data >> >>> models that clearly indicate the use of an insecure transport. >> >>> Operators deploying I2RS must determine if they want to populate >> and >> >>> deploy the portions of the data model which use insecure >> transports. >> >>> >> >>> In Section 3.2 in version -08.txt >> >>> >> >>> SEC-REQ-08: The I2RS protocol MUST be able to transfer data over = a >> >>> secure transport and optionally MAY be able to transfer data over= a >> >>> non-secure transport. A secure transport MUST provide data >> >>> confidentiality, data integrity, and replay prevention. >> >>> >> >>> The default I2RS transport is a secure transport. >> >>> >> >>> 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. >> >>> >> >>> The configuration of ephemeral data in the I2RS Agent by the I2RS >> >>> client SHOULD be done over a secure transport. It is anticipated >> >>> that the passing of most I2RS ephemeral state operational status >> >>> SHOULD be done over a secure transport. As >> >>> [I-D.ietf-i2rs-ephemeral-state] notes, a data model MUST indicat= e >> >>> whether the transport exchanging the data between I2RS client and >> >>> I2RS agent is secure or insecure. >> >>> >> >>> The default mode of transport is >> >>> secure so data models SHOULD clearly annotate what data nodes can >> be >> >>> passed over an insecure connection. >> >>> >> >>>> Yours, >> >>>> Joel >> >>>> >> >>>> -----Original Message----- >> >>>> From: Susan Hares [mailto:shares@ndzh.com] >> >>>> Sent: Thursday, August 18, 2016 9:17 AM >> >>>> To: 'Juergen Schoenwaelder' >> >>>> Cc: i2rs@ietf.org; i2rs-chairs@ietf.org; 'Kathleen Moriarty' >> >>>> ; 'The IESG' ; >> >>>> jhaas@pfrc.org; >> >>>> 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 an= d >> >>>> COMMENT) >> >>>> >> >>>> Juergen and Kathleen: >> >>>> >> >>>> Let me proceed with two examples: BGP route views data model and th= e >> event for the web-service data. >> >>>> >> >>>> The content of these data models are designated as exposed to >> public. The routing system only populates the proposed BGP route views >> data model with the data destined for the BGP looking glass. The policy= on >> the routing system indicates what information gets transferred. The dat= a >> model is completely available to the public. The Yang Doctors are going= to >> review this by seeing the whole model is public and available via >> non-secure means. >> >>>> The security people are going to review this seeing that the whole >> model is public, and available via an unprotect means. The fact the dat= a >> model is all public should simplify the review. >> >>>> >> >>>> An event from the I2RS RIB that a web-service route is up is the >> second case. The I2RS RIB has an event based on policy that indicates a >> web-service route is up. The yang-1.1 doctors must review the content o= f >> the event text to see it does not break privacy or provide too much >> >>>> information The event mechanisms will need to work over secure >> transport >> >>>> and insecure transport. Most of the data will go over the secure >> transport event stream. However, a small amount of information may go ov= er >> the insecure transport stream. >> >>>> >> >>>> First, let me know if my use cases are understandable. Second, let >> me know if you disagree with this use cases. >> >>>> >> >>>> Fyi - IESG approved the architecture with the insecure stream. >> >>>> >> >>>> Sue >> >>>> >> >>>> -----Original Message----- >> >>>> From: Juergen Schoenwaelder >> >>>> [mailto:j.schoenwaelder@jacobs-university.de] >> >>>> Sent: Thursday, August 18, 2016 9:06 AM >> >>>> To: Susan Hares >> >>>> Cc: i2rs@ietf.org; i2rs-chairs@ietf.org; 'Kathleen Moriarty'; 'The >> >>>> IESG'; jhaas@pfrc.org; >> >>>> 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 an= d >> >>>> COMMENT) >> >>>> >> >>>> I just do not know on which basis a data model writer can decide >> whether a data object can be exposed in an unprotected way. How are YANG >> doctors going to review this? How are security directorate people going = to >> judge this? But as promised, I leave (still puzzled) now. >> >>>> >> >>>> /js >> >>>> >> >>>> On Thu, Aug 18, 2016 at 09:00:14AM -0400, Susan Hares wrote: >> >>>>> Juergen: >> >>>>> >> >>>>> Yes, we seem to disagree on the value of making it hardwired in th= e >> model. >> >>>>> For me, the value is a common understanding of deployment >> >>>>> distribution >> >>>> such >> >>>>> as the route-views. Since the operators argued strongly for this >> point, >> >>>> I >> >>>>> think the best idea is to get it working in code and then see if >> >>>>> the deployment matches the requests. >> >>>>> >> >>>>> Sue >> >>>>> >> >>>>> -----Original Message----- >> >>>>> From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Juergen >> >>>>> Schoenwaelder >> >>>>> Sent: Thursday, August 18, 2016 8:14 AM >> >>>>> To: Susan Hares >> >>>>> Cc: i2rs@ietf.org; i2rs-chairs@ietf.org; 'Kathleen Moriarty'; 'The >> >>>>> IESG'; jhaas@pfrc.org; >> >>>>> 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) >> >>>>> >> >>>>> Sue, >> >>>>> >> >>>>> I still do not see why the 'mode of exposure' of data benefits fro= m >> >>>>> being hard-wired in the data model. For me, it is a situational an= d >> >>>>> deployment specific question. But I shut up here since I aired thi= s >> >>>>> concern before (and we simply seem to disagree). >> >>>>> >> >>>>> /js >> >>>>> >> >>>>> On Thu, Aug 18, 2016 at 08:07:18AM -0400, Susan Hares wrote: >> >>>>>> Juergen: >> >>>>>> >> >>>>>> My example is the looking glass servers for the BGP route views >> >>>>>> project >> >>>>>> (http://www.routeviews.org/) or a route indicating the presence >> of a >> >>>>>> web-server that is public. For the BGP I2RS route, a yang model >> could >> >>>>>> replace the looking glass function, and provide events for these >> looking >> >>>>>> glass functions. For the web-server route, an event be sent >> when >> >>>> that >> >>>>>> one route is added. >> >>>>>> >> >>>>>> Sue >> >>>>>> >> >>>>>> >> >>>>>> -----Original Message----- >> >>>>>> From: Juergen Schoenwaelder >> >>>>>> [mailto:j.schoenwaelder@jacobs-university.de] >> >>>>>> Sent: Thursday, August 18, 2016 3:32 AM >> >>>>>> To: Susan Hares >> >>>>>> Cc: 'Kathleen Moriarty'; 'The IESG'; jhaas@pfrc.org; >> >>>>>> i2rs@ietf.org; i2rs-chairs@ietf.org; >> >>>>>> 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 Wed, Aug 17, 2016 at 09:16:48PM -0400, Susan Hares wrote: >> >>>>>>> ----------------------------------------------------------------= - >> >>>>>>> - >> >>>>>>> -- >> >>>>>>> -- >> >>>>>>> COMMENT: >> >>>>>>> ----------------------------------------------------------------= - >> >>>>>>> - >> >>>>>>> -- >> >>>>>>> -- >> >>>>>>> >> >>>>>>>> Section 3: >> >>>>>>>> Can you clarify the second to last sentence? Do you mean there >> >>>>>>>> are >> >>>>>> sections that indicate an insecure transport should be used? >> >>>>>>>> I2RS allows the use of an >> >>>>>>>> insecure transport for portions of data models that clearly >> >>>>>>>> indicate insecure transport. >> >>>>>>>> Perhaps: >> >>>>>>>> I2RS allows the use of an >> >>>>>>>> insecure transport for portions of data models that clearly >> >>>>>>>> indicate the use of an insecure transport. >> >>>>>> I still wonder how a data model writer can reasonably decide >> >>>>>> whether a piece of information can be shipped safely over an >> >>>>>> insecure transport since this decision often depends on the >> >>>>>> specifics of a deployment >> >>>>> situation. >> >>>>>> /js >> >>>>>> >> >>>>>> PS: I hope we do not end up with defining data multiple times (on= ce >> >>>>>> for insecure transport and once for secured transports). >> >>>>>> >> >>>>>> -- >> >>>>>> Juergen Schoenwaelder Jacobs University Bremen gGmbH >> >>>>>> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | >> Germany >> >>>>>> Fax: +49 421 200 3103 >> >>>>>> >> >>>>>> _______________________________________________ >> >>>>>> i2rs mailing list >> >>>>>> i2rs@ietf.org >> >>>>>> https://www.ietf.org/mailman/listinfo/i2rs >> >>>>> -- >> >>>>> Juergen Schoenwaelder Jacobs University Bremen gGmbH >> >>>>> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | >> Germany >> >>>>> Fax: +49 421 200 3103 >> >>>>> >> >>>>> _______________________________________________ >> >>>>> i2rs mailing list >> >>>>> i2rs@ietf.org >> >>>>> https://www.ietf.org/mailman/listinfo/i2rs >> >>>>> >> >>>> -- >> >>>> Juergen Schoenwaelder Jacobs University Bremen gGmbH >> >>>> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | >> Germany >> >>>> Fax: +49 421 200 3103 >> >>>> >> > >> > >> > >> >> >> _______________________________________________ >> i2rs mailing list >> i2rs@ietf.org >> https://www.ietf.org/mailman/listinfo/i2rs >> >> >> > > --001a1135de1cea3415053a728d55 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
First, to be very clear.=C2=A0 This document has WG consen= sus - confirmed over multiple WGLCs - in the I2RS WG.
This thread is to= resolve the concerns expressed by the ADs about specific aspects of this d= ocument.

Second, by having a requirement for in= dicating in the model - whether for the whole model or per leaf - that
the data may be sent over an insecure transport, this encourages limi= ting the standard use of an insecure
transport to exactly those m= odels or data that requires it for a given use-case.

I do see this as limited to certain types of use-cases and t= he ability to mount a model differently allows the
flexibility of= describing a particular model as acceptable for insecure transport rather = than requiring a leaf-by-leaf
indication.

The use of insecure transport is to accommodate use-cases that were not i= n the scope initially considered
for NetConf/RestConf. =C2=A0

Regards,
Alia

On Fri, Aug 19, 2016 at 12:32 PM, A= ndy Bierman <andy@yumaworks.com> wrote:


On Fri, Aug 19, 2016 at 8:42 AM, Susan = Hares <shares@ndzh.com> wrote:

Andy:

=C2=A0

I have been thinking about = your question for 30 minutes.=C2=A0=C2=A0 Let me put down a few of my perso= nal opinions:

=C2=A0

1)=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 Most (99%) of the ephemeral data models will not allow non-secure t= ransport.

2)=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 =C2= =A0If any ephemeral data models have an insecure section, the review and co= nsensus for a standards model should take longer.

=

I hope we can streamline the normal Yang mode= l review.=C2=A0 [It would be nice to streamline features additions for NETC= ONF/RESTCONF as well]. =C2=A0

=C2=A0


I hope you are right that it will almost alwa= ys be easy for a WG
to decide this issue for each leaf.

We already have "security tagging" in NACM, and t= his has not caused delays.
This is the opposite decision -- Is th= is data so sensitive that the NACM default
access control needs t= o block writes (nacm:default-deny-write) or block all access
(nac= m:default-deny-all)?

These extensions are used in = ietf-system.yang, not just in the NACM RFC.
They can be used anyw= here and a NACM implementation MUST enforce
the extension semanti= cs.

If YANG Push had similar requirements (i.e, MU= ST NOT send data in the clear
that is not tagged with the appropr= iate extension) and the review criteria is clear,
then this appro= ach should be OK.
=

Andy


<= span>3)=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 I= prefer to have the non-secure sections of a data model moved to a separate= date model, and the data model marked as insecure. =C2=A0

[I do not know if we could use the li= brary function to mark the data model in meta-language.]

However, until we complete the mount sc= hema work =E2=80=93 I do not know if this is workable.

=C2=A0=

Would it help = if I changed version -08 to

Old/

=C2=A0=C2=A0 A non-secure transport can be used for publishing t= elemetry data or

=C2= =A0=C2=A0 other operational state that was specifically indicated to non-

=C2=A0=C2=A0 confidenti= al in the data model in the Yang syntax. = /

New:/

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 A non-secure transport = can be used for publishing telemetry data or other

=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0Operational state that was specifically indicated to be non-confident= ial in the data model.

=C2=A0=C2=A0=C2=A0 /

=C2=A0

Sue

=C2=A0

=C2=A0<= /u>

From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Susan Hares=
Sent: Friday, August 19, 2016 10:59 AM
To: 'Andy B= ierman'; 'Lou Berger'
Cc: i2rs@ietf.org; 'Alissa Cooper'; 'Ju= ergen Schoenwaelder'; i2rs-chairs@ietf.org; 'Kathleen Moriarty'; 'IESG&#= 39;; 'Jeffrey Haas'; 'Joel Halpern'; draf= t-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)

=C2=A0

Andy:

=C2=A0=

Thank you for your co= mments.=C2=A0=C2=A0 Perhaps you can provide for the IESG the list of things= that are needed to move a Yang module forward in the IETF.=C2=A0=C2=A0 =

= =C2=A0

Sue

=C2=A0

From: Andy Bierman [mailto:andy@yumaworks.com]
Sent: Fr= iday, August 19, 2016 10:24 AM
To: Lou Berger
Cc: Susan= Hares; Juergen Schoenwaelder; i2rs@ietf.org; Alissa Cooper; i2rs-chairs@ietf.org; Kathleen Moriarty; IESG; = Jeffrey Haas; Joel Halpern; draft-ietf-i2rs-protocol-secu= rity-requirements@ietf.org
Subject: Re: [i2rs] Kathleen = Moriarty's Discuss on draft-ietf-i2rs-protocol-security-requiremen= ts-07: (with DISCUSS and COMMENT)

=C2=A0

Hi,=

=C2=A0

I agree with Juergen.

There are already too many details that need consensus to mo= ve

a YANG module forward= in the IETF.=C2=A0 It takes too long already.

=

=C2=A0

We could have been tagging MIB objects all along, but we don't.

Imagine if there was a de= bate for every single OBJECT-TYPE macro

"is this leaf OK for noAuth/noPriv?"

=C2=A0

<= p class=3D"MsoNormal">Are there even clear SEC-DIR guidelines on how one wo= uld decide this

debate i= n a WG? Does SEC-DIR really want to be flooded with review

requests so they become a bottleneck in = YANG RFC publication process?

=C2=A0

Standardize= d insecure access is a big change from what we have done

<= /div>

for 30 years.=C2=A0 There could be a good = reason why we left this out of scope

all this time.

=C2=A0

=C2= =A0

Andy

=C2=A0

=C2=A0

On Fr= i, Aug 19, 2016 at 5:20 AM, Lou Berger <lberger@labn.net> wrote:


Sue,

My message said three things:

1) = Juergen's comment resonates with me.

2) I think the current text= is acceptable.

3) I see changing the SHOULD to a MUST as problemati= c.
I understood one of the other messages on this thread proposing this<= br>change which is what triggered my message.=C2=A0 =C2=A0If I misunderstoo= d that
message, feel free to interpret my message as supporting the curr= ent
text in question.

Note that I am only speaking for myself (in= cluding in my role as NETMOD
co-chair) and not representing the consensu= s opinion of any WG.

Lou
On 8/19/2016 8:07 AM, Susan Hares wrote:=
> Lou:
>
> I am clear that Juergen does not want not wan= t to place transport requirements within the data model for NETMOD.=C2=A0 H= is opinion was considered in the rough for the I2RS WG. If this requirement= is a problem for NETCONF/NETMOD,=C2=A0 the text currently says:
>> REQ-SEC-09 states:
>
>=C2=A0 =C2=A0The default mode of tr= ansport is secure so data models SHOULD clearly annotate what data nodes ca= n be
>=C2=A0 =C2=A0 passed over an insecure connection.
>
&g= t; However, if this means the NETCONF/NETMOD WG will not even entertain pro= posal for marking the insecure functions in yang text -- then the two WG (I= 2RS/NETMOD) have a problem and should stop this standardization process goi= ng forward.
>
> Sue
>
>
> -----Original Messa= ge-----
> From: Lou Berger [mailto:lberger@labn.net]
> Sent: Friday, August 19, = 2016 7:34 AM
> To: Susan Hares; 'Juergen Schoenwaelder'
&g= t; Cc: i2rs@ietf.org= ; 'Alissa Cooper'; i2rs-chairs@ietf.org; 'Kathleen Moriarty'; 'IES= G'; jhaas@pfrc.org<= /a>; 'Joel Halpern'; draft-ietf-i2rs-protocol-sec= urity-requirements@ietf.org
> Subject: Re: [i2rs] Kathleen M= oriarty's Discuss on draft-ietf-i2rs-protocol-security-requirement= s-07: (with DISCUSS and COMMENT)
>
> Sue,
>
>=C2=A0= =C2=A0 =C2=A0I don't see Juergen as arguing against model access via n= on-secure transport. I read his point as that the transport security requir= ements don't belong scattered within a data model.
>
> I ha= ve to say that from a model complexity (definition, process, review, implem= entation - take your pick) , language and NETMOD co-chair perspective, his = comment resonates with me.
>
> I think this makes the key text:=
>
>=C2=A0 =C2=A0 The default mode of transport is
>=C2= =A0 =C2=A0 secure so data models SHOULD clearly annotate what data nodes ca= n be
>=C2=A0 =C2=A0 passed over an insecure connection.
>
&g= t;
> As this isn't a MUST, I personally think we can live with th= e text and we can debate the issue further in the context of specific solut= ions.=C2=A0 I would strongly object to this being changed to a MUST, or if = the document is changed to make transport (security) requirements identifie= d within data models a requirement.
>
> Lou
>
> On = 8/19/2016 6:49 AM, Susan Hares wrote:
>> Juergen:
>>
&= gt;> You have laid out the two options:=C2=A0 =C2=A0a) link the data-mod= el to the non-secure transport, and b) do not link the data to the non-secu= re transport.=C2=A0 =C2=A0I agree with you that past models did not link pa= st SNMP MIB data model to the transport.=C2=A0 Existing NETCONF models do n= ot link it to the transport.=C2=A0 =C2=A0As you have indicated, you disagre= ed in the I2RS WG and we found consensus was to include the non-secure tran= sport.
>>
>> I2RS was created to build things as an inter= face to the routing environment.=C2=A0 =C2=A0The operators clearly informed= the I2RS group of this need during the requirement setting phase prior to = the time I was chair.=C2=A0 The reason I continue to press for this capabil= ity is their input, and the existing use cases I listed previously in this = mail:
>>
>> a) public information - BGP route views,
&= gt;> b) specific well know up events - such as public-web site up
>= ;> c) specific network service events - interface to particular public L= AN up.
>>
>> As you know, we do not have any I2RS data mo= dels that specify this feature at this time.=C2=A0 =C2=A0I suspect after we= get through this lengthy requirement phase, the operators may begin to spe= cify new models that have this feature.
>>
>> Sue
>= >
>> -----Original Message-----
>> From: Juergen Schoe= nwaelder
>> [mailto:j.schoenwaelder@jacobs-university.de]<= br>>> Sent: Friday, August 19, 2016 4:58 AM
>> To: Susan Har= es
>> Cc: 'Alissa Cooper'; 'Joel Halpern'; i2rs@ietf.org;
>> = i2rs-chairs@ietf.= org; 'Kathleen Moriarty'; 'IESG'; jhaas@pfrc.org;
>> draft-ietf-i2rs-protocol-security-requirements@ietf.org
&= gt;> Subject: Re: [i2rs] Kathleen Moriarty's Discuss on
>> = draft-ietf-i2rs-protocol-security-requirements-07: (with DISCUSS and>> COMMENT)
>>
>> I repeat my technical argument:= While there may be deployments where non-secure transports may be reasonab= le to use, defining these situations statically as part of data model schem= as does not follow established practices. The IETF has a long tradition of = standardizing data models that can be used in a variety of operational cont= exts and I do not see reasons why we should move away from that basic appro= ach.
>>
>> /js
>>
>> On Thu, Aug 18, 20= 16 at 02:35:03PM -0400, Susan Hares wrote:
>>> Alissa:
>&= gt;>
>>> Just a little input you may not know.=C2=A0 My back= ground is 15 years (1995-2010)=C2=A0 developing a routing/switching platfor= m (denoted as GateD) which was sold to over 200 companies.=C2=A0 =C2=A0We d= eveloped XML and a binary XML based product that configured this product.= =C2=A0 It could do 100K configuration lines and reboot in less than a secon= d on most hardware.=C2=A0 We also provide status messages in secure streams= and non-secure streams.=C2=A0 =C2=A0 I sold early version of this code to = companies that Alia has worked for=C2=A0 - so she has personal viewed the c= ode.=C2=A0 =C2=A0At the height of our work, our development team ran to 50 = people which I directed (First as VP of Engineering, and then as CTO). It i= s due to this level of experience that Alia selected me for the co-chair.= =C2=A0 =C2=A0Russ White has understood Cisco's process, and has also di= rected software development teams for routing.
>>>
>>&= gt; In order to freshen my direct experience with I2RS on open source work,= I am working on a publically available work in Quagga based on the confD p= roduct suggested by Cisco.
>>>
>>> In contrast, Jue= rgen is a university professor who has worked on proto-types.=C2=A0 =C2=A0H= e is not working on an implementation.=C2=A0 =C2=A0I hope he will.
>&= gt;>
>>> I hope you will consider this background in my resp= onse to your comments below.
>>>
>>> Sue
>>= ;>
>>>
>>> -----Original Message-----
>>= ;> From: Alissa Cooper [mailto:alissa@cooperw.in]
>>> Sent: Thursday, August= 18, 2016 12:54 PM
>>> To: Joel Halpern
>>> Cc: Sus= an Hares; Juergen Schoenwaelder; i2rs@ietf.org;
>>> i2rs-chairs@ietf.org; Kathleen Moriarty; IES= G; jhaas@pfrc.org;<= br>>>> draft-ietf-i2rs-protocol-security-re= quirements@ietf.org
>>> Subject: Re: [i2rs] Kathleen Moriar= ty's Discuss on
>>> draft-ietf-i2rs-protocol-security-= requirements-07: (with DISCUSS and
>>> COMMENT)
>>>=
>>> Jumping in here because this is relevant to my DISCUSS, ho= pe nobody minds (but if you do, I can go back to the other thread).
>= >>
>>>>> On Aug 18, 2016, at 10:30 AM, Joel Halpern= <joel.ha= lpern@ericsson.com> wrote:
>>>>>
>>>&g= t;> Let me try a different take approach to this particular question.>>>>>
>>>>> Let me start by putting aside= the question of where things are marked, and come back to that afterwards.=
>>>>>
>>>>> There are a number of case= s that I2RS has been asked to cover of high rate telemetry data.=C2=A0 This= may be BGP update information, it may be frequent information about line c= ard activity.=C2=A0 There are other cases, some of which have been document= ed.
>>>>>
>>>>> While not completely in= sensitive, the operators have made clear that they see protecting this data= as unnecessary.=C2=A0 While I would hope over time to move to a domain whe= re all of it is protect, that is not trivial.=C2=A0 As the I2RS Architectur= e points out, it is expected that what we describe as a single I2RS >com= munication between a client and agent is actually associated with multiple = channels of communication.
>>>>>
>>>>> = Now, if you want to say that the I2RS protocol requirements cannot allow fo= r unprotected channels, I guess we have disconnect between the IESG and the= WG.
>>>>>
>>>>> If we say that we can = allow for unprotected channels, we then get to the question of which data c= an be sent over such channels.=C2=A0 While architecturally I agree with Jue= rgen that the model is a bad place to specify it, the obverse is also true.= =C2=A0 Not having some limits on what can be sent unprotected >causes co= ncern about insufficient protection.=C2=A0 If I recall correctly, earlier s= ecurity reviews called us to task for being too broad in what we allowed.>>>>>
>>>>> So, if the IESG wants us to = just allow it anywhere, because the
>>>>> model is an awk= ward place to define the limitation, I can live with that.=C2=A0 What I can= 't live with is being told both that the model is a bad place to define= it and that there must be restrictions on what is sent unprotected, withou= t any proposal on how we are to move forward.
>>>> Thank you= Joel, this explanation helps me a lot. I think there is a disconnect about= how the restrictions are expressed. From reading the email traffic about t= his document, it strikes me that trying to express the restrictions program= matically doesn=E2=80=99t make much sense in this case.
>>>>= I agree with Juergen that it will be challenging to make a judgment a prio= ri in order to bake a restriction into a data model, because data that is c= onsidered sensitive enough to warrant a secure transport in one deployment = may not be considered sensitive in another deployment.
>>>> = So for any data elements where there is any question at all about
>&g= t;>> whether they might be sensitive (i.e., any data elements that ar= e not already routinely made public), I would expect data model authors to = end up indicating that they may be sent over either secure or insecure tran= sport, which renders the indication not useful.
>>>> Perhaps= it would make more sense then to just enumerate in the text the cases that= motivate the inclusion of protocol support for insecure transport:
>= >>>
>>>> 1. For conveyance of information that is a= lready routinely made public.
>>>> 2. For line card activity= data where there is no likely upgrade path to support secure transports in= the foreseeable future.
>>>>
>>>> Then the n= ormative requirements would be on clients and agents to use secure transpor= ts unless those clients and agents are deployed where either of the operati= onal circumstances above necessitate otherwise.
>>>> Alissa<= br>>>> Point 1:
>>> I disagree with Juergen on the dif= ficulty in specifying the sections of the yang modules.=C2=A0 I have provid= ed a suggested solution in:
>>> https://tools.ietf.org/html/draft-hares-i2rs-protocol-strawma= n-03#section-4.5.2.
>>>
>>> Given the mount sch= ema functionality, we can mount ephemeral state module which augment non-ep= hemeral state modules which are "in-secure only".
>>>=
>>> Point 2:
>>> I am willing to put an enumeratio= n of the use cases in the protocol requirement, but I would like to underst= and the purpose for the enumeration.=C2=A0 =C2=A0We are not doing a use cas= e, but a requirements document.=C2=A0 This information appears to be a &quo= t;use case" rather than a technical description.=C2=A0 =C2=A0What purp= ose are you looking for this enumeration to server.=C2=A0 Are you looking f= or the enumeration in SEC-REQ-08?
>>>
>>> Point 3: = Could you review -08.txt on this topic, especially the text below.=C2=A0 Gi= ven your comments, I believe I should change the last line to a MUST.
&g= t;>> New/=C2=A0 =C2=A0The default mode of transport is
>>>= ;=C2=A0 =C2=A0 secure so data models MUST clearly annotate what data nodes = can be
>>>=C2=A0 =C2=A0 passed over an insecure connection.
= >>> /
>>>
>>> Sue
>>>
>&= gt;> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>&g= t;> As to the normative requirements (-08.txt) version:
>>><= br>>>> Section 3:
>>>
>>>=C2=A0 =C2=A0 I2R= S allows the use of an insecure transport for portions of data
>>&= gt;=C2=A0 =C2=A0 models that clearly indicate the use of an insecure transp= ort.
>>>=C2=A0 =C2=A0 Operators deploying I2RS must determine i= f they want to populate and
>>>=C2=A0 =C2=A0 deploy the portion= s of the data model which use insecure transports.
>>>
>&= gt;> In Section 3.2 in version -08.txt
>>>
>>>= =C2=A0 =C2=A0 SEC-REQ-08: The I2RS protocol MUST be able to transfer data o= ver a
>>>=C2=A0 =C2=A0 secure transport and optionally MAY be a= ble to transfer data over a
>>>=C2=A0 =C2=A0 non-secure transpo= rt.=C2=A0 A secure transport MUST provide data
>>>=C2=A0 =C2=A0= confidentiality, data integrity, and replay prevention.
>>>>>>=C2=A0 =C2=A0 The default I2RS transport is a secure transport= .
>>>
>>>=C2=A0 =C2=A0 A non-secure transport can b= e used for publishing telemetry data or
>>>=C2=A0 =C2=A0 other = operational state that was specifically indicated to non-
>>>= =C2=A0 =C2=A0 confidential in the data model in the Yang syntax.
>>= ;>
>>>=C2=A0 =C2=A0 The configuration of ephemeral data in t= he I2RS Agent by the I2RS
>>>=C2=A0 =C2=A0 client SHOULD be don= e over a secure transport.=C2=A0 It is anticipated
>>>=C2=A0 = =C2=A0 that the passing of most I2RS ephemeral state operational status
= >>>=C2=A0 =C2=A0 SHOULD be done over a secure transport.=C2=A0 As<= br>>>>=C2=A0 =C2=A0 [I-D.ietf-i2rs-ephemeral-state] notes,=C2= =A0 a data model MUST indicate
>>>=C2=A0 =C2=A0 whether the tra= nsport exchanging the data between I2RS client and
>>>=C2=A0 = =C2=A0 I2RS agent is secure or insecure.
>>>
>>>=C2= =A0 =C2=A0 The default mode of transport is
>>>=C2=A0 =C2=A0 se= cure so data models SHOULD clearly annotate what data nodes can be
>&= gt;>=C2=A0 =C2=A0 passed over an insecure connection.
>>>>>>> Yours,
>>>> Joel
>>>>
&g= t;>>> -----Original Message-----
>>>> From: Susan H= ares [mailto:shares@nd= zh.com]
>>>> Sent: Thursday, August 18, 2016 9:17 AM
= >>>> To: 'Juergen Schoenwaelder' <j.schoenwaelder@jac= obs-university.de>
>>>> Cc: i2rs@ietf.org; i2rs-chairs@ietf.org; 'Kathleen Mo= riarty'
>>>> <Kathleen.Moriarty.ietf@gmail.com>= ;; 'The IESG' <iesg@ietf.org>;
>>>> jhaas@pfrc.org;
>>>> draft-ietf-i2rs-protocol-security-requirements@ietf.org
&g= t;>>> Subject: RE: [i2rs] Kathleen Moriarty's Discuss on
&g= t;>>> draft-ietf-i2rs-protocol-security-requirements-07: (wit= h DISCUSS and
>>>> COMMENT)
>>>>
>>&= gt;> Juergen and Kathleen:
>>>>
>>>> Let m= e proceed with two examples: BGP route views data model and the event for t= he web-service data.
>>>>
>>>> The content of= these data models are designated as exposed to public.=C2=A0 The routing s= ystem only populates the proposed BGP route views data model with the data = destined for the BGP looking glass.=C2=A0 The policy on the routing system = indicates what information gets transferred.=C2=A0 The data model is comple= tely available to the public.=C2=A0 The Yang Doctors are going to review th= is by seeing the whole model is public and available via non-secure means.<= br>>>>> The security people are going to review this seeing tha= t the whole model is public, and available via an unprotect means.=C2=A0 Th= e fact the data model is all public should simplify the review.
>>= >>
>>>> An event from the I2RS RIB that a web-service = route is up is the second case.=C2=A0 The I2RS RIB has an event based on po= licy that indicates a web-service route is up.=C2=A0 The yang-1.1 doctors m= ust review the content of the event text to see it does not break privacy o= r provide too much
>>>> information=C2=A0 =C2=A0The event me= chanisms will need to work over secure transport
>>>> and in= secure transport.=C2=A0 Most of the data will go over the secure transport = event stream. However, a small amount of information may go over the insecu= re transport stream.
>>>>
>>>> First, let me = know if my use cases are understandable.=C2=A0 Second, let me know if you d= isagree with this use cases.
>>>>
>>>> Fyi -= =C2=A0 IESG approved the architecture with the insecure stream.
>>= >>
>>>> Sue
>>>>
>>>> --= ---Original Message-----
>>>> From: Juergen Schoenwaelder>>>> [mailto:j.schoenwaelder@jacobs-university.de]
= >>>> Sent: Thursday, August 18, 2016 9:06 AM
>>>>= ; To: Susan Hares
>>>> Cc: i2rs@ietf.org; i2rs-chairs@ietf.org; 'Kathleen Moriarty'; = 'The
>>>> IESG'; jhaas@pfrc.org;
>>>> = draft-ietf-i2rs-protocol-security-requirements@ietf.org
>>= ;>> Subject: Re: [i2rs] Kathleen Moriarty's Discuss on
>>= ;>> draft-ietf-i2rs-protocol-security-requirements-07: (with DIS= CUSS and
>>>> COMMENT)
>>>>
>>>&g= t; I just do not know on which basis a data model writer can decide whether= a data object can be exposed in an unprotected way. How are YANG doctors g= oing to review this? How are security directorate people going to judge thi= s? But as promised, I leave (still puzzled) now.
>>>>
>= ;>>> /js
>>>>
>>>> On Thu, Aug 18, 2= 016 at 09:00:14AM -0400, Susan Hares wrote:
>>>>> Juergen= :
>>>>>
>>>>> Yes, we seem to disagree = on the value of making it hardwired in the model.
>>>>> F= or me, the value is a common understanding of deployment
>>>>= ;> distribution
>>>> such
>>>>> as the = route-views.=C2=A0 =C2=A0Since the operators argued strongly for this point= ,
>>>> I
>>>>> think the best idea is to g= et it working in code and then see if
>>>>> the deploymen= t matches the requests.
>>>>>
>>>>> Sue=
>>>>>
>>>>> -----Original Message-----=
>>>>> From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Juergen=
>>>>> Schoenwaelder
>>>>> Sent: Thursd= ay, August 18, 2016 8:14 AM
>>>>> To: Susan Hares
>= >>>> Cc: i2r= s@ietf.org; i= 2rs-chairs@ietf.org; 'Kathleen Moriarty'; 'The
>>&= gt;>> IESG'; = jhaas@pfrc.org;
>>>>> draft-ietf-i2= rs-protocol-security-requirements@ietf.org
>>>>>= Subject: Re: [i2rs] Kathleen Moriarty's Discuss on
>>>>= > draft-ietf-i2rs-protocol-security-requirements-07: (with DISCUSS<= br>>>>>> and
>>>>> COMMENT)
>>>= ;>>
>>>>> Sue,
>>>>>
>>&= gt;>> I still do not see why the 'mode of exposure' of data b= enefits from
>>>>> being hard-wired in the data model. Fo= r me, it is a situational and
>>>>> deployment specific q= uestion. But I shut up here since I aired this
>>>>> conc= ern before (and we simply seem to disagree).
>>>>>
>= ;>>>> /js
>>>>>
>>>>> On Th= u, Aug 18, 2016 at 08:07:18AM -0400, Susan Hares wrote:
>>>>= >> Juergen:
>>>>>>
>>>>>> M= y example is the looking glass servers for the BGP route views
>>&= gt;>>> project
>>>>>> (http://www.routeviews.org/) or a rou= te indicating the presence of a
>>>>>> web-server that= is public.=C2=A0 =C2=A0For the BGP I2RS route, a yang model could
>&= gt;>>>> replace the looking glass function, and provide events = for these looking
>>>>>> glass functions.=C2=A0 =C2=A0= For the web-server route,=C2=A0 an event be sent when
>>>> = that
>>>>>> one route is added.
>>>>>= ;>
>>>>>> Sue
>>>>>>
>&g= t;>>>>
>>>>>> -----Original Message----->>>>>> From: Juergen Schoenwaelder
>>>>&= gt;> [mailto:j.schoenwaelder@jacobs-university.de]
>>&g= t;>>> Sent: Thursday, August 18, 2016 3:32 AM
>>>>&= gt;> To: Susan Hares
>>>>>> Cc: 'Kathleen Moria= rty'; 'The IESG'; jhaas@pfrc.org;
>>>>>> i2rs@ietf.org; i2rs-chairs@ietf.org;
>>>&= gt;>> draft-ietf-i2rs-protocol-security-requir= ements@ietf.org
>>>>>> Subject: Re: [i2rs] Kathlee= n Moriarty's Discuss on
>>>>>> draft-ietf-i2rs-pro= tocol-security-requirements-07: (with DISCUSS
>>>>>&= gt; and
>>>>>> COMMENT)
>>>>>>>>>>>> On Wed, Aug 17, 2016 at 09:16:48PM -0400, Susan H= ares wrote:
>>>>>>> ------------------------------<= wbr>-----------------------------------
>>>>>>>= ; -
>>>>>>> --
>>>>>>> -->>>>>>> COMMENT:
>>>>>>> ---= -------------------------------------------------------------->>>>>>> -
>>>>>>> --
>&= gt;>>>>> --
>>>>>>>
>>>&= gt;>>>> Section 3:
>>>>>>>> Can you = clarify the second to last sentence?=C2=A0 Do you mean there
>>>= ;>>>>> are
>>>>>> sections that indicat= e an insecure transport should be used?
>>>>>>>>= =C2=A0 I2RS allows the use of an
>>>>>>>> insecu= re transport for portions of data models that clearly
>>>>&g= t;>>> indicate=C2=A0 insecure transport.
>>>>>&g= t;>> Perhaps:
>>>>>>>> I2RS allows the use= of an
>>>>>>>> insecure transport for portions = of data models that clearly
>>>>>>>> indicate th= e use of an=C2=A0 insecure transport.
>>>>>> I still w= onder how a data model writer can reasonably decide
>>>>>= > whether a piece of information can be shipped safely over an
>&g= t;>>>> insecure transport since this decision often depends on = the
>>>>>> specifics of a deployment
>>>&g= t;> situation.
>>>>>> /js
>>>>>&g= t;
>>>>>> PS: I hope we do not end up with defining da= ta multiple times (once
>>>>>>=C2=A0 =C2=A0 for insecu= re transport and once for secured transports).
>>>>>><= br>>>>>>> --
>>>>>> Juergen Schoenwa= elder=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Jacobs University Bremen gGmb= H
>>>>>> Phone: +49 421 200 3587=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0Campus Ring 1 | 28759 Bremen | Germany
>>&= gt;>>> Fax:=C2=A0 =C2=A0+49 421 200 3103=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0<http://www.jacobs-university.de/>
>>>&g= t;>>
>>>>>> _______________________________= ________________
>>>>>> i2rs mailing list
>>&= gt;>>> i2rs@iet= f.org
>>>>>> https://www.ietf.org/mailman/listi= nfo/i2rs
>>>>> --
>>>>> Juergen Sch= oenwaelder=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Jacobs University Bremen= gGmbH
>>>>> Phone: +49 421 200 3587=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0Campus Ring 1 | 28759 Bremen | Germany
>&g= t;>>> Fax:=C2=A0 =C2=A0+49 421 200 3103=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0<http://www.jacobs-university.de/>
>>>&g= t;>
>>>>> _______________________________________= ________
>>>>> i2rs mailing list
>>>>> = i2rs@ietf.org
>= ;>>>> https://www.ietf.org/mailman/listinfo/i2rs
>= >>>>
>>>> --
>>>> Juergen Schoenw= aelder=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Jacobs University Bremen gGm= bH
>>>> Phone: +49 421 200 3587=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0Campus Ring 1 | 28759 Bremen | Germany
>>>>= Fax:=C2=A0 =C2=A0+49 421 200 3103=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0<ht= tp://www.jacobs-university.de/>
>>>>
>
= >
>


______________________________________________= _
i2rs mailing list
i2rs@ietf.org
https://www.ietf.org/mailman/listinfo/i2rs=

=C2=A0

<= /div>


--001a1135de1cea3415053a728d55-- From nobody Fri Aug 19 14:19:46 2016 Return-Path: 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 8E98812D091; Fri, 19 Aug 2016 14:18:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.738 X-Spam-Level: * X-Spam-Status: No, score=1.738 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, RDNS_NONE=0.793] autolearn=no 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 00zpBOUVwIwS; Fri, 19 Aug 2016 14:18:49 -0700 (PDT) Received: from hickoryhill-consulting.com (unknown [50.245.122.97]) (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 CF9E712B049; Fri, 19 Aug 2016 14:18:48 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=184.157.82.170; From: "Susan Hares" To: "'William Atwood'" , "'Andy Bierman'" References: <013b01d1f8ee$31fa09b0$95ee1d10$@ndzh.com> <20160818073203.GA4338@elstar.local> <04b501d1f949$116c63e0$34452ba0$@ndzh.com> <20160818121405.GA5282@elstar.local> <051301d1f950$7739c670$65ad5350$@ndzh.com> <20160818130555.GA5366@elstar.local> <051701d1f952$c4ae0b30$4e0a2190$@ndzh.com> <6BCE198E4EAEFC4CAB45D75826EFB0761525CCD7@eusaamb101.ericsson.se> <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> <036801d1fa2a$466e9e00$d34bda00$@ndzh.com> <001501d1fa30$46d0ac70$d4720550$@ndzh.com> <00e701d1fa3a$8cf41a70$a6dc4f50$@ndzh.com> In-Reply-To: Date: Fri, 19 Aug 2016 17:16:47 -0400 Message-ID: <033901d1fa5e$ff83e9c0$fe8bbd40$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJ/RF5y8kBC7R3sO+auWKe566R2lwEcb/3KAg+ndAACAypBUwGJSPf4Amiv8FwDJLAGjQJqExQkAqfTovACEJToAwFDCzFbAlTVyfQCrq8/9AJKcpLBAq9whFMCDwN3eQIvrQjwAMUBZUsCRhcJ2wII6YKUAhTBQi+dpbBpgA== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: X-Mailman-Approved-At: Fri, 19 Aug 2016 14:19:45 -0700 Cc: i2rs@ietf.org, 'Alissa Cooper' , 'Juergen Schoenwaelder' , i2rs-chairs@ietf.org, 'Kathleen Moriarty' , 'IESG' , 'Jeffrey Haas' , 'Joel Halpern' , 'Lou Berger' , 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Aug 2016 21:18:50 -0000 Bill: Thank you for your comment. Just to be clear, your revised comment is: New /A non-secure transport may be used for publishing telemetry data or other operational state that was specifically indicated as non-confidential in the data model. / Sue -----Original Message----- From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of William Atwood Sent: Friday, August 19, 2016 4:14 PM To: Susan Hares; 'Andy Bierman' Cc: i2rs@ietf.org; 'Alissa Cooper'; 'Juergen Schoenwaelder'; i2rs-chairs@ietf.org; 'Kathleen Moriarty'; 'IESG'; 'Jeffrey Haas'; 'Joel Halpern'; 'Lou Berger'; 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) See suggestion below:- On 19/08/2016 12:55 PM, Susan Hares wrote: > > New: > > / A non-secure transport can be used for publishing telemetry data or may > > other operational state that was specifically indicated to non- be non- > > confidential in the data model. / > > can = it is possible to do it may = you have permission to do it I offer two choices for the second correction: s/to/to be/ (as indicated) s/to/as/ (which is perhaps better than my first suggestion) Bill -- Dr. J.W. Atwood, Eng. tel: +1 (514) 848-2424 x3046 Distinguished Professor Emeritus fax: +1 (514) 848-2830 Department of Computer Science and Software Engineering Concordia University EV 3.185 email:william.atwood@concordia.ca 1455 de Maisonneuve Blvd. West http://users.encs.concordia.ca/~bill Montreal, Quebec Canada H3G 1M8 _______________________________________________ i2rs mailing list i2rs@ietf.org https://www.ietf.org/mailman/listinfo/i2rs From nobody Sun Aug 21 05:37:18 2016 Return-Path: X-Original-To: i2rs@ietf.org Delivered-To: i2rs@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D584412D0E2; Sun, 21 Aug 2016 05:37:15 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Stephen Farrell" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.29.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147178303586.24090.10213578467078868403.idtracker@ietfa.amsl.com> Date: Sun, 21 Aug 2016 05:37:15 -0700 Archived-At: Cc: jhaas@pfrc.org, i2rs@ietf.org, i2rs-chairs@ietf.org, draft-ietf-i2rs-protocol-security-requirements@ietf.org Subject: [i2rs] Stephen Farrell's Abstain on draft-ietf-i2rs-protocol-security-requirements-09: (with COMMENT) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Aug 2016 12:37:16 -0000 Stephen Farrell has entered the following ballot position for draft-ietf-i2rs-protocol-security-requirements-09: Abstain When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-i2rs-protocol-security-requirements/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- First, apologies for not getting my review done for this when it was scheduled due to my vacation and thanks for being willing to defer the document. Second, having now properly reviewed this, I am balloting abstain as I think it's unlikely that this document can be fixed in a way that results in something useful happening. I think that the likely outcome is that this document will be used later when people are arguing and will not much help in resolving those arguments, or else this will be ignored and arguments will be held afresh, as needed. That latter outcome is what I'd guess is most likely and therefore it seems that spending all of our cycles on DISCUSS ballot processing for this would not be wise. That said, I am willing to change to a DISCUSS ballot if the responsible AD prefers that, but I suspect I'll end up with an abstain in any case, after some discussion. The only plan I can think of that'd lead to me ending up with a yes or no-objection ballot would be if this was returned to the WG for fixing and possibly major surgery, which is what I actually think would be the best plan. (I realise this has had a somewhat tortured history, so folks may not be willing to take it back to the WG, but honestly, I think the failings visible in this document do indicate that this is not ready for approval and ought be returned to the WG.) Third, I think the overall set of requirements posed here might (with some unknown probability) lead to later specifications that are considered too hard to deploy, with the result that non-secure variants of I2RS become the norm. That seems like it would be a really bad outcome. I would suggest that might be partly mitigated if a requirement were added to the effect that deployment issues and specifically ease of deployment MUST be considered as a first order requirement when developing I2RS protocol solutions. Fourth, the (19!) comments below that are preceded by "(discuss" would have been DISCUSS ballot points had I not decided to abstain. I am happy to chat about any of my comments below, but if the authors/WG do want to chat, it might be more efficient to concentrate on those that would otherwise have been DISCUSS points. (But that's your call, I don't mind.) I think the 19 would-have-been-discuss points is another clue that this ought really be sent back to the WG. And with that, and with apologies for this being such an overall negative review, here're my detailed comments: - general: The writing here is generally poor, for example the opener is "This presents..." whereas it ought be "This document presents..." (or s/document/whatever you prefer/). Such issues are repeatedly seen and all that makes this a much harder read than ought be the case. I'd strongly recommend an editorial pass from someone who hasn't been down in the weeds with this text for a while (which could be one of the authors, if one of them has been less active recently.) Note that this is not only (but is primarily) an editorial issue - there are some cases (hopefully called out below) where the writing does create real ambiguity that might lead to re-opening old arguments later. - abstract: "mutual authentication, transport protocols, data transfer and transactions" don't seem to me to be commensurate things, so the abstract, as written is very uninformative for me. - intro 3rd para: I'm really not sure what you're telling me about [I-D.ietf-i2rs-ephemeral-state]. "The draft [RFC7922]" is odd, that being no longer a draft. I'd have expected such nits would have been fixed by now TBH. Same for the last sentence. That para makes the intro pretty unclear for me. - 2.2: The definition of higher level protocol seems like an odd place to introduce the fact that i2rs == netconf + restconf. That'd be more usefully said in the abstract/intro if that's solidly agreed by the WG. - 2.2: This is wrong: "While it is possible to have an I2RS operation which is contained in multiple I2RS (E.g. write in multiple messages), this is not supported in order to simplify the first version of I2RS." The reason this is wrong, is that it is here that you are defining that it is not possible to have an operation in multiple messages. s/it is/it could have been/ would work maybe. - 2.2: " * The I2RS client issues a read request to a I2RS agent, and the I2RS Agent responding to the read request" Shouldn't that use respond and not responding? Given that you seem to be trying to define the scope of what is and is not a transaction, I think being precise with the language is something well worth doing. The 2nd bullet could also do with a re-write. (discuss1) 2.2: you sort-of define messages, operations, transactions and actions. None of the definitions are that precise, e.g. are those the only operations or examples? And transaction and action aren't really defined at all. I'm not sure if that's likely to be a problem or not. I suspect it will later, e.g. when you get to figuring out the scope within which replay needs to be detectable. - 2.2: s/transation/transaction/ (discuss2) - 2.2: "defines a secondary identity as the entity of some non-I2RS entity " That could be abused for tracking of various kinds I would guess, e.g. if an IMEI were used. I think you need to note that and should impose some requirements that such secondary identifiers are not used thusly for tracking. Also, should the first occurrence of entity there be identity? - 3, 1st para: s/The security for the/The/ - there isn't a thing called the security for the i2rs protocol. (discuss3) - section 3 says "the I2RS protocol requires mutually authenticated I2RS clients and I2RS agents communicating over a secure transport." To me that implies that something like TLS or SSH is MTU which seems to contradict recent emails. - section 3 says: "The I2RS protocol MUST be able to provide atomicity of an I2RS transaction, but it is not required to have multi-message atomicity and roll-back mechanism transactions. Multiple messages transactions may be impacted by the interdependency of data." I don't believe that that's easily enough understood to be useful. Also, wouldn't s/Multiple messages transactions/Multiple-message transactions/ be much clearer if that's what's meant? And finally, I think the MUST embedded in the above is not that great an idea - it's clearer IMO to separate the 2119 language from introductory text in documents like this. - 3: "There are dependencies in some of the requirements below" would be better as "There are inter-dependencies between some of the requirements below" unless you mean dependencies on some external things, which is not clear from the text as-is. (discuss4) " For confidentiality (section 3.3) and integrity (section 3.4) to be achieved, the client-agent must have mutual authentication (section 3.1) and secure transport (section 3.2). " This is incorrect. One can have confidentiality without authentication (see RFC7435) so the text is not accurate. - capitalisation needs fixing in various places, e.g. around the end of p5, we get "secure Transport" and then "I2RS client" and "I2RS Agent" in the title of 3.1 Is any of that capitalisation supposed to be significant? Either way, fixing it now would be good as you'll need to get the RFC editor to do it later if you don't (which takes longer). (discuss5) SEC-REQ-01: what is the scope of uniqueness required here? I see no reason why two different data centres cannot re-use a client or agent identifier, if they so wish. I'd be fine if you say that's for later decision, but being silent on the matter could lead to trouble later if different folks decide differently. (discuss6) SEC-REQ-02: the "MUST utilize" there means MTU, which wasn't what you wanted I think (discuss7) - SEC-REQ-03: how is "upon receiving... MUST confirm" a good choice? As stated that'd be hugely onerous, implying e.g. OCSP checks for each packet received. Same point applies to SEC-REQ-04. (discuss8) - SEC-REQ-05: this either means nothing at all (being a tautology) or else something I don't get. I think it's the former, but am not sure. - 3.1: s/One mechanism such mechanism/One such mechanism/ I guess. And it's not at all clear to me "AAA protocols" is the right idea there, and nor is it clear what's meant, with the text as-is. - SEC-REQ-06: where is a "priority" defined? - SEC-REQ-07: here you say read/write is a transaction, but earlier you said it was an operation, which is it? (discuss9) 3.2: As with others, I don't think the idea of annotating parts of yang modules with "can be insecure" is a good one. There's a separate thread discussing that though, so maybe better to not fork that. (discuss10) - SEC-REQ-O9: I hate to do this to ya, but BCP107 is IMO a fairly clear failure when it comes to routing. And yet again the exceptions clauses here are so broad as to be meaningless (e.g. considered low value by whom?). What is the real goal here? (other than an attempt to keep the sec ADs from being annoying and trying to insist on BCP107? ;-) (discuss11) - SEC-REQ-09: Separately, to my other would-be-discuss point on this requirement, "can guarantee" is well beyond the state of the art in key management. I'd just drop that sentence maybe, but can't make a concrete suggestion until I understand where you want to be wrt BCP107. - SEC-REQ-10: the last sentence here is also involved in the "may do stuff insecurely" thing, and so will likely need fixing when that is fully resolved. - How is SEC-REQ-11 useful? What protocol artefacts do you have in mind here? Perhaps a requirement that DDoS attacks be specifically considered in I2RS would be more useful. - SEC-REQ-12: This seems to me to have too many words, e.g. the current text could be read to imply that outside of critical infrastructure there is less or no need for confidentiality, so those added words (presumably there to motivate) might be counter-productive. (discuss12) SEC-REQ-12: I don't get the meaning of the SHOULD here - combined with "certain data" that SHOULD seems to end up meaning MAY, as in, it seems to mean the same as "Read/write operations MAY have to be protected using a confidentiality service." - 3.4, bullet (2) here means that we're not talking about data integrity but data origin authentication as well. (discuss13) 3.4, (3): Within what scope must replay be detected? The text implies for ever, which can be very onerous. SEC-REQ-14 doesn't quite go so far, but is ambiguous on this aspect. I'd say best is to note that the scope within which replay needs to be detectable is for future study. (discuss14) SEC-REQ-15: Sorry, I don't understand what's required here (having read this >1 time). Can you explain? I'm not sure if any substantive change is needed, but there are certainly editorial changes needed for sure as there are multiple wording problems with the text as-is. - 3.5, 1st para: the text here is not as good as the actual definition of "role" in RFC7921, and in fact I found the text here confusing. Better to just delete that and say that 7921 defines roles. (discuss15) SEC-REQ-16: I don't see any content in this text as it seems to just say "some role based access control and some level of transport protection need to be provided" which is always true, as you are allowing "no transport security" and (I assume) "fully public access" so any protocol/system will always meet this requirement. - SEC-REQ-16: "privacy requirements" here is wrong, you mean confidentiality I think. (discuss16) SEC-REQ-17: "MUST work" is far too vague. That could for example hide a major debate about push v. pull of role information. If the WG haven't considered that, I think you could ack that again by saying that more work is needed to define how RBAC is consistent across multiple transport layer connections. (discuss17) SEC-REQ-18: again this seems to have no content, other than perhaps imposing an odd requirement on implementations - I don't see a protocol requirement here at all. It is reasonable to note that libraries for clients ought not assume a single client identity but even that's very specific to library implementations and since it's just a MAY that's entirely obvious, I'd leave it out. (discuss18) SEC-REQ-19: I fully agree with the motivation here but I think the stated requirement is broken. For example, I don't know how a piece of s/w will determine whether or not it is correlated with a person. I also don't think a SHOULD works here, as again something would need to be stated about the situations when the feature is not needed, and I can't figure out a sensible statement for that. The last sentence also seems likely not useful. All in all, I think this is likely to be ignored or even worse treated like a piece of fig-leaf specification text to pretend that we're caring about privacy. (discuss19) - 3.6: I have no idea whether this other draft is supposed to be considered as setting requirements or not. I assume that the answer is "not" as you've made it an informative reference, but in that case you really should say that. The alternative would be that 3.6 is essentially specifying an applicability statement for the environments in which it is, and is not, ok to run i2rs. If the latter were intended, then you'd need to say it and make the draft a normative reference. From nobody Sun Aug 21 12:10:15 2016 Return-Path: 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 9492112D5FB; Sun, 21 Aug 2016 12:10:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.095 X-Spam-Level: X-Spam-Status: No, score=-1.095 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_BL=0.01, RCVD_IN_MSPIKE_L5=0.001, RDNS_NONE=0.793] autolearn=no 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 K-LEzshsII9T; Sun, 21 Aug 2016 12:10:11 -0700 (PDT) Received: from hickoryhill-consulting.com (unknown [50.245.122.97]) (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 6AEDC12D7C6; Sun, 21 Aug 2016 12:10:10 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=166.177.56.220; Date: Sun, 21 Aug 2016 15:10:04 -0400 Message-ID: <6nfkw155x8fc3tk9rou61bbw.1471806604523@email.android.com> Importance: normal From: Susan Hares To: Stephen Farrell , The IESG MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--_com.samsung.android.email_100536710520980" X-Authenticated-User: skh@ndzh.com Archived-At: Cc: jhaas@pfrc.org, i2rs@ietf.org, i2rs-chairs@ietf.org, draft-ietf-i2rs-protocol-security-requirements@ietf.org Subject: Re: [i2rs] Stephen Farrell's Abstain on draft-ietf-i2rs-protocol-security-requirements-09: (with COMMENT) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Aug 2016 19:10:13 -0000 ----_com.samsung.android.email_100536710520980 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 U3RlcGhlbjoKVGhhbmsgeW91IGZvciBsZWF2aW5nIHlvdXIgdmFjYXRpb24gZWFybHkgdG8gZG8g dGhpcyByZXZpZXcuIMKgSXQgaXMgb25lIG9mIHRoZSBtb3N0IG5lZ2F0aXZlIHZpZXdwb2ludCBJ IGhhdmUgcmVhZCBmcm9tIHlvdSwgYW5kIHNpbmNlIMKgaGF2ZSByZWFkIG1hbnkgb2YgeW91ciBE SVNDVVNTIGNvbW1lbnRzIHNpbmNlIHlvdSBiZWNhbWUgYW4gQUQgLSBJIHRoaW5rIHRoaXMgZ2l2 ZXMgbWUgdW5pcXVlIHBlcnNwZWN0aXZlLiDCoFRoaXMgaXMgZmFyIGZyb20gdGhlIGVhcmx5IGNv bW1lbnRzIHlvdSBzZW50IDIgd2Vla3MgYWdvLgpJbiBkZXZlbG9waW5nIHRoaXMgZG9jdW1lbnQg YW5kIEkyUlMgdGVjaG5vbG9neSB0aGUgSTJSUyBXRyBhbmQgSSBhcyB0aGUgSTJSUyBjaGFpciBo YXZlIHJlcXVlc3QgcmV2aWV3cyBmcm9tIHRoZSBTZWN1cml0eSBkaXJlY3RvcmF0ZS4gwqBXZSBk ZWxheWVkIG91dCBmaXJzdCByZXZpc2lvbnMgdG8gdHJ5IHRvIGFkZHJlc3Mgc2VjdXJpdHkgaXNz dWUgYnkgYWRkaW5nIHRoaXMgZG9jdW1lbnQgYW5kIHRoZSBzZWN1cml0eSBlbnZpcm9ubWVudCBk b2N1bWVudC4gwqBXZSBoYXZlIGhhZCBlYXJseSBhbmQgbGF0ZSByZXZpZXdzLiDCoFNpbmNlIHRo ZSBpbml0aWFsIHJldmlldyBvbiB0aGUgSTJSUyBhcmNoaXRlY3R1cmUgd2UgaGF2ZSBkaXNjdXNz ZWQgdGhlIG5vbi1zZWN1cmUgaW50ZXJmYWNlIGFuZCB0cmllZCB0byBnZXQgc2VjdXJpdHkgZGly ZWN0b3JhdGUncyByZXZpZXcuIMKgSSByYWlzZWQgdGhlIHBlcnZhc2l2ZSBwcml2YWN5IGlzc3Vl IGFuZCBhc2tlZCBmb3IgaW5wdXQgaW4geW91ciByZXZpZXcuClRoaXMgbWV0YS1jb21tZW50IGlz IHRoYXQgcHJvY2VzcyBvZiBhc2tpbmcgZm9yIGFpZCBhaGVhZCBvZiB0aGlzIHBvaW50IGhhcyBm YWlsZWQgYWNjb3JkaW5nIHRvIHlvdXIgcmV2aWV3LCBidXQgSSBjYW5ub3QgZmluZCBhIHBvaW50 IHdoZXJlIHRoZSBJMlJTIFdHIGRpZCBub3Qgc29saWNpdCB0aGUgc2VjdXJpdHkgYXJlYSdzIGFp ZCBhbmQgdGFrZSBpdHMgYWR2aWNlLiDCoFRoZXJlZm9yZSwgwqBJIG11c3QgYXNrIHlvdSB0byBj aGVjayB0aGUgcHJvY2VzcyBvZiB5b3VyIHNlY3VyaXR5IGRpcmVjdG9yYXRlJ3MgcmV2aWV3cyB0 byBmaW5kIHdoYXQgaGFwcGVuZWQgdG8gY2F1c2Ugc3VjaCBhIGZhaWx1cmUuCk5vdyBhcyB0byB0 aGUgZG9jdW1lbnQsIEkgaGF2ZSBhIFdHIHdhaXRpbmcgZm9yIHRoZXNlIHJlcXVpcmVtZW50cy4g wqBJIHdvdWxkIGxpa2UgdG8gaGVhciBpbiBhIGNvbXBsZXRlbHkgc2VwYXJhdGUgZW1haWwgdGhy ZWFkIHdoYXQga2VybmVsIG9mIGluZm9ybWF0aW9uIHlvdSB3b3VsZCBoYXZlIGV4cGVjdGVkIHJl Z2FyZGluZyB0aGUgc2VjdXJpdHkgZmlyc3QgYW4gaTJycyBwcm90b2NvbC4gwqBJIHdvdWxkIHRo ZW4gbGlrZSB0byBjb21wYXJlIHRoaXMgYWdhaW5zdCB0aGUgc2VjdXJpdHkgZGlyZWN0b3JhdGUn cyBzdWdnZXN0aW9ucyBvbiB0aGlzIGRvY3VtZW50LiDCoFdlIGhhdmUgYSBzZWNvbmQgZG9jdW1l bnQgb24gdGhlIHNlY3VyaXR5IGVudmlyb25tZW50IHNvIHlvdXIgaW5zaWdodHMgd2lsbCBiZSBh cHBsaWVkIHRvIHRoYXQgZG9jdW1lbnQuClNpbmNlIGluIHRoZSBnZW5lcmFsIHRleHQgeW91IGlu ZGljYXRlIHRoZSBzdHlsZSBpcyB0ZXJyaWJsZSBhbmQgbmVlZHMgdG8gYmUgd3JpdHRlbiwgcGxl YXNlIHByb3ZpZGUgYW4gZXhhbXBsZSBvZiBhIGRvY3VtZW50IGFzIGFuIGV4YW1wbGUgb2YgdGhl IHN0eWxlLiDCoE15IHVuZGVyc3RhbmRpbmcgaXMgdGhhdCBzdHlsZSBpcyBhIGxvd2VyIHByaW9y aXR5IHRoYW4gdGVjaG5pY2FsIGNvcnJlY3RuZXNzIGFuZCBjb25zZW5zdXMuClRoaXMgZW1haWwg ZW5kcyBteSBjb21tZW50cyBvbiB5b3VyIHN1bW1hcnkgbWVzc2FnZS4gwqBUaGUgbmV4dCBzZXQg b2YgY29tbWVudHMgd2lsbCB0YWtlIHlvdXIgZGlzY3VzcyBjb21tZW50cyBvbmUgYXQgYSB0aW1l LiDCoApUaGUgZXhhY3QgbmV4dCBzdGVwcyB0aGF0IEkgYW5kIG15IGNvLWF1dGhvciB3aWxsIHRh a2Ugd2lsbCBiZSBndWlkZWQgYnkgdGhlIEFEIHJlc3BvbnNpYmxlIGZvciB0aGUgSTJSUyBXRywg QWxpYS4gwqAKQ2hlZXJpbHksIMKgU3VlIEhhcmVzCgpTZW50IHZpYSB0aGUgU2Ftc3VuZyBHYWxh eHkgTm90ZTUsIGFuIEFUJlQgNEcgTFRFIHNtYXJ0cGhvbmUKLS0tLS0tLS0gT3JpZ2luYWwgbWVz c2FnZSAtLS0tLS0tLUZyb206IFN0ZXBoZW4gRmFycmVsbCA8c3RlcGhlbi5mYXJyZWxsQGNzLnRj ZC5pZT4gRGF0ZTogOC8yMS8xNiAgODozNyBBTSAgKEdNVC0wNTowMCkgVG86IFRoZSBJRVNHIDxp ZXNnQGlldGYub3JnPiBDYzogamhhYXNAcGZyYy5vcmcsIGkycnNAaWV0Zi5vcmcsIGkycnMtY2hh aXJzQGlldGYub3JnLCBkcmFmdC1pZXRmLWkycnMtcHJvdG9jb2wtc2VjdXJpdHktcmVxdWlyZW1l bnRzQGlldGYub3JnIFN1YmplY3Q6IFtpMnJzXSBTdGVwaGVuIEZhcnJlbGwncyBBYnN0YWluIG9u CiAgZHJhZnQtaWV0Zi1pMnJzLXByb3RvY29sLXNlY3VyaXR5LXJlcXVpcmVtZW50cy0wOTogKHdp dGggQ09NTUVOVCkgClN0ZXBoZW4gRmFycmVsbCBoYXMgZW50ZXJlZCB0aGUgZm9sbG93aW5nIGJh bGxvdCBwb3NpdGlvbiBmb3IKZHJhZnQtaWV0Zi1pMnJzLXByb3RvY29sLXNlY3VyaXR5LXJlcXVp cmVtZW50cy0wOTogQWJzdGFpbgoKV2hlbiByZXNwb25kaW5nLCBwbGVhc2Uga2VlcCB0aGUgc3Vi amVjdCBsaW5lIGludGFjdCBhbmQgcmVwbHkgdG8gYWxsCmVtYWlsIGFkZHJlc3NlcyBpbmNsdWRl ZCBpbiB0aGUgVG8gYW5kIENDIGxpbmVzLiAoRmVlbCBmcmVlIHRvIGN1dCB0aGlzCmludHJvZHVj dG9yeSBwYXJhZ3JhcGgsIGhvd2V2ZXIuKQoKClBsZWFzZSByZWZlciB0byBodHRwczovL3d3dy5p ZXRmLm9yZy9pZXNnL3N0YXRlbWVudC9kaXNjdXNzLWNyaXRlcmlhLmh0bWwKZm9yIG1vcmUgaW5m b3JtYXRpb24gYWJvdXQgSUVTRyBESVNDVVNTIGFuZCBDT01NRU5UIHBvc2l0aW9ucy4KCgpUaGUg ZG9jdW1lbnQsIGFsb25nIHdpdGggb3RoZXIgYmFsbG90IHBvc2l0aW9ucywgY2FuIGJlIGZvdW5k IGhlcmU6Cmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtaTJycy1w cm90b2NvbC1zZWN1cml0eS1yZXF1aXJlbWVudHMvCgoKCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KQ09NTUVOVDoK LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLQoKCkZpcnN0LCBhcG9sb2dpZXMgZm9yIG5vdCBnZXR0aW5nIG15IHJldmll dyBkb25lIGZvcgp0aGlzIHdoZW4gaXQgd2FzIHNjaGVkdWxlZCBkdWUgdG8gbXkgdmFjYXRpb24g YW5kCnRoYW5rcyBmb3IgYmVpbmcgd2lsbGluZyB0byBkZWZlciB0aGUgZG9jdW1lbnQuCgpTZWNv bmQsIGhhdmluZyBub3cgcHJvcGVybHkgcmV2aWV3ZWQgdGhpcywgSSBhbQpiYWxsb3RpbmcgYWJz dGFpbiBhcyBJIHRoaW5rIGl0J3MgdW5saWtlbHkgdGhhdCB0aGlzCmRvY3VtZW50IGNhbiBiZSBm aXhlZCBpbiBhIHdheSB0aGF0IHJlc3VsdHMgaW4Kc29tZXRoaW5nIHVzZWZ1bCBoYXBwZW5pbmcu IEkgdGhpbmsgdGhhdCB0aGUgbGlrZWx5Cm91dGNvbWUgaXMgdGhhdCB0aGlzIGRvY3VtZW50IHdp bGwgYmUgdXNlZCBsYXRlciB3aGVuCnBlb3BsZSBhcmUgYXJndWluZyBhbmQgd2lsbCBub3QgbXVj aCBoZWxwIGluIHJlc29sdmluZwp0aG9zZSBhcmd1bWVudHMsIG9yIGVsc2UgdGhpcyB3aWxsIGJl IGlnbm9yZWQgYW5kCmFyZ3VtZW50cyB3aWxsIGJlIGhlbGQgYWZyZXNoLCBhcyBuZWVkZWQuIFRo YXQgbGF0dGVyCm91dGNvbWUgaXMgd2hhdCBJJ2QgZ3Vlc3MgaXMgbW9zdCBsaWtlbHkgYW5kIHRo ZXJlZm9yZQppdCBzZWVtcyB0aGF0IHNwZW5kaW5nIGFsbCBvZiBvdXIgY3ljbGVzIG9uIERJU0NV U1MKYmFsbG90IHByb2Nlc3NpbmcgZm9yIHRoaXMgd291bGQgbm90IGJlIHdpc2UuIFRoYXQKc2Fp ZCwgSSBhbSB3aWxsaW5nIHRvIGNoYW5nZSB0byBhIERJU0NVU1MgYmFsbG90IGlmIHRoZQpyZXNw b25zaWJsZSBBRCBwcmVmZXJzIHRoYXQsIGJ1dCBJIHN1c3BlY3QgSSdsbCBlbmQgdXAKd2l0aCBh biBhYnN0YWluIGluIGFueSBjYXNlLCBhZnRlciBzb21lIGRpc2N1c3Npb24uIFRoZQpvbmx5IHBs YW4gSSBjYW4gdGhpbmsgb2YgdGhhdCdkIGxlYWQgdG8gbWUgZW5kaW5nIHVwCndpdGggYSB5ZXMg b3Igbm8tb2JqZWN0aW9uIGJhbGxvdCB3b3VsZCBiZSBpZiB0aGlzIHdhcwpyZXR1cm5lZCB0byB0 aGUgV0cgZm9yIGZpeGluZyBhbmQgcG9zc2libHkgbWFqb3IKc3VyZ2VyeSwgd2hpY2ggaXMgd2hh dCBJIGFjdHVhbGx5IHRoaW5rIHdvdWxkIGJlIHRoZQpiZXN0IHBsYW4uIChJIHJlYWxpc2UgdGhp cyBoYXMgaGFkIGEgc29tZXdoYXQgdG9ydHVyZWQKaGlzdG9yeSwgc28gZm9sa3MgbWF5IG5vdCBi ZSB3aWxsaW5nIHRvIHRha2UgaXQgYmFjayB0bwp0aGUgV0csIGJ1dCBob25lc3RseSwgSSB0aGlu ayB0aGUgZmFpbGluZ3MgdmlzaWJsZSBpbgp0aGlzIGRvY3VtZW50IGRvIGluZGljYXRlIHRoYXQg dGhpcyBpcyBub3QgcmVhZHkgZm9yCmFwcHJvdmFsIGFuZCBvdWdodCBiZSByZXR1cm5lZCB0byB0 aGUgV0cuKQoKVGhpcmQsIEkgdGhpbmsgdGhlIG92ZXJhbGwgc2V0IG9mIHJlcXVpcmVtZW50cyBw b3NlZApoZXJlIG1pZ2h0ICh3aXRoIHNvbWUgdW5rbm93biBwcm9iYWJpbGl0eSkgbGVhZCB0bwps YXRlciBzcGVjaWZpY2F0aW9ucyB0aGF0IGFyZSBjb25zaWRlcmVkIHRvbyBoYXJkIHRvCmRlcGxv eSwgd2l0aCB0aGUgcmVzdWx0IHRoYXQgbm9uLXNlY3VyZSB2YXJpYW50cyBvZgpJMlJTIGJlY29t ZSB0aGUgbm9ybS4gVGhhdCBzZWVtcyBsaWtlIGl0IHdvdWxkIGJlIGEKcmVhbGx5IGJhZCBvdXRj b21lLiBJIHdvdWxkIHN1Z2dlc3QgdGhhdCBtaWdodCBiZQpwYXJ0bHkgbWl0aWdhdGVkIGlmIGEg cmVxdWlyZW1lbnQgd2VyZSBhZGRlZCB0byB0aGUKZWZmZWN0IHRoYXQgZGVwbG95bWVudCBpc3N1 ZXMgYW5kIHNwZWNpZmljYWxseSBlYXNlIG9mCmRlcGxveW1lbnQgTVVTVCBiZSBjb25zaWRlcmVk IGFzIGEgZmlyc3Qgb3JkZXIKcmVxdWlyZW1lbnQgd2hlbiBkZXZlbG9waW5nIEkyUlMgcHJvdG9j b2wgc29sdXRpb25zLiAKCkZvdXJ0aCwgdGhlICgxOSEpIGNvbW1lbnRzIGJlbG93IHRoYXQgYXJl IHByZWNlZGVkIGJ5CiIoZGlzY3VzcyIgd291bGQgaGF2ZSBiZWVuIERJU0NVU1MgYmFsbG90IHBv aW50cyBoYWQgSQpub3QgZGVjaWRlZCB0byBhYnN0YWluLiBJIGFtIGhhcHB5IHRvIGNoYXQgYWJv dXQgYW55IG9mCm15IGNvbW1lbnRzIGJlbG93LCBidXQgaWYgdGhlIGF1dGhvcnMvV0cgZG8gd2Fu dCB0bwpjaGF0LCBpdCBtaWdodCBiZSBtb3JlIGVmZmljaWVudCB0byBjb25jZW50cmF0ZSBvbgp0 aG9zZSB0aGF0IHdvdWxkIG90aGVyd2lzZSBoYXZlIGJlZW4gRElTQ1VTUyBwb2ludHMuCihCdXQg dGhhdCdzIHlvdXIgY2FsbCwgSSBkb24ndCBtaW5kLikgSSB0aGluayB0aGUgMTkKd291bGQtaGF2 ZS1iZWVuLWRpc2N1c3MgcG9pbnRzIGlzIGFub3RoZXIgY2x1ZSB0aGF0CnRoaXMgb3VnaHQgcmVh bGx5IGJlIHNlbnQgYmFjayB0byB0aGUgV0cuCgpBbmQgd2l0aCB0aGF0LCBhbmQgd2l0aCBhcG9s b2dpZXMgZm9yIHRoaXMgYmVpbmcgc3VjaAphbiBvdmVyYWxsIG5lZ2F0aXZlIHJldmlldywgaGVy ZSdyZSBteSBkZXRhaWxlZApjb21tZW50czoKCi0gZ2VuZXJhbDogVGhlIHdyaXRpbmcgaGVyZSBp cyBnZW5lcmFsbHkgcG9vciwgZm9yCmV4YW1wbGUgdGhlIG9wZW5lciBpcyAiVGhpcyBwcmVzZW50 cy4uLiIgd2hlcmVhcyBpdApvdWdodCBiZSAiVGhpcyBkb2N1bWVudCBwcmVzZW50cy4uLiIgKG9y CnMvZG9jdW1lbnQvd2hhdGV2ZXIgeW91IHByZWZlci8pLiBTdWNoIGlzc3VlcyBhcmUKcmVwZWF0 ZWRseSBzZWVuIGFuZCBhbGwgdGhhdCBtYWtlcyB0aGlzIGEgbXVjaCBoYXJkZXIKcmVhZCB0aGFu IG91Z2h0IGJlIHRoZSBjYXNlLiBJJ2Qgc3Ryb25nbHkgcmVjb21tZW5kIGFuCmVkaXRvcmlhbCBw YXNzIGZyb20gc29tZW9uZSB3aG8gaGFzbid0IGJlZW4gZG93biBpbiB0aGUKd2VlZHMgd2l0aCB0 aGlzIHRleHQgZm9yIGEgd2hpbGUgKHdoaWNoIGNvdWxkIGJlIG9uZSBvZgp0aGUgYXV0aG9ycywg aWYgb25lIG9mIHRoZW0gaGFzIGJlZW4gbGVzcyBhY3RpdmUKcmVjZW50bHkuKSBOb3RlIHRoYXQg dGhpcyBpcyBub3Qgb25seSAoYnV0IGlzCnByaW1hcmlseSkgYW4gZWRpdG9yaWFsIGlzc3VlIC0g dGhlcmUgYXJlIHNvbWUgY2FzZXMKKGhvcGVmdWxseSBjYWxsZWQgb3V0IGJlbG93KSB3aGVyZSB0 aGUgd3JpdGluZyBkb2VzCmNyZWF0ZSByZWFsIGFtYmlndWl0eSB0aGF0IG1pZ2h0IGxlYWQgdG8g cmUtb3BlbmluZyBvbGQKYXJndW1lbnRzIGxhdGVyLgoKLSBhYnN0cmFjdDogIm11dHVhbCBhdXRo ZW50aWNhdGlvbiwgdHJhbnNwb3J0CnByb3RvY29scywgZGF0YSB0cmFuc2ZlciBhbmQgdHJhbnNh Y3Rpb25zIiBkb24ndCBzZWVtCnRvIG1lIHRvIGJlIGNvbW1lbnN1cmF0ZSB0aGluZ3MsIHNvIHRo ZSBhYnN0cmFjdCwgYXMKd3JpdHRlbiBpcyB2ZXJ5IHVuaW5mb3JtYXRpdmUgZm9yIG1lLgoKLSBp bnRybyAzcmQgcGFyYTogSSdtIHJlYWxseSBub3Qgc3VyZSB3aGF0IHlvdSdyZQp0ZWxsaW5nIG1l IGFib3V0IFtJLUQuaWV0Zi1pMnJzLWVwaGVtZXJhbC1zdGF0ZV0uwqAgIlRoZQpkcmFmdCBbUkZD NzkyMl0iIGlzIG9kZCwgdGhhdCBiZWluZyBubyBsb25nZXIgYSBkcmFmdC4KSSdkIGhhdmUgZXhw ZWN0ZWQgc3VjaCBuaXRzIHdvdWxkIGhhdmUgYmVlbiBmaXhlZCBieQpub3cgVEJILiBTYW1lIGZv ciB0aGUgbGFzdCBzZW50ZW5jZS7CoCBUaGF0IHBhcmEgbWFrZXMKdGhlIGludHJvIHByZXR0eSB1 bmNsZWFyIGZvciBtZS4KCi0gMi4yOiBUaGUgZGVmaW5pdGlvbiBvZiBoaWdoZXIgbGV2ZWwgcHJv dG9jb2wgc2VlbXMKbGlrZSBhbiBvZGQgcGxhY2UgdG8gaW50cm9kdWNlIHRoZSBmYWN0IHRoYXQg aTJycyA9PQpuZXRjb25mICsgcmVzdGNvbmYuwqAgVGhhdCdkIGJlIG1vcmUgdXNlZnVsbHkgc2Fp ZCBpbgp0aGUgYWJzdHJhY3QvaW50cm8gaWYgdGhhdCdzIHNvbGlkbHkgYWdyZWVkIGJ5IHRoZSBX Ry4KCi0gMi4yOiBUaGlzIGlzIHdyb25nOiAiV2hpbGUgaXQgaXMgcG9zc2libGUgdG8gaGF2ZSBh bgpJMlJTIG9wZXJhdGlvbiB3aGljaCBpcyBjb250YWluZWQgaW4gbXVsdGlwbGUgSTJSUwooRS5n LsKgIHdyaXRlIGluIG11bHRpcGxlIG1lc3NhZ2VzKSwgdGhpcyBpcyBub3QKc3VwcG9ydGVkIGlu IG9yZGVyIHRvIHNpbXBsaWZ5IHRoZSBmaXJzdCB2ZXJzaW9uIG9mCkkyUlMuIiBUaGUgcmVhc29u IHRoaXMgaXMgd3JvbmcsIGlzIHRoYXQgaXQgaXMgaGVyZQp0aGF0IHlvdSBhcmUgZGVmaW5pbmcg dGhhdCBpdCBpcyBub3QgcG9zc2libGUgdG8gaGF2ZQphbiBvcGVyYXRpb24gaW4gbXVsdGlwbGUg bWVzc2FnZXMuIHMvaXQgaXMvaXQgY291bGQKaGF2ZSBiZWVuLyB3b3VsZCB3b3JrIG1heWJlLgoK LSAyLjI6ICIgKsKgIFRoZSBJMlJTIGNsaWVudCBpc3N1ZXMgYSByZWFkIHJlcXVlc3QgdG8gYQpJ MlJTIGFnZW50LCBhbmQgdGhlIEkyUlMgQWdlbnQgcmVzcG9uZGluZyB0byB0aGUgcmVhZApyZXF1 ZXN0IiBTaG91bGRuJ3QgdGhhdCB1c2UgcmVzcG9uZCBhbmQgbm90IHJlc3BvbmRpbmc/CkdpdmVu IHRoYXQgeW91IHNlZW0gdG8gYmUgdHJ5aW5nIHRvIGRlZmluZSB0aGUgc2NvcGUgb2YKd2hhdCBp cyBhbmQgaXMgbm90IGEgdHJhbnNhY3Rpb24sIEkgdGhpbmsgYmVpbmcgcHJlY2lzZQp3aXRoIHRo ZSBsYW5ndWFnZSBpcyBzb21ldGhpbmcgd2VsbCB3b3J0aCBkb2luZy7CoCBUaGUKMm5kIGJ1bGxl dCBjb3VsZCBhbHNvIGRvIHdpdGggYSByZS13cml0ZS4KCihkaXNjdXNzMSkgMi4yOiB5b3Ugc29y dC1vZiBkZWZpbmUgbWVzc2FnZXMsCm9wZXJhdGlvbnMsIHRyYW5zYWN0aW9ucyBhbmQgYWN0aW9u cy4gTm9uZSBvZiB0aGUKZGVmaW5pdGlvbnMgYXJlIHRoYXQgcHJlY2lzZSwgZS5nLiBhcmUgdGhv c2UgdGhlIG9ubHkKb3BlcmF0aW9ucyBvciBleGFtcGxlcz8gQW5kIHRyYW5zYWN0aW9uIGFuZCBh Y3Rpb24KYXJlbid0IHJlYWxseSBkZWZpbmVkIGF0IGFsbC4gSSdtIG5vdCBzdXJlIGlmIHRoYXQn cwpsaWtlbHkgdG8gYmUgYSBwcm9ibGVtIG9yIG5vdC4gSSBzdXNwZWN0IGl0IHdpbGwgbGF0ZXIs CmUuZy4gd2hlbiB5b3UgZ2V0IHRvIGZpZ3VyaW5nIG91dCB0aGUgc2NvcGUgd2l0aGluCndoaWNo IHJlcGxheSBuZWVkcyB0byBiZSBkZXRlY3RhYmxlLgoKLSAyLjI6IHMvdHJhbnNhdGlvbi90cmFu c2FjdGlvbi8KCihkaXNjdXNzMikgLSAyLjI6ICJkZWZpbmVzIGEgc2Vjb25kYXJ5IGlkZW50aXR5 IGFzIHRoZQplbnRpdHkgb2Ygc29tZSBub24tSTJSUyBlbnRpdHkgIiBUaGF0IGNvdWxkIGJlIGFi dXNlZApmb3IgdHJhY2tpbmcgb2YgdmFyaW91cyBraW5kcyBJIHdvdWxkIGd1ZXNzLCBlLmcuIGlm IGFuCklNRUkgd2VyZSB1c2VkLiBJIHRoaW5rIHlvdSBuZWVkIHRvIG5vdGUgdGhhdCBhbmQKc2hv dWxkIGltcG9zZSBzb21lIHJlcXVpcmVtZW50cyB0aGF0IHN1Y2ggc2Vjb25kYXJ5CmlkZW50aWZp ZXJzIGFyZSBub3QgdXNlZCB0aHVzbHkgZm9yIHRyYWNraW5nLsKgIEFsc28sCnNob3VsZCB0aGUg Zmlyc3Qgb2NjdXJyZW5jZSBvZiBlbnRpdHkgdGhlcmUgYmUKaWRlbnRpdHk/CgotIDMsIDFzdCBw YXJhOiBzL1RoZSBzZWN1cml0eSBmb3IgdGhlL1RoZS8gLSB0aGVyZQppc24ndCBhIHRoaW5nIGNh bGxlZCB0aGUgc2VjdXJpdHkgZm9yIHRoZSBpMnJzCnByb3RvY29sLgoKKGRpc2N1c3MzKSAtIHNl Y3Rpb24gMyBzYXlzICJ0aGUgSTJSUyBwcm90b2NvbCByZXF1aXJlcwptdXR1YWxseSBhdXRoZW50 aWNhdGVkIEkyUlMgY2xpZW50cyBhbmQgSTJSUyBhZ2VudHMKY29tbXVuaWNhdGluZyBvdmVyIGEg c2VjdXJlIHRyYW5zcG9ydC4iIFRvIG1lIHRoYXQKaW1wbGllcyB0aGF0IHNvbWV0aGluZyBsaWtl IFRMUyBvciBTU0ggaXMgTVRVIHdoaWNoCnNlZW1zIHRvIGNvbnRyYWRpY3QgcmVjZW50IGVtYWls cy4KCi0gc2VjdGlvbiAzIHNheXM6ICJUaGUgSTJSUyBwcm90b2NvbCBNVVNUIGJlIGFibGUgdG8K cHJvdmlkZSBhdG9taWNpdHkgb2YgYW4gSTJSUyB0cmFuc2FjdGlvbiwgYnV0IGl0IGlzIG5vdApy ZXF1aXJlZCB0byBoYXZlIG11bHRpLW1lc3NhZ2UgYXRvbWljaXR5IGFuZCByb2xsLWJhY2sKbWVj aGFuaXNtIHRyYW5zYWN0aW9ucy7CoCBNdWx0aXBsZSBtZXNzYWdlcyB0cmFuc2FjdGlvbnMKbWF5 IGJlIGltcGFjdGVkIGJ5IHRoZSBpbnRlcmRlcGVuZGVuY3kgb2YgZGF0YS4iwqAgSQpkb24ndCBi ZWxpZXZlIHRoYXQgdGhhdCdzIGVhc2lseSBlbm91Z2ggdW5kZXJzdG9vZCB0bwpiZSB1c2VmdWwu IEFsc28sIHdvdWxkbid0IHMvTXVsdGlwbGUgbWVzc2FnZXMKdHJhbnNhY3Rpb25zL011bHRpcGxl LW1lc3NhZ2UgdHJhbnNhY3Rpb25zLyBiZSBtdWNoCmNsZWFyZXIgaWYgdGhhdCdzIHdoYXQncyBt ZWFudD8gQW5kIGZpbmFsbHksIEkgdGhpbmsKdGhlIE1VU1QgZW1iZWRkZWQgaW4gdGhlIGFib3Zl IGlzIG5vdCB0aGF0IGdyZWF0IGFuCmlkZWEgLSBpdCdzIGNsZWFyZXIgSU1PIHRvIHNlcGFyYXRl IHRoZSAyMTE5IGxhbmd1YWdlCmZyb20gaW50cm9kdWN0b3J5IHRleHQgaW4gZG9jdW1lbnRzIGxp a2UgdGhpcy4KCi0gMzogIlRoZXJlIGFyZSBkZXBlbmRlbmNpZXMgaW4gc29tZSBvZiB0aGUKcmVx dWlyZW1lbnRzIGJlbG93IiB3b3VsZCBiZSBiZXR0ZXIgYXMgIlRoZXJlIGFyZQppbnRlci1kZXBl bmRlbmNpZXMgYmV0d2VlbiBzb21lIG9mIHRoZSByZXF1aXJlbWVudHMKYmVsb3ciIHVubGVzcyB5 b3UgbWVhbiBkZXBlbmRlbmNpZXMgb24gc29tZSBleHRlcm5hbAp0aGluZ3MsIHdoaWNoIGlzIG5v dCBjbGVhciBmcm9tIHRoZSB0ZXh0IGFzLWlzLgoKKGRpc2N1c3M0KSAiIEZvciBjb25maWRlbnRp YWxpdHkgKHNlY3Rpb24gMy4zKSBhbmQKaW50ZWdyaXR5IChzZWN0aW9uIDMuNCkgdG8gYmUgYWNo aWV2ZWQsIHRoZQpjbGllbnQtYWdlbnQgbXVzdCBoYXZlIG11dHVhbCBhdXRoZW50aWNhdGlvbiAo c2VjdGlvbgozLjEpIGFuZCBzZWN1cmUgdHJhbnNwb3J0IChzZWN0aW9uIDMuMikuwqAgIiBUaGlz IGlzCmluY29ycmVjdC4gT25lIGNhbiBoYXZlIGNvbmZpZGVudGlhbGl0eSB3aXRob3V0CmF1dGhl bnRpY2F0aW9uIChzZWUgUkZDNzQzNSkgc28gdGhlIHRleHQgaXMgbm90CmFjY3VyYXRlLgoKLSBj YXBpdGFsaXNhdGlvbiBuZWVkcyBmaXhpbmcgaW4gdmFyaW91cyBwbGFjZXMsIGUuZy4KYXJvdW5k IHRoZSBlbmQgb2YgcDUsIHdlIGdldCAic2VjdXJlIFRyYW5zcG9ydCIgYW5kCnRoZW4gIkkyUlMg Y2xpZW50IiBhbmQgIkkyUlMgQWdlbnQiIGluIHRoZSB0aXRsZSBvZiAzLjEKSXMgYW55IG9mIHRo YXQgY2FwaXRhbGlzYXRpb24gc3VwcG9zZWQgdG8gYmUKc2lnbmlmaWNhbnQ/IEVpdGhlciB3YXks IGZpeGluZyBpdCBub3cgd291bGQgYmUgZ29vZCBhcwp5b3UnbGwgbmVlZCB0byBnZXQgdGhlIFJG QyBlZGl0b3IgdG8gZG8gaXQgbGF0ZXIgaWYgeW91CmRvbid0ICh3aGljaCB0YWtlcyBsb25nZXIp LgoKKGRpc2N1c3M1KSBTRUMtUkVRLTAxOiB3aGF0IGlzIHRoZSBzY29wZSBvZiB1bmlxdWVuZXNz CnJlcXVpcmVkIGhlcmU/IEkgc2VlIG5vIHJlYXNvbiB3aHkgdHdvIGRpZmZlcmVudCBkYXRhCmNl bnRyZXMgY2Fubm90IHJlLXVzZSBhIGNsaWVudCBvciBhZ2VudCBpZGVudGlmaWVyLCBpZgp0aGV5 IHNvIHdpc2guIEknZCBiZSBmaW5lIGlmIHlvdSBzYXkgdGhhdCdzIGZvciBsYXRlcgpkZWNpc2lv biwgYnV0IGJlaW5nIHNpbGVudCBvbiB0aGUgbWF0dGVyIGNvdWxkIGxlYWQgdG8KdHJvdWJsZSBs YXRlciBpZiBkaWZmZXJlbnQgZm9sa3MgZGVjaWRlIGRpZmZlcmVudGx5LgoKKGRpc2N1c3M2KSBT RUMtUkVRLTAyOiB0aGUgIk1VU1QgdXRpbGl6ZSIgdGhlcmUgbWVhbnMKTVRVLCB3aGljaCB3YXNu J3Qgd2hhdCB5b3Ugd2FudGVkIEkgdGhpbmsKCihkaXNjdXNzNykgLSBTRUMtUkVRLTAzOiBob3cg aXMgInVwb24gcmVjZWl2aW5nLi4uIE1VU1QKY29uZmlybSIgYSBnb29kIGNob2ljZT8gQXMgc3Rh dGVkIHRoYXQnZCBiZSBodWdlbHkKb25lcm91cywgaW1wbHlpbmcgZS5nLsKgIE9DU1AgY2hlY2tz IGZvciBlYWNoIHBhY2tldApyZWNlaXZlZC4gU2FtZSBwb2ludCBhcHBsaWVzIHRvIFNFQy1SRVEt MDQuCgooZGlzY3VzczgpIC0gU0VDLVJFUS0wNTogdGhpcyBlaXRoZXIgbWVhbnMgbm90aGluZyBh dAphbGwgKGJlaW5nIGEgdGF1dG9sb2d5KSBvciBlbHNlIHNvbWV0aGluZyBJIGRvbid0IGdldC4K SSB0aGluayBpdCdzIHRoZSBmb3JtZXIsIGJ1dCBhbSBub3Qgc3VyZS4KCi0gMy4xOiBzL09uZSBt ZWNoYW5pc20gc3VjaCBtZWNoYW5pc20vT25lIHN1Y2gKbWVjaGFuaXNtLyBJIGd1ZXNzLiBBbmQg aXQncyBub3QgYXQgYWxsIGNsZWFyIHRvIG1lCiJBQUEgcHJvdG9jb2xzIiBpcyB0aGUgcmlnaHQg aWRlYSB0aGVyZSwgYW5kIG5vciBpcyBpdApjbGVhciB3aGF0J3MgbWVhbnQsIHdpdGggdGhlIHRl eHQgYXMtaXMuCgotIFNFQy1SRVEtMDY6IHdoZXJlIGlzIGEgInByaW9yaXR5IiBkZWZpbmVkPwoK LSBTRUMtUkVRLTA3OiBoZXJlIHlvdSBzYXkgcmVhZC93cml0ZSBpcyBhIHRyYW5zYWN0aW9uLApi dXQgZWFybGllciB5b3Ugc2FpZCBpdCB3YXMgYW4gb3BlcmF0aW9uLCB3aGljaCBpcyBpdD8KCihk aXNjdXNzOSkgMy4yOiBBcyB3aXRoIG90aGVycywgSSBkb24ndCB0aGluayB0aGUgaWRlYQpvZiBh bm5vdGF0aW5nIHBhcnRzIG9mIHlhbmcgbW9kdWxlcyB3aXRoICJjYW4gYmUKaW5zZWN1cmUiIGlz IGEgZ29vZCBvbmUuIFRoZXJlJ3MgYSBzZXBhcmF0ZSB0aHJlYWQKZGlzY3Vzc2luZyB0aGF0IHRo b3VnaCwgc28gbWF5YmUgYmV0dGVyIHRvIG5vdCBmb3JrCnRoYXQuIAoKKGRpc2N1c3MxMCkgLSBT RUMtUkVRLU85OiBJIGhhdGUgdG8gZG8gdGhpcyB0byB5YSwgYnV0CkJDUDEwNyBpcyBJTU8gYSBm YWlybHkgY2xlYXIgZmFpbHVyZSB3aGVuIGl0IGNvbWVzIHRvCnJvdXRpbmcuIEFuZCB5ZXQgYWdh aW4gdGhlIGV4Y2VwdGlvbnMgY2xhdXNlcyBoZXJlIGFyZQpzbyBicm9hZCBhcyB0byBiZSBtZWFu aW5nbGVzcyAoZS5nLiBjb25zaWRlcmVkIGxvdwp2YWx1ZSBieSB3aG9tPykuIFdoYXQgaXMgdGhl IHJlYWwgZ29hbCBoZXJlPyAob3RoZXIKdGhhbiBhbiBhdHRlbXB0IHRvIGtlZXAgdGhlIHNlYyBB RHMgZnJvbSBiZWluZyBhbm5veWluZwphbmQgdHJ5aW5nIHRvIGluc2lzdCBvbiBCQ1AxMDc/IDst KSAKCihkaXNjdXNzMTEpIC0gU0VDLVJFUS0wOTogU2VwYXJhdGVseSwgdG8gbXkgb3RoZXIKd291 bGQtYmUtZGlzY3VzcyBwb2ludCBvbiB0aGlzIHJlcXVpcmVtZW50LCAiY2FuCmd1YXJhbnRlZSIg aXMgd2VsbCBiZXlvbmQgdGhlIHN0YXRlIG9mIHRoZSBhcnQgaW4ga2V5Cm1hbmFnZW1lbnQuIEkn ZCBqdXN0IGRyb3AgdGhhdCBzZW50ZW5jZSBtYXliZSwgYnV0CmNhbid0IG1ha2UgYSBjb25jcmV0 ZSBzdWdnZXN0aW9uIHVudGlsIEkgdW5kZXJzdGFuZAp3aGVyZSB5b3Ugd2FudCB0byBiZSB3cnQg QkNQMTA3LgoKLSBTRUMtUkVRLTEwOiB0aGUgbGFzdCBzZW50ZW5jZSBoZXJlIGlzIGFsc28gaW52 b2x2ZWQKaW4gdGhlICJtYXkgZG8gc3R1ZmYgaW5zZWN1cmVseSIgdGhpbmcsIGFuZCBzbyB3aWxs Cmxpa2VseSBuZWVkIGZpeGluZyB3aGVuIHRoYXQgaXMgZnVsbHkgcmVzb2x2ZWQuCgotIEhvdyBp cyBTRUMtUkVRLTExIHVzZWZ1bD8gV2hhdCBwcm90b2NvbCBhcnRlZmFjdHMgZG8KeW91IGhhdmUg aW4gbWluZCBoZXJlPyBQZXJoYXBzIGEgcmVxdWlyZW1lbnQgdGhhdCBERG9TCmF0dGFja3MgYmUg c3BlY2lmaWNhbGx5IGNvbnNpZGVyZWQgaW4gSTJSUyB3b3VsZCBiZQptb3JlIHVzZWZ1bC4KCi0g U0VDLVJFUS0xMjogVGhpcyBzZWVtcyB0byBtZSB0byBoYXZlIHRvbyBtYW55IHdvcmRzLAplLmcu IHRoZSBjdXJyZW50IHRleHQgY291bGQgYmUgcmVhZCB0byBpbXBseSB0aGF0Cm91dHNpZGUgb2Yg Y3JpdGljYWwgaW5mcmFzdHJ1Y3R1cmUgdGhlcmUgaXMgbGVzcyBvciBubwpuZWVkIGZvciBjb25m aWRlbnRpYWxpdHksIHNvIHRob3NlIGFkZGVkIHdvcmRzCihwcmVzdW1hYmx5IHRoZXJlIHRvIG1v dGl2YXRlKSBtaWdodCBiZQpjb3VudGVyLXByb2R1Y3RpdmUuIAoKKGRpc2N1c3MxMikgU0VDLVJF US0xMjogSSBkb24ndCBnZXQgdGhlIG1lYW5pbmcgb2YgdGhlClNIT1VMRCBoZXJlIC0gY29tYmlu ZWQgd2l0aCAiY2VydGFpbiBkYXRhIiB0aGF0IFNIT1VMRApzZWVtcyB0byBlbmQgdXAgbWVhbmlu ZyBNQVksIGFzIGluLCBpdCBzZWVtcyB0byBtZWFuCnRoZSBzYW1lIGFzICJSZWFkL3dyaXRlIG9w ZXJhdGlvbnMgTUFZIGhhdmUgdG8gYmUKcHJvdGVjdGVkIHVzaW5nIGEgY29uZmlkZW50aWFsaXR5 IHNlcnZpY2UuIgoKLSAzLjQsIGJ1bGxldCAoMikgaGVyZSBtZWFucyB0aGF0IHdlJ3JlIG5vdCB0 YWxraW5nCmFib3V0IGRhdGEgaW50ZWdyaXR5IGJ1dCBkYXRhIG9yaWdpbiBhdXRoZW50aWNhdGlv bgphcyB3ZWxsLgoKKGRpc2N1c3MxMykgMy40LCAoMyk6IFdpdGhpbiB3aGF0IHNjb3BlIG11c3Qg cmVwbGF5IGJlCmRldGVjdGVkPyBUaGUgdGV4dCBpbXBsaWVzIGZvciBldmVyLCB3aGljaCBjYW4g YmUgdmVyeQpvbmVyb3VzLiBTRUMtUkVRLTE0IGRvZXNuJ3QgcXVpdGUgZ28gc28gZmFyLCBidXQg aXMKYW1iaWd1b3VzIG9uIHRoaXMgYXNwZWN0LiBJJ2Qgc2F5IGJlc3QgaXMgdG8gbm90ZSB0aGF0 CnRoZSBzY29wZSB3aXRoaW4gd2hpY2ggcmVwbGF5IG5lZWRzIHRvIGJlIGRldGVjdGFibGUgaXMK Zm9yIGZ1dHVyZSBzdHVkeS4gCgooZGlzY3VzczE0KSBTRUMtUkVRLTE1OiBTb3JyeSwgSSBkb24n dCB1bmRlcnN0YW5kCndoYXQncyByZXF1aXJlZCBoZXJlIChoYXZpbmcgcmVhZCB0aGlzID4xIHRp bWUpLiBDYW4KeW91IGV4cGxhaW4/wqAgSSdtIG5vdCBzdXJlIGlmIGFueSBzdWJzdGFudGl2ZSBj aGFuZ2UgaXMKbmVlZGVkLCBidXQgdGhlcmUgYXJlIGNlcnRhaW5seSBlZGl0b3JpYWwgY2hhbmdl cwpuZWVkZWQgZm9yIHN1cmUgYXMgdGhlcmUgYXJlIG11bHRpcGxlIHdvcmRpbmcgcHJvYmxlbXMK d2l0aCB0aGUgdGV4dCBhcy1pcy4KCi0gMy41LCAxc3QgcGFyYTogdGhlIHRleHQgaGVyZSBpcyBu b3QgYXMgZ29vZCBhcyAKdGhlIGFjdHVhbCBkZWZpbml0aW9uIG9mICJyb2xlIiBpbiBSRkM3OTIx LCBhbmQgaW4KZmFjdCBJIGZvdW5kIHRoZSB0ZXh0IGhlcmUgY29uZnVzaW5nLiBCZXR0ZXIgdG8K anVzdCBkZWxldGUgdGhhdCBhbmQgc2F5IHRoYXQgNzkyMSBkZWZpbmVzIHJvbGVzLiAKCihkaXNj dXNzMTUpIFNFQy1SRVEtMTY6IEkgZG9uJ3Qgc2VlIGFueSBjb250ZW50IGluIHRoaXMKdGV4dCBh cyBpdCBzZWVtcyB0byBqdXN0IHNheSAic29tZSByb2xlIGJhc2VkIGFjY2Vzcwpjb250cm9sIGFu ZCBzb21lIGxldmVsIG9mIHRyYW5zcG9ydCBwcm90ZWN0aW9uIG5lZWQgdG8KYmUgcHJvdmlkZWQi IHdoaWNoIGlzIGFsd2F5cyB0cnVlLCBhcyB5b3UgYXJlIGFsbG93aW5nCiJubyB0cmFuc3BvcnQg c2VjdXJpdHkiIGFuZCAoSSBhc3N1bWUpICJmdWxseSBwdWJsaWMKYWNjZXNzIiBzbyBhbnkgcHJv dG9jb2wvc3lzdGVtIHdpbGwgYWx3YXlzIG1lZXQgdGhpcwpyZXF1aXJlbWVudC4KCi0gU0VDLVJF US0xNjogInByaXZhY3kgcmVxdWlyZW1lbnRzIiBoZXJlIGlzIHdyb25nLAp5b3UgbWVhbiBjb25m aWRlbnRpYWxpdHkgSSB0aGluay4KCihkaXNjdXNzMTYpIFNFQy1SRVEtMTc6ICJNVVNUIHdvcmsi IGlzIGZhciB0b28gdmFndWUuClRoYXQgY291bGQgZm9yIGV4YW1wbGUgaGlkZSBhIG1ham9yIGRl YmF0ZSBhYm91dCBwdXNoCnYuIHB1bGwgb2Ygcm9sZSBpbmZvcm1hdGlvbi4gSWYgdGhlIFdHIGhh dmVuJ3QKY29uc2lkZXJlZCB0aGF0LCBJIHRoaW5rIHlvdSBjb3VsZCBhY2sgdGhhdCBhZ2FpbiBi eQpzYXlpbmcgdGhhdCBtb3JlIHdvcmsgaXMgbmVlZGVkIHRvIGRlZmluZSBob3cgUkJBQyBpcwpj b25zaXN0ZW50IGFjcm9zcyBtdWx0aXBsZSB0cmFuc3BvcnQgbGF5ZXIgY29ubmVjdGlvbnMuCgoo ZGlzY3VzczE3KSBTRUMtUkVRLTE4OiBhZ2FpbiB0aGlzIHNlZW1zIHRvIGhhdmUgbm8KY29udGVu dCwgb3RoZXIgdGhhbiBwZXJoYXBzIGltcG9zaW5nIGFuIG9kZCByZXF1aXJlbWVudApvbiBpbXBs ZW1lbnRhdGlvbnMgLSBJIGRvbid0IHNlZSBhIHByb3RvY29sIHJlcXVpcmVtZW50CmhlcmUgYXQg YWxsLiBJdCBpcyByZWFzb25hYmxlIHRvIG5vdGUgdGhhdCBsaWJyYXJpZXMKZm9yIGNsaWVudHMg b3VnaHQgbm90IGFzc3VtZSBhIHNpbmdsZSBjbGllbnQgaWRlbnRpdHkKYnV0IGV2ZW4gdGhhdCdz IHZlcnkgc3BlY2lmaWMgdG8gbGlicmFyeQppbXBsZW1lbnRhdGlvbnMgYW5kIHNpbmNlIGl0J3Mg anVzdCBhIE1BWSB0aGF0J3MKZW50aXJlbHkgb2J2aW91cywgSSdkIGxlYXZlIGl0IG91dC4KCihk aXNjdXNzMTgpIFNFQy1SRVEtMTk6IEkgZnVsbHkgYWdyZWUgd2l0aCB0aGUKbW90aXZhdGlvbiBo ZXJlIGJ1dCBJIHRoaW5rIHRoZSBzdGF0ZWQgcmVxdWlyZW1lbnQgaXMKYnJva2VuLsKgIEZvciBl eGFtcGxlLCBJIGRvbid0IGtub3cgaG93IGEgcGllY2Ugb2Ygcy93CndpbGwgZGV0ZXJtaW5lIHdo ZXRoZXIgb3Igbm90IGl0IGlzIGNvcnJlbGF0ZWQgd2l0aCBhCnBlcnNvbi4gSSBhbHNvIGRvbid0 IHRoaW5rIGEgU0hPVUxEIHdvcmtzIGhlcmUsIGFzCmFnYWluIHNvbWV0aGluZyB3b3VsZCBuZWVk IHRvIGJlIHN0YXRlZCBhYm91dCB0aGUKc2l0dWF0aW9ucyB3aGVuIHRoZSBmZWF0dXJlIGlzIG5v dCBuZWVkZWQsIGFuZCBJIGNhbid0CmZpZ3VyZSBvdXQgYSBzZW5zaWJsZSBzdGF0ZW1lbnQgZm9y IHRoYXQuIFRoZSBsYXN0CnNlbnRlbmNlIGFsc28gc2VlbXMgbGlrZWx5IG5vdCB1c2VmdWwuIEFs bCBpbiBhbGwsIEkKdGhpbmsgdGhpcyBpcyBsaWtlbHkgdG8gYmUgaWdub3JlZCBvciBldmVuIHdv cnNlCnRyZWF0ZWQgbGlrZSBhIHBpZWNlIG9mIGZpZy1sZWFmIHNwZWNpZmljYXRpb24gdGV4dCB0 bwpwcmV0ZW5kIHRoYXQgd2UncmUgY2FyaW5nIGFib3V0IHByaXZhY3kuCgooZGlzY3VzczE5KSAt IDMuNjogSSBoYXZlIG5vIGlkZWEgd2hldGhlciB0aGlzIG90aGVyCmRyYWZ0IGlzIHN1cHBvc2Vk IHRvIGJlIGNvbnNpZGVyZWQgYXMgc2V0dGluZwpyZXF1aXJlbWVudHMgb3Igbm90LiBJIGFzc3Vt ZSB0aGF0IHRoZSBhbnN3ZXIgaXMgIm5vdCIKYXMgeW91J3ZlIG1hZGUgaXQgYW4gaW5mb3JtYXRp dmUgcmVmZXJlbmNlLCBidXQgaW4gdGhhdApjYXNlIHlvdSByZWFsbHkgc2hvdWxkIHNheSB0aGF0 LsKgIFRoZSBhbHRlcm5hdGl2ZSB3b3VsZApiZSB0aGF0IDMuNiBpcyBlc3NlbnRpYWxseSBzcGVj aWZ5aW5nIGFuIGFwcGxpY2FiaWxpdHkKc3RhdGVtZW50IGZvciB0aGUgZW52aXJvbm1lbnRzIGlu IHdoaWNoIGl0IGlzLCBhbmQgaXMKbm90LCBvayB0byBydW4gaTJycy4gSWYgdGhlIGxhdHRlciB3 ZXJlIGludGVuZGVkLCB0aGVuCnlvdSdkIG5lZWQgdG8gc2F5IGl0IGFuZCBtYWtlIHRoZSBkcmFm dCBhIG5vcm1hdGl2ZQpyZWZlcmVuY2UuCgoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18KaTJycyBtYWlsaW5nIGxpc3QKaTJyc0BpZXRmLm9yZwpodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2kycnMK ----_com.samsung.android.email_100536710520980 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 PGh0bWw+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0 L2h0bWw7IGNoYXJzZXQ9VVRGLTgiPjwvaGVhZD48Ym9keT48ZGl2PlN0ZXBoZW46PC9kaXY+PGRp dj48YnI+PC9kaXY+PGRpdj5UaGFuayB5b3UgZm9yIGxlYXZpbmcgeW91ciB2YWNhdGlvbiBlYXJs eSB0byBkbyB0aGlzIHJldmlldy4gJm5ic3A7SXQgaXMgb25lIG9mIHRoZSBtb3N0IG5lZ2F0aXZl IHZpZXdwb2ludCBJIGhhdmUgcmVhZCBmcm9tIHlvdSwgYW5kIHNpbmNlICZuYnNwO2hhdmUgcmVh ZCBtYW55IG9mIHlvdXIgRElTQ1VTUyBjb21tZW50cyBzaW5jZSB5b3UgYmVjYW1lIGFuIEFEIC0g SSB0aGluayB0aGlzIGdpdmVzIG1lIHVuaXF1ZSBwZXJzcGVjdGl2ZS4gJm5ic3A7VGhpcyBpcyBm YXIgZnJvbSB0aGUgZWFybHkgY29tbWVudHMgeW91IHNlbnQgMiB3ZWVrcyBhZ28uPC9kaXY+PGRp dj48YnI+PC9kaXY+PGRpdj5JbiBkZXZlbG9waW5nIHRoaXMgZG9jdW1lbnQgYW5kIEkyUlMgdGVj aG5vbG9neSB0aGUgSTJSUyBXRyBhbmQgSSBhcyB0aGUgSTJSUyBjaGFpciBoYXZlIHJlcXVlc3Qg cmV2aWV3cyBmcm9tIHRoZSBTZWN1cml0eSBkaXJlY3RvcmF0ZS4gJm5ic3A7V2UgZGVsYXllZCBv dXQgZmlyc3QgcmV2aXNpb25zIHRvIHRyeSB0byBhZGRyZXNzIHNlY3VyaXR5IGlzc3VlIGJ5IGFk ZGluZyB0aGlzIGRvY3VtZW50IGFuZCB0aGUgc2VjdXJpdHkgZW52aXJvbm1lbnQgZG9jdW1lbnQu ICZuYnNwO1dlIGhhdmUgaGFkIGVhcmx5IGFuZCBsYXRlIHJldmlld3MuICZuYnNwO1NpbmNlIHRo ZSBpbml0aWFsIHJldmlldyBvbiB0aGUgSTJSUyBhcmNoaXRlY3R1cmUgd2UgaGF2ZSBkaXNjdXNz ZWQgdGhlIG5vbi1zZWN1cmUgaW50ZXJmYWNlIGFuZCB0cmllZCB0byBnZXQgc2VjdXJpdHkgZGly ZWN0b3JhdGUncyByZXZpZXcuICZuYnNwO0kgcmFpc2VkIHRoZSBwZXJ2YXNpdmUgcHJpdmFjeSBp c3N1ZSBhbmQgYXNrZWQgZm9yIGlucHV0IGluIHlvdXIgcmV2aWV3LjwvZGl2PjxkaXY+PGJyPjwv ZGl2PjxkaXY+VGhpcyBtZXRhLWNvbW1lbnQgaXMgdGhhdCBwcm9jZXNzIG9mIGFza2luZyBmb3Ig YWlkIGFoZWFkIG9mIHRoaXMgcG9pbnQgaGFzIGZhaWxlZCBhY2NvcmRpbmcgdG8geW91ciByZXZp ZXcsIGJ1dCBJIGNhbm5vdCBmaW5kIGEgcG9pbnQgd2hlcmUgdGhlIEkyUlMgV0cgZGlkIG5vdCBz b2xpY2l0IHRoZSBzZWN1cml0eSBhcmVhJ3MgYWlkIGFuZCB0YWtlIGl0cyBhZHZpY2UuICZuYnNw O1RoZXJlZm9yZSwgJm5ic3A7SSBtdXN0IGFzayB5b3UgdG8gY2hlY2sgdGhlIHByb2Nlc3Mgb2Yg eW91ciBzZWN1cml0eSBkaXJlY3RvcmF0ZSdzIHJldmlld3MgdG8gZmluZCB3aGF0IGhhcHBlbmVk IHRvIGNhdXNlIHN1Y2ggYSBmYWlsdXJlLjwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXY+Tm93IGFz IHRvIHRoZSBkb2N1bWVudCwgSSBoYXZlIGEgV0cgd2FpdGluZyBmb3IgdGhlc2UgcmVxdWlyZW1l bnRzLiAmbmJzcDtJIHdvdWxkIGxpa2UgdG8gaGVhciBpbiBhIGNvbXBsZXRlbHkgc2VwYXJhdGUg ZW1haWwgdGhyZWFkIHdoYXQga2VybmVsIG9mIGluZm9ybWF0aW9uIHlvdSB3b3VsZCBoYXZlIGV4 cGVjdGVkIHJlZ2FyZGluZyB0aGUgc2VjdXJpdHkgZmlyc3QgYW4gaTJycyBwcm90b2NvbC4gJm5i c3A7SSB3b3VsZCB0aGVuIGxpa2UgdG8gY29tcGFyZSB0aGlzIGFnYWluc3QgdGhlIHNlY3VyaXR5 IGRpcmVjdG9yYXRlJ3Mgc3VnZ2VzdGlvbnMgb24gdGhpcyBkb2N1bWVudC4gJm5ic3A7V2UgaGF2 ZSBhIHNlY29uZCBkb2N1bWVudCBvbiB0aGUgc2VjdXJpdHkgZW52aXJvbm1lbnQgc28geW91ciBp bnNpZ2h0cyB3aWxsIGJlIGFwcGxpZWQgdG8gdGhhdCBkb2N1bWVudC48L2Rpdj48ZGl2Pjxicj48 L2Rpdj48ZGl2PlNpbmNlIGluIHRoZSBnZW5lcmFsIHRleHQgeW91IGluZGljYXRlIHRoZSBzdHls ZSBpcyB0ZXJyaWJsZSBhbmQgbmVlZHMgdG8gYmUgd3JpdHRlbiwgcGxlYXNlIHByb3ZpZGUgYW4g ZXhhbXBsZSBvZiBhIGRvY3VtZW50IGFzIGFuIGV4YW1wbGUgb2YgdGhlIHN0eWxlLiAmbmJzcDtN eSB1bmRlcnN0YW5kaW5nIGlzIHRoYXQgc3R5bGUgaXMgYSBsb3dlciBwcmlvcml0eSB0aGFuIHRl Y2huaWNhbCBjb3JyZWN0bmVzcyBhbmQgY29uc2Vuc3VzLjwvZGl2PjxkaXY+PGJyPjwvZGl2Pjxk aXY+VGhpcyBlbWFpbCBlbmRzIG15IGNvbW1lbnRzIG9uIHlvdXIgc3VtbWFyeSBtZXNzYWdlLiAm bmJzcDtUaGUgbmV4dCBzZXQgb2YgY29tbWVudHMgd2lsbCB0YWtlIHlvdXIgZGlzY3VzcyBjb21t ZW50cyBvbmUgYXQgYSB0aW1lLiAmbmJzcDs8L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2PlRoZSBl eGFjdCBuZXh0IHN0ZXBzIHRoYXQgSSBhbmQgbXkgY28tYXV0aG9yIHdpbGwgdGFrZSB3aWxsIGJl IGd1aWRlZCBieSB0aGUgQUQgcmVzcG9uc2libGUgZm9yIHRoZSBJMlJTIFdHLCBBbGlhLiAmbmJz cDs8L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2PkNoZWVyaWx5LCAmbmJzcDs8L2Rpdj48ZGl2PlN1 ZSBIYXJlczwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXYgaWQ9ImNvbXBv c2VyX3NpZ25hdHVyZSI+PGRpdiBzdHlsZT0iZm9udC1zaXplOjg1JTtjb2xvcjojNTc1NzU3IiBk aXI9ImF1dG8iPlNlbnQgdmlhIHRoZSBTYW1zdW5nIEdhbGF4eSBOb3RlNSwgYW4gQVQmYW1wO1Qg NEcgTFRFIHNtYXJ0cGhvbmU8L2Rpdj48L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2IHN0eWxlPSJm b250LXNpemU6MTAwJTtjb2xvcjojMDAwMDAwIj48IS0tIG9yaWdpbmFsTWVzc2FnZSAtLT48ZGl2 Pi0tLS0tLS0tIE9yaWdpbmFsIG1lc3NhZ2UgLS0tLS0tLS08L2Rpdj48ZGl2PkZyb206IFN0ZXBo ZW4gRmFycmVsbCAmbHQ7c3RlcGhlbi5mYXJyZWxsQGNzLnRjZC5pZSZndDsgPC9kaXY+PGRpdj5E YXRlOiA4LzIxLzE2ICA4OjM3IEFNICAoR01ULTA1OjAwKSA8L2Rpdj48ZGl2PlRvOiBUaGUgSUVT RyAmbHQ7aWVzZ0BpZXRmLm9yZyZndDsgPC9kaXY+PGRpdj5DYzogamhhYXNAcGZyYy5vcmcsIGky cnNAaWV0Zi5vcmcsIGkycnMtY2hhaXJzQGlldGYub3JnLCBkcmFmdC1pZXRmLWkycnMtcHJvdG9j b2wtc2VjdXJpdHktcmVxdWlyZW1lbnRzQGlldGYub3JnIDwvZGl2PjxkaXY+U3ViamVjdDogW2ky cnNdIFN0ZXBoZW4gRmFycmVsbCdzIEFic3RhaW4gb24KICBkcmFmdC1pZXRmLWkycnMtcHJvdG9j b2wtc2VjdXJpdHktcmVxdWlyZW1lbnRzLTA5OiAod2l0aCBDT01NRU5UKSA8L2Rpdj48ZGl2Pjxi cj48L2Rpdj48L2Rpdj5TdGVwaGVuIEZhcnJlbGwgaGFzIGVudGVyZWQgdGhlIGZvbGxvd2luZyBi YWxsb3QgcG9zaXRpb24gZm9yPGJyPmRyYWZ0LWlldGYtaTJycy1wcm90b2NvbC1zZWN1cml0eS1y ZXF1aXJlbWVudHMtMDk6IEFic3RhaW48YnI+PGJyPldoZW4gcmVzcG9uZGluZywgcGxlYXNlIGtl ZXAgdGhlIHN1YmplY3QgbGluZSBpbnRhY3QgYW5kIHJlcGx5IHRvIGFsbDxicj5lbWFpbCBhZGRy ZXNzZXMgaW5jbHVkZWQgaW4gdGhlIFRvIGFuZCBDQyBsaW5lcy4gKEZlZWwgZnJlZSB0byBjdXQg dGhpczxicj5pbnRyb2R1Y3RvcnkgcGFyYWdyYXBoLCBob3dldmVyLik8YnI+PGJyPjxicj5QbGVh c2UgcmVmZXIgdG8gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvaWVzZy9zdGF0ZW1lbnQvZGlzY3Vzcy1j cml0ZXJpYS5odG1sPGJyPmZvciBtb3JlIGluZm9ybWF0aW9uIGFib3V0IElFU0cgRElTQ1VTUyBh bmQgQ09NTUVOVCBwb3NpdGlvbnMuPGJyPjxicj48YnI+VGhlIGRvY3VtZW50LCBhbG9uZyB3aXRo IG90aGVyIGJhbGxvdCBwb3NpdGlvbnMsIGNhbiBiZSBmb3VuZCBoZXJlOjxicj5odHRwczovL2Rh dGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLWkycnMtcHJvdG9jb2wtc2VjdXJpdHkt cmVxdWlyZW1lbnRzLzxicj48YnI+PGJyPjxicj4tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPGJyPkNPTU1FTlQ6PGJy Pi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS08YnI+PGJyPjxicj5GaXJzdCwgYXBvbG9naWVzIGZvciBub3QgZ2V0dGlu ZyBteSByZXZpZXcgZG9uZSBmb3I8YnI+dGhpcyB3aGVuIGl0IHdhcyBzY2hlZHVsZWQgZHVlIHRv IG15IHZhY2F0aW9uIGFuZDxicj50aGFua3MgZm9yIGJlaW5nIHdpbGxpbmcgdG8gZGVmZXIgdGhl IGRvY3VtZW50Ljxicj48YnI+U2Vjb25kLCBoYXZpbmcgbm93IHByb3Blcmx5IHJldmlld2VkIHRo aXMsIEkgYW08YnI+YmFsbG90aW5nIGFic3RhaW4gYXMgSSB0aGluayBpdCdzIHVubGlrZWx5IHRo YXQgdGhpczxicj5kb2N1bWVudCBjYW4gYmUgZml4ZWQgaW4gYSB3YXkgdGhhdCByZXN1bHRzIGlu PGJyPnNvbWV0aGluZyB1c2VmdWwgaGFwcGVuaW5nLiBJIHRoaW5rIHRoYXQgdGhlIGxpa2VseTxi cj5vdXRjb21lIGlzIHRoYXQgdGhpcyBkb2N1bWVudCB3aWxsIGJlIHVzZWQgbGF0ZXIgd2hlbjxi cj5wZW9wbGUgYXJlIGFyZ3VpbmcgYW5kIHdpbGwgbm90IG11Y2ggaGVscCBpbiByZXNvbHZpbmc8 YnI+dGhvc2UgYXJndW1lbnRzLCBvciBlbHNlIHRoaXMgd2lsbCBiZSBpZ25vcmVkIGFuZDxicj5h cmd1bWVudHMgd2lsbCBiZSBoZWxkIGFmcmVzaCwgYXMgbmVlZGVkLiBUaGF0IGxhdHRlcjxicj5v dXRjb21lIGlzIHdoYXQgSSdkIGd1ZXNzIGlzIG1vc3QgbGlrZWx5IGFuZCB0aGVyZWZvcmU8YnI+ aXQgc2VlbXMgdGhhdCBzcGVuZGluZyBhbGwgb2Ygb3VyIGN5Y2xlcyBvbiBESVNDVVNTPGJyPmJh bGxvdCBwcm9jZXNzaW5nIGZvciB0aGlzIHdvdWxkIG5vdCBiZSB3aXNlLiBUaGF0PGJyPnNhaWQs IEkgYW0gd2lsbGluZyB0byBjaGFuZ2UgdG8gYSBESVNDVVNTIGJhbGxvdCBpZiB0aGU8YnI+cmVz cG9uc2libGUgQUQgcHJlZmVycyB0aGF0LCBidXQgSSBzdXNwZWN0IEknbGwgZW5kIHVwPGJyPndp dGggYW4gYWJzdGFpbiBpbiBhbnkgY2FzZSwgYWZ0ZXIgc29tZSBkaXNjdXNzaW9uLiBUaGU8YnI+ b25seSBwbGFuIEkgY2FuIHRoaW5rIG9mIHRoYXQnZCBsZWFkIHRvIG1lIGVuZGluZyB1cDxicj53 aXRoIGEgeWVzIG9yIG5vLW9iamVjdGlvbiBiYWxsb3Qgd291bGQgYmUgaWYgdGhpcyB3YXM8YnI+ cmV0dXJuZWQgdG8gdGhlIFdHIGZvciBmaXhpbmcgYW5kIHBvc3NpYmx5IG1ham9yPGJyPnN1cmdl cnksIHdoaWNoIGlzIHdoYXQgSSBhY3R1YWxseSB0aGluayB3b3VsZCBiZSB0aGU8YnI+YmVzdCBw bGFuLiAoSSByZWFsaXNlIHRoaXMgaGFzIGhhZCBhIHNvbWV3aGF0IHRvcnR1cmVkPGJyPmhpc3Rv cnksIHNvIGZvbGtzIG1heSBub3QgYmUgd2lsbGluZyB0byB0YWtlIGl0IGJhY2sgdG88YnI+dGhl IFdHLCBidXQgaG9uZXN0bHksIEkgdGhpbmsgdGhlIGZhaWxpbmdzIHZpc2libGUgaW48YnI+dGhp cyBkb2N1bWVudCBkbyBpbmRpY2F0ZSB0aGF0IHRoaXMgaXMgbm90IHJlYWR5IGZvcjxicj5hcHBy b3ZhbCBhbmQgb3VnaHQgYmUgcmV0dXJuZWQgdG8gdGhlIFdHLik8YnI+PGJyPlRoaXJkLCBJIHRo aW5rIHRoZSBvdmVyYWxsIHNldCBvZiByZXF1aXJlbWVudHMgcG9zZWQ8YnI+aGVyZSBtaWdodCAo d2l0aCBzb21lIHVua25vd24gcHJvYmFiaWxpdHkpIGxlYWQgdG88YnI+bGF0ZXIgc3BlY2lmaWNh dGlvbnMgdGhhdCBhcmUgY29uc2lkZXJlZCB0b28gaGFyZCB0bzxicj5kZXBsb3ksIHdpdGggdGhl IHJlc3VsdCB0aGF0IG5vbi1zZWN1cmUgdmFyaWFudHMgb2Y8YnI+STJSUyBiZWNvbWUgdGhlIG5v cm0uIFRoYXQgc2VlbXMgbGlrZSBpdCB3b3VsZCBiZSBhPGJyPnJlYWxseSBiYWQgb3V0Y29tZS4g SSB3b3VsZCBzdWdnZXN0IHRoYXQgbWlnaHQgYmU8YnI+cGFydGx5IG1pdGlnYXRlZCBpZiBhIHJl cXVpcmVtZW50IHdlcmUgYWRkZWQgdG8gdGhlPGJyPmVmZmVjdCB0aGF0IGRlcGxveW1lbnQgaXNz dWVzIGFuZCBzcGVjaWZpY2FsbHkgZWFzZSBvZjxicj5kZXBsb3ltZW50IE1VU1QgYmUgY29uc2lk ZXJlZCBhcyBhIGZpcnN0IG9yZGVyPGJyPnJlcXVpcmVtZW50IHdoZW4gZGV2ZWxvcGluZyBJMlJT IHByb3RvY29sIHNvbHV0aW9ucy4gPGJyPjxicj5Gb3VydGgsIHRoZSAoMTkhKSBjb21tZW50cyBi ZWxvdyB0aGF0IGFyZSBwcmVjZWRlZCBieTxicj4iKGRpc2N1c3MiIHdvdWxkIGhhdmUgYmVlbiBE SVNDVVNTIGJhbGxvdCBwb2ludHMgaGFkIEk8YnI+bm90IGRlY2lkZWQgdG8gYWJzdGFpbi4gSSBh bSBoYXBweSB0byBjaGF0IGFib3V0IGFueSBvZjxicj5teSBjb21tZW50cyBiZWxvdywgYnV0IGlm IHRoZSBhdXRob3JzL1dHIGRvIHdhbnQgdG88YnI+Y2hhdCwgaXQgbWlnaHQgYmUgbW9yZSBlZmZp Y2llbnQgdG8gY29uY2VudHJhdGUgb248YnI+dGhvc2UgdGhhdCB3b3VsZCBvdGhlcndpc2UgaGF2 ZSBiZWVuIERJU0NVU1MgcG9pbnRzLjxicj4oQnV0IHRoYXQncyB5b3VyIGNhbGwsIEkgZG9uJ3Qg bWluZC4pIEkgdGhpbmsgdGhlIDE5PGJyPndvdWxkLWhhdmUtYmVlbi1kaXNjdXNzIHBvaW50cyBp cyBhbm90aGVyIGNsdWUgdGhhdDxicj50aGlzIG91Z2h0IHJlYWxseSBiZSBzZW50IGJhY2sgdG8g dGhlIFdHLjxicj48YnI+QW5kIHdpdGggdGhhdCwgYW5kIHdpdGggYXBvbG9naWVzIGZvciB0aGlz IGJlaW5nIHN1Y2g8YnI+YW4gb3ZlcmFsbCBuZWdhdGl2ZSByZXZpZXcsIGhlcmUncmUgbXkgZGV0 YWlsZWQ8YnI+Y29tbWVudHM6PGJyPjxicj4tIGdlbmVyYWw6IFRoZSB3cml0aW5nIGhlcmUgaXMg Z2VuZXJhbGx5IHBvb3IsIGZvcjxicj5leGFtcGxlIHRoZSBvcGVuZXIgaXMgIlRoaXMgcHJlc2Vu dHMuLi4iIHdoZXJlYXMgaXQ8YnI+b3VnaHQgYmUgIlRoaXMgZG9jdW1lbnQgcHJlc2VudHMuLi4i IChvcjxicj5zL2RvY3VtZW50L3doYXRldmVyIHlvdSBwcmVmZXIvKS4gU3VjaCBpc3N1ZXMgYXJl PGJyPnJlcGVhdGVkbHkgc2VlbiBhbmQgYWxsIHRoYXQgbWFrZXMgdGhpcyBhIG11Y2ggaGFyZGVy PGJyPnJlYWQgdGhhbiBvdWdodCBiZSB0aGUgY2FzZS4gSSdkIHN0cm9uZ2x5IHJlY29tbWVuZCBh bjxicj5lZGl0b3JpYWwgcGFzcyBmcm9tIHNvbWVvbmUgd2hvIGhhc24ndCBiZWVuIGRvd24gaW4g dGhlPGJyPndlZWRzIHdpdGggdGhpcyB0ZXh0IGZvciBhIHdoaWxlICh3aGljaCBjb3VsZCBiZSBv bmUgb2Y8YnI+dGhlIGF1dGhvcnMsIGlmIG9uZSBvZiB0aGVtIGhhcyBiZWVuIGxlc3MgYWN0aXZl PGJyPnJlY2VudGx5LikgTm90ZSB0aGF0IHRoaXMgaXMgbm90IG9ubHkgKGJ1dCBpczxicj5wcmlt YXJpbHkpIGFuIGVkaXRvcmlhbCBpc3N1ZSAtIHRoZXJlIGFyZSBzb21lIGNhc2VzPGJyPihob3Bl ZnVsbHkgY2FsbGVkIG91dCBiZWxvdykgd2hlcmUgdGhlIHdyaXRpbmcgZG9lczxicj5jcmVhdGUg cmVhbCBhbWJpZ3VpdHkgdGhhdCBtaWdodCBsZWFkIHRvIHJlLW9wZW5pbmcgb2xkPGJyPmFyZ3Vt ZW50cyBsYXRlci48YnI+PGJyPi0gYWJzdHJhY3Q6ICJtdXR1YWwgYXV0aGVudGljYXRpb24sIHRy YW5zcG9ydDxicj5wcm90b2NvbHMsIGRhdGEgdHJhbnNmZXIgYW5kIHRyYW5zYWN0aW9ucyIgZG9u J3Qgc2VlbTxicj50byBtZSB0byBiZSBjb21tZW5zdXJhdGUgdGhpbmdzLCBzbyB0aGUgYWJzdHJh Y3QsIGFzPGJyPndyaXR0ZW4gaXMgdmVyeSB1bmluZm9ybWF0aXZlIGZvciBtZS48YnI+PGJyPi0g aW50cm8gM3JkIHBhcmE6IEknbSByZWFsbHkgbm90IHN1cmUgd2hhdCB5b3UncmU8YnI+dGVsbGlu ZyBtZSBhYm91dCBbSS1ELmlldGYtaTJycy1lcGhlbWVyYWwtc3RhdGVdLiZuYnNwOyAiVGhlPGJy PmRyYWZ0IFtSRkM3OTIyXSIgaXMgb2RkLCB0aGF0IGJlaW5nIG5vIGxvbmdlciBhIGRyYWZ0Ljxi cj5JJ2QgaGF2ZSBleHBlY3RlZCBzdWNoIG5pdHMgd291bGQgaGF2ZSBiZWVuIGZpeGVkIGJ5PGJy Pm5vdyBUQkguIFNhbWUgZm9yIHRoZSBsYXN0IHNlbnRlbmNlLiZuYnNwOyBUaGF0IHBhcmEgbWFr ZXM8YnI+dGhlIGludHJvIHByZXR0eSB1bmNsZWFyIGZvciBtZS48YnI+PGJyPi0gMi4yOiBUaGUg ZGVmaW5pdGlvbiBvZiBoaWdoZXIgbGV2ZWwgcHJvdG9jb2wgc2VlbXM8YnI+bGlrZSBhbiBvZGQg cGxhY2UgdG8gaW50cm9kdWNlIHRoZSBmYWN0IHRoYXQgaTJycyA9PTxicj5uZXRjb25mICsgcmVz dGNvbmYuJm5ic3A7IFRoYXQnZCBiZSBtb3JlIHVzZWZ1bGx5IHNhaWQgaW48YnI+dGhlIGFic3Ry YWN0L2ludHJvIGlmIHRoYXQncyBzb2xpZGx5IGFncmVlZCBieSB0aGUgV0cuPGJyPjxicj4tIDIu MjogVGhpcyBpcyB3cm9uZzogIldoaWxlIGl0IGlzIHBvc3NpYmxlIHRvIGhhdmUgYW48YnI+STJS UyBvcGVyYXRpb24gd2hpY2ggaXMgY29udGFpbmVkIGluIG11bHRpcGxlIEkyUlM8YnI+KEUuZy4m bmJzcDsgd3JpdGUgaW4gbXVsdGlwbGUgbWVzc2FnZXMpLCB0aGlzIGlzIG5vdDxicj5zdXBwb3J0 ZWQgaW4gb3JkZXIgdG8gc2ltcGxpZnkgdGhlIGZpcnN0IHZlcnNpb24gb2Y8YnI+STJSUy4iIFRo ZSByZWFzb24gdGhpcyBpcyB3cm9uZywgaXMgdGhhdCBpdCBpcyBoZXJlPGJyPnRoYXQgeW91IGFy ZSBkZWZpbmluZyB0aGF0IGl0IGlzIG5vdCBwb3NzaWJsZSB0byBoYXZlPGJyPmFuIG9wZXJhdGlv biBpbiBtdWx0aXBsZSBtZXNzYWdlcy4gcy9pdCBpcy9pdCBjb3VsZDxicj5oYXZlIGJlZW4vIHdv dWxkIHdvcmsgbWF5YmUuPGJyPjxicj4tIDIuMjogIiAqJm5ic3A7IFRoZSBJMlJTIGNsaWVudCBp c3N1ZXMgYSByZWFkIHJlcXVlc3QgdG8gYTxicj5JMlJTIGFnZW50LCBhbmQgdGhlIEkyUlMgQWdl bnQgcmVzcG9uZGluZyB0byB0aGUgcmVhZDxicj5yZXF1ZXN0IiBTaG91bGRuJ3QgdGhhdCB1c2Ug cmVzcG9uZCBhbmQgbm90IHJlc3BvbmRpbmc/PGJyPkdpdmVuIHRoYXQgeW91IHNlZW0gdG8gYmUg dHJ5aW5nIHRvIGRlZmluZSB0aGUgc2NvcGUgb2Y8YnI+d2hhdCBpcyBhbmQgaXMgbm90IGEgdHJh bnNhY3Rpb24sIEkgdGhpbmsgYmVpbmcgcHJlY2lzZTxicj53aXRoIHRoZSBsYW5ndWFnZSBpcyBz b21ldGhpbmcgd2VsbCB3b3J0aCBkb2luZy4mbmJzcDsgVGhlPGJyPjJuZCBidWxsZXQgY291bGQg YWxzbyBkbyB3aXRoIGEgcmUtd3JpdGUuPGJyPjxicj4oZGlzY3VzczEpIDIuMjogeW91IHNvcnQt b2YgZGVmaW5lIG1lc3NhZ2VzLDxicj5vcGVyYXRpb25zLCB0cmFuc2FjdGlvbnMgYW5kIGFjdGlv bnMuIE5vbmUgb2YgdGhlPGJyPmRlZmluaXRpb25zIGFyZSB0aGF0IHByZWNpc2UsIGUuZy4gYXJl IHRob3NlIHRoZSBvbmx5PGJyPm9wZXJhdGlvbnMgb3IgZXhhbXBsZXM/IEFuZCB0cmFuc2FjdGlv biBhbmQgYWN0aW9uPGJyPmFyZW4ndCByZWFsbHkgZGVmaW5lZCBhdCBhbGwuIEknbSBub3Qgc3Vy ZSBpZiB0aGF0J3M8YnI+bGlrZWx5IHRvIGJlIGEgcHJvYmxlbSBvciBub3QuIEkgc3VzcGVjdCBp dCB3aWxsIGxhdGVyLDxicj5lLmcuIHdoZW4geW91IGdldCB0byBmaWd1cmluZyBvdXQgdGhlIHNj b3BlIHdpdGhpbjxicj53aGljaCByZXBsYXkgbmVlZHMgdG8gYmUgZGV0ZWN0YWJsZS48YnI+PGJy Pi0gMi4yOiBzL3RyYW5zYXRpb24vdHJhbnNhY3Rpb24vPGJyPjxicj4oZGlzY3VzczIpIC0gMi4y OiAiZGVmaW5lcyBhIHNlY29uZGFyeSBpZGVudGl0eSBhcyB0aGU8YnI+ZW50aXR5IG9mIHNvbWUg bm9uLUkyUlMgZW50aXR5ICIgVGhhdCBjb3VsZCBiZSBhYnVzZWQ8YnI+Zm9yIHRyYWNraW5nIG9m IHZhcmlvdXMga2luZHMgSSB3b3VsZCBndWVzcywgZS5nLiBpZiBhbjxicj5JTUVJIHdlcmUgdXNl ZC4gSSB0aGluayB5b3UgbmVlZCB0byBub3RlIHRoYXQgYW5kPGJyPnNob3VsZCBpbXBvc2Ugc29t ZSByZXF1aXJlbWVudHMgdGhhdCBzdWNoIHNlY29uZGFyeTxicj5pZGVudGlmaWVycyBhcmUgbm90 IHVzZWQgdGh1c2x5IGZvciB0cmFja2luZy4mbmJzcDsgQWxzbyw8YnI+c2hvdWxkIHRoZSBmaXJz dCBvY2N1cnJlbmNlIG9mIGVudGl0eSB0aGVyZSBiZTxicj5pZGVudGl0eT88YnI+PGJyPi0gMywg MXN0IHBhcmE6IHMvVGhlIHNlY3VyaXR5IGZvciB0aGUvVGhlLyAtIHRoZXJlPGJyPmlzbid0IGEg dGhpbmcgY2FsbGVkIHRoZSBzZWN1cml0eSBmb3IgdGhlIGkycnM8YnI+cHJvdG9jb2wuPGJyPjxi cj4oZGlzY3VzczMpIC0gc2VjdGlvbiAzIHNheXMgInRoZSBJMlJTIHByb3RvY29sIHJlcXVpcmVz PGJyPm11dHVhbGx5IGF1dGhlbnRpY2F0ZWQgSTJSUyBjbGllbnRzIGFuZCBJMlJTIGFnZW50czxi cj5jb21tdW5pY2F0aW5nIG92ZXIgYSBzZWN1cmUgdHJhbnNwb3J0LiIgVG8gbWUgdGhhdDxicj5p bXBsaWVzIHRoYXQgc29tZXRoaW5nIGxpa2UgVExTIG9yIFNTSCBpcyBNVFUgd2hpY2g8YnI+c2Vl bXMgdG8gY29udHJhZGljdCByZWNlbnQgZW1haWxzLjxicj48YnI+LSBzZWN0aW9uIDMgc2F5czog IlRoZSBJMlJTIHByb3RvY29sIE1VU1QgYmUgYWJsZSB0bzxicj5wcm92aWRlIGF0b21pY2l0eSBv ZiBhbiBJMlJTIHRyYW5zYWN0aW9uLCBidXQgaXQgaXMgbm90PGJyPnJlcXVpcmVkIHRvIGhhdmUg bXVsdGktbWVzc2FnZSBhdG9taWNpdHkgYW5kIHJvbGwtYmFjazxicj5tZWNoYW5pc20gdHJhbnNh Y3Rpb25zLiZuYnNwOyBNdWx0aXBsZSBtZXNzYWdlcyB0cmFuc2FjdGlvbnM8YnI+bWF5IGJlIGlt cGFjdGVkIGJ5IHRoZSBpbnRlcmRlcGVuZGVuY3kgb2YgZGF0YS4iJm5ic3A7IEk8YnI+ZG9uJ3Qg YmVsaWV2ZSB0aGF0IHRoYXQncyBlYXNpbHkgZW5vdWdoIHVuZGVyc3Rvb2QgdG88YnI+YmUgdXNl ZnVsLiBBbHNvLCB3b3VsZG4ndCBzL011bHRpcGxlIG1lc3NhZ2VzPGJyPnRyYW5zYWN0aW9ucy9N dWx0aXBsZS1tZXNzYWdlIHRyYW5zYWN0aW9ucy8gYmUgbXVjaDxicj5jbGVhcmVyIGlmIHRoYXQn cyB3aGF0J3MgbWVhbnQ/IEFuZCBmaW5hbGx5LCBJIHRoaW5rPGJyPnRoZSBNVVNUIGVtYmVkZGVk IGluIHRoZSBhYm92ZSBpcyBub3QgdGhhdCBncmVhdCBhbjxicj5pZGVhIC0gaXQncyBjbGVhcmVy IElNTyB0byBzZXBhcmF0ZSB0aGUgMjExOSBsYW5ndWFnZTxicj5mcm9tIGludHJvZHVjdG9yeSB0 ZXh0IGluIGRvY3VtZW50cyBsaWtlIHRoaXMuPGJyPjxicj4tIDM6ICJUaGVyZSBhcmUgZGVwZW5k ZW5jaWVzIGluIHNvbWUgb2YgdGhlPGJyPnJlcXVpcmVtZW50cyBiZWxvdyIgd291bGQgYmUgYmV0 dGVyIGFzICJUaGVyZSBhcmU8YnI+aW50ZXItZGVwZW5kZW5jaWVzIGJldHdlZW4gc29tZSBvZiB0 aGUgcmVxdWlyZW1lbnRzPGJyPmJlbG93IiB1bmxlc3MgeW91IG1lYW4gZGVwZW5kZW5jaWVzIG9u IHNvbWUgZXh0ZXJuYWw8YnI+dGhpbmdzLCB3aGljaCBpcyBub3QgY2xlYXIgZnJvbSB0aGUgdGV4 dCBhcy1pcy48YnI+PGJyPihkaXNjdXNzNCkgIiBGb3IgY29uZmlkZW50aWFsaXR5IChzZWN0aW9u IDMuMykgYW5kPGJyPmludGVncml0eSAoc2VjdGlvbiAzLjQpIHRvIGJlIGFjaGlldmVkLCB0aGU8 YnI+Y2xpZW50LWFnZW50IG11c3QgaGF2ZSBtdXR1YWwgYXV0aGVudGljYXRpb24gKHNlY3Rpb248 YnI+My4xKSBhbmQgc2VjdXJlIHRyYW5zcG9ydCAoc2VjdGlvbiAzLjIpLiZuYnNwOyAiIFRoaXMg aXM8YnI+aW5jb3JyZWN0LiBPbmUgY2FuIGhhdmUgY29uZmlkZW50aWFsaXR5IHdpdGhvdXQ8YnI+ YXV0aGVudGljYXRpb24gKHNlZSBSRkM3NDM1KSBzbyB0aGUgdGV4dCBpcyBub3Q8YnI+YWNjdXJh dGUuPGJyPjxicj4tIGNhcGl0YWxpc2F0aW9uIG5lZWRzIGZpeGluZyBpbiB2YXJpb3VzIHBsYWNl cywgZS5nLjxicj5hcm91bmQgdGhlIGVuZCBvZiBwNSwgd2UgZ2V0ICJzZWN1cmUgVHJhbnNwb3J0 IiBhbmQ8YnI+dGhlbiAiSTJSUyBjbGllbnQiIGFuZCAiSTJSUyBBZ2VudCIgaW4gdGhlIHRpdGxl IG9mIDMuMTxicj5JcyBhbnkgb2YgdGhhdCBjYXBpdGFsaXNhdGlvbiBzdXBwb3NlZCB0byBiZTxi cj5zaWduaWZpY2FudD8gRWl0aGVyIHdheSwgZml4aW5nIGl0IG5vdyB3b3VsZCBiZSBnb29kIGFz PGJyPnlvdSdsbCBuZWVkIHRvIGdldCB0aGUgUkZDIGVkaXRvciB0byBkbyBpdCBsYXRlciBpZiB5 b3U8YnI+ZG9uJ3QgKHdoaWNoIHRha2VzIGxvbmdlcikuPGJyPjxicj4oZGlzY3VzczUpIFNFQy1S RVEtMDE6IHdoYXQgaXMgdGhlIHNjb3BlIG9mIHVuaXF1ZW5lc3M8YnI+cmVxdWlyZWQgaGVyZT8g SSBzZWUgbm8gcmVhc29uIHdoeSB0d28gZGlmZmVyZW50IGRhdGE8YnI+Y2VudHJlcyBjYW5ub3Qg cmUtdXNlIGEgY2xpZW50IG9yIGFnZW50IGlkZW50aWZpZXIsIGlmPGJyPnRoZXkgc28gd2lzaC4g SSdkIGJlIGZpbmUgaWYgeW91IHNheSB0aGF0J3MgZm9yIGxhdGVyPGJyPmRlY2lzaW9uLCBidXQg YmVpbmcgc2lsZW50IG9uIHRoZSBtYXR0ZXIgY291bGQgbGVhZCB0bzxicj50cm91YmxlIGxhdGVy IGlmIGRpZmZlcmVudCBmb2xrcyBkZWNpZGUgZGlmZmVyZW50bHkuPGJyPjxicj4oZGlzY3VzczYp IFNFQy1SRVEtMDI6IHRoZSAiTVVTVCB1dGlsaXplIiB0aGVyZSBtZWFuczxicj5NVFUsIHdoaWNo IHdhc24ndCB3aGF0IHlvdSB3YW50ZWQgSSB0aGluazxicj48YnI+KGRpc2N1c3M3KSAtIFNFQy1S RVEtMDM6IGhvdyBpcyAidXBvbiByZWNlaXZpbmcuLi4gTVVTVDxicj5jb25maXJtIiBhIGdvb2Qg Y2hvaWNlPyBBcyBzdGF0ZWQgdGhhdCdkIGJlIGh1Z2VseTxicj5vbmVyb3VzLCBpbXBseWluZyBl LmcuJm5ic3A7IE9DU1AgY2hlY2tzIGZvciBlYWNoIHBhY2tldDxicj5yZWNlaXZlZC4gU2FtZSBw b2ludCBhcHBsaWVzIHRvIFNFQy1SRVEtMDQuPGJyPjxicj4oZGlzY3VzczgpIC0gU0VDLVJFUS0w NTogdGhpcyBlaXRoZXIgbWVhbnMgbm90aGluZyBhdDxicj5hbGwgKGJlaW5nIGEgdGF1dG9sb2d5 KSBvciBlbHNlIHNvbWV0aGluZyBJIGRvbid0IGdldC48YnI+SSB0aGluayBpdCdzIHRoZSBmb3Jt ZXIsIGJ1dCBhbSBub3Qgc3VyZS48YnI+PGJyPi0gMy4xOiBzL09uZSBtZWNoYW5pc20gc3VjaCBt ZWNoYW5pc20vT25lIHN1Y2g8YnI+bWVjaGFuaXNtLyBJIGd1ZXNzLiBBbmQgaXQncyBub3QgYXQg YWxsIGNsZWFyIHRvIG1lPGJyPiJBQUEgcHJvdG9jb2xzIiBpcyB0aGUgcmlnaHQgaWRlYSB0aGVy ZSwgYW5kIG5vciBpcyBpdDxicj5jbGVhciB3aGF0J3MgbWVhbnQsIHdpdGggdGhlIHRleHQgYXMt aXMuPGJyPjxicj4tIFNFQy1SRVEtMDY6IHdoZXJlIGlzIGEgInByaW9yaXR5IiBkZWZpbmVkPzxi cj48YnI+LSBTRUMtUkVRLTA3OiBoZXJlIHlvdSBzYXkgcmVhZC93cml0ZSBpcyBhIHRyYW5zYWN0 aW9uLDxicj5idXQgZWFybGllciB5b3Ugc2FpZCBpdCB3YXMgYW4gb3BlcmF0aW9uLCB3aGljaCBp cyBpdD88YnI+PGJyPihkaXNjdXNzOSkgMy4yOiBBcyB3aXRoIG90aGVycywgSSBkb24ndCB0aGlu ayB0aGUgaWRlYTxicj5vZiBhbm5vdGF0aW5nIHBhcnRzIG9mIHlhbmcgbW9kdWxlcyB3aXRoICJj YW4gYmU8YnI+aW5zZWN1cmUiIGlzIGEgZ29vZCBvbmUuIFRoZXJlJ3MgYSBzZXBhcmF0ZSB0aHJl YWQ8YnI+ZGlzY3Vzc2luZyB0aGF0IHRob3VnaCwgc28gbWF5YmUgYmV0dGVyIHRvIG5vdCBmb3Jr PGJyPnRoYXQuIDxicj48YnI+KGRpc2N1c3MxMCkgLSBTRUMtUkVRLU85OiBJIGhhdGUgdG8gZG8g dGhpcyB0byB5YSwgYnV0PGJyPkJDUDEwNyBpcyBJTU8gYSBmYWlybHkgY2xlYXIgZmFpbHVyZSB3 aGVuIGl0IGNvbWVzIHRvPGJyPnJvdXRpbmcuIEFuZCB5ZXQgYWdhaW4gdGhlIGV4Y2VwdGlvbnMg Y2xhdXNlcyBoZXJlIGFyZTxicj5zbyBicm9hZCBhcyB0byBiZSBtZWFuaW5nbGVzcyAoZS5nLiBj b25zaWRlcmVkIGxvdzxicj52YWx1ZSBieSB3aG9tPykuIFdoYXQgaXMgdGhlIHJlYWwgZ29hbCBo ZXJlPyAob3RoZXI8YnI+dGhhbiBhbiBhdHRlbXB0IHRvIGtlZXAgdGhlIHNlYyBBRHMgZnJvbSBi ZWluZyBhbm5veWluZzxicj5hbmQgdHJ5aW5nIHRvIGluc2lzdCBvbiBCQ1AxMDc/IDstKSA8YnI+ PGJyPihkaXNjdXNzMTEpIC0gU0VDLVJFUS0wOTogU2VwYXJhdGVseSwgdG8gbXkgb3RoZXI8YnI+ d291bGQtYmUtZGlzY3VzcyBwb2ludCBvbiB0aGlzIHJlcXVpcmVtZW50LCAiY2FuPGJyPmd1YXJh bnRlZSIgaXMgd2VsbCBiZXlvbmQgdGhlIHN0YXRlIG9mIHRoZSBhcnQgaW4ga2V5PGJyPm1hbmFn ZW1lbnQuIEknZCBqdXN0IGRyb3AgdGhhdCBzZW50ZW5jZSBtYXliZSwgYnV0PGJyPmNhbid0IG1h a2UgYSBjb25jcmV0ZSBzdWdnZXN0aW9uIHVudGlsIEkgdW5kZXJzdGFuZDxicj53aGVyZSB5b3Ug d2FudCB0byBiZSB3cnQgQkNQMTA3Ljxicj48YnI+LSBTRUMtUkVRLTEwOiB0aGUgbGFzdCBzZW50 ZW5jZSBoZXJlIGlzIGFsc28gaW52b2x2ZWQ8YnI+aW4gdGhlICJtYXkgZG8gc3R1ZmYgaW5zZWN1 cmVseSIgdGhpbmcsIGFuZCBzbyB3aWxsPGJyPmxpa2VseSBuZWVkIGZpeGluZyB3aGVuIHRoYXQg aXMgZnVsbHkgcmVzb2x2ZWQuPGJyPjxicj4tIEhvdyBpcyBTRUMtUkVRLTExIHVzZWZ1bD8gV2hh dCBwcm90b2NvbCBhcnRlZmFjdHMgZG88YnI+eW91IGhhdmUgaW4gbWluZCBoZXJlPyBQZXJoYXBz IGEgcmVxdWlyZW1lbnQgdGhhdCBERG9TPGJyPmF0dGFja3MgYmUgc3BlY2lmaWNhbGx5IGNvbnNp ZGVyZWQgaW4gSTJSUyB3b3VsZCBiZTxicj5tb3JlIHVzZWZ1bC48YnI+PGJyPi0gU0VDLVJFUS0x MjogVGhpcyBzZWVtcyB0byBtZSB0byBoYXZlIHRvbyBtYW55IHdvcmRzLDxicj5lLmcuIHRoZSBj dXJyZW50IHRleHQgY291bGQgYmUgcmVhZCB0byBpbXBseSB0aGF0PGJyPm91dHNpZGUgb2YgY3Jp dGljYWwgaW5mcmFzdHJ1Y3R1cmUgdGhlcmUgaXMgbGVzcyBvciBubzxicj5uZWVkIGZvciBjb25m aWRlbnRpYWxpdHksIHNvIHRob3NlIGFkZGVkIHdvcmRzPGJyPihwcmVzdW1hYmx5IHRoZXJlIHRv IG1vdGl2YXRlKSBtaWdodCBiZTxicj5jb3VudGVyLXByb2R1Y3RpdmUuIDxicj48YnI+KGRpc2N1 c3MxMikgU0VDLVJFUS0xMjogSSBkb24ndCBnZXQgdGhlIG1lYW5pbmcgb2YgdGhlPGJyPlNIT1VM RCBoZXJlIC0gY29tYmluZWQgd2l0aCAiY2VydGFpbiBkYXRhIiB0aGF0IFNIT1VMRDxicj5zZWVt cyB0byBlbmQgdXAgbWVhbmluZyBNQVksIGFzIGluLCBpdCBzZWVtcyB0byBtZWFuPGJyPnRoZSBz YW1lIGFzICJSZWFkL3dyaXRlIG9wZXJhdGlvbnMgTUFZIGhhdmUgdG8gYmU8YnI+cHJvdGVjdGVk IHVzaW5nIGEgY29uZmlkZW50aWFsaXR5IHNlcnZpY2UuIjxicj48YnI+LSAzLjQsIGJ1bGxldCAo MikgaGVyZSBtZWFucyB0aGF0IHdlJ3JlIG5vdCB0YWxraW5nPGJyPmFib3V0IGRhdGEgaW50ZWdy aXR5IGJ1dCBkYXRhIG9yaWdpbiBhdXRoZW50aWNhdGlvbjxicj5hcyB3ZWxsLjxicj48YnI+KGRp c2N1c3MxMykgMy40LCAoMyk6IFdpdGhpbiB3aGF0IHNjb3BlIG11c3QgcmVwbGF5IGJlPGJyPmRl dGVjdGVkPyBUaGUgdGV4dCBpbXBsaWVzIGZvciBldmVyLCB3aGljaCBjYW4gYmUgdmVyeTxicj5v bmVyb3VzLiBTRUMtUkVRLTE0IGRvZXNuJ3QgcXVpdGUgZ28gc28gZmFyLCBidXQgaXM8YnI+YW1i aWd1b3VzIG9uIHRoaXMgYXNwZWN0LiBJJ2Qgc2F5IGJlc3QgaXMgdG8gbm90ZSB0aGF0PGJyPnRo ZSBzY29wZSB3aXRoaW4gd2hpY2ggcmVwbGF5IG5lZWRzIHRvIGJlIGRldGVjdGFibGUgaXM8YnI+ Zm9yIGZ1dHVyZSBzdHVkeS4gPGJyPjxicj4oZGlzY3VzczE0KSBTRUMtUkVRLTE1OiBTb3JyeSwg SSBkb24ndCB1bmRlcnN0YW5kPGJyPndoYXQncyByZXF1aXJlZCBoZXJlIChoYXZpbmcgcmVhZCB0 aGlzICZndDsxIHRpbWUpLiBDYW48YnI+eW91IGV4cGxhaW4/Jm5ic3A7IEknbSBub3Qgc3VyZSBp ZiBhbnkgc3Vic3RhbnRpdmUgY2hhbmdlIGlzPGJyPm5lZWRlZCwgYnV0IHRoZXJlIGFyZSBjZXJ0 YWlubHkgZWRpdG9yaWFsIGNoYW5nZXM8YnI+bmVlZGVkIGZvciBzdXJlIGFzIHRoZXJlIGFyZSBt dWx0aXBsZSB3b3JkaW5nIHByb2JsZW1zPGJyPndpdGggdGhlIHRleHQgYXMtaXMuPGJyPjxicj4t IDMuNSwgMXN0IHBhcmE6IHRoZSB0ZXh0IGhlcmUgaXMgbm90IGFzIGdvb2QgYXMgPGJyPnRoZSBh Y3R1YWwgZGVmaW5pdGlvbiBvZiAicm9sZSIgaW4gUkZDNzkyMSwgYW5kIGluPGJyPmZhY3QgSSBm b3VuZCB0aGUgdGV4dCBoZXJlIGNvbmZ1c2luZy4gQmV0dGVyIHRvPGJyPmp1c3QgZGVsZXRlIHRo YXQgYW5kIHNheSB0aGF0IDc5MjEgZGVmaW5lcyByb2xlcy4gPGJyPjxicj4oZGlzY3VzczE1KSBT RUMtUkVRLTE2OiBJIGRvbid0IHNlZSBhbnkgY29udGVudCBpbiB0aGlzPGJyPnRleHQgYXMgaXQg c2VlbXMgdG8ganVzdCBzYXkgInNvbWUgcm9sZSBiYXNlZCBhY2Nlc3M8YnI+Y29udHJvbCBhbmQg c29tZSBsZXZlbCBvZiB0cmFuc3BvcnQgcHJvdGVjdGlvbiBuZWVkIHRvPGJyPmJlIHByb3ZpZGVk IiB3aGljaCBpcyBhbHdheXMgdHJ1ZSwgYXMgeW91IGFyZSBhbGxvd2luZzxicj4ibm8gdHJhbnNw b3J0IHNlY3VyaXR5IiBhbmQgKEkgYXNzdW1lKSAiZnVsbHkgcHVibGljPGJyPmFjY2VzcyIgc28g YW55IHByb3RvY29sL3N5c3RlbSB3aWxsIGFsd2F5cyBtZWV0IHRoaXM8YnI+cmVxdWlyZW1lbnQu PGJyPjxicj4tIFNFQy1SRVEtMTY6ICJwcml2YWN5IHJlcXVpcmVtZW50cyIgaGVyZSBpcyB3cm9u Zyw8YnI+eW91IG1lYW4gY29uZmlkZW50aWFsaXR5IEkgdGhpbmsuPGJyPjxicj4oZGlzY3VzczE2 KSBTRUMtUkVRLTE3OiAiTVVTVCB3b3JrIiBpcyBmYXIgdG9vIHZhZ3VlLjxicj5UaGF0IGNvdWxk IGZvciBleGFtcGxlIGhpZGUgYSBtYWpvciBkZWJhdGUgYWJvdXQgcHVzaDxicj52LiBwdWxsIG9m IHJvbGUgaW5mb3JtYXRpb24uIElmIHRoZSBXRyBoYXZlbid0PGJyPmNvbnNpZGVyZWQgdGhhdCwg SSB0aGluayB5b3UgY291bGQgYWNrIHRoYXQgYWdhaW4gYnk8YnI+c2F5aW5nIHRoYXQgbW9yZSB3 b3JrIGlzIG5lZWRlZCB0byBkZWZpbmUgaG93IFJCQUMgaXM8YnI+Y29uc2lzdGVudCBhY3Jvc3Mg bXVsdGlwbGUgdHJhbnNwb3J0IGxheWVyIGNvbm5lY3Rpb25zLjxicj48YnI+KGRpc2N1c3MxNykg U0VDLVJFUS0xODogYWdhaW4gdGhpcyBzZWVtcyB0byBoYXZlIG5vPGJyPmNvbnRlbnQsIG90aGVy IHRoYW4gcGVyaGFwcyBpbXBvc2luZyBhbiBvZGQgcmVxdWlyZW1lbnQ8YnI+b24gaW1wbGVtZW50 YXRpb25zIC0gSSBkb24ndCBzZWUgYSBwcm90b2NvbCByZXF1aXJlbWVudDxicj5oZXJlIGF0IGFs bC4gSXQgaXMgcmVhc29uYWJsZSB0byBub3RlIHRoYXQgbGlicmFyaWVzPGJyPmZvciBjbGllbnRz IG91Z2h0IG5vdCBhc3N1bWUgYSBzaW5nbGUgY2xpZW50IGlkZW50aXR5PGJyPmJ1dCBldmVuIHRo YXQncyB2ZXJ5IHNwZWNpZmljIHRvIGxpYnJhcnk8YnI+aW1wbGVtZW50YXRpb25zIGFuZCBzaW5j ZSBpdCdzIGp1c3QgYSBNQVkgdGhhdCdzPGJyPmVudGlyZWx5IG9idmlvdXMsIEknZCBsZWF2ZSBp dCBvdXQuPGJyPjxicj4oZGlzY3VzczE4KSBTRUMtUkVRLTE5OiBJIGZ1bGx5IGFncmVlIHdpdGgg dGhlPGJyPm1vdGl2YXRpb24gaGVyZSBidXQgSSB0aGluayB0aGUgc3RhdGVkIHJlcXVpcmVtZW50 IGlzPGJyPmJyb2tlbi4mbmJzcDsgRm9yIGV4YW1wbGUsIEkgZG9uJ3Qga25vdyBob3cgYSBwaWVj ZSBvZiBzL3c8YnI+d2lsbCBkZXRlcm1pbmUgd2hldGhlciBvciBub3QgaXQgaXMgY29ycmVsYXRl ZCB3aXRoIGE8YnI+cGVyc29uLiBJIGFsc28gZG9uJ3QgdGhpbmsgYSBTSE9VTEQgd29ya3MgaGVy ZSwgYXM8YnI+YWdhaW4gc29tZXRoaW5nIHdvdWxkIG5lZWQgdG8gYmUgc3RhdGVkIGFib3V0IHRo ZTxicj5zaXR1YXRpb25zIHdoZW4gdGhlIGZlYXR1cmUgaXMgbm90IG5lZWRlZCwgYW5kIEkgY2Fu J3Q8YnI+ZmlndXJlIG91dCBhIHNlbnNpYmxlIHN0YXRlbWVudCBmb3IgdGhhdC4gVGhlIGxhc3Q8 YnI+c2VudGVuY2UgYWxzbyBzZWVtcyBsaWtlbHkgbm90IHVzZWZ1bC4gQWxsIGluIGFsbCwgSTxi cj50aGluayB0aGlzIGlzIGxpa2VseSB0byBiZSBpZ25vcmVkIG9yIGV2ZW4gd29yc2U8YnI+dHJl YXRlZCBsaWtlIGEgcGllY2Ugb2YgZmlnLWxlYWYgc3BlY2lmaWNhdGlvbiB0ZXh0IHRvPGJyPnBy ZXRlbmQgdGhhdCB3ZSdyZSBjYXJpbmcgYWJvdXQgcHJpdmFjeS48YnI+PGJyPihkaXNjdXNzMTkp IC0gMy42OiBJIGhhdmUgbm8gaWRlYSB3aGV0aGVyIHRoaXMgb3RoZXI8YnI+ZHJhZnQgaXMgc3Vw cG9zZWQgdG8gYmUgY29uc2lkZXJlZCBhcyBzZXR0aW5nPGJyPnJlcXVpcmVtZW50cyBvciBub3Qu IEkgYXNzdW1lIHRoYXQgdGhlIGFuc3dlciBpcyAibm90Ijxicj5hcyB5b3UndmUgbWFkZSBpdCBh biBpbmZvcm1hdGl2ZSByZWZlcmVuY2UsIGJ1dCBpbiB0aGF0PGJyPmNhc2UgeW91IHJlYWxseSBz aG91bGQgc2F5IHRoYXQuJm5ic3A7IFRoZSBhbHRlcm5hdGl2ZSB3b3VsZDxicj5iZSB0aGF0IDMu NiBpcyBlc3NlbnRpYWxseSBzcGVjaWZ5aW5nIGFuIGFwcGxpY2FiaWxpdHk8YnI+c3RhdGVtZW50 IGZvciB0aGUgZW52aXJvbm1lbnRzIGluIHdoaWNoIGl0IGlzLCBhbmQgaXM8YnI+bm90LCBvayB0 byBydW4gaTJycy4gSWYgdGhlIGxhdHRlciB3ZXJlIGludGVuZGVkLCB0aGVuPGJyPnlvdSdkIG5l ZWQgdG8gc2F5IGl0IGFuZCBtYWtlIHRoZSBkcmFmdCBhIG5vcm1hdGl2ZTxicj5yZWZlcmVuY2Uu PGJyPjxicj48YnI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X188YnI+aTJycyBtYWlsaW5nIGxpc3Q8YnI+aTJyc0BpZXRmLm9yZzxicj5odHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2kycnM8YnI+PC9ib2R5PjwvaHRtbD4= ----_com.samsung.android.email_100536710520980-- From nobody Sun Aug 21 12:41:50 2016 Return-Path: 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 AAEE712D810; Sun, 21 Aug 2016 12:41:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.849 X-Spam-Level: X-Spam-Status: No, score=-4.849 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_MED=-2.3, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie 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 940gwkzg8p-W; Sun, 21 Aug 2016 12:41:39 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC04712D80E; Sun, 21 Aug 2016 12:41:38 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id A9DD9BE3F; Sun, 21 Aug 2016 20:41:36 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l-KCAASwWGkd; Sun, 21 Aug 2016 20:41:33 +0100 (IST) Received: from [10.87.48.210] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 23300BE35; Sun, 21 Aug 2016 20:41:33 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1471808493; bh=3frszlsuiM5vAeGxg2gekW37yjcnMMcE/Kz4AduCY9o=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=c7QESkQYVQmfL7btNj9tzf4Fcny1PXVKzmPTzGJv5WKt1dZ3wBT9Ag0yoDMkhgFhv mRta4xEAXie9WyvVI96xco5QcbfQnZP755VKAj0maXLiyAD4oyKkt7IsAHsYid/DYt tGIdlGiAq8/Pbkgc/sbYCRAOQf8iALjGzWqbOSMc= To: Susan Hares , The IESG References: <6nfkw155x8fc3tk9rou61bbw.1471806604523@email.android.com> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: Date: Sun, 21 Aug 2016 20:41:32 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <6nfkw155x8fc3tk9rou61bbw.1471806604523@email.android.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms060902050009090706060409" Archived-At: Cc: jhaas@pfrc.org, i2rs@ietf.org, i2rs-chairs@ietf.org, draft-ietf-i2rs-protocol-security-requirements@ietf.org Subject: Re: [i2rs] Stephen Farrell's Abstain on draft-ietf-i2rs-protocol-security-requirements-09: (with COMMENT) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Aug 2016 19:41:43 -0000 This is a cryptographically signed message in MIME format. --------------ms060902050009090706060409 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hiya, On 21/08/16 20:10, Susan Hares wrote: > Stephen: Thank you for leaving your vacation early to do this review. > It is one of the most negative viewpoint I have read from you, and > since have read many of your DISCUSS comments since you became an AD Well, I've done far more negative reviews, but this one has a lot of smaller negative comments. My guess is quite a lot of that is down to a) it's very very hard to write protocol requirements text crisply and accurately, and b) that kind of text is very very easily messed up when doing iterative edits in response to reviews, and c) the writing is really not that good in this version - to the point where the accumulation of nits itself becomes a notable issue, and where it's likely past time that an editorial pass was done to get that out of the way. > - I think this gives me unique perspective. This is far from the > early comments you sent 2 weeks ago. No. I would not have asked for a defer if I thought the only concern was the possibility of this resulting in a hard-to-deploy set of security mechanisms - I would have just balloted that. It is the case that that's all I said before I had properly read the document though, yes. And it wasn't 2 weeks ago:-) > In developing this document and > I2RS technology the I2RS WG and I as the I2RS chair have request > reviews from the Security directorate. We delayed out first > revisions to try to address security issue by adding this document > and the security environment document. We have had early and late > reviews. Since the initial review on the I2RS architecture we have > discussed the non-secure interface and tried to get security > directorate's review. I have looked back at the secdir mails on this, yes. > I raised the pervasive privacy issue and asked > for input in your review.=20 Yes. And I responded with two would-have-been-discuss points related to pervasive monitoring. (I assume that what's you mean when you say "pervasive privacy" but if you mean something else above, please do clarify.) > This meta-comment is that process of asking > for aid ahead of this point has failed according to your review,=20 I think that's an odd view of IETF processes, which are never expected to produce perfection at any stage. IMO we're iterating towards better outcomes, not failing/succeeding at each stage of the process. > but > I cannot find a point where the I2RS WG did not solicit the security > area's aid and take its advice. Therefore, I must ask you to check > the process of your security directorate's reviews to find what > happened to cause such a failure.=20 Don't think of it as failure, think of it as more eyeballs finding more things. (Or repeating things already considered, for those where that's the case.) > Now as to the document, I have a WG > waiting for these requirements. =20 I'd encourage you to question the above, as a first order goal. Are the WG really waiting on these in a final, fixed-forever, form? Or do you need a general agreement as to direction and can then make progress? (And perhaps reduce the final requirements to RFC status later if there's value in that, which there can be.) As I noted a couple of times in my review, it's not possible to be that precise about some requirements without having done more of the design. (One of the traditional waterfalll design problems I guess.) The scope of replay detection is probably a good example. > I would like to hear in a completely > separate email thread what kernel of information you would have > expected regarding the security first an i2rs protocol. =20 I don't understand your question sorry. > I would then > like to compare this against the security directorate's suggestions > on this document. We have a second document on the security > environment so your insights will be applied to that document. Since > in the general text you indicate the style is terrible and needs to > be written, please provide an example of a document as an example of > the style. =20 Really? The accumulation of badly written sentences in -09 has got to be a clear enough problem that you don't need an example of what is not-that. So I'm puzzled at the request. > My understanding is that style is a lower priority than > technical correctness and consensus.=20 Correct/good-enough writing is certainly secondary, up until the issues get to a certain point that impinges on the reader's ability to asses the meaning, and that happens a couple of times in this document. (As I said in my review.) The other writing issues make this a harder read than ought be the case. That doesn't reach the level of making the document unreadable, nor nearly get that bad, but it is enough that I wonder if other readers may have been put off by that in reading some of the text. > This email ends my comments on > your summary message. The next set of comments will take your > discuss comments one at a time. The exact next steps that I and my > co-author will take will be guided by the AD responsible for the I2RS > WG,=20 That's all good. I would re-iterate though, that since my ballot is an abstain there's no onus on you or the WG to respond in any more detail than you feel is useful. Cheers, S. > Alia. Cheerily, Sue Hares >=20 > Sent via the Samsung Galaxy Note5, an AT&T 4G LTE smartphone -------- > Original message --------From: Stephen Farrell > Date: 8/21/16 8:37 AM (GMT-05:00) To: > The IESG Cc: jhaas@pfrc.org, i2rs@ietf.org, > i2rs-chairs@ietf.org, > draft-ietf-i2rs-protocol-security-requirements@ietf.org Subject: > [i2rs] Stephen Farrell's Abstain on=20 > draft-ietf-i2rs-protocol-security-requirements-09: (with COMMENT)=20 > Stephen Farrell has entered the following ballot position for=20 > draft-ietf-i2rs-protocol-security-requirements-09: Abstain >=20 > When responding, please keep the subject line intact and reply to > all email addresses included in the To and CC lines. (Feel free to > cut this introductory paragraph, however.) >=20 >=20 > Please refer to > https://www.ietf.org/iesg/statement/discuss-criteria.html for more > information about IESG DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here:=20 > https://datatracker.ietf.org/doc/draft-ietf-i2rs-protocol-security-requ= irements/ > >=20 >=20 >=20 > ---------------------------------------------------------------------- > >=20 COMMENT: > ---------------------------------------------------------------------- > >=20 >=20 > First, apologies for not getting my review done for this when it was > scheduled due to my vacation and thanks for being willing to defer > the document. >=20 > Second, having now properly reviewed this, I am balloting abstain as > I think it's unlikely that this document can be fixed in a way that > results in something useful happening. I think that the likely=20 > outcome is that this document will be used later when people are > arguing and will not much help in resolving those arguments, or else > this will be ignored and arguments will be held afresh, as needed. > That latter outcome is what I'd guess is most likely and therefore it > seems that spending all of our cycles on DISCUSS ballot processing > for this would not be wise. That said, I am willing to change to a > DISCUSS ballot if the responsible AD prefers that, but I suspect I'll > end up with an abstain in any case, after some discussion. The only > plan I can think of that'd lead to me ending up with a yes or > no-objection ballot would be if this was returned to the WG for > fixing and possibly major surgery, which is what I actually think > would be the best plan. (I realise this has had a somewhat tortured=20 > history, so folks may not be willing to take it back to the WG, but > honestly, I think the failings visible in this document do indicate > that this is not ready for approval and ought be returned to the > WG.) >=20 > Third, I think the overall set of requirements posed here might (with > some unknown probability) lead to later specifications that are > considered too hard to deploy, with the result that non-secure > variants of I2RS become the norm. That seems like it would be a=20 > really bad outcome. I would suggest that might be partly mitigated if > a requirement were added to the effect that deployment issues and > specifically ease of deployment MUST be considered as a first order=20 > requirement when developing I2RS protocol solutions. >=20 > Fourth, the (19!) comments below that are preceded by "(discuss" > would have been DISCUSS ballot points had I not decided to abstain. I > am happy to chat about any of my comments below, but if the > authors/WG do want to chat, it might be more efficient to concentrate > on those that would otherwise have been DISCUSS points. (But that's > your call, I don't mind.) I think the 19 would-have-been-discuss > points is another clue that this ought really be sent back to the > WG. >=20 > And with that, and with apologies for this being such an overall > negative review, here're my detailed comments: >=20 > - general: The writing here is generally poor, for example the opener > is "This presents..." whereas it ought be "This document presents..." > (or s/document/whatever you prefer/). Such issues are repeatedly seen > and all that makes this a much harder read than ought be the case. > I'd strongly recommend an editorial pass from someone who hasn't been > down in the weeds with this text for a while (which could be one of=20 > the authors, if one of them has been less active recently.) Note that > this is not only (but is primarily) an editorial issue - there are > some cases (hopefully called out below) where the writing does create > real ambiguity that might lead to re-opening old arguments later. >=20 > - abstract: "mutual authentication, transport protocols, data > transfer and transactions" don't seem to me to be commensurate > things, so the abstract, as written is very uninformative for me. >=20 > - intro 3rd para: I'm really not sure what you're telling me about > [I-D.ietf-i2rs-ephemeral-state]. "The draft [RFC7922]" is odd, that > being no longer a draft. I'd have expected such nits would have been > fixed by now TBH. Same for the last sentence. That para makes the > intro pretty unclear for me. >=20 > - 2.2: The definition of higher level protocol seems like an odd > place to introduce the fact that i2rs =3D=3D netconf + restconf. That'= d > be more usefully said in the abstract/intro if that's solidly agreed > by the WG. >=20 > - 2.2: This is wrong: "While it is possible to have an I2RS operation > which is contained in multiple I2RS (E.g. write in multiple > messages), this is not supported in order to simplify the first > version of I2RS." The reason this is wrong, is that it is here that > you are defining that it is not possible to have an operation in > multiple messages. s/it is/it could have been/ would work maybe. >=20 > - 2.2: " * The I2RS client issues a read request to a I2RS agent, > and the I2RS Agent responding to the read request" Shouldn't that use > respond and not responding? Given that you seem to be trying to > define the scope of what is and is not a transaction, I think being > precise with the language is something well worth doing. The 2nd > bullet could also do with a re-write. >=20 > (discuss1) 2.2: you sort-of define messages, operations, transactions > and actions. None of the definitions are that precise, e.g. are those > the only operations or examples? And transaction and action aren't > really defined at all. I'm not sure if that's likely to be a problem > or not. I suspect it will later, e.g. when you get to figuring out > the scope within which replay needs to be detectable. >=20 > - 2.2: s/transation/transaction/ >=20 > (discuss2) - 2.2: "defines a secondary identity as the entity of some > non-I2RS entity " That could be abused for tracking of various kinds > I would guess, e.g. if an IMEI were used. I think you need to note > that and should impose some requirements that such secondary=20 > identifiers are not used thusly for tracking. Also, should the first > occurrence of entity there be identity? >=20 > - 3, 1st para: s/The security for the/The/ - there isn't a thing > called the security for the i2rs protocol. >=20 > (discuss3) - section 3 says "the I2RS protocol requires mutually > authenticated I2RS clients and I2RS agents communicating over a > secure transport." To me that implies that something like TLS or SSH > is MTU which seems to contradict recent emails. >=20 > - section 3 says: "The I2RS protocol MUST be able to provide > atomicity of an I2RS transaction, but it is not required to have > multi-message atomicity and roll-back mechanism transactions. > Multiple messages transactions may be impacted by the interdependency > of data." I don't believe that that's easily enough understood to be > useful. Also, wouldn't s/Multiple messages=20 > transactions/Multiple-message transactions/ be much clearer if that's > what's meant? And finally, I think the MUST embedded in the above is > not that great an idea - it's clearer IMO to separate the 2119 > language from introductory text in documents like this. >=20 > - 3: "There are dependencies in some of the requirements below" would > be better as "There are inter-dependencies between some of the > requirements below" unless you mean dependencies on some external=20 > things, which is not clear from the text as-is. >=20 > (discuss4) " For confidentiality (section 3.3) and integrity (section > 3.4) to be achieved, the client-agent must have mutual authentication > (section 3.1) and secure transport (section 3.2). " This is=20 > incorrect. One can have confidentiality without authentication (see > RFC7435) so the text is not accurate. >=20 > - capitalisation needs fixing in various places, e.g. around the end > of p5, we get "secure Transport" and then "I2RS client" and "I2RS > Agent" in the title of 3.1 Is any of that capitalisation supposed to > be significant? Either way, fixing it now would be good as you'll > need to get the RFC editor to do it later if you don't (which takes > longer). >=20 > (discuss5) SEC-REQ-01: what is the scope of uniqueness required here? > I see no reason why two different data centres cannot re-use a client > or agent identifier, if they so wish. I'd be fine if you say that's > for later decision, but being silent on the matter could lead to=20 > trouble later if different folks decide differently. >=20 > (discuss6) SEC-REQ-02: the "MUST utilize" there means MTU, which > wasn't what you wanted I think >=20 > (discuss7) - SEC-REQ-03: how is "upon receiving... MUST confirm" a > good choice? As stated that'd be hugely onerous, implying e.g. OCSP > checks for each packet received. Same point applies to SEC-REQ-04. >=20 > (discuss8) - SEC-REQ-05: this either means nothing at all (being a > tautology) or else something I don't get. I think it's the former, > but am not sure. >=20 > - 3.1: s/One mechanism such mechanism/One such mechanism/ I guess. > And it's not at all clear to me "AAA protocols" is the right idea > there, and nor is it clear what's meant, with the text as-is. >=20 > - SEC-REQ-06: where is a "priority" defined? >=20 > - SEC-REQ-07: here you say read/write is a transaction, but earlier > you said it was an operation, which is it? >=20 > (discuss9) 3.2: As with others, I don't think the idea of annotating > parts of yang modules with "can be insecure" is a good one. There's a > separate thread discussing that though, so maybe better to not fork=20 > that. >=20 > (discuss10) - SEC-REQ-O9: I hate to do this to ya, but BCP107 is IMO > a fairly clear failure when it comes to routing. And yet again the > exceptions clauses here are so broad as to be meaningless (e.g. > considered low value by whom?). What is the real goal here? (other=20 > than an attempt to keep the sec ADs from being annoying and trying to > insist on BCP107? ;-) >=20 > (discuss11) - SEC-REQ-09: Separately, to my other would-be-discuss > point on this requirement, "can guarantee" is well beyond the state > of the art in key management. I'd just drop that sentence maybe, but=20 > can't make a concrete suggestion until I understand where you want to > be wrt BCP107. >=20 > - SEC-REQ-10: the last sentence here is also involved in the "may do > stuff insecurely" thing, and so will likely need fixing when that is > fully resolved. >=20 > - How is SEC-REQ-11 useful? What protocol artefacts do you have in > mind here? Perhaps a requirement that DDoS attacks be specifically > considered in I2RS would be more useful. >=20 > - SEC-REQ-12: This seems to me to have too many words, e.g. the > current text could be read to imply that outside of critical > infrastructure there is less or no need for confidentiality, so those > added words (presumably there to motivate) might be=20 > counter-productive. >=20 > (discuss12) SEC-REQ-12: I don't get the meaning of the SHOULD here - > combined with "certain data" that SHOULD seems to end up meaning MAY, > as in, it seems to mean the same as "Read/write operations MAY have > to be protected using a confidentiality service." >=20 > - 3.4, bullet (2) here means that we're not talking about data > integrity but data origin authentication as well. >=20 > (discuss13) 3.4, (3): Within what scope must replay be detected? The > text implies for ever, which can be very onerous. SEC-REQ-14 doesn't > quite go so far, but is ambiguous on this aspect. I'd say best is to > note that the scope within which replay needs to be detectable is for > future study. >=20 > (discuss14) SEC-REQ-15: Sorry, I don't understand what's required > here (having read this >1 time). Can you explain? I'm not sure if > any substantive change is needed, but there are certainly editorial > changes needed for sure as there are multiple wording problems with > the text as-is. >=20 > - 3.5, 1st para: the text here is not as good as the actual > definition of "role" in RFC7921, and in fact I found the text here > confusing. Better to just delete that and say that 7921 defines > roles. >=20 > (discuss15) SEC-REQ-16: I don't see any content in this text as it > seems to just say "some role based access control and some level of > transport protection need to be provided" which is always true, as > you are allowing "no transport security" and (I assume) "fully > public access" so any protocol/system will always meet this=20 > requirement. >=20 > - SEC-REQ-16: "privacy requirements" here is wrong, you mean > confidentiality I think. >=20 > (discuss16) SEC-REQ-17: "MUST work" is far too vague. That could for > example hide a major debate about push v. pull of role information. > If the WG haven't considered that, I think you could ack that again > by saying that more work is needed to define how RBAC is consistent > across multiple transport layer connections. >=20 > (discuss17) SEC-REQ-18: again this seems to have no content, other > than perhaps imposing an odd requirement on implementations - I don't > see a protocol requirement here at all. It is reasonable to note that > libraries for clients ought not assume a single client identity but > even that's very specific to library implementations and since it's > just a MAY that's entirely obvious, I'd leave it out. >=20 > (discuss18) SEC-REQ-19: I fully agree with the motivation here but I > think the stated requirement is broken. For example, I don't know > how a piece of s/w will determine whether or not it is correlated > with a person. I also don't think a SHOULD works here, as again > something would need to be stated about the situations when the > feature is not needed, and I can't figure out a sensible statement > for that. The last sentence also seems likely not useful. All in all, > I think this is likely to be ignored or even worse treated like a > piece of fig-leaf specification text to pretend that we're caring > about privacy. >=20 > (discuss19) - 3.6: I have no idea whether this other draft is > supposed to be considered as setting requirements or not. I assume > that the answer is "not" as you've made it an informative reference, > but in that case you really should say that. The alternative would=20 > be that 3.6 is essentially specifying an applicability statement for > the environments in which it is, and is not, ok to run i2rs. If the > latter were intended, then you'd need to say it and make the draft a > normative reference. >=20 >=20 > _______________________________________________ i2rs mailing list=20 > i2rs@ietf.org https://www.ietf.org/mailman/listinfo/i2rs >=20 --------------ms060902050009090706060409 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CvIwggUIMIID8KADAgECAhBPzaE7pzYviUJyhmHTFBdnMA0GCSqGSIb3DQEBCwUAMHUxCzAJ BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGll bnQgQ0EwHhcNMTYwMjA5MDkyODE1WhcNMTcwMjA5MDkyODE1WjBOMSIwIAYDVQQDDBlzdGVw aGVuLmZhcnJlbGxAY3MudGNkLmllMSgwJgYJKoZIhvcNAQkBFhlzdGVwaGVuLmZhcnJlbGxA Y3MudGNkLmllMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtuC0rYze/2JinSra C9F2RjGdQZjNALLcW9C3WKTwYII3wBslobmHuPEYE5JaGItmzuKnAW619R1rD/kfoNWC19N3 rBZ6UX9Cmb9D9exCwYIwVuSwjrCQWGxgCtNQTrwKzCCpI790GRiMTvxvO7UmzmBrCaBLiZW5 R0fBjK5Yn6hUhAzGBkNbkIEL28cLJqH0yVz7Kl92OlzrQqTPEts5m6cDnNdY/ADfeAX18c1r dxZqcAxhLotrCqgsVA4ilbQDMMXGTLlB5TP35HeWZuGBU7xu003rLcFLdOkD8xvpJoYZy9Kt 3oABXPS5yqtMK+XCNdqmMn+4mOtLwQSMmPCSiQIDAQABo4IBuTCCAbUwCwYDVR0PBAQDAgSw MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAJBgNVHRMEAjAAMB0GA1UdDgQWBBQJ QhvwQ5Fl372Z6xqo6fdn8XejTTAfBgNVHSMEGDAWgBQkgWw5Yb5JD4+3G0YrySi1J0htaDBv BggrBgEFBQcBAQRjMGEwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbTA5 BggrBgEFBQcwAoYtaHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc2NhLmNsaWVudDEu Y3J0MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3NjYS1jbGll bnQxLmNybDAkBgNVHREEHTAbgRlzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllMCMGA1UdEgQc MBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzBGBgNVHSAEPzA9MDsGCysGAQQBgbU3AQIE MCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeTANBgkqhkiG 9w0BAQsFAAOCAQEArzrSv2C8PlBBmGuiGrzm2Wma46/KHtXmZYS0bsd43pM66Pc/MsqPE0HD C1GzMFfwB6BfkJn8ijNSIhlgj898WzjvnpM/SO8KStjlB8719ig/xKISrOl5mX55XbFlQtX9 U6MrqRgbDIATxhD9IDr+ryvovDzChqgQj7mt2jYr4mdlRjsjod3H1VY6XglRmaaNGZfsCARM aE/TU5SXIiqauwt5KxNGYAY67QkOBs7O1FkSXpTk7+1MmzJMF4nP8QQ5n8vhVNseF+/Wm7ai 9mtnrkLbaznMsy/ULo/C2yuLUWTbZZbf4EKNmVdme6tUDgYkFjAFOblfA7W1fSPiQGagYzCC BeIwggPKoAMCAQICEGunin0K14jWUQr5WeTntOEwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5MB4XDTE1MTIxNjAxMDAwNVoXDTMwMTIxNjAxMDAwNVowdTELMAkGA1UEBhMC SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL192vfDon2D9luC/dtbX64eG3XAtRmv mCSsu1d52DXsCR58zJQbCtB2/A5uFqNxWacpXGGtTCRk9dEDBlmixEd8QiLkUfvHpJX/xKnm VkS6Iye8wUbYzMsDzgnpazlPg19dnSqfhM+Cevdfa89VLnUztRr2cgmCfyO9Otrh7LJDPG+4 D8ZnAqDtVB8MKYJL6QgKyVhhaBc4y3bGWxKyXEtx7QIZZGxPwSkzK3WIN+VKNdkiwTubW5PI dopmykwvIjLPqbJK7yPwFZYekKE015OsW6FV+s4DIM8UlVS8pkIsoGGJtMuWjLL4tq2hYQuu N0jhrxK1ljz50hH23gA9cbMCAwEAAaOCAWQwggFgMA4GA1UdDwEB/wQEAwIBBjAdBgNVHSUE FjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIBADAyBgNVHR8EKzAp MCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwZgYIKwYBBQUHAQEE WjBYMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5zdGFydHNzbC5jb20wMAYIKwYBBQUHMAKG JGh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL2NhLmNydDAdBgNVHQ4EFgQUJIFsOWG+ SQ+PtxtGK8kotSdIbWgwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwPwYDVR0g BDgwNjA0BgRVHSAAMCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Bv bGljeTANBgkqhkiG9w0BAQsFAAOCAgEAi+P3h+wBi4StDwECW5zhIycjBL008HACblIf26HY 0JdOruKbrWDsXUsiI0j/7Crft9S5oxvPiDtVqspBOB/y5uzSns1lZwh7sG96bYBZpcGzGxpF NjDmQbcM3yl3WFIRS4WhNrsOY14V7y2IrUGsvetsD+bjyOngCIVeC/GmsmtbuLOzJ606tEc9 uRbhjTu/b0x2Fo+/e7UkQvKzNeo7OMhijixaULyINBfCBJb+e29bLafgu6JqjOUJ9eXXj20p 6q/CW+uVrZiSW57+q5an2P2i7hP85jQJcy5j4HzA0rSiF3YPhKGAWUxKPMAVGgcYoXzWydOv Z3UDsTDTagXpRDIKQLZo02wrlxY6iMFqvlzsemVf1odhQJmi7Eh5TbxI40kDGcBOBHhwnaOu mZhLP+SWJQnjpLpSlUOj95uf1zo9oz9e0NgIJoz/tdfrBzez76xtDsK0KfUDHt1/q59BvDI7 RX6gVr0fQoCyMczNzCTcRXYHY0tq2J0oT+bsb6sH2b4WVWAiJKnSYaWDjdA70qHX4mq9MIjO /ZskmSY8wtAk24orAc0vwXgYanqNsBX5Yv4sN4Z9VyrwMdLcusP7HJgRdAGKpkR2I9U4zEsN JQJewM7S4Jalo1DyPrLpL2nTET8ZrSl5Utp1UeGp/2deoprGevfnxWB+vHNQiu85o6MxggPM MIIDyAIBATCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcG A1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0 Q29tIENsYXNzIDEgQ2xpZW50IENBAhBPzaE7pzYviUJyhmHTFBdnMA0GCWCGSAFlAwQCAQUA oIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjA4MjEx OTQxMzJaMC8GCSqGSIb3DQEJBDEiBCAmKjfufc7BcJI9rmnuPdo5m3Z/EY/T5FjDXZGBr2gR HzBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzCB nAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYD VQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzANBgkq hkiG9w0BAQEFAASCAQBBzm287Vs8fNmrTkyJP52tgCWLJuyYw5I5+0qMKS/sDvkpT2Z1b6wv z5pP+O5bLCSkJ062G/19rsf1/CwopNxt2wO+QsaninwtHoQtwAWI/rRBfX0xMKoNgV1pFT5d X5Exj2G50Px78t3Sc1kDfcdlh7y85kgmGWg2SzmgU87tAtCjGCGeGaYd4gwt26/F1OwtPsFM EWIOvi+aH2LZYnqxKe7goQY22Kt/Iz3sQuDah0QSKKRTp6pcAsY0SfnIx5krIacmZq4jQjr6 kC37ZVbu8th0Kpl0Bm+5aZcidUooWZxisKsiKPPJJZl6tPYP1e4CX834Mcv/RiXbGTNFK+xj AAAAAAAA --------------ms060902050009090706060409-- From nobody Sun Aug 21 14:16:45 2016 Return-Path: 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 F1A6912B043; Sun, 21 Aug 2016 14:16:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.095 X-Spam-Level: X-Spam-Status: No, score=-1.095 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_BL=0.01, RCVD_IN_MSPIKE_L5=0.001, RDNS_NONE=0.793] autolearn=no 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 qxiXG4MUMVbd; Sun, 21 Aug 2016 14:16:40 -0700 (PDT) Received: from hickoryhill-consulting.com (unknown [50.245.122.97]) (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 0783E12B01F; Sun, 21 Aug 2016 14:16:39 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=166.177.56.220; Date: Sun, 21 Aug 2016 17:16:32 -0400 Message-ID: Importance: normal From: Susan Hares To: Stephen Farrell , The IESG MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--_com.samsung.android.email_176427079500470" X-Authenticated-User: skh@ndzh.com Archived-At: Cc: jhaas@pfrc.org, i2rs@ietf.org, i2rs-chairs@ietf.org, draft-ietf-i2rs-protocol-security-requirements@ietf.org Subject: Re: [i2rs] Stephen Farrell's Abstain on draft-ietf-i2rs-protocol-security-requirements-09: (with COMMENT) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Aug 2016 21:16:44 -0000 ----_com.samsung.android.email_176427079500470 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 U3RlcGhlbjoKVGhpcyBlbWFpbCBiZWdpbnMgdGhlIGRpc2N1c3Npb24gb24gdGhlIERJU0NVU1Mg Y3JpdGVyaWEuIMKgRm9yIGVhc2Ugb2YgcHJvY2VzcyBpdCBnb2VzIHRocm91Z2ggRElTQ1VTUyAx IHRvIDUKU3VlCgoKU2VudCB2aWEgdGhlIFNhbXN1bmcgR2FsYXh5IE5vdGU1LCBhbiBBVCZUIDRH IExURSBzbWFydHBob25lCi0tLS0tLS0tIE9yaWdpbmFsIG1lc3NhZ2UgLS0tLS0tLS1Gcm9tOiBT dGVwaGVuIEZhcnJlbGwgPHN0ZXBoZW4uZmFycmVsbEBjcy50Y2QuaWU+IERhdGU6IDgvMjEvMTYg IDg6MzcgQU0gIChHTVQtMDU6MDApIFRvOiBUaGUgSUVTRyA8aWVzZ0BpZXRmLm9yZz4gQ2M6IGpo YWFzQHBmcmMub3JnLCBpMnJzQGlldGYub3JnLCBpMnJzLWNoYWlyc0BpZXRmLm9yZywgZHJhZnQt aWV0Zi1pMnJzLXByb3RvY29sLXNlY3VyaXR5LXJlcXVpcmVtZW50c0BpZXRmLm9yZyBTdWJqZWN0 OiBbaTJyc10gU3RlcGhlbiBGYXJyZWxsJ3MgQWJzdGFpbiBvbgogIGRyYWZ0LWlldGYtaTJycy1w cm90b2NvbC1zZWN1cml0eS1yZXF1aXJlbWVudHMtMDk6ICh3aXRoIENPTU1FTlQpIApTdGVwaGVu IEZhcnJlbGwgaGFzIGVudGVyZWQgdGhlIGZvbGxvd2luZyBiYWxsb3QgcG9zaXRpb24gZm9yCmRy YWZ0LWlldGYtaTJycy1wcm90b2NvbC1zZWN1cml0eS1yZXF1aXJlbWVudHMtMDk6IEFic3RhaW4K CldoZW4gcmVzcG9uZGluZywgcGxlYXNlIGtlZXAgdGhlIHN1YmplY3QgbGluZSBpbnRhY3QgYW5k IHJlcGx5IHRvIGFsbAplbWFpbCBhZGRyZXNzZXMgaW5jbHVkZWQgaW4gdGhlIFRvIGFuZCBDQyBs aW5lcy4gKEZlZWwgZnJlZSB0byBjdXQgdGhpcwppbnRyb2R1Y3RvcnkgcGFyYWdyYXBoLCBob3dl dmVyLikKCgpQbGVhc2UgcmVmZXIgdG8gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvaWVzZy9zdGF0ZW1l bnQvZGlzY3Vzcy1jcml0ZXJpYS5odG1sCmZvciBtb3JlIGluZm9ybWF0aW9uIGFib3V0IElFU0cg RElTQ1VTUyBhbmQgQ09NTUVOVCBwb3NpdGlvbnMuCgoKVGhlIGRvY3VtZW50LCBhbG9uZyB3aXRo IG90aGVyIGJhbGxvdCBwb3NpdGlvbnMsIGNhbiBiZSBmb3VuZCBoZXJlOgpodHRwczovL2RhdGF0 cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLWkycnMtcHJvdG9jb2wtc2VjdXJpdHktcmVx dWlyZW1lbnRzLwoKCgotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tCkNPTU1FTlQ6Ci0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KCgpGaXJz dCwgYXBvbG9naWVzIGZvciBub3QgZ2V0dGluZyBteSByZXZpZXcgZG9uZSBmb3IKdGhpcyB3aGVu IGl0IHdhcyBzY2hlZHVsZWQgZHVlIHRvIG15IHZhY2F0aW9uIGFuZAp0aGFua3MgZm9yIGJlaW5n IHdpbGxpbmcgdG8gZGVmZXIgdGhlIGRvY3VtZW50LgoKU2Vjb25kLCBoYXZpbmcgbm93IHByb3Bl cmx5IHJldmlld2VkIHRoaXMsIEkgYW0KYmFsbG90aW5nIGFic3RhaW4gYXMgSSB0aGluayBpdCdz IHVubGlrZWx5IHRoYXQgdGhpcwpkb2N1bWVudCBjYW4gYmUgZml4ZWQgaW4gYSB3YXkgdGhhdCBy ZXN1bHRzIGluCnNvbWV0aGluZyB1c2VmdWwgaGFwcGVuaW5nLiBJIHRoaW5rIHRoYXQgdGhlIGxp a2VseQpvdXRjb21lIGlzIHRoYXQgdGhpcyBkb2N1bWVudCB3aWxsIGJlIHVzZWQgbGF0ZXIgd2hl bgpwZW9wbGUgYXJlIGFyZ3VpbmcgYW5kIHdpbGwgbm90IG11Y2ggaGVscCBpbiByZXNvbHZpbmcK dGhvc2UgYXJndW1lbnRzLCBvciBlbHNlIHRoaXMgd2lsbCBiZSBpZ25vcmVkIGFuZAphcmd1bWVu dHMgd2lsbCBiZSBoZWxkIGFmcmVzaCwgYXMgbmVlZGVkLiBUaGF0IGxhdHRlcgpvdXRjb21lIGlz IHdoYXQgSSdkIGd1ZXNzIGlzIG1vc3QgbGlrZWx5IGFuZCB0aGVyZWZvcmUKaXQgc2VlbXMgdGhh dCBzcGVuZGluZyBhbGwgb2Ygb3VyIGN5Y2xlcyBvbiBESVNDVVNTCmJhbGxvdCBwcm9jZXNzaW5n IGZvciB0aGlzIHdvdWxkIG5vdCBiZSB3aXNlLiBUaGF0CnNhaWQsIEkgYW0gd2lsbGluZyB0byBj aGFuZ2UgdG8gYSBESVNDVVNTIGJhbGxvdCBpZiB0aGUKcmVzcG9uc2libGUgQUQgcHJlZmVycyB0 aGF0LCBidXQgSSBzdXNwZWN0IEknbGwgZW5kIHVwCndpdGggYW4gYWJzdGFpbiBpbiBhbnkgY2Fz ZSwgYWZ0ZXIgc29tZSBkaXNjdXNzaW9uLiBUaGUKb25seSBwbGFuIEkgY2FuIHRoaW5rIG9mIHRo YXQnZCBsZWFkIHRvIG1lIGVuZGluZyB1cAp3aXRoIGEgeWVzIG9yIG5vLW9iamVjdGlvbiBiYWxs b3Qgd291bGQgYmUgaWYgdGhpcyB3YXMKcmV0dXJuZWQgdG8gdGhlIFdHIGZvciBmaXhpbmcgYW5k IHBvc3NpYmx5IG1ham9yCnN1cmdlcnksIHdoaWNoIGlzIHdoYXQgSSBhY3R1YWxseSB0aGluayB3 b3VsZCBiZSB0aGUKYmVzdCBwbGFuLiAoSSByZWFsaXNlIHRoaXMgaGFzIGhhZCBhIHNvbWV3aGF0 IHRvcnR1cmVkCmhpc3RvcnksIHNvIGZvbGtzIG1heSBub3QgYmUgd2lsbGluZyB0byB0YWtlIGl0 IGJhY2sgdG8KdGhlIFdHLCBidXQgaG9uZXN0bHksIEkgdGhpbmsgdGhlIGZhaWxpbmdzIHZpc2li bGUgaW4KdGhpcyBkb2N1bWVudCBkbyBpbmRpY2F0ZSB0aGF0IHRoaXMgaXMgbm90IHJlYWR5IGZv cgphcHByb3ZhbCBhbmQgb3VnaHQgYmUgcmV0dXJuZWQgdG8gdGhlIFdHLikKClRoaXJkLCBJIHRo aW5rIHRoZSBvdmVyYWxsIHNldCBvZiByZXF1aXJlbWVudHMgcG9zZWQKaGVyZSBtaWdodCAod2l0 aCBzb21lIHVua25vd24gcHJvYmFiaWxpdHkpIGxlYWQgdG8KbGF0ZXIgc3BlY2lmaWNhdGlvbnMg dGhhdCBhcmUgY29uc2lkZXJlZCB0b28gaGFyZCB0bwpkZXBsb3ksIHdpdGggdGhlIHJlc3VsdCB0 aGF0IG5vbi1zZWN1cmUgdmFyaWFudHMgb2YKSTJSUyBiZWNvbWUgdGhlIG5vcm0uIFRoYXQgc2Vl bXMgbGlrZSBpdCB3b3VsZCBiZSBhCnJlYWxseSBiYWQgb3V0Y29tZS4gSSB3b3VsZCBzdWdnZXN0 IHRoYXQgbWlnaHQgYmUKcGFydGx5IG1pdGlnYXRlZCBpZiBhIHJlcXVpcmVtZW50IHdlcmUgYWRk ZWQgdG8gdGhlCmVmZmVjdCB0aGF0IGRlcGxveW1lbnQgaXNzdWVzIGFuZCBzcGVjaWZpY2FsbHkg ZWFzZSBvZgpkZXBsb3ltZW50IE1VU1QgYmUgY29uc2lkZXJlZCBhcyBhIGZpcnN0IG9yZGVyCnJl cXVpcmVtZW50IHdoZW4gZGV2ZWxvcGluZyBJMlJTIHByb3RvY29sIHNvbHV0aW9ucy4gCgpGb3Vy dGgsIHRoZSAoMTkhKSBjb21tZW50cyBiZWxvdyB0aGF0IGFyZSBwcmVjZWRlZCBieQoiKGRpc2N1 c3MiIHdvdWxkIGhhdmUgYmVlbiBESVNDVVNTIGJhbGxvdCBwb2ludHMgaGFkIEkKbm90IGRlY2lk ZWQgdG8gYWJzdGFpbi4gSSBhbSBoYXBweSB0byBjaGF0IGFib3V0IGFueSBvZgpteSBjb21tZW50 cyBiZWxvdywgYnV0IGlmIHRoZSBhdXRob3JzL1dHIGRvIHdhbnQgdG8KY2hhdCwgaXQgbWlnaHQg YmUgbW9yZSBlZmZpY2llbnQgdG8gY29uY2VudHJhdGUgb24KdGhvc2UgdGhhdCB3b3VsZCBvdGhl cndpc2UgaGF2ZSBiZWVuIERJU0NVU1MgcG9pbnRzLgooQnV0IHRoYXQncyB5b3VyIGNhbGwsIEkg ZG9uJ3QgbWluZC4pIEkgdGhpbmsgdGhlIDE5CndvdWxkLWhhdmUtYmVlbi1kaXNjdXNzIHBvaW50 cyBpcyBhbm90aGVyIGNsdWUgdGhhdAp0aGlzIG91Z2h0IHJlYWxseSBiZSBzZW50IGJhY2sgdG8g dGhlIFdHLgoKQW5kIHdpdGggdGhhdCwgYW5kIHdpdGggYXBvbG9naWVzIGZvciB0aGlzIGJlaW5n IHN1Y2gKYW4gb3ZlcmFsbCBuZWdhdGl2ZSByZXZpZXcsIGhlcmUncmUgbXkgZGV0YWlsZWQKY29t bWVudHM6CgotIGdlbmVyYWw6IFRoZSB3cml0aW5nIGhlcmUgaXMgZ2VuZXJhbGx5IHBvb3IsIGZv cgpleGFtcGxlIHRoZSBvcGVuZXIgaXMgIlRoaXMgcHJlc2VudHMuLi4iIHdoZXJlYXMgaXQKb3Vn aHQgYmUgIlRoaXMgZG9jdW1lbnQgcHJlc2VudHMuLi4iIChvcgpzL2RvY3VtZW50L3doYXRldmVy IHlvdSBwcmVmZXIvKS4gU3VjaCBpc3N1ZXMgYXJlCnJlcGVhdGVkbHkgc2VlbiBhbmQgYWxsIHRo YXQgbWFrZXMgdGhpcyBhIG11Y2ggaGFyZGVyCnJlYWQgdGhhbiBvdWdodCBiZSB0aGUgY2FzZS4g SSdkIHN0cm9uZ2x5IHJlY29tbWVuZCBhbgplZGl0b3JpYWwgcGFzcyBmcm9tIHNvbWVvbmUgd2hv IGhhc24ndCBiZWVuIGRvd24gaW4gdGhlCndlZWRzIHdpdGggdGhpcyB0ZXh0IGZvciBhIHdoaWxl ICh3aGljaCBjb3VsZCBiZSBvbmUgb2YKdGhlIGF1dGhvcnMsIGlmIG9uZSBvZiB0aGVtIGhhcyBi ZWVuIGxlc3MgYWN0aXZlCnJlY2VudGx5LikgTm90ZSB0aGF0IHRoaXMgaXMgbm90IG9ubHkgKGJ1 dCBpcwpwcmltYXJpbHkpIGFuIGVkaXRvcmlhbCBpc3N1ZSAtIHRoZXJlIGFyZSBzb21lIGNhc2Vz Cihob3BlZnVsbHkgY2FsbGVkIG91dCBiZWxvdykgd2hlcmUgdGhlIHdyaXRpbmcgZG9lcwpjcmVh dGUgcmVhbCBhbWJpZ3VpdHkgdGhhdCBtaWdodCBsZWFkIHRvIHJlLW9wZW5pbmcgb2xkCmFyZ3Vt ZW50cyBsYXRlci4KCi0+IGFic3RyYWN0OiAibXV0dWFsIGF1dGhlbnRpY2F0aW9uLCB0cmFuc3Bv cnQKPiBwcm90b2NvbHMsIGRhdGEgdHJhbnNmZXIgYW5kIHRyYW5zYWN0aW9ucyIgZG9uJ3Qgc2Vl bQo+dG8gbWUgdG8gYmUgY29tbWVuc3VyYXRlIHRoaW5ncywgc28gdGhlIGFic3RyYWN0LCBhcyB3 cml0dGVuIGlzIHZlcnkgdW5pbmZvcm1hdGl2ZSBmb3IgbWUuCgpDYW4geW91IHN1Z2dlc3Qgd2hh dCBrZXJuZWwgb2YgaW5mb3JtYXRpb24geW91IHdvdWxkIGRlZW0gdXNlZnVsIGluIHRoZSBhYnN0 cmFjdD/CoAoKCj4gaW50cm8gM3JkIHBhcmE6IEknbSByZWFsbHkgbm90IHN1cmUgd2hhdCB5b3Un cmUKPnRlbGxpbmcgbWUgYWJvdXQgW0ktRC5pZXRmLWkycnMtZXBoZW1lcmFsLXN0YXRlXS4gwqA+ VGhlIGRyYWZ0IFtSRkM3OTIyXSIgaXMgb2RkLCB0aGF0IGJlaW5nIG5vIGxvbmdlciBhIGRyYWZ0 LsKgCj4gSSdkIGhhdmUgZXhwZWN0ZWQgc3VjaCBuaXRzIHdvdWxkIGhhdmUgYmVlbiBmaXhlZCBi eSDCoHJvdyBUQkguIFNhbWUgZm9yIHRoZSBsYXN0IHNlbnRlbmNlLsKgIFRoYXQgcGFyYSBtYWtl c8KgCjx0aGUgaW50cm8gcHJldHR5IHVuY2xlYXIgZm9yIG1lLgpUaGFuayB5b3UgZm9yIHRoYXQg aW5wdXQuIMKgSSB3aWxsIGZpeCB0aGF0IGluIHZlcnNpb24gMTAuIMKgCgo+IDIuMjogVGhlIGRl ZmluaXRpb24gb2YgaGlnaGVyIGxldmVsIHByb3RvY29sIHNlZW1zCmxpa2UgYW4gb2RkIHBsYWNl IHRvIGludHJvZHVjZSB0aGUgZmFjdCB0aGF0IGkycnMgPT0KPm5ldGNvbmYgKyByZXN0Y29uZi7C oCBUaGF0J2QgYmUgbW9yZSB1c2VmdWxseSBzYWlkIGluCnRoZSBhYnN0cmFjdC9pbnRybyBpZiB0 aGF0J3Mgc29saWRseSBhZ3JlZWQgYnkgdGhlIFdHLgoKVGhlIHJlYXNvbiB0aGlzIGlzIGludHJv ZHVjZWQgaGVyZSBpcyB0byBsaW5rIHRvIHN0YXRlbWVudHMgaW4gdGhlIGFyY2hpdGVjdHVyZSBk b2N1bWVudC4gVGhlIGluaXRpYWwgcHJvdG9jb2xzIG1heSBiZSBuZXRjb25mIGFuZCByZXN0Y29u ZiwgYnV0IG90aGVyIHByb3RvY29scyB3aWxsIGZvbGxvdy4gwqBJIHdpbGwgcHJvdmlkZSBhbiBp bXByb3ZlZCB0ZXh0IGluIHZlcnNpb24gMTAuCgo+IDIuMjogVGhpcyBpcyB3cm9uZzogIldoaWxl IGl0IGlzIHBvc3NpYmxlIHRvIGhhdmUgYW4KSTJSUyBvcGVyYXRpb24gd2hpY2ggaXMgY29udGFp bmVkIGluIG11bHRpcGxlIEkyUlMKKEUuZy7CoCB3cml0ZSBpbiBtdWx0aXBsZSBtZXNzYWdlcyks IHRoaXMgaXMgbm90CnN1cHBvcnRlZCBpbiBvcmRlciB0byBzaW1wbGlmeSB0aGUgZmlyc3QgdmVy c2lvbiBvZgpJMlJTLiIgVGhlIHJlYXNvbiB0aGlzIGlzIHdyb25nLCBpcyB0aGF0IGl0IGlzIGhl cmUKdGhhdCB5b3UgYXJlIGRlZmluaW5nIHRoYXQgaXQgaXMgbm90IHBvc3NpYmxlIHRvIGhhdmUK YW4gb3BlcmF0aW9uIGluIG11bHRpcGxlIG1lc3NhZ2VzLiBzL2l0IGlzL2l0IGNvdWxkCmhhdmUg YmVlbi8gd291bGQgd29yayBtYXliZS4KClN0ZXBoZW46IFdlIGFyZSB3b3JraW5nIG9uIGEgcmUt dXNlIHByb3RvY29sIGZvciBORVRDT05GLCBSRVNUQ09ORiwgSVBGSVgsIEZvcmNlcyBhbmQgb3Ro ZXIgcHJvdG9jb2xzLiDCoEl0IGlzIHRlY2huaWNhbGx5IHBvc3NpYmxlIHRvIGRlZmluZSBhbiBv cGVyYXRpb24gd2hpY2ggc3BhbnMgbXVsdGlwbGUgbWVzc2FnZXMuIMKgIEFuZCB3ZSBhcmUgbGlt aXRpbmcgdGhlIGZpcnN0IHZlcnNpb24gb2YgdGhpcyBwcm90b2NvbCB0byBvbmUgbWVzc2FnZS4g wqBQbGVhc2UgY2xhcmlmeSB3aGF0IHlvdSB3aXNoIGFkZGVkLgoKPi0gMi4yOiAiICrCoCBUaGUg STJSUyBjbGllbnQgaXNzdWVzIGEgcmVhZCByZXF1ZXN0IHRvIGEKSTJSUyBhZ2VudCwgYW5kIHRo ZSBJMlJTIEFnZW50IHJlc3BvbmRpbmcgdG8gdGhlIHJlYWQgcmVxdWVzdCIgU2hvdWxkbid0IHRo YXQgdXNlIHJlc3BvbmQgYW5kIG5vdCByZXNwb25kaW5nPyDCoEdpdmVuIHRoYXQgeW91IHNlZW0g dG8gYmUgdHJ5aW5nIHRvIGRlZmluZSB0aGUgc2NvcGUgb2YgwqB3aGF0IGlzIGFuZCBpcyBub3Qg YSB0cmFuc2FjdGlvbiwgSSB0aGluayBiZWluZyBwcmVjaXNlwqB3aXRoIHRoZSBsYW5ndWFnZSBp cyBzb21ldGhpbmcgd2VsbCB3b3J0aCBkb2luZy7CoCBUaGUgMm5kIGJ1bGxldCBjb3VsZCBhbHNv IGRvIHdpdGggYSByZS13cml0ZS4KU3VlJ3MgcmVzcG9uZHM6IFRoZSBsYW5ndWFnZSB3YXMgY2hv c2VuIGNhcmVmdWxseS4gwqBBbiBvdmVybG9hZGVkIEkyUlMgYWdlbnQgaGFzIHRoZSBvcHRpb24g bm90IHRvIHJlYXBvbmQuIMKgVGhlcmZvcmUsIHRoZSBwaHJhc2UgInRoZSBJMlJTIEFnZW50IHJl c3BvbmRpbmcgdG8gdGhlIHJlYWQgcmVxdWVzdCIgaXMgYSBtb3JlIGFwcHJvcHJpYXRlIHBocmFz ZS4KPihkaXNjdXNzMSkgMi4yOiB5b3Ugc29ydC1vZiBkZWZpbmUgbWVzc2FnZXMsCm9wZXJhdGlv bnMsIHRyYW5zYWN0aW9ucyBhbmQgYWN0aW9ucy4gTm9uZSBvZiB0aGUKZGVmaW5pdGlvbnMgYXJl IHRoYXQgcHJlY2lzZSwgZS5nLiBhcmUgdGhvc2UgdGhlIG9ubHkKb3BlcmF0aW9ucyBvciBleGFt cGxlcz8gQW5kIHRyYW5zYWN0aW9uIGFuZCBhY3Rpb24KYXJlbid0IHJlYWxseSBkZWZpbmVkIGF0 IGFsbC4gSSdtIG5vdCBzdXJlIGlmIHRoYXQncwpsaWtlbHkgdG8gYmUgYSBwcm9ibGVtIG9yIG5v dC4gSSBzdXNwZWN0IGl0IHdpbGwgbGF0ZXIsCmUuZy4gd2hlbiB5b3UgZ2V0IHRvIGZpZ3VyaW5n IG91dCB0aGUgc2NvcGUgd2l0aGluCndoaWNoIHJlcGxheSBuZWVkcyB0byBiZSBkZXRlY3RhYmxl LgpTdWUncyByZWFwb25zZTrCoCBXZSBuZWVkIHRvIGdvIHRvIGEgbWV0YSBsZXZlbCBmaXJzdCB0 byBhbnN3ZXIgdGhpcyBxdWVzdGlvbi4gwqBJMlJTIGlzIGEgcmUtdXNlIHByb3RvY29sLiDCoEZv ciBlYWNoIHByb3RvY29sIHRoZXNlIG1lc3NhZ2VzIHdoaWNoIGVuY29kZSBzcGVjaWZpYyB0cmFu c2FjdGlvbnMgdGhhdCBhcmUgYSBzZXF1ZW5jZSBvZiByZWFkLCB3cml0ZSwgcnBjLCBvciBldmVu dCBhY3Rpb25zLiDCoFdlIGFyZSBkZWZpbmluZyB0aGUgaGlnaGVyIGxldmVsIHByb3RvY29sIHRo YXQgd2lsbCBiZSB0cmFuc2xhdGVkIGludG8gZWFjaCBsYW5ndWFnZSB2aWEgZXh0ZW5zaW9ucy4g wqAgU28uLiB3aGF0IHByZWNpc2VseSBmaXRzIHRoZSBkaXNjdXNzIGNyaXRlcmlhIGhlcmU/IMKg QXJlIHlvdSBsb29raW5nIGZvciB0cmFuc2FjdGlvbnMgYW5kIGFjdGlvbnMgdG8gYmUgZGVmaW5l ZD8gwqBIb3cgZG9lcyB0aGlzIGltcGFjdCB0aGUgcmV2aWV3IG9mIHRoZSBJMlJTIHByb3RvY29s IHNlY3VyaXR5wqAKLSAyLjI6IHMvdHJhbnNhdGlvbi90cmFuc2FjdGlvbi8KCj4oZGlzY3VzczIp IC0gMi4yOiAiZGVmaW5lcyBhIHNlY29uZGFyeSBpZGVudGl0eSBhcyB0aGUKZW50aXR5IG9mIHNv bWUgbm9uLUkyUlMgZW50aXR5ICIgVGhhdCBjb3VsZCBiZSBhYnVzZWQKZm9yIHRyYWNraW5nIG9m IHZhcmlvdXMga2luZHMgSSB3b3VsZCBndWVzcywgZS5nLiBpZiBhbgpJTUVJIHdlcmUgdXNlZC4g SSB0aGluayB5b3UgbmVlZCB0byBub3RlIHRoYXQgYW5kCnNob3VsZCBpbXBvc2Ugc29tZSByZXF1 aXJlbWVudHMgdGhhdCBzdWNoIHNlY29uZGFyeQppZGVudGlmaWVycyBhcmUgbm90IHVzZWQgdGh1 c2x5IGZvciB0cmFja2luZy7CoCBBbHNvLApzaG91bGQgdGhlIGZpcnN0IG9jY3VycmVuY2Ugb2Yg ZW50aXR5IHRoZXJlIGJlCmlkZW50aXR5PwpTdWUgcmVzcG9uc2U6IMKgSW4gb3JkZXIgdG8gYmUg cHJlY2lzZSBpbiBteSBhbnN3ZXIsIEkgd2lsbCBuZWVkIHlvdSB0byBkZWZpbmUgSU1FSS4gwqBU aGVzZSBub24tSTJSUyBlbnRpdGllcyBhcmUgYXR0YWNoZWQgdG8gYSB2YWxpZCBpMnJzIGNsaWVu dCB3aXRoIGEgbXV0dWFsbHkgYXV0aGVudGljYXRlZCBpZGVudGl0eSBzaWduYWxlcyBieSB0aGUg aWRlbnRpZmllciAoY2xpZW50IG9yIGFnZW50KS4gwqBUaGUgY29ubmVjdGlvbiBvZiB0aGUgYXBw bGljYXRpb24gdG8gdGhlIGkycnMgY2xpZW50IGlzIG91dHNpZGUgdGhlIHNjb3BlIG9mIHRoZSBJ MlJTIHByb3RvY29sLiDCoFRoZSBzZWNvbmRhcnkgaWRlbnRpZmllcnMgYXJlIHVzZSBmb3IgdHJh Y2tpbmcgb2YgdGhlIGFwcGxpY2F0aW9uIGluIHRoZSB0cmFjZWFiaWxpdHkgbWVjaGFuaXNtLiDC oCBTby4uIGFnYWluIEkgYW0gdW5jbGVhciByZWdhcmRpbmcgd2hhdCB5b3UgYXJlIGNvbmNlcm5l ZCBhYm91dCBhbmQgd2hhdCBtYWtlcyB0aGlzIGEgRElTQ1VTUyBiYXNlZCBvbiB0aGUgRElTQ1VT UyBjcml0ZXJpYS4KLT4gMywgMXN0IHBhcmE6IHMvVGhlIHNlY3VyaXR5IGZvciB0aGUvVGhlLyAt IHRoZXJlCmlzbid0IGEgdGhpbmcgY2FsbGVkIHRoZSBzZWN1cml0eSBmb3IgdGhlIGkycnMKcHJv dG9jb2wuClN1ZTogwqBXaHkgbm90PyDCoFBsZWFzZSBleHBsYWluLiDCoFdlIGFyZSBkZWZpbmlu ZyBhIHJlLXVzZSBwcm90b2NvbCB3aXRoIGV4dGVuc2lvbnMgdG8gb3RoZXIgcHJvdG9jb2xzLiDC oFdoeSBkb2VzIHRoZSBjb21wb3NpdGUgcHJvdG9jb2wgbm90IGhhdmUgYSBsZXZlbCBvZiBzZWN1 cml0eSBvciBzZWN1cml0eSBjb25zaWRlcmF0aW9ucz8gwqBQbGVhc2UgZXhwbGFpbiB3aGF0IHlv dSBkZXNpcmUgaGVyZS4KPihkaXNjdXNzMykgLSBzZWN0aW9uIDMgc2F5cyAidGhlIEkyUlMgcHJv dG9jb2wgcmVxdWlyZXMKbXV0dWFsbHkgYXV0aGVudGljYXRlZCBJMlJTIGNsaWVudHMgYW5kIEky UlMgYWdlbnRzCmNvbW11bmljYXRpbmcgb3ZlciBhIHNlY3VyZSB0cmFuc3BvcnQuIiBUbyBtZSB0 aGF0CmltcGxpZXMgdGhhdCBzb21ldGhpbmcgbGlrZSBUTFMgb3IgU1NIIGlzIE1UVSB3aGljaApz ZWVtcyB0byBjb250cmFkaWN0IHJlY2VudCBlbWFpbHMuCgpTdWU6IEp1c3QgdG8gYmUgY2xlYXIs IHlvdSBhcmUgbm90IG9iamVjdGluZyB0byB0aGUgdGV4dCB5b3UgaW5kaWNhdGUgLWJ1dCB5b3Vy IHVuZGVyc3RhbmRpbmcgZnJvbSB0aGUgZW1haWwuCkFuIEkyUlMgYWdlbnQgaGFzIE1UVSBzZWN1 cmUgdHJhbnNwb3J0IG9mIFRMUyBvciBTU0guIMKgQW55IEkyUlMgY2xpZW50IGFjY2Vzc2luZyBh bnkgZGF0YSBtb2RlbCB3aGljaCBoYXMgbWl4dHVyZSBvZiBzZWN1cmUgYW5kIG5vbi1zZWN1cmUg ZGF0YSBoYXMgYW4gTVRVIG9mIGEgc2VjdXJlIHRyYW5zcG9ydCDCoChUTFMgb3Igc3NoKS4gwqBB bnkgaTJycyBjbGllbnQgYWNjZXNzaW5nIGFuIGkycnMgYWdlbnQgaW4gYW4gZW52aXJvbm1lbnQg dGhhdCB3aGVyZSB0aGUgbmV0d29yayBpbmZvIG1pZ2h0IGJlIGxpbmtlZCB0byBhIHBlcnNvbicg aWRlbnRpdHkgaGFzIGEgTVRVIG9mIHNlY3VyZSB0cmFuc3BvcnQuIMKgClRoZSBvbmx5IHRpbWUg dGhlIEkyUlMgY2xpZW50IGlzIGFsbG93ZWQgdG8gaGF2ZSBhIG5vbi1zZWN1cmUgdHJhbnNwb3J0 IGlzIGlmIHRoZSBvbmx5IHRoaW5nIGl0IGlzIGFjY2Vzc2luZyBpcyBub24tc2VjdXJlIGRhdGEu IMKgV2UgY3VycmVudGx5IGhhdmUgbm8gaTJycyBkYXRhIG1vZGVscyB3aGljaCBoYXZlIG5vbi1z ZWN1cmUgZGF0YS4KPiBzZWN0aW9uIDMgc2F5czogIlRoZSBJMlJTIHByb3RvY29sIE1VU1QgYmUg YWJsZSB0bwpwcm92aWRlIGF0b21pY2l0eSBvZiBhbiBJMlJTIHRyYW5zYWN0aW9uLCBidXQgaXQg aXMgbm90CnJlcXVpcmVkIHRvIGhhdmUgbXVsdGktbWVzc2FnZSBhdG9taWNpdHkgYW5kIHJvbGwt YmFja8KgbWVjaGFuaXNtIHRyYW5zYWN0aW9ucy7CoCBNdWx0aXBsZSBtZXNzYWdlcyB0cmFuc2Fj dGlvbnMgbWF5IGJlIGltcGFjdGVkIGJ5IHRoZSBpbnRlcmRlcGVuZGVuY3kgb2YgZGF0YS4iIMKg Cj4gSSBkb24ndCBiZWxpZXZlIHRoYXQgdGhhdCdzIGVhc2lseSBlbm91Z2ggdW5kZXJzdG9vZCB0 byBiZcKgdXNlZnVsLiBBbHNvLCB3b3VsZG4ndCBzL011bHRpcGxlIG1lc3NhZ2VzCnRyYW5zYWN0 aW9ucy9NdWx0aXBsZS1tZXNzYWdlIHRyYW5zYWN0aW9ucy8gYmUgbXVjaCBjbGVhcmVyIGlmIHRo YXQncyB3aGF0J3MgbWVhbnQ/IEFuZCBmaW5hbGx5LCBJIHRoaW5rIHRoZSBNVVNUIGVtYmVkZGVk IGluIHRoZSBhYm92ZSBpcyBub3QgdGhhdCBncmVhdCBhIGlkZWEgLSBpdCdzIGNsZWFyZXIgSU1P IHRvIHNlcGFyYXRlIHRoZSAyMTE5IGxhbmd1YWdlIGZyb20gaW50cm9kdWN0b3J5IHRleHQgaW4g ZG9jdW1lbnRzIGxpa2UgdGhpcy4KU3RlcGhlbjogwqBUaGUgbGFuZ3VhZ2Ugd2FzIHNwZWNpZmll ZCBieSBhIGZldyBpbXBsZW1lbnRlcnMgZG9pbmcgSTJSUyB3b3JrLgpJIGJlbGlldmUgeW91IGRv IG5vdCB1bmRlcnN0YW5kIEkyUlMgdHJhbnNhY3Rpb25zIHZlcnN1cyBtZXNzYWdlcy4gwqBUcmFu c2FjdGlvbnMgY2FuIGJlIHNldHRpbmcgYSB2YWx1ZSwgcnBjIHRvIGFkZCBhIHNldCBvZiB2YWx1 ZXMsIGFuZCBzdGFydGluZyBhbiBldmVudCBzdHJlYW0uIMKgRWFjaCB0cmFuc2FjdGlvbiBtdXN0 IGVpdGhlciB3b3JrIG9yIG5vdCB3b3JrIGFzIGFuIGluZGVwZW5kZW50IHVuaXQuIMKgIFRoaXMg aXMgbm90IHRoZSBzYW1lIGFzIHNlbmRpbmcgdGhpcyBtZXNzYWdlcyB3aXRoIGEgc2V0IG9mIGNv bW1hbmRzIGFuZCBiZWluZyBhYmxlIHRvIHJvbGxiYWNrIHRvIHRoZSBiZWdpbm5pbmcgb2YgdGhv c2UgNSBjb21tYW5kcy4gwqBTb21lIHByb3RvY29sIEkyUlMgwqBtYXkgc3VwcG9ydCB0aGlzIGxl dmVsIG9mIGNoZWNrcG9pbnRzLSBidXQgaXQgaXMgbm90IGEgcmVxdWlyZW1lbnQuCi0gMzogIlRo ZXJlIGFyZSBkZXBlbmRlbmNpZXMgaW4gc29tZSBvZiB0aGUKcmVxdWlyZW1lbnRzIGJlbG93IiB3 b3VsZCBiZSBiZXR0ZXIgYXMgIlRoZXJlIGFyZQppbnRlci1kZXBlbmRlbmNpZXMgYmV0d2VlbiBz b21lIG9mIHRoZSByZXF1aXJlbWVudHMKYmVsb3ciIHVubGVzcyB5b3UgbWVhbiBkZXBlbmRlbmNp ZXMgb24gc29tZSBleHRlcm5hbAp0aGluZ3MsIHdoaWNoIGlzIG5vdCBjbGVhciBmcm9tIHRoZSB0 ZXh0IGFzLWlzLgpTdWU6IFRoYW5rIHlvdSBmb3IgdGhlIGlucHV0LgoKPiDCoChkaXNjdXNzNCkg IiBGb3IgY29uZmlkZW50aWFsaXR5IChzZWN0aW9uIDMuMykgYW5kCmludGVncml0eSAoc2VjdGlv biAzLjQpIHRvIGJlIGFjaGlldmVkLCB0aGUKY2xpZW50LWFnZW50IG11c3QgaGF2ZSBtdXR1YWwg YXV0aGVudGljYXRpb24gKHNlY3Rpb24KMy4xKSBhbmQgc2VjdXJlIHRyYW5zcG9ydCAoc2VjdGlv biAzLjIpLsKgICIgVGhpcyBpcwppbmNvcnJlY3QuIE9uZSBjYW4gaGF2ZSBjb25maWRlbnRpYWxp dHkgd2l0aG91dAphdXRoZW50aWNhdGlvbiAoc2VlIFJGQzc0MzUpIHNvIHRoZSB0ZXh0IGlzIG5v dAphY2N1cmF0ZS4KU3VlOiDCoFRoZSBjb25kaXRpb25hbCBzZW50ZW5jZSBhYm92ZSBoYXMgYSBj b21wb3VuZCBub3VuLi0gImNvbmZpZGVudGlhbGl0eSBhbmQgaW50ZWdyaXR5IiAtIGNhbiB5b3Ug aGF2ZSBib3RoIHdpdGhvdXQgYXV0aGVudGljYXRpb24/IMKgUGxlYXNlIGNvbmZpcm0uCi0+IGNh cGl0YWxpc2F0aW9uIG5lZWRzIGZpeGluZyBpbiB2YXJpb3VzIHBsYWNlcywgZS5nLgphcm91bmQg dGhlIGVuZCBvZiBwNSwgd2UgZ2V0ICJzZWN1cmUgVHJhbnNwb3J0IiBhbmQKdGhlbiAiSTJSUyBj bGllbnQiIGFuZCAiSTJSUyBBZ2VudCIgaW4gdGhlIHRpdGxlIG9mIDMuMQpJcyBhbnkgb2YgdGhh dCBjYXBpdGFsaXNhdGlvbiBzdXBwb3NlZCB0byBiZQpzaWduaWZpY2FudD8gRWl0aGVyIHdheSwg Zml4aW5nIGl0IG5vdyB3b3VsZCBiZSBnb29kIGFzwqAKeW91J2xsIG5lZWQgdG8gZ2V0IHRoZSBS RkMgZWRpdG9yIHRvIGRvIGl0IGxhdGVyIGlmIHlvdQpkb24ndCAod2hpY2ggdGFrZXMgbG9uZ2Vy KS4KU3VlOiBUaGFuayB5b3UgZm9yIHRoaXMgZWRpdG9yaWFsIGNvcnJlY3Rpb24uIMKgVmVyc2lv biAxMCB3aWxsIGFkZHJlc3MgdGhpcwoKPihkaXNjdXNzNSkgU0VDLVJFUS0wMTogd2hhdCBpcyB0 aGUgc2NvcGUgb2YgdW5pcXVlbmVzcwpyZXF1aXJlZCBoZXJlPyBJIHNlZSBubyByZWFzb24gd2h5 IHR3byBkaWZmZXJlbnQgZGF0YQpjZW50cmVzIGNhbm5vdCByZS11c2UgYSBjbGllbnQgb3IgYWdl bnQgaWRlbnRpZmllciwgaWYKdGhleSBzbyB3aXNoLiBJJ2QgYmUgZmluZSBpZiB5b3Ugc2F5IHRo YXQncyBmb3IgbGF0ZXIKZGVjaXNpb24sIGJ1dCBiZWluZyBzaWxlbnQgb24gdGhlIG1hdHRlciBj b3VsZCBsZWFkIHRvCnRyb3VibGUgbGF0ZXIgaWYgZGlmZmVyZW50IGZvbGtzIGRlY2lkZSBkaWZm ZXJlbnRseS4KU3VlOiDCoFRoaW5ncyB3YW5kZXIgb3V0IG9mIGEgZGF0YSBjZW50ZXIgaW50byB0 aGUgSW50ZXJuZXQuIMKgTWFuYWdlbWVudCBwcm90b2NvbHMgaGF2ZSB3YW5kZXJlZCBvdXQgaW4g dGhlIHBhc3QuIMKgVGhlIHNhZmVzdCBtZWNoYW5pc20gaXMgdG8gYmUgdXR0ZXJseSB1bmlxdWUu IMKgaWYgZGVwbG95bWVudHMgY2hvb3NlIGxlc3MgdGhhdCB0aGF0LCB0aGUgc2VjdXJpdHkgbmV0 d29yayBkZXNpZ25lciBtdXN0IGRvIHJpc2svcmV3YXJkIGNob2ljZS4gwqBPciBwZW9wbGUgbWF5 IGRlY2lkZSB0byBjb25uZWN0IDIgZGF0YSBjZW50ZXJzIGR1ZSB0byBhbiBlbWVyZ2VuY3kgYW5k IGZvcmdldCB0aGUgTWFuYWdlbWVudCBzeXN0ZW0gaWRlbnRpZmllcnMgb3ZlcmxhcC4gwqBBbmQg dGhlbiB0aGUgbmV0d29yayBzeXN0ZW1zIHN0YXJ0IGludGVyYWN0aW5nLiDCoE9vcHNBbnl0aGlu ZyBsZXNzIHRoYW4gY29tcGxldGUgdW5pcXVlbmVzcyBjYW4gZ28gYmFkLgoKPT09PT09PSByZXNw b25zZSBlbmRzIGhlcmU9PT09PT09PQooZGlzY3VzczYpIFNFQy1SRVEtMDI6IHRoZSAiTVVTVCB1 dGlsaXplIiB0aGVyZSBtZWFucwpNVFUsIHdoaWNoIHdhc24ndCB3aGF0IHlvdSB3YW50ZWQgSSB0 aGluawoKKGRpc2N1c3M3KSAtIFNFQy1SRVEtMDM6IGhvdyBpcyAidXBvbiByZWNlaXZpbmcuLi4g TVVTVApjb25maXJtIiBhIGdvb2QgY2hvaWNlPyBBcyBzdGF0ZWQgdGhhdCdkIGJlIGh1Z2VseQpv bmVyb3VzLCBpbXBseWluZyBlLmcuwqAgT0NTUCBjaGVja3MgZm9yIGVhY2ggcGFja2V0CnJlY2Vp dmVkLiBTYW1lIHBvaW50IGFwcGxpZXMgdG8gU0VDLVJFUS0wNC4KCihkaXNjdXNzOCkgLSBTRUMt UkVRLTA1OiB0aGlzIGVpdGhlciBtZWFucyBub3RoaW5nIGF0CmFsbCAoYmVpbmcgYSB0YXV0b2xv Z3kpIG9yIGVsc2Ugc29tZXRoaW5nIEkgZG9uJ3QgZ2V0LgpJIHRoaW5rIGl0J3MgdGhlIGZvcm1l ciwgYnV0IGFtIG5vdCBzdXJlLgoKLSAzLjE6IHMvT25lIG1lY2hhbmlzbSBzdWNoIG1lY2hhbmlz bS9PbmUgc3VjaAptZWNoYW5pc20vIEkgZ3Vlc3MuIEFuZCBpdCdzIG5vdCBhdCBhbGwgY2xlYXIg dG8gbWUKIkFBQSBwcm90b2NvbHMiIGlzIHRoZSByaWdodCBpZGVhIHRoZXJlLCBhbmQgbm9yIGlz IGl0CmNsZWFyIHdoYXQncyBtZWFudCwgd2l0aCB0aGUgdGV4dCBhcy1pcy4KCi0gU0VDLVJFUS0w Njogd2hlcmUgaXMgYSAicHJpb3JpdHkiIGRlZmluZWQ/CgotIFNFQy1SRVEtMDc6IGhlcmUgeW91 IHNheSByZWFkL3dyaXRlIGlzIGEgdHJhbnNhY3Rpb24sCmJ1dCBlYXJsaWVyIHlvdSBzYWlkIGl0 IHdhcyBhbiBvcGVyYXRpb24sIHdoaWNoIGlzIGl0PwoKKGRpc2N1c3M5KSAzLjI6IEFzIHdpdGgg b3RoZXJzLCBJIGRvbid0IHRoaW5rIHRoZSBpZGVhCm9mIGFubm90YXRpbmcgcGFydHMgb2YgeWFu ZyBtb2R1bGVzIHdpdGggImNhbiBiZQppbnNlY3VyZSIgaXMgYSBnb29kIG9uZS4gVGhlcmUncyBh IHNlcGFyYXRlIHRocmVhZApkaXNjdXNzaW5nIHRoYXQgdGhvdWdoLCBzbyBtYXliZSBiZXR0ZXIg dG8gbm90IGZvcmsKdGhhdC4gCgooZGlzY3VzczEwKSAtIFNFQy1SRVEtTzk6IEkgaGF0ZSB0byBk byB0aGlzIHRvIHlhLCBidXQKQkNQMTA3IGlzIElNTyBhIGZhaXJseSBjbGVhciBmYWlsdXJlIHdo ZW4gaXQgY29tZXMgdG8Kcm91dGluZy4gQW5kIHlldCBhZ2FpbiB0aGUgZXhjZXB0aW9ucyBjbGF1 c2VzIGhlcmUgYXJlCnNvIGJyb2FkIGFzIHRvIGJlIG1lYW5pbmdsZXNzIChlLmcuIGNvbnNpZGVy ZWQgbG93CnZhbHVlIGJ5IHdob20/KS4gV2hhdCBpcyB0aGUgcmVhbCBnb2FsIGhlcmU/IChvdGhl cgp0aGFuIGFuIGF0dGVtcHQgdG8ga2VlcCB0aGUgc2VjIEFEcyBmcm9tIGJlaW5nIGFubm95aW5n CmFuZCB0cnlpbmcgdG8gaW5zaXN0IG9uIEJDUDEwNz8gOy0pIAoKKGRpc2N1c3MxMSkgLSBTRUMt UkVRLTA5OiBTZXBhcmF0ZWx5LCB0byBteSBvdGhlcgp3b3VsZC1iZS1kaXNjdXNzIHBvaW50IG9u IHRoaXMgcmVxdWlyZW1lbnQsICJjYW4KZ3VhcmFudGVlIiBpcyB3ZWxsIGJleW9uZCB0aGUgc3Rh dGUgb2YgdGhlIGFydCBpbiBrZXkKbWFuYWdlbWVudC4gSSdkIGp1c3QgZHJvcCB0aGF0IHNlbnRl bmNlIG1heWJlLCBidXQKY2FuJ3QgbWFrZSBhIGNvbmNyZXRlIHN1Z2dlc3Rpb24gdW50aWwgSSB1 bmRlcnN0YW5kCndoZXJlIHlvdSB3YW50IHRvIGJlIHdydCBCQ1AxMDcuCgotIFNFQy1SRVEtMTA6 IHRoZSBsYXN0IHNlbnRlbmNlIGhlcmUgaXMgYWxzbyBpbnZvbHZlZAppbiB0aGUgIm1heSBkbyBz dHVmZiBpbnNlY3VyZWx5IiB0aGluZywgYW5kIHNvIHdpbGwKbGlrZWx5IG5lZWQgZml4aW5nIHdo ZW4gdGhhdCBpcyBmdWxseSByZXNvbHZlZC4KCi0gSG93IGlzIFNFQy1SRVEtMTEgdXNlZnVsPyBX aGF0IHByb3RvY29sIGFydGVmYWN0cyBkbwp5b3UgaGF2ZSBpbiBtaW5kIGhlcmU/IFBlcmhhcHMg YSByZXF1aXJlbWVudCB0aGF0IEREb1MKYXR0YWNrcyBiZSBzcGVjaWZpY2FsbHkgY29uc2lkZXJl ZCBpbiBJMlJTIHdvdWxkIGJlCm1vcmUgdXNlZnVsLgoKLSBTRUMtUkVRLTEyOiBUaGlzIHNlZW1z IHRvIG1lIHRvIGhhdmUgdG9vIG1hbnkgd29yZHMsCmUuZy4gdGhlIGN1cnJlbnQgdGV4dCBjb3Vs ZCBiZSByZWFkIHRvIGltcGx5IHRoYXQKb3V0c2lkZSBvZiBjcml0aWNhbCBpbmZyYXN0cnVjdHVy ZSB0aGVyZSBpcyBsZXNzIG9yIG5vCm5lZWQgZm9yIGNvbmZpZGVudGlhbGl0eSwgc28gdGhvc2Ug YWRkZWQgd29yZHMKKHByZXN1bWFibHkgdGhlcmUgdG8gbW90aXZhdGUpIG1pZ2h0IGJlCmNvdW50 ZXItcHJvZHVjdGl2ZS4gCgooZGlzY3VzczEyKSBTRUMtUkVRLTEyOiBJIGRvbid0IGdldCB0aGUg bWVhbmluZyBvZiB0aGUKU0hPVUxEIGhlcmUgLSBjb21iaW5lZCB3aXRoICJjZXJ0YWluIGRhdGEi IHRoYXQgU0hPVUxECnNlZW1zIHRvIGVuZCB1cCBtZWFuaW5nIE1BWSwgYXMgaW4sIGl0IHNlZW1z IHRvIG1lYW4KdGhlIHNhbWUgYXMgIlJlYWQvd3JpdGUgb3BlcmF0aW9ucyBNQVkgaGF2ZSB0byBi ZQpwcm90ZWN0ZWQgdXNpbmcgYSBjb25maWRlbnRpYWxpdHkgc2VydmljZS4iCgotIDMuNCwgYnVs bGV0ICgyKSBoZXJlIG1lYW5zIHRoYXQgd2UncmUgbm90IHRhbGtpbmcKYWJvdXQgZGF0YSBpbnRl Z3JpdHkgYnV0IGRhdGEgb3JpZ2luIGF1dGhlbnRpY2F0aW9uCmFzIHdlbGwuCgooZGlzY3VzczEz KSAzLjQsICgzKTogV2l0aGluIHdoYXQgc2NvcGUgbXVzdCByZXBsYXkgYmUKZGV0ZWN0ZWQ/IFRo ZSB0ZXh0IGltcGxpZXMgZm9yIGV2ZXIsIHdoaWNoIGNhbiBiZSB2ZXJ5Cm9uZXJvdXMuIFNFQy1S RVEtMTQgZG9lc24ndCBxdWl0ZSBnbyBzbyBmYXIsIGJ1dCBpcwphbWJpZ3VvdXMgb24gdGhpcyBh c3BlY3QuIEknZCBzYXkgYmVzdCBpcyB0byBub3RlIHRoYXQKdGhlIHNjb3BlIHdpdGhpbiB3aGlj aCByZXBsYXkgbmVlZHMgdG8gYmUgZGV0ZWN0YWJsZSBpcwpmb3IgZnV0dXJlIHN0dWR5LiAKCihk aXNjdXNzMTQpIFNFQy1SRVEtMTU6IFNvcnJ5LCBJIGRvbid0IHVuZGVyc3RhbmQKd2hhdCdzIHJl cXVpcmVkIGhlcmUgKGhhdmluZyByZWFkIHRoaXMgPjEgdGltZSkuIENhbgp5b3UgZXhwbGFpbj/C oCBJJ20gbm90IHN1cmUgaWYgYW55IHN1YnN0YW50aXZlIGNoYW5nZSBpcwpuZWVkZWQsIGJ1dCB0 aGVyZSBhcmUgY2VydGFpbmx5IGVkaXRvcmlhbCBjaGFuZ2VzCm5lZWRlZCBmb3Igc3VyZSBhcyB0 aGVyZSBhcmUgbXVsdGlwbGUgd29yZGluZyBwcm9ibGVtcwp3aXRoIHRoZSB0ZXh0IGFzLWlzLgoK LSAzLjUsIDFzdCBwYXJhOiB0aGUgdGV4dCBoZXJlIGlzIG5vdCBhcyBnb29kIGFzIAp0aGUgYWN0 dWFsIGRlZmluaXRpb24gb2YgInJvbGUiIGluIFJGQzc5MjEsIGFuZCBpbgpmYWN0IEkgZm91bmQg dGhlIHRleHQgaGVyZSBjb25mdXNpbmcuIEJldHRlciB0bwpqdXN0IGRlbGV0ZSB0aGF0IGFuZCBz YXkgdGhhdCA3OTIxIGRlZmluZXMgcm9sZXMuIAoKKGRpc2N1c3MxNSkgU0VDLVJFUS0xNjogSSBk b24ndCBzZWUgYW55IGNvbnRlbnQgaW4gdGhpcwp0ZXh0IGFzIGl0IHNlZW1zIHRvIGp1c3Qgc2F5 ICJzb21lIHJvbGUgYmFzZWQgYWNjZXNzCmNvbnRyb2wgYW5kIHNvbWUgbGV2ZWwgb2YgdHJhbnNw b3J0IHByb3RlY3Rpb24gbmVlZCB0bwpiZSBwcm92aWRlZCIgd2hpY2ggaXMgYWx3YXlzIHRydWUs IGFzIHlvdSBhcmUgYWxsb3dpbmcKIm5vIHRyYW5zcG9ydCBzZWN1cml0eSIgYW5kIChJIGFzc3Vt ZSkgImZ1bGx5IHB1YmxpYwphY2Nlc3MiIHNvIGFueSBwcm90b2NvbC9zeXN0ZW0gd2lsbCBhbHdh eXMgbWVldCB0aGlzCnJlcXVpcmVtZW50LgoKLSBTRUMtUkVRLTE2OiAicHJpdmFjeSByZXF1aXJl bWVudHMiIGhlcmUgaXMgd3JvbmcsCnlvdSBtZWFuIGNvbmZpZGVudGlhbGl0eSBJIHRoaW5rLgoK KGRpc2N1c3MxNikgU0VDLVJFUS0xNzogIk1VU1Qgd29yayIgaXMgZmFyIHRvbyB2YWd1ZS4KVGhh dCBjb3VsZCBmb3IgZXhhbXBsZSBoaWRlIGEgbWFqb3IgZGViYXRlIGFib3V0IHB1c2gKdi4gcHVs bCBvZiByb2xlIGluZm9ybWF0aW9uLiBJZiB0aGUgV0cgaGF2ZW4ndApjb25zaWRlcmVkIHRoYXQs IEkgdGhpbmsgeW91IGNvdWxkIGFjayB0aGF0IGFnYWluIGJ5CnNheWluZyB0aGF0IG1vcmUgd29y ayBpcyBuZWVkZWQgdG8gZGVmaW5lIGhvdyBSQkFDIGlzCmNvbnNpc3RlbnQgYWNyb3NzIG11bHRp cGxlIHRyYW5zcG9ydCBsYXllciBjb25uZWN0aW9ucy4KCihkaXNjdXNzMTcpIFNFQy1SRVEtMTg6 IGFnYWluIHRoaXMgc2VlbXMgdG8gaGF2ZSBubwpjb250ZW50LCBvdGhlciB0aGFuIHBlcmhhcHMg aW1wb3NpbmcgYW4gb2RkIHJlcXVpcmVtZW50Cm9uIGltcGxlbWVudGF0aW9ucyAtIEkgZG9uJ3Qg c2VlIGEgcHJvdG9jb2wgcmVxdWlyZW1lbnQKaGVyZSBhdCBhbGwuIEl0IGlzIHJlYXNvbmFibGUg dG8gbm90ZSB0aGF0IGxpYnJhcmllcwpmb3IgY2xpZW50cyBvdWdodCBub3QgYXNzdW1lIGEgc2lu Z2xlIGNsaWVudCBpZGVudGl0eQpidXQgZXZlbiB0aGF0J3MgdmVyeSBzcGVjaWZpYyB0byBsaWJy YXJ5CmltcGxlbWVudGF0aW9ucyBhbmQgc2luY2UgaXQncyBqdXN0IGEgTUFZIHRoYXQncwplbnRp cmVseSBvYnZpb3VzLCBJJ2QgbGVhdmUgaXQgb3V0LgoKKGRpc2N1c3MxOCkgU0VDLVJFUS0xOTog SSBmdWxseSBhZ3JlZSB3aXRoIHRoZQptb3RpdmF0aW9uIGhlcmUgYnV0IEkgdGhpbmsgdGhlIHN0 YXRlZCByZXF1aXJlbWVudCBpcwpicm9rZW4uwqAgRm9yIGV4YW1wbGUsIEkgZG9uJ3Qga25vdyBo b3cgYSBwaWVjZSBvZiBzL3cKd2lsbCBkZXRlcm1pbmUgd2hldGhlciBvciBub3QgaXQgaXMgY29y cmVsYXRlZCB3aXRoIGEKcGVyc29uLiBJIGFsc28gZG9uJ3QgdGhpbmsgYSBTSE9VTEQgd29ya3Mg aGVyZSwgYXMKYWdhaW4gc29tZXRoaW5nIHdvdWxkIG5lZWQgdG8gYmUgc3RhdGVkIGFib3V0IHRo ZQpzaXR1YXRpb25zIHdoZW4gdGhlIGZlYXR1cmUgaXMgbm90IG5lZWRlZCwgYW5kIEkgY2FuJ3QK ZmlndXJlIG91dCBhIHNlbnNpYmxlIHN0YXRlbWVudCBmb3IgdGhhdC4gVGhlIGxhc3QKc2VudGVu Y2UgYWxzbyBzZWVtcyBsaWtlbHkgbm90IHVzZWZ1bC4gQWxsIGluIGFsbCwgSQp0aGluayB0aGlz IGlzIGxpa2VseSB0byBiZSBpZ25vcmVkIG9yIGV2ZW4gd29yc2UKdHJlYXRlZCBsaWtlIGEgcGll Y2Ugb2YgZmlnLWxlYWYgc3BlY2lmaWNhdGlvbiB0ZXh0IHRvCnByZXRlbmQgdGhhdCB3ZSdyZSBj YXJpbmcgYWJvdXQgcHJpdmFjeS4KCihkaXNjdXNzMTkpIC0gMy42OiBJIGhhdmUgbm8gaWRlYSB3 aGV0aGVyIHRoaXMgb3RoZXIKZHJhZnQgaXMgc3VwcG9zZWQgdG8gYmUgY29uc2lkZXJlZCBhcyBz ZXR0aW5nCnJlcXVpcmVtZW50cyBvciBub3QuIEkgYXNzdW1lIHRoYXQgdGhlIGFuc3dlciBpcyAi bm90IgphcyB5b3UndmUgbWFkZSBpdCBhbiBpbmZvcm1hdGl2ZSByZWZlcmVuY2UsIGJ1dCBpbiB0 aGF0CmNhc2UgeW91IHJlYWxseSBzaG91bGQgc2F5IHRoYXQuwqAgVGhlIGFsdGVybmF0aXZlIHdv dWxkCmJlIHRoYXQgMy42IGlzIGVzc2VudGlhbGx5IHNwZWNpZnlpbmcgYW4gYXBwbGljYWJpbGl0 eQpzdGF0ZW1lbnQgZm9yIHRoZSBlbnZpcm9ubWVudHMgaW4gd2hpY2ggaXQgaXMsIGFuZCBpcwpu b3QsIG9rIHRvIHJ1biBpMnJzLiBJZiB0aGUgbGF0dGVyIHdlcmUgaW50ZW5kZWQsIHRoZW4KeW91 J2QgbmVlZCB0byBzYXkgaXQgYW5kIG1ha2UgdGhlIGRyYWZ0IGEgbm9ybWF0aXZlCnJlZmVyZW5j ZS4KCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwppMnJz IG1haWxpbmcgbGlzdAppMnJzQGlldGYub3JnCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vaTJycwo= ----_com.samsung.android.email_176427079500470 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 PGh0bWw+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0 L2h0bWw7IGNoYXJzZXQ9VVRGLTgiPjwvaGVhZD48Ym9keT48ZGl2PlN0ZXBoZW46PC9kaXY+PGRp dj48YnI+PC9kaXY+PGRpdj5UaGlzIGVtYWlsIGJlZ2lucyB0aGUgZGlzY3Vzc2lvbiBvbiB0aGUg RElTQ1VTUyBjcml0ZXJpYS4gJm5ic3A7Rm9yIGVhc2Ugb2YgcHJvY2VzcyBpdCBnb2VzIHRocm91 Z2ggRElTQ1VTUyAxIHRvIDU8L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2PlN1ZTwvZGl2PjxkaXY+ PGJyPjwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXYgaWQ9ImNvbXBvc2Vy X3NpZ25hdHVyZSI+PGRpdiBzdHlsZT0iZm9udC1zaXplOjg1JTtjb2xvcjojNTc1NzU3IiBkaXI9 ImF1dG8iPlNlbnQgdmlhIHRoZSBTYW1zdW5nIEdhbGF4eSBOb3RlNSwgYW4gQVQmYW1wO1QgNEcg TFRFIHNtYXJ0cGhvbmU8L2Rpdj48L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2IHN0eWxlPSJmb250 LXNpemU6MTAwJTtjb2xvcjojMDAwMDAwIj48IS0tIG9yaWdpbmFsTWVzc2FnZSAtLT48ZGl2Pi0t LS0tLS0tIE9yaWdpbmFsIG1lc3NhZ2UgLS0tLS0tLS08L2Rpdj48ZGl2PkZyb206IFN0ZXBoZW4g RmFycmVsbCAmbHQ7c3RlcGhlbi5mYXJyZWxsQGNzLnRjZC5pZSZndDsgPC9kaXY+PGRpdj5EYXRl OiA4LzIxLzE2ICA4OjM3IEFNICAoR01ULTA1OjAwKSA8L2Rpdj48ZGl2PlRvOiBUaGUgSUVTRyAm bHQ7aWVzZ0BpZXRmLm9yZyZndDsgPC9kaXY+PGRpdj5DYzogamhhYXNAcGZyYy5vcmcsIGkycnNA aWV0Zi5vcmcsIGkycnMtY2hhaXJzQGlldGYub3JnLCBkcmFmdC1pZXRmLWkycnMtcHJvdG9jb2wt c2VjdXJpdHktcmVxdWlyZW1lbnRzQGlldGYub3JnIDwvZGl2PjxkaXY+U3ViamVjdDogW2kycnNd IFN0ZXBoZW4gRmFycmVsbCdzIEFic3RhaW4gb24KICBkcmFmdC1pZXRmLWkycnMtcHJvdG9jb2wt c2VjdXJpdHktcmVxdWlyZW1lbnRzLTA5OiAod2l0aCBDT01NRU5UKSA8L2Rpdj48ZGl2Pjxicj48 L2Rpdj48L2Rpdj5TdGVwaGVuIEZhcnJlbGwgaGFzIGVudGVyZWQgdGhlIGZvbGxvd2luZyBiYWxs b3QgcG9zaXRpb24gZm9yPGJyPmRyYWZ0LWlldGYtaTJycy1wcm90b2NvbC1zZWN1cml0eS1yZXF1 aXJlbWVudHMtMDk6IEFic3RhaW48YnI+PGJyPldoZW4gcmVzcG9uZGluZywgcGxlYXNlIGtlZXAg dGhlIHN1YmplY3QgbGluZSBpbnRhY3QgYW5kIHJlcGx5IHRvIGFsbDxicj5lbWFpbCBhZGRyZXNz ZXMgaW5jbHVkZWQgaW4gdGhlIFRvIGFuZCBDQyBsaW5lcy4gKEZlZWwgZnJlZSB0byBjdXQgdGhp czxicj5pbnRyb2R1Y3RvcnkgcGFyYWdyYXBoLCBob3dldmVyLik8YnI+PGJyPjxicj5QbGVhc2Ug cmVmZXIgdG8gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvaWVzZy9zdGF0ZW1lbnQvZGlzY3Vzcy1jcml0 ZXJpYS5odG1sPGJyPmZvciBtb3JlIGluZm9ybWF0aW9uIGFib3V0IElFU0cgRElTQ1VTUyBhbmQg Q09NTUVOVCBwb3NpdGlvbnMuPGJyPjxicj48YnI+VGhlIGRvY3VtZW50LCBhbG9uZyB3aXRoIG90 aGVyIGJhbGxvdCBwb3NpdGlvbnMsIGNhbiBiZSBmb3VuZCBoZXJlOjxicj5odHRwczovL2RhdGF0 cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLWkycnMtcHJvdG9jb2wtc2VjdXJpdHktcmVx dWlyZW1lbnRzLzxicj48YnI+PGJyPjxicj4tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPGJyPkNPTU1FTlQ6PGJyPi0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS08YnI+PGJyPjxicj5GaXJzdCwgYXBvbG9naWVzIGZvciBub3QgZ2V0dGluZyBt eSByZXZpZXcgZG9uZSBmb3I8YnI+dGhpcyB3aGVuIGl0IHdhcyBzY2hlZHVsZWQgZHVlIHRvIG15 IHZhY2F0aW9uIGFuZDxicj50aGFua3MgZm9yIGJlaW5nIHdpbGxpbmcgdG8gZGVmZXIgdGhlIGRv Y3VtZW50Ljxicj48YnI+U2Vjb25kLCBoYXZpbmcgbm93IHByb3Blcmx5IHJldmlld2VkIHRoaXMs IEkgYW08YnI+YmFsbG90aW5nIGFic3RhaW4gYXMgSSB0aGluayBpdCdzIHVubGlrZWx5IHRoYXQg dGhpczxicj5kb2N1bWVudCBjYW4gYmUgZml4ZWQgaW4gYSB3YXkgdGhhdCByZXN1bHRzIGluPGJy PnNvbWV0aGluZyB1c2VmdWwgaGFwcGVuaW5nLiBJIHRoaW5rIHRoYXQgdGhlIGxpa2VseTxicj5v dXRjb21lIGlzIHRoYXQgdGhpcyBkb2N1bWVudCB3aWxsIGJlIHVzZWQgbGF0ZXIgd2hlbjxicj5w ZW9wbGUgYXJlIGFyZ3VpbmcgYW5kIHdpbGwgbm90IG11Y2ggaGVscCBpbiByZXNvbHZpbmc8YnI+ dGhvc2UgYXJndW1lbnRzLCBvciBlbHNlIHRoaXMgd2lsbCBiZSBpZ25vcmVkIGFuZDxicj5hcmd1 bWVudHMgd2lsbCBiZSBoZWxkIGFmcmVzaCwgYXMgbmVlZGVkLiBUaGF0IGxhdHRlcjxicj5vdXRj b21lIGlzIHdoYXQgSSdkIGd1ZXNzIGlzIG1vc3QgbGlrZWx5IGFuZCB0aGVyZWZvcmU8YnI+aXQg c2VlbXMgdGhhdCBzcGVuZGluZyBhbGwgb2Ygb3VyIGN5Y2xlcyBvbiBESVNDVVNTPGJyPmJhbGxv dCBwcm9jZXNzaW5nIGZvciB0aGlzIHdvdWxkIG5vdCBiZSB3aXNlLiBUaGF0PGJyPnNhaWQsIEkg YW0gd2lsbGluZyB0byBjaGFuZ2UgdG8gYSBESVNDVVNTIGJhbGxvdCBpZiB0aGU8YnI+cmVzcG9u c2libGUgQUQgcHJlZmVycyB0aGF0LCBidXQgSSBzdXNwZWN0IEknbGwgZW5kIHVwPGJyPndpdGgg YW4gYWJzdGFpbiBpbiBhbnkgY2FzZSwgYWZ0ZXIgc29tZSBkaXNjdXNzaW9uLiBUaGU8YnI+b25s eSBwbGFuIEkgY2FuIHRoaW5rIG9mIHRoYXQnZCBsZWFkIHRvIG1lIGVuZGluZyB1cDxicj53aXRo IGEgeWVzIG9yIG5vLW9iamVjdGlvbiBiYWxsb3Qgd291bGQgYmUgaWYgdGhpcyB3YXM8YnI+cmV0 dXJuZWQgdG8gdGhlIFdHIGZvciBmaXhpbmcgYW5kIHBvc3NpYmx5IG1ham9yPGJyPnN1cmdlcnks IHdoaWNoIGlzIHdoYXQgSSBhY3R1YWxseSB0aGluayB3b3VsZCBiZSB0aGU8YnI+YmVzdCBwbGFu LiAoSSByZWFsaXNlIHRoaXMgaGFzIGhhZCBhIHNvbWV3aGF0IHRvcnR1cmVkPGJyPmhpc3Rvcnks IHNvIGZvbGtzIG1heSBub3QgYmUgd2lsbGluZyB0byB0YWtlIGl0IGJhY2sgdG88YnI+dGhlIFdH LCBidXQgaG9uZXN0bHksIEkgdGhpbmsgdGhlIGZhaWxpbmdzIHZpc2libGUgaW48YnI+dGhpcyBk b2N1bWVudCBkbyBpbmRpY2F0ZSB0aGF0IHRoaXMgaXMgbm90IHJlYWR5IGZvcjxicj5hcHByb3Zh bCBhbmQgb3VnaHQgYmUgcmV0dXJuZWQgdG8gdGhlIFdHLik8YnI+PGJyPlRoaXJkLCBJIHRoaW5r IHRoZSBvdmVyYWxsIHNldCBvZiByZXF1aXJlbWVudHMgcG9zZWQ8YnI+aGVyZSBtaWdodCAod2l0 aCBzb21lIHVua25vd24gcHJvYmFiaWxpdHkpIGxlYWQgdG88YnI+bGF0ZXIgc3BlY2lmaWNhdGlv bnMgdGhhdCBhcmUgY29uc2lkZXJlZCB0b28gaGFyZCB0bzxicj5kZXBsb3ksIHdpdGggdGhlIHJl c3VsdCB0aGF0IG5vbi1zZWN1cmUgdmFyaWFudHMgb2Y8YnI+STJSUyBiZWNvbWUgdGhlIG5vcm0u IFRoYXQgc2VlbXMgbGlrZSBpdCB3b3VsZCBiZSBhPGJyPnJlYWxseSBiYWQgb3V0Y29tZS4gSSB3 b3VsZCBzdWdnZXN0IHRoYXQgbWlnaHQgYmU8YnI+cGFydGx5IG1pdGlnYXRlZCBpZiBhIHJlcXVp cmVtZW50IHdlcmUgYWRkZWQgdG8gdGhlPGJyPmVmZmVjdCB0aGF0IGRlcGxveW1lbnQgaXNzdWVz IGFuZCBzcGVjaWZpY2FsbHkgZWFzZSBvZjxicj5kZXBsb3ltZW50IE1VU1QgYmUgY29uc2lkZXJl ZCBhcyBhIGZpcnN0IG9yZGVyPGJyPnJlcXVpcmVtZW50IHdoZW4gZGV2ZWxvcGluZyBJMlJTIHBy b3RvY29sIHNvbHV0aW9ucy4gPGJyPjxicj5Gb3VydGgsIHRoZSAoMTkhKSBjb21tZW50cyBiZWxv dyB0aGF0IGFyZSBwcmVjZWRlZCBieTxicj4iKGRpc2N1c3MiIHdvdWxkIGhhdmUgYmVlbiBESVND VVNTIGJhbGxvdCBwb2ludHMgaGFkIEk8YnI+bm90IGRlY2lkZWQgdG8gYWJzdGFpbi4gSSBhbSBo YXBweSB0byBjaGF0IGFib3V0IGFueSBvZjxicj5teSBjb21tZW50cyBiZWxvdywgYnV0IGlmIHRo ZSBhdXRob3JzL1dHIGRvIHdhbnQgdG88YnI+Y2hhdCwgaXQgbWlnaHQgYmUgbW9yZSBlZmZpY2ll bnQgdG8gY29uY2VudHJhdGUgb248YnI+dGhvc2UgdGhhdCB3b3VsZCBvdGhlcndpc2UgaGF2ZSBi ZWVuIERJU0NVU1MgcG9pbnRzLjxicj4oQnV0IHRoYXQncyB5b3VyIGNhbGwsIEkgZG9uJ3QgbWlu ZC4pIEkgdGhpbmsgdGhlIDE5PGJyPndvdWxkLWhhdmUtYmVlbi1kaXNjdXNzIHBvaW50cyBpcyBh bm90aGVyIGNsdWUgdGhhdDxicj50aGlzIG91Z2h0IHJlYWxseSBiZSBzZW50IGJhY2sgdG8gdGhl IFdHLjxicj48YnI+QW5kIHdpdGggdGhhdCwgYW5kIHdpdGggYXBvbG9naWVzIGZvciB0aGlzIGJl aW5nIHN1Y2g8YnI+YW4gb3ZlcmFsbCBuZWdhdGl2ZSByZXZpZXcsIGhlcmUncmUgbXkgZGV0YWls ZWQ8YnI+Y29tbWVudHM6PGJyPjxicj4tIGdlbmVyYWw6IFRoZSB3cml0aW5nIGhlcmUgaXMgZ2Vu ZXJhbGx5IHBvb3IsIGZvcjxicj5leGFtcGxlIHRoZSBvcGVuZXIgaXMgIlRoaXMgcHJlc2VudHMu Li4iIHdoZXJlYXMgaXQ8YnI+b3VnaHQgYmUgIlRoaXMgZG9jdW1lbnQgcHJlc2VudHMuLi4iIChv cjxicj5zL2RvY3VtZW50L3doYXRldmVyIHlvdSBwcmVmZXIvKS4gU3VjaCBpc3N1ZXMgYXJlPGJy PnJlcGVhdGVkbHkgc2VlbiBhbmQgYWxsIHRoYXQgbWFrZXMgdGhpcyBhIG11Y2ggaGFyZGVyPGJy PnJlYWQgdGhhbiBvdWdodCBiZSB0aGUgY2FzZS4gSSdkIHN0cm9uZ2x5IHJlY29tbWVuZCBhbjxi cj5lZGl0b3JpYWwgcGFzcyBmcm9tIHNvbWVvbmUgd2hvIGhhc24ndCBiZWVuIGRvd24gaW4gdGhl PGJyPndlZWRzIHdpdGggdGhpcyB0ZXh0IGZvciBhIHdoaWxlICh3aGljaCBjb3VsZCBiZSBvbmUg b2Y8YnI+dGhlIGF1dGhvcnMsIGlmIG9uZSBvZiB0aGVtIGhhcyBiZWVuIGxlc3MgYWN0aXZlPGJy PnJlY2VudGx5LikgTm90ZSB0aGF0IHRoaXMgaXMgbm90IG9ubHkgKGJ1dCBpczxicj5wcmltYXJp bHkpIGFuIGVkaXRvcmlhbCBpc3N1ZSAtIHRoZXJlIGFyZSBzb21lIGNhc2VzPGJyPihob3BlZnVs bHkgY2FsbGVkIG91dCBiZWxvdykgd2hlcmUgdGhlIHdyaXRpbmcgZG9lczxicj5jcmVhdGUgcmVh bCBhbWJpZ3VpdHkgdGhhdCBtaWdodCBsZWFkIHRvIHJlLW9wZW5pbmcgb2xkPGJyPmFyZ3VtZW50 cyBsYXRlci48YnI+PGJyPi0mZ3Q7IGFic3RyYWN0OiAibXV0dWFsIGF1dGhlbnRpY2F0aW9uLCB0 cmFuc3BvcnQ8YnI+Jmd0OyBwcm90b2NvbHMsIGRhdGEgdHJhbnNmZXIgYW5kIHRyYW5zYWN0aW9u cyIgZG9uJ3Qgc2VlbTxicj4mZ3Q7dG8gbWUgdG8gYmUgY29tbWVuc3VyYXRlIHRoaW5ncywgc28g dGhlIGFic3RyYWN0LCBhcyB3cml0dGVuIGlzIHZlcnkgdW5pbmZvcm1hdGl2ZSBmb3IgbWUuPGJy Pjxicj5DYW4geW91IHN1Z2dlc3Qgd2hhdCBrZXJuZWwgb2YgaW5mb3JtYXRpb24geW91IHdvdWxk IGRlZW0gdXNlZnVsIGluIHRoZSBhYnN0cmFjdD8mbmJzcDs8YnI+PGJyPjxicj4mZ3Q7IGludHJv IDNyZCBwYXJhOiBJJ20gcmVhbGx5IG5vdCBzdXJlIHdoYXQgeW91J3JlPGJyPiZndDt0ZWxsaW5n IG1lIGFib3V0IFtJLUQuaWV0Zi1pMnJzLWVwaGVtZXJhbC1zdGF0ZV0uICZuYnNwOzxkaXY+Jmd0 O1RoZSBkcmFmdCBbUkZDNzkyMl0iIGlzIG9kZCwgdGhhdCBiZWluZyBubyBsb25nZXIgYSBkcmFm dC4mbmJzcDs8YnIgZGlyPSJhdXRvIj4mZ3Q7IEknZCBoYXZlIGV4cGVjdGVkIHN1Y2ggbml0cyB3 b3VsZCBoYXZlIGJlZW4gZml4ZWQgYnkgJm5ic3A7cm93IFRCSC4gU2FtZSBmb3IgdGhlIGxhc3Qg c2VudGVuY2UuJm5ic3A7IFRoYXQgcGFyYSBtYWtlcyZuYnNwOzxiciBkaXI9ImF1dG8iPiZsdDt0 aGUgaW50cm8gcHJldHR5IHVuY2xlYXIgZm9yIG1lLjxkaXYgZGlyPSJhdXRvIj48YnI+PC9kaXY+ PGRpdiBkaXI9ImF1dG8iPlRoYW5rIHlvdSBmb3IgdGhhdCBpbnB1dC4gJm5ic3A7SSB3aWxsIGZp eCB0aGF0IGluIHZlcnNpb24gMTAuICZuYnNwOzxiciBkaXI9ImF1dG8iPjxiciBkaXI9ImF1dG8i PiZndDsgMi4yOiBUaGUgZGVmaW5pdGlvbiBvZiBoaWdoZXIgbGV2ZWwgcHJvdG9jb2wgc2VlbXM8 YnIgZGlyPSJhdXRvIj5saWtlIGFuIG9kZCBwbGFjZSB0byBpbnRyb2R1Y2UgdGhlIGZhY3QgdGhh dCBpMnJzID09PGJyIGRpcj0iYXV0byI+Jmd0O25ldGNvbmYgKyByZXN0Y29uZi4mbmJzcDsgVGhh dCdkIGJlIG1vcmUgdXNlZnVsbHkgc2FpZCBpbjxiciBkaXI9ImF1dG8iPnRoZSBhYnN0cmFjdC9p bnRybyBpZiB0aGF0J3Mgc29saWRseSBhZ3JlZWQgYnkgdGhlIFdHLjxiciBkaXI9ImF1dG8iPjxi cj5UaGUgcmVhc29uIHRoaXMgaXMgaW50cm9kdWNlZCBoZXJlIGlzIHRvIGxpbmsgdG8gc3RhdGVt ZW50cyBpbiB0aGUgYXJjaGl0ZWN0dXJlIGRvY3VtZW50LiBUaGUgaW5pdGlhbCBwcm90b2NvbHMg bWF5IGJlIG5ldGNvbmYgYW5kIHJlc3Rjb25mLCBidXQgb3RoZXIgcHJvdG9jb2xzIHdpbGwgZm9s bG93LiAmbmJzcDtJIHdpbGwgcHJvdmlkZSBhbiBpbXByb3ZlZCB0ZXh0IGluIHZlcnNpb24gMTAu PGJyPjxiciBkaXI9ImF1dG8iPiZndDsgMi4yOiBUaGlzIGlzIHdyb25nOiAiV2hpbGUgaXQgaXMg cG9zc2libGUgdG8gaGF2ZSBhbjxiciBkaXI9ImF1dG8iPkkyUlMgb3BlcmF0aW9uIHdoaWNoIGlz IGNvbnRhaW5lZCBpbiBtdWx0aXBsZSBJMlJTPGJyIGRpcj0iYXV0byI+KEUuZy4mbmJzcDsgd3Jp dGUgaW4gbXVsdGlwbGUgbWVzc2FnZXMpLCB0aGlzIGlzIG5vdDxiciBkaXI9ImF1dG8iPnN1cHBv cnRlZCBpbiBvcmRlciB0byBzaW1wbGlmeSB0aGUgZmlyc3QgdmVyc2lvbiBvZjxiciBkaXI9ImF1 dG8iPkkyUlMuIiBUaGUgcmVhc29uIHRoaXMgaXMgd3JvbmcsIGlzIHRoYXQgaXQgaXMgaGVyZTxi ciBkaXI9ImF1dG8iPnRoYXQgeW91IGFyZSBkZWZpbmluZyB0aGF0IGl0IGlzIG5vdCBwb3NzaWJs ZSB0byBoYXZlPGJyIGRpcj0iYXV0byI+YW4gb3BlcmF0aW9uIGluIG11bHRpcGxlIG1lc3NhZ2Vz LiBzL2l0IGlzL2l0IGNvdWxkPGJyIGRpcj0iYXV0byI+aGF2ZSBiZWVuLyB3b3VsZCB3b3JrIG1h eWJlLjxiciBkaXI9ImF1dG8iPjxicj5TdGVwaGVuOiBXZSBhcmUgd29ya2luZyBvbiBhIHJlLXVz ZSBwcm90b2NvbCBmb3IgTkVUQ09ORiwgUkVTVENPTkYsIElQRklYLCBGb3JjZXMgYW5kIG90aGVy IHByb3RvY29scy4gJm5ic3A7SXQgaXMgdGVjaG5pY2FsbHkgcG9zc2libGUgdG8gZGVmaW5lIGFu IG9wZXJhdGlvbiB3aGljaCBzcGFucyBtdWx0aXBsZSBtZXNzYWdlcy4gJm5ic3A7IEFuZCB3ZSBh cmUgbGltaXRpbmcgdGhlIGZpcnN0IHZlcnNpb24gb2YgdGhpcyBwcm90b2NvbCB0byBvbmUgbWVz c2FnZS4gJm5ic3A7UGxlYXNlIGNsYXJpZnkgd2hhdCB5b3Ugd2lzaCBhZGRlZC48YnI+PGJyIGRp cj0iYXV0byI+Jmd0Oy0gMi4yOiAiICombmJzcDsgVGhlIEkyUlMgY2xpZW50IGlzc3VlcyBhIHJl YWQgcmVxdWVzdCB0byBhPGJyIGRpcj0iYXV0byI+STJSUyBhZ2VudCwgYW5kIHRoZSBJMlJTIEFn ZW50IHJlc3BvbmRpbmcgdG8gdGhlIHJlYWQgcmVxdWVzdCIgU2hvdWxkbid0IHRoYXQgdXNlIHJl c3BvbmQgYW5kIG5vdCByZXNwb25kaW5nPyAmbmJzcDtHaXZlbiB0aGF0IHlvdSBzZWVtIHRvIGJl IHRyeWluZyB0byBkZWZpbmUgdGhlIHNjb3BlIG9mICZuYnNwO3doYXQgaXMgYW5kIGlzIG5vdCBh IHRyYW5zYWN0aW9uLCBJIHRoaW5rIGJlaW5nIHByZWNpc2UmbmJzcDt3aXRoIHRoZSBsYW5ndWFn ZSBpcyBzb21ldGhpbmcgd2VsbCB3b3J0aCBkb2luZy4mbmJzcDsgVGhlIDJuZCBidWxsZXQgY291 bGQgYWxzbyBkbyB3aXRoIGEgcmUtd3JpdGUuPC9kaXY+PGRpdiBkaXI9ImF1dG8iPjxicj48L2Rp dj48ZGl2IGRpcj0iYXV0byI+U3VlJ3MgcmVzcG9uZHM6IFRoZSBsYW5ndWFnZSB3YXMgY2hvc2Vu IGNhcmVmdWxseS4gJm5ic3A7QW4gb3ZlcmxvYWRlZCBJMlJTIGFnZW50IGhhcyB0aGUgb3B0aW9u IG5vdCB0byByZWFwb25kLiAmbmJzcDtUaGVyZm9yZSwgdGhlIHBocmFzZSAidGhlIEkyUlMgQWdl bnQgcmVzcG9uZGluZyB0byB0aGUgcmVhZCByZXF1ZXN0IiBpcyBhIG1vcmUgYXBwcm9wcmlhdGUg cGhyYXNlLjwvZGl2PjxkaXYgZGlyPSJhdXRvIj48YnIgZGlyPSJhdXRvIj4mZ3Q7KGRpc2N1c3Mx KSAyLjI6IHlvdSBzb3J0LW9mIGRlZmluZSBtZXNzYWdlcyw8YnIgZGlyPSJhdXRvIj5vcGVyYXRp b25zLCB0cmFuc2FjdGlvbnMgYW5kIGFjdGlvbnMuIE5vbmUgb2YgdGhlPGJyIGRpcj0iYXV0byI+ ZGVmaW5pdGlvbnMgYXJlIHRoYXQgcHJlY2lzZSwgZS5nLiBhcmUgdGhvc2UgdGhlIG9ubHk8YnIg ZGlyPSJhdXRvIj5vcGVyYXRpb25zIG9yIGV4YW1wbGVzPyBBbmQgdHJhbnNhY3Rpb24gYW5kIGFj dGlvbjxiciBkaXI9ImF1dG8iPmFyZW4ndCByZWFsbHkgZGVmaW5lZCBhdCBhbGwuIEknbSBub3Qg c3VyZSBpZiB0aGF0J3M8YnIgZGlyPSJhdXRvIj5saWtlbHkgdG8gYmUgYSBwcm9ibGVtIG9yIG5v dC4gSSBzdXNwZWN0IGl0IHdpbGwgbGF0ZXIsPGJyIGRpcj0iYXV0byI+ZS5nLiB3aGVuIHlvdSBn ZXQgdG8gZmlndXJpbmcgb3V0IHRoZSBzY29wZSB3aXRoaW48YnIgZGlyPSJhdXRvIj53aGljaCBy ZXBsYXkgbmVlZHMgdG8gYmUgZGV0ZWN0YWJsZS48L2Rpdj48ZGl2IGRpcj0iYXV0byI+PGJyPjwv ZGl2PjxkaXYgZGlyPSJhdXRvIj5TdWUncyByZWFwb25zZTo8L2Rpdj48ZGl2IGRpcj0iYXV0byI+ Jm5ic3A7IFdlIG5lZWQgdG8gZ28gdG8gYSBtZXRhIGxldmVsIGZpcnN0IHRvIGFuc3dlciB0aGlz IHF1ZXN0aW9uLiAmbmJzcDtJMlJTIGlzIGEgcmUtdXNlIHByb3RvY29sLiAmbmJzcDtGb3IgZWFj aCBwcm90b2NvbCB0aGVzZSBtZXNzYWdlcyB3aGljaCBlbmNvZGUgc3BlY2lmaWMgdHJhbnNhY3Rp b25zIHRoYXQgYXJlIGEgc2VxdWVuY2Ugb2YgcmVhZCwgd3JpdGUsIHJwYywgb3IgZXZlbnQgYWN0 aW9ucy4gJm5ic3A7V2UgYXJlIGRlZmluaW5nIHRoZSBoaWdoZXIgbGV2ZWwgcHJvdG9jb2wgdGhh dCB3aWxsIGJlIHRyYW5zbGF0ZWQgaW50byBlYWNoIGxhbmd1YWdlIHZpYSBleHRlbnNpb25zLiAm bmJzcDsgU28uLiB3aGF0IHByZWNpc2VseSBmaXRzIHRoZSBkaXNjdXNzIGNyaXRlcmlhIGhlcmU/ ICZuYnNwO0FyZSB5b3UgbG9va2luZyBmb3IgdHJhbnNhY3Rpb25zIGFuZCBhY3Rpb25zIHRvIGJl IGRlZmluZWQ/ICZuYnNwO0hvdyBkb2VzIHRoaXMgaW1wYWN0IHRoZSByZXZpZXcgb2YgPHU+dGhl IEkyUlMgcHJvdG9jb2wgc2VjdXJpdHk8L3U+PC9kaXY+PGRpdiBkaXI9ImF1dG8iPiZuYnNwOzwv ZGl2PjxkaXYgZGlyPSJhdXRvIj48YnI+PC9kaXY+PGRpdiBkaXI9ImF1dG8iPi0gMi4yOiBzL3Ry YW5zYXRpb24vdHJhbnNhY3Rpb24vPGJyIGRpcj0iYXV0byI+PGJyIGRpcj0iYXV0byI+Jmd0Oyhk aXNjdXNzMikgLSAyLjI6ICJkZWZpbmVzIGEgc2Vjb25kYXJ5IGlkZW50aXR5IGFzIHRoZTxiciBk aXI9ImF1dG8iPmVudGl0eSBvZiBzb21lIG5vbi1JMlJTIGVudGl0eSAiIFRoYXQgY291bGQgYmUg YWJ1c2VkPGJyIGRpcj0iYXV0byI+Zm9yIHRyYWNraW5nIG9mIHZhcmlvdXMga2luZHMgSSB3b3Vs ZCBndWVzcywgZS5nLiBpZiBhbjxiciBkaXI9ImF1dG8iPklNRUkgd2VyZSB1c2VkLiBJIHRoaW5r IHlvdSBuZWVkIHRvIG5vdGUgdGhhdCBhbmQ8YnIgZGlyPSJhdXRvIj5zaG91bGQgaW1wb3NlIHNv bWUgcmVxdWlyZW1lbnRzIHRoYXQgc3VjaCBzZWNvbmRhcnk8YnIgZGlyPSJhdXRvIj5pZGVudGlm aWVycyBhcmUgbm90IHVzZWQgdGh1c2x5IGZvciB0cmFja2luZy4mbmJzcDsgQWxzbyw8YnIgZGly PSJhdXRvIj5zaG91bGQgdGhlIGZpcnN0IG9jY3VycmVuY2Ugb2YgZW50aXR5IHRoZXJlIGJlPGJy IGRpcj0iYXV0byI+aWRlbnRpdHk/PC9kaXY+PGRpdiBkaXI9ImF1dG8iPjxicj48L2Rpdj48ZGl2 IGRpcj0iYXV0byI+U3VlIHJlc3BvbnNlOiAmbmJzcDs8L2Rpdj48ZGl2IGRpcj0iYXV0byI+SW4g b3JkZXIgdG8gYmUgcHJlY2lzZSBpbiBteSBhbnN3ZXIsIEkgd2lsbCBuZWVkIHlvdSB0byBkZWZp bmUgSU1FSS4gJm5ic3A7VGhlc2Ugbm9uLUkyUlMgZW50aXRpZXMgYXJlIGF0dGFjaGVkIHRvIGEg dmFsaWQgaTJycyBjbGllbnQgd2l0aCBhIG11dHVhbGx5IGF1dGhlbnRpY2F0ZWQgaWRlbnRpdHkg c2lnbmFsZXMgYnkgdGhlIGlkZW50aWZpZXIgKGNsaWVudCBvciBhZ2VudCkuICZuYnNwO1RoZSBj b25uZWN0aW9uIG9mIHRoZSBhcHBsaWNhdGlvbiB0byB0aGUgaTJycyBjbGllbnQgaXMgb3V0c2lk ZSB0aGUgc2NvcGUgb2YgdGhlIEkyUlMgcHJvdG9jb2wuICZuYnNwO1RoZSBzZWNvbmRhcnkgaWRl bnRpZmllcnMgYXJlIHVzZSBmb3IgdHJhY2tpbmcgb2YgdGhlIGFwcGxpY2F0aW9uIGluIHRoZSB0 cmFjZWFiaWxpdHkgbWVjaGFuaXNtLiAmbmJzcDsgU28uLiBhZ2FpbiBJIGFtIHVuY2xlYXIgcmVn YXJkaW5nIHdoYXQgeW91IGFyZSBjb25jZXJuZWQgYWJvdXQgYW5kIHdoYXQgbWFrZXMgdGhpcyBh IERJU0NVU1MgYmFzZWQgb24gdGhlIERJU0NVU1MgY3JpdGVyaWEuPC9kaXY+PGRpdiBkaXI9ImF1 dG8iPjxiciBkaXI9ImF1dG8iPi0mZ3Q7IDMsIDFzdCBwYXJhOiBzL1RoZSBzZWN1cml0eSBmb3Ig dGhlL1RoZS8gLSB0aGVyZTxiciBkaXI9ImF1dG8iPmlzbid0IGEgdGhpbmcgY2FsbGVkIHRoZSBz ZWN1cml0eSBmb3IgdGhlIGkycnM8YnIgZGlyPSJhdXRvIj5wcm90b2NvbC48L2Rpdj48ZGl2IGRp cj0iYXV0byI+PGJyPjwvZGl2PjxkaXYgZGlyPSJhdXRvIj5TdWU6ICZuYnNwO1doeSBub3Q/ICZu YnNwO1BsZWFzZSBleHBsYWluLiAmbmJzcDtXZSBhcmUgZGVmaW5pbmcgYSByZS11c2UgcHJvdG9j b2wgd2l0aCBleHRlbnNpb25zIHRvIG90aGVyIHByb3RvY29scy4gJm5ic3A7V2h5IGRvZXMgdGhl IGNvbXBvc2l0ZSBwcm90b2NvbCBub3QgaGF2ZSBhIGxldmVsIG9mIHNlY3VyaXR5IG9yIHNlY3Vy aXR5IGNvbnNpZGVyYXRpb25zPyAmbmJzcDtQbGVhc2UgZXhwbGFpbiB3aGF0IHlvdSBkZXNpcmUg aGVyZS48L2Rpdj48ZGl2IGRpcj0iYXV0byI+PGJyIGRpcj0iYXV0byI+Jmd0OyhkaXNjdXNzMykg LSBzZWN0aW9uIDMgc2F5cyAidGhlIEkyUlMgcHJvdG9jb2wgcmVxdWlyZXM8YnIgZGlyPSJhdXRv Ij5tdXR1YWxseSBhdXRoZW50aWNhdGVkIEkyUlMgY2xpZW50cyBhbmQgSTJSUyBhZ2VudHM8YnIg ZGlyPSJhdXRvIj5jb21tdW5pY2F0aW5nIG92ZXIgYSBzZWN1cmUgdHJhbnNwb3J0LiIgVG8gbWUg dGhhdDxiciBkaXI9ImF1dG8iPmltcGxpZXMgdGhhdCBzb21ldGhpbmcgbGlrZSBUTFMgb3IgU1NI IGlzIE1UVSB3aGljaDxiciBkaXI9ImF1dG8iPnNlZW1zIHRvIGNvbnRyYWRpY3QgcmVjZW50IGVt YWlscy48YnIgZGlyPSJhdXRvIj48YnI+U3VlOiBKdXN0IHRvIGJlIGNsZWFyLCB5b3UgYXJlIG5v dCBvYmplY3RpbmcgdG8gdGhlIHRleHQgeW91IGluZGljYXRlIC1idXQgeW91ciB1bmRlcnN0YW5k aW5nIGZyb20gdGhlIGVtYWlsLjxicj5BbiBJMlJTIGFnZW50IGhhcyBNVFUgc2VjdXJlIHRyYW5z cG9ydCBvZiBUTFMgb3IgU1NILiAmbmJzcDtBbnkgSTJSUyBjbGllbnQgYWNjZXNzaW5nIGFueSBk YXRhIG1vZGVsIHdoaWNoIGhhcyBtaXh0dXJlIG9mIHNlY3VyZSBhbmQgbm9uLXNlY3VyZSBkYXRh IGhhcyBhbiBNVFUgb2YgYSBzZWN1cmUgdHJhbnNwb3J0ICZuYnNwOyhUTFMgb3Igc3NoKS4gJm5i c3A7QW55IGkycnMgY2xpZW50IGFjY2Vzc2luZyBhbiBpMnJzIGFnZW50IGluIGFuIGVudmlyb25t ZW50IHRoYXQgd2hlcmUgdGhlIG5ldHdvcmsgaW5mbyBtaWdodCBiZSBsaW5rZWQgdG8gYSBwZXJz b24nIGlkZW50aXR5IGhhcyBhIE1UVSBvZiBzZWN1cmUgdHJhbnNwb3J0LiAmbmJzcDs8L2Rpdj48 ZGl2IGRpcj0iYXV0byI+PGJyPjwvZGl2PjxkaXYgZGlyPSJhdXRvIj5UaGUgb25seSB0aW1lIHRo ZSBJMlJTIGNsaWVudCBpcyBhbGxvd2VkIHRvIGhhdmUgYSBub24tc2VjdXJlIHRyYW5zcG9ydCBp cyBpZiB0aGUgb25seSB0aGluZyBpdCBpcyBhY2Nlc3NpbmcgaXMgbm9uLXNlY3VyZSBkYXRhLiAm bmJzcDtXZSBjdXJyZW50bHkgaGF2ZSBubyBpMnJzIGRhdGEgbW9kZWxzIHdoaWNoIGhhdmUgbm9u LXNlY3VyZSBkYXRhLjwvZGl2PjxkaXYgZGlyPSJhdXRvIj48YnIgZGlyPSJhdXRvIj4mZ3Q7IHNl Y3Rpb24gMyBzYXlzOiAiVGhlIEkyUlMgcHJvdG9jb2wgTVVTVCBiZSBhYmxlIHRvPGJyIGRpcj0i YXV0byI+cHJvdmlkZSBhdG9taWNpdHkgb2YgYW4gSTJSUyB0cmFuc2FjdGlvbiwgYnV0IGl0IGlz IG5vdDxiciBkaXI9ImF1dG8iPnJlcXVpcmVkIHRvIGhhdmUgbXVsdGktbWVzc2FnZSBhdG9taWNp dHkgYW5kIHJvbGwtYmFjayZuYnNwO21lY2hhbmlzbSB0cmFuc2FjdGlvbnMuJm5ic3A7IE11bHRp cGxlIG1lc3NhZ2VzIHRyYW5zYWN0aW9ucyBtYXkgYmUgaW1wYWN0ZWQgYnkgdGhlIGludGVyZGVw ZW5kZW5jeSBvZiBkYXRhLiIgJm5ic3A7PC9kaXY+PGRpdiBkaXI9ImF1dG8iPjxicj48L2Rpdj48 ZGl2IGRpcj0iYXV0byI+Jmd0OyBJIGRvbid0IGJlbGlldmUgdGhhdCB0aGF0J3MgZWFzaWx5IGVu b3VnaCB1bmRlcnN0b29kIHRvIGJlJm5ic3A7dXNlZnVsLiBBbHNvLCB3b3VsZG4ndCBzL011bHRp cGxlIG1lc3NhZ2VzPGJyIGRpcj0iYXV0byI+dHJhbnNhY3Rpb25zL011bHRpcGxlLW1lc3NhZ2Ug dHJhbnNhY3Rpb25zLyBiZSBtdWNoIGNsZWFyZXIgaWYgdGhhdCdzIHdoYXQncyBtZWFudD8gQW5k IGZpbmFsbHksIEkgdGhpbmsgdGhlIE1VU1QgZW1iZWRkZWQgaW4gdGhlIGFib3ZlIGlzIG5vdCB0 aGF0IGdyZWF0IGEgaWRlYSAtIGl0J3MgY2xlYXJlciBJTU8gdG8gc2VwYXJhdGUgdGhlIDIxMTkg bGFuZ3VhZ2UgZnJvbSBpbnRyb2R1Y3RvcnkgdGV4dCBpbiBkb2N1bWVudHMgbGlrZSB0aGlzLjwv ZGl2PjxkaXYgZGlyPSJhdXRvIj48YnI+PC9kaXY+PGRpdiBkaXI9ImF1dG8iPlN0ZXBoZW46ICZu YnNwO1RoZSBsYW5ndWFnZSB3YXMgc3BlY2lmaWVkIGJ5IGEgZmV3IGltcGxlbWVudGVycyBkb2lu ZyBJMlJTIHdvcmsuPC9kaXY+PGRpdiBkaXI9ImF1dG8iPjxicj48L2Rpdj48ZGl2IGRpcj0iYXV0 byI+SSBiZWxpZXZlIHlvdSBkbyBub3QgdW5kZXJzdGFuZCBJMlJTIHRyYW5zYWN0aW9ucyB2ZXJz dXMgbWVzc2FnZXMuICZuYnNwO1RyYW5zYWN0aW9ucyBjYW4gYmUgc2V0dGluZyBhIHZhbHVlLCBy cGMgdG8gYWRkIGEgc2V0IG9mIHZhbHVlcywgYW5kIHN0YXJ0aW5nIGFuIGV2ZW50IHN0cmVhbS4g Jm5ic3A7RWFjaCB0cmFuc2FjdGlvbiBtdXN0IGVpdGhlciB3b3JrIG9yIG5vdCB3b3JrIGFzIGFu IGluZGVwZW5kZW50IHVuaXQuICZuYnNwOyBUaGlzIGlzIG5vdCB0aGUgc2FtZSBhcyBzZW5kaW5n IHRoaXMgbWVzc2FnZXMgd2l0aCBhIHNldCBvZiBjb21tYW5kcyBhbmQgYmVpbmcgYWJsZSB0byBy b2xsYmFjayB0byB0aGUgYmVnaW5uaW5nIG9mIHRob3NlIDUgY29tbWFuZHMuICZuYnNwO1NvbWUg cHJvdG9jb2wgSTJSUyAmbmJzcDttYXkgc3VwcG9ydCB0aGlzIGxldmVsIG9mIGNoZWNrcG9pbnRz LSBidXQgaXQgaXMgbm90IGEgcmVxdWlyZW1lbnQuPC9kaXY+PGRpdiBkaXI9ImF1dG8iPjxiciBk aXI9ImF1dG8iPi0gMzogIlRoZXJlIGFyZSBkZXBlbmRlbmNpZXMgaW4gc29tZSBvZiB0aGU8YnIg ZGlyPSJhdXRvIj5yZXF1aXJlbWVudHMgYmVsb3ciIHdvdWxkIGJlIGJldHRlciBhcyAiVGhlcmUg YXJlPGJyIGRpcj0iYXV0byI+aW50ZXItZGVwZW5kZW5jaWVzIGJldHdlZW4gc29tZSBvZiB0aGUg cmVxdWlyZW1lbnRzPGJyIGRpcj0iYXV0byI+YmVsb3ciIHVubGVzcyB5b3UgbWVhbiBkZXBlbmRl bmNpZXMgb24gc29tZSBleHRlcm5hbDxiciBkaXI9ImF1dG8iPnRoaW5ncywgd2hpY2ggaXMgbm90 IGNsZWFyIGZyb20gdGhlIHRleHQgYXMtaXMuPC9kaXY+PGRpdiBkaXI9ImF1dG8iPjxicj48L2Rp dj48ZGl2IGRpcj0iYXV0byI+U3VlOiBUaGFuayB5b3UgZm9yIHRoZSBpbnB1dC48YnIgZGlyPSJh dXRvIj48YnIgZGlyPSJhdXRvIj4mZ3Q7ICZuYnNwOyhkaXNjdXNzNCkgIiBGb3IgY29uZmlkZW50 aWFsaXR5IChzZWN0aW9uIDMuMykgYW5kPGJyIGRpcj0iYXV0byI+aW50ZWdyaXR5IChzZWN0aW9u IDMuNCkgdG8gYmUgYWNoaWV2ZWQsIHRoZTxiciBkaXI9ImF1dG8iPmNsaWVudC1hZ2VudCBtdXN0 IGhhdmUgbXV0dWFsIGF1dGhlbnRpY2F0aW9uIChzZWN0aW9uPGJyIGRpcj0iYXV0byI+My4xKSBh bmQgc2VjdXJlIHRyYW5zcG9ydCAoc2VjdGlvbiAzLjIpLiZuYnNwOyAiIFRoaXMgaXM8YnIgZGly PSJhdXRvIj5pbmNvcnJlY3QuIE9uZSBjYW4gaGF2ZSBjb25maWRlbnRpYWxpdHkgd2l0aG91dDxi ciBkaXI9ImF1dG8iPmF1dGhlbnRpY2F0aW9uIChzZWUgUkZDNzQzNSkgc28gdGhlIHRleHQgaXMg bm90PGJyIGRpcj0iYXV0byI+YWNjdXJhdGUuPC9kaXY+PGRpdiBkaXI9ImF1dG8iPjxicj48L2Rp dj48ZGl2IGRpcj0iYXV0byI+U3VlOiAmbmJzcDtUaGUgY29uZGl0aW9uYWwgc2VudGVuY2UgYWJv dmUgaGFzIGEgY29tcG91bmQgbm91bi4tICJjb25maWRlbnRpYWxpdHkgYW5kIGludGVncml0eSIg LSBjYW4geW91IGhhdmUgYm90aCB3aXRob3V0IGF1dGhlbnRpY2F0aW9uPyAmbmJzcDtQbGVhc2Ug Y29uZmlybS48L2Rpdj48ZGl2IGRpcj0iYXV0byI+PGJyIGRpcj0iYXV0byI+LSZndDsgY2FwaXRh bGlzYXRpb24gbmVlZHMgZml4aW5nIGluIHZhcmlvdXMgcGxhY2VzLCBlLmcuPGJyIGRpcj0iYXV0 byI+YXJvdW5kIHRoZSBlbmQgb2YgcDUsIHdlIGdldCAic2VjdXJlIFRyYW5zcG9ydCIgYW5kPGJy IGRpcj0iYXV0byI+dGhlbiAiSTJSUyBjbGllbnQiIGFuZCAiSTJSUyBBZ2VudCIgaW4gdGhlIHRp dGxlIG9mIDMuMTxiciBkaXI9ImF1dG8iPklzIGFueSBvZiB0aGF0IGNhcGl0YWxpc2F0aW9uIHN1 cHBvc2VkIHRvIGJlPGJyIGRpcj0iYXV0byI+c2lnbmlmaWNhbnQ/IEVpdGhlciB3YXksIGZpeGlu ZyBpdCBub3cgd291bGQgYmUgZ29vZCBhcyZuYnNwOzxiciBkaXI9ImF1dG8iPnlvdSdsbCBuZWVk IHRvIGdldCB0aGUgUkZDIGVkaXRvciB0byBkbyBpdCBsYXRlciBpZiB5b3U8YnIgZGlyPSJhdXRv Ij5kb24ndCAod2hpY2ggdGFrZXMgbG9uZ2VyKS48L2Rpdj48ZGl2IGRpcj0iYXV0byI+PGJyPjwv ZGl2PjxkaXYgZGlyPSJhdXRvIj5TdWU6IFRoYW5rIHlvdSBmb3IgdGhpcyBlZGl0b3JpYWwgY29y cmVjdGlvbi4gJm5ic3A7VmVyc2lvbiAxMCB3aWxsIGFkZHJlc3MgdGhpczwvZGl2PjxkaXYgZGly PSJhdXRvIj48YnI+PC9kaXY+PGRpdiBkaXI9ImF1dG8iPjxiciBkaXI9ImF1dG8iPiZndDsoZGlz Y3VzczUpIFNFQy1SRVEtMDE6IHdoYXQgaXMgdGhlIHNjb3BlIG9mIHVuaXF1ZW5lc3M8YnIgZGly PSJhdXRvIj5yZXF1aXJlZCBoZXJlPyBJIHNlZSBubyByZWFzb24gd2h5IHR3byBkaWZmZXJlbnQg ZGF0YTxiciBkaXI9ImF1dG8iPmNlbnRyZXMgY2Fubm90IHJlLXVzZSBhIGNsaWVudCBvciBhZ2Vu dCBpZGVudGlmaWVyLCBpZjxiciBkaXI9ImF1dG8iPnRoZXkgc28gd2lzaC4gSSdkIGJlIGZpbmUg aWYgeW91IHNheSB0aGF0J3MgZm9yIGxhdGVyPGJyIGRpcj0iYXV0byI+ZGVjaXNpb24sIGJ1dCBi ZWluZyBzaWxlbnQgb24gdGhlIG1hdHRlciBjb3VsZCBsZWFkIHRvPGJyIGRpcj0iYXV0byI+dHJv dWJsZSBsYXRlciBpZiBkaWZmZXJlbnQgZm9sa3MgZGVjaWRlIGRpZmZlcmVudGx5LjwvZGl2Pjxk aXYgZGlyPSJhdXRvIj48YnI+PC9kaXY+PGRpdiBkaXI9ImF1dG8iPlN1ZTogJm5ic3A7VGhpbmdz IHdhbmRlciBvdXQgb2YgYSBkYXRhIGNlbnRlciBpbnRvIHRoZSBJbnRlcm5ldC4gJm5ic3A7TWFu YWdlbWVudCBwcm90b2NvbHMgaGF2ZSB3YW5kZXJlZCBvdXQgaW4gdGhlIHBhc3QuICZuYnNwO1Ro ZSBzYWZlc3QgbWVjaGFuaXNtIGlzIHRvIGJlIHV0dGVybHkgdW5pcXVlLiAmbmJzcDtpZiBkZXBs b3ltZW50cyBjaG9vc2UgbGVzcyB0aGF0IHRoYXQsIHRoZSBzZWN1cml0eSBuZXR3b3JrIGRlc2ln bmVyIG11c3QgZG8gcmlzay9yZXdhcmQgY2hvaWNlLiAmbmJzcDtPciBwZW9wbGUgbWF5IGRlY2lk ZSB0byBjb25uZWN0IDIgZGF0YSBjZW50ZXJzIGR1ZSB0byBhbiBlbWVyZ2VuY3kgYW5kIGZvcmdl dCB0aGUgTWFuYWdlbWVudCBzeXN0ZW0gaWRlbnRpZmllcnMgb3ZlcmxhcC4gJm5ic3A7QW5kIHRo ZW4gdGhlIG5ldHdvcmsgc3lzdGVtcyBzdGFydCBpbnRlcmFjdGluZy4gJm5ic3A7T29wczwvZGl2 PjxkaXYgZGlyPSJhdXRvIj5Bbnl0aGluZyBsZXNzIHRoYW4gY29tcGxldGUgdW5pcXVlbmVzcyBj YW4gZ28gYmFkLjwvZGl2PjxkaXYgZGlyPSJhdXRvIj48YnI+PC9kaXY+PGRpdiBkaXI9ImF1dG8i Pjxicj48L2Rpdj48ZGl2IGRpcj0iYXV0byI+PT09PT09PSByZXNwb25zZSBlbmRzIGhlcmU9PT09 PT09PTwvZGl2PjxkaXYgZGlyPSJhdXRvIj48YnI+PC9kaXY+PGRpdiBkaXI9ImF1dG8iPihkaXNj dXNzNikgU0VDLVJFUS0wMjogdGhlICJNVVNUIHV0aWxpemUiIHRoZXJlIG1lYW5zPGJyIGRpcj0i YXV0byI+TVRVLCB3aGljaCB3YXNuJ3Qgd2hhdCB5b3Ugd2FudGVkIEkgdGhpbms8YnIgZGlyPSJh dXRvIj48YnIgZGlyPSJhdXRvIj4oZGlzY3VzczcpIC0gU0VDLVJFUS0wMzogaG93IGlzICJ1cG9u IHJlY2VpdmluZy4uLiBNVVNUPGJyIGRpcj0iYXV0byI+Y29uZmlybSIgYSBnb29kIGNob2ljZT8g QXMgc3RhdGVkIHRoYXQnZCBiZSBodWdlbHk8YnIgZGlyPSJhdXRvIj5vbmVyb3VzLCBpbXBseWlu ZyBlLmcuJm5ic3A7IE9DU1AgY2hlY2tzIGZvciBlYWNoIHBhY2tldDxiciBkaXI9ImF1dG8iPnJl Y2VpdmVkLiBTYW1lIHBvaW50IGFwcGxpZXMgdG8gU0VDLVJFUS0wNC48YnIgZGlyPSJhdXRvIj48 YnIgZGlyPSJhdXRvIj4oZGlzY3VzczgpIC0gU0VDLVJFUS0wNTogdGhpcyBlaXRoZXIgbWVhbnMg bm90aGluZyBhdDxiciBkaXI9ImF1dG8iPmFsbCAoYmVpbmcgYSB0YXV0b2xvZ3kpIG9yIGVsc2Ug c29tZXRoaW5nIEkgZG9uJ3QgZ2V0LjxiciBkaXI9ImF1dG8iPkkgdGhpbmsgaXQncyB0aGUgZm9y bWVyLCBidXQgYW0gbm90IHN1cmUuPGJyIGRpcj0iYXV0byI+PGJyIGRpcj0iYXV0byI+LSAzLjE6 IHMvT25lIG1lY2hhbmlzbSBzdWNoIG1lY2hhbmlzbS9PbmUgc3VjaDxiciBkaXI9ImF1dG8iPm1l Y2hhbmlzbS8gSSBndWVzcy4gQW5kIGl0J3Mgbm90IGF0IGFsbCBjbGVhciB0byBtZTxiciBkaXI9 ImF1dG8iPiJBQUEgcHJvdG9jb2xzIiBpcyB0aGUgcmlnaHQgaWRlYSB0aGVyZSwgYW5kIG5vciBp cyBpdDxiciBkaXI9ImF1dG8iPmNsZWFyIHdoYXQncyBtZWFudCwgd2l0aCB0aGUgdGV4dCBhcy1p cy48YnIgZGlyPSJhdXRvIj48YnIgZGlyPSJhdXRvIj4tIFNFQy1SRVEtMDY6IHdoZXJlIGlzIGEg InByaW9yaXR5IiBkZWZpbmVkPzxiciBkaXI9ImF1dG8iPjxiciBkaXI9ImF1dG8iPi0gU0VDLVJF US0wNzogaGVyZSB5b3Ugc2F5IHJlYWQvd3JpdGUgaXMgYSB0cmFuc2FjdGlvbiw8YnIgZGlyPSJh dXRvIj5idXQgZWFybGllciB5b3Ugc2FpZCBpdCB3YXMgYW4gb3BlcmF0aW9uLCB3aGljaCBpcyBp dD88YnIgZGlyPSJhdXRvIj48YnIgZGlyPSJhdXRvIj4oZGlzY3VzczkpIDMuMjogQXMgd2l0aCBv dGhlcnMsIEkgZG9uJ3QgdGhpbmsgdGhlIGlkZWE8YnIgZGlyPSJhdXRvIj5vZiBhbm5vdGF0aW5n IHBhcnRzIG9mIHlhbmcgbW9kdWxlcyB3aXRoICJjYW4gYmU8YnIgZGlyPSJhdXRvIj5pbnNlY3Vy ZSIgaXMgYSBnb29kIG9uZS4gVGhlcmUncyBhIHNlcGFyYXRlIHRocmVhZDxiciBkaXI9ImF1dG8i PmRpc2N1c3NpbmcgdGhhdCB0aG91Z2gsIHNvIG1heWJlIGJldHRlciB0byBub3QgZm9yazxiciBk aXI9ImF1dG8iPnRoYXQuIDxiciBkaXI9ImF1dG8iPjxiciBkaXI9ImF1dG8iPihkaXNjdXNzMTAp IC0gU0VDLVJFUS1POTogSSBoYXRlIHRvIGRvIHRoaXMgdG8geWEsIGJ1dDxiciBkaXI9ImF1dG8i PkJDUDEwNyBpcyBJTU8gYSBmYWlybHkgY2xlYXIgZmFpbHVyZSB3aGVuIGl0IGNvbWVzIHRvPGJy IGRpcj0iYXV0byI+cm91dGluZy4gQW5kIHlldCBhZ2FpbiB0aGUgZXhjZXB0aW9ucyBjbGF1c2Vz IGhlcmUgYXJlPGJyIGRpcj0iYXV0byI+c28gYnJvYWQgYXMgdG8gYmUgbWVhbmluZ2xlc3MgKGUu Zy4gY29uc2lkZXJlZCBsb3c8YnIgZGlyPSJhdXRvIj52YWx1ZSBieSB3aG9tPykuIFdoYXQgaXMg dGhlIHJlYWwgZ29hbCBoZXJlPyAob3RoZXI8YnIgZGlyPSJhdXRvIj50aGFuIGFuIGF0dGVtcHQg dG8ga2VlcCB0aGUgc2VjIEFEcyBmcm9tIGJlaW5nIGFubm95aW5nPGJyIGRpcj0iYXV0byI+YW5k IHRyeWluZyB0byBpbnNpc3Qgb24gQkNQMTA3PyA7LSkgPGJyIGRpcj0iYXV0byI+PGJyIGRpcj0i YXV0byI+KGRpc2N1c3MxMSkgLSBTRUMtUkVRLTA5OiBTZXBhcmF0ZWx5LCB0byBteSBvdGhlcjxi ciBkaXI9ImF1dG8iPndvdWxkLWJlLWRpc2N1c3MgcG9pbnQgb24gdGhpcyByZXF1aXJlbWVudCwg ImNhbjxiciBkaXI9ImF1dG8iPmd1YXJhbnRlZSIgaXMgd2VsbCBiZXlvbmQgdGhlIHN0YXRlIG9m IHRoZSBhcnQgaW4ga2V5PGJyIGRpcj0iYXV0byI+bWFuYWdlbWVudC4gSSdkIGp1c3QgZHJvcCB0 aGF0IHNlbnRlbmNlIG1heWJlLCBidXQ8YnIgZGlyPSJhdXRvIj5jYW4ndCBtYWtlIGEgY29uY3Jl dGUgc3VnZ2VzdGlvbiB1bnRpbCBJIHVuZGVyc3RhbmQ8YnIgZGlyPSJhdXRvIj53aGVyZSB5b3Ug d2FudCB0byBiZSB3cnQgQkNQMTA3LjxiciBkaXI9ImF1dG8iPjxiciBkaXI9ImF1dG8iPi0gU0VD LVJFUS0xMDogdGhlIGxhc3Qgc2VudGVuY2UgaGVyZSBpcyBhbHNvIGludm9sdmVkPGJyIGRpcj0i YXV0byI+aW4gdGhlICJtYXkgZG8gc3R1ZmYgaW5zZWN1cmVseSIgdGhpbmcsIGFuZCBzbyB3aWxs PGJyIGRpcj0iYXV0byI+bGlrZWx5IG5lZWQgZml4aW5nIHdoZW4gdGhhdCBpcyBmdWxseSByZXNv bHZlZC48YnIgZGlyPSJhdXRvIj48YnIgZGlyPSJhdXRvIj4tIEhvdyBpcyBTRUMtUkVRLTExIHVz ZWZ1bD8gV2hhdCBwcm90b2NvbCBhcnRlZmFjdHMgZG88YnIgZGlyPSJhdXRvIj55b3UgaGF2ZSBp biBtaW5kIGhlcmU/IFBlcmhhcHMgYSByZXF1aXJlbWVudCB0aGF0IEREb1M8YnIgZGlyPSJhdXRv Ij5hdHRhY2tzIGJlIHNwZWNpZmljYWxseSBjb25zaWRlcmVkIGluIEkyUlMgd291bGQgYmU8YnIg ZGlyPSJhdXRvIj5tb3JlIHVzZWZ1bC48YnIgZGlyPSJhdXRvIj48YnIgZGlyPSJhdXRvIj4tIFNF Qy1SRVEtMTI6IFRoaXMgc2VlbXMgdG8gbWUgdG8gaGF2ZSB0b28gbWFueSB3b3Jkcyw8YnIgZGly PSJhdXRvIj5lLmcuIHRoZSBjdXJyZW50IHRleHQgY291bGQgYmUgcmVhZCB0byBpbXBseSB0aGF0 PGJyIGRpcj0iYXV0byI+b3V0c2lkZSBvZiBjcml0aWNhbCBpbmZyYXN0cnVjdHVyZSB0aGVyZSBp cyBsZXNzIG9yIG5vPGJyIGRpcj0iYXV0byI+bmVlZCBmb3IgY29uZmlkZW50aWFsaXR5LCBzbyB0 aG9zZSBhZGRlZCB3b3JkczxiciBkaXI9ImF1dG8iPihwcmVzdW1hYmx5IHRoZXJlIHRvIG1vdGl2 YXRlKSBtaWdodCBiZTxiciBkaXI9ImF1dG8iPmNvdW50ZXItcHJvZHVjdGl2ZS4gPGJyIGRpcj0i YXV0byI+PGJyIGRpcj0iYXV0byI+KGRpc2N1c3MxMikgU0VDLVJFUS0xMjogSSBkb24ndCBnZXQg dGhlIG1lYW5pbmcgb2YgdGhlPGJyIGRpcj0iYXV0byI+U0hPVUxEIGhlcmUgLSBjb21iaW5lZCB3 aXRoICJjZXJ0YWluIGRhdGEiIHRoYXQgU0hPVUxEPGJyIGRpcj0iYXV0byI+c2VlbXMgdG8gZW5k IHVwIG1lYW5pbmcgTUFZLCBhcyBpbiwgaXQgc2VlbXMgdG8gbWVhbjxiciBkaXI9ImF1dG8iPnRo ZSBzYW1lIGFzICJSZWFkL3dyaXRlIG9wZXJhdGlvbnMgTUFZIGhhdmUgdG8gYmU8YnIgZGlyPSJh dXRvIj5wcm90ZWN0ZWQgdXNpbmcgYSBjb25maWRlbnRpYWxpdHkgc2VydmljZS4iPGJyIGRpcj0i YXV0byI+PGJyIGRpcj0iYXV0byI+LSAzLjQsIGJ1bGxldCAoMikgaGVyZSBtZWFucyB0aGF0IHdl J3JlIG5vdCB0YWxraW5nPGJyIGRpcj0iYXV0byI+YWJvdXQgZGF0YSBpbnRlZ3JpdHkgYnV0IGRh dGEgb3JpZ2luIGF1dGhlbnRpY2F0aW9uPGJyIGRpcj0iYXV0byI+YXMgd2VsbC48YnIgZGlyPSJh dXRvIj48YnIgZGlyPSJhdXRvIj4oZGlzY3VzczEzKSAzLjQsICgzKTogV2l0aGluIHdoYXQgc2Nv cGUgbXVzdCByZXBsYXkgYmU8YnIgZGlyPSJhdXRvIj5kZXRlY3RlZD8gVGhlIHRleHQgaW1wbGll cyBmb3IgZXZlciwgd2hpY2ggY2FuIGJlIHZlcnk8YnIgZGlyPSJhdXRvIj5vbmVyb3VzLiBTRUMt UkVRLTE0IGRvZXNuJ3QgcXVpdGUgZ28gc28gZmFyLCBidXQgaXM8YnIgZGlyPSJhdXRvIj5hbWJp Z3VvdXMgb24gdGhpcyBhc3BlY3QuIEknZCBzYXkgYmVzdCBpcyB0byBub3RlIHRoYXQ8YnIgZGly PSJhdXRvIj50aGUgc2NvcGUgd2l0aGluIHdoaWNoIHJlcGxheSBuZWVkcyB0byBiZSBkZXRlY3Rh YmxlIGlzPGJyIGRpcj0iYXV0byI+Zm9yIGZ1dHVyZSBzdHVkeS4gPGJyIGRpcj0iYXV0byI+PGJy IGRpcj0iYXV0byI+KGRpc2N1c3MxNCkgU0VDLVJFUS0xNTogU29ycnksIEkgZG9uJ3QgdW5kZXJz dGFuZDxiciBkaXI9ImF1dG8iPndoYXQncyByZXF1aXJlZCBoZXJlIChoYXZpbmcgcmVhZCB0aGlz ICZndDsxIHRpbWUpLiBDYW48YnIgZGlyPSJhdXRvIj55b3UgZXhwbGFpbj8mbmJzcDsgSSdtIG5v dCBzdXJlIGlmIGFueSBzdWJzdGFudGl2ZSBjaGFuZ2UgaXM8YnIgZGlyPSJhdXRvIj5uZWVkZWQs IGJ1dCB0aGVyZSBhcmUgY2VydGFpbmx5IGVkaXRvcmlhbCBjaGFuZ2VzPGJyIGRpcj0iYXV0byI+ bmVlZGVkIGZvciBzdXJlIGFzIHRoZXJlIGFyZSBtdWx0aXBsZSB3b3JkaW5nIHByb2JsZW1zPGJy IGRpcj0iYXV0byI+d2l0aCB0aGUgdGV4dCBhcy1pcy48YnIgZGlyPSJhdXRvIj48YnIgZGlyPSJh dXRvIj4tIDMuNSwgMXN0IHBhcmE6IHRoZSB0ZXh0IGhlcmUgaXMgbm90IGFzIGdvb2QgYXMgPGJy IGRpcj0iYXV0byI+dGhlIGFjdHVhbCBkZWZpbml0aW9uIG9mICJyb2xlIiBpbiBSRkM3OTIxLCBh bmQgaW48YnIgZGlyPSJhdXRvIj5mYWN0IEkgZm91bmQgdGhlIHRleHQgaGVyZSBjb25mdXNpbmcu IEJldHRlciB0bzxiciBkaXI9ImF1dG8iPmp1c3QgZGVsZXRlIHRoYXQgYW5kIHNheSB0aGF0IDc5 MjEgZGVmaW5lcyByb2xlcy4gPGJyIGRpcj0iYXV0byI+PGJyIGRpcj0iYXV0byI+KGRpc2N1c3Mx NSkgU0VDLVJFUS0xNjogSSBkb24ndCBzZWUgYW55IGNvbnRlbnQgaW4gdGhpczxiciBkaXI9ImF1 dG8iPnRleHQgYXMgaXQgc2VlbXMgdG8ganVzdCBzYXkgInNvbWUgcm9sZSBiYXNlZCBhY2Nlc3M8 YnIgZGlyPSJhdXRvIj5jb250cm9sIGFuZCBzb21lIGxldmVsIG9mIHRyYW5zcG9ydCBwcm90ZWN0 aW9uIG5lZWQgdG88YnIgZGlyPSJhdXRvIj5iZSBwcm92aWRlZCIgd2hpY2ggaXMgYWx3YXlzIHRy dWUsIGFzIHlvdSBhcmUgYWxsb3dpbmc8YnIgZGlyPSJhdXRvIj4ibm8gdHJhbnNwb3J0IHNlY3Vy aXR5IiBhbmQgKEkgYXNzdW1lKSAiZnVsbHkgcHVibGljPGJyIGRpcj0iYXV0byI+YWNjZXNzIiBz byBhbnkgcHJvdG9jb2wvc3lzdGVtIHdpbGwgYWx3YXlzIG1lZXQgdGhpczxiciBkaXI9ImF1dG8i PnJlcXVpcmVtZW50LjxiciBkaXI9ImF1dG8iPjxiciBkaXI9ImF1dG8iPi0gU0VDLVJFUS0xNjog InByaXZhY3kgcmVxdWlyZW1lbnRzIiBoZXJlIGlzIHdyb25nLDxiciBkaXI9ImF1dG8iPnlvdSBt ZWFuIGNvbmZpZGVudGlhbGl0eSBJIHRoaW5rLjxiciBkaXI9ImF1dG8iPjxiciBkaXI9ImF1dG8i PihkaXNjdXNzMTYpIFNFQy1SRVEtMTc6ICJNVVNUIHdvcmsiIGlzIGZhciB0b28gdmFndWUuPGJy IGRpcj0iYXV0byI+VGhhdCBjb3VsZCBmb3IgZXhhbXBsZSBoaWRlIGEgbWFqb3IgZGViYXRlIGFi b3V0IHB1c2g8YnIgZGlyPSJhdXRvIj52LiBwdWxsIG9mIHJvbGUgaW5mb3JtYXRpb24uIElmIHRo ZSBXRyBoYXZlbid0PGJyIGRpcj0iYXV0byI+Y29uc2lkZXJlZCB0aGF0LCBJIHRoaW5rIHlvdSBj b3VsZCBhY2sgdGhhdCBhZ2FpbiBieTxiciBkaXI9ImF1dG8iPnNheWluZyB0aGF0IG1vcmUgd29y ayBpcyBuZWVkZWQgdG8gZGVmaW5lIGhvdyBSQkFDIGlzPGJyIGRpcj0iYXV0byI+Y29uc2lzdGVu dCBhY3Jvc3MgbXVsdGlwbGUgdHJhbnNwb3J0IGxheWVyIGNvbm5lY3Rpb25zLjxiciBkaXI9ImF1 dG8iPjxiciBkaXI9ImF1dG8iPihkaXNjdXNzMTcpIFNFQy1SRVEtMTg6IGFnYWluIHRoaXMgc2Vl bXMgdG8gaGF2ZSBubzxiciBkaXI9ImF1dG8iPmNvbnRlbnQsIG90aGVyIHRoYW4gcGVyaGFwcyBp bXBvc2luZyBhbiBvZGQgcmVxdWlyZW1lbnQ8YnIgZGlyPSJhdXRvIj5vbiBpbXBsZW1lbnRhdGlv bnMgLSBJIGRvbid0IHNlZSBhIHByb3RvY29sIHJlcXVpcmVtZW50PGJyIGRpcj0iYXV0byI+aGVy ZSBhdCBhbGwuIEl0IGlzIHJlYXNvbmFibGUgdG8gbm90ZSB0aGF0IGxpYnJhcmllczxiciBkaXI9 ImF1dG8iPmZvciBjbGllbnRzIG91Z2h0IG5vdCBhc3N1bWUgYSBzaW5nbGUgY2xpZW50IGlkZW50 aXR5PGJyIGRpcj0iYXV0byI+YnV0IGV2ZW4gdGhhdCdzIHZlcnkgc3BlY2lmaWMgdG8gbGlicmFy eTxiciBkaXI9ImF1dG8iPmltcGxlbWVudGF0aW9ucyBhbmQgc2luY2UgaXQncyBqdXN0IGEgTUFZ IHRoYXQnczxiciBkaXI9ImF1dG8iPmVudGlyZWx5IG9idmlvdXMsIEknZCBsZWF2ZSBpdCBvdXQu PGJyIGRpcj0iYXV0byI+PGJyIGRpcj0iYXV0byI+KGRpc2N1c3MxOCkgU0VDLVJFUS0xOTogSSBm dWxseSBhZ3JlZSB3aXRoIHRoZTxiciBkaXI9ImF1dG8iPm1vdGl2YXRpb24gaGVyZSBidXQgSSB0 aGluayB0aGUgc3RhdGVkIHJlcXVpcmVtZW50IGlzPGJyIGRpcj0iYXV0byI+YnJva2VuLiZuYnNw OyBGb3IgZXhhbXBsZSwgSSBkb24ndCBrbm93IGhvdyBhIHBpZWNlIG9mIHMvdzxiciBkaXI9ImF1 dG8iPndpbGwgZGV0ZXJtaW5lIHdoZXRoZXIgb3Igbm90IGl0IGlzIGNvcnJlbGF0ZWQgd2l0aCBh PGJyIGRpcj0iYXV0byI+cGVyc29uLiBJIGFsc28gZG9uJ3QgdGhpbmsgYSBTSE9VTEQgd29ya3Mg aGVyZSwgYXM8YnIgZGlyPSJhdXRvIj5hZ2FpbiBzb21ldGhpbmcgd291bGQgbmVlZCB0byBiZSBz dGF0ZWQgYWJvdXQgdGhlPGJyIGRpcj0iYXV0byI+c2l0dWF0aW9ucyB3aGVuIHRoZSBmZWF0dXJl IGlzIG5vdCBuZWVkZWQsIGFuZCBJIGNhbid0PGJyIGRpcj0iYXV0byI+ZmlndXJlIG91dCBhIHNl bnNpYmxlIHN0YXRlbWVudCBmb3IgdGhhdC4gVGhlIGxhc3Q8YnIgZGlyPSJhdXRvIj5zZW50ZW5j ZSBhbHNvIHNlZW1zIGxpa2VseSBub3QgdXNlZnVsLiBBbGwgaW4gYWxsLCBJPGJyIGRpcj0iYXV0 byI+dGhpbmsgdGhpcyBpcyBsaWtlbHkgdG8gYmUgaWdub3JlZCBvciBldmVuIHdvcnNlPGJyIGRp cj0iYXV0byI+dHJlYXRlZCBsaWtlIGEgcGllY2Ugb2YgZmlnLWxlYWYgc3BlY2lmaWNhdGlvbiB0 ZXh0IHRvPGJyIGRpcj0iYXV0byI+cHJldGVuZCB0aGF0IHdlJ3JlIGNhcmluZyBhYm91dCBwcml2 YWN5LjxiciBkaXI9ImF1dG8iPjxiciBkaXI9ImF1dG8iPihkaXNjdXNzMTkpIC0gMy42OiBJIGhh dmUgbm8gaWRlYSB3aGV0aGVyIHRoaXMgb3RoZXI8YnIgZGlyPSJhdXRvIj5kcmFmdCBpcyBzdXBw b3NlZCB0byBiZSBjb25zaWRlcmVkIGFzIHNldHRpbmc8YnIgZGlyPSJhdXRvIj5yZXF1aXJlbWVu dHMgb3Igbm90LiBJIGFzc3VtZSB0aGF0IHRoZSBhbnN3ZXIgaXMgIm5vdCI8YnIgZGlyPSJhdXRv Ij5hcyB5b3UndmUgbWFkZSBpdCBhbiBpbmZvcm1hdGl2ZSByZWZlcmVuY2UsIGJ1dCBpbiB0aGF0 PGJyIGRpcj0iYXV0byI+Y2FzZSB5b3UgcmVhbGx5IHNob3VsZCBzYXkgdGhhdC4mbmJzcDsgVGhl IGFsdGVybmF0aXZlIHdvdWxkPGJyIGRpcj0iYXV0byI+YmUgdGhhdCAzLjYgaXMgZXNzZW50aWFs bHkgc3BlY2lmeWluZyBhbiBhcHBsaWNhYmlsaXR5PGJyIGRpcj0iYXV0byI+c3RhdGVtZW50IGZv ciB0aGUgZW52aXJvbm1lbnRzIGluIHdoaWNoIGl0IGlzLCBhbmQgaXM8YnIgZGlyPSJhdXRvIj5u b3QsIG9rIHRvIHJ1biBpMnJzLiBJZiB0aGUgbGF0dGVyIHdlcmUgaW50ZW5kZWQsIHRoZW48YnIg ZGlyPSJhdXRvIj55b3UnZCBuZWVkIHRvIHNheSBpdCBhbmQgbWFrZSB0aGUgZHJhZnQgYSBub3Jt YXRpdmU8YnIgZGlyPSJhdXRvIj5yZWZlcmVuY2UuPGJyIGRpcj0iYXV0byI+PGJyIGRpcj0iYXV0 byI+PGJyIGRpcj0iYXV0byI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX188YnIgZGlyPSJhdXRvIj5pMnJzIG1haWxpbmcgbGlzdDxiciBkaXI9ImF1dG8iPmky cnNAaWV0Zi5vcmc8YnIgZGlyPSJhdXRvIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL2kycnM8YnIgZGlyPSJhdXRvIj48L2Rpdj48L2Rpdj48L2JvZHk+PC9odG1sPg== ----_com.samsung.android.email_176427079500470-- From nobody Sun Aug 21 14:57:28 2016 Return-Path: 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 7225012B025; Sun, 21 Aug 2016 14:57:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.095 X-Spam-Level: X-Spam-Status: No, score=-1.095 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_BL=0.01, RCVD_IN_MSPIKE_L5=0.001, RDNS_NONE=0.793] autolearn=no 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 xGaKsxm0cSQP; Sun, 21 Aug 2016 14:57:19 -0700 (PDT) Received: from hickoryhill-consulting.com (unknown [50.245.122.97]) (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 CB13D12B012; Sun, 21 Aug 2016 14:57:18 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=166.177.56.220; Date: Sun, 21 Aug 2016 17:57:12 -0400 Message-ID: Importance: normal From: Susan Hares To: Stephen Farrell , The IESG MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--_com.samsung.android.email_200817715012930" X-Authenticated-User: skh@ndzh.com Archived-At: Cc: jhaas@pfrc.org, i2rs@ietf.org, i2rs-chairs@ietf.org, draft-ietf-i2rs-protocol-security-requirements@ietf.org Subject: Re: [i2rs] Stephen Farrell's Abstain on draft-ietf-i2rs-protocol-security-requirements-09: (with COMMENT) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Aug 2016 21:57:22 -0000 ----_com.samsung.android.email_200817715012930 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 U3RlcGhlbjrCoApUaGFuayB5b3UgZm9yIHRoZSBleHBsYW5hdGlvbnMuIMKgSXRlcmF0aXZlIGVk aXRzIGRvIGltcGFjdCBvbiB0aGUgc3R5bGUuIMKgCsKgV2hpbGUgeW91IGRlbm90ZSB0aGUgY29u Y2VybiBhcyBwZXJ2YXNpdmUgbW9uaXRvcmluZywgwqBpbiBteSBtaW5kIGl0IGlzIGJldHRlciB0 byBjb25zaWRlciB0aGUgZWZmb3J0IGFzIGVuc3VyaW5nIHBlcnZhc2l2ZSBwcml2YWN5IGZvciBp bmRpdmlkdWFscyBhbmQgZ3JvdXBzIHV0aWxpemluZyB0aGUgSW50ZXJuZXQuIMKgKEhhdmluZyB3 b3JrZWQgd2l0aCBzdXJ2aXZvcnMgb2YgZG9tZXN0aWMgYWJ1c2UgYW5kIHNleHVhbCBhYnVzZSwg SSBjaGVlciBJRVRGIGVmZm9ydCBvbiBwZXJ2YXNpdmUgbW9uaXRvcmluZy4pCk15IGZvY3VzIGFu ZCB0aGUgcmVhc29uIEkgYXNrZWQgYWJvdXQgdGhlIHNlY3VyaXR5IGRpcmVjdG9yYXRlIHJldmll d3MgLSBpcyB0aGF0IGl0IGlzIGltcG9ydGFudCB0byBmaXggcHJvYmxlbXMgZWFybHkgaW4gdGhl IHByb2Nlc3MuIMKgV2hlbiBJIGNvbWUgdG8gYW4gdW5leHBlY3RlZCBmYWlsaW5nIGdyYWRlIGZv ciBhIGRvY3VtZW50LCDCoEkgdHJ5IHRvIGFkZHJlc3MgYm90aCB0aGUgZG9jdW1lbnQgYW5kIHRo ZSBwcm9jZXNzIGluIG9yZGVyIHRvIGltcHJvdmUuIMKgSSBleHBlY3RlZCB0aGUgcHJvY2VzcyBv ZiBnZXR0aW5nIGEgc2VjdXJpdHkgZGlyZWN0b3JhdGUgcmV2aWV3cyB3b3VsZCBkZXRlY3QgcHJv YmxlbXMgc29vbmVyLiDCoCBTbyBJIGFtIGFza2luZyB3aGF0IGhhcHBlbmVkIGluIHRoZSBzZWN1 cml0eSBkaXJlY3RvcmF0ZSByZXZpZXdzIHRoYXQgY2F1c2VkIHRoZW0gdG8gbWlzcyB5b3VyIGNv bmNlcm5zPyDCoCBEaWQgbWlzcyBzb21ldGhpbmcgaW4gdGhlaXIgY29tbWVudHM/Ck15IG5leHQg cXVlc3Rpb24gaXMgd2hhdCBkbyB5b3UgZXhwZWN0IGZyb20gYSBwcm90b2NvbCBzZWN1cml0eSBk b2N1bWVudD8gwqBEbyB5b3UgaGF2ZSBhIGNoZWNrbGlzdD8gwqAKT24gdGhlIG5leHQgc3RlcHMs IEkgcmVzcG9uZGVkIHVwIHRocm91Z2ggeW91ciB+ZGlzY3Vzcy1jcml0ZXJpYS5odG1sIGNvbW1l bnQgNS4gwqBJZiB5b3UgaGF2ZSB0aW1lIHRvIGFuc3dlciDCoGp1c3QgbXkgcXVzdGlvbnMgb24g dGhlIDUgZGlzY3VzcyBRcyAtIGl0IHdpbGwgaGVscCBteSBkaXNjdXNzaW9uIHdpdGggQWxpYS4g wqAKU3VlU3VlCgpTZW50IHZpYSB0aGUgU2Ftc3VuZyBHYWxheHkgTm90ZTUsIGFuIEFUJlQgNEcg TFRFIHNtYXJ0cGhvbmUKLS0tLS0tLS0gT3JpZ2luYWwgbWVzc2FnZSAtLS0tLS0tLUZyb206IFN0 ZXBoZW4gRmFycmVsbCA8c3RlcGhlbi5mYXJyZWxsQGNzLnRjZC5pZT4gRGF0ZTogOC8yMS8xNiAg Mzo0MSBQTSAgKEdNVC0wNTowMCkgVG86IFN1c2FuIEhhcmVzIDxzaGFyZXNAbmR6aC5jb20+LCBU aGUgSUVTRyA8aWVzZ0BpZXRmLm9yZz4gQ2M6IGpoYWFzQHBmcmMub3JnLCBpMnJzQGlldGYub3Jn LCBpMnJzLWNoYWlyc0BpZXRmLm9yZywgZHJhZnQtaWV0Zi1pMnJzLXByb3RvY29sLXNlY3VyaXR5 LXJlcXVpcmVtZW50c0BpZXRmLm9yZyBTdWJqZWN0OiBSZTogW2kycnNdIFN0ZXBoZW4gRmFycmVs bCdzIEFic3RhaW4gb24gZHJhZnQtaWV0Zi1pMnJzLXByb3RvY29sLXNlY3VyaXR5LXJlcXVpcmVt ZW50cy0wOTogKHdpdGggQ09NTUVOVCkgCgpIaXlhLAoKT24gMjEvMDgvMTYgMjA6MTAsIFN1c2Fu IEhhcmVzIHdyb3RlOgo+IFN0ZXBoZW46IFRoYW5rIHlvdSBmb3IgbGVhdmluZyB5b3VyIHZhY2F0 aW9uIGVhcmx5IHRvIGRvIHRoaXMgcmV2aWV3Lgo+IEl0IGlzIG9uZSBvZiB0aGUgbW9zdCBuZWdh dGl2ZSB2aWV3cG9pbnQgSSBoYXZlIHJlYWQgZnJvbSB5b3UsIGFuZAo+IHNpbmNlwqAgaGF2ZSBy ZWFkIG1hbnkgb2YgeW91ciBESVNDVVNTIGNvbW1lbnRzIHNpbmNlIHlvdSBiZWNhbWUgYW4gQUQK CldlbGwsIEkndmUgZG9uZSBmYXIgbW9yZSBuZWdhdGl2ZSByZXZpZXdzLCBidXQgdGhpcyBvbmUg aGFzIGEgbG90Cm9mIHNtYWxsZXIgbmVnYXRpdmUgY29tbWVudHMuIE15IGd1ZXNzIGlzIHF1aXRl IGEgbG90IG9mIHRoYXQgaXMgZG93bgp0byBhKSBpdCdzIHZlcnkgdmVyeSBoYXJkIHRvIHdyaXRl IHByb3RvY29sIHJlcXVpcmVtZW50cyB0ZXh0IGNyaXNwbHkKYW5kIGFjY3VyYXRlbHksIGFuZCBi KSB0aGF0IGtpbmQgb2YgdGV4dCBpcyB2ZXJ5IHZlcnkgZWFzaWx5IG1lc3NlZCB1cAp3aGVuIGRv aW5nIGl0ZXJhdGl2ZSBlZGl0cyBpbiByZXNwb25zZSB0byByZXZpZXdzLCBhbmQgYykgdGhlIHdy aXRpbmcKaXMgcmVhbGx5IG5vdCB0aGF0IGdvb2QgaW4gdGhpcyB2ZXJzaW9uIC0gdG8gdGhlIHBv aW50IHdoZXJlIHRoZQphY2N1bXVsYXRpb24gb2Ygbml0cyBpdHNlbGYgYmVjb21lcyBhIG5vdGFi bGUgaXNzdWUsIGFuZCB3aGVyZSBpdCdzCmxpa2VseSBwYXN0IHRpbWUgdGhhdCBhbiBlZGl0b3Jp YWwgcGFzcyB3YXMgZG9uZSB0byBnZXQgdGhhdCBvdXQgb2YgdGhlCndheS4KCj4gLSBJIHRoaW5r IHRoaXMgZ2l2ZXMgbWUgdW5pcXVlIHBlcnNwZWN0aXZlLsKgIFRoaXMgaXMgZmFyIGZyb20gdGhl Cj4gZWFybHkgY29tbWVudHMgeW91IHNlbnQgMiB3ZWVrcyBhZ28uCgpOby4gSSB3b3VsZCBub3Qg aGF2ZSBhc2tlZCBmb3IgYSBkZWZlciBpZiBJIHRob3VnaHQgdGhlIG9ubHkgY29uY2Vybgp3YXMg dGhlIHBvc3NpYmlsaXR5IG9mIHRoaXMgcmVzdWx0aW5nIGluIGEgaGFyZC10by1kZXBsb3kgc2V0 IG9mCnNlY3VyaXR5IG1lY2hhbmlzbXMgLSBJIHdvdWxkIGhhdmUganVzdCBiYWxsb3RlZCB0aGF0 LiBJdCBpcyB0aGUgY2FzZQp0aGF0IHRoYXQncyBhbGwgSSBzYWlkIGJlZm9yZSBJIGhhZCBwcm9w ZXJseSByZWFkIHRoZSBkb2N1bWVudCB0aG91Z2gsCnllcy4gQW5kIGl0IHdhc24ndCAyIHdlZWtz IGFnbzotKQoKPiBJbiBkZXZlbG9waW5nIHRoaXMgZG9jdW1lbnQgYW5kCj4gSTJSUyB0ZWNobm9s b2d5IHRoZSBJMlJTIFdHIGFuZCBJIGFzIHRoZSBJMlJTIGNoYWlyIGhhdmUgcmVxdWVzdAo+IHJl dmlld3MgZnJvbSB0aGUgU2VjdXJpdHkgZGlyZWN0b3JhdGUuwqAgV2UgZGVsYXllZCBvdXQgZmly c3QKPiByZXZpc2lvbnMgdG8gdHJ5IHRvIGFkZHJlc3Mgc2VjdXJpdHkgaXNzdWUgYnkgYWRkaW5n IHRoaXMgZG9jdW1lbnQKPiBhbmQgdGhlIHNlY3VyaXR5IGVudmlyb25tZW50IGRvY3VtZW50LsKg IFdlIGhhdmUgaGFkIGVhcmx5IGFuZCBsYXRlCj4gcmV2aWV3cy7CoCBTaW5jZSB0aGUgaW5pdGlh bCByZXZpZXcgb24gdGhlIEkyUlMgYXJjaGl0ZWN0dXJlIHdlIGhhdmUKPiBkaXNjdXNzZWQgdGhl IG5vbi1zZWN1cmUgaW50ZXJmYWNlIGFuZCB0cmllZCB0byBnZXQgc2VjdXJpdHkKPiBkaXJlY3Rv cmF0ZSdzIHJldmlldy4KCkkgaGF2ZSBsb29rZWQgYmFjayBhdCB0aGUgc2VjZGlyIG1haWxzIG9u IHRoaXMsIHllcy4KCj4gSSByYWlzZWQgdGhlIHBlcnZhc2l2ZSBwcml2YWN5IGlzc3VlIGFuZCBh c2tlZAo+IGZvciBpbnB1dCBpbiB5b3VyIHJldmlldy4gCgpZZXMuIEFuZCBJIHJlc3BvbmRlZCB3 aXRoIHR3byB3b3VsZC1oYXZlLWJlZW4tZGlzY3VzcyBwb2ludHMgcmVsYXRlZAp0byBwZXJ2YXNp dmUgbW9uaXRvcmluZy4gKEkgYXNzdW1lIHRoYXQgd2hhdCdzIHlvdSBtZWFuIHdoZW4geW91IHNh eQoicGVydmFzaXZlIHByaXZhY3kiIGJ1dCBpZiB5b3UgbWVhbiBzb21ldGhpbmcgZWxzZSBhYm92 ZSwgcGxlYXNlIGRvCmNsYXJpZnkuKQoKPiBUaGlzIG1ldGEtY29tbWVudCBpcyB0aGF0IHByb2Nl c3Mgb2YgYXNraW5nCj4gZm9yIGFpZCBhaGVhZCBvZiB0aGlzIHBvaW50IGhhcyBmYWlsZWQgYWNj b3JkaW5nIHRvIHlvdXIgcmV2aWV3LCAKCkkgdGhpbmsgdGhhdCdzIGFuIG9kZCB2aWV3IG9mIElF VEYgcHJvY2Vzc2VzLCB3aGljaCBhcmUgbmV2ZXIgZXhwZWN0ZWQKdG8gcHJvZHVjZSBwZXJmZWN0 aW9uIGF0IGFueSBzdGFnZS4gSU1PIHdlJ3JlIGl0ZXJhdGluZyB0b3dhcmRzIGJldHRlcgpvdXRj b21lcywgbm90IGZhaWxpbmcvc3VjY2VlZGluZyBhdCBlYWNoIHN0YWdlIG9mIHRoZSBwcm9jZXNz LgoKPiBidXQKPiBJIGNhbm5vdCBmaW5kIGEgcG9pbnQgd2hlcmUgdGhlIEkyUlMgV0cgZGlkIG5v dCBzb2xpY2l0IHRoZSBzZWN1cml0eQo+IGFyZWEncyBhaWQgYW5kIHRha2UgaXRzIGFkdmljZS7C oCBUaGVyZWZvcmUswqAgSSBtdXN0IGFzayB5b3UgdG8gY2hlY2sKPiB0aGUgcHJvY2VzcyBvZiB5 b3VyIHNlY3VyaXR5IGRpcmVjdG9yYXRlJ3MgcmV2aWV3cyB0byBmaW5kIHdoYXQKPiBoYXBwZW5l ZCB0byBjYXVzZSBzdWNoIGEgZmFpbHVyZS4gCgpEb24ndCB0aGluayBvZiBpdCBhcyBmYWlsdXJl LCB0aGluayBvZiBpdCBhcyBtb3JlIGV5ZWJhbGxzIGZpbmRpbmcgbW9yZQp0aGluZ3MuIChPciBy ZXBlYXRpbmcgdGhpbmdzIGFscmVhZHkgY29uc2lkZXJlZCwgZm9yIHRob3NlIHdoZXJlIHRoYXQn cwp0aGUgY2FzZS4pCgo+IE5vdyBhcyB0byB0aGUgZG9jdW1lbnQsIEkgaGF2ZSBhIFdHCj4gd2Fp dGluZyBmb3IgdGhlc2UgcmVxdWlyZW1lbnRzLsKgIAoKSSdkIGVuY291cmFnZSB5b3UgdG8gcXVl c3Rpb24gdGhlIGFib3ZlLCBhcyBhIGZpcnN0IG9yZGVyIGdvYWwuIEFyZQp0aGUgV0cgcmVhbGx5 IHdhaXRpbmcgb24gdGhlc2UgaW4gYSBmaW5hbCwgZml4ZWQtZm9yZXZlciwgZm9ybT8gT3IKZG8g eW91IG5lZWQgYSBnZW5lcmFsIGFncmVlbWVudCBhcyB0byBkaXJlY3Rpb24gYW5kIGNhbiB0aGVu IG1ha2UKcHJvZ3Jlc3M/IChBbmQgcGVyaGFwcyByZWR1Y2UgdGhlIGZpbmFsIHJlcXVpcmVtZW50 cyB0byBSRkMgc3RhdHVzCmxhdGVyIGlmIHRoZXJlJ3MgdmFsdWUgaW4gdGhhdCwgd2hpY2ggdGhl cmUgY2FuIGJlLikKCkFzIEkgbm90ZWQgYSBjb3VwbGUgb2YgdGltZXMgaW4gbXkgcmV2aWV3LCBp dCdzIG5vdCBwb3NzaWJsZSB0byBiZQp0aGF0IHByZWNpc2UgYWJvdXQgc29tZSByZXF1aXJlbWVu dHMgd2l0aG91dCBoYXZpbmcgZG9uZSBtb3JlIG9mIHRoZQpkZXNpZ24uIChPbmUgb2YgdGhlIHRy YWRpdGlvbmFsIHdhdGVyZmFsbGwgZGVzaWduIHByb2JsZW1zIEkgZ3Vlc3MuKQpUaGUgc2NvcGUg b2YgcmVwbGF5IGRldGVjdGlvbiBpcyBwcm9iYWJseSBhIGdvb2QgZXhhbXBsZS4KCj4gSSB3b3Vs ZCBsaWtlIHRvIGhlYXIgaW4gYSBjb21wbGV0ZWx5Cj4gc2VwYXJhdGUgZW1haWwgdGhyZWFkIHdo YXQga2VybmVsIG9mIGluZm9ybWF0aW9uIHlvdSB3b3VsZCBoYXZlCj4gZXhwZWN0ZWQgcmVnYXJk aW5nIHRoZSBzZWN1cml0eSBmaXJzdCBhbiBpMnJzIHByb3RvY29sLsKgIAoKSSBkb24ndCB1bmRl cnN0YW5kIHlvdXIgcXVlc3Rpb24gc29ycnkuCgo+IEkgd291bGQgdGhlbgo+IGxpa2UgdG8gY29t cGFyZSB0aGlzIGFnYWluc3QgdGhlIHNlY3VyaXR5IGRpcmVjdG9yYXRlJ3Mgc3VnZ2VzdGlvbnMK PiBvbiB0aGlzIGRvY3VtZW50LsKgIFdlIGhhdmUgYSBzZWNvbmQgZG9jdW1lbnQgb24gdGhlIHNl Y3VyaXR5Cj4gZW52aXJvbm1lbnQgc28geW91ciBpbnNpZ2h0cyB3aWxsIGJlIGFwcGxpZWQgdG8g dGhhdCBkb2N1bWVudC4gU2luY2UKPiBpbiB0aGUgZ2VuZXJhbCB0ZXh0IHlvdSBpbmRpY2F0ZSB0 aGUgc3R5bGUgaXMgdGVycmlibGUgYW5kIG5lZWRzIHRvCj4gYmUgd3JpdHRlbiwgcGxlYXNlIHBy b3ZpZGUgYW4gZXhhbXBsZSBvZiBhIGRvY3VtZW50IGFzIGFuIGV4YW1wbGUgb2YKPiB0aGUgc3R5 bGUuwqAgCgpSZWFsbHk/IFRoZSBhY2N1bXVsYXRpb24gb2YgYmFkbHkgd3JpdHRlbiBzZW50ZW5j ZXMgaW4gLTA5IGhhcyBnb3QKdG8gYmUgYSBjbGVhciBlbm91Z2ggcHJvYmxlbSB0aGF0IHlvdSBk b24ndCBuZWVkIGFuIGV4YW1wbGUgb2Ygd2hhdAppcyBub3QtdGhhdC4gU28gSSdtIHB1enpsZWQg YXQgdGhlIHJlcXVlc3QuCgo+IE15IHVuZGVyc3RhbmRpbmcgaXMgdGhhdCBzdHlsZSBpcyBhIGxv d2VyIHByaW9yaXR5IHRoYW4KPiB0ZWNobmljYWwgY29ycmVjdG5lc3MgYW5kIGNvbnNlbnN1cy4g CgpDb3JyZWN0L2dvb2QtZW5vdWdoIHdyaXRpbmcgaXMgY2VydGFpbmx5IHNlY29uZGFyeSwgdXAg dW50aWwgdGhlCmlzc3VlcyBnZXQgdG8gYSBjZXJ0YWluIHBvaW50IHRoYXQgaW1waW5nZXMgb24g dGhlIHJlYWRlcidzIGFiaWxpdHkKdG8gYXNzZXMgdGhlIG1lYW5pbmcsIGFuZCB0aGF0IGhhcHBl bnMgYSBjb3VwbGUgb2YgdGltZXMgaW4gdGhpcwpkb2N1bWVudC4gKEFzIEkgc2FpZCBpbiBteSBy ZXZpZXcuKSBUaGUgb3RoZXIgd3JpdGluZyBpc3N1ZXMgbWFrZQp0aGlzIGEgaGFyZGVyIHJlYWQg dGhhbiBvdWdodCBiZSB0aGUgY2FzZS4gVGhhdCBkb2Vzbid0IHJlYWNoIHRoZQpsZXZlbCBvZiBt YWtpbmcgdGhlIGRvY3VtZW50IHVucmVhZGFibGUsIG5vciBuZWFybHkgZ2V0IHRoYXQgYmFkLApi dXQgaXQgaXMgZW5vdWdoIHRoYXQgSSB3b25kZXIgaWYgb3RoZXIgcmVhZGVycyBtYXkgaGF2ZSBi ZWVuIHB1dApvZmYgYnkgdGhhdCBpbiByZWFkaW5nIHNvbWUgb2YgdGhlIHRleHQuCgo+IFRoaXMg ZW1haWwgZW5kcyBteSBjb21tZW50cyBvbgo+IHlvdXIgc3VtbWFyeSBtZXNzYWdlLsKgIFRoZSBu ZXh0IHNldCBvZiBjb21tZW50cyB3aWxsIHRha2UgeW91cgo+IGRpc2N1c3MgY29tbWVudHMgb25l IGF0IGEgdGltZS4gVGhlIGV4YWN0IG5leHQgc3RlcHMgdGhhdCBJIGFuZCBteQo+IGNvLWF1dGhv ciB3aWxsIHRha2Ugd2lsbCBiZSBndWlkZWQgYnkgdGhlIEFEIHJlc3BvbnNpYmxlIGZvciB0aGUg STJSUwo+IFdHLCAKClRoYXQncyBhbGwgZ29vZC4KCkkgd291bGQgcmUtaXRlcmF0ZSB0aG91Z2gs IHRoYXQgc2luY2UgbXkgYmFsbG90IGlzIGFuIGFic3RhaW4gdGhlcmUncwpubyBvbnVzIG9uIHlv dSBvciB0aGUgV0cgdG8gcmVzcG9uZCBpbiBhbnkgbW9yZSBkZXRhaWwgdGhhbiB5b3UgZmVlbApp cyB1c2VmdWwuCgpDaGVlcnMsClMuCgo+IEFsaWEuIENoZWVyaWx5LMKgIFN1ZSBIYXJlcwo+IAo+ IFNlbnQgdmlhIHRoZSBTYW1zdW5nIEdhbGF4eSBOb3RlNSwgYW4gQVQmVCA0RyBMVEUgc21hcnRw aG9uZSAtLS0tLS0tLQo+IE9yaWdpbmFsIG1lc3NhZ2UgLS0tLS0tLS1Gcm9tOiBTdGVwaGVuIEZh cnJlbGwKPiA8c3RlcGhlbi5mYXJyZWxsQGNzLnRjZC5pZT4gRGF0ZTogOC8yMS8xNsKgIDg6Mzcg QU3CoCAoR01ULTA1OjAwKSBUbzoKPiBUaGUgSUVTRyA8aWVzZ0BpZXRmLm9yZz4gQ2M6IGpoYWFz QHBmcmMub3JnLCBpMnJzQGlldGYub3JnLAo+IGkycnMtY2hhaXJzQGlldGYub3JnLAo+IGRyYWZ0 LWlldGYtaTJycy1wcm90b2NvbC1zZWN1cml0eS1yZXF1aXJlbWVudHNAaWV0Zi5vcmcgU3ViamVj dDoKPiBbaTJyc10gU3RlcGhlbiBGYXJyZWxsJ3MgQWJzdGFpbiBvbiAKPiBkcmFmdC1pZXRmLWky cnMtcHJvdG9jb2wtc2VjdXJpdHktcmVxdWlyZW1lbnRzLTA5OiAod2l0aCBDT01NRU5UKSAKPiBT dGVwaGVuIEZhcnJlbGwgaGFzIGVudGVyZWQgdGhlIGZvbGxvd2luZyBiYWxsb3QgcG9zaXRpb24g Zm9yIAo+IGRyYWZ0LWlldGYtaTJycy1wcm90b2NvbC1zZWN1cml0eS1yZXF1aXJlbWVudHMtMDk6 IEFic3RhaW4KPiAKPiBXaGVuIHJlc3BvbmRpbmcsIHBsZWFzZSBrZWVwIHRoZSBzdWJqZWN0IGxp bmUgaW50YWN0IGFuZCByZXBseSB0bwo+IGFsbCBlbWFpbCBhZGRyZXNzZXMgaW5jbHVkZWQgaW4g dGhlIFRvIGFuZCBDQyBsaW5lcy4gKEZlZWwgZnJlZSB0bwo+IGN1dCB0aGlzIGludHJvZHVjdG9y eSBwYXJhZ3JhcGgsIGhvd2V2ZXIuKQo+IAo+IAo+IFBsZWFzZSByZWZlciB0bwo+IGh0dHBzOi8v d3d3LmlldGYub3JnL2llc2cvc3RhdGVtZW50L2Rpc2N1c3MtY3JpdGVyaWEuaHRtbCBmb3IgbW9y ZQo+IGluZm9ybWF0aW9uIGFib3V0IElFU0cgRElTQ1VTUyBhbmQgQ09NTUVOVCBwb3NpdGlvbnMu Cj4gCj4gCj4gVGhlIGRvY3VtZW50LCBhbG9uZyB3aXRoIG90aGVyIGJhbGxvdCBwb3NpdGlvbnMs IGNhbiBiZSBmb3VuZCBoZXJlOiAKPiBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9k cmFmdC1pZXRmLWkycnMtcHJvdG9jb2wtc2VjdXJpdHktcmVxdWlyZW1lbnRzLwo+Cj4gCj4gCj4g Cj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLQo+Cj4gCkNPTU1FTlQ6Cj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQo+Cj4gCj4gCj4g Rmlyc3QsIGFwb2xvZ2llcyBmb3Igbm90IGdldHRpbmcgbXkgcmV2aWV3IGRvbmUgZm9yIHRoaXMg d2hlbiBpdCB3YXMKPiBzY2hlZHVsZWQgZHVlIHRvIG15IHZhY2F0aW9uIGFuZCB0aGFua3MgZm9y IGJlaW5nIHdpbGxpbmcgdG8gZGVmZXIKPiB0aGUgZG9jdW1lbnQuCj4gCj4gU2Vjb25kLCBoYXZp bmcgbm93IHByb3Blcmx5IHJldmlld2VkIHRoaXMsIEkgYW0gYmFsbG90aW5nIGFic3RhaW4gYXMK PiBJIHRoaW5rIGl0J3MgdW5saWtlbHkgdGhhdCB0aGlzIGRvY3VtZW50IGNhbiBiZSBmaXhlZCBp biBhIHdheSB0aGF0Cj4gcmVzdWx0cyBpbiBzb21ldGhpbmcgdXNlZnVsIGhhcHBlbmluZy4gSSB0 aGluayB0aGF0IHRoZSBsaWtlbHkgCj4gb3V0Y29tZSBpcyB0aGF0IHRoaXMgZG9jdW1lbnQgd2ls bCBiZSB1c2VkIGxhdGVyIHdoZW4gcGVvcGxlIGFyZQo+IGFyZ3VpbmcgYW5kIHdpbGwgbm90IG11 Y2ggaGVscCBpbiByZXNvbHZpbmcgdGhvc2UgYXJndW1lbnRzLCBvciBlbHNlCj4gdGhpcyB3aWxs IGJlIGlnbm9yZWQgYW5kIGFyZ3VtZW50cyB3aWxsIGJlIGhlbGQgYWZyZXNoLCBhcyBuZWVkZWQu Cj4gVGhhdCBsYXR0ZXIgb3V0Y29tZSBpcyB3aGF0IEknZCBndWVzcyBpcyBtb3N0IGxpa2VseSBh bmQgdGhlcmVmb3JlIGl0Cj4gc2VlbXMgdGhhdCBzcGVuZGluZyBhbGwgb2Ygb3VyIGN5Y2xlcyBv biBESVNDVVNTIGJhbGxvdCBwcm9jZXNzaW5nCj4gZm9yIHRoaXMgd291bGQgbm90IGJlIHdpc2Uu IFRoYXQgc2FpZCwgSSBhbSB3aWxsaW5nIHRvIGNoYW5nZSB0byBhCj4gRElTQ1VTUyBiYWxsb3Qg aWYgdGhlIHJlc3BvbnNpYmxlIEFEIHByZWZlcnMgdGhhdCwgYnV0IEkgc3VzcGVjdCBJJ2xsCj4g ZW5kIHVwIHdpdGggYW4gYWJzdGFpbiBpbiBhbnkgY2FzZSwgYWZ0ZXIgc29tZSBkaXNjdXNzaW9u LiBUaGUgb25seQo+IHBsYW4gSSBjYW4gdGhpbmsgb2YgdGhhdCdkIGxlYWQgdG8gbWUgZW5kaW5n IHVwIHdpdGggYSB5ZXMgb3IKPiBuby1vYmplY3Rpb24gYmFsbG90IHdvdWxkIGJlIGlmIHRoaXMg d2FzIHJldHVybmVkIHRvIHRoZSBXRyBmb3IKPiBmaXhpbmcgYW5kIHBvc3NpYmx5IG1ham9yIHN1 cmdlcnksIHdoaWNoIGlzIHdoYXQgSSBhY3R1YWxseSB0aGluawo+IHdvdWxkIGJlIHRoZSBiZXN0 IHBsYW4uIChJIHJlYWxpc2UgdGhpcyBoYXMgaGFkIGEgc29tZXdoYXQgdG9ydHVyZWQgCj4gaGlz dG9yeSwgc28gZm9sa3MgbWF5IG5vdCBiZSB3aWxsaW5nIHRvIHRha2UgaXQgYmFjayB0byB0aGUg V0csIGJ1dAo+IGhvbmVzdGx5LCBJIHRoaW5rIHRoZSBmYWlsaW5ncyB2aXNpYmxlIGluIHRoaXMg ZG9jdW1lbnQgZG8gaW5kaWNhdGUKPiB0aGF0IHRoaXMgaXMgbm90IHJlYWR5IGZvciBhcHByb3Zh bCBhbmQgb3VnaHQgYmUgcmV0dXJuZWQgdG8gdGhlCj4gV0cuKQo+IAo+IFRoaXJkLCBJIHRoaW5r IHRoZSBvdmVyYWxsIHNldCBvZiByZXF1aXJlbWVudHMgcG9zZWQgaGVyZSBtaWdodCAod2l0aAo+ IHNvbWUgdW5rbm93biBwcm9iYWJpbGl0eSkgbGVhZCB0byBsYXRlciBzcGVjaWZpY2F0aW9ucyB0 aGF0IGFyZQo+IGNvbnNpZGVyZWQgdG9vIGhhcmQgdG8gZGVwbG95LCB3aXRoIHRoZSByZXN1bHQg dGhhdCBub24tc2VjdXJlCj4gdmFyaWFudHMgb2YgSTJSUyBiZWNvbWUgdGhlIG5vcm0uIFRoYXQg c2VlbXMgbGlrZSBpdCB3b3VsZCBiZSBhIAo+IHJlYWxseSBiYWQgb3V0Y29tZS4gSSB3b3VsZCBz dWdnZXN0IHRoYXQgbWlnaHQgYmUgcGFydGx5IG1pdGlnYXRlZCBpZgo+IGEgcmVxdWlyZW1lbnQg d2VyZSBhZGRlZCB0byB0aGUgZWZmZWN0IHRoYXQgZGVwbG95bWVudCBpc3N1ZXMgYW5kCj4gc3Bl Y2lmaWNhbGx5IGVhc2Ugb2YgZGVwbG95bWVudCBNVVNUIGJlIGNvbnNpZGVyZWQgYXMgYSBmaXJz dCBvcmRlciAKPiByZXF1aXJlbWVudCB3aGVuIGRldmVsb3BpbmcgSTJSUyBwcm90b2NvbCBzb2x1 dGlvbnMuCj4gCj4gRm91cnRoLCB0aGUgKDE5ISkgY29tbWVudHMgYmVsb3cgdGhhdCBhcmUgcHJl Y2VkZWQgYnkgIihkaXNjdXNzIgo+IHdvdWxkIGhhdmUgYmVlbiBESVNDVVNTIGJhbGxvdCBwb2lu dHMgaGFkIEkgbm90IGRlY2lkZWQgdG8gYWJzdGFpbi4gSQo+IGFtIGhhcHB5IHRvIGNoYXQgYWJv dXQgYW55IG9mIG15IGNvbW1lbnRzIGJlbG93LCBidXQgaWYgdGhlCj4gYXV0aG9ycy9XRyBkbyB3 YW50IHRvIGNoYXQsIGl0IG1pZ2h0IGJlIG1vcmUgZWZmaWNpZW50IHRvIGNvbmNlbnRyYXRlCj4g b24gdGhvc2UgdGhhdCB3b3VsZCBvdGhlcndpc2UgaGF2ZSBiZWVuIERJU0NVU1MgcG9pbnRzLiAo QnV0IHRoYXQncwo+IHlvdXIgY2FsbCwgSSBkb24ndCBtaW5kLikgSSB0aGluayB0aGUgMTkgd291 bGQtaGF2ZS1iZWVuLWRpc2N1c3MKPiBwb2ludHMgaXMgYW5vdGhlciBjbHVlIHRoYXQgdGhpcyBv dWdodCByZWFsbHkgYmUgc2VudCBiYWNrIHRvIHRoZQo+IFdHLgo+IAo+IEFuZCB3aXRoIHRoYXQs IGFuZCB3aXRoIGFwb2xvZ2llcyBmb3IgdGhpcyBiZWluZyBzdWNoIGFuIG92ZXJhbGwKPiBuZWdh dGl2ZSByZXZpZXcsIGhlcmUncmUgbXkgZGV0YWlsZWQgY29tbWVudHM6Cj4gCj4gLSBnZW5lcmFs OiBUaGUgd3JpdGluZyBoZXJlIGlzIGdlbmVyYWxseSBwb29yLCBmb3IgZXhhbXBsZSB0aGUgb3Bl bmVyCj4gaXMgIlRoaXMgcHJlc2VudHMuLi4iIHdoZXJlYXMgaXQgb3VnaHQgYmUgIlRoaXMgZG9j dW1lbnQgcHJlc2VudHMuLi4iCj4gKG9yIHMvZG9jdW1lbnQvd2hhdGV2ZXIgeW91IHByZWZlci8p LiBTdWNoIGlzc3VlcyBhcmUgcmVwZWF0ZWRseSBzZWVuCj4gYW5kIGFsbCB0aGF0IG1ha2VzIHRo aXMgYSBtdWNoIGhhcmRlciByZWFkIHRoYW4gb3VnaHQgYmUgdGhlIGNhc2UuCj4gSSdkIHN0cm9u Z2x5IHJlY29tbWVuZCBhbiBlZGl0b3JpYWwgcGFzcyBmcm9tIHNvbWVvbmUgd2hvIGhhc24ndCBi ZWVuCj4gZG93biBpbiB0aGUgd2VlZHMgd2l0aCB0aGlzIHRleHQgZm9yIGEgd2hpbGUgKHdoaWNo IGNvdWxkIGJlIG9uZSBvZiAKPiB0aGUgYXV0aG9ycywgaWYgb25lIG9mIHRoZW0gaGFzIGJlZW4g bGVzcyBhY3RpdmUgcmVjZW50bHkuKSBOb3RlIHRoYXQKPiB0aGlzIGlzIG5vdCBvbmx5IChidXQg aXMgcHJpbWFyaWx5KSBhbiBlZGl0b3JpYWwgaXNzdWUgLSB0aGVyZSBhcmUKPiBzb21lIGNhc2Vz IChob3BlZnVsbHkgY2FsbGVkIG91dCBiZWxvdykgd2hlcmUgdGhlIHdyaXRpbmcgZG9lcyBjcmVh dGUKPiByZWFsIGFtYmlndWl0eSB0aGF0IG1pZ2h0IGxlYWQgdG8gcmUtb3BlbmluZyBvbGQgYXJn dW1lbnRzIGxhdGVyLgo+IAo+IC0gYWJzdHJhY3Q6ICJtdXR1YWwgYXV0aGVudGljYXRpb24sIHRy YW5zcG9ydCBwcm90b2NvbHMsIGRhdGEKPiB0cmFuc2ZlciBhbmQgdHJhbnNhY3Rpb25zIiBkb24n dCBzZWVtIHRvIG1lIHRvIGJlIGNvbW1lbnN1cmF0ZQo+IHRoaW5ncywgc28gdGhlIGFic3RyYWN0 LCBhcyB3cml0dGVuIGlzIHZlcnkgdW5pbmZvcm1hdGl2ZSBmb3IgbWUuCj4gCj4gLSBpbnRybyAz cmQgcGFyYTogSSdtIHJlYWxseSBub3Qgc3VyZSB3aGF0IHlvdSdyZSB0ZWxsaW5nIG1lIGFib3V0 Cj4gW0ktRC5pZXRmLWkycnMtZXBoZW1lcmFsLXN0YXRlXS7CoCAiVGhlIGRyYWZ0IFtSRkM3OTIy XSIgaXMgb2RkLCB0aGF0Cj4gYmVpbmcgbm8gbG9uZ2VyIGEgZHJhZnQuIEknZCBoYXZlIGV4cGVj dGVkIHN1Y2ggbml0cyB3b3VsZCBoYXZlIGJlZW4KPiBmaXhlZCBieSBub3cgVEJILiBTYW1lIGZv ciB0aGUgbGFzdCBzZW50ZW5jZS7CoCBUaGF0IHBhcmEgbWFrZXMgdGhlCj4gaW50cm8gcHJldHR5 IHVuY2xlYXIgZm9yIG1lLgo+IAo+IC0gMi4yOiBUaGUgZGVmaW5pdGlvbiBvZiBoaWdoZXIgbGV2 ZWwgcHJvdG9jb2wgc2VlbXMgbGlrZSBhbiBvZGQKPiBwbGFjZSB0byBpbnRyb2R1Y2UgdGhlIGZh Y3QgdGhhdCBpMnJzID09IG5ldGNvbmYgKyByZXN0Y29uZi7CoCBUaGF0J2QKPiBiZSBtb3JlIHVz ZWZ1bGx5IHNhaWQgaW4gdGhlIGFic3RyYWN0L2ludHJvIGlmIHRoYXQncyBzb2xpZGx5IGFncmVl ZAo+IGJ5IHRoZSBXRy4KPiAKPiAtIDIuMjogVGhpcyBpcyB3cm9uZzogIldoaWxlIGl0IGlzIHBv c3NpYmxlIHRvIGhhdmUgYW4gSTJSUyBvcGVyYXRpb24KPiB3aGljaCBpcyBjb250YWluZWQgaW4g bXVsdGlwbGUgSTJSUyAoRS5nLsKgIHdyaXRlIGluIG11bHRpcGxlCj4gbWVzc2FnZXMpLCB0aGlz IGlzIG5vdCBzdXBwb3J0ZWQgaW4gb3JkZXIgdG8gc2ltcGxpZnkgdGhlIGZpcnN0Cj4gdmVyc2lv biBvZiBJMlJTLiIgVGhlIHJlYXNvbiB0aGlzIGlzIHdyb25nLCBpcyB0aGF0IGl0IGlzIGhlcmUg dGhhdAo+IHlvdSBhcmUgZGVmaW5pbmcgdGhhdCBpdCBpcyBub3QgcG9zc2libGUgdG8gaGF2ZSBh biBvcGVyYXRpb24gaW4KPiBtdWx0aXBsZSBtZXNzYWdlcy4gcy9pdCBpcy9pdCBjb3VsZCBoYXZl IGJlZW4vIHdvdWxkIHdvcmsgbWF5YmUuCj4gCj4gLSAyLjI6ICIgKsKgIFRoZSBJMlJTIGNsaWVu dCBpc3N1ZXMgYSByZWFkIHJlcXVlc3QgdG8gYSBJMlJTIGFnZW50LAo+IGFuZCB0aGUgSTJSUyBB Z2VudCByZXNwb25kaW5nIHRvIHRoZSByZWFkIHJlcXVlc3QiIFNob3VsZG4ndCB0aGF0IHVzZQo+ IHJlc3BvbmQgYW5kIG5vdCByZXNwb25kaW5nPyBHaXZlbiB0aGF0IHlvdSBzZWVtIHRvIGJlIHRy eWluZyB0bwo+IGRlZmluZSB0aGUgc2NvcGUgb2Ygd2hhdCBpcyBhbmQgaXMgbm90IGEgdHJhbnNh Y3Rpb24sIEkgdGhpbmsgYmVpbmcKPiBwcmVjaXNlIHdpdGggdGhlIGxhbmd1YWdlIGlzIHNvbWV0 aGluZyB3ZWxsIHdvcnRoIGRvaW5nLsKgIFRoZSAybmQKPiBidWxsZXQgY291bGQgYWxzbyBkbyB3 aXRoIGEgcmUtd3JpdGUuCj4gCj4gKGRpc2N1c3MxKSAyLjI6IHlvdSBzb3J0LW9mIGRlZmluZSBt ZXNzYWdlcywgb3BlcmF0aW9ucywgdHJhbnNhY3Rpb25zCj4gYW5kIGFjdGlvbnMuIE5vbmUgb2Yg dGhlIGRlZmluaXRpb25zIGFyZSB0aGF0IHByZWNpc2UsIGUuZy4gYXJlIHRob3NlCj4gdGhlIG9u bHkgb3BlcmF0aW9ucyBvciBleGFtcGxlcz8gQW5kIHRyYW5zYWN0aW9uIGFuZCBhY3Rpb24gYXJl bid0Cj4gcmVhbGx5IGRlZmluZWQgYXQgYWxsLiBJJ20gbm90IHN1cmUgaWYgdGhhdCdzIGxpa2Vs eSB0byBiZSBhIHByb2JsZW0KPiBvciBub3QuIEkgc3VzcGVjdCBpdCB3aWxsIGxhdGVyLCBlLmcu IHdoZW4geW91IGdldCB0byBmaWd1cmluZyBvdXQKPiB0aGUgc2NvcGUgd2l0aGluIHdoaWNoIHJl cGxheSBuZWVkcyB0byBiZSBkZXRlY3RhYmxlLgo+IAo+IC0gMi4yOiBzL3RyYW5zYXRpb24vdHJh bnNhY3Rpb24vCj4gCj4gKGRpc2N1c3MyKSAtIDIuMjogImRlZmluZXMgYSBzZWNvbmRhcnkgaWRl bnRpdHkgYXMgdGhlIGVudGl0eSBvZiBzb21lCj4gbm9uLUkyUlMgZW50aXR5ICIgVGhhdCBjb3Vs ZCBiZSBhYnVzZWQgZm9yIHRyYWNraW5nIG9mIHZhcmlvdXMga2luZHMKPiBJIHdvdWxkIGd1ZXNz LCBlLmcuIGlmIGFuIElNRUkgd2VyZSB1c2VkLiBJIHRoaW5rIHlvdSBuZWVkIHRvIG5vdGUKPiB0 aGF0IGFuZCBzaG91bGQgaW1wb3NlIHNvbWUgcmVxdWlyZW1lbnRzIHRoYXQgc3VjaCBzZWNvbmRh cnkgCj4gaWRlbnRpZmllcnMgYXJlIG5vdCB1c2VkIHRodXNseSBmb3IgdHJhY2tpbmcuwqAgQWxz bywgc2hvdWxkIHRoZSBmaXJzdAo+IG9jY3VycmVuY2Ugb2YgZW50aXR5IHRoZXJlIGJlIGlkZW50 aXR5Pwo+IAo+IC0gMywgMXN0IHBhcmE6IHMvVGhlIHNlY3VyaXR5IGZvciB0aGUvVGhlLyAtIHRo ZXJlIGlzbid0IGEgdGhpbmcKPiBjYWxsZWQgdGhlIHNlY3VyaXR5IGZvciB0aGUgaTJycyBwcm90 b2NvbC4KPiAKPiAoZGlzY3VzczMpIC0gc2VjdGlvbiAzIHNheXMgInRoZSBJMlJTIHByb3RvY29s IHJlcXVpcmVzIG11dHVhbGx5Cj4gYXV0aGVudGljYXRlZCBJMlJTIGNsaWVudHMgYW5kIEkyUlMg YWdlbnRzIGNvbW11bmljYXRpbmcgb3ZlciBhCj4gc2VjdXJlIHRyYW5zcG9ydC4iIFRvIG1lIHRo YXQgaW1wbGllcyB0aGF0IHNvbWV0aGluZyBsaWtlIFRMUyBvciBTU0gKPiBpcyBNVFUgd2hpY2gg c2VlbXMgdG8gY29udHJhZGljdCByZWNlbnQgZW1haWxzLgo+IAo+IC0gc2VjdGlvbiAzIHNheXM6 ICJUaGUgSTJSUyBwcm90b2NvbCBNVVNUIGJlIGFibGUgdG8gcHJvdmlkZQo+IGF0b21pY2l0eSBv ZiBhbiBJMlJTIHRyYW5zYWN0aW9uLCBidXQgaXQgaXMgbm90IHJlcXVpcmVkIHRvIGhhdmUKPiBt dWx0aS1tZXNzYWdlIGF0b21pY2l0eSBhbmQgcm9sbC1iYWNrIG1lY2hhbmlzbSB0cmFuc2FjdGlv bnMuCj4gTXVsdGlwbGUgbWVzc2FnZXMgdHJhbnNhY3Rpb25zIG1heSBiZSBpbXBhY3RlZCBieSB0 aGUgaW50ZXJkZXBlbmRlbmN5Cj4gb2YgZGF0YS4iwqAgSSBkb24ndCBiZWxpZXZlIHRoYXQgdGhh dCdzIGVhc2lseSBlbm91Z2ggdW5kZXJzdG9vZCB0byBiZQo+IHVzZWZ1bC4gQWxzbywgd291bGRu J3Qgcy9NdWx0aXBsZSBtZXNzYWdlcyAKPiB0cmFuc2FjdGlvbnMvTXVsdGlwbGUtbWVzc2FnZSB0 cmFuc2FjdGlvbnMvIGJlIG11Y2ggY2xlYXJlciBpZiB0aGF0J3MKPiB3aGF0J3MgbWVhbnQ/IEFu ZCBmaW5hbGx5LCBJIHRoaW5rIHRoZSBNVVNUIGVtYmVkZGVkIGluIHRoZSBhYm92ZSBpcwo+IG5v dCB0aGF0IGdyZWF0IGFuIGlkZWEgLSBpdCdzIGNsZWFyZXIgSU1PIHRvIHNlcGFyYXRlIHRoZSAy MTE5Cj4gbGFuZ3VhZ2UgZnJvbSBpbnRyb2R1Y3RvcnkgdGV4dCBpbiBkb2N1bWVudHMgbGlrZSB0 aGlzLgo+IAo+IC0gMzogIlRoZXJlIGFyZSBkZXBlbmRlbmNpZXMgaW4gc29tZSBvZiB0aGUgcmVx dWlyZW1lbnRzIGJlbG93IiB3b3VsZAo+IGJlIGJldHRlciBhcyAiVGhlcmUgYXJlIGludGVyLWRl cGVuZGVuY2llcyBiZXR3ZWVuIHNvbWUgb2YgdGhlCj4gcmVxdWlyZW1lbnRzIGJlbG93IiB1bmxl c3MgeW91IG1lYW4gZGVwZW5kZW5jaWVzIG9uIHNvbWUgZXh0ZXJuYWwgCj4gdGhpbmdzLCB3aGlj aCBpcyBub3QgY2xlYXIgZnJvbSB0aGUgdGV4dCBhcy1pcy4KPiAKPiAoZGlzY3VzczQpICIgRm9y IGNvbmZpZGVudGlhbGl0eSAoc2VjdGlvbiAzLjMpIGFuZCBpbnRlZ3JpdHkgKHNlY3Rpb24KPiAz LjQpIHRvIGJlIGFjaGlldmVkLCB0aGUgY2xpZW50LWFnZW50IG11c3QgaGF2ZSBtdXR1YWwgYXV0 aGVudGljYXRpb24KPiAoc2VjdGlvbiAzLjEpIGFuZCBzZWN1cmUgdHJhbnNwb3J0IChzZWN0aW9u IDMuMikuwqAgIiBUaGlzIGlzIAo+IGluY29ycmVjdC4gT25lIGNhbiBoYXZlIGNvbmZpZGVudGlh bGl0eSB3aXRob3V0IGF1dGhlbnRpY2F0aW9uIChzZWUKPiBSRkM3NDM1KSBzbyB0aGUgdGV4dCBp cyBub3QgYWNjdXJhdGUuCj4gCj4gLSBjYXBpdGFsaXNhdGlvbiBuZWVkcyBmaXhpbmcgaW4gdmFy aW91cyBwbGFjZXMsIGUuZy4gYXJvdW5kIHRoZSBlbmQKPiBvZiBwNSwgd2UgZ2V0ICJzZWN1cmUg VHJhbnNwb3J0IiBhbmQgdGhlbiAiSTJSUyBjbGllbnQiIGFuZCAiSTJSUwo+IEFnZW50IiBpbiB0 aGUgdGl0bGUgb2YgMy4xIElzIGFueSBvZiB0aGF0IGNhcGl0YWxpc2F0aW9uIHN1cHBvc2VkIHRv Cj4gYmUgc2lnbmlmaWNhbnQ/IEVpdGhlciB3YXksIGZpeGluZyBpdCBub3cgd291bGQgYmUgZ29v ZCBhcyB5b3UnbGwKPiBuZWVkIHRvIGdldCB0aGUgUkZDIGVkaXRvciB0byBkbyBpdCBsYXRlciBp ZiB5b3UgZG9uJ3QgKHdoaWNoIHRha2VzCj4gbG9uZ2VyKS4KPiAKPiAoZGlzY3VzczUpIFNFQy1S RVEtMDE6IHdoYXQgaXMgdGhlIHNjb3BlIG9mIHVuaXF1ZW5lc3MgcmVxdWlyZWQgaGVyZT8KPiBJ IHNlZSBubyByZWFzb24gd2h5IHR3byBkaWZmZXJlbnQgZGF0YSBjZW50cmVzIGNhbm5vdCByZS11 c2UgYSBjbGllbnQKPiBvciBhZ2VudCBpZGVudGlmaWVyLCBpZiB0aGV5IHNvIHdpc2guIEknZCBi ZSBmaW5lIGlmIHlvdSBzYXkgdGhhdCdzCj4gZm9yIGxhdGVyIGRlY2lzaW9uLCBidXQgYmVpbmcg c2lsZW50IG9uIHRoZSBtYXR0ZXIgY291bGQgbGVhZCB0byAKPiB0cm91YmxlIGxhdGVyIGlmIGRp ZmZlcmVudCBmb2xrcyBkZWNpZGUgZGlmZmVyZW50bHkuCj4gCj4gKGRpc2N1c3M2KSBTRUMtUkVR LTAyOiB0aGUgIk1VU1QgdXRpbGl6ZSIgdGhlcmUgbWVhbnMgTVRVLCB3aGljaAo+IHdhc24ndCB3 aGF0IHlvdSB3YW50ZWQgSSB0aGluawo+IAo+IChkaXNjdXNzNykgLSBTRUMtUkVRLTAzOiBob3cg aXMgInVwb24gcmVjZWl2aW5nLi4uIE1VU1QgY29uZmlybSIgYQo+IGdvb2QgY2hvaWNlPyBBcyBz dGF0ZWQgdGhhdCdkIGJlIGh1Z2VseSBvbmVyb3VzLCBpbXBseWluZyBlLmcuwqAgT0NTUAo+IGNo ZWNrcyBmb3IgZWFjaCBwYWNrZXQgcmVjZWl2ZWQuIFNhbWUgcG9pbnQgYXBwbGllcyB0byBTRUMt UkVRLTA0Lgo+IAo+IChkaXNjdXNzOCkgLSBTRUMtUkVRLTA1OiB0aGlzIGVpdGhlciBtZWFucyBu b3RoaW5nIGF0IGFsbCAoYmVpbmcgYQo+IHRhdXRvbG9neSkgb3IgZWxzZSBzb21ldGhpbmcgSSBk b24ndCBnZXQuIEkgdGhpbmsgaXQncyB0aGUgZm9ybWVyLAo+IGJ1dCBhbSBub3Qgc3VyZS4KPiAK PiAtIDMuMTogcy9PbmUgbWVjaGFuaXNtIHN1Y2ggbWVjaGFuaXNtL09uZSBzdWNoIG1lY2hhbmlz bS8gSSBndWVzcy4KPiBBbmQgaXQncyBub3QgYXQgYWxsIGNsZWFyIHRvIG1lICJBQUEgcHJvdG9j b2xzIiBpcyB0aGUgcmlnaHQgaWRlYQo+IHRoZXJlLCBhbmQgbm9yIGlzIGl0IGNsZWFyIHdoYXQn cyBtZWFudCwgd2l0aCB0aGUgdGV4dCBhcy1pcy4KPiAKPiAtIFNFQy1SRVEtMDY6IHdoZXJlIGlz IGEgInByaW9yaXR5IiBkZWZpbmVkPwo+IAo+IC0gU0VDLVJFUS0wNzogaGVyZSB5b3Ugc2F5IHJl YWQvd3JpdGUgaXMgYSB0cmFuc2FjdGlvbiwgYnV0IGVhcmxpZXIKPiB5b3Ugc2FpZCBpdCB3YXMg YW4gb3BlcmF0aW9uLCB3aGljaCBpcyBpdD8KPiAKPiAoZGlzY3VzczkpIDMuMjogQXMgd2l0aCBv dGhlcnMsIEkgZG9uJ3QgdGhpbmsgdGhlIGlkZWEgb2YgYW5ub3RhdGluZwo+IHBhcnRzIG9mIHlh bmcgbW9kdWxlcyB3aXRoICJjYW4gYmUgaW5zZWN1cmUiIGlzIGEgZ29vZCBvbmUuIFRoZXJlJ3Mg YQo+IHNlcGFyYXRlIHRocmVhZCBkaXNjdXNzaW5nIHRoYXQgdGhvdWdoLCBzbyBtYXliZSBiZXR0 ZXIgdG8gbm90IGZvcmsgCj4gdGhhdC4KPiAKPiAoZGlzY3VzczEwKSAtIFNFQy1SRVEtTzk6IEkg aGF0ZSB0byBkbyB0aGlzIHRvIHlhLCBidXQgQkNQMTA3IGlzIElNTwo+IGEgZmFpcmx5IGNsZWFy IGZhaWx1cmUgd2hlbiBpdCBjb21lcyB0byByb3V0aW5nLiBBbmQgeWV0IGFnYWluIHRoZQo+IGV4 Y2VwdGlvbnMgY2xhdXNlcyBoZXJlIGFyZSBzbyBicm9hZCBhcyB0byBiZSBtZWFuaW5nbGVzcyAo ZS5nLgo+IGNvbnNpZGVyZWQgbG93IHZhbHVlIGJ5IHdob20/KS4gV2hhdCBpcyB0aGUgcmVhbCBn b2FsIGhlcmU/IChvdGhlciAKPiB0aGFuIGFuIGF0dGVtcHQgdG8ga2VlcCB0aGUgc2VjIEFEcyBm cm9tIGJlaW5nIGFubm95aW5nIGFuZCB0cnlpbmcgdG8KPiBpbnNpc3Qgb24gQkNQMTA3PyA7LSkK PiAKPiAoZGlzY3VzczExKSAtIFNFQy1SRVEtMDk6IFNlcGFyYXRlbHksIHRvIG15IG90aGVyIHdv dWxkLWJlLWRpc2N1c3MKPiBwb2ludCBvbiB0aGlzIHJlcXVpcmVtZW50LCAiY2FuIGd1YXJhbnRl ZSIgaXMgd2VsbCBiZXlvbmQgdGhlIHN0YXRlCj4gb2YgdGhlIGFydCBpbiBrZXkgbWFuYWdlbWVu dC4gSSdkIGp1c3QgZHJvcCB0aGF0IHNlbnRlbmNlIG1heWJlLCBidXQgCj4gY2FuJ3QgbWFrZSBh IGNvbmNyZXRlIHN1Z2dlc3Rpb24gdW50aWwgSSB1bmRlcnN0YW5kIHdoZXJlIHlvdSB3YW50IHRv Cj4gYmUgd3J0IEJDUDEwNy4KPiAKPiAtIFNFQy1SRVEtMTA6IHRoZSBsYXN0IHNlbnRlbmNlIGhl cmUgaXMgYWxzbyBpbnZvbHZlZCBpbiB0aGUgIm1heSBkbwo+IHN0dWZmIGluc2VjdXJlbHkiIHRo aW5nLCBhbmQgc28gd2lsbCBsaWtlbHkgbmVlZCBmaXhpbmcgd2hlbiB0aGF0IGlzCj4gZnVsbHkg cmVzb2x2ZWQuCj4gCj4gLSBIb3cgaXMgU0VDLVJFUS0xMSB1c2VmdWw/IFdoYXQgcHJvdG9jb2wg YXJ0ZWZhY3RzIGRvIHlvdSBoYXZlIGluCj4gbWluZCBoZXJlPyBQZXJoYXBzIGEgcmVxdWlyZW1l bnQgdGhhdCBERG9TIGF0dGFja3MgYmUgc3BlY2lmaWNhbGx5Cj4gY29uc2lkZXJlZCBpbiBJMlJT IHdvdWxkIGJlIG1vcmUgdXNlZnVsLgo+IAo+IC0gU0VDLVJFUS0xMjogVGhpcyBzZWVtcyB0byBt ZSB0byBoYXZlIHRvbyBtYW55IHdvcmRzLCBlLmcuIHRoZQo+IGN1cnJlbnQgdGV4dCBjb3VsZCBi ZSByZWFkIHRvIGltcGx5IHRoYXQgb3V0c2lkZSBvZiBjcml0aWNhbAo+IGluZnJhc3RydWN0dXJl IHRoZXJlIGlzIGxlc3Mgb3Igbm8gbmVlZCBmb3IgY29uZmlkZW50aWFsaXR5LCBzbyB0aG9zZQo+ IGFkZGVkIHdvcmRzIChwcmVzdW1hYmx5IHRoZXJlIHRvIG1vdGl2YXRlKSBtaWdodCBiZSAKPiBj b3VudGVyLXByb2R1Y3RpdmUuCj4gCj4gKGRpc2N1c3MxMikgU0VDLVJFUS0xMjogSSBkb24ndCBn ZXQgdGhlIG1lYW5pbmcgb2YgdGhlIFNIT1VMRCBoZXJlIC0KPiBjb21iaW5lZCB3aXRoICJjZXJ0 YWluIGRhdGEiIHRoYXQgU0hPVUxEIHNlZW1zIHRvIGVuZCB1cCBtZWFuaW5nIE1BWSwKPiBhcyBp biwgaXQgc2VlbXMgdG8gbWVhbiB0aGUgc2FtZSBhcyAiUmVhZC93cml0ZSBvcGVyYXRpb25zIE1B WSBoYXZlCj4gdG8gYmUgcHJvdGVjdGVkIHVzaW5nIGEgY29uZmlkZW50aWFsaXR5IHNlcnZpY2Uu Igo+IAo+IC0gMy40LCBidWxsZXQgKDIpIGhlcmUgbWVhbnMgdGhhdCB3ZSdyZSBub3QgdGFsa2lu ZyBhYm91dCBkYXRhCj4gaW50ZWdyaXR5IGJ1dCBkYXRhIG9yaWdpbiBhdXRoZW50aWNhdGlvbiBh cyB3ZWxsLgo+IAo+IChkaXNjdXNzMTMpIDMuNCwgKDMpOiBXaXRoaW4gd2hhdCBzY29wZSBtdXN0 IHJlcGxheSBiZSBkZXRlY3RlZD8gVGhlCj4gdGV4dCBpbXBsaWVzIGZvciBldmVyLCB3aGljaCBj YW4gYmUgdmVyeSBvbmVyb3VzLiBTRUMtUkVRLTE0IGRvZXNuJ3QKPiBxdWl0ZSBnbyBzbyBmYXIs IGJ1dCBpcyBhbWJpZ3VvdXMgb24gdGhpcyBhc3BlY3QuIEknZCBzYXkgYmVzdCBpcyB0bwo+IG5v dGUgdGhhdCB0aGUgc2NvcGUgd2l0aGluIHdoaWNoIHJlcGxheSBuZWVkcyB0byBiZSBkZXRlY3Rh YmxlIGlzIGZvcgo+IGZ1dHVyZSBzdHVkeS4KPiAKPiAoZGlzY3VzczE0KSBTRUMtUkVRLTE1OiBT b3JyeSwgSSBkb24ndCB1bmRlcnN0YW5kIHdoYXQncyByZXF1aXJlZAo+IGhlcmUgKGhhdmluZyBy ZWFkIHRoaXMgPjEgdGltZSkuIENhbiB5b3UgZXhwbGFpbj/CoCBJJ20gbm90IHN1cmUgaWYKPiBh bnkgc3Vic3RhbnRpdmUgY2hhbmdlIGlzIG5lZWRlZCwgYnV0IHRoZXJlIGFyZSBjZXJ0YWlubHkg ZWRpdG9yaWFsCj4gY2hhbmdlcyBuZWVkZWQgZm9yIHN1cmUgYXMgdGhlcmUgYXJlIG11bHRpcGxl IHdvcmRpbmcgcHJvYmxlbXMgd2l0aAo+IHRoZSB0ZXh0IGFzLWlzLgo+IAo+IC0gMy41LCAxc3Qg cGFyYTogdGhlIHRleHQgaGVyZSBpcyBub3QgYXMgZ29vZCBhcyB0aGUgYWN0dWFsCj4gZGVmaW5p dGlvbiBvZiAicm9sZSIgaW4gUkZDNzkyMSwgYW5kIGluIGZhY3QgSSBmb3VuZCB0aGUgdGV4dCBo ZXJlCj4gY29uZnVzaW5nLiBCZXR0ZXIgdG8ganVzdCBkZWxldGUgdGhhdCBhbmQgc2F5IHRoYXQg NzkyMSBkZWZpbmVzCj4gcm9sZXMuCj4gCj4gKGRpc2N1c3MxNSkgU0VDLVJFUS0xNjogSSBkb24n dCBzZWUgYW55IGNvbnRlbnQgaW4gdGhpcyB0ZXh0IGFzIGl0Cj4gc2VlbXMgdG8ganVzdCBzYXkg InNvbWUgcm9sZSBiYXNlZCBhY2Nlc3MgY29udHJvbCBhbmQgc29tZSBsZXZlbCBvZgo+IHRyYW5z cG9ydCBwcm90ZWN0aW9uIG5lZWQgdG8gYmUgcHJvdmlkZWQiIHdoaWNoIGlzIGFsd2F5cyB0cnVl LCBhcwo+IHlvdSBhcmUgYWxsb3dpbmcgIm5vIHRyYW5zcG9ydCBzZWN1cml0eSIgYW5kIChJIGFz c3VtZSkgImZ1bGx5Cj4gcHVibGljIGFjY2VzcyIgc28gYW55IHByb3RvY29sL3N5c3RlbSB3aWxs IGFsd2F5cyBtZWV0IHRoaXMgCj4gcmVxdWlyZW1lbnQuCj4gCj4gLSBTRUMtUkVRLTE2OiAicHJp dmFjeSByZXF1aXJlbWVudHMiIGhlcmUgaXMgd3JvbmcsIHlvdSBtZWFuCj4gY29uZmlkZW50aWFs aXR5IEkgdGhpbmsuCj4gCj4gKGRpc2N1c3MxNikgU0VDLVJFUS0xNzogIk1VU1Qgd29yayIgaXMg ZmFyIHRvbyB2YWd1ZS4gVGhhdCBjb3VsZCBmb3IKPiBleGFtcGxlIGhpZGUgYSBtYWpvciBkZWJh dGUgYWJvdXQgcHVzaCB2LiBwdWxsIG9mIHJvbGUgaW5mb3JtYXRpb24uCj4gSWYgdGhlIFdHIGhh dmVuJ3QgY29uc2lkZXJlZCB0aGF0LCBJIHRoaW5rIHlvdSBjb3VsZCBhY2sgdGhhdCBhZ2Fpbgo+ IGJ5IHNheWluZyB0aGF0IG1vcmUgd29yayBpcyBuZWVkZWQgdG8gZGVmaW5lIGhvdyBSQkFDIGlz IGNvbnNpc3RlbnQKPiBhY3Jvc3MgbXVsdGlwbGUgdHJhbnNwb3J0IGxheWVyIGNvbm5lY3Rpb25z Lgo+IAo+IChkaXNjdXNzMTcpIFNFQy1SRVEtMTg6IGFnYWluIHRoaXMgc2VlbXMgdG8gaGF2ZSBu byBjb250ZW50LCBvdGhlcgo+IHRoYW4gcGVyaGFwcyBpbXBvc2luZyBhbiBvZGQgcmVxdWlyZW1l bnQgb24gaW1wbGVtZW50YXRpb25zIC0gSSBkb24ndAo+IHNlZSBhIHByb3RvY29sIHJlcXVpcmVt ZW50IGhlcmUgYXQgYWxsLiBJdCBpcyByZWFzb25hYmxlIHRvIG5vdGUgdGhhdAo+IGxpYnJhcmll cyBmb3IgY2xpZW50cyBvdWdodCBub3QgYXNzdW1lIGEgc2luZ2xlIGNsaWVudCBpZGVudGl0eSBi dXQKPiBldmVuIHRoYXQncyB2ZXJ5IHNwZWNpZmljIHRvIGxpYnJhcnkgaW1wbGVtZW50YXRpb25z IGFuZCBzaW5jZSBpdCdzCj4ganVzdCBhIE1BWSB0aGF0J3MgZW50aXJlbHkgb2J2aW91cywgSSdk IGxlYXZlIGl0IG91dC4KPiAKPiAoZGlzY3VzczE4KSBTRUMtUkVRLTE5OiBJIGZ1bGx5IGFncmVl IHdpdGggdGhlIG1vdGl2YXRpb24gaGVyZSBidXQgSQo+IHRoaW5rIHRoZSBzdGF0ZWQgcmVxdWly ZW1lbnQgaXMgYnJva2VuLsKgIEZvciBleGFtcGxlLCBJIGRvbid0IGtub3cKPiBob3cgYSBwaWVj ZSBvZiBzL3cgd2lsbCBkZXRlcm1pbmUgd2hldGhlciBvciBub3QgaXQgaXMgY29ycmVsYXRlZAo+ IHdpdGggYSBwZXJzb24uIEkgYWxzbyBkb24ndCB0aGluayBhIFNIT1VMRCB3b3JrcyBoZXJlLCBh cyBhZ2Fpbgo+IHNvbWV0aGluZyB3b3VsZCBuZWVkIHRvIGJlIHN0YXRlZCBhYm91dCB0aGUgc2l0 dWF0aW9ucyB3aGVuIHRoZQo+IGZlYXR1cmUgaXMgbm90IG5lZWRlZCwgYW5kIEkgY2FuJ3QgZmln dXJlIG91dCBhIHNlbnNpYmxlIHN0YXRlbWVudAo+IGZvciB0aGF0LiBUaGUgbGFzdCBzZW50ZW5j ZSBhbHNvIHNlZW1zIGxpa2VseSBub3QgdXNlZnVsLiBBbGwgaW4gYWxsLAo+IEkgdGhpbmsgdGhp cyBpcyBsaWtlbHkgdG8gYmUgaWdub3JlZCBvciBldmVuIHdvcnNlIHRyZWF0ZWQgbGlrZSBhCj4g cGllY2Ugb2YgZmlnLWxlYWYgc3BlY2lmaWNhdGlvbiB0ZXh0IHRvIHByZXRlbmQgdGhhdCB3ZSdy ZSBjYXJpbmcKPiBhYm91dCBwcml2YWN5Lgo+IAo+IChkaXNjdXNzMTkpIC0gMy42OiBJIGhhdmUg bm8gaWRlYSB3aGV0aGVyIHRoaXMgb3RoZXIgZHJhZnQgaXMKPiBzdXBwb3NlZCB0byBiZSBjb25z aWRlcmVkIGFzIHNldHRpbmcgcmVxdWlyZW1lbnRzIG9yIG5vdC4gSSBhc3N1bWUKPiB0aGF0IHRo ZSBhbnN3ZXIgaXMgIm5vdCIgYXMgeW91J3ZlIG1hZGUgaXQgYW4gaW5mb3JtYXRpdmUgcmVmZXJl bmNlLAo+IGJ1dCBpbiB0aGF0IGNhc2UgeW91IHJlYWxseSBzaG91bGQgc2F5IHRoYXQuwqAgVGhl IGFsdGVybmF0aXZlIHdvdWxkIAo+IGJlIHRoYXQgMy42IGlzIGVzc2VudGlhbGx5IHNwZWNpZnlp bmcgYW4gYXBwbGljYWJpbGl0eSBzdGF0ZW1lbnQgZm9yCj4gdGhlIGVudmlyb25tZW50cyBpbiB3 aGljaCBpdCBpcywgYW5kIGlzIG5vdCwgb2sgdG8gcnVuIGkycnMuIElmIHRoZQo+IGxhdHRlciB3 ZXJlIGludGVuZGVkLCB0aGVuIHlvdSdkIG5lZWQgdG8gc2F5IGl0IGFuZCBtYWtlIHRoZSBkcmFm dCBhCj4gbm9ybWF0aXZlIHJlZmVyZW5jZS4KPiAKPiAKPiBfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXyBpMnJzIG1haWxpbmcgbGlzdCAKPiBpMnJzQGlldGYu b3JnIGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaTJycwo+IAoK ----_com.samsung.android.email_200817715012930 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 PGh0bWw+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0 L2h0bWw7IGNoYXJzZXQ9VVRGLTgiPjwvaGVhZD48Ym9keT48ZGl2PlN0ZXBoZW46Jm5ic3A7PC9k aXY+PGRpdj48YnI+PC9kaXY+PGRpdj5UaGFuayB5b3UgZm9yIHRoZSBleHBsYW5hdGlvbnMuICZu YnNwO0l0ZXJhdGl2ZSBlZGl0cyBkbyBpbXBhY3Qgb24gdGhlIHN0eWxlLiAmbmJzcDs8L2Rpdj48 ZGl2Pjxicj48L2Rpdj48ZGl2PiZuYnNwO1doaWxlIHlvdSBkZW5vdGUgdGhlIGNvbmNlcm4gYXMg cGVydmFzaXZlIG1vbml0b3JpbmcsICZuYnNwO2luIG15IG1pbmQgaXQgaXMgYmV0dGVyIHRvIGNv bnNpZGVyIHRoZSBlZmZvcnQgYXMgZW5zdXJpbmcgcGVydmFzaXZlIHByaXZhY3kgZm9yIGluZGl2 aWR1YWxzIGFuZCBncm91cHMgdXRpbGl6aW5nIHRoZSBJbnRlcm5ldC4gJm5ic3A7KEhhdmluZyB3 b3JrZWQgd2l0aCBzdXJ2aXZvcnMgb2YgZG9tZXN0aWMgYWJ1c2UgYW5kIHNleHVhbCBhYnVzZSwg SSBjaGVlciBJRVRGIGVmZm9ydCBvbiBwZXJ2YXNpdmUgbW9uaXRvcmluZy4pPC9kaXY+PGRpdj48 YnI+PC9kaXY+PGRpdj5NeSBmb2N1cyBhbmQgdGhlIHJlYXNvbiBJIGFza2VkIGFib3V0IHRoZSBz ZWN1cml0eSBkaXJlY3RvcmF0ZSByZXZpZXdzIC0gaXMgdGhhdCBpdCBpcyBpbXBvcnRhbnQgdG8g Zml4IHByb2JsZW1zIGVhcmx5IGluIHRoZSBwcm9jZXNzLiAmbmJzcDtXaGVuIEkgY29tZSB0byBh biB1bmV4cGVjdGVkIGZhaWxpbmcgZ3JhZGUgZm9yIGEgZG9jdW1lbnQsICZuYnNwO0kgdHJ5IHRv IGFkZHJlc3MgYm90aCB0aGUgZG9jdW1lbnQgYW5kIHRoZSBwcm9jZXNzIGluIG9yZGVyIHRvIGlt cHJvdmUuICZuYnNwO0kgZXhwZWN0ZWQgdGhlIHByb2Nlc3Mgb2YgZ2V0dGluZyBhIHNlY3VyaXR5 IGRpcmVjdG9yYXRlIHJldmlld3Mgd291bGQgZGV0ZWN0IHByb2JsZW1zIHNvb25lci4gJm5ic3A7 IFNvIEkgYW0gYXNraW5nIHdoYXQgaGFwcGVuZWQgaW4gdGhlIHNlY3VyaXR5IGRpcmVjdG9yYXRl IHJldmlld3MgdGhhdCBjYXVzZWQgdGhlbSB0byBtaXNzIHlvdXIgY29uY2VybnM/ICZuYnNwOyBE aWQgbWlzcyBzb21ldGhpbmcgaW4gdGhlaXIgY29tbWVudHM/PC9kaXY+PGRpdj48YnI+PC9kaXY+ PGRpdj5NeSBuZXh0IHF1ZXN0aW9uIGlzIHdoYXQgZG8geW91IGV4cGVjdCBmcm9tIGEgcHJvdG9j b2wgc2VjdXJpdHkgZG9jdW1lbnQ/ICZuYnNwO0RvIHlvdSBoYXZlIGEgY2hlY2tsaXN0PyAmbmJz cDs8L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2Pk9uIHRoZSBuZXh0IHN0ZXBzLCBJIHJlc3BvbmRl ZCB1cCB0aHJvdWdoIHlvdXIgfmRpc2N1c3MtY3JpdGVyaWEuaHRtbCBjb21tZW50IDUuICZuYnNw O0lmIHlvdSBoYXZlIHRpbWUgdG8gYW5zd2VyICZuYnNwO2p1c3QgbXkgcXVzdGlvbnMgb24gdGhl IDUgZGlzY3VzcyBRcyAtIGl0IHdpbGwgaGVscCBteSBkaXNjdXNzaW9uIHdpdGggQWxpYS4gJm5i c3A7PC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj5TdWU8L2Rpdj48ZGl2PlN1ZTwvZGl2PjxkaXY+ PGJyPjwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXYgaWQ9ImNvbXBvc2VyX3NpZ25hdHVyZSI+PGRp diBzdHlsZT0iZm9udC1zaXplOjg1JTtjb2xvcjojNTc1NzU3IiBkaXI9ImF1dG8iPlNlbnQgdmlh IHRoZSBTYW1zdW5nIEdhbGF4eSBOb3RlNSwgYW4gQVQmYW1wO1QgNEcgTFRFIHNtYXJ0cGhvbmU8 L2Rpdj48L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2IHN0eWxlPSJmb250LXNpemU6MTAwJTtjb2xv cjojMDAwMDAwIj48L2Rpdj48ZGl2IHN0eWxlPSJmb250LXNpemU6MTAwJTtjb2xvcjojMDAwMDAw Ij48IS0tIG9yaWdpbmFsTWVzc2FnZSAtLT48ZGl2Pi0tLS0tLS0tIE9yaWdpbmFsIG1lc3NhZ2Ug LS0tLS0tLS08L2Rpdj48ZGl2PkZyb206IFN0ZXBoZW4gRmFycmVsbCAmbHQ7c3RlcGhlbi5mYXJy ZWxsQGNzLnRjZC5pZSZndDsgPC9kaXY+PGRpdj5EYXRlOiA4LzIxLzE2ICAzOjQxIFBNICAoR01U LTA1OjAwKSA8L2Rpdj48ZGl2PlRvOiBTdXNhbiBIYXJlcyAmbHQ7c2hhcmVzQG5kemguY29tJmd0 OywgVGhlIElFU0cgJmx0O2llc2dAaWV0Zi5vcmcmZ3Q7IDwvZGl2PjxkaXY+Q2M6IGpoYWFzQHBm cmMub3JnLCBpMnJzQGlldGYub3JnLCBpMnJzLWNoYWlyc0BpZXRmLm9yZywgZHJhZnQtaWV0Zi1p MnJzLXByb3RvY29sLXNlY3VyaXR5LXJlcXVpcmVtZW50c0BpZXRmLm9yZyA8L2Rpdj48ZGl2PlN1 YmplY3Q6IFJlOiBbaTJyc10gU3RlcGhlbiBGYXJyZWxsJ3MgQWJzdGFpbiBvbiBkcmFmdC1pZXRm LWkycnMtcHJvdG9jb2wtc2VjdXJpdHktcmVxdWlyZW1lbnRzLTA5OiAod2l0aCBDT01NRU5UKSA8 L2Rpdj48ZGl2Pjxicj48L2Rpdj48L2Rpdj48YnI+SGl5YSw8YnI+PGJyPk9uIDIxLzA4LzE2IDIw OjEwLCBTdXNhbiBIYXJlcyB3cm90ZTo8YnI+Jmd0OyBTdGVwaGVuOiBUaGFuayB5b3UgZm9yIGxl YXZpbmcgeW91ciB2YWNhdGlvbiBlYXJseSB0byBkbyB0aGlzIHJldmlldy48YnI+Jmd0OyBJdCBp cyBvbmUgb2YgdGhlIG1vc3QgbmVnYXRpdmUgdmlld3BvaW50IEkgaGF2ZSByZWFkIGZyb20geW91 LCBhbmQ8YnI+Jmd0OyBzaW5jZSZuYnNwOyBoYXZlIHJlYWQgbWFueSBvZiB5b3VyIERJU0NVU1Mg Y29tbWVudHMgc2luY2UgeW91IGJlY2FtZSBhbiBBRDxicj48YnI+V2VsbCwgSSd2ZSBkb25lIGZh ciBtb3JlIG5lZ2F0aXZlIHJldmlld3MsIGJ1dCB0aGlzIG9uZSBoYXMgYSBsb3Q8YnI+b2Ygc21h bGxlciBuZWdhdGl2ZSBjb21tZW50cy4gTXkgZ3Vlc3MgaXMgcXVpdGUgYSBsb3Qgb2YgdGhhdCBp cyBkb3duPGJyPnRvIGEpIGl0J3MgdmVyeSB2ZXJ5IGhhcmQgdG8gd3JpdGUgcHJvdG9jb2wgcmVx dWlyZW1lbnRzIHRleHQgY3Jpc3BseTxicj5hbmQgYWNjdXJhdGVseSwgYW5kIGIpIHRoYXQga2lu ZCBvZiB0ZXh0IGlzIHZlcnkgdmVyeSBlYXNpbHkgbWVzc2VkIHVwPGJyPndoZW4gZG9pbmcgaXRl cmF0aXZlIGVkaXRzIGluIHJlc3BvbnNlIHRvIHJldmlld3MsIGFuZCBjKSB0aGUgd3JpdGluZzxi cj5pcyByZWFsbHkgbm90IHRoYXQgZ29vZCBpbiB0aGlzIHZlcnNpb24gLSB0byB0aGUgcG9pbnQg d2hlcmUgdGhlPGJyPmFjY3VtdWxhdGlvbiBvZiBuaXRzIGl0c2VsZiBiZWNvbWVzIGEgbm90YWJs ZSBpc3N1ZSwgYW5kIHdoZXJlIGl0J3M8YnI+bGlrZWx5IHBhc3QgdGltZSB0aGF0IGFuIGVkaXRv cmlhbCBwYXNzIHdhcyBkb25lIHRvIGdldCB0aGF0IG91dCBvZiB0aGU8YnI+d2F5Ljxicj48YnI+ Jmd0OyAtIEkgdGhpbmsgdGhpcyBnaXZlcyBtZSB1bmlxdWUgcGVyc3BlY3RpdmUuJm5ic3A7IFRo aXMgaXMgZmFyIGZyb20gdGhlPGJyPiZndDsgZWFybHkgY29tbWVudHMgeW91IHNlbnQgMiB3ZWVr cyBhZ28uPGJyPjxicj5Oby4gSSB3b3VsZCBub3QgaGF2ZSBhc2tlZCBmb3IgYSBkZWZlciBpZiBJ IHRob3VnaHQgdGhlIG9ubHkgY29uY2Vybjxicj53YXMgdGhlIHBvc3NpYmlsaXR5IG9mIHRoaXMg cmVzdWx0aW5nIGluIGEgaGFyZC10by1kZXBsb3kgc2V0IG9mPGJyPnNlY3VyaXR5IG1lY2hhbmlz bXMgLSBJIHdvdWxkIGhhdmUganVzdCBiYWxsb3RlZCB0aGF0LiBJdCBpcyB0aGUgY2FzZTxicj50 aGF0IHRoYXQncyBhbGwgSSBzYWlkIGJlZm9yZSBJIGhhZCBwcm9wZXJseSByZWFkIHRoZSBkb2N1 bWVudCB0aG91Z2gsPGJyPnllcy4gQW5kIGl0IHdhc24ndCAyIHdlZWtzIGFnbzotKTxicj48YnI+ Jmd0OyBJbiBkZXZlbG9waW5nIHRoaXMgZG9jdW1lbnQgYW5kPGJyPiZndDsgSTJSUyB0ZWNobm9s b2d5IHRoZSBJMlJTIFdHIGFuZCBJIGFzIHRoZSBJMlJTIGNoYWlyIGhhdmUgcmVxdWVzdDxicj4m Z3Q7IHJldmlld3MgZnJvbSB0aGUgU2VjdXJpdHkgZGlyZWN0b3JhdGUuJm5ic3A7IFdlIGRlbGF5 ZWQgb3V0IGZpcnN0PGJyPiZndDsgcmV2aXNpb25zIHRvIHRyeSB0byBhZGRyZXNzIHNlY3VyaXR5 IGlzc3VlIGJ5IGFkZGluZyB0aGlzIGRvY3VtZW50PGJyPiZndDsgYW5kIHRoZSBzZWN1cml0eSBl bnZpcm9ubWVudCBkb2N1bWVudC4mbmJzcDsgV2UgaGF2ZSBoYWQgZWFybHkgYW5kIGxhdGU8YnI+ Jmd0OyByZXZpZXdzLiZuYnNwOyBTaW5jZSB0aGUgaW5pdGlhbCByZXZpZXcgb24gdGhlIEkyUlMg YXJjaGl0ZWN0dXJlIHdlIGhhdmU8YnI+Jmd0OyBkaXNjdXNzZWQgdGhlIG5vbi1zZWN1cmUgaW50 ZXJmYWNlIGFuZCB0cmllZCB0byBnZXQgc2VjdXJpdHk8YnI+Jmd0OyBkaXJlY3RvcmF0ZSdzIHJl dmlldy48YnI+PGJyPkkgaGF2ZSBsb29rZWQgYmFjayBhdCB0aGUgc2VjZGlyIG1haWxzIG9uIHRo aXMsIHllcy48YnI+PGJyPiZndDsgSSByYWlzZWQgdGhlIHBlcnZhc2l2ZSBwcml2YWN5IGlzc3Vl IGFuZCBhc2tlZDxicj4mZ3Q7IGZvciBpbnB1dCBpbiB5b3VyIHJldmlldy4gPGJyPjxicj5ZZXMu IEFuZCBJIHJlc3BvbmRlZCB3aXRoIHR3byB3b3VsZC1oYXZlLWJlZW4tZGlzY3VzcyBwb2ludHMg cmVsYXRlZDxicj50byBwZXJ2YXNpdmUgbW9uaXRvcmluZy4gKEkgYXNzdW1lIHRoYXQgd2hhdCdz IHlvdSBtZWFuIHdoZW4geW91IHNheTxicj4icGVydmFzaXZlIHByaXZhY3kiIGJ1dCBpZiB5b3Ug bWVhbiBzb21ldGhpbmcgZWxzZSBhYm92ZSwgcGxlYXNlIGRvPGJyPmNsYXJpZnkuKTxicj48YnI+ Jmd0OyBUaGlzIG1ldGEtY29tbWVudCBpcyB0aGF0IHByb2Nlc3Mgb2YgYXNraW5nPGJyPiZndDsg Zm9yIGFpZCBhaGVhZCBvZiB0aGlzIHBvaW50IGhhcyBmYWlsZWQgYWNjb3JkaW5nIHRvIHlvdXIg cmV2aWV3LCA8YnI+PGJyPkkgdGhpbmsgdGhhdCdzIGFuIG9kZCB2aWV3IG9mIElFVEYgcHJvY2Vz c2VzLCB3aGljaCBhcmUgbmV2ZXIgZXhwZWN0ZWQ8YnI+dG8gcHJvZHVjZSBwZXJmZWN0aW9uIGF0 IGFueSBzdGFnZS4gSU1PIHdlJ3JlIGl0ZXJhdGluZyB0b3dhcmRzIGJldHRlcjxicj5vdXRjb21l cywgbm90IGZhaWxpbmcvc3VjY2VlZGluZyBhdCBlYWNoIHN0YWdlIG9mIHRoZSBwcm9jZXNzLjxi cj48YnI+Jmd0OyBidXQ8YnI+Jmd0OyBJIGNhbm5vdCBmaW5kIGEgcG9pbnQgd2hlcmUgdGhlIEky UlMgV0cgZGlkIG5vdCBzb2xpY2l0IHRoZSBzZWN1cml0eTxicj4mZ3Q7IGFyZWEncyBhaWQgYW5k IHRha2UgaXRzIGFkdmljZS4mbmJzcDsgVGhlcmVmb3JlLCZuYnNwOyBJIG11c3QgYXNrIHlvdSB0 byBjaGVjazxicj4mZ3Q7IHRoZSBwcm9jZXNzIG9mIHlvdXIgc2VjdXJpdHkgZGlyZWN0b3JhdGUn cyByZXZpZXdzIHRvIGZpbmQgd2hhdDxicj4mZ3Q7IGhhcHBlbmVkIHRvIGNhdXNlIHN1Y2ggYSBm YWlsdXJlLiA8YnI+PGJyPkRvbid0IHRoaW5rIG9mIGl0IGFzIGZhaWx1cmUsIHRoaW5rIG9mIGl0 IGFzIG1vcmUgZXllYmFsbHMgZmluZGluZyBtb3JlPGJyPnRoaW5ncy4gKE9yIHJlcGVhdGluZyB0 aGluZ3MgYWxyZWFkeSBjb25zaWRlcmVkLCBmb3IgdGhvc2Ugd2hlcmUgdGhhdCdzPGJyPnRoZSBj YXNlLik8YnI+PGJyPiZndDsgTm93IGFzIHRvIHRoZSBkb2N1bWVudCwgSSBoYXZlIGEgV0c8YnI+ Jmd0OyB3YWl0aW5nIGZvciB0aGVzZSByZXF1aXJlbWVudHMuJm5ic3A7IDxicj48YnI+SSdkIGVu Y291cmFnZSB5b3UgdG8gcXVlc3Rpb24gdGhlIGFib3ZlLCBhcyBhIGZpcnN0IG9yZGVyIGdvYWwu IEFyZTxicj50aGUgV0cgcmVhbGx5IHdhaXRpbmcgb24gdGhlc2UgaW4gYSBmaW5hbCwgZml4ZWQt Zm9yZXZlciwgZm9ybT8gT3I8YnI+ZG8geW91IG5lZWQgYSBnZW5lcmFsIGFncmVlbWVudCBhcyB0 byBkaXJlY3Rpb24gYW5kIGNhbiB0aGVuIG1ha2U8YnI+cHJvZ3Jlc3M/IChBbmQgcGVyaGFwcyBy ZWR1Y2UgdGhlIGZpbmFsIHJlcXVpcmVtZW50cyB0byBSRkMgc3RhdHVzPGJyPmxhdGVyIGlmIHRo ZXJlJ3MgdmFsdWUgaW4gdGhhdCwgd2hpY2ggdGhlcmUgY2FuIGJlLik8YnI+PGJyPkFzIEkgbm90 ZWQgYSBjb3VwbGUgb2YgdGltZXMgaW4gbXkgcmV2aWV3LCBpdCdzIG5vdCBwb3NzaWJsZSB0byBi ZTxicj50aGF0IHByZWNpc2UgYWJvdXQgc29tZSByZXF1aXJlbWVudHMgd2l0aG91dCBoYXZpbmcg ZG9uZSBtb3JlIG9mIHRoZTxicj5kZXNpZ24uIChPbmUgb2YgdGhlIHRyYWRpdGlvbmFsIHdhdGVy ZmFsbGwgZGVzaWduIHByb2JsZW1zIEkgZ3Vlc3MuKTxicj5UaGUgc2NvcGUgb2YgcmVwbGF5IGRl dGVjdGlvbiBpcyBwcm9iYWJseSBhIGdvb2QgZXhhbXBsZS48YnI+PGJyPiZndDsgSSB3b3VsZCBs aWtlIHRvIGhlYXIgaW4gYSBjb21wbGV0ZWx5PGJyPiZndDsgc2VwYXJhdGUgZW1haWwgdGhyZWFk IHdoYXQga2VybmVsIG9mIGluZm9ybWF0aW9uIHlvdSB3b3VsZCBoYXZlPGJyPiZndDsgZXhwZWN0 ZWQgcmVnYXJkaW5nIHRoZSBzZWN1cml0eSBmaXJzdCBhbiBpMnJzIHByb3RvY29sLiZuYnNwOyA8 YnI+PGJyPkkgZG9uJ3QgdW5kZXJzdGFuZCB5b3VyIHF1ZXN0aW9uIHNvcnJ5Ljxicj48YnI+Jmd0 OyBJIHdvdWxkIHRoZW48YnI+Jmd0OyBsaWtlIHRvIGNvbXBhcmUgdGhpcyBhZ2FpbnN0IHRoZSBz ZWN1cml0eSBkaXJlY3RvcmF0ZSdzIHN1Z2dlc3Rpb25zPGJyPiZndDsgb24gdGhpcyBkb2N1bWVu dC4mbmJzcDsgV2UgaGF2ZSBhIHNlY29uZCBkb2N1bWVudCBvbiB0aGUgc2VjdXJpdHk8YnI+Jmd0 OyBlbnZpcm9ubWVudCBzbyB5b3VyIGluc2lnaHRzIHdpbGwgYmUgYXBwbGllZCB0byB0aGF0IGRv Y3VtZW50LiBTaW5jZTxicj4mZ3Q7IGluIHRoZSBnZW5lcmFsIHRleHQgeW91IGluZGljYXRlIHRo ZSBzdHlsZSBpcyB0ZXJyaWJsZSBhbmQgbmVlZHMgdG88YnI+Jmd0OyBiZSB3cml0dGVuLCBwbGVh c2UgcHJvdmlkZSBhbiBleGFtcGxlIG9mIGEgZG9jdW1lbnQgYXMgYW4gZXhhbXBsZSBvZjxicj4m Z3Q7IHRoZSBzdHlsZS4mbmJzcDsgPGJyPjxicj5SZWFsbHk/IFRoZSBhY2N1bXVsYXRpb24gb2Yg YmFkbHkgd3JpdHRlbiBzZW50ZW5jZXMgaW4gLTA5IGhhcyBnb3Q8YnI+dG8gYmUgYSBjbGVhciBl bm91Z2ggcHJvYmxlbSB0aGF0IHlvdSBkb24ndCBuZWVkIGFuIGV4YW1wbGUgb2Ygd2hhdDxicj5p cyBub3QtdGhhdC4gU28gSSdtIHB1enpsZWQgYXQgdGhlIHJlcXVlc3QuPGJyPjxicj4mZ3Q7IE15 IHVuZGVyc3RhbmRpbmcgaXMgdGhhdCBzdHlsZSBpcyBhIGxvd2VyIHByaW9yaXR5IHRoYW48YnI+ Jmd0OyB0ZWNobmljYWwgY29ycmVjdG5lc3MgYW5kIGNvbnNlbnN1cy4gPGJyPjxicj5Db3JyZWN0 L2dvb2QtZW5vdWdoIHdyaXRpbmcgaXMgY2VydGFpbmx5IHNlY29uZGFyeSwgdXAgdW50aWwgdGhl PGJyPmlzc3VlcyBnZXQgdG8gYSBjZXJ0YWluIHBvaW50IHRoYXQgaW1waW5nZXMgb24gdGhlIHJl YWRlcidzIGFiaWxpdHk8YnI+dG8gYXNzZXMgdGhlIG1lYW5pbmcsIGFuZCB0aGF0IGhhcHBlbnMg YSBjb3VwbGUgb2YgdGltZXMgaW4gdGhpczxicj5kb2N1bWVudC4gKEFzIEkgc2FpZCBpbiBteSBy ZXZpZXcuKSBUaGUgb3RoZXIgd3JpdGluZyBpc3N1ZXMgbWFrZTxicj50aGlzIGEgaGFyZGVyIHJl YWQgdGhhbiBvdWdodCBiZSB0aGUgY2FzZS4gVGhhdCBkb2Vzbid0IHJlYWNoIHRoZTxicj5sZXZl bCBvZiBtYWtpbmcgdGhlIGRvY3VtZW50IHVucmVhZGFibGUsIG5vciBuZWFybHkgZ2V0IHRoYXQg YmFkLDxicj5idXQgaXQgaXMgZW5vdWdoIHRoYXQgSSB3b25kZXIgaWYgb3RoZXIgcmVhZGVycyBt YXkgaGF2ZSBiZWVuIHB1dDxicj5vZmYgYnkgdGhhdCBpbiByZWFkaW5nIHNvbWUgb2YgdGhlIHRl eHQuPGJyPjxicj4mZ3Q7IFRoaXMgZW1haWwgZW5kcyBteSBjb21tZW50cyBvbjxicj4mZ3Q7IHlv dXIgc3VtbWFyeSBtZXNzYWdlLiZuYnNwOyBUaGUgbmV4dCBzZXQgb2YgY29tbWVudHMgd2lsbCB0 YWtlIHlvdXI8YnI+Jmd0OyBkaXNjdXNzIGNvbW1lbnRzIG9uZSBhdCBhIHRpbWUuIFRoZSBleGFj dCBuZXh0IHN0ZXBzIHRoYXQgSSBhbmQgbXk8YnI+Jmd0OyBjby1hdXRob3Igd2lsbCB0YWtlIHdp bGwgYmUgZ3VpZGVkIGJ5IHRoZSBBRCByZXNwb25zaWJsZSBmb3IgdGhlIEkyUlM8YnI+Jmd0OyBX RywgPGJyPjxicj5UaGF0J3MgYWxsIGdvb2QuPGJyPjxicj5JIHdvdWxkIHJlLWl0ZXJhdGUgdGhv dWdoLCB0aGF0IHNpbmNlIG15IGJhbGxvdCBpcyBhbiBhYnN0YWluIHRoZXJlJ3M8YnI+bm8gb251 cyBvbiB5b3Ugb3IgdGhlIFdHIHRvIHJlc3BvbmQgaW4gYW55IG1vcmUgZGV0YWlsIHRoYW4geW91 IGZlZWw8YnI+aXMgdXNlZnVsLjxicj48YnI+Q2hlZXJzLDxicj5TLjxicj48YnI+Jmd0OyBBbGlh LiBDaGVlcmlseSwmbmJzcDsgU3VlIEhhcmVzPGJyPiZndDsgPGJyPiZndDsgU2VudCB2aWEgdGhl IFNhbXN1bmcgR2FsYXh5IE5vdGU1LCBhbiBBVCZhbXA7VCA0RyBMVEUgc21hcnRwaG9uZSAtLS0t LS0tLTxicj4mZ3Q7IE9yaWdpbmFsIG1lc3NhZ2UgLS0tLS0tLS1Gcm9tOiBTdGVwaGVuIEZhcnJl bGw8YnI+Jmd0OyAmbHQ7c3RlcGhlbi5mYXJyZWxsQGNzLnRjZC5pZSZndDsgRGF0ZTogOC8yMS8x NiZuYnNwOyA4OjM3IEFNJm5ic3A7IChHTVQtMDU6MDApIFRvOjxicj4mZ3Q7IFRoZSBJRVNHICZs dDtpZXNnQGlldGYub3JnJmd0OyBDYzogamhhYXNAcGZyYy5vcmcsIGkycnNAaWV0Zi5vcmcsPGJy PiZndDsgaTJycy1jaGFpcnNAaWV0Zi5vcmcsPGJyPiZndDsgZHJhZnQtaWV0Zi1pMnJzLXByb3Rv Y29sLXNlY3VyaXR5LXJlcXVpcmVtZW50c0BpZXRmLm9yZyBTdWJqZWN0Ojxicj4mZ3Q7IFtpMnJz XSBTdGVwaGVuIEZhcnJlbGwncyBBYnN0YWluIG9uIDxicj4mZ3Q7IGRyYWZ0LWlldGYtaTJycy1w cm90b2NvbC1zZWN1cml0eS1yZXF1aXJlbWVudHMtMDk6ICh3aXRoIENPTU1FTlQpIDxicj4mZ3Q7 IFN0ZXBoZW4gRmFycmVsbCBoYXMgZW50ZXJlZCB0aGUgZm9sbG93aW5nIGJhbGxvdCBwb3NpdGlv biBmb3IgPGJyPiZndDsgZHJhZnQtaWV0Zi1pMnJzLXByb3RvY29sLXNlY3VyaXR5LXJlcXVpcmVt ZW50cy0wOTogQWJzdGFpbjxicj4mZ3Q7IDxicj4mZ3Q7IFdoZW4gcmVzcG9uZGluZywgcGxlYXNl IGtlZXAgdGhlIHN1YmplY3QgbGluZSBpbnRhY3QgYW5kIHJlcGx5IHRvPGJyPiZndDsgYWxsIGVt YWlsIGFkZHJlc3NlcyBpbmNsdWRlZCBpbiB0aGUgVG8gYW5kIENDIGxpbmVzLiAoRmVlbCBmcmVl IHRvPGJyPiZndDsgY3V0IHRoaXMgaW50cm9kdWN0b3J5IHBhcmFncmFwaCwgaG93ZXZlci4pPGJy PiZndDsgPGJyPiZndDsgPGJyPiZndDsgUGxlYXNlIHJlZmVyIHRvPGJyPiZndDsgaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvaWVzZy9zdGF0ZW1lbnQvZGlzY3Vzcy1jcml0ZXJpYS5odG1sIGZvciBtb3Jl PGJyPiZndDsgaW5mb3JtYXRpb24gYWJvdXQgSUVTRyBESVNDVVNTIGFuZCBDT01NRU5UIHBvc2l0 aW9ucy48YnI+Jmd0OyA8YnI+Jmd0OyA8YnI+Jmd0OyBUaGUgZG9jdW1lbnQsIGFsb25nIHdpdGgg b3RoZXIgYmFsbG90IHBvc2l0aW9ucywgY2FuIGJlIGZvdW5kIGhlcmU6IDxicj4mZ3Q7IGh0dHBz Oi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtaTJycy1wcm90b2NvbC1zZWN1 cml0eS1yZXF1aXJlbWVudHMvPGJyPiZndDs8YnI+Jmd0OyA8YnI+Jmd0OyA8YnI+Jmd0OyA8YnI+ Jmd0OyAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tPGJyPiZndDs8YnI+Jmd0OyA8YnI+Q09NTUVOVDo8YnI+Jmd0OyAt LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tPGJyPiZndDs8YnI+Jmd0OyA8YnI+Jmd0OyA8YnI+Jmd0OyBGaXJzdCwgYXBv bG9naWVzIGZvciBub3QgZ2V0dGluZyBteSByZXZpZXcgZG9uZSBmb3IgdGhpcyB3aGVuIGl0IHdh czxicj4mZ3Q7IHNjaGVkdWxlZCBkdWUgdG8gbXkgdmFjYXRpb24gYW5kIHRoYW5rcyBmb3IgYmVp bmcgd2lsbGluZyB0byBkZWZlcjxicj4mZ3Q7IHRoZSBkb2N1bWVudC48YnI+Jmd0OyA8YnI+Jmd0 OyBTZWNvbmQsIGhhdmluZyBub3cgcHJvcGVybHkgcmV2aWV3ZWQgdGhpcywgSSBhbSBiYWxsb3Rp bmcgYWJzdGFpbiBhczxicj4mZ3Q7IEkgdGhpbmsgaXQncyB1bmxpa2VseSB0aGF0IHRoaXMgZG9j dW1lbnQgY2FuIGJlIGZpeGVkIGluIGEgd2F5IHRoYXQ8YnI+Jmd0OyByZXN1bHRzIGluIHNvbWV0 aGluZyB1c2VmdWwgaGFwcGVuaW5nLiBJIHRoaW5rIHRoYXQgdGhlIGxpa2VseSA8YnI+Jmd0OyBv dXRjb21lIGlzIHRoYXQgdGhpcyBkb2N1bWVudCB3aWxsIGJlIHVzZWQgbGF0ZXIgd2hlbiBwZW9w bGUgYXJlPGJyPiZndDsgYXJndWluZyBhbmQgd2lsbCBub3QgbXVjaCBoZWxwIGluIHJlc29sdmlu ZyB0aG9zZSBhcmd1bWVudHMsIG9yIGVsc2U8YnI+Jmd0OyB0aGlzIHdpbGwgYmUgaWdub3JlZCBh bmQgYXJndW1lbnRzIHdpbGwgYmUgaGVsZCBhZnJlc2gsIGFzIG5lZWRlZC48YnI+Jmd0OyBUaGF0 IGxhdHRlciBvdXRjb21lIGlzIHdoYXQgSSdkIGd1ZXNzIGlzIG1vc3QgbGlrZWx5IGFuZCB0aGVy ZWZvcmUgaXQ8YnI+Jmd0OyBzZWVtcyB0aGF0IHNwZW5kaW5nIGFsbCBvZiBvdXIgY3ljbGVzIG9u IERJU0NVU1MgYmFsbG90IHByb2Nlc3Npbmc8YnI+Jmd0OyBmb3IgdGhpcyB3b3VsZCBub3QgYmUg d2lzZS4gVGhhdCBzYWlkLCBJIGFtIHdpbGxpbmcgdG8gY2hhbmdlIHRvIGE8YnI+Jmd0OyBESVND VVNTIGJhbGxvdCBpZiB0aGUgcmVzcG9uc2libGUgQUQgcHJlZmVycyB0aGF0LCBidXQgSSBzdXNw ZWN0IEknbGw8YnI+Jmd0OyBlbmQgdXAgd2l0aCBhbiBhYnN0YWluIGluIGFueSBjYXNlLCBhZnRl ciBzb21lIGRpc2N1c3Npb24uIFRoZSBvbmx5PGJyPiZndDsgcGxhbiBJIGNhbiB0aGluayBvZiB0 aGF0J2QgbGVhZCB0byBtZSBlbmRpbmcgdXAgd2l0aCBhIHllcyBvcjxicj4mZ3Q7IG5vLW9iamVj dGlvbiBiYWxsb3Qgd291bGQgYmUgaWYgdGhpcyB3YXMgcmV0dXJuZWQgdG8gdGhlIFdHIGZvcjxi cj4mZ3Q7IGZpeGluZyBhbmQgcG9zc2libHkgbWFqb3Igc3VyZ2VyeSwgd2hpY2ggaXMgd2hhdCBJ IGFjdHVhbGx5IHRoaW5rPGJyPiZndDsgd291bGQgYmUgdGhlIGJlc3QgcGxhbi4gKEkgcmVhbGlz ZSB0aGlzIGhhcyBoYWQgYSBzb21ld2hhdCB0b3J0dXJlZCA8YnI+Jmd0OyBoaXN0b3J5LCBzbyBm b2xrcyBtYXkgbm90IGJlIHdpbGxpbmcgdG8gdGFrZSBpdCBiYWNrIHRvIHRoZSBXRywgYnV0PGJy PiZndDsgaG9uZXN0bHksIEkgdGhpbmsgdGhlIGZhaWxpbmdzIHZpc2libGUgaW4gdGhpcyBkb2N1 bWVudCBkbyBpbmRpY2F0ZTxicj4mZ3Q7IHRoYXQgdGhpcyBpcyBub3QgcmVhZHkgZm9yIGFwcHJv dmFsIGFuZCBvdWdodCBiZSByZXR1cm5lZCB0byB0aGU8YnI+Jmd0OyBXRy4pPGJyPiZndDsgPGJy PiZndDsgVGhpcmQsIEkgdGhpbmsgdGhlIG92ZXJhbGwgc2V0IG9mIHJlcXVpcmVtZW50cyBwb3Nl ZCBoZXJlIG1pZ2h0ICh3aXRoPGJyPiZndDsgc29tZSB1bmtub3duIHByb2JhYmlsaXR5KSBsZWFk IHRvIGxhdGVyIHNwZWNpZmljYXRpb25zIHRoYXQgYXJlPGJyPiZndDsgY29uc2lkZXJlZCB0b28g aGFyZCB0byBkZXBsb3ksIHdpdGggdGhlIHJlc3VsdCB0aGF0IG5vbi1zZWN1cmU8YnI+Jmd0OyB2 YXJpYW50cyBvZiBJMlJTIGJlY29tZSB0aGUgbm9ybS4gVGhhdCBzZWVtcyBsaWtlIGl0IHdvdWxk IGJlIGEgPGJyPiZndDsgcmVhbGx5IGJhZCBvdXRjb21lLiBJIHdvdWxkIHN1Z2dlc3QgdGhhdCBt aWdodCBiZSBwYXJ0bHkgbWl0aWdhdGVkIGlmPGJyPiZndDsgYSByZXF1aXJlbWVudCB3ZXJlIGFk ZGVkIHRvIHRoZSBlZmZlY3QgdGhhdCBkZXBsb3ltZW50IGlzc3VlcyBhbmQ8YnI+Jmd0OyBzcGVj aWZpY2FsbHkgZWFzZSBvZiBkZXBsb3ltZW50IE1VU1QgYmUgY29uc2lkZXJlZCBhcyBhIGZpcnN0 IG9yZGVyIDxicj4mZ3Q7IHJlcXVpcmVtZW50IHdoZW4gZGV2ZWxvcGluZyBJMlJTIHByb3RvY29s IHNvbHV0aW9ucy48YnI+Jmd0OyA8YnI+Jmd0OyBGb3VydGgsIHRoZSAoMTkhKSBjb21tZW50cyBi ZWxvdyB0aGF0IGFyZSBwcmVjZWRlZCBieSAiKGRpc2N1c3MiPGJyPiZndDsgd291bGQgaGF2ZSBi ZWVuIERJU0NVU1MgYmFsbG90IHBvaW50cyBoYWQgSSBub3QgZGVjaWRlZCB0byBhYnN0YWluLiBJ PGJyPiZndDsgYW0gaGFwcHkgdG8gY2hhdCBhYm91dCBhbnkgb2YgbXkgY29tbWVudHMgYmVsb3cs IGJ1dCBpZiB0aGU8YnI+Jmd0OyBhdXRob3JzL1dHIGRvIHdhbnQgdG8gY2hhdCwgaXQgbWlnaHQg YmUgbW9yZSBlZmZpY2llbnQgdG8gY29uY2VudHJhdGU8YnI+Jmd0OyBvbiB0aG9zZSB0aGF0IHdv dWxkIG90aGVyd2lzZSBoYXZlIGJlZW4gRElTQ1VTUyBwb2ludHMuIChCdXQgdGhhdCdzPGJyPiZn dDsgeW91ciBjYWxsLCBJIGRvbid0IG1pbmQuKSBJIHRoaW5rIHRoZSAxOSB3b3VsZC1oYXZlLWJl ZW4tZGlzY3Vzczxicj4mZ3Q7IHBvaW50cyBpcyBhbm90aGVyIGNsdWUgdGhhdCB0aGlzIG91Z2h0 IHJlYWxseSBiZSBzZW50IGJhY2sgdG8gdGhlPGJyPiZndDsgV0cuPGJyPiZndDsgPGJyPiZndDsg QW5kIHdpdGggdGhhdCwgYW5kIHdpdGggYXBvbG9naWVzIGZvciB0aGlzIGJlaW5nIHN1Y2ggYW4g b3ZlcmFsbDxicj4mZ3Q7IG5lZ2F0aXZlIHJldmlldywgaGVyZSdyZSBteSBkZXRhaWxlZCBjb21t ZW50czo8YnI+Jmd0OyA8YnI+Jmd0OyAtIGdlbmVyYWw6IFRoZSB3cml0aW5nIGhlcmUgaXMgZ2Vu ZXJhbGx5IHBvb3IsIGZvciBleGFtcGxlIHRoZSBvcGVuZXI8YnI+Jmd0OyBpcyAiVGhpcyBwcmVz ZW50cy4uLiIgd2hlcmVhcyBpdCBvdWdodCBiZSAiVGhpcyBkb2N1bWVudCBwcmVzZW50cy4uLiI8 YnI+Jmd0OyAob3Igcy9kb2N1bWVudC93aGF0ZXZlciB5b3UgcHJlZmVyLykuIFN1Y2ggaXNzdWVz IGFyZSByZXBlYXRlZGx5IHNlZW48YnI+Jmd0OyBhbmQgYWxsIHRoYXQgbWFrZXMgdGhpcyBhIG11 Y2ggaGFyZGVyIHJlYWQgdGhhbiBvdWdodCBiZSB0aGUgY2FzZS48YnI+Jmd0OyBJJ2Qgc3Ryb25n bHkgcmVjb21tZW5kIGFuIGVkaXRvcmlhbCBwYXNzIGZyb20gc29tZW9uZSB3aG8gaGFzbid0IGJl ZW48YnI+Jmd0OyBkb3duIGluIHRoZSB3ZWVkcyB3aXRoIHRoaXMgdGV4dCBmb3IgYSB3aGlsZSAo d2hpY2ggY291bGQgYmUgb25lIG9mIDxicj4mZ3Q7IHRoZSBhdXRob3JzLCBpZiBvbmUgb2YgdGhl bSBoYXMgYmVlbiBsZXNzIGFjdGl2ZSByZWNlbnRseS4pIE5vdGUgdGhhdDxicj4mZ3Q7IHRoaXMg aXMgbm90IG9ubHkgKGJ1dCBpcyBwcmltYXJpbHkpIGFuIGVkaXRvcmlhbCBpc3N1ZSAtIHRoZXJl IGFyZTxicj4mZ3Q7IHNvbWUgY2FzZXMgKGhvcGVmdWxseSBjYWxsZWQgb3V0IGJlbG93KSB3aGVy ZSB0aGUgd3JpdGluZyBkb2VzIGNyZWF0ZTxicj4mZ3Q7IHJlYWwgYW1iaWd1aXR5IHRoYXQgbWln aHQgbGVhZCB0byByZS1vcGVuaW5nIG9sZCBhcmd1bWVudHMgbGF0ZXIuPGJyPiZndDsgPGJyPiZn dDsgLSBhYnN0cmFjdDogIm11dHVhbCBhdXRoZW50aWNhdGlvbiwgdHJhbnNwb3J0IHByb3RvY29s cywgZGF0YTxicj4mZ3Q7IHRyYW5zZmVyIGFuZCB0cmFuc2FjdGlvbnMiIGRvbid0IHNlZW0gdG8g bWUgdG8gYmUgY29tbWVuc3VyYXRlPGJyPiZndDsgdGhpbmdzLCBzbyB0aGUgYWJzdHJhY3QsIGFz IHdyaXR0ZW4gaXMgdmVyeSB1bmluZm9ybWF0aXZlIGZvciBtZS48YnI+Jmd0OyA8YnI+Jmd0OyAt IGludHJvIDNyZCBwYXJhOiBJJ20gcmVhbGx5IG5vdCBzdXJlIHdoYXQgeW91J3JlIHRlbGxpbmcg bWUgYWJvdXQ8YnI+Jmd0OyBbSS1ELmlldGYtaTJycy1lcGhlbWVyYWwtc3RhdGVdLiZuYnNwOyAi VGhlIGRyYWZ0IFtSRkM3OTIyXSIgaXMgb2RkLCB0aGF0PGJyPiZndDsgYmVpbmcgbm8gbG9uZ2Vy IGEgZHJhZnQuIEknZCBoYXZlIGV4cGVjdGVkIHN1Y2ggbml0cyB3b3VsZCBoYXZlIGJlZW48YnI+ Jmd0OyBmaXhlZCBieSBub3cgVEJILiBTYW1lIGZvciB0aGUgbGFzdCBzZW50ZW5jZS4mbmJzcDsg VGhhdCBwYXJhIG1ha2VzIHRoZTxicj4mZ3Q7IGludHJvIHByZXR0eSB1bmNsZWFyIGZvciBtZS48 YnI+Jmd0OyA8YnI+Jmd0OyAtIDIuMjogVGhlIGRlZmluaXRpb24gb2YgaGlnaGVyIGxldmVsIHBy b3RvY29sIHNlZW1zIGxpa2UgYW4gb2RkPGJyPiZndDsgcGxhY2UgdG8gaW50cm9kdWNlIHRoZSBm YWN0IHRoYXQgaTJycyA9PSBuZXRjb25mICsgcmVzdGNvbmYuJm5ic3A7IFRoYXQnZDxicj4mZ3Q7 IGJlIG1vcmUgdXNlZnVsbHkgc2FpZCBpbiB0aGUgYWJzdHJhY3QvaW50cm8gaWYgdGhhdCdzIHNv bGlkbHkgYWdyZWVkPGJyPiZndDsgYnkgdGhlIFdHLjxicj4mZ3Q7IDxicj4mZ3Q7IC0gMi4yOiBU aGlzIGlzIHdyb25nOiAiV2hpbGUgaXQgaXMgcG9zc2libGUgdG8gaGF2ZSBhbiBJMlJTIG9wZXJh dGlvbjxicj4mZ3Q7IHdoaWNoIGlzIGNvbnRhaW5lZCBpbiBtdWx0aXBsZSBJMlJTIChFLmcuJm5i c3A7IHdyaXRlIGluIG11bHRpcGxlPGJyPiZndDsgbWVzc2FnZXMpLCB0aGlzIGlzIG5vdCBzdXBw b3J0ZWQgaW4gb3JkZXIgdG8gc2ltcGxpZnkgdGhlIGZpcnN0PGJyPiZndDsgdmVyc2lvbiBvZiBJ MlJTLiIgVGhlIHJlYXNvbiB0aGlzIGlzIHdyb25nLCBpcyB0aGF0IGl0IGlzIGhlcmUgdGhhdDxi cj4mZ3Q7IHlvdSBhcmUgZGVmaW5pbmcgdGhhdCBpdCBpcyBub3QgcG9zc2libGUgdG8gaGF2ZSBh biBvcGVyYXRpb24gaW48YnI+Jmd0OyBtdWx0aXBsZSBtZXNzYWdlcy4gcy9pdCBpcy9pdCBjb3Vs ZCBoYXZlIGJlZW4vIHdvdWxkIHdvcmsgbWF5YmUuPGJyPiZndDsgPGJyPiZndDsgLSAyLjI6ICIg KiZuYnNwOyBUaGUgSTJSUyBjbGllbnQgaXNzdWVzIGEgcmVhZCByZXF1ZXN0IHRvIGEgSTJSUyBh Z2VudCw8YnI+Jmd0OyBhbmQgdGhlIEkyUlMgQWdlbnQgcmVzcG9uZGluZyB0byB0aGUgcmVhZCBy ZXF1ZXN0IiBTaG91bGRuJ3QgdGhhdCB1c2U8YnI+Jmd0OyByZXNwb25kIGFuZCBub3QgcmVzcG9u ZGluZz8gR2l2ZW4gdGhhdCB5b3Ugc2VlbSB0byBiZSB0cnlpbmcgdG88YnI+Jmd0OyBkZWZpbmUg dGhlIHNjb3BlIG9mIHdoYXQgaXMgYW5kIGlzIG5vdCBhIHRyYW5zYWN0aW9uLCBJIHRoaW5rIGJl aW5nPGJyPiZndDsgcHJlY2lzZSB3aXRoIHRoZSBsYW5ndWFnZSBpcyBzb21ldGhpbmcgd2VsbCB3 b3J0aCBkb2luZy4mbmJzcDsgVGhlIDJuZDxicj4mZ3Q7IGJ1bGxldCBjb3VsZCBhbHNvIGRvIHdp dGggYSByZS13cml0ZS48YnI+Jmd0OyA8YnI+Jmd0OyAoZGlzY3VzczEpIDIuMjogeW91IHNvcnQt b2YgZGVmaW5lIG1lc3NhZ2VzLCBvcGVyYXRpb25zLCB0cmFuc2FjdGlvbnM8YnI+Jmd0OyBhbmQg YWN0aW9ucy4gTm9uZSBvZiB0aGUgZGVmaW5pdGlvbnMgYXJlIHRoYXQgcHJlY2lzZSwgZS5nLiBh cmUgdGhvc2U8YnI+Jmd0OyB0aGUgb25seSBvcGVyYXRpb25zIG9yIGV4YW1wbGVzPyBBbmQgdHJh bnNhY3Rpb24gYW5kIGFjdGlvbiBhcmVuJ3Q8YnI+Jmd0OyByZWFsbHkgZGVmaW5lZCBhdCBhbGwu IEknbSBub3Qgc3VyZSBpZiB0aGF0J3MgbGlrZWx5IHRvIGJlIGEgcHJvYmxlbTxicj4mZ3Q7IG9y IG5vdC4gSSBzdXNwZWN0IGl0IHdpbGwgbGF0ZXIsIGUuZy4gd2hlbiB5b3UgZ2V0IHRvIGZpZ3Vy aW5nIG91dDxicj4mZ3Q7IHRoZSBzY29wZSB3aXRoaW4gd2hpY2ggcmVwbGF5IG5lZWRzIHRvIGJl IGRldGVjdGFibGUuPGJyPiZndDsgPGJyPiZndDsgLSAyLjI6IHMvdHJhbnNhdGlvbi90cmFuc2Fj dGlvbi88YnI+Jmd0OyA8YnI+Jmd0OyAoZGlzY3VzczIpIC0gMi4yOiAiZGVmaW5lcyBhIHNlY29u ZGFyeSBpZGVudGl0eSBhcyB0aGUgZW50aXR5IG9mIHNvbWU8YnI+Jmd0OyBub24tSTJSUyBlbnRp dHkgIiBUaGF0IGNvdWxkIGJlIGFidXNlZCBmb3IgdHJhY2tpbmcgb2YgdmFyaW91cyBraW5kczxi cj4mZ3Q7IEkgd291bGQgZ3Vlc3MsIGUuZy4gaWYgYW4gSU1FSSB3ZXJlIHVzZWQuIEkgdGhpbmsg eW91IG5lZWQgdG8gbm90ZTxicj4mZ3Q7IHRoYXQgYW5kIHNob3VsZCBpbXBvc2Ugc29tZSByZXF1 aXJlbWVudHMgdGhhdCBzdWNoIHNlY29uZGFyeSA8YnI+Jmd0OyBpZGVudGlmaWVycyBhcmUgbm90 IHVzZWQgdGh1c2x5IGZvciB0cmFja2luZy4mbmJzcDsgQWxzbywgc2hvdWxkIHRoZSBmaXJzdDxi cj4mZ3Q7IG9jY3VycmVuY2Ugb2YgZW50aXR5IHRoZXJlIGJlIGlkZW50aXR5Pzxicj4mZ3Q7IDxi cj4mZ3Q7IC0gMywgMXN0IHBhcmE6IHMvVGhlIHNlY3VyaXR5IGZvciB0aGUvVGhlLyAtIHRoZXJl IGlzbid0IGEgdGhpbmc8YnI+Jmd0OyBjYWxsZWQgdGhlIHNlY3VyaXR5IGZvciB0aGUgaTJycyBw cm90b2NvbC48YnI+Jmd0OyA8YnI+Jmd0OyAoZGlzY3VzczMpIC0gc2VjdGlvbiAzIHNheXMgInRo ZSBJMlJTIHByb3RvY29sIHJlcXVpcmVzIG11dHVhbGx5PGJyPiZndDsgYXV0aGVudGljYXRlZCBJ MlJTIGNsaWVudHMgYW5kIEkyUlMgYWdlbnRzIGNvbW11bmljYXRpbmcgb3ZlciBhPGJyPiZndDsg c2VjdXJlIHRyYW5zcG9ydC4iIFRvIG1lIHRoYXQgaW1wbGllcyB0aGF0IHNvbWV0aGluZyBsaWtl IFRMUyBvciBTU0g8YnI+Jmd0OyBpcyBNVFUgd2hpY2ggc2VlbXMgdG8gY29udHJhZGljdCByZWNl bnQgZW1haWxzLjxicj4mZ3Q7IDxicj4mZ3Q7IC0gc2VjdGlvbiAzIHNheXM6ICJUaGUgSTJSUyBw cm90b2NvbCBNVVNUIGJlIGFibGUgdG8gcHJvdmlkZTxicj4mZ3Q7IGF0b21pY2l0eSBvZiBhbiBJ MlJTIHRyYW5zYWN0aW9uLCBidXQgaXQgaXMgbm90IHJlcXVpcmVkIHRvIGhhdmU8YnI+Jmd0OyBt dWx0aS1tZXNzYWdlIGF0b21pY2l0eSBhbmQgcm9sbC1iYWNrIG1lY2hhbmlzbSB0cmFuc2FjdGlv bnMuPGJyPiZndDsgTXVsdGlwbGUgbWVzc2FnZXMgdHJhbnNhY3Rpb25zIG1heSBiZSBpbXBhY3Rl ZCBieSB0aGUgaW50ZXJkZXBlbmRlbmN5PGJyPiZndDsgb2YgZGF0YS4iJm5ic3A7IEkgZG9uJ3Qg YmVsaWV2ZSB0aGF0IHRoYXQncyBlYXNpbHkgZW5vdWdoIHVuZGVyc3Rvb2QgdG8gYmU8YnI+Jmd0 OyB1c2VmdWwuIEFsc28sIHdvdWxkbid0IHMvTXVsdGlwbGUgbWVzc2FnZXMgPGJyPiZndDsgdHJh bnNhY3Rpb25zL011bHRpcGxlLW1lc3NhZ2UgdHJhbnNhY3Rpb25zLyBiZSBtdWNoIGNsZWFyZXIg aWYgdGhhdCdzPGJyPiZndDsgd2hhdCdzIG1lYW50PyBBbmQgZmluYWxseSwgSSB0aGluayB0aGUg TVVTVCBlbWJlZGRlZCBpbiB0aGUgYWJvdmUgaXM8YnI+Jmd0OyBub3QgdGhhdCBncmVhdCBhbiBp ZGVhIC0gaXQncyBjbGVhcmVyIElNTyB0byBzZXBhcmF0ZSB0aGUgMjExOTxicj4mZ3Q7IGxhbmd1 YWdlIGZyb20gaW50cm9kdWN0b3J5IHRleHQgaW4gZG9jdW1lbnRzIGxpa2UgdGhpcy48YnI+Jmd0 OyA8YnI+Jmd0OyAtIDM6ICJUaGVyZSBhcmUgZGVwZW5kZW5jaWVzIGluIHNvbWUgb2YgdGhlIHJl cXVpcmVtZW50cyBiZWxvdyIgd291bGQ8YnI+Jmd0OyBiZSBiZXR0ZXIgYXMgIlRoZXJlIGFyZSBp bnRlci1kZXBlbmRlbmNpZXMgYmV0d2VlbiBzb21lIG9mIHRoZTxicj4mZ3Q7IHJlcXVpcmVtZW50 cyBiZWxvdyIgdW5sZXNzIHlvdSBtZWFuIGRlcGVuZGVuY2llcyBvbiBzb21lIGV4dGVybmFsIDxi cj4mZ3Q7IHRoaW5ncywgd2hpY2ggaXMgbm90IGNsZWFyIGZyb20gdGhlIHRleHQgYXMtaXMuPGJy PiZndDsgPGJyPiZndDsgKGRpc2N1c3M0KSAiIEZvciBjb25maWRlbnRpYWxpdHkgKHNlY3Rpb24g My4zKSBhbmQgaW50ZWdyaXR5IChzZWN0aW9uPGJyPiZndDsgMy40KSB0byBiZSBhY2hpZXZlZCwg dGhlIGNsaWVudC1hZ2VudCBtdXN0IGhhdmUgbXV0dWFsIGF1dGhlbnRpY2F0aW9uPGJyPiZndDsg KHNlY3Rpb24gMy4xKSBhbmQgc2VjdXJlIHRyYW5zcG9ydCAoc2VjdGlvbiAzLjIpLiZuYnNwOyAi IFRoaXMgaXMgPGJyPiZndDsgaW5jb3JyZWN0LiBPbmUgY2FuIGhhdmUgY29uZmlkZW50aWFsaXR5 IHdpdGhvdXQgYXV0aGVudGljYXRpb24gKHNlZTxicj4mZ3Q7IFJGQzc0MzUpIHNvIHRoZSB0ZXh0 IGlzIG5vdCBhY2N1cmF0ZS48YnI+Jmd0OyA8YnI+Jmd0OyAtIGNhcGl0YWxpc2F0aW9uIG5lZWRz IGZpeGluZyBpbiB2YXJpb3VzIHBsYWNlcywgZS5nLiBhcm91bmQgdGhlIGVuZDxicj4mZ3Q7IG9m IHA1LCB3ZSBnZXQgInNlY3VyZSBUcmFuc3BvcnQiIGFuZCB0aGVuICJJMlJTIGNsaWVudCIgYW5k ICJJMlJTPGJyPiZndDsgQWdlbnQiIGluIHRoZSB0aXRsZSBvZiAzLjEgSXMgYW55IG9mIHRoYXQg Y2FwaXRhbGlzYXRpb24gc3VwcG9zZWQgdG88YnI+Jmd0OyBiZSBzaWduaWZpY2FudD8gRWl0aGVy IHdheSwgZml4aW5nIGl0IG5vdyB3b3VsZCBiZSBnb29kIGFzIHlvdSdsbDxicj4mZ3Q7IG5lZWQg dG8gZ2V0IHRoZSBSRkMgZWRpdG9yIHRvIGRvIGl0IGxhdGVyIGlmIHlvdSBkb24ndCAod2hpY2gg dGFrZXM8YnI+Jmd0OyBsb25nZXIpLjxicj4mZ3Q7IDxicj4mZ3Q7IChkaXNjdXNzNSkgU0VDLVJF US0wMTogd2hhdCBpcyB0aGUgc2NvcGUgb2YgdW5pcXVlbmVzcyByZXF1aXJlZCBoZXJlPzxicj4m Z3Q7IEkgc2VlIG5vIHJlYXNvbiB3aHkgdHdvIGRpZmZlcmVudCBkYXRhIGNlbnRyZXMgY2Fubm90 IHJlLXVzZSBhIGNsaWVudDxicj4mZ3Q7IG9yIGFnZW50IGlkZW50aWZpZXIsIGlmIHRoZXkgc28g d2lzaC4gSSdkIGJlIGZpbmUgaWYgeW91IHNheSB0aGF0J3M8YnI+Jmd0OyBmb3IgbGF0ZXIgZGVj aXNpb24sIGJ1dCBiZWluZyBzaWxlbnQgb24gdGhlIG1hdHRlciBjb3VsZCBsZWFkIHRvIDxicj4m Z3Q7IHRyb3VibGUgbGF0ZXIgaWYgZGlmZmVyZW50IGZvbGtzIGRlY2lkZSBkaWZmZXJlbnRseS48 YnI+Jmd0OyA8YnI+Jmd0OyAoZGlzY3VzczYpIFNFQy1SRVEtMDI6IHRoZSAiTVVTVCB1dGlsaXpl IiB0aGVyZSBtZWFucyBNVFUsIHdoaWNoPGJyPiZndDsgd2Fzbid0IHdoYXQgeW91IHdhbnRlZCBJ IHRoaW5rPGJyPiZndDsgPGJyPiZndDsgKGRpc2N1c3M3KSAtIFNFQy1SRVEtMDM6IGhvdyBpcyAi dXBvbiByZWNlaXZpbmcuLi4gTVVTVCBjb25maXJtIiBhPGJyPiZndDsgZ29vZCBjaG9pY2U/IEFz IHN0YXRlZCB0aGF0J2QgYmUgaHVnZWx5IG9uZXJvdXMsIGltcGx5aW5nIGUuZy4mbmJzcDsgT0NT UDxicj4mZ3Q7IGNoZWNrcyBmb3IgZWFjaCBwYWNrZXQgcmVjZWl2ZWQuIFNhbWUgcG9pbnQgYXBw bGllcyB0byBTRUMtUkVRLTA0Ljxicj4mZ3Q7IDxicj4mZ3Q7IChkaXNjdXNzOCkgLSBTRUMtUkVR LTA1OiB0aGlzIGVpdGhlciBtZWFucyBub3RoaW5nIGF0IGFsbCAoYmVpbmcgYTxicj4mZ3Q7IHRh dXRvbG9neSkgb3IgZWxzZSBzb21ldGhpbmcgSSBkb24ndCBnZXQuIEkgdGhpbmsgaXQncyB0aGUg Zm9ybWVyLDxicj4mZ3Q7IGJ1dCBhbSBub3Qgc3VyZS48YnI+Jmd0OyA8YnI+Jmd0OyAtIDMuMTog cy9PbmUgbWVjaGFuaXNtIHN1Y2ggbWVjaGFuaXNtL09uZSBzdWNoIG1lY2hhbmlzbS8gSSBndWVz cy48YnI+Jmd0OyBBbmQgaXQncyBub3QgYXQgYWxsIGNsZWFyIHRvIG1lICJBQUEgcHJvdG9jb2xz IiBpcyB0aGUgcmlnaHQgaWRlYTxicj4mZ3Q7IHRoZXJlLCBhbmQgbm9yIGlzIGl0IGNsZWFyIHdo YXQncyBtZWFudCwgd2l0aCB0aGUgdGV4dCBhcy1pcy48YnI+Jmd0OyA8YnI+Jmd0OyAtIFNFQy1S RVEtMDY6IHdoZXJlIGlzIGEgInByaW9yaXR5IiBkZWZpbmVkPzxicj4mZ3Q7IDxicj4mZ3Q7IC0g U0VDLVJFUS0wNzogaGVyZSB5b3Ugc2F5IHJlYWQvd3JpdGUgaXMgYSB0cmFuc2FjdGlvbiwgYnV0 IGVhcmxpZXI8YnI+Jmd0OyB5b3Ugc2FpZCBpdCB3YXMgYW4gb3BlcmF0aW9uLCB3aGljaCBpcyBp dD88YnI+Jmd0OyA8YnI+Jmd0OyAoZGlzY3VzczkpIDMuMjogQXMgd2l0aCBvdGhlcnMsIEkgZG9u J3QgdGhpbmsgdGhlIGlkZWEgb2YgYW5ub3RhdGluZzxicj4mZ3Q7IHBhcnRzIG9mIHlhbmcgbW9k dWxlcyB3aXRoICJjYW4gYmUgaW5zZWN1cmUiIGlzIGEgZ29vZCBvbmUuIFRoZXJlJ3MgYTxicj4m Z3Q7IHNlcGFyYXRlIHRocmVhZCBkaXNjdXNzaW5nIHRoYXQgdGhvdWdoLCBzbyBtYXliZSBiZXR0 ZXIgdG8gbm90IGZvcmsgPGJyPiZndDsgdGhhdC48YnI+Jmd0OyA8YnI+Jmd0OyAoZGlzY3VzczEw KSAtIFNFQy1SRVEtTzk6IEkgaGF0ZSB0byBkbyB0aGlzIHRvIHlhLCBidXQgQkNQMTA3IGlzIElN Tzxicj4mZ3Q7IGEgZmFpcmx5IGNsZWFyIGZhaWx1cmUgd2hlbiBpdCBjb21lcyB0byByb3V0aW5n LiBBbmQgeWV0IGFnYWluIHRoZTxicj4mZ3Q7IGV4Y2VwdGlvbnMgY2xhdXNlcyBoZXJlIGFyZSBz byBicm9hZCBhcyB0byBiZSBtZWFuaW5nbGVzcyAoZS5nLjxicj4mZ3Q7IGNvbnNpZGVyZWQgbG93 IHZhbHVlIGJ5IHdob20/KS4gV2hhdCBpcyB0aGUgcmVhbCBnb2FsIGhlcmU/IChvdGhlciA8YnI+ Jmd0OyB0aGFuIGFuIGF0dGVtcHQgdG8ga2VlcCB0aGUgc2VjIEFEcyBmcm9tIGJlaW5nIGFubm95 aW5nIGFuZCB0cnlpbmcgdG88YnI+Jmd0OyBpbnNpc3Qgb24gQkNQMTA3PyA7LSk8YnI+Jmd0OyA8 YnI+Jmd0OyAoZGlzY3VzczExKSAtIFNFQy1SRVEtMDk6IFNlcGFyYXRlbHksIHRvIG15IG90aGVy IHdvdWxkLWJlLWRpc2N1c3M8YnI+Jmd0OyBwb2ludCBvbiB0aGlzIHJlcXVpcmVtZW50LCAiY2Fu IGd1YXJhbnRlZSIgaXMgd2VsbCBiZXlvbmQgdGhlIHN0YXRlPGJyPiZndDsgb2YgdGhlIGFydCBp biBrZXkgbWFuYWdlbWVudC4gSSdkIGp1c3QgZHJvcCB0aGF0IHNlbnRlbmNlIG1heWJlLCBidXQg PGJyPiZndDsgY2FuJ3QgbWFrZSBhIGNvbmNyZXRlIHN1Z2dlc3Rpb24gdW50aWwgSSB1bmRlcnN0 YW5kIHdoZXJlIHlvdSB3YW50IHRvPGJyPiZndDsgYmUgd3J0IEJDUDEwNy48YnI+Jmd0OyA8YnI+ Jmd0OyAtIFNFQy1SRVEtMTA6IHRoZSBsYXN0IHNlbnRlbmNlIGhlcmUgaXMgYWxzbyBpbnZvbHZl ZCBpbiB0aGUgIm1heSBkbzxicj4mZ3Q7IHN0dWZmIGluc2VjdXJlbHkiIHRoaW5nLCBhbmQgc28g d2lsbCBsaWtlbHkgbmVlZCBmaXhpbmcgd2hlbiB0aGF0IGlzPGJyPiZndDsgZnVsbHkgcmVzb2x2 ZWQuPGJyPiZndDsgPGJyPiZndDsgLSBIb3cgaXMgU0VDLVJFUS0xMSB1c2VmdWw/IFdoYXQgcHJv dG9jb2wgYXJ0ZWZhY3RzIGRvIHlvdSBoYXZlIGluPGJyPiZndDsgbWluZCBoZXJlPyBQZXJoYXBz IGEgcmVxdWlyZW1lbnQgdGhhdCBERG9TIGF0dGFja3MgYmUgc3BlY2lmaWNhbGx5PGJyPiZndDsg Y29uc2lkZXJlZCBpbiBJMlJTIHdvdWxkIGJlIG1vcmUgdXNlZnVsLjxicj4mZ3Q7IDxicj4mZ3Q7 IC0gU0VDLVJFUS0xMjogVGhpcyBzZWVtcyB0byBtZSB0byBoYXZlIHRvbyBtYW55IHdvcmRzLCBl LmcuIHRoZTxicj4mZ3Q7IGN1cnJlbnQgdGV4dCBjb3VsZCBiZSByZWFkIHRvIGltcGx5IHRoYXQg b3V0c2lkZSBvZiBjcml0aWNhbDxicj4mZ3Q7IGluZnJhc3RydWN0dXJlIHRoZXJlIGlzIGxlc3Mg b3Igbm8gbmVlZCBmb3IgY29uZmlkZW50aWFsaXR5LCBzbyB0aG9zZTxicj4mZ3Q7IGFkZGVkIHdv cmRzIChwcmVzdW1hYmx5IHRoZXJlIHRvIG1vdGl2YXRlKSBtaWdodCBiZSA8YnI+Jmd0OyBjb3Vu dGVyLXByb2R1Y3RpdmUuPGJyPiZndDsgPGJyPiZndDsgKGRpc2N1c3MxMikgU0VDLVJFUS0xMjog SSBkb24ndCBnZXQgdGhlIG1lYW5pbmcgb2YgdGhlIFNIT1VMRCBoZXJlIC08YnI+Jmd0OyBjb21i aW5lZCB3aXRoICJjZXJ0YWluIGRhdGEiIHRoYXQgU0hPVUxEIHNlZW1zIHRvIGVuZCB1cCBtZWFu aW5nIE1BWSw8YnI+Jmd0OyBhcyBpbiwgaXQgc2VlbXMgdG8gbWVhbiB0aGUgc2FtZSBhcyAiUmVh ZC93cml0ZSBvcGVyYXRpb25zIE1BWSBoYXZlPGJyPiZndDsgdG8gYmUgcHJvdGVjdGVkIHVzaW5n IGEgY29uZmlkZW50aWFsaXR5IHNlcnZpY2UuIjxicj4mZ3Q7IDxicj4mZ3Q7IC0gMy40LCBidWxs ZXQgKDIpIGhlcmUgbWVhbnMgdGhhdCB3ZSdyZSBub3QgdGFsa2luZyBhYm91dCBkYXRhPGJyPiZn dDsgaW50ZWdyaXR5IGJ1dCBkYXRhIG9yaWdpbiBhdXRoZW50aWNhdGlvbiBhcyB3ZWxsLjxicj4m Z3Q7IDxicj4mZ3Q7IChkaXNjdXNzMTMpIDMuNCwgKDMpOiBXaXRoaW4gd2hhdCBzY29wZSBtdXN0 IHJlcGxheSBiZSBkZXRlY3RlZD8gVGhlPGJyPiZndDsgdGV4dCBpbXBsaWVzIGZvciBldmVyLCB3 aGljaCBjYW4gYmUgdmVyeSBvbmVyb3VzLiBTRUMtUkVRLTE0IGRvZXNuJ3Q8YnI+Jmd0OyBxdWl0 ZSBnbyBzbyBmYXIsIGJ1dCBpcyBhbWJpZ3VvdXMgb24gdGhpcyBhc3BlY3QuIEknZCBzYXkgYmVz dCBpcyB0bzxicj4mZ3Q7IG5vdGUgdGhhdCB0aGUgc2NvcGUgd2l0aGluIHdoaWNoIHJlcGxheSBu ZWVkcyB0byBiZSBkZXRlY3RhYmxlIGlzIGZvcjxicj4mZ3Q7IGZ1dHVyZSBzdHVkeS48YnI+Jmd0 OyA8YnI+Jmd0OyAoZGlzY3VzczE0KSBTRUMtUkVRLTE1OiBTb3JyeSwgSSBkb24ndCB1bmRlcnN0 YW5kIHdoYXQncyByZXF1aXJlZDxicj4mZ3Q7IGhlcmUgKGhhdmluZyByZWFkIHRoaXMgJmd0OzEg dGltZSkuIENhbiB5b3UgZXhwbGFpbj8mbmJzcDsgSSdtIG5vdCBzdXJlIGlmPGJyPiZndDsgYW55 IHN1YnN0YW50aXZlIGNoYW5nZSBpcyBuZWVkZWQsIGJ1dCB0aGVyZSBhcmUgY2VydGFpbmx5IGVk aXRvcmlhbDxicj4mZ3Q7IGNoYW5nZXMgbmVlZGVkIGZvciBzdXJlIGFzIHRoZXJlIGFyZSBtdWx0 aXBsZSB3b3JkaW5nIHByb2JsZW1zIHdpdGg8YnI+Jmd0OyB0aGUgdGV4dCBhcy1pcy48YnI+Jmd0 OyA8YnI+Jmd0OyAtIDMuNSwgMXN0IHBhcmE6IHRoZSB0ZXh0IGhlcmUgaXMgbm90IGFzIGdvb2Qg YXMgdGhlIGFjdHVhbDxicj4mZ3Q7IGRlZmluaXRpb24gb2YgInJvbGUiIGluIFJGQzc5MjEsIGFu ZCBpbiBmYWN0IEkgZm91bmQgdGhlIHRleHQgaGVyZTxicj4mZ3Q7IGNvbmZ1c2luZy4gQmV0dGVy IHRvIGp1c3QgZGVsZXRlIHRoYXQgYW5kIHNheSB0aGF0IDc5MjEgZGVmaW5lczxicj4mZ3Q7IHJv bGVzLjxicj4mZ3Q7IDxicj4mZ3Q7IChkaXNjdXNzMTUpIFNFQy1SRVEtMTY6IEkgZG9uJ3Qgc2Vl IGFueSBjb250ZW50IGluIHRoaXMgdGV4dCBhcyBpdDxicj4mZ3Q7IHNlZW1zIHRvIGp1c3Qgc2F5 ICJzb21lIHJvbGUgYmFzZWQgYWNjZXNzIGNvbnRyb2wgYW5kIHNvbWUgbGV2ZWwgb2Y8YnI+Jmd0 OyB0cmFuc3BvcnQgcHJvdGVjdGlvbiBuZWVkIHRvIGJlIHByb3ZpZGVkIiB3aGljaCBpcyBhbHdh eXMgdHJ1ZSwgYXM8YnI+Jmd0OyB5b3UgYXJlIGFsbG93aW5nICJubyB0cmFuc3BvcnQgc2VjdXJp dHkiIGFuZCAoSSBhc3N1bWUpICJmdWxseTxicj4mZ3Q7IHB1YmxpYyBhY2Nlc3MiIHNvIGFueSBw cm90b2NvbC9zeXN0ZW0gd2lsbCBhbHdheXMgbWVldCB0aGlzIDxicj4mZ3Q7IHJlcXVpcmVtZW50 Ljxicj4mZ3Q7IDxicj4mZ3Q7IC0gU0VDLVJFUS0xNjogInByaXZhY3kgcmVxdWlyZW1lbnRzIiBo ZXJlIGlzIHdyb25nLCB5b3UgbWVhbjxicj4mZ3Q7IGNvbmZpZGVudGlhbGl0eSBJIHRoaW5rLjxi cj4mZ3Q7IDxicj4mZ3Q7IChkaXNjdXNzMTYpIFNFQy1SRVEtMTc6ICJNVVNUIHdvcmsiIGlzIGZh ciB0b28gdmFndWUuIFRoYXQgY291bGQgZm9yPGJyPiZndDsgZXhhbXBsZSBoaWRlIGEgbWFqb3Ig ZGViYXRlIGFib3V0IHB1c2ggdi4gcHVsbCBvZiByb2xlIGluZm9ybWF0aW9uLjxicj4mZ3Q7IElm IHRoZSBXRyBoYXZlbid0IGNvbnNpZGVyZWQgdGhhdCwgSSB0aGluayB5b3UgY291bGQgYWNrIHRo YXQgYWdhaW48YnI+Jmd0OyBieSBzYXlpbmcgdGhhdCBtb3JlIHdvcmsgaXMgbmVlZGVkIHRvIGRl ZmluZSBob3cgUkJBQyBpcyBjb25zaXN0ZW50PGJyPiZndDsgYWNyb3NzIG11bHRpcGxlIHRyYW5z cG9ydCBsYXllciBjb25uZWN0aW9ucy48YnI+Jmd0OyA8YnI+Jmd0OyAoZGlzY3VzczE3KSBTRUMt UkVRLTE4OiBhZ2FpbiB0aGlzIHNlZW1zIHRvIGhhdmUgbm8gY29udGVudCwgb3RoZXI8YnI+Jmd0 OyB0aGFuIHBlcmhhcHMgaW1wb3NpbmcgYW4gb2RkIHJlcXVpcmVtZW50IG9uIGltcGxlbWVudGF0 aW9ucyAtIEkgZG9uJ3Q8YnI+Jmd0OyBzZWUgYSBwcm90b2NvbCByZXF1aXJlbWVudCBoZXJlIGF0 IGFsbC4gSXQgaXMgcmVhc29uYWJsZSB0byBub3RlIHRoYXQ8YnI+Jmd0OyBsaWJyYXJpZXMgZm9y IGNsaWVudHMgb3VnaHQgbm90IGFzc3VtZSBhIHNpbmdsZSBjbGllbnQgaWRlbnRpdHkgYnV0PGJy PiZndDsgZXZlbiB0aGF0J3MgdmVyeSBzcGVjaWZpYyB0byBsaWJyYXJ5IGltcGxlbWVudGF0aW9u cyBhbmQgc2luY2UgaXQnczxicj4mZ3Q7IGp1c3QgYSBNQVkgdGhhdCdzIGVudGlyZWx5IG9idmlv dXMsIEknZCBsZWF2ZSBpdCBvdXQuPGJyPiZndDsgPGJyPiZndDsgKGRpc2N1c3MxOCkgU0VDLVJF US0xOTogSSBmdWxseSBhZ3JlZSB3aXRoIHRoZSBtb3RpdmF0aW9uIGhlcmUgYnV0IEk8YnI+Jmd0 OyB0aGluayB0aGUgc3RhdGVkIHJlcXVpcmVtZW50IGlzIGJyb2tlbi4mbmJzcDsgRm9yIGV4YW1w bGUsIEkgZG9uJ3Qga25vdzxicj4mZ3Q7IGhvdyBhIHBpZWNlIG9mIHMvdyB3aWxsIGRldGVybWlu ZSB3aGV0aGVyIG9yIG5vdCBpdCBpcyBjb3JyZWxhdGVkPGJyPiZndDsgd2l0aCBhIHBlcnNvbi4g SSBhbHNvIGRvbid0IHRoaW5rIGEgU0hPVUxEIHdvcmtzIGhlcmUsIGFzIGFnYWluPGJyPiZndDsg c29tZXRoaW5nIHdvdWxkIG5lZWQgdG8gYmUgc3RhdGVkIGFib3V0IHRoZSBzaXR1YXRpb25zIHdo ZW4gdGhlPGJyPiZndDsgZmVhdHVyZSBpcyBub3QgbmVlZGVkLCBhbmQgSSBjYW4ndCBmaWd1cmUg b3V0IGEgc2Vuc2libGUgc3RhdGVtZW50PGJyPiZndDsgZm9yIHRoYXQuIFRoZSBsYXN0IHNlbnRl bmNlIGFsc28gc2VlbXMgbGlrZWx5IG5vdCB1c2VmdWwuIEFsbCBpbiBhbGwsPGJyPiZndDsgSSB0 aGluayB0aGlzIGlzIGxpa2VseSB0byBiZSBpZ25vcmVkIG9yIGV2ZW4gd29yc2UgdHJlYXRlZCBs aWtlIGE8YnI+Jmd0OyBwaWVjZSBvZiBmaWctbGVhZiBzcGVjaWZpY2F0aW9uIHRleHQgdG8gcHJl dGVuZCB0aGF0IHdlJ3JlIGNhcmluZzxicj4mZ3Q7IGFib3V0IHByaXZhY3kuPGJyPiZndDsgPGJy PiZndDsgKGRpc2N1c3MxOSkgLSAzLjY6IEkgaGF2ZSBubyBpZGVhIHdoZXRoZXIgdGhpcyBvdGhl ciBkcmFmdCBpczxicj4mZ3Q7IHN1cHBvc2VkIHRvIGJlIGNvbnNpZGVyZWQgYXMgc2V0dGluZyBy ZXF1aXJlbWVudHMgb3Igbm90LiBJIGFzc3VtZTxicj4mZ3Q7IHRoYXQgdGhlIGFuc3dlciBpcyAi bm90IiBhcyB5b3UndmUgbWFkZSBpdCBhbiBpbmZvcm1hdGl2ZSByZWZlcmVuY2UsPGJyPiZndDsg YnV0IGluIHRoYXQgY2FzZSB5b3UgcmVhbGx5IHNob3VsZCBzYXkgdGhhdC4mbmJzcDsgVGhlIGFs dGVybmF0aXZlIHdvdWxkIDxicj4mZ3Q7IGJlIHRoYXQgMy42IGlzIGVzc2VudGlhbGx5IHNwZWNp ZnlpbmcgYW4gYXBwbGljYWJpbGl0eSBzdGF0ZW1lbnQgZm9yPGJyPiZndDsgdGhlIGVudmlyb25t ZW50cyBpbiB3aGljaCBpdCBpcywgYW5kIGlzIG5vdCwgb2sgdG8gcnVuIGkycnMuIElmIHRoZTxi cj4mZ3Q7IGxhdHRlciB3ZXJlIGludGVuZGVkLCB0aGVuIHlvdSdkIG5lZWQgdG8gc2F5IGl0IGFu ZCBtYWtlIHRoZSBkcmFmdCBhPGJyPiZndDsgbm9ybWF0aXZlIHJlZmVyZW5jZS48YnI+Jmd0OyA8 YnI+Jmd0OyA8YnI+Jmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXyBpMnJzIG1haWxpbmcgbGlzdCA8YnI+Jmd0OyBpMnJzQGlldGYub3JnIGh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaTJyczxicj4mZ3Q7IDxicj48YnI+PC9ib2R5 PjwvaHRtbD4= ----_com.samsung.android.email_200817715012930-- From nobody Sun Aug 21 16:23:55 2016 Return-Path: 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 D229C12D5A5; Sun, 21 Aug 2016 16:23:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.849 X-Spam-Level: X-Spam-Status: No, score=-4.849 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_MED=-2.3, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie 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 kOLXVp6CPDbP; Sun, 21 Aug 2016 16:23:45 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8C0D012D59D; Sun, 21 Aug 2016 16:23:45 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 3FD82BE35; Mon, 22 Aug 2016 00:23:43 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uleTL6NnqWNA; Mon, 22 Aug 2016 00:23:40 +0100 (IST) Received: from [10.87.48.210] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 81692BE2F; Mon, 22 Aug 2016 00:23:39 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1471821820; bh=2aqCnXoj9zMT3ikl96RJrg04alNfDQ2mEO8Qdv/thBM=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=ObtehSgf/DFNQQ//zABCufDSk96SqZOn6eiCUNq13Y9d4Zy20IkktULISEIQiJUCf WtQRWfxyvKhgsMvS+jKbGyVwRLjcVgo67dG0iIZ8XFyfF2CXBu9F/h22GyoH2Akw1x qHQstmVCP7kcr58vhlDAyqMaftG9wQAo863l1vFE= To: Susan Hares , The IESG References: From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: Date: Mon, 22 Aug 2016 00:23:39 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms010600000401040204010306" Archived-At: Cc: jhaas@pfrc.org, i2rs@ietf.org, i2rs-chairs@ietf.org, draft-ietf-i2rs-protocol-security-requirements@ietf.org Subject: Re: [i2rs] Stephen Farrell's Abstain on draft-ietf-i2rs-protocol-security-requirements-09: (with COMMENT) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Aug 2016 23:23:49 -0000 This is a cryptographically signed message in MIME format. --------------ms010600000401040204010306 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hiya, On 21/08/16 22:57, Susan Hares wrote: > Stephen: Thank you for the explanations. Iterative edits do impact > on the style.=20 Well, yes, but it is not just a matter of style, when there are so many non-sentences. > While you denote the concern as pervasive monitoring, Not just I - the IETF adopted that term in BCP188. > in my mind it is better to consider the effort as ensuring pervasive > privacy for individuals and groups utilizing the Internet. (Having > worked with survivors of domestic abuse and sexual abuse, I cheer > IETF effort on pervasive monitoring.) My focus and the reason I asked > about the security directorate reviews - is that it is important to > fix problems early in the process. =20 If you really want my opinion on process here - I think that the process the WG are following to document requirements in RFCs is where the problem lies. That causes us all to want to ensure that the text documenting the agreed requirements is sufficient precise for us all, whereas that level of precision (of the text) is not really required for most requirements in order to pursue the work. > When I come to an unexpected > failing grade for a document,=20 Again, I do not agree with the concept that there is any such failing grade. We (the IETF) ought consider that it's a normal part of the process that work has to go back a step or two now and then in order to be done as well as we need it to be done. If the end result of this IESG evaluation is that this document ends up back with the WG, then I would hope that that leads to an overall better outcome. If OTOH, the document still moves ahead, then I am not insisting on being a blocking factor as I have balloted abstain. > I try to address both the document and > the process in order to improve. I expected the process of getting a > security directorate reviews would detect problems sooner.=20 I think it did detect some problems. Did it identify all problems? No. And one ought not expect that from any volunteer-lead review process. One ought also not expect that an early secdir review will focus on the precise words used, as those will change before the work is done. And many of my comments on this relate to (im)precision in the words used. > So I am > asking what happened in the security directorate reviews that caused > them to miss your concerns? Did miss something in their comments?=20 See above. It's entirely normal that reviews do not involve a constant level of effort, nor produce a predictable outcome. > My next question is what do you expect from a protocol security > document? Do you have a checklist?=20 I don't think it's reasonable to ask an AD what they consider a perfect document, nor for a checklist. (And the document in question is not a "protocol security" specification but a requirements specification, which is a different beast entirely.) > On the next steps, I responded up > through your ~discuss-criteria.html comment 5. If you have time to > answer just my qustions on the 5 discuss Qs - it will help my > discussion with Alia.=20 I will look tomorrow. But to be honest, it would really help me if it were possible for your email to use normal email quoting. (Your mail seems to not do that - "who said what" may be nicely visible in your mail UA but in my very basic one it's very hard to pick out what you and what I wrote.) But I can manage with what you sent if it's hard to do it with normal quoting. (FWIW, I suspect the form of quoting you used has lead other discussions on this draft to be more prolonged that would otherwise have been the case - at least that's a pattern I think I see over many discussions and in this one too.) Cheers, S. > SueSue >=20 > Sent via the Samsung Galaxy Note5, an AT&T 4G LTE smartphone -------- > Original message --------From: Stephen Farrell > Date: 8/21/16 3:41 PM (GMT-05:00) To: > Susan Hares , The IESG Cc: > jhaas@pfrc.org, i2rs@ietf.org, i2rs-chairs@ietf.org, > draft-ietf-i2rs-protocol-security-requirements@ietf.org Subject: Re: > [i2rs] Stephen Farrell's Abstain on > draft-ietf-i2rs-protocol-security-requirements-09: (with COMMENT) >=20 > Hiya, >=20 > On 21/08/16 20:10, Susan Hares wrote: >> Stephen: Thank you for leaving your vacation early to do this >> review. It is one of the most negative viewpoint I have read from >> you, and since have read many of your DISCUSS comments since you >> became an AD >=20 > Well, I've done far more negative reviews, but this one has a lot of > smaller negative comments. My guess is quite a lot of that is down to > a) it's very very hard to write protocol requirements text crisply=20 > and accurately, and b) that kind of text is very very easily messed > up when doing iterative edits in response to reviews, and c) the > writing is really not that good in this version - to the point where > the accumulation of nits itself becomes a notable issue, and where > it's likely past time that an editorial pass was done to get that out > of the way. >=20 >> - I think this gives me unique perspective. This is far from the=20 >> early comments you sent 2 weeks ago. >=20 > No. I would not have asked for a defer if I thought the only concern=20 > was the possibility of this resulting in a hard-to-deploy set of=20 > security mechanisms - I would have just balloted that. It is the > case that that's all I said before I had properly read the document > though, yes. And it wasn't 2 weeks ago:-) >=20 >> In developing this document and I2RS technology the I2RS WG and I >> as the I2RS chair have request reviews from the Security >> directorate. We delayed out first revisions to try to address >> security issue by adding this document and the security environment >> document. We have had early and late reviews. Since the initial >> review on the I2RS architecture we have discussed the non-secure >> interface and tried to get security directorate's review. >=20 > I have looked back at the secdir mails on this, yes. >=20 >> I raised the pervasive privacy issue and asked for input in your >> review. >=20 > Yes. And I responded with two would-have-been-discuss points related=20 > to pervasive monitoring. (I assume that what's you mean when you say=20 > "pervasive privacy" but if you mean something else above, please do=20 > clarify.) >=20 >> This meta-comment is that process of asking for aid ahead of this >> point has failed according to your review, >=20 > I think that's an odd view of IETF processes, which are never > expected to produce perfection at any stage. IMO we're iterating > towards better outcomes, not failing/succeeding at each stage of the > process. >=20 >> but I cannot find a point where the I2RS WG did not solicit the >> security area's aid and take its advice. Therefore, I must ask >> you to check the process of your security directorate's reviews to >> find what happened to cause such a failure. >=20 > Don't think of it as failure, think of it as more eyeballs finding > more things. (Or repeating things already considered, for those where > that's the case.) >=20 >> Now as to the document, I have a WG waiting for these requirements. >>=20 >=20 > I'd encourage you to question the above, as a first order goal. Are=20 > the WG really waiting on these in a final, fixed-forever, form? Or do > you need a general agreement as to direction and can then make=20 > progress? (And perhaps reduce the final requirements to RFC status=20 > later if there's value in that, which there can be.) >=20 > As I noted a couple of times in my review, it's not possible to be=20 > that precise about some requirements without having done more of the=20 > design. (One of the traditional waterfalll design problems I guess.)=20 > The scope of replay detection is probably a good example. >=20 >> I would like to hear in a completely separate email thread what >> kernel of information you would have expected regarding the >> security first an i2rs protocol. >=20 > I don't understand your question sorry. >=20 >> I would then like to compare this against the security >> directorate's suggestions on this document. We have a second >> document on the security environment so your insights will be >> applied to that document. Since in the general text you indicate >> the style is terrible and needs to be written, please provide an >> example of a document as an example of the style. >=20 > Really? The accumulation of badly written sentences in -09 has got to > be a clear enough problem that you don't need an example of what is > not-that. So I'm puzzled at the request. >=20 >> My understanding is that style is a lower priority than technical >> correctness and consensus. >=20 > Correct/good-enough writing is certainly secondary, up until the=20 > issues get to a certain point that impinges on the reader's ability=20 > to asses the meaning, and that happens a couple of times in this=20 > document. (As I said in my review.) The other writing issues make=20 > this a harder read than ought be the case. That doesn't reach the=20 > level of making the document unreadable, nor nearly get that bad, but > it is enough that I wonder if other readers may have been put off by > that in reading some of the text. >=20 >> This email ends my comments on your summary message. The next set >> of comments will take your discuss comments one at a time. The >> exact next steps that I and my co-author will take will be guided >> by the AD responsible for the I2RS WG, >=20 > That's all good. >=20 > I would re-iterate though, that since my ballot is an abstain > there's no onus on you or the WG to respond in any more detail than > you feel is useful. >=20 > Cheers, S. >=20 >> Alia. Cheerily, Sue Hares >>=20 >> Sent via the Samsung Galaxy Note5, an AT&T 4G LTE smartphone >> -------- Original message --------From: Stephen Farrell=20 >> Date: 8/21/16 8:37 AM (GMT-05:00) >> To: The IESG Cc: jhaas@pfrc.org, i2rs@ietf.org,=20 >> i2rs-chairs@ietf.org,=20 >> draft-ietf-i2rs-protocol-security-requirements@ietf.org Subject:=20 >> [i2rs] Stephen Farrell's Abstain on=20 >> draft-ietf-i2rs-protocol-security-requirements-09: (with COMMENT)=20 >> Stephen Farrell has entered the following ballot position for=20 >> draft-ietf-i2rs-protocol-security-requirements-09: Abstain >>=20 >> When responding, please keep the subject line intact and reply to=20 >> all email addresses included in the To and CC lines. (Feel free to=20 >> cut this introductory paragraph, however.) >>=20 >>=20 >> Please refer to=20 >> https://www.ietf.org/iesg/statement/discuss-criteria.html for more=20 >> information about IESG DISCUSS and COMMENT positions. >>=20 >>=20 >> The document, along with other ballot positions, can be found here: >> =20 >> https://datatracker.ietf.org/doc/draft-ietf-i2rs-protocol-security-req= uirements/ >> >> >> >> >> >>=20 ---------------------------------------------------------------------- >>=20 >>=20 > COMMENT: >> ----------------------------------------------------------------------= >> >> >> >> >>=20 First, apologies for not getting my review done for this when it was >> scheduled due to my vacation and thanks for being willing to defer=20 >> the document. >>=20 >> Second, having now properly reviewed this, I am balloting abstain >> as I think it's unlikely that this document can be fixed in a way >> that results in something useful happening. I think that the likely >> outcome is that this document will be used later when people are=20 >> arguing and will not much help in resolving those arguments, or >> else this will be ignored and arguments will be held afresh, as >> needed. That latter outcome is what I'd guess is most likely and >> therefore it seems that spending all of our cycles on DISCUSS >> ballot processing for this would not be wise. That said, I am >> willing to change to a DISCUSS ballot if the responsible AD prefers >> that, but I suspect I'll end up with an abstain in any case, after >> some discussion. The only plan I can think of that'd lead to me >> ending up with a yes or no-objection ballot would be if this was >> returned to the WG for fixing and possibly major surgery, which is >> what I actually think would be the best plan. (I realise this has >> had a somewhat tortured history, so folks may not be willing to >> take it back to the WG, but honestly, I think the failings visible >> in this document do indicate that this is not ready for approval >> and ought be returned to the WG.) >>=20 >> Third, I think the overall set of requirements posed here might >> (with some unknown probability) lead to later specifications that >> are considered too hard to deploy, with the result that non-secure=20 >> variants of I2RS become the norm. That seems like it would be a=20 >> really bad outcome. I would suggest that might be partly mitigated >> if a requirement were added to the effect that deployment issues >> and specifically ease of deployment MUST be considered as a first >> order requirement when developing I2RS protocol solutions. >>=20 >> Fourth, the (19!) comments below that are preceded by "(discuss"=20 >> would have been DISCUSS ballot points had I not decided to abstain. >> I am happy to chat about any of my comments below, but if the=20 >> authors/WG do want to chat, it might be more efficient to >> concentrate on those that would otherwise have been DISCUSS points. >> (But that's your call, I don't mind.) I think the 19 >> would-have-been-discuss points is another clue that this ought >> really be sent back to the WG. >>=20 >> And with that, and with apologies for this being such an overall=20 >> negative review, here're my detailed comments: >>=20 >> - general: The writing here is generally poor, for example the >> opener is "This presents..." whereas it ought be "This document >> presents..." (or s/document/whatever you prefer/). Such issues are >> repeatedly seen and all that makes this a much harder read than >> ought be the case. I'd strongly recommend an editorial pass from >> someone who hasn't been down in the weeds with this text for a >> while (which could be one of the authors, if one of them has been >> less active recently.) Note that this is not only (but is >> primarily) an editorial issue - there are some cases (hopefully >> called out below) where the writing does create real ambiguity that >> might lead to re-opening old arguments later. >>=20 >> - abstract: "mutual authentication, transport protocols, data=20 >> transfer and transactions" don't seem to me to be commensurate=20 >> things, so the abstract, as written is very uninformative for me. >>=20 >> - intro 3rd para: I'm really not sure what you're telling me about=20 >> [I-D.ietf-i2rs-ephemeral-state]. "The draft [RFC7922]" is odd, >> that being no longer a draft. I'd have expected such nits would >> have been fixed by now TBH. Same for the last sentence. That para >> makes the intro pretty unclear for me. >>=20 >> - 2.2: The definition of higher level protocol seems like an odd=20 >> place to introduce the fact that i2rs =3D=3D netconf + restconf. >> That'd be more usefully said in the abstract/intro if that's >> solidly agreed by the WG. >>=20 >> - 2.2: This is wrong: "While it is possible to have an I2RS >> operation which is contained in multiple I2RS (E.g. write in >> multiple messages), this is not supported in order to simplify the >> first version of I2RS." The reason this is wrong, is that it is >> here that you are defining that it is not possible to have an >> operation in multiple messages. s/it is/it could have been/ would >> work maybe. >>=20 >> - 2.2: " * The I2RS client issues a read request to a I2RS agent,=20 >> and the I2RS Agent responding to the read request" Shouldn't that >> use respond and not responding? Given that you seem to be trying >> to define the scope of what is and is not a transaction, I think >> being precise with the language is something well worth doing. The >> 2nd bullet could also do with a re-write. >>=20 >> (discuss1) 2.2: you sort-of define messages, operations, >> transactions and actions. None of the definitions are that precise, >> e.g. are those the only operations or examples? And transaction and >> action aren't really defined at all. I'm not sure if that's likely >> to be a problem or not. I suspect it will later, e.g. when you get >> to figuring out the scope within which replay needs to be >> detectable. >>=20 >> - 2.2: s/transation/transaction/ >>=20 >> (discuss2) - 2.2: "defines a secondary identity as the entity of >> some non-I2RS entity " That could be abused for tracking of various >> kinds I would guess, e.g. if an IMEI were used. I think you need to >> note that and should impose some requirements that such secondary=20 >> identifiers are not used thusly for tracking. Also, should the >> first occurrence of entity there be identity? >>=20 >> - 3, 1st para: s/The security for the/The/ - there isn't a thing=20 >> called the security for the i2rs protocol. >>=20 >> (discuss3) - section 3 says "the I2RS protocol requires mutually=20 >> authenticated I2RS clients and I2RS agents communicating over a=20 >> secure transport." To me that implies that something like TLS or >> SSH is MTU which seems to contradict recent emails. >>=20 >> - section 3 says: "The I2RS protocol MUST be able to provide=20 >> atomicity of an I2RS transaction, but it is not required to have=20 >> multi-message atomicity and roll-back mechanism transactions.=20 >> Multiple messages transactions may be impacted by the >> interdependency of data." I don't believe that that's easily >> enough understood to be useful. Also, wouldn't s/Multiple messages >> transactions/Multiple-message transactions/ be much clearer if >> that's what's meant? And finally, I think the MUST embedded in the >> above is not that great an idea - it's clearer IMO to separate the >> 2119 language from introductory text in documents like this. >>=20 >> - 3: "There are dependencies in some of the requirements below" >> would be better as "There are inter-dependencies between some of >> the requirements below" unless you mean dependencies on some >> external things, which is not clear from the text as-is. >>=20 >> (discuss4) " For confidentiality (section 3.3) and integrity >> (section 3.4) to be achieved, the client-agent must have mutual >> authentication (section 3.1) and secure transport (section 3.2). " >> This is incorrect. One can have confidentiality without >> authentication (see RFC7435) so the text is not accurate. >>=20 >> - capitalisation needs fixing in various places, e.g. around the >> end of p5, we get "secure Transport" and then "I2RS client" and >> "I2RS Agent" in the title of 3.1 Is any of that capitalisation >> supposed to be significant? Either way, fixing it now would be good >> as you'll need to get the RFC editor to do it later if you don't >> (which takes longer). >>=20 >> (discuss5) SEC-REQ-01: what is the scope of uniqueness required >> here? I see no reason why two different data centres cannot re-use >> a client or agent identifier, if they so wish. I'd be fine if you >> say that's for later decision, but being silent on the matter could >> lead to trouble later if different folks decide differently. >>=20 >> (discuss6) SEC-REQ-02: the "MUST utilize" there means MTU, which=20 >> wasn't what you wanted I think >>=20 >> (discuss7) - SEC-REQ-03: how is "upon receiving... MUST confirm" a=20 >> good choice? As stated that'd be hugely onerous, implying e.g. >> OCSP checks for each packet received. Same point applies to >> SEC-REQ-04. >>=20 >> (discuss8) - SEC-REQ-05: this either means nothing at all (being a=20 >> tautology) or else something I don't get. I think it's the former,=20 >> but am not sure. >>=20 >> - 3.1: s/One mechanism such mechanism/One such mechanism/ I guess.=20 >> And it's not at all clear to me "AAA protocols" is the right idea=20 >> there, and nor is it clear what's meant, with the text as-is. >>=20 >> - SEC-REQ-06: where is a "priority" defined? >>=20 >> - SEC-REQ-07: here you say read/write is a transaction, but >> earlier you said it was an operation, which is it? >>=20 >> (discuss9) 3.2: As with others, I don't think the idea of >> annotating parts of yang modules with "can be insecure" is a good >> one. There's a separate thread discussing that though, so maybe >> better to not fork that. >>=20 >> (discuss10) - SEC-REQ-O9: I hate to do this to ya, but BCP107 is >> IMO a fairly clear failure when it comes to routing. And yet again >> the exceptions clauses here are so broad as to be meaningless >> (e.g. considered low value by whom?). What is the real goal here? >> (other than an attempt to keep the sec ADs from being annoying and >> trying to insist on BCP107? ;-) >>=20 >> (discuss11) - SEC-REQ-09: Separately, to my other would-be-discuss=20 >> point on this requirement, "can guarantee" is well beyond the >> state of the art in key management. I'd just drop that sentence >> maybe, but can't make a concrete suggestion until I understand >> where you want to be wrt BCP107. >>=20 >> - SEC-REQ-10: the last sentence here is also involved in the "may >> do stuff insecurely" thing, and so will likely need fixing when >> that is fully resolved. >>=20 >> - How is SEC-REQ-11 useful? What protocol artefacts do you have in=20 >> mind here? Perhaps a requirement that DDoS attacks be specifically=20 >> considered in I2RS would be more useful. >>=20 >> - SEC-REQ-12: This seems to me to have too many words, e.g. the=20 >> current text could be read to imply that outside of critical=20 >> infrastructure there is less or no need for confidentiality, so >> those added words (presumably there to motivate) might be=20 >> counter-productive. >>=20 >> (discuss12) SEC-REQ-12: I don't get the meaning of the SHOULD here >> - combined with "certain data" that SHOULD seems to end up meaning >> MAY, as in, it seems to mean the same as "Read/write operations MAY >> have to be protected using a confidentiality service." >>=20 >> - 3.4, bullet (2) here means that we're not talking about data=20 >> integrity but data origin authentication as well. >>=20 >> (discuss13) 3.4, (3): Within what scope must replay be detected? >> The text implies for ever, which can be very onerous. SEC-REQ-14 >> doesn't quite go so far, but is ambiguous on this aspect. I'd say >> best is to note that the scope within which replay needs to be >> detectable is for future study. >>=20 >> (discuss14) SEC-REQ-15: Sorry, I don't understand what's required=20 >> here (having read this >1 time). Can you explain? I'm not sure if=20 >> any substantive change is needed, but there are certainly >> editorial changes needed for sure as there are multiple wording >> problems with the text as-is. >>=20 >> - 3.5, 1st para: the text here is not as good as the actual=20 >> definition of "role" in RFC7921, and in fact I found the text here=20 >> confusing. Better to just delete that and say that 7921 defines=20 >> roles. >>=20 >> (discuss15) SEC-REQ-16: I don't see any content in this text as it=20 >> seems to just say "some role based access control and some level >> of transport protection need to be provided" which is always true, >> as you are allowing "no transport security" and (I assume) "fully=20 >> public access" so any protocol/system will always meet this=20 >> requirement. >>=20 >> - SEC-REQ-16: "privacy requirements" here is wrong, you mean=20 >> confidentiality I think. >>=20 >> (discuss16) SEC-REQ-17: "MUST work" is far too vague. That could >> for example hide a major debate about push v. pull of role >> information. If the WG haven't considered that, I think you could >> ack that again by saying that more work is needed to define how >> RBAC is consistent across multiple transport layer connections. >>=20 >> (discuss17) SEC-REQ-18: again this seems to have no content, other=20 >> than perhaps imposing an odd requirement on implementations - I >> don't see a protocol requirement here at all. It is reasonable to >> note that libraries for clients ought not assume a single client >> identity but even that's very specific to library implementations >> and since it's just a MAY that's entirely obvious, I'd leave it >> out. >>=20 >> (discuss18) SEC-REQ-19: I fully agree with the motivation here but >> I think the stated requirement is broken. For example, I don't >> know how a piece of s/w will determine whether or not it is >> correlated with a person. I also don't think a SHOULD works here, >> as again something would need to be stated about the situations >> when the feature is not needed, and I can't figure out a sensible >> statement for that. The last sentence also seems likely not useful. >> All in all, I think this is likely to be ignored or even worse >> treated like a piece of fig-leaf specification text to pretend that >> we're caring about privacy. >>=20 >> (discuss19) - 3.6: I have no idea whether this other draft is=20 >> supposed to be considered as setting requirements or not. I assume=20 >> that the answer is "not" as you've made it an informative >> reference, but in that case you really should say that. The >> alternative would be that 3.6 is essentially specifying an >> applicability statement for the environments in which it is, and is >> not, ok to run i2rs. If the latter were intended, then you'd need >> to say it and make the draft a normative reference. >>=20 >>=20 >> _______________________________________________ i2rs mailing list=20 >> i2rs@ietf.org https://www.ietf.org/mailman/listinfo/i2rs >>=20 >=20 --------------ms010600000401040204010306 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CvIwggUIMIID8KADAgECAhBPzaE7pzYviUJyhmHTFBdnMA0GCSqGSIb3DQEBCwUAMHUxCzAJ BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGll bnQgQ0EwHhcNMTYwMjA5MDkyODE1WhcNMTcwMjA5MDkyODE1WjBOMSIwIAYDVQQDDBlzdGVw aGVuLmZhcnJlbGxAY3MudGNkLmllMSgwJgYJKoZIhvcNAQkBFhlzdGVwaGVuLmZhcnJlbGxA Y3MudGNkLmllMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtuC0rYze/2JinSra C9F2RjGdQZjNALLcW9C3WKTwYII3wBslobmHuPEYE5JaGItmzuKnAW619R1rD/kfoNWC19N3 rBZ6UX9Cmb9D9exCwYIwVuSwjrCQWGxgCtNQTrwKzCCpI790GRiMTvxvO7UmzmBrCaBLiZW5 R0fBjK5Yn6hUhAzGBkNbkIEL28cLJqH0yVz7Kl92OlzrQqTPEts5m6cDnNdY/ADfeAX18c1r dxZqcAxhLotrCqgsVA4ilbQDMMXGTLlB5TP35HeWZuGBU7xu003rLcFLdOkD8xvpJoYZy9Kt 3oABXPS5yqtMK+XCNdqmMn+4mOtLwQSMmPCSiQIDAQABo4IBuTCCAbUwCwYDVR0PBAQDAgSw MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAJBgNVHRMEAjAAMB0GA1UdDgQWBBQJ QhvwQ5Fl372Z6xqo6fdn8XejTTAfBgNVHSMEGDAWgBQkgWw5Yb5JD4+3G0YrySi1J0htaDBv BggrBgEFBQcBAQRjMGEwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbTA5 BggrBgEFBQcwAoYtaHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc2NhLmNsaWVudDEu Y3J0MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3NjYS1jbGll bnQxLmNybDAkBgNVHREEHTAbgRlzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllMCMGA1UdEgQc MBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzBGBgNVHSAEPzA9MDsGCysGAQQBgbU3AQIE MCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeTANBgkqhkiG 9w0BAQsFAAOCAQEArzrSv2C8PlBBmGuiGrzm2Wma46/KHtXmZYS0bsd43pM66Pc/MsqPE0HD C1GzMFfwB6BfkJn8ijNSIhlgj898WzjvnpM/SO8KStjlB8719ig/xKISrOl5mX55XbFlQtX9 U6MrqRgbDIATxhD9IDr+ryvovDzChqgQj7mt2jYr4mdlRjsjod3H1VY6XglRmaaNGZfsCARM aE/TU5SXIiqauwt5KxNGYAY67QkOBs7O1FkSXpTk7+1MmzJMF4nP8QQ5n8vhVNseF+/Wm7ai 9mtnrkLbaznMsy/ULo/C2yuLUWTbZZbf4EKNmVdme6tUDgYkFjAFOblfA7W1fSPiQGagYzCC BeIwggPKoAMCAQICEGunin0K14jWUQr5WeTntOEwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5MB4XDTE1MTIxNjAxMDAwNVoXDTMwMTIxNjAxMDAwNVowdTELMAkGA1UEBhMC SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL192vfDon2D9luC/dtbX64eG3XAtRmv mCSsu1d52DXsCR58zJQbCtB2/A5uFqNxWacpXGGtTCRk9dEDBlmixEd8QiLkUfvHpJX/xKnm VkS6Iye8wUbYzMsDzgnpazlPg19dnSqfhM+Cevdfa89VLnUztRr2cgmCfyO9Otrh7LJDPG+4 D8ZnAqDtVB8MKYJL6QgKyVhhaBc4y3bGWxKyXEtx7QIZZGxPwSkzK3WIN+VKNdkiwTubW5PI dopmykwvIjLPqbJK7yPwFZYekKE015OsW6FV+s4DIM8UlVS8pkIsoGGJtMuWjLL4tq2hYQuu N0jhrxK1ljz50hH23gA9cbMCAwEAAaOCAWQwggFgMA4GA1UdDwEB/wQEAwIBBjAdBgNVHSUE FjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIBADAyBgNVHR8EKzAp MCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwZgYIKwYBBQUHAQEE WjBYMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5zdGFydHNzbC5jb20wMAYIKwYBBQUHMAKG JGh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL2NhLmNydDAdBgNVHQ4EFgQUJIFsOWG+ SQ+PtxtGK8kotSdIbWgwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwPwYDVR0g BDgwNjA0BgRVHSAAMCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Bv bGljeTANBgkqhkiG9w0BAQsFAAOCAgEAi+P3h+wBi4StDwECW5zhIycjBL008HACblIf26HY 0JdOruKbrWDsXUsiI0j/7Crft9S5oxvPiDtVqspBOB/y5uzSns1lZwh7sG96bYBZpcGzGxpF NjDmQbcM3yl3WFIRS4WhNrsOY14V7y2IrUGsvetsD+bjyOngCIVeC/GmsmtbuLOzJ606tEc9 uRbhjTu/b0x2Fo+/e7UkQvKzNeo7OMhijixaULyINBfCBJb+e29bLafgu6JqjOUJ9eXXj20p 6q/CW+uVrZiSW57+q5an2P2i7hP85jQJcy5j4HzA0rSiF3YPhKGAWUxKPMAVGgcYoXzWydOv Z3UDsTDTagXpRDIKQLZo02wrlxY6iMFqvlzsemVf1odhQJmi7Eh5TbxI40kDGcBOBHhwnaOu mZhLP+SWJQnjpLpSlUOj95uf1zo9oz9e0NgIJoz/tdfrBzez76xtDsK0KfUDHt1/q59BvDI7 RX6gVr0fQoCyMczNzCTcRXYHY0tq2J0oT+bsb6sH2b4WVWAiJKnSYaWDjdA70qHX4mq9MIjO /ZskmSY8wtAk24orAc0vwXgYanqNsBX5Yv4sN4Z9VyrwMdLcusP7HJgRdAGKpkR2I9U4zEsN JQJewM7S4Jalo1DyPrLpL2nTET8ZrSl5Utp1UeGp/2deoprGevfnxWB+vHNQiu85o6MxggPM MIIDyAIBATCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcG A1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0 Q29tIENsYXNzIDEgQ2xpZW50IENBAhBPzaE7pzYviUJyhmHTFBdnMA0GCWCGSAFlAwQCAQUA oIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjA4MjEy MzIzMzlaMC8GCSqGSIb3DQEJBDEiBCDxWg+8zsB4HhYSD2li4bBut+j9EGtOTSIvqhuen57+ iTBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzCB nAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYD VQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzANBgkq hkiG9w0BAQEFAASCAQB4VLZM5laeO+dwkTc+D4+b5qjU6PZGrS4qN1beOAeyc/0sqeWcHksw UaiFwXBEYXOyaVzAf6tdMsJMsDW6X0zO9LGDqbLyo9Tks1PqHu5Op0/L/COP30PSGr8vLSKj IZ5SzU1dBjlhWGv8DKMLkvTKuSQcP11meoSVbZfuFae0oM+UOLDVbWQtbWKfKN595H7OLd4Z lMD9rAIk+yGvBGhad7tWcezT8bgdHqoOGOQdmVD6mT54MlIEbMgNgg7OIxSCQnEMIUXZweHs ccwQJ2hjqYI6kdZ7nV1Ccst1bBk+7w3RFxC5MxHXGt01HFHFCabRzqqrMU6e1FFtZUlFk2HH AAAAAAAA --------------ms010600000401040204010306-- From nobody Mon Aug 22 05:32:31 2016 Return-Path: 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 0FC0712D18B; Mon, 22 Aug 2016 05:32:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.749 X-Spam-Level: * X-Spam-Status: No, score=1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, RCVD_IN_MSPIKE_BL=0.01, RCVD_IN_MSPIKE_L5=0.001, RDNS_NONE=0.793] autolearn=no 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 O6BX2HeZ7WvV; Mon, 22 Aug 2016 05:32:21 -0700 (PDT) Received: from hickoryhill-consulting.com (unknown [50.245.122.97]) (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 D7C1E127077; Mon, 22 Aug 2016 05:32:20 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=74.43.47.166; From: "Susan Hares" To: "'Stephen Farrell'" , "'The IESG'" References: In-Reply-To: Date: Mon, 22 Aug 2016 08:30:32 -0400 Message-ID: <03db01d1fc71$0ee24970$2ca6dc50$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQKMFfnez03laf+daehODFfYigiIegG//9YpntK1y7A= Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: jhaas@pfrc.org, i2rs@ietf.org, i2rs-chairs@ietf.org, draft-ietf-i2rs-protocol-security-requirements@ietf.org Subject: Re: [i2rs] Stephen Farrell's Abstain on draft-ietf-i2rs-protocol-security-requirements-09: (with COMMENT) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Aug 2016 12:32:24 -0000 Stephen:=20 Thank you for your note. You do not have to respond then to the = questions. I will check with Alia this morning to see what she wants = to do.=20 Sue=20 -----Original Message----- From: Stephen Farrell [mailto:stephen.farrell@cs.tcd.ie]=20 Sent: Sunday, August 21, 2016 7:24 PM To: Susan Hares; The IESG Cc: jhaas@pfrc.org; i2rs@ietf.org; i2rs-chairs@ietf.org; = draft-ietf-i2rs-protocol-security-requirements@ietf.org Subject: Re: [i2rs] Stephen Farrell's Abstain on = draft-ietf-i2rs-protocol-security-requirements-09: (with COMMENT) Hiya, On 21/08/16 22:57, Susan Hares wrote: > Stephen: Thank you for the explanations. Iterative edits do impact > on the style.=20 Well, yes, but it is not just a matter of style, when there are so many non-sentences. > While you denote the concern as pervasive monitoring, Not just I - the IETF adopted that term in BCP188. > in my mind it is better to consider the effort as ensuring pervasive > privacy for individuals and groups utilizing the Internet. (Having > worked with survivors of domestic abuse and sexual abuse, I cheer > IETF effort on pervasive monitoring.) My focus and the reason I asked > about the security directorate reviews - is that it is important to > fix problems early in the process. =20 If you really want my opinion on process here - I think that the process the WG are following to document requirements in RFCs is where the problem lies. That causes us all to want to ensure that the text documenting the agreed requirements is sufficient precise for us all, whereas that level of precision (of the text) is not really required for most requirements in order to pursue the work. > When I come to an unexpected > failing grade for a document,=20 Again, I do not agree with the concept that there is any such failing grade. We (the IETF) ought consider that it's a normal part of the process that work has to go back a step or two now and then in order to be done as well as we need it to be done. If the end result of this IESG evaluation is that this document ends up back with the WG, then I would hope that that leads to an overall better outcome. If OTOH, the document still moves ahead, then I am not insisting on being a blocking factor as I have balloted abstain. > I try to address both the document and > the process in order to improve. I expected the process of getting a > security directorate reviews would detect problems sooner.=20 I think it did detect some problems. Did it identify all problems? No. And one ought not expect that from any volunteer-lead review process. One ought also not expect that an early secdir review will focus on the precise words used, as those will change before the work is done. And many of my comments on this relate to (im)precision in the words used. > So I am > asking what happened in the security directorate reviews that caused > them to miss your concerns? Did miss something in their comments?=20 See above. It's entirely normal that reviews do not involve a constant level of effort, nor produce a predictable outcome. > My next question is what do you expect from a protocol security > document? Do you have a checklist?=20 I don't think it's reasonable to ask an AD what they consider a perfect document, nor for a checklist. (And the document in question is not a "protocol security" specification but a requirements specification, which is a different beast entirely.) > On the next steps, I responded up > through your ~discuss-criteria.html comment 5. If you have time to > answer just my qustions on the 5 discuss Qs - it will help my > discussion with Alia.=20 I will look tomorrow. But to be honest, it would really help me if it were possible for your email to use normal email quoting. (Your mail seems to not do that - "who said what" may be nicely visible in your mail UA but in my very basic one it's very hard to pick out what you and what I wrote.) But I can manage with what you sent if it's hard to do it with normal quoting. (FWIW, I suspect the form of quoting you used has lead other discussions on this draft to be more prolonged that would otherwise have been the case - at least that's a pattern I think I see over many discussions and in this one too.) Cheers, S. > SueSue >=20 > Sent via the Samsung Galaxy Note5, an AT&T 4G LTE smartphone -------- > Original message --------From: Stephen Farrell > Date: 8/21/16 3:41 PM (GMT-05:00) To: > Susan Hares , The IESG Cc: > jhaas@pfrc.org, i2rs@ietf.org, i2rs-chairs@ietf.org, > draft-ietf-i2rs-protocol-security-requirements@ietf.org Subject: Re: > [i2rs] Stephen Farrell's Abstain on > draft-ietf-i2rs-protocol-security-requirements-09: (with COMMENT) >=20 > Hiya, >=20 > On 21/08/16 20:10, Susan Hares wrote: >> Stephen: Thank you for leaving your vacation early to do this >> review. It is one of the most negative viewpoint I have read from >> you, and since have read many of your DISCUSS comments since you >> became an AD >=20 > Well, I've done far more negative reviews, but this one has a lot of > smaller negative comments. My guess is quite a lot of that is down to > a) it's very very hard to write protocol requirements text crisply=20 > and accurately, and b) that kind of text is very very easily messed > up when doing iterative edits in response to reviews, and c) the > writing is really not that good in this version - to the point where > the accumulation of nits itself becomes a notable issue, and where > it's likely past time that an editorial pass was done to get that out > of the way. >=20 >> - I think this gives me unique perspective. This is far from the=20 >> early comments you sent 2 weeks ago. >=20 > No. I would not have asked for a defer if I thought the only concern=20 > was the possibility of this resulting in a hard-to-deploy set of=20 > security mechanisms - I would have just balloted that. It is the > case that that's all I said before I had properly read the document > though, yes. And it wasn't 2 weeks ago:-) >=20 >> In developing this document and I2RS technology the I2RS WG and I >> as the I2RS chair have request reviews from the Security >> directorate. We delayed out first revisions to try to address >> security issue by adding this document and the security environment >> document. We have had early and late reviews. Since the initial >> review on the I2RS architecture we have discussed the non-secure >> interface and tried to get security directorate's review. >=20 > I have looked back at the secdir mails on this, yes. >=20 >> I raised the pervasive privacy issue and asked for input in your >> review. >=20 > Yes. And I responded with two would-have-been-discuss points related=20 > to pervasive monitoring. (I assume that what's you mean when you say=20 > "pervasive privacy" but if you mean something else above, please do=20 > clarify.) >=20 >> This meta-comment is that process of asking for aid ahead of this >> point has failed according to your review, >=20 > I think that's an odd view of IETF processes, which are never > expected to produce perfection at any stage. IMO we're iterating > towards better outcomes, not failing/succeeding at each stage of the > process. >=20 >> but I cannot find a point where the I2RS WG did not solicit the >> security area's aid and take its advice. Therefore, I must ask >> you to check the process of your security directorate's reviews to >> find what happened to cause such a failure. >=20 > Don't think of it as failure, think of it as more eyeballs finding > more things. (Or repeating things already considered, for those where > that's the case.) >=20 >> Now as to the document, I have a WG waiting for these requirements. >>=20 >=20 > I'd encourage you to question the above, as a first order goal. Are=20 > the WG really waiting on these in a final, fixed-forever, form? Or do > you need a general agreement as to direction and can then make=20 > progress? (And perhaps reduce the final requirements to RFC status=20 > later if there's value in that, which there can be.) >=20 > As I noted a couple of times in my review, it's not possible to be=20 > that precise about some requirements without having done more of the=20 > design. (One of the traditional waterfalll design problems I guess.)=20 > The scope of replay detection is probably a good example. >=20 >> I would like to hear in a completely separate email thread what >> kernel of information you would have expected regarding the >> security first an i2rs protocol. >=20 > I don't understand your question sorry. >=20 >> I would then like to compare this against the security >> directorate's suggestions on this document. We have a second >> document on the security environment so your insights will be >> applied to that document. Since in the general text you indicate >> the style is terrible and needs to be written, please provide an >> example of a document as an example of the style. >=20 > Really? The accumulation of badly written sentences in -09 has got to > be a clear enough problem that you don't need an example of what is > not-that. So I'm puzzled at the request. >=20 >> My understanding is that style is a lower priority than technical >> correctness and consensus. >=20 > Correct/good-enough writing is certainly secondary, up until the=20 > issues get to a certain point that impinges on the reader's ability=20 > to asses the meaning, and that happens a couple of times in this=20 > document. (As I said in my review.) The other writing issues make=20 > this a harder read than ought be the case. That doesn't reach the=20 > level of making the document unreadable, nor nearly get that bad, but > it is enough that I wonder if other readers may have been put off by > that in reading some of the text. >=20 >> This email ends my comments on your summary message. The next set >> of comments will take your discuss comments one at a time. The >> exact next steps that I and my co-author will take will be guided >> by the AD responsible for the I2RS WG, >=20 > That's all good. >=20 > I would re-iterate though, that since my ballot is an abstain > there's no onus on you or the WG to respond in any more detail than > you feel is useful. >=20 > Cheers, S. >=20 >> Alia. Cheerily, Sue Hares >>=20 >> Sent via the Samsung Galaxy Note5, an AT&T 4G LTE smartphone >> -------- Original message --------From: Stephen Farrell=20 >> Date: 8/21/16 8:37 AM (GMT-05:00) >> To: The IESG Cc: jhaas@pfrc.org, i2rs@ietf.org,=20 >> i2rs-chairs@ietf.org,=20 >> draft-ietf-i2rs-protocol-security-requirements@ietf.org Subject:=20 >> [i2rs] Stephen Farrell's Abstain on=20 >> draft-ietf-i2rs-protocol-security-requirements-09: (with COMMENT)=20 >> Stephen Farrell has entered the following ballot position for=20 >> draft-ietf-i2rs-protocol-security-requirements-09: Abstain >>=20 >> When responding, please keep the subject line intact and reply to=20 >> all email addresses included in the To and CC lines. (Feel free to=20 >> cut this introductory paragraph, however.) >>=20 >>=20 >> Please refer to=20 >> https://www.ietf.org/iesg/statement/discuss-criteria.html for more=20 >> information about IESG DISCUSS and COMMENT positions. >>=20 >>=20 >> The document, along with other ballot positions, can be found here: >> =20 >> = https://datatracker.ietf.org/doc/draft-ietf-i2rs-protocol-security-requir= ements/ >> >> >> >> >> >>=20 ---------------------------------------------------------------------- >>=20 >>=20 > COMMENT: >> = ---------------------------------------------------------------------- >> >> >> >> >>=20 First, apologies for not getting my review done for this when it was >> scheduled due to my vacation and thanks for being willing to defer=20 >> the document. >>=20 >> Second, having now properly reviewed this, I am balloting abstain >> as I think it's unlikely that this document can be fixed in a way >> that results in something useful happening. I think that the likely >> outcome is that this document will be used later when people are=20 >> arguing and will not much help in resolving those arguments, or >> else this will be ignored and arguments will be held afresh, as >> needed. That latter outcome is what I'd guess is most likely and >> therefore it seems that spending all of our cycles on DISCUSS >> ballot processing for this would not be wise. That said, I am >> willing to change to a DISCUSS ballot if the responsible AD prefers >> that, but I suspect I'll end up with an abstain in any case, after >> some discussion. The only plan I can think of that'd lead to me >> ending up with a yes or no-objection ballot would be if this was >> returned to the WG for fixing and possibly major surgery, which is >> what I actually think would be the best plan. (I realise this has >> had a somewhat tortured history, so folks may not be willing to >> take it back to the WG, but honestly, I think the failings visible >> in this document do indicate that this is not ready for approval >> and ought be returned to the WG.) >>=20 >> Third, I think the overall set of requirements posed here might >> (with some unknown probability) lead to later specifications that >> are considered too hard to deploy, with the result that non-secure=20 >> variants of I2RS become the norm. That seems like it would be a=20 >> really bad outcome. I would suggest that might be partly mitigated >> if a requirement were added to the effect that deployment issues >> and specifically ease of deployment MUST be considered as a first >> order requirement when developing I2RS protocol solutions. >>=20 >> Fourth, the (19!) comments below that are preceded by "(discuss"=20 >> would have been DISCUSS ballot points had I not decided to abstain. >> I am happy to chat about any of my comments below, but if the=20 >> authors/WG do want to chat, it might be more efficient to >> concentrate on those that would otherwise have been DISCUSS points. >> (But that's your call, I don't mind.) I think the 19 >> would-have-been-discuss points is another clue that this ought >> really be sent back to the WG. >>=20 >> And with that, and with apologies for this being such an overall=20 >> negative review, here're my detailed comments: >>=20 >> - general: The writing here is generally poor, for example the >> opener is "This presents..." whereas it ought be "This document >> presents..." (or s/document/whatever you prefer/). Such issues are >> repeatedly seen and all that makes this a much harder read than >> ought be the case. I'd strongly recommend an editorial pass from >> someone who hasn't been down in the weeds with this text for a >> while (which could be one of the authors, if one of them has been >> less active recently.) Note that this is not only (but is >> primarily) an editorial issue - there are some cases (hopefully >> called out below) where the writing does create real ambiguity that >> might lead to re-opening old arguments later. >>=20 >> - abstract: "mutual authentication, transport protocols, data=20 >> transfer and transactions" don't seem to me to be commensurate=20 >> things, so the abstract, as written is very uninformative for me. >>=20 >> - intro 3rd para: I'm really not sure what you're telling me about=20 >> [I-D.ietf-i2rs-ephemeral-state]. "The draft [RFC7922]" is odd, >> that being no longer a draft. I'd have expected such nits would >> have been fixed by now TBH. Same for the last sentence. That para >> makes the intro pretty unclear for me. >>=20 >> - 2.2: The definition of higher level protocol seems like an odd=20 >> place to introduce the fact that i2rs =3D=3D netconf + restconf. >> That'd be more usefully said in the abstract/intro if that's >> solidly agreed by the WG. >>=20 >> - 2.2: This is wrong: "While it is possible to have an I2RS >> operation which is contained in multiple I2RS (E.g. write in >> multiple messages), this is not supported in order to simplify the >> first version of I2RS." The reason this is wrong, is that it is >> here that you are defining that it is not possible to have an >> operation in multiple messages. s/it is/it could have been/ would >> work maybe. >>=20 >> - 2.2: " * The I2RS client issues a read request to a I2RS agent,=20 >> and the I2RS Agent responding to the read request" Shouldn't that >> use respond and not responding? Given that you seem to be trying >> to define the scope of what is and is not a transaction, I think >> being precise with the language is something well worth doing. The >> 2nd bullet could also do with a re-write. >>=20 >> (discuss1) 2.2: you sort-of define messages, operations, >> transactions and actions. None of the definitions are that precise, >> e.g. are those the only operations or examples? And transaction and >> action aren't really defined at all. I'm not sure if that's likely >> to be a problem or not. I suspect it will later, e.g. when you get >> to figuring out the scope within which replay needs to be >> detectable. >>=20 >> - 2.2: s/transation/transaction/ >>=20 >> (discuss2) - 2.2: "defines a secondary identity as the entity of >> some non-I2RS entity " That could be abused for tracking of various >> kinds I would guess, e.g. if an IMEI were used. I think you need to >> note that and should impose some requirements that such secondary=20 >> identifiers are not used thusly for tracking. Also, should the >> first occurrence of entity there be identity? >>=20 >> - 3, 1st para: s/The security for the/The/ - there isn't a thing=20 >> called the security for the i2rs protocol. >>=20 >> (discuss3) - section 3 says "the I2RS protocol requires mutually=20 >> authenticated I2RS clients and I2RS agents communicating over a=20 >> secure transport." To me that implies that something like TLS or >> SSH is MTU which seems to contradict recent emails. >>=20 >> - section 3 says: "The I2RS protocol MUST be able to provide=20 >> atomicity of an I2RS transaction, but it is not required to have=20 >> multi-message atomicity and roll-back mechanism transactions.=20 >> Multiple messages transactions may be impacted by the >> interdependency of data." I don't believe that that's easily >> enough understood to be useful. Also, wouldn't s/Multiple messages >> transactions/Multiple-message transactions/ be much clearer if >> that's what's meant? And finally, I think the MUST embedded in the >> above is not that great an idea - it's clearer IMO to separate the >> 2119 language from introductory text in documents like this. >>=20 >> - 3: "There are dependencies in some of the requirements below" >> would be better as "There are inter-dependencies between some of >> the requirements below" unless you mean dependencies on some >> external things, which is not clear from the text as-is. >>=20 >> (discuss4) " For confidentiality (section 3.3) and integrity >> (section 3.4) to be achieved, the client-agent must have mutual >> authentication (section 3.1) and secure transport (section 3.2). " >> This is incorrect. One can have confidentiality without >> authentication (see RFC7435) so the text is not accurate. >>=20 >> - capitalisation needs fixing in various places, e.g. around the >> end of p5, we get "secure Transport" and then "I2RS client" and >> "I2RS Agent" in the title of 3.1 Is any of that capitalisation >> supposed to be significant? Either way, fixing it now would be good >> as you'll need to get the RFC editor to do it later if you don't >> (which takes longer). >>=20 >> (discuss5) SEC-REQ-01: what is the scope of uniqueness required >> here? I see no reason why two different data centres cannot re-use >> a client or agent identifier, if they so wish. I'd be fine if you >> say that's for later decision, but being silent on the matter could >> lead to trouble later if different folks decide differently. >>=20 >> (discuss6) SEC-REQ-02: the "MUST utilize" there means MTU, which=20 >> wasn't what you wanted I think >>=20 >> (discuss7) - SEC-REQ-03: how is "upon receiving... MUST confirm" a=20 >> good choice? As stated that'd be hugely onerous, implying e.g. >> OCSP checks for each packet received. Same point applies to >> SEC-REQ-04. >>=20 >> (discuss8) - SEC-REQ-05: this either means nothing at all (being a=20 >> tautology) or else something I don't get. I think it's the former,=20 >> but am not sure. >>=20 >> - 3.1: s/One mechanism such mechanism/One such mechanism/ I guess.=20 >> And it's not at all clear to me "AAA protocols" is the right idea=20 >> there, and nor is it clear what's meant, with the text as-is. >>=20 >> - SEC-REQ-06: where is a "priority" defined? >>=20 >> - SEC-REQ-07: here you say read/write is a transaction, but >> earlier you said it was an operation, which is it? >>=20 >> (discuss9) 3.2: As with others, I don't think the idea of >> annotating parts of yang modules with "can be insecure" is a good >> one. There's a separate thread discussing that though, so maybe >> better to not fork that. >>=20 >> (discuss10) - SEC-REQ-O9: I hate to do this to ya, but BCP107 is >> IMO a fairly clear failure when it comes to routing. And yet again >> the exceptions clauses here are so broad as to be meaningless >> (e.g. considered low value by whom?). What is the real goal here? >> (other than an attempt to keep the sec ADs from being annoying and >> trying to insist on BCP107? ;-) >>=20 >> (discuss11) - SEC-REQ-09: Separately, to my other would-be-discuss=20 >> point on this requirement, "can guarantee" is well beyond the >> state of the art in key management. I'd just drop that sentence >> maybe, but can't make a concrete suggestion until I understand >> where you want to be wrt BCP107. >>=20 >> - SEC-REQ-10: the last sentence here is also involved in the "may >> do stuff insecurely" thing, and so will likely need fixing when >> that is fully resolved. >>=20 >> - How is SEC-REQ-11 useful? What protocol artefacts do you have in=20 >> mind here? Perhaps a requirement that DDoS attacks be specifically=20 >> considered in I2RS would be more useful. >>=20 >> - SEC-REQ-12: This seems to me to have too many words, e.g. the=20 >> current text could be read to imply that outside of critical=20 >> infrastructure there is less or no need for confidentiality, so >> those added words (presumably there to motivate) might be=20 >> counter-productive. >>=20 >> (discuss12) SEC-REQ-12: I don't get the meaning of the SHOULD here >> - combined with "certain data" that SHOULD seems to end up meaning >> MAY, as in, it seems to mean the same as "Read/write operations MAY >> have to be protected using a confidentiality service." >>=20 >> - 3.4, bullet (2) here means that we're not talking about data=20 >> integrity but data origin authentication as well. >>=20 >> (discuss13) 3.4, (3): Within what scope must replay be detected? >> The text implies for ever, which can be very onerous. SEC-REQ-14 >> doesn't quite go so far, but is ambiguous on this aspect. I'd say >> best is to note that the scope within which replay needs to be >> detectable is for future study. >>=20 >> (discuss14) SEC-REQ-15: Sorry, I don't understand what's required=20 >> here (having read this >1 time). Can you explain? I'm not sure if=20 >> any substantive change is needed, but there are certainly >> editorial changes needed for sure as there are multiple wording >> problems with the text as-is. >>=20 >> - 3.5, 1st para: the text here is not as good as the actual=20 >> definition of "role" in RFC7921, and in fact I found the text here=20 >> confusing. Better to just delete that and say that 7921 defines=20 >> roles. >>=20 >> (discuss15) SEC-REQ-16: I don't see any content in this text as it=20 >> seems to just say "some role based access control and some level >> of transport protection need to be provided" which is always true, >> as you are allowing "no transport security" and (I assume) "fully=20 >> public access" so any protocol/system will always meet this=20 >> requirement. >>=20 >> - SEC-REQ-16: "privacy requirements" here is wrong, you mean=20 >> confidentiality I think. >>=20 >> (discuss16) SEC-REQ-17: "MUST work" is far too vague. That could >> for example hide a major debate about push v. pull of role >> information. If the WG haven't considered that, I think you could >> ack that again by saying that more work is needed to define how >> RBAC is consistent across multiple transport layer connections. >>=20 >> (discuss17) SEC-REQ-18: again this seems to have no content, other=20 >> than perhaps imposing an odd requirement on implementations - I >> don't see a protocol requirement here at all. It is reasonable to >> note that libraries for clients ought not assume a single client >> identity but even that's very specific to library implementations >> and since it's just a MAY that's entirely obvious, I'd leave it >> out. >>=20 >> (discuss18) SEC-REQ-19: I fully agree with the motivation here but >> I think the stated requirement is broken. For example, I don't >> know how a piece of s/w will determine whether or not it is >> correlated with a person. I also don't think a SHOULD works here, >> as again something would need to be stated about the situations >> when the feature is not needed, and I can't figure out a sensible >> statement for that. The last sentence also seems likely not useful. >> All in all, I think this is likely to be ignored or even worse >> treated like a piece of fig-leaf specification text to pretend that >> we're caring about privacy. >>=20 >> (discuss19) - 3.6: I have no idea whether this other draft is=20 >> supposed to be considered as setting requirements or not. I assume=20 >> that the answer is "not" as you've made it an informative >> reference, but in that case you really should say that. The >> alternative would be that 3.6 is essentially specifying an >> applicability statement for the environments in which it is, and is >> not, ok to run i2rs. If the latter were intended, then you'd need >> to say it and make the draft a normative reference. >>=20 >>=20 >> _______________________________________________ i2rs mailing list=20 >> i2rs@ietf.org https://www.ietf.org/mailman/listinfo/i2rs >>=20 >=20 From nobody Mon Aug 22 06:09:05 2016 Return-Path: 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 F0FEC12D0B3; Mon, 22 Aug 2016 03:08:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.748 X-Spam-Level: X-Spam-Status: No, score=-4.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.548] 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 GV_oddqkNlgc; Mon, 22 Aug 2016 03:08:01 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6CA5C12D096; Mon, 22 Aug 2016 03:08:01 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 58EB080E; Mon, 22 Aug 2016 12:07:59 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.205]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id kp0_ZRI8Fmbj; Mon, 22 Aug 2016 12:07:43 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Mon, 22 Aug 2016 12:07:44 +0200 (CEST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id EC74D200A8; Mon, 22 Aug 2016 12:07:43 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id mXqSf1Mg0yEV; Mon, 22 Aug 2016 12:07:42 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id D5B3E200AB; Mon, 22 Aug 2016 12:07:40 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id D95603C2A981; Mon, 22 Aug 2016 12:07:38 +0200 (CEST) Date: Mon, 22 Aug 2016 12:07:38 +0200 From: Juergen Schoenwaelder To: Susan Hares Message-ID: <20160822100738.GA12248@elstar.local> Mail-Followup-To: Susan Hares , '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 References: <20160819085756.GA6759@elstar.local> <01e501d1fa07$6d613fe0$4823bfa0$@ndzh.com> <9c53ff98-3268-f6e2-fbe6-862fc3948794@labn.net> <027a01d1fa12$3879b270$a96d1750$@ndzh.com> <036801d1fa2a$466e9e00$d34bda00$@ndzh.com> <001501d1fa30$46d0ac70$d4720550$@ndzh.com> <00e701d1fa3a$8cf41a70$a6dc4f50$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline X-Clacks-Overhead: GNU Terry Pratchett Content-Transfer-Encoding: 8bit In-Reply-To: <00e701d1fa3a$8cf41a70$a6dc4f50$@ndzh.com> User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: X-Mailman-Approved-At: Mon, 22 Aug 2016 06:09:04 -0700 Cc: i2rs@ietf.org, 'Alissa Cooper' , 'Andy Bierman' , i2rs-chairs@ietf.org, 'Kathleen Moriarty' , 'IESG' , 'Jeffrey Haas' , 'Joel Halpern' , 'Lou Berger' , 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 Reply-To: Juergen Schoenwaelder List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Aug 2016 10:08:04 -0000 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 From nobody Mon Aug 22 06:09:08 2016 Return-Path: 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 945A312D122; Mon, 22 Aug 2016 05:47:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.749 X-Spam-Level: * X-Spam-Status: No, score=1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, RCVD_IN_MSPIKE_BL=0.01, RCVD_IN_MSPIKE_L5=0.001, RDNS_NONE=0.793] autolearn=no 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 yxowCn_OecFt; Mon, 22 Aug 2016 05:47:55 -0700 (PDT) Received: from hickoryhill-consulting.com (unknown [50.245.122.97]) (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 378A412D0F0; Mon, 22 Aug 2016 05:47:55 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=74.43.47.166; From: "Susan Hares" To: "'Juergen Schoenwaelder'" References: <20160819085756.GA6759@elstar.local> <01e501d1fa07$6d613fe0$4823bfa0$@ndzh.com> <9c53ff98-3268-f6e2-fbe6-862fc3948794@labn.net> <027a01d1fa12$3879b270$a96d1750$@ndzh.com> <036801d1fa2a$466e9e00$d34bda00$@ndzh.com> <001501d1fa30$46d0ac70$d4720550$@ndzh.com> <00e701d1fa3a$8cf41a70$a6dc4f50$@ndzh.com> <20160822100738.GA12248@elstar.local> In-Reply-To: <20160822100738.GA12248@elstar.local> Date: Mon, 22 Aug 2016 08:46:13 -0400 Message-ID: <03ee01d1fc73$322502e0$966f08a0$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQFDCzFbX6CMUYXOBAS3fGQAhaIB3wJU1cn0Aq6vP/QCSnKSwQKvcIRTAg8Dd3kCL60I8ADFAWVLAkYXCdsCCOmClAIqM4lcoMb7UlA= Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: X-Mailman-Approved-At: Mon, 22 Aug 2016 06:09:04 -0700 Cc: i2rs@ietf.org, 'Alissa Cooper' , 'Andy Bierman' , i2rs-chairs@ietf.org, 'Kathleen Moriarty' , 'IESG' , 'Jeffrey Haas' , 'Joel Halpern' , 'Lou Berger' , 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Aug 2016 12:47:57 -0000 Juergen:=20 Thank you for your input.=20 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. =20 Sue =20 -----Original Message----- From: Juergen Schoenwaelder = [mailto:j.schoenwaelder@jacobs-university.de]=20 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:=20 >=20 > =20 >=20 > The easy of reviewing per leaf =E2=80=93 is why I suggested the per = leaf. =20 >=20 > I also agree it is important to mention this non-secure/secure = requirement to the PUSH work team we are both on.=20 >=20 > =20 >=20 > Should I change:=20 >=20 > Old: / >=20 > A non-secure transport can be used for publishing telemetry data or >=20 > other operational state that was specifically indicated to non- >=20 > confidential in the data model in the Yang syntax. / >=20 > New:=20 >=20 > / A non-secure transport can be used for publishing telemetry data = or >=20 > other operational state that was specifically indicated to non- >=20 > 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 --=20 Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Mon Aug 22 08:36:34 2016 Return-Path: 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> <036801d1fa2a$466e9e00$d34bda00$@ndzh.com> <001501d1fa30$46d0ac70$d4720550$@ndzh.com> <00e701d1fa3a$8cf41a70$a6dc4f50$@ndzh.com> <20160822100738.GA12248@elstar.local> <03ee01d1fc73$322502e0$966f08a0$@ndzh.com> From: Kathleen Moriarty Date: Mon, 22 Aug 2016 11:19:12 -0400 Message-ID: To: Susan Hares Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: X-Mailman-Approved-At: Mon, 22 Aug 2016 08:36:32 -0700 Cc: i2rs@ietf.org, Alissa Cooper , Juergen Schoenwaelder , Andy Bierman , i2rs-chairs@ietf.org, IESG , Jeffrey Haas , Joel Halpern , Lou Berger , 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 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 oc= curred 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 reque= sted by some operators. Please note that the operator should have a knob t= hat 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-ch= airs@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-protoc= ol-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 =E2=80=93 is why I suggested the per leaf= . >> >> I also agree it is important to mention this non-secure/secure requireme= nt 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 flawe= d idea. What can be considered 'non-confidential' depends on the deployment= scenario. It is even worse to standardize some piece of information as 'no= n-confidential'. How can the IETF claim that something is always 'non-confi= dential'? (And note, a non-secure transport is not just about confidentiali= ty, it also implies that boxes on the path can arbitrarily change the infor= mation.) > > 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 > --=20 Best regards, Kathleen From nobody Mon Aug 22 10:32:43 2016 Return-Path: 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 3FDEF12D093; Mon, 22 Aug 2016 08:36:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.749 X-Spam-Level: * X-Spam-Status: No, score=1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, RCVD_IN_MSPIKE_BL=0.01, RCVD_IN_MSPIKE_L5=0.001, RDNS_NONE=0.793] autolearn=no 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 1XjO77YU_zOO; Mon, 22 Aug 2016 08:36:49 -0700 (PDT) Received: from hickoryhill-consulting.com (unknown [50.245.122.97]) (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 BFDA712D0C0; Mon, 22 Aug 2016 08:36:44 -0700 (PDT) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=74.43.47.166; From: "Susan Hares" To: "'Kathleen Moriarty'" References: <20160819085756.GA6759@elstar.local> <01e501d1fa07$6d613fe0$4823bfa0$@ndzh.com> <9c53ff98-3268-f6e2-fbe6-862fc3948794@labn.net> <027a01d1fa12$3879b270$a96d1750$@ndzh.com> <036801d1fa2a$466e9e00$d34bda00$@ndzh.com> <001501d1fa30$46d0ac70$d4720550$@ndzh.com> <00e701d1fa3a$8cf41a70$a6dc4f50$@ndzh.com> <20160822100738.GA12248@elstar.local> <03ee01d1fc73$322502e0$966f08a0$@ndzh.com> In-Reply-To: Date: Mon, 22 Aug 2016 11:35:15 -0400 Message-ID: <029901d1fc8a$c9fca840$5df5f8c0$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQFDCzFbX6CMUYXOBAS3fGQAhaIB3wJU1cn0Aq6vP/QCSnKSwQKvcIRTAg8Dd3kCL60I8ADFAWVLAkYXCdsCCOmClAIqM4lcAlwhIFsBxzwH3qCmEY7w Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: X-Mailman-Approved-At: Mon, 22 Aug 2016 10:32:41 -0700 Cc: i2rs@ietf.org, 'Alissa Cooper' , 'Juergen Schoenwaelder' , 'Andy Bierman' , i2rs-chairs@ietf.org, 'IESG' , 'Jeffrey Haas' , 'Joel Halpern' , 'Lou Berger' , 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Aug 2016 15:36:51 -0000 Kathleen: I will include some of Stephen's updates. The document update will = probably late today or early tomorrow. =20 Sue=20 -----Original Message----- From: Kathleen Moriarty [mailto:kathleen.moriarty.ietf@gmail.com]=20 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 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=20 > [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';=20 > i2rs-chairs@ietf.org; 'Kathleen Moriarty'; 'IESG'; 'Jeffrey Haas';=20 > 'Joel Halpern';=20 > draft-ietf-i2rs-protocol-security-requirements@ietf.org > Subject: Re: [i2rs] Kathleen Moriarty's Discuss on=20 > draft-ietf-i2rs-protocol-security-requirements-07: (with DISCUSS and=20 > COMMENT) > > On Fri, Aug 19, 2016 at 12:55:53PM -0400, Susan Hares wrote: >> Andy: >> >> >> >> The easy of reviewing per leaf =E2=80=93 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=20 >> 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=20 > flawed idea. What can be considered 'non-confidential' depends on the=20 > deployment scenario. It is even worse to standardize some piece of=20 > information as 'non-confidential'. How can the IETF claim that=20 > something is always 'non-confidential'? (And note, a non-secure=20 > transport is not just about confidentiality, it also implies that=20 > 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 > --=20 Best regards, Kathleen From nobody Mon Aug 22 10:32:46 2016 Return-Path: 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> <036801d1fa2a$466e9e00$d34bda00$@ndzh.com> <001501d1fa30$46d0ac70$d4720550$@ndzh.com> <00e701d1fa3a$8cf41a70$a6dc4f50$@ndzh.com> <20160822100738.GA12248@elstar.local> <03ee01d1fc73$322502e0$966f08a0$@ndzh.com> <029901d1fc8a$c9fca840$5df5f8c0$@ndzh.com> To: Susan Hares Archived-At: X-Mailman-Approved-At: Mon, 22 Aug 2016 10:32:41 -0700 Cc: i2rs@ietf.org, Alissa Cooper , Juergen Schoenwaelder , Andy Bierman , i2rs-chairs@ietf.org, IESG , Jeffrey Haas , Joel Halpern , Lou Berger , 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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=20 Sent from my iPhone > On Aug 22, 2016, at 11:35 AM, Susan Hares wrote: >=20 > Kathleen: >=20 > I will include some of Stephen's updates. The document update will proba= bly late today or early tomorrow. =20 >=20 > Sue=20 >=20 > -----Original Message----- > From: Kathleen Moriarty [mailto:kathleen.moriarty.ietf@gmail.com]=20 > 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-protoco= l-security-requirements-07: (with DISCUSS and COMMENT) >=20 > Hello, >=20 > 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 t= o see where we are at as there have been a lot of messages on this thread an= d updates from other related AD comments/disucusses. I'm still concerned ab= out a few things, but will see if that matters in the text. >=20 > I believe I responded on the heading for the mutual authentication suggest= ing that it should really be identifiers and authentication instead of mutua= l authentication. I don't expect to see explicit guidelines on mutual auth,= but with that as the header, I would have. >=20 > Thanks, > Kathleen >=20 >> On Mon, Aug 22, 2016 at 8:46 AM, Susan Hares wrote: >> Juergen: >>=20 >> Thank you for your input. >>=20 >> I can find nothing new in your input that was not covered in the I2RS WG d= iscussions. As far as I can tell you are re-iterating a discussion that occu= rred 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 s= ays "always" secure-transport. >>=20 >> Sue >>=20 >> -----Original Message----- >> From: Juergen Schoenwaelder=20 >> [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';=20 >> i2rs-chairs@ietf.org; 'Kathleen Moriarty'; 'IESG'; 'Jeffrey Haas';=20 >> 'Joel Halpern';=20 >> draft-ietf-i2rs-protocol-security-requirements@ietf.org >> Subject: Re: [i2rs] Kathleen Moriarty's Discuss on=20 >> draft-ietf-i2rs-protocol-security-requirements-07: (with DISCUSS and=20 >> COMMENT) >>=20 >>> On Fri, Aug 19, 2016 at 12:55:53PM -0400, Susan Hares wrote: >>> Andy: >>>=20 >>>=20 >>>=20 >>> The easy of reviewing per leaf =E2=80=93 is why I suggested the per leaf= . >>>=20 >>> I also agree it is important to mention this non-secure/secure requireme= nt to the PUSH work team we are both on. >>>=20 >>>=20 >>>=20 >>> Should I change: >>>=20 >>> Old: / >>>=20 >>> A non-secure transport can be used for publishing telemetry data=20 >>> or >>>=20 >>> other operational state that was specifically indicated to non- >>>=20 >>> confidential in the data model in the Yang syntax. / >>>=20 >>> New: >>>=20 >>> / A non-secure transport can be used for publishing telemetry data or >>>=20 >>> other operational state that was specifically indicated to non- >>>=20 >>> confidential in the data model. / >>=20 >> Tagging something in the data model as 'non-confidential' remains a=20 >> flawed idea. What can be considered 'non-confidential' depends on the=20 >> deployment scenario. It is even worse to standardize some piece of=20 >> information as 'non-confidential'. How can the IETF claim that=20 >> something is always 'non-confidential'? (And note, a non-secure=20 >> transport is not just about confidentiality, it also implies that=20 >> boxes on the path can arbitrarily change the information.) >>=20 >> 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 a= ccess control model. This makes the decision runtime configurable and thus t= hings 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 par= ts of YANG data models as 'non-confidential'. >>=20 >> /js >>=20 >> -- >> Juergen Schoenwaelder Jacobs University Bremen gGmbH >> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany >> Fax: +49 421 200 3103 >=20 >=20 >=20 > --=20 >=20 > Best regards, > Kathleen >=20 From nobody Mon Aug 22 10:32:49 2016 Return-Path: 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 4A81512D794 for ; Mon, 22 Aug 2016 10:06:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=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=yumaworks-com.20150623.gappssmtp.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 57rIWIeu8hhZ for ; Mon, 22 Aug 2016 10:06:46 -0700 (PDT) Received: from mail-ua0-x236.google.com (mail-ua0-x236.google.com [IPv6:2607:f8b0:400c:c08::236]) (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 89B3512D549 for ; Mon, 22 Aug 2016 10:06:46 -0700 (PDT) Received: by mail-ua0-x236.google.com with SMTP id k90so200355939uak.1 for ; Mon, 22 Aug 2016 10:06:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=yraaCc6Gqu7H92VMUDdmlU6c67E/PX5k26/9MUTIXz8=; b=E5/MxO3Cy5kyqexsHw3VSnr6FsH3+agoFmT6Zu2kEyrhFIxcnSyfWirF6aFrGCPX1e Lkoo8v/TgikxKQmvNWXajih78Z18F3XdG5HFiwlAolr71jNGB2tQnwHnGrW9xUWsboLO iG0RFBM7aWTuBwuKREGVA1Ds9OMVdhn/aMgL24stb+tTp9wowotHbiPM0sd2qrfisJ7Q xib0DgjvUjG6GEmxbvNpraGMhSoA0K2SfPw1QG1b1SP4QussUooB3BDgjSNeuEDTR6nF Wf5y+fxhlmLK2cjBVY/PZN3qPF+zzdhE1SYOKaa3NdHc4KKKiJrGFRAahPU4fLG0Akwi griw== 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; bh=yraaCc6Gqu7H92VMUDdmlU6c67E/PX5k26/9MUTIXz8=; b=mcYf5YkLjJUmDz+Ali8SPqIVC8DYYKU0wUydz3ujuqkayXrTWo5ziXoaIaGtYJL466 /DyA2q8rgrpQfEIVJdvHNa0BIUw/X5kZFgazrDrTRkq01qIv7fyWtrnm8Wi87dml/nYZ u89TIn8QifvijvmBE+S2QcMZrlbPBRL1iX0ShsG4gqU4EerhGwyouiEhODSi9qtVpNsm bWTTKNRkSJri2KXkTX793Z8ttwN+n+1K32bJPbRXnJEVPj9E61l/y/UpEIngmq5zsCNy Em0KGLj748Y7bWhzxrmDxiIFLKMpBoZROJebZWGSD2WZQlx3GAqcij5/oVh8PRmB3Twm B17Q== X-Gm-Message-State: AEkoouvBNbwu4gKVUsiT+d6loi9XSYdiYh580R+TV2Md3dMkUse+kx127bXlNqyAItCnUnVQYweYbJ4mgHWelA== X-Received: by 10.176.68.166 with SMTP id n35mr12338873uan.47.1471885605577; Mon, 22 Aug 2016 10:06:45 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.4.134 with HTTP; Mon, 22 Aug 2016 10:06:43 -0700 (PDT) In-Reply-To: <20160822100738.GA12248@elstar.local> References: <20160819085756.GA6759@elstar.local> <01e501d1fa07$6d613fe0$4823bfa0$@ndzh.com> <9c53ff98-3268-f6e2-fbe6-862fc3948794@labn.net> <027a01d1fa12$3879b270$a96d1750$@ndzh.com> <036801d1fa2a$466e9e00$d34bda00$@ndzh.com> <001501d1fa30$46d0ac70$d4720550$@ndzh.com> <00e701d1fa3a$8cf41a70$a6dc4f50$@ndzh.com> <20160822100738.GA12248@elstar.local> From: Andy Bierman Date: Mon, 22 Aug 2016 10:06:43 -0700 Message-ID: To: Juergen Schoenwaelder , Susan Hares , 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 Content-Type: multipart/alternative; boundary=94eb2c05c5deabc1e9053aac12a4 Archived-At: X-Mailman-Approved-At: Mon, 22 Aug 2016 10:32:41 -0700 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Aug 2016 17:06:48 -0000 --94eb2c05c5deabc1e9053aac12a4 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Mon, Aug 22, 2016 at 3:07 AM, Juergen Schoenwaelder < j.schoenwaelder@jacobs-university.de> wrote: > On Fri, Aug 19, 2016 at 12:55:53PM -0400, Susan Hares wrote: > > Andy: > > > > > > > > The easy of reviewing per leaf =E2=80=93 is why I suggested the per lea= f. > > > > 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.) > > This additional note is quite interesting. It is 1 thing to decide if the data is public info or not. (Assume security guidelines could be provided that clearly define that.) It is quite another to say "it's OK if the monitoring data gets modified in flight". I can't imagine any use-cases for that. 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 > > Andy > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 > --94eb2c05c5deabc1e9053aac12a4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon, Aug 22, 2016 at 3:07 AM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
On Fri, Aug 19, 2016 at 12:55:53PM -0400, Susan Hare= s wrote:
> Andy:
>
>
>
> The easy of reviewing per leaf =E2=80=93 is why I suggested the per le= af.
>
> I also agree it is important to mention this non-secure/secure require= ment to the PUSH work team we are both on.
>
>
>
> Should I change:
>
> Old: /
>
>=C2=A0 =C2=A0 A non-secure transport can be used for publishing telemet= ry data or
>
>=C2=A0 =C2=A0 other operational state that was specifically indicated t= o non-
>
>=C2=A0 =C2=A0 confidential in the data model in the Yang syntax. /
>
> New:
>
> /=C2=A0 =C2=A0A non-secure transport can be used for publishing teleme= try data or
>
>=C2=A0 =C2=A0 other operational state that was specifically indicated t= o non-
>
>=C2=A0 =C2=A0 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 t= he
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.)


This additional note is quite interest= ing.
It is 1 thing to decide if the data is public info or not.
(Assume security guidelines could be provided that clearly define = that.)

It is quite another to say "it's O= K if the monitoring data gets modified in flight".
I can'= ;t imagine any use-cases for that.


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



Andy
=C2=A0
--
Juergen Schoenwaelder=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Jacobs Univer= sity Bremen gGmbH
Phone: +49 421 200 3587=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Campus Ring 1 | 28= 759 Bremen | Germany
Fax:=C2=A0 =C2=A0+49 421 200 3103=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<http://www.jacobs-university.de/>

--94eb2c05c5deabc1e9053aac12a4-- From nobody Tue Aug 23 07:35:39 2016 Return-Path: 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 To: Andy Bierman Message-ID: <20160822194549.GA5600@pfrc.org> References: <051701d1f952$c4ae0b30$4e0a2190$@ndzh.com> <6BCE198E4EAEFC4CAB45D75826EFB0761525CCD7@eusaamb101.ericsson.se> <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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: X-Mailman-Approved-At: Tue, 23 Aug 2016 07:35:38 -0700 Cc: "i2rs@ietf.org" , Alissa Cooper , Juergen Schoenwaelder , i2rs-chairs@ietf.org, Kathleen Moriarty , IESG , Joel Halpern , Lou Berger , Susan Hares , 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 From nobody Tue Aug 23 07:35:43 2016 Return-Path: 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 8E2CC12D7D1; Mon, 22 Aug 2016 12:51:14 -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 jGSGl3orwwt7; Mon, 22 Aug 2016 12:51:12 -0700 (PDT) Received: from mail-ua0-x232.google.com (mail-ua0-x232.google.com [IPv6:2607:f8b0:400c:c08::232]) (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 B8E1312D177; Mon, 22 Aug 2016 12:51:12 -0700 (PDT) Received: by mail-ua0-x232.google.com with SMTP id 74so208510214uau.0; Mon, 22 Aug 2016 12:51:12 -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; bh=+5ZA9oxKqs186BrgNj5xJoJKtl/PlN4atOH2yXtLraU=; b=NnP+Y4jGutBiStTGU+N0owO7FaPR1l7NrVcPUKVjlSyoqClm6nfsYHirmqIkSqhamy zcd88l5gE9YunMS72PFVvSklmvcuCPGgADXE3MCDlzWE/+ocQ9fsFI361OfVwOZohXRq Fn7nnYXnzQ/q3kcfucIZLntalmZ4xQELRtnfvP0fpoPwVEUcOAOMouvB1FtHlVqhgzm+ Jysm2meshKk1Gf0iFHAsR5yRlRBLMj79gC7frkodfpg0XHUuqVxCyerBexhNq0MKCLqV z17voydHlJi6tQm4NN69cAQjbHIJg67HZC+MJKOIMKJETD4FqY0ujHdTaeT9OtoRtmY6 RRuQ== 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; bh=+5ZA9oxKqs186BrgNj5xJoJKtl/PlN4atOH2yXtLraU=; b=UtelagDvMOCAf+LF9gELHLm9oKxHUQyNwusHftRMl9DQjidDhzdY47NDBJtQypepTf oX3n26kw26n4z44HzuD1F3Qdcb0W7rWOpOvzgP7M0MC05acTdCDvC+EcDGDGvHrLJWL7 9tHFmb8F9RQhuMzfqdQgBLEdNHHCoN0fX0wWqIKOIXKPGdvjwOjFHZVk8VtBGBnw+4kD CEEbFDQTgdJaa0mlErznB8e2U/UF0mj+D8TiZx5MraPU5qhHTTeNHER8pwQzkd/NnYZP vD0OdiTpcjvRxCryjbqbpMPFy0sgqZjcjW4d8kt9cnFHkfyFrruWmuW/iEisBxFJa8dR Bngw== X-Gm-Message-State: AEkoouucP7FGzXM8blus+3WyyFnKF9/zQVEByT1oyTrmzGwS/RGzPRPJl2DCsAHIK6nb1R/VPL5rdtPBB5w/jw== X-Received: by 10.176.1.67 with SMTP id 61mr9604463uak.99.1471895471702; Mon, 22 Aug 2016 12:51:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.1.228 with HTTP; Mon, 22 Aug 2016 12:51:09 -0700 (PDT) In-Reply-To: <20160822194549.GA5600@pfrc.org> References: <051701d1f952$c4ae0b30$4e0a2190$@ndzh.com> <6BCE198E4EAEFC4CAB45D75826EFB0761525CCD7@eusaamb101.ericsson.se> <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> <20160822194549.GA5600@pfrc.org> From: Kathleen Moriarty Date: Mon, 22 Aug 2016 15:51:09 -0400 Message-ID: To: Jeffrey Haas Content-Type: text/plain; charset=UTF-8 Archived-At: X-Mailman-Approved-At: Tue, 23 Aug 2016 07:35:38 -0700 Cc: "i2rs@ietf.org" , Juergen Schoenwaelder , Alissa Cooper , Andy Bierman , i2rs-chairs@ietf.org, IESG , Joel Halpern , Lou Berger , Susan Hares , 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Aug 2016 19:51:14 -0000 On Mon, Aug 22, 2016 at 3:45 PM, Jeffrey Haas wrote: > 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. 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. 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. > > > -- Jeff -- Best regards, Kathleen From nobody Tue Aug 23 07:35:45 2016 Return-Path: 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 To: Kathleen Moriarty Message-ID: <20160822195821.GB5600@pfrc.org> References: <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> <20160822194549.GA5600@pfrc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: X-Mailman-Approved-At: Tue, 23 Aug 2016 07:35:38 -0700 Cc: "i2rs@ietf.org" , Juergen Schoenwaelder , Alissa Cooper , Andy Bierman , i2rs-chairs@ietf.org, IESG , Joel Halpern , Lou Berger , Susan Hares , 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 From nobody Tue Aug 23 07:35:54 2016 Return-Path: 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 E7EBB12D7FF; Mon, 22 Aug 2016 13:08: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 4thz3R5n97IV; Mon, 22 Aug 2016 13:08:16 -0700 (PDT) Received: from mail-ua0-x236.google.com (mail-ua0-x236.google.com [IPv6:2607:f8b0:400c:c08::236]) (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 79B0712D7F7; Mon, 22 Aug 2016 13:08:16 -0700 (PDT) Received: by mail-ua0-x236.google.com with SMTP id n59so209097717uan.2; Mon, 22 Aug 2016 13:08:16 -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; bh=cjH1eaNWQcJAtCmQhmKjVcVOamFmtwgxG6vVTx8Yh7w=; b=E6aBbFpPhfv0eB7530wIEOcro0K9811imspKKA6qZ0oaLMsm1qAMoyPxVYa/0EbIjc QxEII425DbijcSL52RT/GpMCaGgGxkyLSKUM/U/Sc15Tya4W/0M4MxJio9GjtQSAqzmT 1PttJz1u0CQbjTwJE8MPeknh0wrr0zSV1uJMzGFzEZWAbXNVO+mD1+b4QyK3fyoZoLmK 7dGz3FHf5le4mYDhMDOv6OCJ+JIpw9Pwc6CWGtcCCdTjHgxBe6INDBR9iWeeYE6UUawT S5Ubx0GJmixXvx0rhXVVuLGzFf4gf2vQG5nn99o3fn8hCKzQ2iHvJxhS+2RyukTV35hA DyCw== 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; bh=cjH1eaNWQcJAtCmQhmKjVcVOamFmtwgxG6vVTx8Yh7w=; b=L5ciODMVnuUa9aXK5c2dXTdHw9ng9++6GNe/vlL3aSB4SaGGst2q8KmdVhfQ6Lot7d /cvb1nO29F7Y7bC8I4ugh92Cu8I+FHycVhbmhAnvh983iR9I5FBHASqWUX1U+NR6qSCJ 2L7fMLhveF90SyWyq6+Iq9ykVnBSRcFEakH0r/jIlGiBZuVE313aM7IGlmULo0qXysSv zXWuAwKdFB1/jkHTN/r6rYfhJLEr+l6BsgkbVXa0GlvV2gAbroaUv0vXmT8ArXm741pt TZP6orf2lvONvlVquJykTm/azQMtZQcoukPEQ23HAkD71Idtv1fxbMGqw6orvaJkl44y pwAQ== X-Gm-Message-State: AEkoousfe+Qo/bvFq3/HLkuZlFQO2Vcb7pyDRiH+PbWjK4TDyCIvb/U3ZQOX2bFLcdRhW/gMlZYLVGE2XS3G0w== X-Received: by 10.176.83.98 with SMTP id y31mr12470777uay.88.1471896495527; Mon, 22 Aug 2016 13:08:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.1.228 with HTTP; Mon, 22 Aug 2016 13:08:13 -0700 (PDT) In-Reply-To: <20160822195821.GB5600@pfrc.org> References: <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> <20160822194549.GA5600@pfrc.org> <20160822195821.GB5600@pfrc.org> From: Kathleen Moriarty Date: Mon, 22 Aug 2016 16:08:13 -0400 Message-ID: To: Jeffrey Haas Content-Type: text/plain; charset=UTF-8 Archived-At: X-Mailman-Approved-At: Tue, 23 Aug 2016 07:35:38 -0700 Cc: "i2rs@ietf.org" , Juergen Schoenwaelder , Alissa Cooper , Andy Bierman , i2rs-chairs@ietf.org, IESG , Joel Halpern , Lou Berger , Susan Hares , 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Aug 2016 20:08:18 -0000 On Mon, Aug 22, 2016 at 3:58 PM, Jeffrey Haas wrote: > 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. One other important consideration from this discussion is the terms used. I have been careful to say needing confidentiality and integrity protections, which is different from saying it needs to be secure (or it doesn't need confidentiality and integrity protection). > > 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. :-) Not that it matters, but yes, one my masters degree projects involved automating a bunch of functions in a service provider NOC with SNMP and I wrote a MIB for one of my drafts that was later changed to XML. Kathleen > > -- Jeff -- Best regards, Kathleen From nobody Tue Aug 23 10:00:46 2016 Return-Path: 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 E19E212D550; Tue, 23 Aug 2016 09:33:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.957 X-Spam-Level: X-Spam-Status: No, score=0.957 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_BL=0.01, RCVD_IN_MSPIKE_L5=0.001] autolearn=no 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 sKWc0Stty6SQ; Tue, 23 Aug 2016 09:33:10 -0700 (PDT) Received: from hickoryhill-consulting.com (50-245-122-97-static.hfc.comcastbusiness.net [50.245.122.97]) (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 B441612D59F; Tue, 23 Aug 2016 09:33:09 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=74.43.47.166; From: "Susan Hares" To: "'Andy Bierman'" , "'Juergen Schoenwaelder'" , "'Lou Berger'" , , "'Alissa Cooper'" , , "'Kathleen Moriarty'" , "'IESG'" , "'Jeffrey Haas'" , "'Joel Halpern'" , References: <20160819085756.GA6759@elstar.local> <01e501d1fa07$6d613fe0$4823bfa0$@ndzh.com> <9c53ff98-3268-f6e2-fbe6-862fc3948794@labn.net> <027a01d1fa12$3879b270$a96d1750$@ndzh.com> <036801d1fa2a$466e9e00$d34bda00$@ndzh.com> <001501d1fa30$46d0ac70$d4720550$@ndzh.com> <00e701d1fa3a$8cf41a70$a6dc4f50$@ndzh.com> <20160822100738.GA12248@elstar.local> In-Reply-To: Date: Tue, 23 Aug 2016 12:31:39 -0400 Message-ID: <0f2501d1fd5b$d3cddbb0$7b699310$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0F26_01D1FD3A.4CBD7430" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQFDCzFbX6CMUYXOBAS3fGQAhaIB3wJU1cn0Aq6vP/QCSnKSwQKvcIRTAg8Dd3kCL60I8ADFAWVLAkYXCdsCCOmClAIqM4lcAovteGagtG1yAA== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: X-Mailman-Approved-At: Tue, 23 Aug 2016 10:00:45 -0700 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Aug 2016 16:33:12 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0F26_01D1FD3A.4CBD7430 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Andy:=20 =20 Rather than state =E2=80=9Cdata model as 'non-confidential' remains a = flawed=E2=80=9D in the abstract, can we simply discuss the specifics I = listed?=20 =20 1) BGP information publically sent as part of route-views Sent as an event stream from an I2RS client=20 =20 2) Web server =E2=80=9Cup=E2=80=9D messages sent as an event=20 With the text similar to: =E2=80=9Cgo-to-me.com web server is = up=E2=80=9D where =E2=80=9Cgo-to-me=E2=80=9D is a public name.=20 =20 Please consider in terms of an Event stream model we are working in the = push. Remember the configuration of the stream is via secure servers, = and what we are talking about is listeners to the stream. =20 =20 Sue Hares =20 =20 From: Andy Bierman [mailto:andy@yumaworks.com]=20 Sent: Monday, August 22, 2016 1:07 PM To: Juergen Schoenwaelder; Susan Hares; 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) =20 =20 =20 On Mon, Aug 22, 2016 at 3:07 AM, Juergen Schoenwaelder = wrote: On Fri, Aug 19, 2016 at 12:55:53PM -0400, Susan Hares wrote: > Andy: > > > > The easy of reviewing per leaf =E2=80=93 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.) =20 This additional note is quite interesting. It is 1 thing to decide if the data is public info or not. (Assume security guidelines could be provided that clearly define that.) =20 It is quite another to say "it's OK if the monitoring data gets modified = in flight". I can't imagine any use-cases for that. =20 =20 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 =20 =20 Andy =20 -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 =20 ------=_NextPart_000_0F26_01D1FD3A.4CBD7430 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Andy:

 

Rather than state =E2=80=9Cdata model as 'non-confidential' = remains a flawed=E2=80=9D in the abstract, can we simply discuss the = specifics I listed?

 

1)      = BGP information publically sent as part of = route-views

Sent as an =C2=A0event stream from an I2RS client =

 

2)      = Web server =E2=80=9Cup=E2=80=9D messages sent as an event =

With the text similar to:=C2=A0=C2=A0 =E2=80=9Cgo-to-me.com web = server is up=E2=80=9D=C2=A0 where =E2=80=9Cgo-to-me=E2=80=9D is a public = name.

 

Please consider in terms of an Event stream model we are working in = the push. =C2=A0Remember the configuration of the stream is via secure = servers, and what we are talking about is listeners to the stream. = =C2=A0

 

Sue Hares = =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0

 

From:= = Andy Bierman [mailto:andy@yumaworks.com]
Sent: Monday, August = 22, 2016 1:07 PM
To: Juergen Schoenwaelder; Susan Hares; 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 Mon, = Aug 22, 2016 at 3:07 AM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> = wrote:

On Fri, Aug 19, 2016 at 12:55:53PM -0400, = Susan Hares wrote:
> Andy:
>
>
>
> The = easy of reviewing per leaf =E2=80=93 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.)

 

This additional note is quite = interesting.

It is 1 thing = to decide if the data is public info or not.

(Assume security guidelines could be provided that = clearly define that.)

 

It is quite another to say "it's OK if the = monitoring data gets modified in = flight".

I can't = imagine any use-cases for that.

 

 

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

 

 

Andy

 

--
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/><= o:p>

 

------=_NextPart_000_0F26_01D1FD3A.4CBD7430-- From nobody Tue Aug 23 13:13:30 2016 Return-Path: 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 6261F12D620 for ; Tue, 23 Aug 2016 10:08:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.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 5r6U4AXniyLQ for ; Tue, 23 Aug 2016 10:08:48 -0700 (PDT) Received: from mail-ua0-x22c.google.com (mail-ua0-x22c.google.com [IPv6:2607:f8b0:400c:c08::22c]) (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 692DD12D627 for ; Tue, 23 Aug 2016 10:08:40 -0700 (PDT) Received: by mail-ua0-x22c.google.com with SMTP id n59so255665572uan.2 for ; Tue, 23 Aug 2016 10:08:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=X+Z4SPR2kcNLEg4mnXjFKQ0kMj55w1AriUfJqhGFl7k=; b=oWSewiAhMeP9rx8odNA9NVNANJR0zC3hlnZJMCHnF4olj+XgllPHoZv3LNmkp55faE tyD3vccmC/ITZBkzb0h353/4AOgzeFkxtWkKXfYIDLOenoeVdYNf/q6bned6ocher+ML DWlTqyv36hBFzA6oLKUYnYcDWvfI2IgLnwaE49rdHk6xHtaqNntgc8Y7mJ+/mMHp1lRW HlFqt++fRItQbYYcI07J1i77CL0A1KSqdkF6IBWEpR8vgVezXmCum8gDdNTO9oST3LtG UAhrflJpftC5z5CwZG1aI2yVUi+Z4mAFm5NlnRATHBqa3/eZ0jf/Sc+jeXSA6cDaJtzU grpw== 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; bh=X+Z4SPR2kcNLEg4mnXjFKQ0kMj55w1AriUfJqhGFl7k=; b=T6yKTtYjSoS1hHc73m2Xh9J24J2Ht2Zsek9koNQsgdZxPU8swDBzEJ8m5hTHWKbJvY EZy/dybnpoels5BrCMkmfuKBO8VZ+VO6oMosU/Tb+lLiH1GNrl5QGIYnu1SKse9IONCS 8SMr0OnLoMeTOea6pNOGXNVti6nY7PN7NkbonS7AhklZqfpOZRK2TkIC02vP4zorLecp ur6fBSxhqcpeaJ6zOT1NgwyK702l/CqQq2Bgo5Yk157x16/rxzsgWqH2b4qH4E7OVccq pmyR43uYyjAhFn0+AmGLOzWTon8LfAE/5F/o0KRRUuQzzrCeFeEfbRCdKMSUdjS/gkBG FgVw== X-Gm-Message-State: AEkooutf7P2W7Gw7taaWcCqWzPwPmrwiVeOEvTee2kOitEQ6s2oq/2cHmwcEgj70pyu19Df9xHAOBBX55Uf+cw== X-Received: by 10.159.40.167 with SMTP id d36mr14835577uad.55.1471972119407; Tue, 23 Aug 2016 10:08:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.4.134 with HTTP; Tue, 23 Aug 2016 10:08:37 -0700 (PDT) In-Reply-To: <0f2501d1fd5b$d3cddbb0$7b699310$@ndzh.com> References: <20160819085756.GA6759@elstar.local> <01e501d1fa07$6d613fe0$4823bfa0$@ndzh.com> <9c53ff98-3268-f6e2-fbe6-862fc3948794@labn.net> <027a01d1fa12$3879b270$a96d1750$@ndzh.com> <036801d1fa2a$466e9e00$d34bda00$@ndzh.com> <001501d1fa30$46d0ac70$d4720550$@ndzh.com> <00e701d1fa3a$8cf41a70$a6dc4f50$@ndzh.com> <20160822100738.GA12248@elstar.local> <0f2501d1fd5b$d3cddbb0$7b699310$@ndzh.com> From: Andy Bierman Date: Tue, 23 Aug 2016 10:08:37 -0700 Message-ID: To: Susan Hares Content-Type: multipart/alternative; boundary=94eb2c1237944c191d053ac03714 Archived-At: X-Mailman-Approved-At: Tue, 23 Aug 2016 13:13:27 -0700 Cc: "i2rs@ietf.org" , Alissa Cooper , Juergen Schoenwaelder , i2rs-chairs@ietf.org, Kathleen Moriarty , IESG , Jeffrey Haas , Joel Halpern , Lou Berger , 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Aug 2016 17:08:49 -0000 --94eb2c1237944c191d053ac03714 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tue, Aug 23, 2016 at 9:31 AM, Susan Hares wrote: > Andy: > > > > Rather than state =E2=80=9Cdata model as 'non-confidential' remains a fla= wed=E2=80=9D in > the abstract, can we simply discuss the specifics I listed? > > > That was Juergen's comment. I think the tagging proposal is OK if the standard protocol that YANG Push designates as non-secure (HTTP?) is not allowed to send any YANG data that is not properly tagged. (If the protocol is allowed to ignore this extension, then the extension is pointless.) 1) BGP information publically sent as part of route-views > > Sent as an event stream from an I2RS client > > > > 2) Web server =E2=80=9Cup=E2=80=9D messages sent as an event > > With the text similar to: =E2=80=9Cgo-to-me.com web server is up=E2=80= =9D where > =E2=80=9Cgo-to-me=E2=80=9D is a public name. > > > > Please consider in terms of an Event stream model we are working in the > push. Remember the configuration of the stream is via secure servers, an= d > what we are talking about is listeners to the stream. > The actual data sent to listeners can be altered in flight. This may be a low risk. This is part of the decision WGs will have to make to support non-secure transport of data in the data models. > > > Sue Hares > Andy > > > *From:* Andy Bierman [mailto:andy@yumaworks.com] > *Sent:* Monday, August 22, 2016 1:07 PM > *To:* Juergen Schoenwaelder; Susan Hares; 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 Mon, Aug 22, 2016 at 3:07 AM, Juergen Schoenwaelder < > j.schoenwaelder@jacobs-university.de> wrote: > > On Fri, Aug 19, 2016 at 12:55:53PM -0400, Susan Hares wrote: > > Andy: > > > > > > > > The easy of reviewing per leaf =E2=80=93 is why I suggested the per lea= f. > > > > 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.) > > > > This additional note is quite interesting. > > It is 1 thing to decide if the data is public info or not. > > (Assume security guidelines could be provided that clearly define that.) > > > > It is quite another to say "it's OK if the monitoring data gets modified > in flight". > > I can't imagine any use-cases for that. > > > > > > 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 > > > > > > Andy > > > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 > > > --94eb2c1237944c191d053ac03714 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Aug 23, 2016 at 9:31 AM, Susan Hares <shares@ndzh.com> wrote:

Andy:

=

=C2=A0

Rather than state =E2=80=9Cdata model as 'non-= confidential' remains a flawed=E2=80=9D in the abstract, can we simply = discuss the specifics I listed?

=C2=A0


That was Juergen's comment.

I= think the tagging proposal is OK if the standard protocol that YANG Push
designates as non-secure (HTTP?) is not allowed to send any YANG d= ata
that is not properly tagged.

(If the= protocol is allowed to ignore this extension, then the extension is pointl= ess.)

1)=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 BGP information publically sent as part of ro= ute-views

Sent as an =C2=A0event stream from an I2RS client =

=C2=A0

2)= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Web serv= er =E2=80=9Cup=E2=80=9D messages sent as an event

=

With the text si= milar to:=C2=A0=C2=A0 =E2=80=9Cgo-to-me.com web server is up=E2=80=9D=C2=A0 where =E2=80=9Cgo-to= -me=E2=80=9D is a public name.

=C2=A0

P= lease consider in terms of an Event stream model we are working in the push= .=C2=A0 Remember the configuration of the stream is via secure servers, and= what we are talking about is listeners to the stream. =C2=A0



The actual data se= nt to listeners can be altered in flight.
This may be a low risk.= =C2=A0 This is part of the decision WGs will
have to make to supp= ort non-secure transport of data in the data models.

=C2=A0

=C2=A0

Sue Hares =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0



Andy
=C2=A0

=C2=A0

Fro= m: = Andy Bierman [mailto:andy@yumaworks.com]
Sent: Monday, August 22, 2016 1:07 PM<= br>To: Juergen Schoenwaelder; Susan Hares; Andy Bierman; Lou Berger;= i2rs@ietf.org; Alis= sa Cooper; i2rs-c= hairs@ietf.org; Kathleen Moriarty; IESG; Jeffrey Haas; Joel Halpern; draft-ietf-i2rs-protocol-security-requirements@ietf.or= g
Subject: Re: [i2rs] Kathleen Moriarty's Discuss on draf= t-ietf-i2rs-protocol-security-requirements-07: (with DISCUSS and COMME= NT)

=C2=A0

=

=C2=A0

=C2=A0

On Mon, Aug 22, 20= 16 at 3:07 AM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-univers= ity.de> wrote:

On Fri, Aug 19, 2016 at 12:55:53PM -0400, Susan Hares wrote= :
> Andy:
>
>
>
> The easy of reviewing per l= eaf =E2=80=93 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:<= br>>
> Old: /
>
>=C2=A0 =C2=A0 A non-secure transport = can be used for publishing telemetry data or
>
>=C2=A0 =C2=A0 o= ther operational state that was specifically indicated to non-
>
&= gt;=C2=A0 =C2=A0 confidential in the data model in the Yang syntax. /
&g= t;
> New:
>
> /=C2=A0 =C2=A0A non-secure transport can be= used for publishing telemetry data or
>
>=C2=A0 =C2=A0 other o= perational state that was specifically indicated to non-
>
>=C2= =A0 =C2=A0 confidential in the data model. /
>

Tagging somethi= ng in the data model as 'non-confidential' remains a
flawed idea= . What can be considered 'non-confidential' depends on the
deplo= yment scenario. It is even worse to standardize some piece of
informatio= n as 'non-confidential'. How can the IETF claim that
something i= s always 'non-confidential'? (And note, a non-secure
transport i= s not just about confidentiality, it also implies that
boxes on the path= can arbitrarily change the information.)

=C2=A0

This = additional note is quite interesting.

It is 1 thing to decide if the data is public info or not.

(Assume security guidelin= es could be provided that clearly define that.)

=C2=A0

It is quite another to say "it's OK if the monitoring data = gets modified in flight".

I can't imagine any use-cases for that.

<= div>

=C2=A0

=C2=A0

In case this is not clear: What we h= ave done for ~30 years is to have
the decision which information goes in= to an insecure transport be
taken by an access control model. This makes= the decision runtime
configurable and thus things can be deployment spe= cific. This has
worked for 30 years and I have no problem with this. Wha= t I am
struggling with is the idea to standardize parts of YANG data mod= els
as 'non-confidential'.

/js

=C2=A0

<= u>=C2=A0

Andy

=C2=A0=

--
Juergen Schoenwaelder=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0Jacobs University Bremen gGmbH
Phone: +49 421 200 358= 7=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Campus Ring 1 | 28759 Bremen | Germany
Fax:=C2=A0 =C2=A0+49 421 200 3103=C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0<h= ttp://www.jacobs-university.de/>

=C2=A0

--94eb2c1237944c191d053ac03714-- From nobody Tue Aug 23 13:13:34 2016 Return-Path: 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 A6BB212D124; Tue, 23 Aug 2016 10:22:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.957 X-Spam-Level: X-Spam-Status: No, score=0.957 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_BL=0.01, RCVD_IN_MSPIKE_L5=0.001] autolearn=no 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 ZzDCXdx8_cOb; Tue, 23 Aug 2016 10:22:20 -0700 (PDT) Received: from hickoryhill-consulting.com (50-245-122-97-static.hfc.comcastbusiness.net [50.245.122.97]) (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 E81D112B02B; Tue, 23 Aug 2016 10:22:19 -0700 (PDT) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=74.43.47.166; From: "Susan Hares" To: "'Andy Bierman'" References: <20160819085756.GA6759@elstar.local> <01e501d1fa07$6d613fe0$4823bfa0$@ndzh.com> <9c53ff98-3268-f6e2-fbe6-862fc3948794@labn.net> <027a01d1fa12$3879b270$a96d1750$@ndzh.com> <036801d1fa2a$466e9e00$d34bda00$@ndzh.com> <001501d1fa30$46d0ac70$d4720550$@ndzh.com> <00e701d1fa3a$8cf41a70$a6dc4f50$@ndzh.com> <20160822100738.GA12248@elstar.local> <0f2501d1fd5b$d3cddbb0$7b699310$@ndzh.com> In-Reply-To: Date: Tue, 23 Aug 2016 13:20:50 -0400 Message-ID: <000901d1fd62$b2683090$173891b0$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000A_01D1FD41.2B59EBF0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQFDCzFbX6CMUYXOBAS3fGQAhaIB3wJU1cn0Aq6vP/QCSnKSwQKvcIRTAg8Dd3kCL60I8ADFAWVLAkYXCdsCCOmClAIqM4lcAovteGYAhZ1t4wKivnjkoJs29dA= Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: X-Mailman-Approved-At: Tue, 23 Aug 2016 13:13:27 -0700 Cc: i2rs@ietf.org, 'Alissa Cooper' , 'Juergen Schoenwaelder' , i2rs-chairs@ietf.org, 'Kathleen Moriarty' , 'IESG' , 'Jeffrey Haas' , 'Joel Halpern' , 'Lou Berger' , 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Aug 2016 17:22:21 -0000 This is a multipart message in MIME format. ------=_NextPart_000_000A_01D1FD41.2B59EBF0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Andy:=20 =20 Thanks for your input. I=E2=80=99m sorry I got your comment confused = with Juergen=E2=80=99s comment. I agree with your solution. The Yang = Push designating a non-secure (HTTP/RESTCONF) is not allowed to send = anything that is not properly tagged. This works for the BGP event = stream and the web service up stream.=20 =20 Sue=20 =20 From: Andy Bierman [mailto:andy@yumaworks.com]=20 Sent: Tuesday, August 23, 2016 1:09 PM To: Susan Hares Cc: Juergen Schoenwaelder; 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) =20 =20 =20 On Tue, Aug 23, 2016 at 9:31 AM, Susan Hares wrote: Andy:=20 =20 Rather than state =E2=80=9Cdata model as 'non-confidential' remains a = flawed=E2=80=9D in the abstract, can we simply discuss the specifics I = listed?=20 =20 =20 That was Juergen's comment. =20 I think the tagging proposal is OK if the standard protocol that YANG = Push designates as non-secure (HTTP?) is not allowed to send any YANG data that is not properly tagged. =20 (If the protocol is allowed to ignore this extension, then the extension = is pointless.) =20 1) BGP information publically sent as part of route-views Sent as an event stream from an I2RS client=20 =20 2) Web server =E2=80=9Cup=E2=80=9D messages sent as an event=20 With the text similar to: =E2=80=9Cgo-to-me.com web server is = up=E2=80=9D where =E2=80=9Cgo-to-me=E2=80=9D is a public name.=20 =20 Please consider in terms of an Event stream model we are working in the = push. Remember the configuration of the stream is via secure servers, = and what we are talking about is listeners to the stream. =20 =20 =20 The actual data sent to listeners can be altered in flight. This may be a low risk. This is part of the decision WGs will have to make to support non-secure transport of data in the data models. =20 =20 =20 Sue Hares =20 =20 =20 Andy =20 =20 From: Andy Bierman [mailto:andy@yumaworks.com]=20 Sent: Monday, August 22, 2016 1:07 PM To: Juergen Schoenwaelder; Susan Hares; 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) =20 =20 =20 On Mon, Aug 22, 2016 at 3:07 AM, Juergen Schoenwaelder = wrote: On Fri, Aug 19, 2016 at 12:55:53PM -0400, Susan Hares wrote: > Andy: > > > > The easy of reviewing per leaf =E2=80=93 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.) =20 This additional note is quite interesting. It is 1 thing to decide if the data is public info or not. (Assume security guidelines could be provided that clearly define that.) =20 It is quite another to say "it's OK if the monitoring data gets modified = in flight". I can't imagine any use-cases for that. =20 =20 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 =20 =20 Andy =20 -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 =20 =20 ------=_NextPart_000_000A_01D1FD41.2B59EBF0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Andy:

 

Thanks for your input.=C2=A0 I=E2=80=99m sorry I got your comment = confused with Juergen=E2=80=99s comment. =C2=A0=C2=A0I agree with your = solution.=C2=A0 The Yang Push designating a non-secure (HTTP/RESTCONF) = is not allowed to send anything that is not properly tagged. = =C2=A0=C2=A0This works for the BGP event stream and the web service = =C2=A0up stream.

 

Sue

 

From:= = Andy Bierman [mailto:andy@yumaworks.com]
Sent: Tuesday, = August 23, 2016 1:09 PM
To: Susan Hares
Cc: Juergen = Schoenwaelder; 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 Tue, = Aug 23, 2016 at 9:31 AM, Susan Hares <shares@ndzh.com> = wrote:

Andy:

 

Rather than state =E2=80=9Cdata model as 'non-confidential' = remains a flawed=E2=80=9D in the abstract, can we simply discuss the = specifics I listed?

 

 

That was Juergen's = comment.

 

I = think the tagging proposal is OK if the standard protocol that YANG = Push

designates as = non-secure (HTTP?) is not allowed to send any YANG = data

that is not properly = tagged.

 

(If the protocol is allowed to ignore this extension, = then the extension is pointless.)

 

1)      = BGP information publically sent as part of = route-views

Sent as an  event stream from an I2RS client =

 

2)      = Web server =E2=80=9Cup=E2=80=9D messages sent as an event =

With the text similar to:   =E2=80=9Cgo-to-me.com web = server is up=E2=80=9D  where =E2=80=9Cgo-to-me=E2=80=9D is a public = name.

 

Please consider in terms of an Event stream model we are working in = the push.  Remember the configuration of the stream is via secure = servers, and what we are talking about is listeners to the stream. =  

 

 

The actual data sent to listeners can be altered in = flight.

This may be a low = risk.  This is part of the decision WGs = will

have to make to = support non-secure transport of data in the data = models.

 

 

 

Sue Hares =         

 

 

Andy

 

 

From:= = Andy Bierman [mailto:andy@yumaworks.com]
Sent: Monday, = August 22, 2016 1:07 PM
To: Juergen Schoenwaelder; Susan = Hares; 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)

 <= /o:p>

 <= /o:p>

 <= /o:p>

On Mon, Aug = 22, 2016 at 3:07 AM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> = wrote:

On Fri, Aug 19, = 2016 at 12:55:53PM -0400, Susan Hares wrote:
> = Andy:
>
>
>
> The easy of reviewing per leaf = =E2=80=93 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.)

 <= /o:p>

This = additional note is quite interesting.

It is 1 = thing to decide if the data is public info or = not.

(Assume = security guidelines could be provided that clearly define = that.)

 <= /o:p>

It is quite = another to say "it's OK if the monitoring data gets modified in = flight".

I can't = imagine any use-cases for that.

 <= /o:p>

 <= /o:p>

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

 <= /o:p>

 <= /o:p>

Andy

 

--
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/>

 <= /o:p>

 

------=_NextPart_000_000A_01D1FD41.2B59EBF0-- From nobody Tue Aug 23 13:13:36 2016 Return-Path: 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 E34A512D9BD; Tue, 23 Aug 2016 12:28:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.956 X-Spam-Level: X-Spam-Status: No, score=0.956 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, RCVD_IN_MSPIKE_BL=0.01, RCVD_IN_MSPIKE_L5=0.001] autolearn=no 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 jnBiv82xIxcC; Tue, 23 Aug 2016 12:28:30 -0700 (PDT) Received: from hickoryhill-consulting.com (50-245-122-97-static.hfc.comcastbusiness.net [50.245.122.97]) (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 8025012D7A5; Tue, 23 Aug 2016 12:28:30 -0700 (PDT) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=74.43.47.166; From: "Susan Hares" To: "'Jeffrey Haas'" , "'Andy Bierman'" References: <051701d1f952$c4ae0b30$4e0a2190$@ndzh.com> <6BCE198E4EAEFC4CAB45D75826EFB0761525CCD7@eusaamb101.ericsson.se> <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> <20160822194549.GA5600@pfrc.org> In-Reply-To: <20160822194549.GA5600@pfrc.org> Date: Tue, 23 Aug 2016 15:27:01 -0400 Message-ID: <000d01d1fd74$53dcd4b0$fb967e10$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQMksAaN1IctIh4kw2oqzO+tHe/O3gJqExQkAqfTovACEJToAwFDCzFbAlTVyfQCrq8/9AJKcpLBAq9whFMCDwN3eQIASoM+nP3kCkA= Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: X-Mailman-Approved-At: Tue, 23 Aug 2016 13:13:27 -0700 Cc: i2rs@ietf.org, 'Alissa Cooper' , 'Juergen Schoenwaelder' , i2rs-chairs@ietf.org, 'Kathleen Moriarty' , 'IESG' , 'Joel Halpern' , 'Lou Berger' , 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Aug 2016 19:28:32 -0000 Jeff: Thank you your comments. I agree with your assessment of the WG's desires. It provides a helpful context for the IESG members. As I mentioned in another email, one of the first mechanisms is to describe what portions of an data model can be sent in the PUB/SUB Push via a non-secure HTTP session or what require a secure HTTP session. Sue -----Original Message----- From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Jeffrey Haas Sent: Monday, August 22, 2016 3:46 PM To: Andy Bierman Cc: i2rs@ietf.org; Alissa Cooper; Juergen Schoenwaelder; i2rs-chairs@ietf.org; Kathleen Moriarty; IESG; Joel Halpern; Lou Berger; Susan Hares; 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) 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 _______________________________________________ i2rs mailing list i2rs@ietf.org https://www.ietf.org/mailman/listinfo/i2rs From nobody Tue Aug 23 13:38:32 2016 Return-Path: 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 A957D12DAAA for ; Tue, 23 Aug 2016 13:17:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.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 Kq7HZnGNjAjs for ; Tue, 23 Aug 2016 13:16:58 -0700 (PDT) Received: from mail-ua0-x22a.google.com (mail-ua0-x22a.google.com [IPv6:2607:f8b0:400c:c08::22a]) (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 B3F0912DABA for ; Tue, 23 Aug 2016 13:16:46 -0700 (PDT) Received: by mail-ua0-x22a.google.com with SMTP id n59so264404798uan.2 for ; Tue, 23 Aug 2016 13:16:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=qMDEyAbLrvlC4ZjEIKphEr1mkXlkiLddv94GKHHywdc=; b=hObn/4alHN1aDJD06ZcIzv7IK8cwiHkxnSRzu54tk4efd0+EsCcnOOHx44+huSjhMV AVcurR7Z9hrR4+BfHD0CIGWo5YVCbNqO3B/gD3CzGQZHmBGytge/bPcuJE/VivUoBI5L 4Zw9XzwDun0SQn3yR6bUSo8mxfqVUC+V3p7ZTQqYzEM+NNQ9Lkp0TtCn35J+5VOdmjnf 1WfM5cy6V+9gearYuEirltNzehmQ+IcF0y7YB4KQukyJCum1Wfs84QoRQjvuGGD9xCNh Z1DIcCPAzfmgWYsxzb/VfyJPomw70A6GQ+OKPTb5iwTmhEqrtNIbV9RAC6RgH6rIecHe serg== 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; bh=qMDEyAbLrvlC4ZjEIKphEr1mkXlkiLddv94GKHHywdc=; b=SrIIdemAoX8UCsu0YVeBftnyDfcqzL3NI2iwY/TtNf4/G42GxitzTux5Xbi5KCMCOu cM7Cxi117Kj4vjA/0OPzS9OGRFq4/mm1k94JKg4FSRqugRT6ShK1+N40SKuxn+1jwQT4 XuYBe8NNUVknIA1t+oGE2KvCVqtFYACtYVZ/E4ft/+mxxD8JpOD8iNJhQXy1b/aFJ7xt AADzu8KmCIRHjnx63gd9eRgLY4fSpElPpx3G6G2yhDvdpk6bJU4nRmZRKEXAaqEOrFdn s9WQnfi0xcoMjoo3X7dGk1UvubOWhaYtY7gaheZtLQAXdDoez8BAB+JyXZ6S/wMbyoXZ 2J8Q== X-Gm-Message-State: AEkoouvWMfUKuc1VlvLKd+De+S7sS4850ydGtvuZhrAwFk4HlAXhWA5Leg6HMNEOhG4E/xpgEQ7MXzUfqnMD8g== X-Received: by 10.176.68.166 with SMTP id n35mr15970696uan.47.1471983405840; Tue, 23 Aug 2016 13:16:45 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.4.134 with HTTP; Tue, 23 Aug 2016 13:16:44 -0700 (PDT) In-Reply-To: <000d01d1fd74$53dcd4b0$fb967e10$@ndzh.com> References: <051701d1f952$c4ae0b30$4e0a2190$@ndzh.com> <6BCE198E4EAEFC4CAB45D75826EFB0761525CCD7@eusaamb101.ericsson.se> <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> <20160822194549.GA5600@pfrc.org> <000d01d1fd74$53dcd4b0$fb967e10$@ndzh.com> From: Andy Bierman Date: Tue, 23 Aug 2016 13:16:44 -0700 Message-ID: To: Susan Hares Content-Type: multipart/alternative; boundary=94eb2c05c5de05514d053ac2d8f2 Archived-At: X-Mailman-Approved-At: Tue, 23 Aug 2016 13:38:30 -0700 Cc: "i2rs@ietf.org" , Alissa Cooper , Juergen Schoenwaelder , i2rs-chairs@ietf.org, Kathleen Moriarty , IESG , Jeffrey Haas , Joel Halpern , Lou Berger , 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Aug 2016 20:17:01 -0000 --94eb2c05c5de05514d053ac2d8f2 Content-Type: text/plain; charset=UTF-8 On Tue, Aug 23, 2016 at 12:27 PM, Susan Hares wrote: > Jeff: > > Thank you your comments. I agree with your assessment of the WG's > desires. > It provides a helpful context for the IESG members. > > As I mentioned in another email, one of the first mechanisms is to describe > what portions of an data model can be sent in the PUB/SUB Push via a > non-secure HTTP session or what require a secure HTTP session. > > Sue > -----Original Message----- > From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Jeffrey Haas > Sent: Monday, August 22, 2016 3:46 PM > To: Andy Bierman > Cc: i2rs@ietf.org; Alissa Cooper; Juergen Schoenwaelder; > i2rs-chairs@ietf.org; Kathleen Moriarty; IESG; Joel Halpern; Lou Berger; > Susan Hares; 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) > > 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. > I believe the actual annotation needs to apply to a specific subtree. There are corner-cases where the module-wide annotation does not work (such as groupings used in a different module). IMO the annotation needs to apply only to descendant-or-self nodes in the same module namespace. > > 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 > Andy > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs > > --94eb2c05c5de05514d053ac2d8f2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Aug 23, 2016 at 12:27 PM, Susan Hares <shares@ndzh.com> wrote:
Jeff:

Thank you your comments.=C2=A0 =C2=A0I agree with your assessment of the WG= 's desires.
It provides a helpful context for the IESG members.

As I mentioned in another email, one of the first mechanisms is to describe=
what portions of an data model can be sent in the PUB/SUB Push via a
non-secure HTTP session or what require a secure HTTP session.

Sue
-----Original Message-----
From: i2rs [mailto:i2rs-bounces@ie= tf.org] On Behalf Of Jeffrey Haas
Sent: Monday, August 22, 2016 3:46 PM
To: Andy Bierman
Cc: i2rs@ietf.org; Alissa Cooper; Juer= gen Schoenwaelder;
i2rs-chairs@ietf.org; Kathleen = Moriarty; IESG; Joel Halpern; Lou Berger;
Susan Hares; 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)

I'm lagging in my email, as usual.=C2=A0 However, this one caught my ey= e:

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?<= br>
I wanted to point out some of the per-object security evaluation that is already imposed on MIB modules.=C2=A0 Consider the following text from RFC = 4273:

:=C2=A0 =C2=A0 There are a number of managed objects in this MIB that conta= in
:=C2=A0 =C2=A0 sensitive information regarding the operation of a network.= =C2=A0 For
:=C2=A0 =C2=A0 example, a BGP peer's local and remote addresses might b= e sensitive
:=C2=A0 =C2=A0 for ISPs who want to keep interface addresses on routers con= fidential
:=C2=A0 =C2=A0 in order to prevent router addresses used for a denial of se= rvice
:=C2=A0 =C2=A0 attack or spoofing.
:
:=C2=A0 =C2=A0 Therefore, it is important in most environments to control r= ead
:=C2=A0 =C2=A0 access to these objects and possibly to even encrypt the val= ues of
:=C2=A0 =C2=A0 these object when sending them over the network via SNMP.
In some respect, the discussion with regard to I2RS annotation of yang node= s
with security considerations have precedence.=C2=A0 It could be done in the=
containing documents' security considerations section.=C2=A0 It could b= e 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 pre= smise
of "secure by default", is it okay to mark things as "the au= thor of this
module believes this to be okay to be insecure by default"?

Possibly not.=C2=A0 As you both mention, it will depend on the circumstance= s 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?=C2=A0 If the answer is "read the security considerations and write a filter", it's not the answer i2rs is lo= oking for.


-- Jeff



_______________________________________________
i2rs mailing list
i2rs@ietf.org
https://www.ietf.org/mailman/listinfo/i2rs


--94eb2c05c5de05514d053ac2d8f2-- From nobody Fri Aug 26 04:18:17 2016 Return-Path: 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 B9AB312DE32; Wed, 24 Aug 2016 08:34:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.748 X-Spam-Level: X-Spam-Status: No, score=-4.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.548] 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 ngT98JCn5f7v; Wed, 24 Aug 2016 08:34:23 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 85CD212DE85; Wed, 24 Aug 2016 08:24:43 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id CA920F14; Wed, 24 Aug 2016 17:24:41 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.205]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id dYm7V-X_agqF; Wed, 24 Aug 2016 17:24:28 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Wed, 24 Aug 2016 17:24:40 +0200 (CEST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 7FB24200AB; Wed, 24 Aug 2016 17:24:40 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 3gKrc7VmGk0G; Wed, 24 Aug 2016 17:24:39 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id C40CE200A3; Wed, 24 Aug 2016 17:24:38 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id B59303C30FB7; Wed, 24 Aug 2016 17:24:37 +0200 (CEST) Date: Wed, 24 Aug 2016 17:24:37 +0200 From: Juergen Schoenwaelder To: Susan Hares Message-ID: <20160824152437.GC17330@elstar.local> Mail-Followup-To: Susan Hares , 'Jeffrey Haas' , 'Andy Bierman' , i2rs@ietf.org, 'Alissa Cooper' , i2rs-chairs@ietf.org, 'Kathleen Moriarty' , 'IESG' , 'Joel Halpern' , 'Lou Berger' , draft-ietf-i2rs-protocol-security-requirements@ietf.org References: <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> <20160822194549.GA5600@pfrc.org> <000d01d1fd74$53dcd4b0$fb967e10$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <000d01d1fd74$53dcd4b0$fb967e10$@ndzh.com> User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: X-Mailman-Approved-At: Fri, 26 Aug 2016 04:18:15 -0700 Cc: i2rs@ietf.org, 'Alissa Cooper' , 'Andy Bierman' , i2rs-chairs@ietf.org, 'Kathleen Moriarty' , 'IESG' , 'Jeffrey Haas' , 'Joel Halpern' , 'Lou Berger' , 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 Reply-To: Juergen Schoenwaelder List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Aug 2016 15:34:27 -0000 I fail to understand why it makes a difference whether something is accessed via pub/sub or in a more traditional way. We need to look at this from an architectural point of view. And I am a big fan of the separation of mechanism from policy [1]. The question what can be sent over an insecure transport is a policy decision of a specific deployment and hard-coding such policies statically in a data model scares me. SNMP got this piece right since SNMP left it to the access control subsystem to take the decision and thus policies could be flexible. If there is a need to document common policies that certain applications may find useful, then simply write them down as NACM rules in XML. (The only little issue is that NACM today does not know whether a request came via a non-secure transport since it assumes there are only secure transports. But this seems to be fixable and required to fix if NETCONF indeed introduces non-secure transports.) /js [1] https://en.wikipedia.org/wiki/Separation_of_mechanism_and_policy On Tue, Aug 23, 2016 at 03:27:01PM -0400, Susan Hares wrote: > Jeff: > > Thank you your comments. I agree with your assessment of the WG's desires. > It provides a helpful context for the IESG members. > > As I mentioned in another email, one of the first mechanisms is to describe > what portions of an data model can be sent in the PUB/SUB Push via a > non-secure HTTP session or what require a secure HTTP session. > > Sue > -----Original Message----- > From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Jeffrey Haas > Sent: Monday, August 22, 2016 3:46 PM > To: Andy Bierman > Cc: i2rs@ietf.org; Alissa Cooper; Juergen Schoenwaelder; > i2rs-chairs@ietf.org; Kathleen Moriarty; IESG; Joel Halpern; Lou Berger; > Susan Hares; 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) > > 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 > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs > -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Fri Aug 26 04:18:21 2016 Return-Path: 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 71B3512B04E; Thu, 25 Aug 2016 06:05:37 -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 djp4TRnlgPVN; Thu, 25 Aug 2016 06:05:36 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 5F9CB12B018; Thu, 25 Aug 2016 06:05:36 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 315851E32B; Thu, 25 Aug 2016 09:06:18 -0400 (EDT) Date: Thu, 25 Aug 2016 09:06:18 -0400 From: Jeffrey Haas To: Susan Hares , 'Andy Bierman' , i2rs@ietf.org, 'Alissa Cooper' , i2rs-chairs@ietf.org, 'Kathleen Moriarty' , 'IESG' , 'Joel Halpern' , 'Lou Berger' , draft-ietf-i2rs-protocol-security-requirements@ietf.org Message-ID: <20160825130617.GB7765@pfrc.org> References: <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> <20160822194549.GA5600@pfrc.org> <000d01d1fd74$53dcd4b0$fb967e10$@ndzh.com> <20160824152437.GC17330@elstar.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160824152437.GC17330@elstar.local> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: X-Mailman-Approved-At: Fri, 26 Aug 2016 04:18:15 -0700 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\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Aug 2016 13:05:37 -0000 Juergen, On Wed, Aug 24, 2016 at 05:24:37PM +0200, Juergen Schoenwaelder wrote: > I fail to understand why it makes a difference whether something is > accessed via pub/sub or in a more traditional way. We need to look at > this from an architectural point of view. And I am a big fan of the > separation of mechanism from policy [1]. The main i2rs use case is pub-sub. I personally have no objection if the use of such a mechanism is made general and is tied to the security properties of the transport rather than the transport type. > The question what can be sent over an insecure transport is a policy > decision of a specific deployment and hard-coding such policies > statically in a data model scares me. SNMP got this piece right since > SNMP left it to the access control subsystem to take the decision and > thus policies could be flexible. In my opinion, SNMP is often improperly secured since the mechanisms provided to lock down sensitive objects puts too much onus on the users to "get it right". This is made particularly difficult by the lack of machine parseable hints in SMIv2 and requires the users to dig through conformance statements, textual conventions and security considerations of the underlying document which may not even be available in the extracted MIBs. I will concede that by starting with "we're secure by default", a number of such headaches with regard to the security of objects is remediated. What is missing is the ability to make it easy to expose objects that have less sensitivity. > If there is a need to document common policies that certain > applications may find useful, then simply write them down as NACM > rules in XML. (The only little issue is that NACM today does not know > whether a request came via a non-secure transport since it assumes > there are only secure transports. But this seems to be fixable and > required to fix if NETCONF indeed introduces non-secure transports.) Presume NACM gained visibility into the security profile of a transport. What would such common policies look like? Where do they get published? Can we make them machine extractable so they can be loaded onto routers as a default profile for a given presumed security level? My suspicion is much of such a profile would simply reduce to "the following nodes are permitted to be covered by the lower security profile". Having markup in the yang to permit extraction by NACM without explicit enumeration in a per-module fashion helps quite a bit. -- Jeff From nobody Fri Aug 26 06:41:26 2016 Return-Path: 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 363E512D8C0; Fri, 26 Aug 2016 06:41:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.845 X-Spam-Level: ** X-Spam-Status: No, score=2.845 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001] autolearn=no 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 kHHibNFj1th9; Fri, 26 Aug 2016 06:41:20 -0700 (PDT) Received: from hickoryhill-consulting.com (50-245-122-97-static.hfc.comcastbusiness.net [50.245.122.97]) (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 E6DE112D806; Fri, 26 Aug 2016 06:28:41 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=74.43.47.166; From: "Susan Hares" To: Date: Fri, 26 Aug 2016 09:27:30 -0400 Message-ID: <086701d1ff9d$98f42320$cadc6960$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0868_01D1FF7C.11E31F60" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdH/nZRqLOLRrhL+SVOMvXFw6nRfXg== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: draft-ietf-i2rs-yang-l3-topology@ietf.org, russ@riw.us, 'Alia Atlas' Subject: [i2rs] WG LC on draft-ietf-i2rs-yang-l3-topology-03.txt (8/26 to 9/9) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Aug 2016 13:41:25 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0868_01D1FF7C.11E31F60 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit This begins a 2 week WG LC on draft-ietf-i2rs-yang-l3-network-topo-05.txt (8/26 to 9/9). The authors should indicate if they know of IPR on this draft by 8/31/2016. In considering this draft, the WG should consider: 1) Does the implementations of this draft in ODL open source code base sufficient experience on the Yang drafts? 2) Does anyone know of other implementations of this model? 3) Do you believe this Yang model is stable enough to publish and distribute to yang libraries? Sue Hares and Russ White Co-chairs ------=_NextPart_000_0868_01D1FF7C.11E31F60 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

This begins = a 2 week WG LC on draft-ietf-i2rs-yang-l3-network-topo-05.txt (8/26 to = 9/9). 

 

The authors should indicate if they know of IPR on = this draft by 8/31/2016.  In considering this draft, the WG should = consider:

 

1)      = Does the implementations of this draft in ODL = open source code base sufficient experience on the Yang drafts? =

2)      = Does anyone know of other implementations of = this model?

3)      = Do you believe this Yang model is stable enough = to publish and distribute to yang libraries?

 

Sue Hares = and Russ White

Co-chairs =

 

 

------=_NextPart_000_0868_01D1FF7C.11E31F60-- From nobody Fri Aug 26 06:41:37 2016 Return-Path: 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 79C2A12D806; Fri, 26 Aug 2016 06:41:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.845 X-Spam-Level: ** X-Spam-Status: No, score=2.845 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001] autolearn=no 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 eHLqya3XhnMo; Fri, 26 Aug 2016 06:41:27 -0700 (PDT) Received: from hickoryhill-consulting.com (50-245-122-97-static.hfc.comcastbusiness.net [50.245.122.97]) (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 05DB012D8FC; Fri, 26 Aug 2016 06:28:50 -0700 (PDT) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=74.43.47.166; From: "Susan Hares" To: Date: Fri, 26 Aug 2016 09:27:39 -0400 Message-ID: <087401d1ff9d$9e6e6b80$db4b4280$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0875_01D1FF7C.175D40B0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdH/nI6CHNIEuQDjSduW/fLB7KGw7Q== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: russ@riw.us, draft-ietf-i2rs-yang-network-topo@ietf.org Subject: [i2rs] WG Last call on the draft-ietf-i2rs-yang-network-topo X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Aug 2016 13:41:31 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0875_01D1FF7C.175D40B0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit This begins a 2 week WG LC on draft-ietf-i2rs-yang-network-topo-05.txt (8/26 to 9/9). The authors should indicate if they know of IPR on this draft by 8/31/2016. In considering this draft, the WG should consider: 1) Does the implementations of this draft in ODL open source code base sufficient experience on the Yang drafts? 2) Does anyone know of other implementations of this model? 3) Do you believe this Yang model is stable enough to publish and distribute to yang libraries? Sue Hares and Russ White Co-chairs ------=_NextPart_000_0875_01D1FF7C.175D40B0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

This = begins a 2 week WG LC on draft-ietf-i2rs-yang-network-topo-05.txt (8/26 = to 9/9). 

 

The authors = should indicate if they know of IPR on this draft by 8/31/2016.  In = considering this draft, the WG should consider:

 

1)      = Does the implementations of this draft in ODL = open source code base sufficient experience on the Yang drafts? =

2)      = Does anyone know of other implementations of = this model?

3)      = Do you believe this Yang model is stable enough = to publish and distribute to yang libraries?

 

Sue Hares = and Russ White

Co-chairs =

 

 

------=_NextPart_000_0875_01D1FF7C.175D40B0-- From nobody Fri Aug 26 06:43:29 2016 Return-Path: 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 0F47412D8CA; Fri, 26 Aug 2016 06:43:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.946 X-Spam-Level: X-Spam-Status: No, score=0.946 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001] autolearn=no 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 bi8LEk5_8odd; Fri, 26 Aug 2016 06:43:19 -0700 (PDT) Received: from hickoryhill-consulting.com (50-245-122-97-static.hfc.comcastbusiness.net [50.245.122.97]) (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 F205112D92A; Fri, 26 Aug 2016 06:31:20 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=74.43.47.166; From: "Susan Hares" To: "'Netconf'" , , "'TEAS WG'" , Date: Fri, 26 Aug 2016 09:30:11 -0400 Message-ID: <088101d1ff9d$f8fddc70$eaf99550$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0882_01D1FF7C.71EDC310" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdH/nc6dK6XhOH24RUiLR0Uhb4KVrg== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Subject: [i2rs] Feedback on WG Last call on the draft-ietf-i2rs-yang-network-topo-05.txt (8/26 to 9/9) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Aug 2016 13:43:24 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0882_01D1FF7C.71EDC310 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit The I2RS WG has begun a WG LC on the Yang data model for network topologies, and looks for feedback from your working on this draft. You may just respond to this email to provide feedback. Sue Hares From: Susan Hares [mailto:shares@ndzh.com] Sent: Friday, August 26, 2016 9:28 AM To: 'i2rs@ietf.org' Cc: 'draft-ietf-i2rs-yang-network-topo@ietf.org'; 'russ@riw.us' Subject: WG Last call on the draft-ietf-i2rs-yang-network-topo This begins a 2 week WG LC on draft-ietf-i2rs-yang-network-topo-05.txt (8/26 to 9/9). The authors should indicate if they know of IPR on this draft by 8/31/2016. In considering this draft, the WG should consider: 1) Does the implementations of this draft in ODL open source code base sufficient experience on the Yang drafts? 2) Does anyone know of other implementations of this model? 3) Do you believe this Yang model is stable enough to publish and distribute to yang libraries? Sue Hares and Russ White Co-chairs ------=_NextPart_000_0882_01D1FF7C.71EDC310 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The I2RS WG has begun a WG LC on the Yang data = model for network topologies, and looks for feedback from your working =  on this draft.  You may just respond to this email to provide = feedback.

 

Sue Hares =

 

From:= = Susan Hares [mailto:shares@ndzh.com]
Sent: Friday, August 26, = 2016 9:28 AM
To: 'i2rs@ietf.org'
Cc: = 'draft-ietf-i2rs-yang-network-topo@ietf.org'; = 'russ@riw.us'
Subject: WG Last call on the = draft-ietf-i2rs-yang-network-topo

 

This begins = a 2 week WG LC on draft-ietf-i2rs-yang-network-topo-05.txt (8/26 to = 9/9). 

 

The authors should indicate if they know of IPR on = this draft by 8/31/2016.  In considering this draft, the WG should = consider:

 

1)      = Does the implementations of this draft in ODL = open source code base sufficient experience on the Yang drafts? =

2)      = Does anyone know of other implementations of = this model?

3)      = Do you believe this Yang model is stable enough = to publish and distribute to yang libraries?

 

Sue Hares = and Russ White

Co-chairs =

 

 

------=_NextPart_000_0882_01D1FF7C.71EDC310-- From nobody Fri Aug 26 06:55:23 2016 Return-Path: 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 E533912D7B0; Fri, 26 Aug 2016 06:55:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.957 X-Spam-Level: X-Spam-Status: No, score=0.957 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_BL=0.01, RCVD_IN_MSPIKE_L5=0.001] autolearn=no 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 7J9mAPQ0t6NY; Fri, 26 Aug 2016 06:55:20 -0700 (PDT) Received: from hickoryhill-consulting.com (50-245-122-97-static.hfc.comcastbusiness.net [50.245.122.97]) (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 D91AC12D815; Fri, 26 Aug 2016 06:43:07 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=74.43.47.166; From: "Susan Hares" To: "'Netconf'" , , , "'TEAS WG'" References: In-Reply-To: Date: Fri, 26 Aug 2016 09:41:58 -0400 Message-ID: <088e01d1ff9f$9e34fa10$da9eee30$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_088F_01D1FF7E.1723F650" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHxkphU7njWmJH4A5s+GBIshhds06AcFslg Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Subject: [i2rs] FW: WG LC on draft-ietf-i2rs-yang-l3-topology-03.txt (8/26 to 9/9) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Aug 2016 13:55:22 -0000 This is a multipart message in MIME format. ------=_NextPart_000_088F_01D1FF7E.1723F650 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit The I2RS WG is starting a WG LC on the L3 network topology model and wishes input. Sue Hares and Russ White From: Susan Hares [mailto:shares@ndzh.com] Sent: Friday, August 26, 2016 9:28 AM To: 'i2rs@ietf.org' Cc: 'draft-ietf-i2rs-yang-l3-topology@ietf.org'; 'Alia Atlas'; 'russ@riw.us' Subject: WG LC on draft-ietf-i2rs-yang-l3-topology-03.txt (8/26 to 9/9) This begins a 2 week WG LC on draft-ietf-i2rs-yang-l3-network-topo-05.txt (8/26 to 9/9). The authors should indicate if they know of IPR on this draft by 8/31/2016. In considering this draft, the WG should consider: 1) Does the implementations of this draft in ODL open source code base sufficient experience on the Yang drafts? 2) Does anyone know of other implementations of this model? 3) Do you believe this Yang model is stable enough to publish and distribute to yang libraries? Sue Hares and Russ White Co-chairs ------=_NextPart_000_088F_01D1FF7E.1723F650 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The I2RS WG is starting a WG LC on the L3 = network topology model and wishes input. 

 

Sue Hares and Russ White =

 

From:= = Susan Hares [mailto:shares@ndzh.com]
Sent: Friday, August 26, = 2016 9:28 AM
To: 'i2rs@ietf.org'
Cc: = 'draft-ietf-i2rs-yang-l3-topology@ietf.org'; 'Alia Atlas'; = 'russ@riw.us'
Subject: WG LC on = draft-ietf-i2rs-yang-l3-topology-03.txt (8/26 to 9/9) =

 

 

This begins = a 2 week WG LC on draft-ietf-i2rs-yang-l3-network-topo-05.txt (8/26 to = 9/9). 

 

The authors should indicate if they know of IPR on = this draft by 8/31/2016.  In considering this draft, the WG should = consider:

 

1)      = Does the implementations of this draft in ODL = open source code base sufficient experience on the Yang drafts? =

2)      = Does anyone know of other implementations of = this model?

3)      = Do you believe this Yang model is stable enough = to publish and distribute to yang libraries?

 

Sue Hares = and Russ White

Co-chairs =

 

 

------=_NextPart_000_088F_01D1FF7E.1723F650-- From nobody Sun Aug 28 04:26:31 2016 Return-Path: <7riw77@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 EAC181288B8 for ; Sun, 28 Aug 2016 04:26:29 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, 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 9P0fhgxl7qu0 for ; Sun, 28 Aug 2016 04:26:28 -0700 (PDT) Received: from mail-qk0-x22e.google.com (mail-qk0-x22e.google.com [IPv6:2607:f8b0:400d:c09::22e]) (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 8D57312D0C5 for ; Sun, 28 Aug 2016 04:26:28 -0700 (PDT) Received: by mail-qk0-x22e.google.com with SMTP id t7so115007439qkh.1 for ; Sun, 28 Aug 2016 04:26:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:date:message-id:mime-version :content-transfer-encoding:thread-index:content-language; bh=uNcRgUR+9AXpwl3GkRxZUT6m8l9V5NiOiZht0VkVtGQ=; b=PpLZLbDrivsjk16TG0WalhLw99IuZHuPeO0yFhA+L7LpR87qJlTRU+pgRvHVUDY7KI 9uy35YSHFBXnuS399B3WfDn9m7r/sp/8/jVDnEdRvVCNIOoILW0786BqlPfLmQcxH0pG eT7Pwt9sHvxGB487hVSVCK0Qr2nq1d1sz7Y1y9484pfWWzn+HKsFxDAb1X1DxPwyrby0 LzyR0L/nlhM468yJiVhyhVstuVPNQhNva89sCcAZilj76Zm86zWdWEdJ8f4LqzOsX1+K roZjWETXB53T0+wdbrAC4K+8xHjVanCheLRfJSCafVZn4bEqPNsm9PE9fauMO7T1RBr7 oB2Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:subject:date:message-id:mime-version :content-transfer-encoding:thread-index:content-language; bh=uNcRgUR+9AXpwl3GkRxZUT6m8l9V5NiOiZht0VkVtGQ=; b=ivy5Lr7aebMufz3krB78p6oKp+kN+/sUvUhsppJ8amliA+K36DUfsBVR3Q2UOwM90M ZkAMlzwLbLVxqQW2FH/kRBIbFxEVrSUCa549EVgDL8KDC1ENhwBhJ6+J/y6jqy6XalRx eCBfWBueKaKBIaWdSsrtTarQt/ezktx0GkYBPSIcug1OLahT4JlbIhrHlM0psgo3JC3T DZHKv2XouU2AWzOycqIKx4+YBiyIjz2+t5qDht7xlRQQhreY435o9x/ZEe20TKrIDlV4 juC9oQCojOnFYpih3SwkoG4wN0COjFdCORY3iGRXgVi3hr7YFICfVDoon19CKIAEV/iZ 0cZQ== X-Gm-Message-State: AE9vXwNu82lkJG10Pr7wUQMAz51obdPoQi7IZCAzP95T3xeNWhf71D0Py9F2QAgRA20dZQ== X-Received: by 10.55.198.129 with SMTP id s1mr12805341qkl.200.1472383587611; Sun, 28 Aug 2016 04:26:27 -0700 (PDT) Received: from Russ (108-78-210-25.lightspeed.chrlnc.sbcglobal.net. [108.78.210.25]) by smtp.gmail.com with ESMTPSA id t126sm15417728qkd.47.2016.08.28.04.26.26 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 28 Aug 2016 04:26:27 -0700 (PDT) From: "Russ White" <7riw77@gmail.com> To: Date: Sun, 28 Aug 2016 07:26:23 -0400 Message-ID: <012501d2011f$030d8f80$0928ae80$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AdIBHrg8fFIGphkWTHOgcOw8RnH6lA== Content-Language: en-us Archived-At: Subject: [i2rs] Consensus on draft-i2rs-ephemeral-state-15.txt X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Aug 2016 11:26:30 -0000 Y'all -- The I2RS WG LC on the RIB Informational Model completed on the 15th of August. We let it run a little long, but it appears the WG has reached consensus on this document. The next steps for this document are Shepherd reviews and routing-area reviews prior to submission to the IESG. Russ & Sue From nobody Sun Aug 28 05:44:56 2016 Return-Path: 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 D707A12D127 for ; Sun, 28 Aug 2016 05:44:54 -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 z3OCH2sxwWWV for ; Sun, 28 Aug 2016 05:44:53 -0700 (PDT) Received: from mail-wm0-x22f.google.com (mail-wm0-x22f.google.com [IPv6:2a00:1450:400c:c09::22f]) (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 12B9412D0CF for ; Sun, 28 Aug 2016 05:44:53 -0700 (PDT) Received: by mail-wm0-x22f.google.com with SMTP id f65so46084493wmi.0 for ; Sun, 28 Aug 2016 05:44:52 -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=j4/mEAx6YwqMS5i3lgWF1Mfm18EDep/AYEt/ygDGO9A=; b=Xuqt+KmUpfrJ/3h3k4ZmjDCpSB7R9DlTVbPAj/NjxcdS1iXmTCo9ECkTYJcUwurMyG tbh0HWjTSA6XQ7oEpDYx1Zdq2LelGzhCElgKeSv65YgXji3DJ8hpynbT5XcaPeRxujkj RQIvLsubvmWhBAq9wcoFccsIhqeQKM8WBqYUvzcStFI1uIoObqB9g+1SkOvHEYHCsrOm +Z/x8h+IkyPfMadqiwdhyKzMnN9Os1efKAyig2qQiJP+9+EUXk27oJh9xHm1T8XOe728 nHoS+NcYmDpFcyqeW9ttlxCJG3EcRc3O1S6nuphiD3wfIiWKCk2fe5HXCmmtthItHVLW GcOA== 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=j4/mEAx6YwqMS5i3lgWF1Mfm18EDep/AYEt/ygDGO9A=; b=a3MnKUcoRoMgMHSjNpZ9OKNfuDGcZgFOU97ld/Rn7Z5Xf9gsyF2E6XcDYju6wToQyr H7T5Jj7BxfuNmMm9uPR3k6QiqTRVrXWuU6w4PczW6PutKNE0OSPp0oSVjk7qIy+zm/eH AKlrNCz/TSd3A8PLiJ1Sj4Kk4FYYu96GNucV/LhFZb6l62/Lz2TsUg4TFsqCpDEkqAO/ Jc+4dJNQPLEvscTLvxBlBpU7SUxAADZyJq9D0JiJAHxMBqr6vbB3QfkcewdmF3unTnv0 asBzEdeWOT78URb/tiiKCXDzTk3v9ZQaagTgrxJFGYnPxFU82bTqxf7Z4tT739X9t9Z5 7LIA== X-Gm-Message-State: AE9vXwMe3CIrL2LCEvtjBDvDKIy9K9OPhuZSbe1IqLOTAS0fabN3hTS+dpe/XB6aTjrCiw== X-Received: by 10.28.109.214 with SMTP id b83mr6041493wmi.19.1472388291512; Sun, 28 Aug 2016 05:44:51 -0700 (PDT) Received: from [192.168.5.12] (236-133.dsl.iskon.hr. [89.164.236.133]) by smtp.gmail.com with ESMTPSA id a2sm29249241wjg.46.2016.08.28.05.44.50 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sun, 28 Aug 2016 05:44:50 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Dean Bogdanovic X-Mailer: iPhone Mail (13G34) In-Reply-To: <012501d2011f$030d8f80$0928ae80$@gmail.com> Date: Sun, 28 Aug 2016 14:44:49 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <7144D2B4-4F3B-4CAC-B323-80A57B7404AE@gmail.com> References: <012501d2011f$030d8f80$0928ae80$@gmail.com> To: Russ White <7riw77@gmail.com> Archived-At: Cc: i2rs@ietf.org Subject: Re: [i2rs] Consensus on draft-i2rs-ephemeral-state-15.txt X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Aug 2016 12:44:55 -0000 Russ, The email subject and the content of the email are different.=20 Are you referring to the draft on ephemeral state or on the RIB info model? I= presume it is on RIB info model, but will let you clarify it Dean > On Aug 28, 2016, at 13:26, Russ White <7riw77@gmail.com> wrote: >=20 > Y'all -- >=20 > The I2RS WG LC on the RIB Informational Model completed on the 15th of > August. We let it run a little long, but it appears the WG has reached > consensus on this document. The next steps for this document are Shepherd > reviews and routing-area reviews prior to submission to the IESG. >=20 > Russ & Sue >=20 >=20 > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs From nobody Sun Aug 28 07:03:46 2016 Return-Path: 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 080CB12B046 for ; Sun, 28 Aug 2016 07:03:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.945 X-Spam-Level: X-Spam-Status: No, score=0.945 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845] autolearn=no 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 VNcvmhb-obaE for ; Sun, 28 Aug 2016 07:03:44 -0700 (PDT) Received: from hickoryhill-consulting.com (50-245-122-97-static.hfc.comcastbusiness.net [50.245.122.97]) (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 C82F512B039 for ; Sun, 28 Aug 2016 07:03:43 -0700 (PDT) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=74.43.47.166; From: "Susan Hares" To: "'Russ White'" <7riw77@gmail.com>, References: <012501d2011f$030d8f80$0928ae80$@gmail.com> In-Reply-To: <012501d2011f$030d8f80$0928ae80$@gmail.com> Date: Sun, 28 Aug 2016 10:02:26 -0400 Message-ID: <001801d20134$cfae75d0$6f0b6170$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQFJeZXwpxig9Gy6D9mOEK2QtHfaAaFvcZyw Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: 'Dean Bogdanovic' Subject: Re: [i2rs] Consensus on draft-i2rs-ephemeral-state-15.txt X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Aug 2016 14:03:45 -0000 Russ: I believe you meant the ephemeral state has completed its working group last call. We did not have a WG LC on the I2RS RIB. Sue -----Original Message----- From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Russ White Sent: Sunday, August 28, 2016 7:26 AM To: i2rs@ietf.org Subject: [i2rs] Consensus on draft-i2rs-ephemeral-state-15.txt Y'all -- The I2RS WG LC on the RIB Informational Model completed on the 15th of August. We let it run a little long, but it appears the WG has reached consensus on this document. The next steps for this document are Shepherd reviews and routing-area reviews prior to submission to the IESG. Russ & Sue _______________________________________________ i2rs mailing list i2rs@ietf.org https://www.ietf.org/mailman/listinfo/i2rs From nobody Sun Aug 28 07:30:14 2016 Return-Path: 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 13C8012B04C for ; Sun, 28 Aug 2016 07:30:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.069 X-Spam-Level: X-Spam-Status: No, score=-15.069 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_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 hSDV9a0zmiLT for ; Sun, 28 Aug 2016 07:30:13 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E537E12B00B for ; Sun, 28 Aug 2016 07:30:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=488; q=dns/txt; s=iport; t=1472394612; x=1473604212; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=LnZrsOcHJKIcEwkJEo+SF2S/YRLM2TUbc89HkSQR/fY=; b=JhBUn+sOb9MAEjneke241KdURqycpWqAkEtrGgBtCDY7yqbvWK04D4ms kTKKTU8sQYAqTTmkb8mQyV9IVA/W2O5/QSIeIxXo6agAuQjg+qt9HGDCH rtq2FlrdRFLaru5dxOzNs+2NU0Mx4NfI+C2WgBOO5SQhgPlY2dwm2c7uk s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CLAQCK9MJX/4QNJK1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBgykBAQEBAR6BAY4AqnaCAYYTCgKBLjgUAQIBAQEBAQEBXieEYgEBBDhRCw4?= =?us-ascii?q?KLlcGAQwIAQGIPL0dAQEBAQEBAQECAQEBAQEBIYYugXgIgk2KHAEEmU+PK4FXi?= =?us-ascii?q?ASFepA9HjaEOCCHAAEBAQ?= X-IronPort-AV: E=Sophos;i="5.28,591,1464652800"; d="scan'208";a="140771626" Received: from alln-core-10.cisco.com ([173.36.13.132]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 28 Aug 2016 14:30:11 +0000 Received: from [10.118.87.88] (rtp-jclarke-nitro7.cisco.com [10.118.87.88]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id u7SEUAgb004227; Sun, 28 Aug 2016 14:30:10 GMT To: Russ White <7riw77@gmail.com>, i2rs@ietf.org References: <012501d2011f$030d8f80$0928ae80$@gmail.com> From: Joe Clarke Organization: Cisco Systems, Inc. Message-ID: <43aeb0c2-cb03-6691-1226-d2e00ee77fc1@cisco.com> Date: Sun, 28 Aug 2016 10:30:09 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <012501d2011f$030d8f80$0928ae80$@gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [i2rs] Consensus on draft-i2rs-ephemeral-state-15.txt X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Aug 2016 14:30:14 -0000 On 8/28/16 07:26, Russ White wrote: > Y'all -- > > The I2RS WG LC on the RIB Informational Model completed on the 15th of > August. We let it run a little long, but it appears the WG has reached > consensus on this document. The next steps for this document are Shepherd > reviews and routing-area reviews prior to submission to the IESG. Assuming the subject is correct :-) I had some additional feedback on ephemeral state on the ML to which I didn't see a response. Joe From nobody Sun Aug 28 07:49:49 2016 Return-Path: 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 8B8AE12B00D for ; Sun, 28 Aug 2016 07:49:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.945 X-Spam-Level: X-Spam-Status: No, score=0.945 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845] autolearn=no 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 U6ORvYHgzM5x for ; Sun, 28 Aug 2016 07:49:46 -0700 (PDT) Received: from hickoryhill-consulting.com (50-245-122-97-static.hfc.comcastbusiness.net [50.245.122.97]) (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 5158412B00B for ; Sun, 28 Aug 2016 07:49:46 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=74.43.47.166; From: "Susan Hares" To: "'Joe Clarke'" , "'Russ White'" <7riw77@gmail.com>, References: <012501d2011f$030d8f80$0928ae80$@gmail.com> <43aeb0c2-cb03-6691-1226-d2e00ee77fc1@cisco.com> In-Reply-To: <43aeb0c2-cb03-6691-1226-d2e00ee77fc1@cisco.com> Date: Sun, 28 Aug 2016 10:48:24 -0400 Message-ID: <01c001d2013b$3cf2a980$b6d7fc80$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQFJeZXwpxig9Gy6D9mOEK2QtHfaAQK9J/4FoVmZzxA= Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Subject: Re: [i2rs] Consensus on draft-i2rs-ephemeral-state-15.txt X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Aug 2016 14:49:47 -0000 Joe: Russ indicated that I forgot to respond to you. I apologize. Watch for the response momentarily. Sue -----Original Message----- From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Joe Clarke Sent: Sunday, August 28, 2016 10:30 AM To: Russ White; i2rs@ietf.org Subject: Re: [i2rs] Consensus on draft-i2rs-ephemeral-state-15.txt On 8/28/16 07:26, Russ White wrote: > Y'all -- > > The I2RS WG LC on the RIB Informational Model completed on the 15th of > August. We let it run a little long, but it appears the WG has reached > consensus on this document. The next steps for this document are > Shepherd reviews and routing-area reviews prior to submission to the IESG. Assuming the subject is correct :-) I had some additional feedback on ephemeral state on the ML to which I didn't see a response. Joe _______________________________________________ i2rs mailing list i2rs@ietf.org https://www.ietf.org/mailman/listinfo/i2rs From nobody Sun Aug 28 08:37:10 2016 Return-Path: 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 E713012B010 for ; Sun, 28 Aug 2016 08:37:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.945 X-Spam-Level: X-Spam-Status: No, score=0.945 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845] autolearn=no 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 kbX1Jb_octjf for ; Sun, 28 Aug 2016 08:37:07 -0700 (PDT) Received: from hickoryhill-consulting.com (50-245-122-97-static.hfc.comcastbusiness.net [50.245.122.97]) (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 A548512B00B for ; Sun, 28 Aug 2016 08:37:07 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=74.43.47.166; From: "Susan Hares" To: "'Joe Clarke'" , References: <00b801d1ecc0$594b0620$0be11260$@ndzh.com> <85dccb29-d395-e206-e53d-42e27e3300a0@cisco.com> In-Reply-To: <85dccb29-d395-e206-e53d-42e27e3300a0@cisco.com> Date: Sun, 28 Aug 2016 11:35:47 -0400 Message-ID: <020801d20141$d9acd3d0$8d067b70$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQKK2u9RuXRaZ/qKcZ/TddJhjST0/QFB/MGCnuK1AHA= Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: russ@riw.us, 'Alia Atlas' Subject: Re: [i2rs] 2 Week WG LC on draft-ephemeral-state-15.txt (8/2 to 8/15) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Aug 2016 15:37:09 -0000 Joe: I'm sorry I missed responding you on August 2nd. It appears I wrote the message and then did not send it. Please see comments below. All changes except the ephemeral state--> ephemeral configuration work for me (WFM). Would you take a moment to look at that point, and then I will release a version with the changes. Sue -----Original Message----- From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Joe Clarke Sent: Tuesday, August 2, 2016 12:38 PM To: Susan Hares; i2rs@ietf.org Cc: russ@riw.us; 'Alia Atlas' Subject: Re: [i2rs] 2 Week WG LC on draft-ephemeral-state-15.txt (8/2 to 8/15) On 8/2/16 09:18, Susan Hares wrote: >> This begins a 2 week WG LC on draft-i2rs-ephemeral-state-15.txt. This >> draft received a "hum" of consensus at IETF 96, and we are now taking >> the final text to a WG Last Call. Please send your comments on the >> requirements to the WG list. >I think this is good. A general comment I have is that "ephemeral state" is used in a number of places where I think "ephemeral configuration" should be used. >This may be a nit, but the device has one state that is dictated by the various configuration types and the operational state. This was raised in BA in the meetings >as well. >My recommendation is to replace "ephemeral state" with "ephemeral >configuration". It's not a show-stopper the way it is, but I think the >latter is a bit clearer. We had agreed that "ephemeral state" as what is defined in section 3. Do you think clarifying this in the text would be better: Old/Ephemeral state is defined as potentially including both ephemeral configured state and operational state. / New/Ephemeral state is defined as potentially including in a data model ephemeral configuration state and operational state which is flagged as ephemeral./ Without this explicit comment, Juergen did not consider Ephemeral-REQ--01 thru Ephemeral-REQ-04 to be specific enough. >One nit I notice is a mixed use of Client/client Agent/agent. Per the last round of RFCs, we are normalizing on client and agent (lowercase). I will fix in version-16. You are correct. After we agree upon the use of ephemeral state. >Section 7, bullet 2: This text reads strangely: > >OLD TEXT: > >The I2RS protocol MUST support the > ability to have data nodes MAY store I2RS client identity and not > the effective priority of the I2RS client at the time the data > node is stored. >PROPOSED NEW TEXT: > >The I2RS protocol MUST support the ability to have data nodes store I2RS client identity and not the effective priority of the I2RS client at > the time the data node is stored. Warning: I am re-writing the ephemeral-protocol-security-requirements so, the reference in bullet may change. You new text works for me. >Section 8: I2RS is written "I2SR" I will fix in version -16 of the text. Thank you. >Section 8: This text is odd >OLD TEXT: >multiple operations in one or more messages handling can handle > errors within the set of operations in many ways. >I'm stumped. This doesn't read as a requirement per se. Yes, the I2RS protocol can support multiple operations within one message or multiple messages. Based >on the fact that atomicity is not provided, an error in one message will have no effect on other messages, even if they are related. So maybe: >PROPOSED NEW TEXT: > >multiple operations in one or more messages; though errors in one message or operation will have no effect on other messages or commands even if they are >related Works for me (WFM): The complete sentences would be: As part of this requirement, the I2SR protocol should support: - multiple operations in one or more messages; though errors in one message or operation will have no effect on other messages or commands even if they are related. - No multi-message commands SHOULD cause errors to be inserted into the I2RS ephemeral state. >Section 9: OLD TEXT: >requirements SHOULD be understood to be expanded to to include > >NEW TEXT: > >requirements SHOULD be understood to be expanded to include Works for me (WFM). If you confirm _______________________________________________ i2rs mailing list i2rs@ietf.org https://www.ietf.org/mailman/listinfo/i2rs From nobody Sun Aug 28 13:05:21 2016 Return-Path: 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 3ED2212D0B9 for ; Sun, 28 Aug 2016 13:05:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.069 X-Spam-Level: X-Spam-Status: No, score=-15.069 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_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 glMuxIYW_tzB for ; Sun, 28 Aug 2016 13:05:19 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5A49812B043 for ; Sun, 28 Aug 2016 13:05:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2856; q=dns/txt; s=iport; t=1472414719; x=1473624319; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=mAY0awvURkl3fXhNkwAIwwrpPTDI0YdXYEyBoOXVucg=; b=OOitm152gJ1a7hNvm2QbNir0Z1YoDZSnHw8fcHG0vm31cZXnTnzIa2oh OLfaDlW0mZjgB5Ys/i2HHNHegqInvGHjjBY93ueiw8Xs8egK7HJsY1shp 6XAlz9DDj2cGo7I8OvshBK3ZrTtNhpgITb8KwfXn6lkOO0HHLylNIAQvp I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AZBgCRQ8NX/4cNJK1UCYNNAQEBAQEeg?= =?us-ascii?q?QG4d4IBhh0CgTA5EwECAQEBAQEBAV4nhGEBAQQBMgEFQQULCw4KLlcGAQwIAQG?= =?us-ascii?q?INAi8cAEBAQEBAQEBAQEBAQEBAQEBAR+GLoF4glWEGYYDAQSUCIVHjyuJW4V6k?= =?us-ascii?q?D0fATSCNByBaCCHAAEBAQ?= X-IronPort-AV: E=Sophos;i="5.28,592,1464652800"; d="scan'208";a="144825981" Received: from alln-core-2.cisco.com ([173.36.13.135]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 28 Aug 2016 20:05:18 +0000 Received: from [10.24.54.169] ([10.24.54.169]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id u7SK5FI6021555; Sun, 28 Aug 2016 20:05:16 GMT To: Susan Hares , i2rs@ietf.org References: <00b801d1ecc0$594b0620$0be11260$@ndzh.com> <85dccb29-d395-e206-e53d-42e27e3300a0@cisco.com> <020801d20141$d9acd3d0$8d067b70$@ndzh.com> From: Joe Clarke Organization: Cisco Systems, Inc. Message-ID: <3a28683e-1e65-632c-4a9d-1e77a7e4fe28@cisco.com> Date: Sun, 28 Aug 2016 16:05:15 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <020801d20141$d9acd3d0$8d067b70$@ndzh.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: russ@riw.us, 'Alia Atlas' Subject: Re: [i2rs] 2 Week WG LC on draft-ephemeral-state-15.txt (8/2 to 8/15) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Aug 2016 20:05:20 -0000 On 8/28/16 11:35, Susan Hares wrote: >> I think this is good. A general comment I have is that "ephemeral state" > is used in a number of places where I think "ephemeral configuration" should > be used. >This may be a nit, but the device has one state that is dictated > by the various configuration types and the operational state. This was > raised in BA in the meetings >as well. > >> My recommendation is to replace "ephemeral state" with "ephemeral >> configuration". It's not a show-stopper the way it is, but I think the >> latter is a bit clearer. > > We had agreed that "ephemeral state" as what is defined in section 3. Do > you think clarifying this in the text would be better: > > Old/Ephemeral state is defined as potentially including both ephemeral > configured state and operational state. / > New/Ephemeral state is defined as potentially including in a data model > ephemeral configuration state and operational state which is flagged as > ephemeral./ > > Without this explicit comment, Juergen did not consider Ephemeral-REQ--01 > thru Ephemeral-REQ-04 to be specific enough. To be clear, I think this is somewhat semantic. A device has one state that is made of a number of related things. But this terminology not a stopping thing for me. In the new text above, would the following not satisfy Jürgen's comment? /Ephemeral state is defined as potentially including in a data model ephemeral configuration and operational state which is flagged as ephemeral./ Note: I simply drop the second "state" as this seems a bit clearer to be (i.e., before it stated, essentially, that ephemeral state includes ephemeral state). >> Section 7, bullet 2: This text reads strangely: >> >> OLD TEXT: >> >> The I2RS protocol MUST support the >> ability to have data nodes MAY store I2RS client identity and not >> the effective priority of the I2RS client at the time the data >> node is stored. > >> PROPOSED NEW TEXT: >> >> The I2RS protocol MUST support the ability to have data nodes store I2RS > client identity and not the effective priority of the I2RS client at >> the time the data node is stored. > > Warning: I am re-writing the ephemeral-protocol-security-requirements so, > the reference in bullet may change. You new text works for me. Thanks and understood. > Works for me (WFM): The complete sentences would be: > > As part of this requirement, the I2SR protocol should support: s/I2SR/I2RS/ :-) > - multiple operations in one or more messages; though errors in one message > or operation will have no effect on other messages or commands even if they > are related. > - No multi-message commands SHOULD cause errors to be inserted into the I2RS > ephemeral state. Works for me. > If you confirm Thanks, Sue. Joe From nobody Sun Aug 28 13:21:42 2016 Return-Path: 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 4418B12B051 for ; Sun, 28 Aug 2016 13:21:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.945 X-Spam-Level: X-Spam-Status: No, score=0.945 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845] autolearn=no 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 IcyDHfVLo095 for ; Sun, 28 Aug 2016 13:21:40 -0700 (PDT) Received: from hickoryhill-consulting.com (50-245-122-97-static.hfc.comcastbusiness.net [50.245.122.97]) (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 E44C612B043 for ; Sun, 28 Aug 2016 13:21:39 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=74.43.47.166; From: "Susan Hares" To: "'Joe Clarke'" , References: <00b801d1ecc0$594b0620$0be11260$@ndzh.com> <85dccb29-d395-e206-e53d-42e27e3300a0@cisco.com> <020801d20141$d9acd3d0$8d067b70$@ndzh.com> <3a28683e-1e65-632c-4a9d-1e77a7e4fe28@cisco.com> In-Reply-To: <3a28683e-1e65-632c-4a9d-1e77a7e4fe28@cisco.com> Date: Sun, 28 Aug 2016 16:20:18 -0400 Message-ID: <000001d20169$98fd59e0$caf80da0$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQKK2u9RuXRaZ/qKcZ/TddJhjST0/QFB/MGCAm8F7EsCjBpmIZ67M0mw Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: russ@riw.us, 'Alia Atlas' Subject: Re: [i2rs] 2 Week WG LC on draft-ephemeral-state-15.txt (8/2 to 8/15) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Aug 2016 20:21:41 -0000 Joe: Let's start with the overview, and then go down to words.=20 My concern:=20 The phrasing of this impacts the OPSTATE discussions for Juergen. = Juergen is pushing for ephemeral to just be operational state. Other drafts are pushing for ephemeral state to be configuration and ephemeral state. I = have suggested a different model in the protocol-strawman for I2RS. =20 What is important in this document is to indicate that ephemeral models = have both configuration and operational state. =20 Words:=20 This statement words for me in the beginning of section 3. =20 /Ephemeral state is defined as potentially including in a data model ephemeral configuration and operational state which is flagged as ephemeral./ If this works, for you as well - I'll create a version 16.=20 Sue =20 -----Original Message----- From: Joe Clarke [mailto:jclarke@cisco.com]=20 Sent: Sunday, August 28, 2016 4:05 PM To: Susan Hares; i2rs@ietf.org Cc: russ@riw.us; 'Alia Atlas' Subject: Re: [i2rs] 2 Week WG LC on draft-ephemeral-state-15.txt (8/2 to 8/15) On 8/28/16 11:35, Susan Hares wrote: >> I think this is good. A general comment I have is that "ephemeral = state" > is used in a number of places where I think "ephemeral configuration"=20 > should be used. >This may be a nit, but the device has one state that = > is dictated by the various configuration types and the operational=20 > state. This was raised in BA in the meetings >as well. > >> My recommendation is to replace "ephemeral state" with "ephemeral >> configuration". It's not a show-stopper the way it is, but I think = the >> latter is a bit clearer. > > We had agreed that "ephemeral state" as what is defined in section 3. = > Do you think clarifying this in the text would be better: > > Old/Ephemeral state is defined as potentially including both ephemeral = > configured state and operational state. / New/Ephemeral state is=20 > defined as potentially including in a data model ephemeral=20 > configuration state and operational state which is flagged as=20 > ephemeral./ > > Without this explicit comment, Juergen did not consider=20 > Ephemeral-REQ--01 thru Ephemeral-REQ-04 to be specific enough. To be clear, I think this is somewhat semantic. A device has one state = that is made of a number of related things. But this terminology not a = stopping thing for me. In the new text above, would the following not satisfy J=FCrgen's = comment? /Ephemeral state is defined as potentially including in a data model ephemeral configuration and operational state which is flagged as ephemeral./ Note: I simply drop the second "state" as this seems a bit clearer to be (i.e., before it stated, essentially, that ephemeral state includes ephemeral state). >> Section 7, bullet 2: This text reads strangely: >> >> OLD TEXT: >> >> The I2RS protocol MUST support the >> ability to have data nodes MAY store I2RS client identity and = not >> the effective priority of the I2RS client at the time the data >> node is stored. > >> PROPOSED NEW TEXT: >> >> The I2RS protocol MUST support the ability to have data nodes store=20 >> I2RS > client identity and not the effective priority of the I2RS client at >> the time the data node is stored. > > Warning: I am re-writing the ephemeral-protocol-security-requirements=20 > so, the reference in bullet may change. You new text works for me. Thanks and understood. > Works for me (WFM): The complete sentences would be: > > As part of this requirement, the I2SR protocol should support: s/I2SR/I2RS/ :-) > - multiple operations in one or more messages; though errors in one=20 > message or operation will have no effect on other messages or commands = > even if they are related. > - No multi-message commands SHOULD cause errors to be inserted into=20 > the I2RS ephemeral state. Works for me. > If you confirm Thanks, Sue. Joe From nobody Sun Aug 28 13:32:57 2016 Return-Path: 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 4D96612B047 for ; Sun, 28 Aug 2016 13:32:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.069 X-Spam-Level: X-Spam-Status: No, score=-15.069 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_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 ChmuO-41M2FV for ; Sun, 28 Aug 2016 13:32:54 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B3C5812B043 for ; Sun, 28 Aug 2016 13:32:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4272; q=dns/txt; s=iport; t=1472416374; x=1473625974; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=hitthheKKCEUIR6zw9EvPQV2itdFvzRzadogkys7umM=; b=Wtbk2Zg805pxWyNb2WBfFRVjH+tLyfVOntt9mPoS+zZIG/Vqo/o4Jnie t+shdrX9g0/U7MppZbTjZGQ8aFh9Y4ImRxENn7To6+JBlmO38pXe3G4CM gD8LMh18n59RyEC69x+qAvmr9MiEKEa/TIh6Orwnaf53K6Se7j3ywX1UB Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BhAgApScNX/5pdJa1UCYNNAQEBAQEeV?= =?us-ascii?q?ypSuCWCASSFeQKBMDgUAQIBAQEBAQEBXieEYQEBBAEBATABBTYLDAQLDgMEAQE?= =?us-ascii?q?BJwcnHwkIBgEMBgIBAYg0CA68YwEBAQEBAQEBAQEBAQEBAQEBAQEBARcFhi6Be?= =?us-ascii?q?AiCTYQZhgMBBJQIhUePK4lbhXqMRIN5HjaCNByBaCA0hkwBAQE?= X-IronPort-AV: E=Sophos;i="5.28,592,1464652800"; d="scan'208";a="144830030" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 28 Aug 2016 20:32:53 +0000 Received: from [10.24.54.169] ([10.24.54.169]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id u7SKWqkP029468; Sun, 28 Aug 2016 20:32:52 GMT To: Susan Hares , i2rs@ietf.org References: <00b801d1ecc0$594b0620$0be11260$@ndzh.com> <85dccb29-d395-e206-e53d-42e27e3300a0@cisco.com> <020801d20141$d9acd3d0$8d067b70$@ndzh.com> <3a28683e-1e65-632c-4a9d-1e77a7e4fe28@cisco.com> <000001d20169$98fd59e0$caf80da0$@ndzh.com> From: Joe Clarke Organization: Cisco Systems, Inc. Message-ID: <74928d20-79f1-6604-b051-02e118f98592@cisco.com> Date: Sun, 28 Aug 2016 16:32:51 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <000001d20169$98fd59e0$caf80da0$@ndzh.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: russ@riw.us, 'Alia Atlas' Subject: Re: [i2rs] 2 Week WG LC on draft-ephemeral-state-15.txt (8/2 to 8/15) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Aug 2016 20:32:56 -0000 On 8/28/16 16:20, Susan Hares wrote: > Joe: > > Let's start with the overview, and then go down to words. > > My concern: > The phrasing of this impacts the OPSTATE discussions for Juergen. Juergen > is pushing for ephemeral to just be operational state. Other drafts are > pushing for ephemeral state to be configuration and ephemeral state. I have > suggested a different model in the protocol-strawman for I2RS. > > What is important in this document is to indicate that ephemeral models have > both configuration and operational state. Agreed. > > Words: > > This statement words for me in the beginning of section 3. > /Ephemeral state is defined as potentially including in a data model > ephemeral configuration and operational state which is flagged as > ephemeral./ > > If this works, for you as well - I'll create a version 16. Yes, this works. Joe > > Sue > > -----Original Message----- > From: Joe Clarke [mailto:jclarke@cisco.com] > Sent: Sunday, August 28, 2016 4:05 PM > To: Susan Hares; i2rs@ietf.org > Cc: russ@riw.us; 'Alia Atlas' > Subject: Re: [i2rs] 2 Week WG LC on draft-ephemeral-state-15.txt (8/2 to > 8/15) > > On 8/28/16 11:35, Susan Hares wrote: >>> I think this is good. A general comment I have is that "ephemeral state" >> is used in a number of places where I think "ephemeral configuration" >> should be used. >This may be a nit, but the device has one state that >> is dictated by the various configuration types and the operational >> state. This was raised in BA in the meetings >as well. >> >>> My recommendation is to replace "ephemeral state" with "ephemeral >>> configuration". It's not a show-stopper the way it is, but I think the >>> latter is a bit clearer. >> >> We had agreed that "ephemeral state" as what is defined in section 3. >> Do you think clarifying this in the text would be better: >> >> Old/Ephemeral state is defined as potentially including both ephemeral >> configured state and operational state. / New/Ephemeral state is >> defined as potentially including in a data model ephemeral >> configuration state and operational state which is flagged as >> ephemeral./ >> >> Without this explicit comment, Juergen did not consider >> Ephemeral-REQ--01 thru Ephemeral-REQ-04 to be specific enough. > > To be clear, I think this is somewhat semantic. A device has one state that > is made of a number of related things. But this terminology not a stopping > thing for me. > > In the new text above, would the following not satisfy Jürgen's comment? > > /Ephemeral state is defined as potentially including in a data model > ephemeral configuration and operational state which is flagged as > ephemeral./ > > Note: I simply drop the second "state" as this seems a bit clearer to be > (i.e., before it stated, essentially, that ephemeral state includes > ephemeral state). > >>> Section 7, bullet 2: This text reads strangely: >>> >>> OLD TEXT: >>> >>> The I2RS protocol MUST support the >>> ability to have data nodes MAY store I2RS client identity and not >>> the effective priority of the I2RS client at the time the data >>> node is stored. >> >>> PROPOSED NEW TEXT: >>> >>> The I2RS protocol MUST support the ability to have data nodes store >>> I2RS >> client identity and not the effective priority of the I2RS client at >>> the time the data node is stored. >> >> Warning: I am re-writing the ephemeral-protocol-security-requirements >> so, the reference in bullet may change. You new text works for me. > > Thanks and understood. > >> Works for me (WFM): The complete sentences would be: >> >> As part of this requirement, the I2SR protocol should support: > > s/I2SR/I2RS/ :-) > >> - multiple operations in one or more messages; though errors in one >> message or operation will have no effect on other messages or commands >> even if they are related. >> - No multi-message commands SHOULD cause errors to be inserted into >> the I2RS ephemeral state. > > Works for me. > >> If you confirm > > Thanks, Sue. > > Joe > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs > From nobody Sun Aug 28 13:55:55 2016 Return-Path: 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 F2DDB12D0C2 for ; Sun, 28 Aug 2016 13:55:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.945 X-Spam-Level: X-Spam-Status: No, score=0.945 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845] autolearn=no 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 GaMsyUzwypwo for ; Sun, 28 Aug 2016 13:55:51 -0700 (PDT) Received: from hickoryhill-consulting.com (50-245-122-97-static.hfc.comcastbusiness.net [50.245.122.97]) (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 A5C4D12B051 for ; Sun, 28 Aug 2016 13:55:51 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=74.43.47.166; From: "Susan Hares" To: "'Joe Clarke'" , References: <00b801d1ecc0$594b0620$0be11260$@ndzh.com> <85dccb29-d395-e206-e53d-42e27e3300a0@cisco.com> <020801d20141$d9acd3d0$8d067b70$@ndzh.com> <3a28683e-1e65-632c-4a9d-1e77a7e4fe28@cisco.com> <000001d20169$98fd59e0$caf80da0$@ndzh.com> <74928d20-79f1-6604-b051-02e118f98592@cisco.com> In-Reply-To: <74928d20-79f1-6604-b051-02e118f98592@cisco.com> Date: Sun, 28 Aug 2016 16:54:30 -0400 Message-ID: <000c01d2016e$5fc4a980$1f4dfc80$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQKK2u9RuXRaZ/qKcZ/TddJhjST0/QFB/MGCAm8F7EsCjBpmIQEUTZScAWL+zOCep4N44A== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: russ@riw.us, 'Alia Atlas' Subject: Re: [i2rs] 2 Week WG LC on draft-ephemeral-state-15.txt (8/2 to 8/15) X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Aug 2016 20:55:53 -0000 Joe:=20 I will send out version 16 shortly.=20 Sue=20 -----Original Message----- From: Joe Clarke [mailto:jclarke@cisco.com]=20 Sent: Sunday, August 28, 2016 4:33 PM To: Susan Hares; i2rs@ietf.org Cc: russ@riw.us; 'Alia Atlas' Subject: Re: [i2rs] 2 Week WG LC on draft-ephemeral-state-15.txt (8/2 to 8/15) On 8/28/16 16:20, Susan Hares wrote: > Joe: > > Let's start with the overview, and then go down to words. > > My concern: > The phrasing of this impacts the OPSTATE discussions for Juergen. =20 > Juergen is pushing for ephemeral to just be operational state. Other=20 > drafts are pushing for ephemeral state to be configuration and=20 > ephemeral state. I have suggested a different model in the protocol-strawman for I2RS. > > What is important in this document is to indicate that ephemeral=20 > models have both configuration and operational state. Agreed. > > Words: > > This statement words for me in the beginning of section 3. > /Ephemeral state is defined as potentially including in a data model=20 > ephemeral configuration and operational state which is flagged as=20 > ephemeral./ > > If this works, for you as well - I'll create a version 16. Yes, this works. Joe > > Sue > > -----Original Message----- > From: Joe Clarke [mailto:jclarke@cisco.com] > Sent: Sunday, August 28, 2016 4:05 PM > To: Susan Hares; i2rs@ietf.org > Cc: russ@riw.us; 'Alia Atlas' > Subject: Re: [i2rs] 2 Week WG LC on draft-ephemeral-state-15.txt (8/2=20 > to > 8/15) > > On 8/28/16 11:35, Susan Hares wrote: >>> I think this is good. A general comment I have is that "ephemeral state" >> is used in a number of places where I think "ephemeral configuration" >> should be used. >This may be a nit, but the device has one state=20 >> that is dictated by the various configuration types and the=20 >> operational state. This was raised in BA in the meetings >as well. >> >>> My recommendation is to replace "ephemeral state" with "ephemeral >>> configuration". It's not a show-stopper the way it is, but I think = the >>> latter is a bit clearer. >> >> We had agreed that "ephemeral state" as what is defined in section 3. >> Do you think clarifying this in the text would be better: >> >> Old/Ephemeral state is defined as potentially including both=20 >> ephemeral configured state and operational state. / New/Ephemeral=20 >> state is defined as potentially including in a data model ephemeral=20 >> configuration state and operational state which is flagged as=20 >> ephemeral./ >> >> Without this explicit comment, Juergen did not consider >> Ephemeral-REQ--01 thru Ephemeral-REQ-04 to be specific enough. > > To be clear, I think this is somewhat semantic. A device has one=20 > state that is made of a number of related things. But this=20 > terminology not a stopping thing for me. > > In the new text above, would the following not satisfy J=FCrgen's = comment? > > /Ephemeral state is defined as potentially including in a data model=20 > ephemeral configuration and operational state which is flagged as=20 > ephemeral./ > > Note: I simply drop the second "state" as this seems a bit clearer to=20 > be (i.e., before it stated, essentially, that ephemeral state includes = > ephemeral state). > >>> Section 7, bullet 2: This text reads strangely: >>> >>> OLD TEXT: >>> >>> The I2RS protocol MUST support the >>> ability to have data nodes MAY store I2RS client identity and = not >>> the effective priority of the I2RS client at the time the data >>> node is stored. >> >>> PROPOSED NEW TEXT: >>> >>> The I2RS protocol MUST support the ability to have data nodes store=20 >>> I2RS >> client identity and not the effective priority of the I2RS client at >>> the time the data node is stored. >> >> Warning: I am re-writing the ephemeral-protocol-security-requirements >> so, the reference in bullet may change. You new text works for me. > > Thanks and understood. > >> Works for me (WFM): The complete sentences would be: >> >> As part of this requirement, the I2SR protocol should support: > > s/I2SR/I2RS/ :-) > >> - multiple operations in one or more messages; though errors in one=20 >> message or operation will have no effect on other messages or=20 >> commands even if they are related. >> - No multi-message commands SHOULD cause errors to be inserted into=20 >> the I2RS ephemeral state. > > Works for me. > >> If you confirm > > Thanks, Sue. > > Joe > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs > From nobody Mon Aug 29 05:22:48 2016 Return-Path: X-Original-To: i2rs@ietf.org Delivered-To: i2rs@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id F3FC512D73A; Mon, 29 Aug 2016 05:22:43 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.31.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147247336399.14138.12719301248532905942.idtracker@ietfa.amsl.com> Date: Mon, 29 Aug 2016 05:22:43 -0700 Archived-At: Cc: i2rs@ietf.org Subject: [i2rs] I-D Action: draft-ietf-i2rs-ephemeral-state-16.txt X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Aug 2016 12:22:44 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Interface to the Routing System of the IETF. Title : I2RS Ephemeral State Requirements Authors : Jeff Haas Susan Hares Filename : draft-ietf-i2rs-ephemeral-state-16.txt Pages : 11 Date : 2016-08-29 Abstract: This document covers requests to the NETMOD and NETCONF Working Groups for functionality to support the ephemeral state requirements to implement the I2RS architecture. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-i2rs-ephemeral-state/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-i2rs-ephemeral-state-16 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-i2rs-ephemeral-state-16 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Aug 29 05:34:10 2016 Return-Path: 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 A82F612D0F1 for ; Mon, 29 Aug 2016 05:34:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.945 X-Spam-Level: X-Spam-Status: No, score=0.945 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845] autolearn=no 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 5MTYpyoGAJzz for ; Mon, 29 Aug 2016 05:34:08 -0700 (PDT) Received: from hickoryhill-consulting.com (50-245-122-97-static.hfc.comcastbusiness.net [50.245.122.97]) (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 497EF12D529 for ; Mon, 29 Aug 2016 05:34:08 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=74.43.47.166; From: "Susan Hares" To: References: <147247336399.14138.12719301248532905942.idtracker@ietfa.amsl.com> In-Reply-To: <147247336399.14138.12719301248532905942.idtracker@ietfa.amsl.com> Date: Mon, 29 Aug 2016 08:32:49 -0400 Message-ID: <01a601d201f1$74613740$5d23a5c0$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQEb3LGNLFTzpmmGxUpe42AoA3HcAaHMKVTA Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: 'Jeffrey Haas' Subject: [i2rs] FW: I-D Action: draft-ietf-i2rs-ephemeral-state-16.txt X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Aug 2016 12:34:09 -0000 This document includes all the comments made by Joe Clarke during the Working Group Last Call. Sue Hares -----Original Message----- From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of internet-drafts@ietf.org Sent: Monday, August 29, 2016 8:23 AM To: i-d-announce@ietf.org Cc: i2rs@ietf.org Subject: [i2rs] I-D Action: draft-ietf-i2rs-ephemeral-state-16.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Interface to the Routing System of the IETF. Title : I2RS Ephemeral State Requirements Authors : Jeff Haas Susan Hares Filename : draft-ietf-i2rs-ephemeral-state-16.txt Pages : 11 Date : 2016-08-29 Abstract: This document covers requests to the NETMOD and NETCONF Working Groups for functionality to support the ephemeral state requirements to implement the I2RS architecture. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-i2rs-ephemeral-state/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-i2rs-ephemeral-state-16 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-i2rs-ephemeral-state-16 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ i2rs mailing list i2rs@ietf.org https://www.ietf.org/mailman/listinfo/i2rs From nobody Mon Aug 29 05:42:10 2016 Return-Path: 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 920CD12D1BE for ; Mon, 29 Aug 2016 05:42:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.646 X-Spam-Level: *** X-Spam-Status: No, score=3.646 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001] autolearn=no 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 forT26NEbAcQ for ; Mon, 29 Aug 2016 05:42:09 -0700 (PDT) Received: from hickoryhill-consulting.com (50-245-122-97-static.hfc.comcastbusiness.net [50.245.122.97]) (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 C620D12D17E for ; Mon, 29 Aug 2016 05:42:08 -0700 (PDT) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=74.43.47.166; From: "Susan Hares" To: , "'Jeffrey Haas'" Date: Mon, 29 Aug 2016 08:40:48 -0400 Message-ID: <01b801d201f2$920bdc90$b62395b0$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_01B9_01D201D1.0AFAFFE0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdIB8nB86yculSmBScSb3hmFhsGC8Q== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: 'Russ White' <7riw77@gmail.com>, 'Alia Atlas' Subject: [i2rs] IPR for draft-ietf-ephemeral-state-16.txt X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Aug 2016 12:42:09 -0000 This is a multipart message in MIME format. ------=_NextPart_000_01B9_01D201D1.0AFAFFE0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit This is to begin an IPR call for draft-ietf-ephemeral-state-16.txt. The authors should indicate on the list whether they know of any IPR related to this draft. Sue Hares and Russ White ------=_NextPart_000_01B9_01D201D1.0AFAFFE0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

This is to = begin an IPR call for draft-ietf-ephemeral-state-16.txt.  The = authors should indicate on the list whether they know of any IPR related = to this draft.

 

Sue Hares = and Russ White

------=_NextPart_000_01B9_01D201D1.0AFAFFE0-- From nobody Mon Aug 29 06:02:59 2016 Return-Path: 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 2422212D0C5 for ; Mon, 29 Aug 2016 06:02:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.946 X-Spam-Level: X-Spam-Status: No, score=0.946 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001] autolearn=no 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 LBFvBBunQaAa for ; Mon, 29 Aug 2016 06:02:57 -0700 (PDT) Received: from hickoryhill-consulting.com (50-245-122-97-static.hfc.comcastbusiness.net [50.245.122.97]) (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 506C212B01E for ; Mon, 29 Aug 2016 06:02:57 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=74.43.47.166; From: "Susan Hares" To: , "'Jeffrey Haas'" References: <01b801d201f2$920bdc90$b62395b0$@ndzh.com> In-Reply-To: <01b801d201f2$920bdc90$b62395b0$@ndzh.com> Date: Mon, 29 Aug 2016 09:01:38 -0400 Message-ID: <01e101d201f5$7ad4d6f0$707e84d0$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_01E2_01D201D3.F3C3AC20" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJUWoMlwIe6UBYR8oBi+8tRYreGT59bNcPg Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: Cc: 'Russ White' <7riw77@gmail.com>, 'Alia Atlas' Subject: Re: [i2rs] IPR for draft-ietf-ephemeral-state-16.txt X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Aug 2016 13:02:58 -0000 This is a multipart message in MIME format. ------=_NextPart_000_01E2_01D201D3.F3C3AC20 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I do not know of any IPR related to draft-ietf-ephemeral-state-16.txt. Sue Hares From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Susan Hares Sent: Monday, August 29, 2016 8:41 AM To: i2rs@ietf.org; 'Jeffrey Haas' Cc: 'Russ White'; 'Alia Atlas' Subject: [i2rs] IPR for draft-ietf-ephemeral-state-16.txt This is to begin an IPR call for draft-ietf-ephemeral-state-16.txt. The authors should indicate on the list whether they know of any IPR related to this draft. Sue Hares and Russ White ------=_NextPart_000_01E2_01D201D3.F3C3AC20 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I do not know of any IPR related to = draft-ietf-ephemeral-state-16.txt.

 

Sue Hares =

 

From:= = i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Susan = Hares
Sent: Monday, August 29, 2016 8:41 AM
To: = i2rs@ietf.org; 'Jeffrey Haas'
Cc: 'Russ White'; 'Alia = Atlas'
Subject: [i2rs] IPR for = draft-ietf-ephemeral-state-16.txt

 

This is to = begin an IPR call for draft-ietf-ephemeral-state-16.txt.  The = authors should indicate on the list whether they know of any IPR related = to this draft.

 

Sue Hares = and Russ White

------=_NextPart_000_01E2_01D201D3.F3C3AC20-- From nobody Mon Aug 29 10:34:57 2016 Return-Path: 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 2815312D7C1 for ; Mon, 29 Aug 2016 10:34:56 -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 5oJEQCAdHM8R for ; Mon, 29 Aug 2016 10:34:55 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 49A5812D7B9 for ; Mon, 29 Aug 2016 10:34:55 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 888D21E32B; Mon, 29 Aug 2016 13:35:43 -0400 (EDT) Date: Mon, 29 Aug 2016 13:35:43 -0400 From: Jeffrey Haas To: Susan Hares Message-ID: <20160829173543.GA31699@pfrc.org> References: <01b801d201f2$920bdc90$b62395b0$@ndzh.com> <01e101d201f5$7ad4d6f0$707e84d0$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <01e101d201f5$7ad4d6f0$707e84d0$@ndzh.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Cc: i2rs@ietf.org, 'Russ White' <7riw77@gmail.com>, 'Alia Atlas' Subject: Re: [i2rs] IPR for draft-ietf-ephemeral-state-16.txt X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Aug 2016 17:34:56 -0000 On Mon, Aug 29, 2016 at 09:01:38AM -0400, Susan Hares wrote: > I do not know of any IPR related to draft-ietf-ephemeral-state-16.txt. I have no IPR on this draft. -- Jeff From nobody Mon Aug 29 11:54:54 2016 Return-Path: <7riw77@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 CE24312D811 for ; Mon, 29 Aug 2016 11:54:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no 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 NJKDYoTXOzB4 for ; Mon, 29 Aug 2016 11:54:52 -0700 (PDT) Received: from mail-oi0-x229.google.com (mail-oi0-x229.google.com [IPv6:2607:f8b0:4003:c06::229]) (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 F3AB312B04E for ; Mon, 29 Aug 2016 11:54:51 -0700 (PDT) Received: by mail-oi0-x229.google.com with SMTP id f189so209014797oig.3 for ; Mon, 29 Aug 2016 11:54:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:thread-index :content-language; bh=CRcY/SnBjrZIzSBVXTXZzLsb23pWz4/QfRl/3u6YVe0=; b=ROUDGe44OYKFu3iJjgqCWMkKTSexJbu3Phzj/bXT7c4/CA3eFu6knktkMA3DNpwPjg uvGg3pBbEcoXHW2faZ+zhcsG3TCKk/s1SG9OFobfsYsB34jSGImSCS/6MK+Wie9KwDb9 jWssy8GPwrXmk4r1ttVOWylaLxAVU3R0qHrczgloLJHR1L0kXntwnLaBGCzatZE3s3Gv 86Vbhp5GscEDjwjYUw/b6+lY7w6uywKopSxrmfTZlGpkxDgStT4ICO5ZOZEN+jbKvbba 4tFP/XM5hNCgkbJzFTnIWKn/Jg8p+Gj5sUynuLBu1yweMjAHbSrPs2ctewO2O0nHOVEf +pxw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:thread-index :content-language; bh=CRcY/SnBjrZIzSBVXTXZzLsb23pWz4/QfRl/3u6YVe0=; b=KtjhFnarPPzpmB8O4qCgBxwZ2X9YfoE6O2AJfFzfz0twjt3bfBdRWJ3cWX/i+5JYR+ QYmvflHiczKX7xarisImdFl7yK0r/RZe/tmj9f2W6i5Ss88qffwnDkFbScCg2DxJfAjH ovSSiT5aeao1i++olvgNEM+Vopg6IRdjtl/N7/cF7pynLqsIwDe/7whsHhmwlle5f3gP fjWvgyqa0nIexb5D26JqtCNZ9qn33IZk3LePLKZLmkvjG4kTDNwyEXeloJA1rjUU3yAp iaZr9CHui7EwrME4blLh1LlD5KkNW3Gy1ANd0IQkVAf39/dh0A7OujBEP0nk8pZFfJcN mHxw== X-Gm-Message-State: AE9vXwPojt/+n9AYsROBq1oxJKdfPPkHoFw3Dmdstn3PDrux2Ze1U41seMmbmgsNM03D8g== X-Received: by 10.157.20.151 with SMTP id d23mr4645390ote.186.1472496891278; Mon, 29 Aug 2016 11:54:51 -0700 (PDT) Received: from Russ (108-78-210-25.lightspeed.chrlnc.sbcglobal.net. [108.78.210.25]) by smtp.gmail.com with ESMTPSA id 65sm5799675otw.17.2016.08.29.11.54.50 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 29 Aug 2016 11:54:50 -0700 (PDT) From: "Russ White" <7riw77@gmail.com> To: "'Susan Hares'" , , "'Jeffrey Haas'" References: <01b801d201f2$920bdc90$b62395b0$@ndzh.com> In-Reply-To: <01b801d201f2$920bdc90$b62395b0$@ndzh.com> Date: Mon, 29 Aug 2016 14:54:45 -0400 Message-ID: <035a01d20226$d002e870$7008b950$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQJUWoMlwIe6UBYR8oBi+8tRYreGT59bmH7A Content-Language: en-us Archived-At: Cc: 'Alia Atlas' Subject: Re: [i2rs] IPR for draft-ietf-ephemeral-state-16.txt X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Aug 2016 18:54:53 -0000 I do not know of any ipr related to this draft. :-) Russ From nobody Mon Aug 29 11:55:40 2016 Return-Path: <7riw77@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 BC83912B04E for ; Mon, 29 Aug 2016 11:55:38 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, 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 Vu3_XmzEgOQx for ; Mon, 29 Aug 2016 11:55:37 -0700 (PDT) Received: from mail-oi0-x22e.google.com (mail-oi0-x22e.google.com [IPv6:2607:f8b0:4003:c06::22e]) (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 B470612B00D for ; Mon, 29 Aug 2016 11:55:37 -0700 (PDT) Received: by mail-oi0-x22e.google.com with SMTP id c15so208910504oig.0 for ; Mon, 29 Aug 2016 11:55:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:thread-index :content-language; bh=B9R4eVzhNa2PTlbkD2lDSVt8tRE71xakxTwbQcQCFvw=; b=UOaY7e99/bt6pfrElhHnnNSjQIWwBeNrghA/4etRPJcNiajnmwMCi9RyYRj8rKtsrF fYoMHsVgfCiSkfqyFTAdQtBdyoFDzhVjB2ISdjL0hTW9bYnTusfdAsDpMAsMN+a9HYee X5nkmZlI2Gz4iKM07V9bVLRSR0ggk47S+r80Tn2Agrc0QjqAP8vM1azA87MeLru1quiL QjefE3tx1aOwbiCBhlTBnTbG0BXBQFWEQ7S2cuDeh5i0A/m8Quehsw6wgP1dYA37txt9 ZJ1ETzV7CTd5vAwOM7lOZrXyradsnAi6+VcmuGo5NcCE503J2H1EX3/t1+N5EgCNaQqq DXYQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:thread-index :content-language; bh=B9R4eVzhNa2PTlbkD2lDSVt8tRE71xakxTwbQcQCFvw=; b=RgK2Q39DaJjBbFj81p6xFMBaBTxNSyf65euYcqKnLpj+1iaVr5JYCAN5Xk8MDQVvsn Btq86tdPFCxWZIelev6cFpBzybj+/j2IL/jDY4hGhBgedzKksxaEhj9LuOwe9kQak2yP 7zzD5dIPRHdXHLkWnWEEtQY7dGcIYYyAQLGNYqk7+ps+bbeUIMB3LDkwrejmFAVx1NZ5 rV4PcexYD2dsVLI6E4wuNDPMkPiluXiZra9zA6Jb7y7xi2Ly8EmO8FXsReYaOrg3Qowx rUL/RBVYvxcVmJAcLWKkQhljijhSWOm9WLQ3K4kuqdbRFw9coiHTvRSd1d8nevP5pdRu /PnQ== X-Gm-Message-State: AE9vXwNQJeNLgocgbG66UZnFjaqXr1AjTNQDnkyG669xatjkCGK9SLpqLC09LYmlJZWd/g== X-Received: by 10.157.20.239 with SMTP id r44mr13908831otr.54.1472496937154; Mon, 29 Aug 2016 11:55:37 -0700 (PDT) Received: from Russ (108-78-210-25.lightspeed.chrlnc.sbcglobal.net. [108.78.210.25]) by smtp.gmail.com with ESMTPSA id j47sm15225140otd.38.2016.08.29.11.55.36 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 29 Aug 2016 11:55:36 -0700 (PDT) From: "Russ White" <7riw77@gmail.com> To: "'Dean Bogdanovic'" References: <012501d2011f$030d8f80$0928ae80$@gmail.com> <7144D2B4-4F3B-4CAC-B323-80A57B7404AE@gmail.com> In-Reply-To: <7144D2B4-4F3B-4CAC-B323-80A57B7404AE@gmail.com> Date: Mon, 29 Aug 2016 14:55:31 -0400 Message-ID: <036901d20226$eb728750$c25795f0$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQFJeZXwpxig9Gy6D9mOEK2QtHfaAQGwDlvhoWPaIvA= Content-Language: en-us Archived-At: Cc: i2rs@ietf.org Subject: Re: [i2rs] Consensus on draft-i2rs-ephemeral-state-15.txt X-BeenThere: i2rs@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Interface to The Internet Routing System \(IRS\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Aug 2016 18:55:39 -0000 > The email subject and the content of the email are different. > Are you referring to the draft on ephemeral state or on the RIB info model? I > presume it is on RIB info model, but will let you clarify it Ephemeral state! Copy/paste error. :-) Russ