From Sandra.Murphy@sparta.com Tue May 1 02:13:46 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A9AB21F86B4 for ; Tue, 1 May 2012 02:13:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.666 X-Spam-Level: X-Spam-Status: No, score=-103.666 tagged_above=-999 required=5 tests=[AWL=0.933, BAYES_00=-2.599, GB_I_LETTER=-2, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g-Q3ldyiE1By for ; Tue, 1 May 2012 02:13:45 -0700 (PDT) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by ietfa.amsl.com (Postfix) with ESMTP id 462A921F8712 for ; Tue, 1 May 2012 02:13:45 -0700 (PDT) Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.14.4/8.14.4) with ESMTP id q419DiCZ006380 for ; Tue, 1 May 2012 04:13:44 -0500 Received: from Hermes.columbia.ads.sparta.com ([157.185.80.107]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id q419DiU2013240 for ; Tue, 1 May 2012 04:13:44 -0500 Received: from HERMES.columbia.ads.sparta.com ([2002:9db9:506b::9db9:506b]) by Hermes.columbia.ads.sparta.com ([::1]) with mapi id 14.01.0355.002; Tue, 1 May 2012 05:13:44 -0400 From: "Murphy, Sandra" To: "sidr@ietf.org" Thread-Topic: date/time/logistics for Jun meeting in association with nanog Thread-Index: AQHNJLQ3k8m5ei44xEqRhYx+ajp7cZa0qjA6 Date: Tue, 1 May 2012 09:13:43 +0000 Message-ID: <24B20D14B2CD29478C8D5D6E9CBB29F60F705D21@Hermes.columbia.ads.sparta.com> References: <24B20D14B2CD29478C8D5D6E9CBB29F60F70484F@Hermes.columbia.ads.sparta.com> In-Reply-To: <24B20D14B2CD29478C8D5D6E9CBB29F60F70484F@Hermes.columbia.ads.sparta.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.185.63.118] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sidr] date/time/logistics for Jun meeting in association with nanog X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 May 2012 09:13:46 -0000 Note that we are coming up on the four week advance notice deadline for thi= s new date. We are required to announce the interim four weeks ahead of time, which wou= ld be Sun 6 May, this coming Sunday. I doubt the secretariat is working on the weekends. So far we have few responses on which to judge consensus. Please respond, and please respond quickly. The chairs will make the consensus call on Friday morning. RSVP. Keep those cards and letters and messages coming. --Sandy, speaking as wg co-chair ________________________________________ From: sidr-bounces@ietf.org [sidr-bounces@ietf.org] on behalf of Murphy, Sa= ndra [Sandra.Murphy@sparta.com] Sent: Friday, April 27, 2012 4:27 PM To: sidr@ietf.org Subject: [sidr] date/time/logistics for Jun meeting in association with nan= og One of the upcoming sidr interim meetings is scheduled to be held in associ= ation with NANOG 55 in Vancouver. The hope was to attract operators from N= ANOG to attend the sidr meeting. Originally, there were indications that NANOG might be able to provide meet= ing room support for an interim sidr meeting on Wednesday afternoon, 6 Jun.= For that reason, 6 Jun was chosen as the date for the meeting. However, it was pointed out on the list that 6 Jun is World IPv6 Launch Day= (http://www.worldipv6launch.org/). Many operators and many sidr members m= ight have other demands on their hands on that day. Also, NANOG has just told us that they would be able to provide meeting roo= m support, but only on Sunday 3 Jun, 0800-1200. Please respond as to whether you would accept moving the interim meeting to= 3 Jun. [Understand that if the wg desires to keep to the original 6 Jun date, othe= r arrangements will have to be made for meeting space, which may require a = fee.] --Sandy, speaking as wg co-chair _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr= From warren@kumari.net Tue May 1 09:42:02 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C70321E8188 for ; Tue, 1 May 2012 09:42:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.532 X-Spam-Level: X-Spam-Status: No, score=-106.532 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NHOTTHQuFcXy for ; Tue, 1 May 2012 09:42:02 -0700 (PDT) Received: from vimes.kumari.net (vimes.kumari.net [198.186.192.250]) by ietfa.amsl.com (Postfix) with ESMTP id 033F621E80F7 for ; Tue, 1 May 2012 09:42:02 -0700 (PDT) Received: from dhcp-172-19-119-246.cbf.corp.google.com (unknown [64.13.52.115]) by vimes.kumari.net (Postfix) with ESMTPSA id 487221B40305; Tue, 1 May 2012 12:42:01 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Warren Kumari In-Reply-To: Date: Tue, 1 May 2012 12:41:59 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <9D947C51-59C5-40D9-ABD2-286EC0EE7FA7@kumari.net> References: <24B20D14B2CD29478C8D5D6E9CBB29F60F70484F@Hermes.columbia.ads.sparta.com> To: Samuel Weiler X-Mailer: Apple Mail (2.1084) Cc: "Murphy, Sandra" , "sidr@ietf.org" Subject: Re: [sidr] date/time/logistics for Jun meeting in association with nanog X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 May 2012 16:42:02 -0000 On Apr 30, 2012, at 4:33 PM, Samuel Weiler wrote: > On Fri, 27 Apr 2012, Murphy, Sandra wrote: >=20 >> Please respond as to whether you would accept moving the interim = meeting to 3 Jun. >=20 > No, I am not available on 3 June (including for virtual = participation). June 6 and 7 work fine for me. I'm fine with it. Any of the above work for me... W >=20 > -- Sam >=20 > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr >=20 From Anuja.Sonalker@sparta.com Tue May 1 10:17:21 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3CB921E8384 for ; Tue, 1 May 2012 10:17:20 -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=[AWL=0.001, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lNv1fIW-ShwC for ; Tue, 1 May 2012 10:17:20 -0700 (PDT) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by ietfa.amsl.com (Postfix) with ESMTP id 2B48021E8015 for ; Tue, 1 May 2012 10:17:20 -0700 (PDT) Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.14.4/8.14.4) with ESMTP id q41HHJgH010750; Tue, 1 May 2012 12:17:19 -0500 Received: from Hermes.columbia.ads.sparta.com ([157.185.80.107]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id q41HHJdD027099; Tue, 1 May 2012 12:17:19 -0500 Received: from HERMES.columbia.ads.sparta.com ([2002:9db9:506b::9db9:506b]) by Hermes.columbia.ads.sparta.com ([::1]) with mapi id 14.01.0355.002; Tue, 1 May 2012 13:17:18 -0400 From: "Sonalker, Anuja" To: Warren Kumari , Samuel Weiler Thread-Topic: [sidr] date/time/logistics for Jun meeting in association with nanog Thread-Index: AQHNJ7lZCXF3DSBavkmJxOftRCgPQZa1LMfw Date: Tue, 1 May 2012 17:17:17 +0000 Message-ID: References: <24B20D14B2CD29478C8D5D6E9CBB29F60F70484F@Hermes.columbia.ads.sparta.com> <9D947C51-59C5-40D9-ABD2-286EC0EE7FA7@kumari.net> In-Reply-To: <9D947C51-59C5-40D9-ABD2-286EC0EE7FA7@kumari.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.185.81.99] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Murphy, Sandra" , "sidr@ietf.org" Subject: Re: [sidr] date/time/logistics for Jun meeting in association with nanog X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 May 2012 17:17:21 -0000 Any of the above are fine with me too. -Anuja -----Original Message----- From: sidr-bounces@ietf.org [mailto:sidr-bounces@ietf.org] On Behalf Of War= ren Kumari Sent: Tuesday, May 01, 2012 12:42 PM To: Samuel Weiler Cc: Murphy, Sandra; sidr@ietf.org Subject: Re: [sidr] date/time/logistics for Jun meeting in association with= nanog On Apr 30, 2012, at 4:33 PM, Samuel Weiler wrote: > On Fri, 27 Apr 2012, Murphy, Sandra wrote: >=20 >> Please respond as to whether you would accept moving the interim meeting= to 3 Jun. >=20 > No, I am not available on 3 June (including for virtual participation). = June 6 and 7 work fine for me. I'm fine with it. Any of the above work for me... W >=20 > -- Sam >=20 > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr >=20 _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sra@hactrn.net Tue May 1 15:06:29 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B04DB21E8093 for ; Tue, 1 May 2012 15:06:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5R9pnMCrAcWk for ; Tue, 1 May 2012 15:06:28 -0700 (PDT) Received: from cyteen.hactrn.net (cyteen.hactrn.net [66.92.66.68]) by ietfa.amsl.com (Postfix) with ESMTP id AB07011E8072 for ; Tue, 1 May 2012 15:06:28 -0700 (PDT) Received: from thrintun.hactrn.net (thrintun.hactrn.net [IPv6:2002:425c:4242:0:219:d1ff:fe12:5d30]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "thrintun.hactrn.net", Issuer "Grunchweather Associates" (verified OK)) by cyteen.hactrn.net (Postfix) with ESMTPS id 91EFA2846C for ; Tue, 1 May 2012 22:06:26 +0000 (UTC) Received: from thrintun.hactrn.net (localhost [IPv6:::1]) by thrintun.hactrn.net (Postfix) with ESMTP id 6A7A418067 for ; Tue, 1 May 2012 18:06:26 -0400 (EDT) Date: Tue, 01 May 2012 18:06:26 -0400 From: Rob Austein To: sidr@ietf.org In-Reply-To: <24B20D14B2CD29478C8D5D6E9CBB29F60F70484F@Hermes.columbia.ads.sparta.com> References: <24B20D14B2CD29478C8D5D6E9CBB29F60F70484F@Hermes.columbia.ads.sparta.com> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/23.4 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20120501220626.6A7A418067@thrintun.hactrn.net> Subject: Re: [sidr] date/time/logistics for Jun meeting in association with nanog X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 May 2012 22:06:29 -0000 At Fri, 27 Apr 2012 20:27:50 +0000, Sandy Murphy wrote: > > Please respond as to whether you would accept moving the interim > meeting to 3 Jun. > > [Understand that if the wg desires to keep to the original 6 Jun > date, other arrangements will have to be made for meeting space, > which may require a fee.] AFAIK I can make either date. From randy@psg.com Tue May 1 19:05:25 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5325021F88D7 for ; Tue, 1 May 2012 19:05:25 -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=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R8ChSB3OCfV6 for ; Tue, 1 May 2012 19:05:25 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id EE7C521F88D4 for ; Tue, 1 May 2012 19:05:24 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1SPOwV-000JFg-S4 for sidr@ietf.org; Wed, 02 May 2012 02:05:24 +0000 Date: Tue, 01 May 2012 16:05:22 -1000 Message-ID: From: Randy Bush To: sidr wg list User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Subject: Re: [sidr] date/time/logistics for Jun meeting in association with nanog X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 May 2012 02:05:25 -0000 > Please respond as to whether you would accept moving the interim meeting to 3 Jun. would require changing an expensive flight which is already ticketed randy From kotikalapudi.sriram@nist.gov Wed May 2 07:21:37 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B3BD21F85F7 for ; Wed, 2 May 2012 07:21:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.556 X-Spam-Level: X-Spam-Status: No, score=-6.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OacYV4A-VZl7 for ; Wed, 2 May 2012 07:21:36 -0700 (PDT) Received: from wsget2.nist.gov (wsget2.nist.gov [129.6.13.151]) by ietfa.amsl.com (Postfix) with ESMTP id F022B21F85DD for ; Wed, 2 May 2012 07:21:34 -0700 (PDT) Received: from WSXGHUB1.xchange.nist.gov (129.6.18.96) by wsget2.nist.gov (129.6.13.151) with Microsoft SMTP Server (TLS) id 14.1.355.2; Wed, 2 May 2012 10:21:16 -0400 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB1.xchange.nist.gov ([129.6.18.96]) with mapi; Wed, 2 May 2012 10:21:34 -0400 From: "Sriram, Kotikalapudi" To: "sidr wg list (sidr@ietf.org)" , "John Scudder (jgs@juniper.net)" Date: Wed, 2 May 2012 10:21:32 -0400 Thread-Topic: bgpsec-spec S. 4.2 comments Thread-Index: Ac0obtehCy69xThqQruQVHIm4hdoQA== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Subject: [sidr] bgpsec-spec S. 4.2 comments X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 May 2012 14:21:37 -0000 John Scudder asked the following question in an email to the authors of draft-ietf-sidr-bgpsec-protocol: >From: John G. Scudder >Date: Wed, Apr 18, 2012 at 8:00 PM >Subject: bgpsec-spec S. 4.2 comments > >A few misc questions/comments I noticed while perusing S. 4.2: > > "A BGPSEC speaker MUST NOT generate an update message containing the > BGPSEC_Path_Signatures attribute unless it has selected, as the best > route to the given prefix, a route that it received in an update > message containing the BGPSEC_Path_Signatures attribute." > >What's the rationale for this MUST NOT? Certainly it's an assumption of the base >protocol, but I assume it wouldn't need to be called out here unless it bore on >some BGPSEC-specific issue. This is relevant in the context of draft-ietf-idr-add- >paths, which allows non-best paths to be sent in BGP. > The authors have agreed that the above text in the bgpsec spec document (quoted by John) certainly seems problematic. The authors agreed to make the following text substitution: (there was also consensus on this at the SIDR Interim meeting April 30, 2012): "If a BGPSEC router has received an _unsigned_ route from a peer and if it chooses to propagate that route, then it MUST NOT attach any BGPSEC_Path_Signatures attribute to the corresponding update being propagated." It was also agreed that we further add (if not already clearly stated elsewhere in the spec): "If a BGPSEC router has received a _signed_ update, and if it chooses to propagate that route, then the router SHOULD propagate the corresponding update with BGPSEC_Path_Signatures attribute (after adding its own signature)." These substitutions would help keep the text unambiguous, and also inclusive of (or at least not conflicting with) draft-ietf-idr-add-paths. Sriram From jakob.heitz@ericsson.com Wed May 2 08:06:26 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B57A21F8541 for ; Wed, 2 May 2012 08:06:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.353 X-Spam-Level: X-Spam-Status: No, score=-6.353 tagged_above=-999 required=5 tests=[AWL=0.246, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qkeAihC2dYv9 for ; Wed, 2 May 2012 08:06:25 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id F14E911E807F for ; Wed, 2 May 2012 08:06:16 -0700 (PDT) Received: from eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id q42F6Fda004125; Wed, 2 May 2012 10:06:16 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.6]) by eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) with mapi; Wed, 2 May 2012 11:06:10 -0400 From: Jakob Heitz To: "Sriram, Kotikalapudi" Date: Wed, 2 May 2012 11:06:37 -0400 Thread-Topic: [sidr] bgpsec-spec S. 4.2 comments Thread-Index: Ac0odRsrcoeHB3mOQ+e9bOwx5Ui5gw== Message-ID: <01068404-27B5-42B6-B1BF-9F1CABA8B3AA@ericsson.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "John Scudder \(jgs@juniper.net\)" , "sidr wg list \(sidr@ietf.org\)" Subject: Re: [sidr] bgpsec-spec S. 4.2 comments X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 May 2012 15:06:26 -0000 that's also flawed. You should be able to sign anything that you can. Suppose you receive it from an ibgp peer that sourced it but didn't sign it= . -- Jakob Heitz. On May 2, 2012, at 7:21 AM, "Sriram, Kotikalapudi" wrote: > John Scudder asked the following question in an email to the > authors of draft-ietf-sidr-bgpsec-protocol: >=20 >> From: John G. Scudder >> Date: Wed, Apr 18, 2012 at 8:00 PM >> Subject: bgpsec-spec S. 4.2 comments >>=20 >> A few misc questions/comments I noticed while perusing S. 4.2: >>=20 >> "A BGPSEC speaker MUST NOT generate an update message containing the >> BGPSEC_Path_Signatures attribute unless it has selected, as the best >> route to the given prefix, a route that it received in an update >> message containing the BGPSEC_Path_Signatures attribute." >>=20 >> What's the rationale for this MUST NOT? Certainly it's an assumption of = the base >> protocol, but I assume it wouldn't need to be called out here unless it = bore on >> some BGPSEC-specific issue. This is relevant in the context of draft-iet= f-idr-add- >> paths, which allows non-best paths to be sent in BGP. >>=20 >=20 > The authors have agreed that the above text in the bgpsec spec=20 > document (quoted by John) certainly seems problematic. > The authors agreed to make the following text substitution: > (there was also consensus on this at the SIDR Interim meeting April 30, 2= 012): >=20 > "If a BGPSEC router has received an _unsigned_ route from a peer and > if it chooses to propagate that route, then it MUST NOT attach any > BGPSEC_Path_Signatures attribute to the corresponding update being propag= ated." >=20 > It was also agreed that we further add (if not already clearly stated > elsewhere in the spec): >=20 > "If a BGPSEC router has received a _signed_ update, > and if it chooses to propagate that route, then the router SHOULD propaga= te > the corresponding update with BGPSEC_Path_Signatures attribute > (after adding its own signature)." >=20 > These substitutions would help keep the text unambiguous, and > also inclusive of (or at least not conflicting with) draft-ietf-idr-add-p= aths. >=20 > Sriram > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr From kotikalapudi.sriram@nist.gov Wed May 2 08:43:17 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09CE521F85B6 for ; Wed, 2 May 2012 08:43:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.562 X-Spam-Level: X-Spam-Status: No, score=-6.562 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9GzUe6BFxzI6 for ; Wed, 2 May 2012 08:43:15 -0700 (PDT) Received: from wsget1.nist.gov (wsget1.nist.gov [129.6.13.150]) by ietfa.amsl.com (Postfix) with ESMTP id 17F1221F85AE for ; Wed, 2 May 2012 08:43:14 -0700 (PDT) Received: from WSXGHUB2.xchange.nist.gov (129.6.18.19) by wsget1.nist.gov (129.6.13.150) with Microsoft SMTP Server (TLS) id 14.1.355.2; Wed, 2 May 2012 11:43:08 -0400 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB2.xchange.nist.gov ([129.6.18.19]) with mapi; Wed, 2 May 2012 11:42:48 -0400 From: "Sriram, Kotikalapudi" To: Jakob Heitz Date: Wed, 2 May 2012 11:43:11 -0400 Thread-Topic: [sidr] bgpsec-spec S. 4.2 comments Thread-Index: Ac0odRsrcoeHB3mOQ+e9bOwx5Ui5gwAAFKBw Message-ID: References: <01068404-27B5-42B6-B1BF-9F1CABA8B3AA@ericsson.com> In-Reply-To: <01068404-27B5-42B6-B1BF-9F1CABA8B3AA@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Cc: "John Scudder \(jgs@juniper.net\)" , "sidr wg list \(sidr@ietf.org\)" Subject: Re: [sidr] bgpsec-spec S. 4.2 comments X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 May 2012 15:43:17 -0000 >that's also flawed. >You should be able to sign anything that you can. > >Suppose you receive it from an ibgp peer that sourced it but didn't sign it. > >-- >Jakob Heitz. > What a BGPSEC router does when "originating" a new BGPSEC update is covered in Section 4.1. You are right -- the router can receive a prefix route (without an AS path) from an ibgp peer who sourced it, and the method of signing that (or any prefix being originated) is in Section 4.1. The discussion here (and John's comment) is related to text in Section 4.2, where we discuss what a BGPSEC router does when "propagating" a route advertisement. "Propagating" connotes here that the update (or route) was received from an eBGP peer. Sriram From randy@psg.com Wed May 2 10:58:52 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51C0611E8081 for ; Wed, 2 May 2012 10:58:52 -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=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yPOS4nHSuJpG for ; Wed, 2 May 2012 10:58:51 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id C8FB221F8552 for ; Wed, 2 May 2012 10:58:51 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1SPdp8-000LJj-4B; Wed, 02 May 2012 17:58:46 +0000 Date: Wed, 02 May 2012 07:58:45 -1000 Message-ID: From: Randy Bush To: "Sriram, Kotikalapudi" In-Reply-To: References: <01068404-27B5-42B6-B1BF-9F1CABA8B3AA@ericsson.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: "John Scudder \(jgs@juniper.net\)" , "sidr wg list \(sidr@ietf.org\)" Subject: Re: [sidr] bgpsec-spec S. 4.2 comments X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 May 2012 17:58:52 -0000 > The discussion here (and John's comment) is related to text in Section > 4.2, where we discuss what a BGPSEC router does when "propagating" a > route advertisement. "Propagating" connotes here that the update (or > route) was received from an eBGP peer. not exactly. 4.0 says Sections 4.1 and 4.2 cover two cases in which a BGPSEC speaker may generate an update message containing the BGPSEC_Path_Signatures attribute. The first case is that in which the BGPSEC speaker originates a new route advertisement (Section 4.1). That is, the BGPSEC speaker is constructing an update message in which the only AS to appear in the AS_PATH attribute is the speaker's own AS (normally appears once but may appear multiple times if AS prepending is applied). The second case is that in which the BGPSEC speaker receives a route advertisement from a peer and then decides to propagate the route advertisement to an external (eBGP) peer (Section 4.2). That is, the BGPSEC speaker has received a BGPSEC update message and is constructing a new update message for the same NLRI in which the AS_PATH attribute will contain AS number(s) other than the speaker's own AS. From morrowc@ops-netman.net Wed May 2 21:08:36 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D490111E8074 for ; Wed, 2 May 2012 21:08:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9EDTEw1I8G2J for ; Wed, 2 May 2012 21:08:36 -0700 (PDT) Received: from mailserver.ops-netman.net (mailserver.ops-netman.net [IPv6:2001:470:e495:fade:5054:ff:fe79:69db]) by ietfa.amsl.com (Postfix) with ESMTP id 3C77221F8531 for ; Wed, 2 May 2012 21:08:36 -0700 (PDT) Received: from [IPv6:2001:470:e03a:b00b:224:d7ff:fe9a:c078] (unknown [IPv6:2001:470:e03a:b00b:224:d7ff:fe9a:c078]) (Authenticated sender: morrowc@OPS-NETMAN.NET) by mailserver.ops-netman.net (Postfix) with ESMTPSA id 92C9A320348; Thu, 3 May 2012 04:08:35 +0000 (UTC) Message-ID: <4FA204C3.6090503@ops-netman.net> Date: Thu, 03 May 2012 00:08:35 -0400 From: Chris Morrow User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: "sidr-chairs@tools.ietf.org" , sidr@ietf.org, "sidr-ads@tools.ietf.org" X-Enigmail-Version: 1.4.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [sidr] Interim Meeting (Apr 30, 2012) fallout/lessons/room-foo X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 May 2012 04:08:36 -0000 Howdy, for the folks that attended in person, and remotely I think we (chairs) would like to get some feedback on how the meeting was done. I think we know of a few stumbling blocks: 1) late start/technology fail with the webex (probably webex operations failures more than anything - my fault) 2) audio issues (occasionally the webex audio would cut out) 3) local dial-in for webex-call for non-US participants 4) in-room audio failures with respect to typing noise 5) lack of slideware (though really, most of the discussion was based on agenda notes, and slideware wasn't going to be particularly helpful, or so the thought went) 6) microphone discipline for in-room vs external folks, often the in-room folk displayed (me too) an inability to wait their turn (jump into the conversation directly without queuing up, etc) (there are likely others, I'd like to get those from the remote/local folks as well) We tried in this meeting to use: o webex for shared-notes/slides o webex 'voip' audio for those that could make that work o webex PSTN dialin (us-toll-free, us-toll only) for those which could not use webex 'voip' o webex PSTN for in-room audio/bridge-to-webex o jabber for in-meeting communication, disambiguation of speakers, questions and hand-raising/remote-questions. I think the things that worked well were: o PSTN dial-in (especially the addition of local-to-callers numbers in non-US locations) o shared-application for note-taking o jabber for questions/hand-raising/etc I think for this experience webex came out poorly (for me frustrating at best). I'd like to see us either give the meetecho product a whirl (which I think the secretariat supports for us) or go a bit more less all encompassing: o etherpad/shared-doc/etc for notes o shared slides prior to the meeting (no slides, no slot. potentially) o jabber o pstn-bridge and force some better mic/floor discipline. I'd also (and sandy as well) would like some feedback on this message, the meeting, and suggestions for what a direction forward might be. (for sizing I believe we ended up with ~21 folks in-room and 'some number' maybe 10? remote) -Chris co-chair-2-of-3 From randy@psg.com Thu May 3 00:34:52 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C219521F85AA for ; Thu, 3 May 2012 00:34:52 -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=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fUm5LFn6W3gE for ; Thu, 3 May 2012 00:34:52 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id EA95B21F85A8 for ; Thu, 3 May 2012 00:34:51 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1SPqYr-000NY4-U2; Thu, 03 May 2012 07:34:50 +0000 Date: Wed, 02 May 2012 21:34:48 -1000 Message-ID: From: Randy Bush To: Chris Morrow In-Reply-To: <4FA204C3.6090503@ops-netman.net> References: <4FA204C3.6090503@ops-netman.net> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: sidr wg list Subject: Re: [sidr] Interim Meeting (Apr 30, 2012) fallout/lessons/room-foo X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 May 2012 07:34:52 -0000 > 1) late start/technology fail with the webex (probably webex > operations failures more than anything - my fault) http://en.wikipedia.org/wiki/Sound_check > 6) microphone discipline for in-room vs external folks, often the > in-room folk displayed (me too) an inability to wait their turn > (jump into the conversation directly without queuing up, etc) like it or not, when there are 20 people in the room, the need for queue discipline is not obvious. so it becomes more critical that remote folk can break in equally. i would like to hear from folk who participated remotely. ruediger seemed to be able to participate as if he was in the room. which of the 19 semi-functional technologies was he using? (and he is unlikely to get/answer email) in $dayjob, this kind of meeting has video of the participants, which, imiho, aids equality. randy From ietfc@btconnect.com Thu May 3 02:00:18 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B117C21F85FD; Thu, 3 May 2012 02:00:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rfdufkDbKfL1; Thu, 3 May 2012 02:00:18 -0700 (PDT) Received: from am1outboundpool.messaging.microsoft.com (am1ehsobe002.messaging.microsoft.com [213.199.154.205]) by ietfa.amsl.com (Postfix) with ESMTP id 7CA6621F8595; Thu, 3 May 2012 02:00:16 -0700 (PDT) Received: from mail109-am1-R.bigfish.com (10.3.201.229) by AM1EHSOBE006.bigfish.com (10.3.204.26) with Microsoft SMTP Server id 14.1.225.23; Thu, 3 May 2012 09:00:06 +0000 Received: from mail109-am1 (localhost [127.0.0.1]) by mail109-am1-R.bigfish.com (Postfix) with ESMTP id 73E5C4C04EA; Thu, 3 May 2012 09:00:06 +0000 (UTC) X-SpamScore: -38 X-BigFish: PS-38(zzbb2dI9371I936eK103dK542M1432N98dKzz1202hzz1033IL8275bh8275dhz2dh2a8h5a9h668h839hd24h304l) X-Forefront-Antispam-Report: CIP:157.55.224.141; KIP:(null); UIP:(null); IPV:NLI; H:DB3PRD0702HT004.eurprd07.prod.outlook.com; RD:none; EFVD:NLI Received: from mail109-am1 (localhost.localdomain [127.0.0.1]) by mail109-am1 (MessageSwitch) id 1336035605420851_1569; Thu, 3 May 2012 09:00:05 +0000 (UTC) Received: from AM1EHSMHS006.bigfish.com (unknown [10.3.201.250]) by mail109-am1.bigfish.com (Postfix) with ESMTP id 58827A007D; Thu, 3 May 2012 09:00:05 +0000 (UTC) Received: from DB3PRD0702HT004.eurprd07.prod.outlook.com (157.55.224.141) by AM1EHSMHS006.bigfish.com (10.3.207.106) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 3 May 2012 09:00:03 +0000 Received: from BY2PRD0610HT002.namprd06.prod.outlook.com (157.56.236.117) by pod51017.outlook.com (10.3.4.154) with Microsoft SMTP Server (TLS) id 14.15.65.3; Thu, 3 May 2012 09:00:06 +0000 Message-ID: <00d501cd2902$7a53d440$4001a8c0@gateway.2wire.net> From: t.petch To: Christopher Morrow , , References: Date: Thu, 3 May 2012 09:57:39 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [157.56.236.117] X-OriginatorOrg: btconnect.com Subject: Re: [sidr] WGLC: draft-ietf-sidr-bgpsec-pki-profiles X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 May 2012 09:00:18 -0000 A question arising from my ignorance. How do values in the security arc get assigned? Not IANA since there are no IANA considerations, but how then? On the IANA profiles web page I can see (1.3.6.1.5.5.4) and (1.3.6.1.5.5.8) but no 1.3.6.1.5.5.7, just a reference to Russ. Tom Petch ----- Original Message ----- From: "Christopher Morrow" To: ; Sent: Friday, April 13, 2012 10:16 PM Helo WG peoples, The following update posted today. Sean and Tom have come to agreement on their differences, I believe this closes the last open items on this document. Let's start a WGLC for this, ending: 4/27/2012 or 27/4/2012 Thanks! -Chris On Fri, Apr 13, 2012 at 3:03 PM, wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Secure Inter-Domain Routing Working Group of the IETF. > > Title : A Profile for BGPSEC Router Certificates, Certificate Revocation Lists, and Certification Requests > Author(s) : Mark Reynolds > Sean Turner > Steve Kent > Filename : draft-ietf-sidr-bgpsec-pki-profiles-03.txt > Pages : 11 > Date : 2012-04-13 > > This document defines a standard profile for X.509 certificates for > the purposes of supporting validation of Autonomous System (AS) paths > in the Border Gateway Protocol (BGP), as part of an extension to that > protocol known as BGPSEC. BGP is a critical component for the proper > operation of the Internet as a whole. The BGPSEC protocol is under > development as a component to address the requirement to provide > security for the BGP protocol. The goal of BGPSEC is to design a > protocol for full AS path validation based on the use of strong > cryptographic primitives. The end-entity (EE) certificates specified > by this profile are issued under Resource Public Key Infrastructure > (RPKI) Certification Authority (CA) certificates, containing the AS > Identifier Delegation extension, to routers within the Autonomous > System (AS). The certificate asserts that the router(s) holding the > private key are authorized to send out secure route advertisements on > behalf of the specified AS. This document also profiles the > Certificate Revocation List (CRL), profiles the format of > certification requests, and specifies Relying Party certificate path > validation procedures. The document extends the RPKI; therefore, > this documents updates the RPKI Resource Certificates Profile (RFC > 6487). > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-sidr-bgpsec-pki-profiles-03.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > This Internet-Draft can be retrieved at: > ftp://ftp.ietf.org/internet-drafts/draft-ietf-sidr-bgpsec-pki-profiles-03.txt > > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From christopher.morrow@gmail.com Thu May 3 06:52:44 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 530D021F858D for ; Thu, 3 May 2012 06:52:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.581 X-Spam-Level: X-Spam-Status: No, score=-103.581 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3yRthBNOvbdi for ; Thu, 3 May 2012 06:52:43 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7C1BC21F84DC for ; Thu, 3 May 2012 06:52:43 -0700 (PDT) Received: by obbeh20 with SMTP id eh20so2993929obb.31 for ; Thu, 03 May 2012 06:52:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=YBiJ4VYa7ex58yBUFDrg6jHGtY3OgynNUhtvCR+vkuM=; b=eZuiJQgJ4b461zF93ZpRMF8WRAyWJmxYTqSA7LeVrWKd+Ym1G5oVEMmGiQlohJzxW+ EnhKeza7g7WHAp1NT9bYkzQBVIO8rVcJ/7ZA4eohWsRcnqxj8u64qqX9zcnlNllNcHHa t0S3IDtKPX1qiBj7iXr4/amG+qBmTntrvwh3mwPkmLqx+UEyLM2RPc/Y87oX4kr/zIgm ST2yQHgjUh8CNJs1G8HfudZ2jJlOSTolB9sFtM9nUu4XMJvEsA6H0UA2TeB6vA02BIfF c4ixsu48B6iK2IaaLirt8yXATL6e7UOG7UQaCpHIuK/7/eRKGDRkwC8wnxelnoLEVZLt XoJg== MIME-Version: 1.0 Received: by 10.182.174.71 with SMTP id bq7mr2994998obc.29.1336053163135; Thu, 03 May 2012 06:52:43 -0700 (PDT) Sender: christopher.morrow@gmail.com Received: by 10.182.155.39 with HTTP; Thu, 3 May 2012 06:52:43 -0700 (PDT) In-Reply-To: References: <4FA204C3.6090503@ops-netman.net> Date: Thu, 3 May 2012 09:52:43 -0400 X-Google-Sender-Auth: UfXBojcnE5qtqdnVUUovqVEMoNI Message-ID: From: Christopher Morrow To: Randy Bush Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Chris Morrow , sidr wg list Subject: Re: [sidr] Interim Meeting (Apr 30, 2012) fallout/lessons/room-foo X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 May 2012 13:52:44 -0000 On Thu, May 3, 2012 at 3:34 AM, Randy Bush wrote: >> =A0 1) late start/technology fail with the webex (probably webex >> =A0 =A0 =A0 operations failures more than anything - my fault) > > http://en.wikipedia.org/wiki/Sound_check > >> =A0 6) microphone discipline for in-room vs external folks, often the >> =A0 =A0 =A0in-room folk displayed (me too) an inability to wait their tu= rn >> =A0 =A0 =A0(jump into the conversation directly without queuing up, etc) > > like it or not, when there are 20 people in the room, the need for queue > discipline is not obvious. =A0so it becomes more critical that remote fol= k > can break in equally. > > i would like to hear from folk who participated remotely. =A0ruediger > seemed to be able to participate as if he was in the room. =A0which of th= e > 19 semi-functional technologies was he using? =A0(and he is unlikely to > get/answer email) > > in $dayjob, this kind of meeting has video of the participants, which, > imiho, aids equality. agreed, videoconference works quite well for office things (sometimes 2-3 large rooms + 20 or so remote folks at desks) anyways, yes more from remote people. thanks! -chris From morrowc@ops-netman.net Thu May 3 07:14:20 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 922D921F85FF; Thu, 3 May 2012 07:14:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.3 X-Spam-Level: X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AipxCa9FnjZD; Thu, 3 May 2012 07:14:20 -0700 (PDT) Received: from mailserver.ops-netman.net (mailserver.ops-netman.net [IPv6:2001:470:e495:fade:5054:ff:fe79:69db]) by ietfa.amsl.com (Postfix) with ESMTP id D7A6C21F8601; Thu, 3 May 2012 07:14:19 -0700 (PDT) Received: from donkey.her.corp.google.com (unknown [IPv6:2620:0:100a:0:baac:6fff:fe92:fb7a]) (Authenticated sender: morrowc@OPS-NETMAN.NET) by mailserver.ops-netman.net (Postfix) with ESMTPSA id 2FDC0320086; Thu, 3 May 2012 14:14:12 +0000 (UTC) Message-ID: <4FA292AF.2040901@ops-netman.net> Date: Thu, 03 May 2012 10:14:07 -0400 From: Chris Morrow User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: "t.petch" References: <00d501cd2902$7a53d440$4001a8c0@gateway.2wire.net> In-Reply-To: <00d501cd2902$7a53d440$4001a8c0@gateway.2wire.net> X-Enigmail-Version: 1.4.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: sidr-chairs@ietf.org, "sidr-ads@tools.ietf.org" , sidr@ietf.org Subject: Re: [sidr] WGLC: draft-ietf-sidr-bgpsec-pki-profiles X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 May 2012 14:14:20 -0000 On 05/03/2012 03:57 AM, t.petch wrote: > A question arising from my ignorance. > > How do values in the security arc get assigned? Not IANA since there are no > IANA considerations, but how then? good question... the below are asn.1 things, quickly searching around isn't helping me out much either :( Russ, any idea how this happens in practice? 'lick finger, test wind, guess number' seems like the wrong method... > > On the IANA profiles web page I can see > (1.3.6.1.5.5.4) > and > (1.3.6.1.5.5.8) > but no 1.3.6.1.5.5.7, just a reference to Russ. > > > Tom Petch > > ----- Original Message ----- > From: "Christopher Morrow" > To: ; > Sent: Friday, April 13, 2012 10:16 PM > > Helo WG peoples, > The following update posted today. Sean and Tom have come to agreement > on their differences, I believe this closes the last open items on > this document. > > Let's start a WGLC for this, ending: 4/27/2012 or 27/4/2012 > > Thanks! > -Chris > > > On Fri, Apr 13, 2012 at 3:03 PM, wrote: >> >> A New Internet-Draft is available from the on-line Internet-Drafts > directories. This draft is a work item of the Secure Inter-Domain Routing > Working Group of the IETF. >> >> Title : A Profile for BGPSEC Router Certificates, Certificate Revocation > Lists, and Certification Requests >> Author(s) : Mark Reynolds >> Sean Turner >> Steve Kent >> Filename : draft-ietf-sidr-bgpsec-pki-profiles-03.txt >> Pages : 11 >> Date : 2012-04-13 >> >> This document defines a standard profile for X.509 certificates for >> the purposes of supporting validation of Autonomous System (AS) paths >> in the Border Gateway Protocol (BGP), as part of an extension to that >> protocol known as BGPSEC. BGP is a critical component for the proper >> operation of the Internet as a whole. The BGPSEC protocol is under >> development as a component to address the requirement to provide >> security for the BGP protocol. The goal of BGPSEC is to design a >> protocol for full AS path validation based on the use of strong >> cryptographic primitives. The end-entity (EE) certificates specified >> by this profile are issued under Resource Public Key Infrastructure >> (RPKI) Certification Authority (CA) certificates, containing the AS >> Identifier Delegation extension, to routers within the Autonomous >> System (AS). The certificate asserts that the router(s) holding the >> private key are authorized to send out secure route advertisements on >> behalf of the specified AS. This document also profiles the >> Certificate Revocation List (CRL), profiles the format of >> certification requests, and specifies Relying Party certificate path >> validation procedures. The document extends the RPKI; therefore, >> this documents updates the RPKI Resource Certificates Profile (RFC >> 6487). >> >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-ietf-sidr-bgpsec-pki-profiles-03.txt >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> This Internet-Draft can be retrieved at: >> ftp://ftp.ietf.org/internet-drafts/draft-ietf-sidr-bgpsec-pki-profiles-03.txt >> >> _______________________________________________ >> sidr mailing list >> sidr@ietf.org >> https://www.ietf.org/mailman/listinfo/sidr > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr > From mlepinski@bbn.com Thu May 3 10:51:52 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D6EC21F85D3 for ; Thu, 3 May 2012 10:51:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eLkbfzG7no0E for ; Thu, 3 May 2012 10:51:51 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id C475921F85C4 for ; Thu, 3 May 2012 10:51:51 -0700 (PDT) Received: from mail.bbn.com ([128.33.0.48]:51002) by smtp.bbn.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1SQ0Bb-000Exe-3x for sidr@ietf.org; Thu, 03 May 2012 13:51:27 -0400 Received: from [128.89.254.135] by mail.bbn.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1SQ0Bz-0007zS-0R for sidr@ietf.org; Thu, 03 May 2012 13:51:51 -0400 Message-ID: <4FA2C5C6.9030408@bbn.com> Date: Thu, 03 May 2012 13:52:06 -0400 From: Matt Lepinski User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: sidr@ietf.org References: <24B20D14B2CD29478C8D5D6E9CBB29F60F70484F@Hermes.columbia.ads.sparta.com> In-Reply-To: <24B20D14B2CD29478C8D5D6E9CBB29F60F70484F@Hermes.columbia.ads.sparta.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [sidr] date/time/logistics for Jun meeting in association with nanog X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 May 2012 17:51:52 -0000 3 June and (the originally proposed) 6 June both work equally well for me. On 4/27/2012 4:27 PM, Murphy, Sandra wrote: > Also, NANOG has just told us that they would be able to provide meeting room support, but only on Sunday 3 Jun, 0800-1200. > > Please respond as to whether you would accept moving the interim meeting to 3 Jun. > From bew@cisco.com Thu May 3 11:09:13 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4141521F85D3 for ; Thu, 3 May 2012 11:09:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.542 X-Spam-Level: X-Spam-Status: No, score=-110.542 tagged_above=-999 required=5 tests=[AWL=0.057, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tdFYMaXYMGt4 for ; Thu, 3 May 2012 11:09:12 -0700 (PDT) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id 701CC21F85A2 for ; Thu, 3 May 2012 11:09:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=bew@cisco.com; l=774; q=dns/txt; s=iport; t=1336068552; x=1337278152; h=mime-version:subject:from:in-reply-to:date: content-transfer-encoding:message-id:references:to; bh=Sgefv3c8DbJPvUMhQEIzDhLaJAkbmJBE2zQ/eA2wNH0=; b=WssJ52WTn6h/5zwsoo48R8LZlRZLBadhD7IZE0Jx+hcjdi2ugmQYAbCP 8iKOBazgIjBlM4qBoZfKGrWzpjX8aGmhUndepYAMZB7mtDUhKQn3euYXt EHEZMefCy5H7ngfzB+t4Ys6RqSQlhcLGF2beZAMPMIW4wppJCkEJ5wqnK E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAJ3Jok+rRDoJ/2dsb2JhbABBA7J8gQeCCQEBAQMBAQEBDwEnNBALCxguJzAGEyKHZgQBC5pQoBcEjV6CR2MEiGSNGo5ZgWmDCIE8 X-IronPort-AV: E=Sophos;i="4.75,526,1330905600"; d="scan'208";a="40259765" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-1.cisco.com with ESMTP; 03 May 2012 18:09:12 +0000 Received: from dhcp-128-107-147-68.cisco.com (dhcp-128-107-147-68.cisco.com [128.107.147.68]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q43I9CTF019168 for ; Thu, 3 May 2012 18:09:12 GMT Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1257) From: Brian Weis In-Reply-To: <4FA2C5C6.9030408@bbn.com> Date: Thu, 3 May 2012 11:09:13 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <4A536399-6C57-4395-83E5-9727CFACF9AE@cisco.com> References: <24B20D14B2CD29478C8D5D6E9CBB29F60F70484F@Hermes.columbia.ads.sparta.com> <4FA2C5C6.9030408@bbn.com> To: "sidr@ietf.org wg" X-Mailer: Apple Mail (2.1257) Subject: Re: [sidr] date/time/logistics for Jun meeting in association with nanog X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 May 2012 18:09:13 -0000 3 June does not work for me; 6 June (or any other day that week) does. Brian On May 3, 2012, at 10:52 AM, Matt Lepinski wrote: > 3 June and (the originally proposed) 6 June both work equally well for = me. >=20 > On 4/27/2012 4:27 PM, Murphy, Sandra wrote: >> Also, NANOG has just told us that they would be able to provide = meeting room support, but only on Sunday 3 Jun, 0800-1200. >>=20 >> Please respond as to whether you would accept moving the interim = meeting to 3 Jun. >>=20 >=20 > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr --=20 Brian Weis Security Standards and Technology, SRTG, Cisco Systems Telephone: +1 408 526 4796 Email: bew@cisco.com From mlepinski@bbn.com Thu May 3 11:20:08 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FC6F21F854E for ; Thu, 3 May 2012 11:20:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IXtNIZAhdWBO for ; Thu, 3 May 2012 11:20:07 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id F241721F8665 for ; Thu, 3 May 2012 11:20:06 -0700 (PDT) Received: from mail.bbn.com ([128.33.0.48]:60699) by smtp.bbn.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1SQ0cw-000G9n-IE for sidr@ietf.org; Thu, 03 May 2012 14:19:42 -0400 Received: from [128.89.254.135] by mail.bbn.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1SQ0dK-0004F4-An for sidr@ietf.org; Thu, 03 May 2012 14:20:06 -0400 Message-ID: <4FA2CC65.6030406@bbn.com> Date: Thu, 03 May 2012 14:20:21 -0400 From: Matt Lepinski User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: sidr@ietf.org References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------080308050104070705030903" Subject: Re: [sidr] WGLC: draft-ietf-sidr-bgpsec-pki-profiles X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 May 2012 18:20:08 -0000 This is a multi-part message in MIME format. --------------080308050104070705030903 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit I have read the -03 version of bgpsec profiles. I think the current version of the document is solid. But I don't think the protocol spec is quite stable enough to say "we aren't going to be making any changes to the bgpsec protocol that will require a change to the profiles document" ... but I hope the protocol spec will soon (several months) be that stable. - Matt Lepinski On 4/13/2012 5:26 PM, Brian Dickson wrote: > While I think the document may be pretty solid currently, the > meta-issue of the tail wagging the dog exists. > > I.e. There still exists the potential for additional requirements to > surface, > related to the design and implementation of the bgpsec protocol, which > have > the potential to "inform" additional requirements for the EE certs, > and/or other (new) cert types. > > So, even if it passes WGLC intact, I'm of the opinion that it should > be kept in the "hold" buffer, > until the other work goes through more substantial development and > review cycles. > > Brian > > On Fri, Apr 13, 2012 at 4:16 PM, Christopher Morrow > > wrote: > > Helo WG peoples, > The following update posted today. Sean and Tom have come to agreement > on their differences, I believe this closes the last open items on > this document. > > Let's start a WGLC for this, ending: 4/27/2012 or 27/4/2012 > > Thanks! > -Chris > > > On Fri, Apr 13, 2012 at 3:03 PM, > wrote: > > > > A New Internet-Draft is available from the on-line > Internet-Drafts directories. This draft is a work item of the > Secure Inter-Domain Routing Working Group of the IETF. > > > > Title : A Profile for BGPSEC Router > Certificates, Certificate Revocation Lists, and Certification Requests > > Author(s) : Mark Reynolds > > Sean Turner > > Steve Kent > > Filename : draft-ietf-sidr-bgpsec-pki-profiles-03.txt > > Pages : 11 > > Date : 2012-04-13 > > > > This document defines a standard profile for X.509 > certificates for > > the purposes of supporting validation of Autonomous System > (AS) paths > > in the Border Gateway Protocol (BGP), as part of an extension > to that > > protocol known as BGPSEC. BGP is a critical component for the > proper > > operation of the Internet as a whole. The BGPSEC protocol is > under > > development as a component to address the requirement to provide > > security for the BGP protocol. The goal of BGPSEC is to design a > > protocol for full AS path validation based on the use of strong > > cryptographic primitives. The end-entity (EE) certificates > specified > > by this profile are issued under Resource Public Key > Infrastructure > > (RPKI) Certification Authority (CA) certificates, containing > the AS > > Identifier Delegation extension, to routers within the Autonomous > > System (AS). The certificate asserts that the router(s) > holding the > > private key are authorized to send out secure route > advertisements on > > behalf of the specified AS. This document also profiles the > > Certificate Revocation List (CRL), profiles the format of > > certification requests, and specifies Relying Party > certificate path > > validation procedures. The document extends the RPKI; therefore, > > this documents updates the RPKI Resource Certificates Profile (RFC > > 6487). > > > > > > A URL for this Internet-Draft is: > > > http://www.ietf.org/internet-drafts/draft-ietf-sidr-bgpsec-pki-profiles-03.txt > > > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > > > > This Internet-Draft can be retrieved at: > > > ftp://ftp.ietf.org/internet-drafts/draft-ietf-sidr-bgpsec-pki-profiles-03.txt > > > > _______________________________________________ > > sidr mailing list > > sidr@ietf.org > > https://www.ietf.org/mailman/listinfo/sidr > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr > > > > > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr --------------080308050104070705030903 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit I have read the -03 version of bgpsec profiles. I think the current version of the document is solid. But I don't think the protocol spec is quite stable enough to say "we aren't going to be making any changes to the bgpsec protocol that will require a change to the profiles document" ... but I hope the protocol spec will soon (several months) be that stable.

- Matt Lepinski

On 4/13/2012 5:26 PM, Brian Dickson wrote:
While I think the document may be pretty solid currently, the meta-issue of the tail wagging the dog exists.

I.e. There still exists the potential for additional requirements to surface,
related to the design and implementation of the bgpsec protocol, which have
the potential to "inform" additional requirements for the EE certs, and/or other (new) cert types.

So, even if it passes WGLC intact, I'm of the opinion that it should be kept in the "hold" buffer,
until the other work goes through more substantial development and review cycles.

Brian

On Fri, Apr 13, 2012 at 4:16 PM, Christopher Morrow <morrowc.lists@gmail.com> wrote:
Helo WG peoples,
The following update posted today. Sean and Tom have come to agreement
on their differences, I believe this closes the last open items on
this document.

Let's start a WGLC for this, ending: 4/27/2012 or 27/4/2012

Thanks!
-Chris
<co-chair>

On Fri, Apr 13, 2012 at 3:03 PM,  <internet-drafts@ietf.org> wrote:
>
> A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Secure Inter-Domain Routing Working Group of the IETF.
>
>        Title           : A Profile for BGPSEC Router Certificates, Certificate Revocation Lists, and Certification Requests
>        Author(s)       : Mark Reynolds
>                          Sean Turner
>                          Steve Kent
>        Filename        : draft-ietf-sidr-bgpsec-pki-profiles-03.txt
>        Pages           : 11
>        Date            : 2012-04-13
>
>   This document defines a standard profile for X.509 certificates for
>   the purposes of supporting validation of Autonomous System (AS) paths
>   in the Border Gateway Protocol (BGP), as part of an extension to that
>   protocol known as BGPSEC.  BGP is a critical component for the proper
>   operation of the Internet as a whole.  The BGPSEC protocol is under
>   development as a component to address the requirement to provide
>   security for the BGP protocol.  The goal of BGPSEC is to design a
>   protocol for full AS path validation based on the use of strong
>   cryptographic primitives.  The end-entity (EE) certificates specified
>   by this profile are issued under Resource Public Key Infrastructure
>   (RPKI) Certification Authority (CA) certificates, containing the AS
>   Identifier Delegation extension, to routers within the Autonomous
>   System (AS).  The certificate asserts that the router(s) holding the
>   private key are authorized to send out secure route advertisements on
>   behalf of the specified AS.  This document also profiles the
>   Certificate Revocation List (CRL), profiles the format of
>   certification requests, and specifies Relying Party certificate path
>   validation procedures.  The document extends the RPKI; therefore,
>   this documents updates the RPKI Resource Certificates Profile (RFC
>   6487).
>
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-sidr-bgpsec-pki-profiles-03.txt
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> This Internet-Draft can be retrieved at:
> ftp://ftp.ietf.org/internet-drafts/draft-ietf-sidr-bgpsec-pki-profiles-03.txt
>
> _______________________________________________
> sidr mailing list
> sidr@ietf.org
> https://www.ietf.org/mailman/listinfo/sidr
_______________________________________________
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr



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

--------------080308050104070705030903-- From Sandra.Murphy@sparta.com Thu May 3 12:07:17 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D454921F85C2 for ; Thu, 3 May 2012 12:07:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.685 X-Spam-Level: X-Spam-Status: No, score=-103.685 tagged_above=-999 required=5 tests=[AWL=0.914, BAYES_00=-2.599, GB_I_LETTER=-2, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FhYaBgKmSWs0 for ; Thu, 3 May 2012 12:07:16 -0700 (PDT) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by ietfa.amsl.com (Postfix) with ESMTP id 7BBB121F856F for ; Thu, 3 May 2012 12:07:16 -0700 (PDT) Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.14.4/8.14.4) with ESMTP id q43J7FpE001164 for ; Thu, 3 May 2012 14:07:15 -0500 Received: from Hermes.columbia.ads.sparta.com ([157.185.80.107]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id q43J7F37032211 for ; Thu, 3 May 2012 14:07:15 -0500 Received: from HERMES.columbia.ads.sparta.com ([2002:9db9:506b::9db9:506b]) by Hermes.columbia.ads.sparta.com ([::1]) with mapi id 14.01.0355.002; Thu, 3 May 2012 15:07:15 -0400 From: "Murphy, Sandra" To: "sidr@ietf.org" Thread-Topic: date/time/logistics for Jun meeting in association with nanog Thread-Index: AQHNJLQ3k8m5ei44xEqRhYx+ajp7cZa0qjA6gAJGEkM= Date: Thu, 3 May 2012 19:07:14 +0000 Message-ID: <24B20D14B2CD29478C8D5D6E9CBB29F60F706222@Hermes.columbia.ads.sparta.com> References: <24B20D14B2CD29478C8D5D6E9CBB29F60F70484F@Hermes.columbia.ads.sparta.com>, <24B20D14B2CD29478C8D5D6E9CBB29F60F705D21@Hermes.columbia.ads.sparta.com> In-Reply-To: <24B20D14B2CD29478C8D5D6E9CBB29F60F705D21@Hermes.columbia.ads.sparta.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.185.63.118] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sidr] date/time/logistics for Jun meeting in association with nanog X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 May 2012 19:07:18 -0000 A reminder that consensus will be called on Friday morning (early).=0A= =0A= =0A= =0A= --Sandy=0A= =0A= ________________________________________=0A= From: Murphy, Sandra=0A= Sent: Tuesday, May 01, 2012 5:13 AM=0A= To: sidr@ietf.org=0A= Subject: RE: date/time/logistics for Jun meeting in association with nanog= =0A= =0A= Note that we are coming up on the four week advance notice deadline for thi= s new date.=0A= =0A= We are required to announce the interim four weeks ahead of time, which wou= ld be Sun 6 May, this coming Sunday.=0A= =0A= I doubt the secretariat is working on the weekends.=0A= =0A= So far we have few responses on which to judge consensus.=0A= =0A= Please respond, and please respond quickly.=0A= =0A= The chairs will make the consensus call on Friday morning.=0A= =0A= RSVP.=0A= =0A= Keep those cards and letters and messages coming.=0A= =0A= --Sandy, speaking as wg co-chair=0A= =0A= =0A= =0A= ________________________________________=0A= From: sidr-bounces@ietf.org [sidr-bounces@ietf.org] on behalf of Murphy, Sa= ndra [Sandra.Murphy@sparta.com]=0A= Sent: Friday, April 27, 2012 4:27 PM=0A= To: sidr@ietf.org=0A= Subject: [sidr] date/time/logistics for Jun meeting in association with nan= og=0A= =0A= One of the upcoming sidr interim meetings is scheduled to be held in associ= ation with NANOG 55 in Vancouver. The hope was to attract operators from N= ANOG to attend the sidr meeting.=0A= =0A= Originally, there were indications that NANOG might be able to provide meet= ing room support for an interim sidr meeting on Wednesday afternoon, 6 Jun.= For that reason, 6 Jun was chosen as the date for the meeting.=0A= =0A= However, it was pointed out on the list that 6 Jun is World IPv6 Launch Day= (http://www.worldipv6launch.org/). Many operators and many sidr members m= ight have other demands on their hands on that day.=0A= =0A= Also, NANOG has just told us that they would be able to provide meeting roo= m support, but only on Sunday 3 Jun, 0800-1200.=0A= =0A= Please respond as to whether you would accept moving the interim meeting to= 3 Jun.=0A= =0A= [Understand that if the wg desires to keep to the original 6 Jun date, othe= r arrangements will have to be made for meeting space, which may require a = fee.]=0A= =0A= --Sandy, speaking as wg co-chair=0A= _______________________________________________=0A= sidr mailing list=0A= sidr@ietf.org=0A= https://www.ietf.org/mailman/listinfo/sidr=0A= From housley@vigilsec.com Thu May 3 12:38:05 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 445C821F85FC for ; Thu, 3 May 2012 12:38:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0t8fDQL5DFh5 for ; Thu, 3 May 2012 12:38:04 -0700 (PDT) Received: from odin.smetech.net (mail.smetech.net [208.254.26.82]) by ietfa.amsl.com (Postfix) with ESMTP id 5DFAF21F8531 for ; Thu, 3 May 2012 12:38:04 -0700 (PDT) Received: from localhost (unknown [208.254.26.81]) by odin.smetech.net (Postfix) with ESMTP id 55F34F2403F for ; Thu, 3 May 2012 15:38:13 -0400 (EDT) X-Virus-Scanned: amavisd-new at smetech.net Received: from odin.smetech.net ([208.254.26.82]) by localhost (ronin.smetech.net [208.254.26.81]) (amavisd-new, port 10024) with ESMTP id b5e99bJ537Nh for ; Thu, 3 May 2012 15:38:00 -0400 (EDT) Received: from [10.16.123.24] (173-167-193-1-ip-static.hfc.comcastbusiness.net [173.167.193.1]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id E8150F24047 for ; Thu, 3 May 2012 15:38:09 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1084) From: Russ Housley In-Reply-To: <4FA2C5C6.9030408@bbn.com> Date: Thu, 3 May 2012 15:37:59 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <6E482C81-2F54-4E0C-963E-A26F88B04CE8@vigilsec.com> References: <24B20D14B2CD29478C8D5D6E9CBB29F60F70484F@Hermes.columbia.ads.sparta.com> <4FA2C5C6.9030408@bbn.com> To: "sidr@ietf.org wg" X-Mailer: Apple Mail (2.1084) Subject: Re: [sidr] date/time/logistics for Jun meeting in association with nanog X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 May 2012 19:38:05 -0000 3 June is preferable for me; 6 June is acceptable. Russ On May 3, 2012, at 10:52 AM, Matt Lepinski wrote: > 3 June and (the originally proposed) 6 June both work equally well for = me. >=20 > On 4/27/2012 4:27 PM, Murphy, Sandra wrote: >> Also, NANOG has just told us that they would be able to provide = meeting room support, but only on Sunday 3 Jun, 0800-1200. >>=20 >> Please respond as to whether you would accept moving the interim = meeting to 3 Jun. >>=20 >=20 > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr --=20 Brian Weis Security Standards and Technology, SRTG, Cisco Systems Telephone: +1 408 526 4796 Email: bew@cisco.com _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From weiler@watson.org Thu May 3 12:43:37 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43F3B21F85FC for ; Thu, 3 May 2012 12:43:37 -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=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iZzgkzzcLCwP for ; Thu, 3 May 2012 12:43:36 -0700 (PDT) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by ietfa.amsl.com (Postfix) with ESMTP id 422EE21F8628 for ; Thu, 3 May 2012 12:43:36 -0700 (PDT) Received: from fledge.watson.org (localhost.watson.org [127.0.0.1]) by fledge.watson.org (8.14.4/8.14.4) with ESMTP id q43JhZ4p011869; Thu, 3 May 2012 15:43:35 -0400 (EDT) (envelope-from weiler@watson.org) Received: from localhost (weiler@localhost) by fledge.watson.org (8.14.4/8.14.4/Submit) with ESMTP id q43JhZtT011862; Thu, 3 May 2012 15:43:35 -0400 (EDT) (envelope-from weiler@watson.org) X-Authentication-Warning: fledge.watson.org: weiler owned process doing -bs Date: Thu, 3 May 2012 15:43:35 -0400 (EDT) From: Samuel Weiler To: Chris Morrow In-Reply-To: <4FA204C3.6090503@ops-netman.net> Message-ID: References: <4FA204C3.6090503@ops-netman.net> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.3 (fledge.watson.org [127.0.0.1]); Thu, 03 May 2012 15:43:35 -0400 (EDT) Cc: "sidr-ads@tools.ietf.org" , "sidr-chairs@tools.ietf.org" , sidr@ietf.org Subject: Re: [sidr] Interim Meeting (Apr 30, 2012) fallout/lessons/room-foo X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 May 2012 19:43:37 -0000 On Thu, 3 May 2012, Chris Morrow wrote: > I'd also (and sandy as well) would like some feedback on this > message, the meeting, and suggestions for what a direction forward > might be. I will observe that my support for having interims was conditioned on improving the remote participation experience[1]. I think we did not hit the bar on Monday. In the absence of a concrete plan to make further progress, I feel I must withdraw my support for having interims. Knowing one voice in opposition may not change the consensus call for having interims, I'm still going to try to make some constructive suggestions. > 1) late start/technology fail with the webex (probably webex > operations failures more than anything - my fault) I heard grumbling in the room in Reston re: having taken the trouble to travel there only to be faced with a seriously delayed WG meeting. There was talk of wandering off to another location to "get work done". We may need to deeply consider the plan for what happens if we fail at making the tech work in the future. > 2) audio issues (occasionally the webex audio would cut out) I believe some people were using the WebEx "integrated" audio, and the source for that in Reston was not the speakerphone but was instead a single laptop's built-in microphone. That audio was bad and, as you report, would frequently just stop entirely. As best as I could tell, the integrated audio and PSTN call were not connected, and I'm not sure that anyone on the integrated channel could talk back to the room. The PSTN audio outbound from Reston was decent, though not as good as I was hoping for. > 3) local dial-in for webex-call for non-US participants I don't recall seeing a toll-free number for the US. Such would be helpful in the future. I found Sandy's live notes to be very helpful. They would have been better if I could have paged back through them on my own schedule and if they hadn't kept trying to take control of my screen. Jabber worked fine. For those in the room, I think having tables/desks would be more comfortable -- I don't like having my "laptop" on my lap for the duration of a normal WG meeting, and doing that for eight hours is too much. As for future suggestions re: remote participation, I refer back to my note of 27 March: http://www.ietf.org/mail-archive/web/sidr/current/msg04288.html I continue to believe that advance testing, delegation of the tech issues, and providing one microphone per person will help improve the experience. There was a suggestion on Monday to use multiple jabber rooms: one with the (live) notes, and one for discussion/questions/etc. Assuming we don't find a better shared note-taking tool, I'm fine with trying that. Video seems like it might help with integrating the remote folks, though I have little experience doing video with large numbers of remote participants. -- Sam [1] http://www.ietf.org/mail-archive/web/sidr/current/msg04268.html From Sandra.Murphy@sparta.com Thu May 3 15:06:13 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F89921F8618 for ; Thu, 3 May 2012 15:06:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.712 X-Spam-Level: X-Spam-Status: No, score=-102.712 tagged_above=-999 required=5 tests=[AWL=-0.113, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CtiBQdiHm7Dl for ; Thu, 3 May 2012 15:06:12 -0700 (PDT) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by ietfa.amsl.com (Postfix) with ESMTP id 978FD21F8620 for ; Thu, 3 May 2012 15:06:11 -0700 (PDT) Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.14.4/8.14.4) with ESMTP id q43M689m003120; Thu, 3 May 2012 17:06:08 -0500 Received: from Hermes.columbia.ads.sparta.com ([157.185.80.107]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id q43M661a005899; Thu, 3 May 2012 17:06:07 -0500 Received: from HERMES.columbia.ads.sparta.com ([2002:9db9:506b::9db9:506b]) by Hermes.columbia.ads.sparta.com ([::1]) with mapi id 14.01.0355.002; Thu, 3 May 2012 18:06:04 -0400 From: "Murphy, Sandra" To: Samuel Weiler , Chris Morrow Thread-Topic: [sidr] Interim Meeting (Apr 30, 2012) fallout/lessons/room-foo Thread-Index: AQHNKOKpXssTQmoa8EiJmeXhBCAF/Ja4u1aA//+98io= Date: Thu, 3 May 2012 22:06:03 +0000 Message-ID: <24B20D14B2CD29478C8D5D6E9CBB29F60F70752C@Hermes.columbia.ads.sparta.com> References: <4FA204C3.6090503@ops-netman.net>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.185.63.118] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "sidr@ietf.org" , "sidr-chairs@tools.ietf.org" , "sidr-ads@tools.ietf.org" Subject: Re: [sidr] Interim Meeting (Apr 30, 2012) fallout/lessons/room-foo X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 May 2012 22:06:13 -0000 I actually was pleased with the amount of useful participation we had from = remote participants. Of course, that does not mean that all participants w= ere as pleased with their experience.=0A= =0A= I'm glad that you found the note-taking useful. I'm sorry that the typing = of the note taking disturbed the audio. At the time, the choice seemed to = be (a) note taking noise and active telecon, (b) no note taking noise and n= o telecon.=0A= =0A= Why? The idea was that the remote participants would be participating via = webex and so the webex should be used to broadcast the note taking to the r= emote participants. To get the note-taking input into the webex broadcast = meant that the note taking had to be on the webex host. (See below for "in= hindsight") Muting the host in webex wasn't possible because muting the ho= st cut off the webex audio for the remote participants.=0A= =0A= I am not at all sure why the typing noise was coming through. There have b= een suggestions that webex finds a way around a platform's audio settings a= nd can ignore the mute. If true, then despite the fact that the host platf= orm was configured to be mute, the webex was working against that.=0A= =0A= In hindsight, note taking into etherpad on the web (as provided at recent i= etf meetings), would have allowed the webex host platform to broadcast the = notes without being the note taking platform. etherpad -> web -> webex -> = world. Of course, the world can watch the etherpad directly.=0A= =0A= (Powerpoint was chosen as the note taking tool on Monday with the thought t= hat drawings done on the whiteboard could be rendered in powerpoint. That = was a futile thought (creating diagrams in ppt is just too slow) and meant = the remote participants could not scroll back to see what had been typed be= fore.)=0A= =0A= The audio cutting out at various times was the result of various attempts t= o get the typing noise fixed. Different people in the room had various sug= gestions, none of which worked.=0A= =0A= The desktop sharing ceased a handful of times as webex reported problems. = I was told that each time sharing restarted, it took over people's screens= . From my experience in other webex sessions, that is a common feature of = webex. It may be a configurable option, who knows.=0A= =0A= These interim sessions are intended to be intense discussions of thorny iss= ues. So we need:=0A= =0A= real time audio in both directions with world wide access=0A= real time view of presentations=0A= real time note taking=0A= real time chat=0A= real time video?=0A= =0A= One final note. Whatever tools we use have to provide a way to archive the= results.=0A= =0A= Webex can provide all of those, but is proving to be a bit problematic, in = some new way each time.=0A= =0A= Webex has been used for our meetings before, but this time was the first ti= me webex was being used to transmit the note taking and the first time inte= grated conference was used.=0A= =0A= real time audio=0A= webex provides a teleconference number and an integrated conference aud= io (aka voip). this was the first time =0A= (I think) that the integrated conference audio was in use in a sidr mee= ting. the webex telecon number (for ietf) =0A= is US only, so we had some people connected by webex's integrated confe= rence audio. On Monday, we eventually=0A= used an volunteered telecon number with local access worldwide and dial= ed that into the webex telecon. If the=0A= integrated conference audio is not used, the meeting room needs a way t= o dial into the telecon (whichever).=0A= real time view of presentations=0A= on Monday, we were using webex to broadcast the presentations=0A= we could also just upload the presentations to the ietf and be rigorous= about letting remote people know what=0A= slide we are on=0A= (uploading slides means people can scroll back at will, and they need a= n app to view the slides)=0A= real time note taking=0A= on Monday, this was done on the webex host platform. see discussion ab= out typing noise.=0A= we could also use jabber for note taking, as was done in San Diego. bu= t, as has been said, using one jabber room=0A= for both chatting and note taking is not ideal. support for multiple j= abber rooms in the ietf could be explored.=0A= we could also use etherpad for note taking. etherpad also allows for r= emote participation.=0A= either jabber or etherpad allows for scrolling back.=0A= as a matter of fact, webex is generally limiting the participant to wha= tever is being seen on the shared space=0A= real time chat=0A= jabber room support is provided and expected=0A= webex has a chat feature=0A= real time video=0A= if it can be displayed on a desktop, it can be shared in webex=0A= various other apps can share video=0A= =0A= Any combination of these are possible. Do we want webex to do everything o= r do we want to use a collection of different tools?=0A= =0A= =0A= --Sandy, speaking as wg co-chair=0A= =0A= ________________________________________=0A= From: sidr-bounces@ietf.org [sidr-bounces@ietf.org] on behalf of Samuel Wei= ler [weiler@watson.org]=0A= Sent: Thursday, May 03, 2012 3:43 PM=0A= To: Chris Morrow=0A= Cc: sidr-ads@tools.ietf.org; sidr-chairs@tools.ietf.org; sidr@ietf.org=0A= Subject: Re: [sidr] Interim Meeting (Apr 30, 2012) fallout/lessons/room-foo= =0A= =0A= On Thu, 3 May 2012, Chris Morrow wrote:=0A= =0A= > I'd also (and sandy as well) would like some feedback on this=0A= > message, the meeting, and suggestions for what a direction forward=0A= > might be.=0A= =0A= I will observe that my support for having interims was conditioned on=0A= improving the remote participation experience[1]. I think we did not=0A= hit the bar on Monday. In the absence of a concrete plan to make=0A= further progress, I feel I must withdraw my support for having=0A= interims.=0A= =0A= Knowing one voice in opposition may not change the consensus call for=0A= having interims, I'm still going to try to make some constructive=0A= suggestions.=0A= =0A= > 1) late start/technology fail with the webex (probably webex=0A= > operations failures more than anything - my fault)=0A= =0A= I heard grumbling in the room in Reston re: having taken the trouble=0A= to travel there only to be faced with a seriously delayed WG meeting.=0A= There was talk of wandering off to another location to "get work=0A= done". We may need to deeply consider the plan for what happens if we=0A= fail at making the tech work in the future.=0A= =0A= > 2) audio issues (occasionally the webex audio would cut out)=0A= =0A= I believe some people were using the WebEx "integrated" audio, and the=0A= source for that in Reston was not the speakerphone but was instead a=0A= single laptop's built-in microphone. That audio was bad and, as you=0A= report, would frequently just stop entirely. As best as I could tell,=0A= the integrated audio and PSTN call were not connected, and I'm not=0A= sure that anyone on the integrated channel could talk back to the=0A= room.=0A= =0A= The PSTN audio outbound from Reston was decent, though not as good as=0A= I was hoping for.=0A= =0A= > 3) local dial-in for webex-call for non-US participants=0A= =0A= I don't recall seeing a toll-free number for the US. Such would be=0A= helpful in the future.=0A= =0A= I found Sandy's live notes to be very helpful. They would have been=0A= better if I could have paged back through them on my own schedule and=0A= if they hadn't kept trying to take control of my screen. Jabber=0A= worked fine. For those in the room, I think having tables/desks would=0A= be more comfortable -- I don't like having my "laptop" on my lap for=0A= the duration of a normal WG meeting, and doing that for eight hours is=0A= too much.=0A= =0A= As for future suggestions re: remote participation, I refer back to my=0A= note of 27 March:=0A= http://www.ietf.org/mail-archive/web/sidr/current/msg04288.html=0A= =0A= I continue to believe that advance testing, delegation of the tech=0A= issues, and providing one microphone per person will help improve the=0A= experience. There was a suggestion on Monday to use multiple jabber=0A= rooms: one with the (live) notes, and one for=0A= discussion/questions/etc. Assuming we don't find a better shared=0A= note-taking tool, I'm fine with trying that.=0A= =0A= Video seems like it might help with integrating the remote folks,=0A= though I have little experience doing video with large numbers of=0A= remote participants.=0A= =0A= -- Sam=0A= =0A= =0A= [1] http://www.ietf.org/mail-archive/web/sidr/current/msg04268.html=0A= =0A= _______________________________________________=0A= sidr mailing list=0A= sidr@ietf.org=0A= https://www.ietf.org/mailman/listinfo/sidr=0A= From kotikalapudi.sriram@nist.gov Thu May 3 15:07:59 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CBF521F8707 for ; Thu, 3 May 2012 15:07:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.566 X-Spam-Level: X-Spam-Status: No, score=-6.566 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KjjeXxwZe1UC for ; Thu, 3 May 2012 15:07:58 -0700 (PDT) Received: from wsget2.nist.gov (wsget2.nist.gov [129.6.13.151]) by ietfa.amsl.com (Postfix) with ESMTP id A8A0421F8705 for ; Thu, 3 May 2012 15:07:58 -0700 (PDT) Received: from WSXGHUB2.xchange.nist.gov (129.6.18.19) by wsget2.nist.gov (129.6.13.151) with Microsoft SMTP Server (TLS) id 14.1.355.2; Thu, 3 May 2012 18:07:37 -0400 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB2.xchange.nist.gov ([129.6.18.19]) with mapi; Thu, 3 May 2012 18:07:58 -0400 From: "Sriram, Kotikalapudi" To: "Murphy, Sandra" , "sidr@ietf.org" Date: Thu, 3 May 2012 18:07:55 -0400 Thread-Topic: [sidr] date/time/logistics for Jun meeting in association with nanog Thread-Index: Ac0peTDL2ledPAc7SIy49aE2A4q+/Q== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Subject: Re: [sidr] date/time/logistics for Jun meeting in association with nanog X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 May 2012 22:07:59 -0000 I am OK with either date (June 3 or June 6). Sriram > >Please respond as to whether you would accept moving the interim meeting to 3 >Jun. From alexey.melnikov@isode.com Fri May 4 07:32:25 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2A8121F8779 for ; Fri, 4 May 2012 07:32:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.512 X-Spam-Level: X-Spam-Status: No, score=-102.512 tagged_above=-999 required=5 tests=[AWL=0.087, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7Xw4ASLWhBdJ for ; Fri, 4 May 2012 07:32:25 -0700 (PDT) Received: from rufus.isode.com (cl-125.lon-03.gb.sixxs.net [IPv6:2a00:14f0:e000:7c::2]) by ietfa.amsl.com (Postfix) with ESMTP id EFA5C21F85B9 for ; Fri, 4 May 2012 07:32:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1336141942; d=isode.com; s=selector; i=@isode.com; bh=ICyZdgGJIpcrKhWqU8gXBw4z5xBI8WPD4eBCX78zi6s=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=fSjcFa72HC5oG7knF8ybyhB20tERZJPxruUg6VVRAFtcnQHVamzFsu+xRsHLW+4Z2dYdYA xHLZdlJxfVWQlJhA+BQBuJ1eGTLN9/twVIauNca4wp2bNQf5GhWXYCFugvmBrhl5kk3pQ+ feTM27kISqC8wE4SIkwd1GpNCkSDGvI=; Received: from [172.16.1.29] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPSA id ; Fri, 4 May 2012 15:32:21 +0100 X-SMTP-Protocol-Errors: PIPELINING Message-ID: <4FA3E898.9080205@isode.com> Date: Fri, 04 May 2012 15:32:56 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 To: sidr wg MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [sidr] Conclusion: next SIDR interim is June 6th X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 May 2012 14:32:25 -0000 After reviewing feedback from the WG and discussing it with my co-chairs and our ADs, it doesn't seem we have strong enough consensus to change to June 3rd. In addition June 2-5 is a long weekend in UK this year, so blame me for not willing to spend one of these days on the phone ;-). So, the next interim is June 6th. Please mark in your calendars. Thanks, Alexey, as a co-chair. From iesg-secretary@ietf.org Fri May 4 07:53:42 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95ADC21F86F7; Fri, 4 May 2012 07:53:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.505 X-Spam-Level: X-Spam-Status: No, score=-102.505 tagged_above=-999 required=5 tests=[AWL=0.094, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id taI9VwJB1nPA; Fri, 4 May 2012 07:53:40 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9A4F21F8624; Fri, 4 May 2012 07:53:39 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: IESG Secretary To: IETF Announcement List X-Test-IDTracker: no X-IETF-IDTracker: 4.02 Message-ID: <20120504145339.26712.48106.idtracker@ietfa.amsl.com> Date: Fri, 04 May 2012 07:53:39 -0700 Cc: sidr@ietf.org Subject: [sidr] SIDR Working Group Interim Meeting: Wednesday, June 6, 2012 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 May 2012 14:53:42 -0000 The SIDR working group will hold an interim meeting (plus virtual = attendance) on June 6th 2012. Location: Vancouver, Canada Time: 0900 - 1700 PDT Agenda and dial-in information will be posted to the mailing list and will also be available at: From turners@ieca.com Fri May 4 08:36:23 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D38221F870F for ; Fri, 4 May 2012 08:36:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.952 X-Spam-Level: X-Spam-Status: No, score=-101.952 tagged_above=-999 required=5 tests=[AWL=-0.287, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_15=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UHXFQQUHJ9pf for ; Fri, 4 May 2012 08:36:22 -0700 (PDT) Received: from gateway14.websitewelcome.com (gateway14.websitewelcome.com [67.18.70.2]) by ietfa.amsl.com (Postfix) with ESMTP id 7256821F8685 for ; Fri, 4 May 2012 08:36:22 -0700 (PDT) Received: by gateway14.websitewelcome.com (Postfix, from userid 5007) id CF4664D062442; Fri, 4 May 2012 10:36:21 -0500 (CDT) Received: from gator1743.hostgator.com (gator1743.hostgator.com [184.173.253.227]) by gateway14.websitewelcome.com (Postfix) with ESMTP id C1BB84D062422 for ; Fri, 4 May 2012 10:36:21 -0500 (CDT) Received: from [198.180.150.230] (port=49950 helo=thunderfish.local) by gator1743.hostgator.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1SQKYP-0002S5-09; Fri, 04 May 2012 10:36:21 -0500 Message-ID: <4FA3F774.7040803@ieca.com> Date: Fri, 04 May 2012 11:36:20 -0400 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:12.0) Gecko/20120420 Thunderbird/12.0 MIME-Version: 1.0 To: Chris Morrow , "t.petch" References: <00d501cd2902$7a53d440$4001a8c0@gateway.2wire.net> <4FA292AF.2040901@ops-netman.net> In-Reply-To: <4FA292AF.2040901@ops-netman.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator1743.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: v230.vpn.iad.rg.net (thunderfish.local) [198.180.150.230]:49950 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 2 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IxNzQzLmhvc3RnYXRvci5jb20= Cc: sidr@ietf.org, sidr-chairs@ietf.org, "sidr-ads@tools.ietf.org" Subject: Re: [sidr] WGLC: draft-ietf-sidr-bgpsec-pki-profiles X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 May 2012 15:36:23 -0000 On 5/3/12 10:14 AM, Chris Morrow wrote: > > > On 05/03/2012 03:57 AM, t.petch wrote: >> A question arising from my ignorance. >> >> How do values in the security arc get assigned? Not IANA since there are no >> IANA considerations, but how then? > > good question... the below are asn.1 things, quickly searching around > isn't helping me out much either :( > > Russ, any idea how this happens in practice? 'lick finger, test wind, > guess number' seems like the wrong method... Russ Housley controls the pkix arc (has for years). If we need a value from that arc (e.g., for the EKU extension and module OID), then we'll/I'll send a request to Russ for an OID. He then returns an OID after some review. I know he often compiles the modules too. If you're curious about the OIDs under the 1.3.6.1.5.5.7 arc, the values can be found at: http://www.imc.org/ietf-pkix/pkix-oid.asn. The longer term plan is to transition the arc to IANA when PKIX closes. spt >> >> On the IANA profiles web page I can see >> (1.3.6.1.5.5.4) >> and >> (1.3.6.1.5.5.8) >> but no 1.3.6.1.5.5.7, just a reference to Russ. >> >> >> Tom Petch >> >> ----- Original Message ----- >> From: "Christopher Morrow" >> To:; >> Sent: Friday, April 13, 2012 10:16 PM >> >> Helo WG peoples, >> The following update posted today. Sean and Tom have come to agreement >> on their differences, I believe this closes the last open items on >> this document. >> >> Let's start a WGLC for this, ending: 4/27/2012 or 27/4/2012 >> >> Thanks! >> -Chris >> >> >> On Fri, Apr 13, 2012 at 3:03 PM, wrote: >>> >>> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. This draft is a work item of the Secure Inter-Domain Routing >> Working Group of the IETF. >>> >>> Title : A Profile for BGPSEC Router Certificates, Certificate Revocation >> Lists, and Certification Requests >>> Author(s) : Mark Reynolds >>> Sean Turner >>> Steve Kent >>> Filename : draft-ietf-sidr-bgpsec-pki-profiles-03.txt >>> Pages : 11 >>> Date : 2012-04-13 >>> >>> This document defines a standard profile for X.509 certificates for >>> the purposes of supporting validation of Autonomous System (AS) paths >>> in the Border Gateway Protocol (BGP), as part of an extension to that >>> protocol known as BGPSEC. BGP is a critical component for the proper >>> operation of the Internet as a whole. The BGPSEC protocol is under >>> development as a component to address the requirement to provide >>> security for the BGP protocol. The goal of BGPSEC is to design a >>> protocol for full AS path validation based on the use of strong >>> cryptographic primitives. The end-entity (EE) certificates specified >>> by this profile are issued under Resource Public Key Infrastructure >>> (RPKI) Certification Authority (CA) certificates, containing the AS >>> Identifier Delegation extension, to routers within the Autonomous >>> System (AS). The certificate asserts that the router(s) holding the >>> private key are authorized to send out secure route advertisements on >>> behalf of the specified AS. This document also profiles the >>> Certificate Revocation List (CRL), profiles the format of >>> certification requests, and specifies Relying Party certificate path >>> validation procedures. The document extends the RPKI; therefore, >>> this documents updates the RPKI Resource Certificates Profile (RFC >>> 6487). >>> >>> >>> A URL for this Internet-Draft is: >>> http://www.ietf.org/internet-drafts/draft-ietf-sidr-bgpsec-pki-profiles-03.txt >>> >>> Internet-Drafts are also available by anonymous FTP at: >>> ftp://ftp.ietf.org/internet-drafts/ >>> >>> This Internet-Draft can be retrieved at: >>> ftp://ftp.ietf.org/internet-drafts/draft-ietf-sidr-bgpsec-pki-profiles-03.txt >>> >>> _______________________________________________ >>> sidr mailing list >>> sidr@ietf.org >>> https://www.ietf.org/mailman/listinfo/sidr >> _______________________________________________ >> sidr mailing list >> sidr@ietf.org >> https://www.ietf.org/mailman/listinfo/sidr >> > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr > From iesg-secretary@ietf.org Fri May 4 10:45:14 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3D8A21E8024; Fri, 4 May 2012 10:45:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.508 X-Spam-Level: X-Spam-Status: No, score=-102.508 tagged_above=-999 required=5 tests=[AWL=0.091, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F6E950IEhqAa; Fri, 4 May 2012 10:45:14 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D9E111E8073; Fri, 4 May 2012 10:45:14 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: IESG Secretary To: IETF Announcement List X-Test-IDTracker: no X-IETF-IDTracker: 4.02 Message-ID: <20120504174514.9069.65993.idtracker@ietfa.amsl.com> Date: Fri, 04 May 2012 10:45:14 -0700 Cc: sidr@ietf.org Subject: [sidr] UPDATED: SIDR Working Group Interim Meeting: Wednesday, June 6, 2012 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 May 2012 17:45:14 -0000 Please note updated meeting time below. The SIDR working group will hold an interim meeting (plus virtual = attendance) on June 6th 2012. Location: Vancouver, Canada Time: 1300-1700 PDT Agenda and dial-in information will be posted to the mailing list and will also be available at: From jgs@juniper.net Fri May 4 12:43:11 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A50621E8047 for ; Fri, 4 May 2012 12:43:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.583 X-Spam-Level: X-Spam-Status: No, score=-6.583 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7XYzdWoUhgJi for ; Fri, 4 May 2012 12:43:10 -0700 (PDT) Received: from exprod7og112.obsmtp.com (exprod7og112.obsmtp.com [64.18.2.177]) by ietfa.amsl.com (Postfix) with ESMTP id 5CD2921E8042 for ; Fri, 4 May 2012 12:43:03 -0700 (PDT) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob112.postini.com ([64.18.6.12]) with SMTP ID DSNKT6QxRvMmEP/QdUCsnNqHhwZAWTRrhvoU@postini.com; Fri, 04 May 2012 12:43:10 PDT Received: from [172.16.13.202] (172.16.13.202) by P-EMHUB01-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server id 8.3.213.0; Fri, 4 May 2012 12:42:38 -0700 MIME-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset="us-ascii" From: "John G. Scudder" In-Reply-To: <4FA204C3.6090503@ops-netman.net> Date: Fri, 4 May 2012 15:42:37 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: References: <4FA204C3.6090503@ops-netman.net> To: Chris Morrow X-Mailer: Apple Mail (2.1257) Cc: "sidr-ads@tools.ietf.org" , "sidr-chairs@tools.ietf.org" , sidr@ietf.org Subject: Re: [sidr] Interim Meeting (Apr 30, 2012) fallout/lessons/room-foo X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 May 2012 19:43:11 -0000 A few things in addition to what others have said: On May 3, 2012, at 12:08 AM, Chris Morrow wrote: > o shared slides prior to the meeting (no slides, no slot. = potentially) We covered a fair amount of ground at the interim without using slides = at all. Based on that, I'm not sure where this (possible) requirement = comes from? I, for one, am not at all keen to prepare slide decks just = for the fun of it, and I looked at lack of slides at the interim as a = plus, not a minus. Yes, if slides are used -- and I'm not against it = when useful/desired -- they should be distributed. But I can't see = making them required. That brings me to one other point, the whiteboard. I think we should = encourage use of a whiteboard (or easel, etc). But this implies a need = to be able to share it with remote participants. We did the best we = could last time, by snapping photos of the whiteboard and sending them = out in real time, but there's gotta be a better way. Ideally remote participants would be able to mark on the whiteboard too, = but while the technology does exist, I don't see it really happening. At = least, let's focus on getting the audio right first. --John= From morrowc@ops-netman.net Fri May 4 13:07:11 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDC3821F85AA for ; Fri, 4 May 2012 13:07:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.3 X-Spam-Level: X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_54=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MlvRE0g+CCUK for ; Fri, 4 May 2012 13:07:11 -0700 (PDT) Received: from mailserver.ops-netman.net (mailserver.ops-netman.net [IPv6:2001:470:e495:fade:5054:ff:fe79:69db]) by ietfa.amsl.com (Postfix) with ESMTP id 4692721F85A3 for ; Fri, 4 May 2012 13:07:11 -0700 (PDT) Received: from donkey.her.corp.google.com (unknown [IPv6:2620:0:100a:0:baac:6fff:fe92:fb7a]) (Authenticated sender: morrowc@OPS-NETMAN.NET) by mailserver.ops-netman.net (Postfix) with ESMTPSA id E285F320306; Fri, 4 May 2012 20:07:09 +0000 (UTC) Message-ID: <4FA436EC.6000609@ops-netman.net> Date: Fri, 04 May 2012 16:07:08 -0400 From: Chris Morrow User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: "John G. Scudder" References: <4FA204C3.6090503@ops-netman.net> In-Reply-To: X-Enigmail-Version: 1.4.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "sidr-ads@tools.ietf.org" , "sidr-chairs@tools.ietf.org" , sidr@ietf.org Subject: Re: [sidr] Interim Meeting (Apr 30, 2012) fallout/lessons/room-foo X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 May 2012 20:07:11 -0000 On 05/04/2012 03:42 PM, John G. Scudder wrote: > A few things in addition to what others have said: > > On May 3, 2012, at 12:08 AM, Chris Morrow wrote: > >> o shared slides prior to the meeting (no slides, no slot. >> potentially) > > We covered a fair amount of ground at the interim without using > slides at all. Based on that, I'm not sure where this (possible) > requirement comes from? I, for one, am not at all keen to prepare There were several remote people who said: "Where are the slides, yo?" I think I also translated this from 'regular meeting' in my head :( For the interim I believe if there are slides to be presented we need those posted to the SIDR wg page on tools.ietf before the meeting starts. I don't think that for the interim slides (in this case) would have been particularly helpful. In past meetings we've had success with slides (Sharon's given a few presentations that were slide-heavy, as has Sriram). > slide decks just for the fun of it, and I looked at lack of slides at > the interim as a plus, not a minus. Yes, if slides are used -- and > I'm not against it when useful/desired -- they should be distributed. > But I can't see making them required. yes, this was my thought process jump, oops! > That brings me to one other point, the whiteboard. I think we should > encourage use of a whiteboard (or easel, etc). But this implies a > need to be able to share it with remote participants. We did the best > we could last time, by snapping photos of the whiteboard and sending > them out in real time, but there's gotta be a better way. so far I've not seen a workable/useful shared whiteboard app :( I'm also not super enamoured with using my personal flickr account :) who knows what I may post there in the future. > Ideally remote participants would be able to mark on the whiteboard > too, but while the technology does exist, I don't see it really > happening. At least, let's focus on getting the audio right first. yes. Thanks for your thoughts, -chris From randy@psg.com Fri May 4 15:17:03 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00FF821F84A0 for ; Fri, 4 May 2012 15:17:03 -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=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fBcXRvxarc1q for ; Fri, 4 May 2012 15:17:02 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id 9D30821F84B2 for ; Fri, 4 May 2012 15:17:02 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1SQQo9-0004SI-MV for sidr@ietf.org; Fri, 04 May 2012 22:17:02 +0000 Date: Fri, 04 May 2012 12:17:00 -1000 Message-ID: From: Randy Bush To: sidr@ietf.org In-Reply-To: <20120504174514.9069.65993.idtracker@ietfa.amsl.com> References: <20120504174514.9069.65993.idtracker@ietfa.amsl.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Subject: Re: [sidr] UPDATED: SIDR Working Group Interim Meeting: Wednesday, June 6, 2012 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 May 2012 22:17:03 -0000 > Time: 1300-1700 PDT huh? and we'll spend an hour+ of it playing sound check. is there a reason for this half day? randy From randy@psg.com Fri May 4 15:17:32 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81E8F21F84B3 for ; Fri, 4 May 2012 15:17:32 -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=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fob69vK8g451 for ; Fri, 4 May 2012 15:17:32 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id 17FE721F84A0 for ; Fri, 4 May 2012 15:17:32 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1SQQoY-0004SU-I8; Fri, 04 May 2012 22:17:26 +0000 Date: Fri, 04 May 2012 12:17:25 -1000 Message-ID: From: Randy Bush To: "John G. Scudder" In-Reply-To: References: <4FA204C3.6090503@ops-netman.net> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: Chris Morrow , sidr@ietf.org, "sidr-chairs@tools.ietf.org" , "sidr-ads@tools.ietf.org" Subject: Re: [sidr] Interim Meeting (Apr 30, 2012) fallout/lessons/room-foo X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 May 2012 22:17:32 -0000 > We covered a fair amount of ground at the interim without using slides > at all. Based on that, I'm not sure where this (possible) requirement > comes from? I, for one, am not at all keen to prepare slide decks just > for the fun of it, and I looked at lack of slides at the interim as a > plus, not a minus. Yes, if slides are used -- and I'm not against it > when useful/desired -- they should be distributed. But I can't see > making them required. From Sandra.Murphy@sparta.com Fri May 4 15:24:10 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A359721F84D8 for ; Fri, 4 May 2012 15:24:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.393 X-Spam-Level: X-Spam-Status: No, score=-102.393 tagged_above=-999 required=5 tests=[AWL=-0.394, BAYES_00=-2.599, J_CHICKENPOX_45=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YMzj3hHT2FUx for ; Fri, 4 May 2012 15:24:10 -0700 (PDT) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by ietfa.amsl.com (Postfix) with ESMTP id 987E321F84D0 for ; Fri, 4 May 2012 15:24:09 -0700 (PDT) Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.14.4/8.14.4) with ESMTP id q44MO76r012716; Fri, 4 May 2012 17:24:07 -0500 Received: from Hermes.columbia.ads.sparta.com ([157.185.80.107]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id q44MO7J0003263; Fri, 4 May 2012 17:24:07 -0500 Received: from HERMES.columbia.ads.sparta.com ([2002:9db9:506b::9db9:506b]) by Hermes.columbia.ads.sparta.com ([::1]) with mapi id 14.01.0355.002; Fri, 4 May 2012 18:24:06 -0400 From: "Murphy, Sandra" To: Danny McPherson , Christopher Morrow Thread-Topic: RPKI and private keys (was RE: [sidr] Interim Meeting Draft Agenda: 04-30-2012 (April 30, 2012))) Thread-Index: AQHNKkSJz7TI33mXqEag9uIgDcAF1w== Date: Fri, 4 May 2012 22:24:05 +0000 Message-ID: <24B20D14B2CD29478C8D5D6E9CBB29F60F707BE6@Hermes.columbia.ads.sparta.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.185.63.118] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: sidr wg , "sidr-chairs@tools.ietf.org" , "sidr-ads@tools.ietf.org" Subject: [sidr] RPKI and private keys (was RE: Interim Meeting Draft Agenda: 04-30-2012 (April 30, 2012))) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 May 2012 22:24:10 -0000 still speaking as regular ol' member=0A= =0A= Looking back, I do not see a reply from Danny to my question below.=0A= =0A= But the subsequent conversation reads to me like "onboard .. signing certif= icates" means getting the private keys routers would use for signing into t= he routers.=0A= =0A= Because the below implies that the "signing certificates", i.e., private ke= ys, would be "from the RPKI", I figure I'd better speak up. Just in case s= omeone actually thought that was being suggested.=0A= =0A= Communicating the router's private keys in the RPKI would be a bad idea.=0A= =0A= First, of course, is the confidentiality concern. Private keys are suppose= d to be protected from exposure. Creating RPKI objects where they would be= protected from exposure would be hard.=0A= =0A= Furthermore, the private keys used in the routers are strictly a local conc= ern. There is no need to communicate them globally. So publishing them in= the RPKI at all, even if protected, would be a poor choice.=0A= =0A= I do not know that anyone plans to use the rpki-rtr protocol to get private= keys to the router.=0A= =0A= --Sandy, speaking as regular ol' member=0A= =0A= ________________________________________=0A= From: sidr-bounces@ietf.org [sidr-bounces@ietf.org] on behalf of Murphy, Sa= ndra [Sandra.Murphy@sparta.com]=0A= Sent: Wednesday, April 11, 2012 1:28 PM=0A= To: Danny McPherson; Christopher Morrow=0A= Cc: sidr-ads@tools.ietf.org; sidr-chairs@tools.ietf.org; sidr wg=0A= Subject: Re: [sidr] Interim Meeting Draft Agenda: 04-30-2012 (April 30, 201= 2)=0A= =0A= speaking as regular ol' member=0A= =0A= On Tuesday, April 10, 2012 9:15 PM, Danny McPherson [danny@tcb.net] said:= =0A= =0A= >From there, we can discuss the issue of, for example, HOW TO onboard=0A= >and purge signing and validating certificates to routers from the RPKI --= =0A= >[I suspect the intention was to use rpki-rtr protocol for this, but it doe= sn't=0A= >currently support it, nor are the security implications clear].=0A= =0A= I can not understand your comment. What do you mean by "signing certifica= tes"?=0A= =0A= I can guess that "validating certificates" means the certs carrying public = keys used to validate signatures, but the "signing certificates" part has m= e stumped.=0A= =0A= --Sandy=0A= =0A= =0A= ________________________________________=0A= From: sidr-bounces@ietf.org [sidr-bounces@ietf.org] on behalf of Danny McPh= erson [danny@tcb.net]=0A= Sent: Tuesday, April 10, 2012 9:15 PM=0A= To: Christopher Morrow=0A= Cc: sidr wg; sidr-chairs@tools.ietf.org; sidr-ads@tools.ietf.org=0A= Subject: Re: [sidr] Interim Meeting Draft Agenda: 04-30-2012 (April 30, 201= 2)=0A= =0A= On Apr 10, 2012, at 8:56 PM, Christopher Morrow wrote:=0A= =0A= > yes, my goal was to have updated the wiki today at the office, work=0A= > intruded... tomorrow I'll do that with some more content for each=0A= > item, and hopefully better coordinates as well for the location.=0A= =0A= Thanks.=0A= =0A= >> Also, are we collecting requirements for these (e.g., object scale, RPs,= etc..)? Basing these discussions on requirements that exist somewhere alr= eady? Or simply discussing solutions that have already been developed and = deployment experience? If the latter, then we can we ensure we reference a= nd prepare to discuss what requirements drive to the development of those s= olutions?=0A= >>=0A= >=0A= > I think the only bit in the 3 that has a current 'requirements'=0A= > discussion is the 'freshness' (item 2). The first item 'deployment=0A= > discussion' is really a discussion of:=0A= > "Should there be some document that describes the top N (3?)=0A= > deployment scenarios && where should that document/presentation/etc=0A= > live?" (I suppose implicit in that is 'requirements for format,=0A= > content, intended audience')=0A= =0A= I was thinking more simply along the lines of "a fully deployed RPKI today = would have o objects and r RPs a c churn and we ought to ensure our designs= accommodate that" -- only then can we have a reasonable discussion on, e.g= ., data freshness? What have we based these design goals on thus far - do = we have a stable reference for this?=0A= =0A= >From there, we can discuss the issue of, for example, HOW TO onboard and pu= rge signing and validating certificates to routers from the RPKI -- [I susp= ect the intention was to use rpki-rtr protocol for this, but it doesn't cur= rently support it, nor are the security implications clear].=0A= =0A= Only when we get to that point will we really begin to understand the dynam= ics of RPKI and it's employment for secure routing (well beyond "authorized= " origin policy configuration), and the impact of rate+state in both the RP= KI and it's effectuating in the routing system, and perhaps most importantl= y, the inter-dependencies between the two (even basic stuff like the rate o= f updates from an RPKI cache to a router in a fully loaded system given tod= ay's RPKI object counts).=0A= =0A= >> Also, it looks to me like we're in dire need of a charter update...=0A= >=0A= > for which? (I didn't think that any of the 3 items was actually=0A= > outside of the current charter)=0A= =0A= I meant the goals and milestones, apologies for not being clear.=0A= =0A= -danny=0A= _______________________________________________=0A= sidr mailing list=0A= sidr@ietf.org=0A= https://www.ietf.org/mailman/listinfo/sidr=0A= _______________________________________________=0A= sidr mailing list=0A= sidr@ietf.org=0A= https://www.ietf.org/mailman/listinfo/sidr=0A= From Sandra.Murphy@sparta.com Fri May 4 15:38:45 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28FF521E8015 for ; Fri, 4 May 2012 15:38:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.683 X-Spam-Level: X-Spam-Status: No, score=-102.683 tagged_above=-999 required=5 tests=[AWL=-0.084, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L9F4AJtNMQ2x for ; Fri, 4 May 2012 15:38:44 -0700 (PDT) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by ietfa.amsl.com (Postfix) with ESMTP id 8E8B221F84F1 for ; Fri, 4 May 2012 15:38:44 -0700 (PDT) Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.14.4/8.14.4) with ESMTP id q44Mci5x012765; Fri, 4 May 2012 17:38:44 -0500 Received: from Hermes.columbia.ads.sparta.com ([157.185.80.107]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id q44MchPv003459; Fri, 4 May 2012 17:38:43 -0500 Received: from HERMES.columbia.ads.sparta.com ([2002:9db9:506b::9db9:506b]) by Hermes.columbia.ads.sparta.com ([::1]) with mapi id 14.01.0355.002; Fri, 4 May 2012 18:38:43 -0400 From: "Murphy, Sandra" To: Randy Bush , "sidr@ietf.org" Thread-Topic: [sidr] UPDATED: SIDR Working Group Interim Meeting: Wednesday, June 6, 2012 Thread-Index: AQHNKkOktvwCCc+T8UKbon5unEbt5pa6OBUV Date: Fri, 4 May 2012 22:38:42 +0000 Message-ID: <24B20D14B2CD29478C8D5D6E9CBB29F60F707C29@Hermes.columbia.ads.sparta.com> References: <20120504174514.9069.65993.idtracker@ietfa.amsl.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.185.63.118] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sidr] UPDATED: SIDR Working Group Interim Meeting: Wednesday, June 6, 2012 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 May 2012 22:38:45 -0000 NANOG is meeting in the morning. As we hope to attract operators, we don't= want to overlap. Not to mention nanog's desire to avoid conflicts with th= eir agenda. And members who go to nanog.=0A= =0A= This is as was originally announced.=0A= =0A= --Sandy=0A= ________________________________________=0A= From: sidr-bounces@ietf.org [sidr-bounces@ietf.org] on behalf of Randy Bush= [randy@psg.com]=0A= Sent: Friday, May 04, 2012 6:17 PM=0A= To: sidr@ietf.org=0A= Subject: Re: [sidr] UPDATED: SIDR Working Group Interim Meeting: Wednesday,= June 6, 2012=0A= =0A= > Time: 1300-1700 PDT=0A= =0A= huh? and we'll spend an hour+ of it playing sound check.=0A= =0A= is there a reason for this half day?=0A= =0A= randy=0A= _______________________________________________=0A= sidr mailing list=0A= sidr@ietf.org=0A= https://www.ietf.org/mailman/listinfo/sidr=0A= From randy@psg.com Fri May 4 17:10:34 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6EBA21E8012 for ; Fri, 4 May 2012 17:10:34 -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=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id my4oo3O+FrVB for ; Fri, 4 May 2012 17:10:34 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id 583DB11E8072 for ; Fri, 4 May 2012 17:10:34 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1SQSa1-00050C-6s; Sat, 05 May 2012 00:10:33 +0000 Date: Fri, 04 May 2012 14:10:31 -1000 Message-ID: From: Randy Bush To: "Murphy, Sandra" In-Reply-To: <24B20D14B2CD29478C8D5D6E9CBB29F60F707BE6@Hermes.columbia.ads.sparta.com> References: <24B20D14B2CD29478C8D5D6E9CBB29F60F707BE6@Hermes.columbia.ads.sparta.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: sidr wg list Subject: Re: [sidr] RPKI and private keys (was RE: Interim Meeting Draft Agenda: 04-30-2012 (April 30, 2012))) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 May 2012 00:10:35 -0000 > But the subsequent conversation reads to me like "onboard .. signing > certificates" i can not find 'onboard' used as a verb in any rfc. so anything is a guess. > means getting the private keys routers would use for signing into the > routers. try draft-ymbk-bgpsec-rtr-rekeying-00.txt, which i thought was asked to be adopted by the wg. probably my screw-up. > Communicating the router's private keys in the RPKI would be a bad > idea. only if you don't think a public bath is private :) > I do not know that anyone plans to use the rpki-rtr protocol to get > private keys to the router. this is the ietf. i am fairly sure someone does. i just think they would be extremely ill-advised to do so. randy From eosterweil@verisign.com Fri May 4 18:00:01 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 837F321E8024 for ; Fri, 4 May 2012 18:00:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.649 X-Spam-Level: X-Spam-Status: No, score=-5.649 tagged_above=-999 required=5 tests=[AWL=0.350, BAYES_00=-2.599, J_CHICKENPOX_45=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wHXIb3RknZ5X for ; Fri, 4 May 2012 18:00:00 -0700 (PDT) Received: from exprod6og112.obsmtp.com (exprod6og112.obsmtp.com [64.18.1.29]) by ietfa.amsl.com (Postfix) with ESMTP id 8ECDE21E8018 for ; Fri, 4 May 2012 17:59:57 -0700 (PDT) Received: from osprey.verisign.com ([216.168.239.75]) (using TLSv1) by exprod6ob112.postini.com ([64.18.5.12]) with SMTP ID DSNKT6R7gv0otpLPk9imlQO8QqUpBl2qIfSv@postini.com; Fri, 04 May 2012 18:00:00 PDT Received: from brn1wnexcas01.vcorp.ad.vrsn.com (brn1wnexcas01.vcorp.ad.vrsn.com [10.173.152.205]) by osprey.verisign.com (8.13.6/8.13.4) with ESMTP id q450xg9w032233 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 4 May 2012 20:59:42 -0400 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.02.0247.003; Fri, 4 May 2012 20:59:42 -0400 From: "Osterweil, Eric" To: "'Sandra.Murphy@sparta.com'" , "'danny@tcb.net'" , "'morrowc.lists@gmail.com'" Thread-Topic: [sidr] RPKI and private keys (was RE: Interim Meeting Draft Agenda: 04-30-2012 (April 30, 2012))) Thread-Index: AQHNKkSJz7TI33mXqEag9uIgDcAF15a6YCwk Date: Sat, 5 May 2012 00:59:41 +0000 Message-ID: In-Reply-To: <24B20D14B2CD29478C8D5D6E9CBB29F60F707BE6@Hermes.columbia.ads.sparta.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.170.13.175] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "'sidr-ads@tools.ietf.org'" , "'sidr-chairs@tools.ietf.org'" , "'sidr@ietf.org'" Subject: Re: [sidr] RPKI and private keys (was RE: Interim Meeting Draft Agenda: 04-30-2012 (April 30, 2012))) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 May 2012 01:00:01 -0000 He Sandy, Speaking just as a regular ole wg member: The issue Danny alluded to is NOT private keys in rpki. It is the fact that= the specs imply that routers that need to sign updates ON BEHALF OF ASES n= eed to do so with private keys that have been vouched for. But getting thes= e private keys "onboard" routers that lie across (for example) foreign bord= ers can be an operational nonstarter. For ex, if my router's key needs to b= e voched for but its private portion (that signs updates) is sent over a me= dium in which it can be intercepted, then how can I trust the signatures fr= om it. Conversely, if I cannot securely get my private keys onto my routers= across potentially hostile borders, how can I expect them to sign my AS' u= pdates? =20 His point is NOT addressed by any draft in the wg (since you asked). Hth, Eric ----- Original Message ----- From: Murphy, Sandra [mailto:Sandra.Murphy@sparta.com] Sent: Friday, May 04, 2012 06:24 PM=0A= To: Danny McPherson ; Christopher Morrow Cc: sidr wg ; sidr-chairs@tools.ietf.org ; sidr-ads@tools.ietf.org Subject: [sidr] RPKI and private keys (was RE: Interim Meeting Draft Agenda= : 04-30-2012 (April 30, 2012))) still speaking as regular ol' member Looking back, I do not see a reply from Danny to my question below. But the subsequent conversation reads to me like "onboard .. signing certif= icates" means getting the private keys routers would use for signing into t= he routers. Because the below implies that the "signing certificates", i.e., private ke= ys, would be "from the RPKI", I figure I'd better speak up. Just in case s= omeone actually thought that was being suggested. Communicating the router's private keys in the RPKI would be a bad idea. First, of course, is the confidentiality concern. Private keys are suppose= d to be protected from exposure. Creating RPKI objects where they would be= protected from exposure would be hard. Furthermore, the private keys used in the routers are strictly a local conc= ern. There is no need to communicate them globally. So publishing them in= the RPKI at all, even if protected, would be a poor choice. I do not know that anyone plans to use the rpki-rtr protocol to get private= keys to the router. --Sandy, speaking as regular ol' member ________________________________________ From: sidr-bounces@ietf.org [sidr-bounces@ietf.org] on behalf of Murphy, Sa= ndra [Sandra.Murphy@sparta.com] Sent: Wednesday, April 11, 2012 1:28 PM To: Danny McPherson; Christopher Morrow Cc: sidr-ads@tools.ietf.org; sidr-chairs@tools.ietf.org; sidr wg Subject: Re: [sidr] Interim Meeting Draft Agenda: 04-30-2012 (April 30, 201= 2) speaking as regular ol' member On Tuesday, April 10, 2012 9:15 PM, Danny McPherson [danny@tcb.net] said: >From there, we can discuss the issue of, for example, HOW TO onboard >and purge signing and validating certificates to routers from the RPKI -- >[I suspect the intention was to use rpki-rtr protocol for this, but it doe= sn't >currently support it, nor are the security implications clear]. I can not understand your comment. What do you mean by "signing certifica= tes"? I can guess that "validating certificates" means the certs carrying public = keys used to validate signatures, but the "signing certificates" part has m= e stumped. --Sandy ________________________________________ From: sidr-bounces@ietf.org [sidr-bounces@ietf.org] on behalf of Danny McPh= erson [danny@tcb.net] Sent: Tuesday, April 10, 2012 9:15 PM To: Christopher Morrow Cc: sidr wg; sidr-chairs@tools.ietf.org; sidr-ads@tools.ietf.org Subject: Re: [sidr] Interim Meeting Draft Agenda: 04-30-2012 (April 30, 201= 2) On Apr 10, 2012, at 8:56 PM, Christopher Morrow wrote: > yes, my goal was to have updated the wiki today at the office, work > intruded... tomorrow I'll do that with some more content for each > item, and hopefully better coordinates as well for the location. Thanks. >> Also, are we collecting requirements for these (e.g., object scale, RPs,= etc..)? Basing these discussions on requirements that exist somewhere alr= eady? Or simply discussing solutions that have already been developed and = deployment experience? If the latter, then we can we ensure we reference a= nd prepare to discuss what requirements drive to the development of those s= olutions? >> > > I think the only bit in the 3 that has a current 'requirements' > discussion is the 'freshness' (item 2). The first item 'deployment > discussion' is really a discussion of: > "Should there be some document that describes the top N (3?) > deployment scenarios && where should that document/presentation/etc > live?" (I suppose implicit in that is 'requirements for format, > content, intended audience') I was thinking more simply along the lines of "a fully deployed RPKI today = would have o objects and r RPs a c churn and we ought to ensure our designs= accommodate that" -- only then can we have a reasonable discussion on, e.g= ., data freshness? What have we based these design goals on thus far - do = we have a stable reference for this? >From there, we can discuss the issue of, for example, HOW TO onboard and pu= rge signing and validating certificates to routers from the RPKI -- [I susp= ect the intention was to use rpki-rtr protocol for this, but it doesn't cur= rently support it, nor are the security implications clear]. Only when we get to that point will we really begin to understand the dynam= ics of RPKI and it's employment for secure routing (well beyond "authorized= " origin policy configuration), and the impact of rate+state in both the RP= KI and it's effectuating in the routing system, and perhaps most importantl= y, the inter-dependencies between the two (even basic stuff like the rate o= f updates from an RPKI cache to a router in a fully loaded system given tod= ay's RPKI object counts). >> Also, it looks to me like we're in dire need of a charter update... > > for which? (I didn't think that any of the 3 items was actually > outside of the current charter) I meant the goals and milestones, apologies for not being clear. -danny _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From morrowc@ops-netman.net Fri May 4 18:28:39 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB43C21F84BF for ; Fri, 4 May 2012 18:28:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.5 X-Spam-Level: X-Spam-Status: No, score=-2.5 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rEpYrrlN9cDB for ; Fri, 4 May 2012 18:28:36 -0700 (PDT) Received: from mailserver.ops-netman.net (mailserver.ops-netman.net [IPv6:2001:470:e495:fade:5054:ff:fe79:69db]) by ietfa.amsl.com (Postfix) with ESMTP id 9AEBB21F84BD for ; Fri, 4 May 2012 18:28:36 -0700 (PDT) Received: from [192.168.1.125] (c-98-204-226-233.hsd1.va.comcast.net [98.204.226.233]) (Authenticated sender: morrowc@OPS-NETMAN.NET) by mailserver.ops-netman.net (Postfix) with ESMTPSA id 39EDC3202DC; Sat, 5 May 2012 01:28:33 +0000 (UTC) Message-ID: <4FA48240.9060405@ops-netman.net> Date: Fri, 04 May 2012 21:28:32 -0400 From: Chris Morrow User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120410 Thunderbird/11.0.1 MIME-Version: 1.0 To: "Osterweil, Eric" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "'sidr-chairs@tools.ietf.org'" , "'Sandra.Murphy@sparta.com'" , "'sidr-ads@tools.ietf.org'" , "'sidr@ietf.org'" Subject: Re: [sidr] RPKI and private keys (was RE: Interim Meeting Draft Agenda: 04-30-2012 (April 30, 2012))) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 May 2012 01:28:39 -0000 On 05/04/2012 08:59 PM, Osterweil, Eric wrote: > His point is NOT addressed by any draft in the wg (since you asked). read randy's mentioned draft? From eosterweil@verisign.com Fri May 4 18:38:16 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B97E921F84DF for ; Fri, 4 May 2012 18:38:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.019 X-Spam-Level: X-Spam-Status: No, score=-6.019 tagged_above=-999 required=5 tests=[AWL=0.580, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5UzeXzK7WuCm for ; Fri, 4 May 2012 18:38:16 -0700 (PDT) Received: from exprod6og117.obsmtp.com (exprod6og117.obsmtp.com [64.18.1.39]) by ietfa.amsl.com (Postfix) with ESMTP id B1DD521F84DE for ; Fri, 4 May 2012 18:38:03 -0700 (PDT) Received: from peregrine.verisign.com ([216.168.239.74]) (using TLSv1) by exprod6ob117.postini.com ([64.18.5.12]) with SMTP ID DSNKT6SEdbT+gcbpFL/dUQZDWV6w9XayMQCo@postini.com; Fri, 04 May 2012 18:38:06 PDT Received: from brn1wnexcas02.vcorp.ad.vrsn.com (brn1wnexcas02.vcorp.ad.vrsn.com [10.173.152.206]) by peregrine.verisign.com (8.13.6/8.13.4) with ESMTP id q451bsFp031203 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 4 May 2012 21:37:54 -0400 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas02.vcorp.ad.vrsn.com ([::1]) with mapi id 14.02.0247.003; Fri, 4 May 2012 21:37:54 -0400 From: "Osterweil, Eric" To: "'morrowc@ops-netman.net'" Thread-Topic: [sidr] RPKI and private keys (was RE: Interim Meeting Draft Agenda: 04-30-2012 (April 30, 2012))) Thread-Index: AQHNKkSJz7TI33mXqEag9uIgDcAF15a6YCwkgABLHAD//7+Qog== Date: Sat, 5 May 2012 01:37:53 +0000 Message-ID: In-Reply-To: <4FA48240.9060405@ops-netman.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.170.13.175] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "'sidr-chairs@tools.ietf.org'" , "'Sandra.Murphy@sparta.com'" , "'sidr-ads@tools.ietf.org'" , "'sidr@ietf.org'" Subject: Re: [sidr] RPKI and private keys (was RE: Interim Meeting Draft Agenda: 04-30-2012 (April 30, 2012))) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 May 2012 01:38:16 -0000 Hey Chris, Yeah, I read that. I know there's a tendency for some people to want to tal= k about bath houses on this list, but I was going to pass on that. As for draft-ymbk-bgpsec-rtr-rekeying-00.txt, that draft just points out th= e inadequacies of either approach and that there is no good solution. My ta= ke is that this is indicative of a misalignment between a given architectur= e and implicit requirements. Sometimes you can't patch the holes in a leaky= ship, you need to reassess the requirements. I think the evidence illustra= tes that this is the case here. Eric=20 ----- Original Message ----- From: Chris Morrow [mailto:morrowc@ops-netman.net] Sent: Friday, May 04, 2012 09:28 PM=0A= To: Osterweil, Eric Cc: 'Sandra.Murphy@sparta.com' ; 'danny@tcb.net' = ; 'morrowc.lists@gmail.com' ; 'sidr= @ietf.org' ; 'sidr-chairs@tools.ietf.org' ; 'sidr-ads@tools.ietf.org' Subject: Re: [sidr] RPKI and private keys (was RE: Interim Meeting Draft Ag= enda: 04-30-2012 (April 30, 2012))) On 05/04/2012 08:59 PM, Osterweil, Eric wrote: > His point is NOT addressed by any draft in the wg (since you asked). read randy's mentioned draft? From christopher.morrow@gmail.com Fri May 4 18:54:07 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0351721E802D for ; Fri, 4 May 2012 18:54:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.582 X-Spam-Level: X-Spam-Status: No, score=-103.582 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gOPAf6a6n4uo for ; Fri, 4 May 2012 18:54:06 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 73E6B21E8018 for ; Fri, 4 May 2012 18:54:06 -0700 (PDT) Received: by obbeh20 with SMTP id eh20so5623995obb.31 for ; Fri, 04 May 2012 18:54:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=NQkYifyCWw19dZq+B91SPCOgFUU++kA2+fk19zTjzxc=; b=Wpmx8JMhWx0d8IhHm58k7LK/3cpp6Zk+WUed+RnxiZOWLLYhA91QLI2DxkRU35N7+r p5uYALA9GlHynSiUg0bWYKRzWrgtPO8CpjLWfiCfFskp4hZpcHmPHmM9G04LBhqCjacr /1eQIPH6KRSOhh5q9qQ6qBgHoeQwolBfmrWF3rpZRH9xNS/V5DJaDY7zFm9vQLOl5YG+ sNAtV+68tbqGn029jP94E+9qUMKyhu2ZYmAfFMZ185+yXBatPUe7Y1d3ocLm8Bwj5JOm HecckP0vmZRS1tyBhA2hrbRHMc9aJcsfsxy13YiXboZdfPC6Uv6GqqY866cGaDfdWf69 qlpg== MIME-Version: 1.0 Received: by 10.60.13.37 with SMTP id e5mr11319511oec.70.1336182845980; Fri, 04 May 2012 18:54:05 -0700 (PDT) Sender: christopher.morrow@gmail.com Received: by 10.182.155.39 with HTTP; Fri, 4 May 2012 18:54:05 -0700 (PDT) In-Reply-To: References: <4FA48240.9060405@ops-netman.net> Date: Fri, 4 May 2012 21:54:05 -0400 X-Google-Sender-Auth: wffzXoeJ733L7ZxGco76Wtik-Po Message-ID: From: Christopher Morrow To: "Osterweil, Eric" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "sidr-chairs@tools.ietf.org" , "Sandra.Murphy@sparta.com" , "sidr-ads@tools.ietf.org" , "morrowc@ops-netman.net" , "sidr@ietf.org" Subject: Re: [sidr] RPKI and private keys (was RE: Interim Meeting Draft Agenda: 04-30-2012 (April 30, 2012))) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 May 2012 01:54:07 -0000 On Fri, May 4, 2012 at 9:37 PM, Osterweil, Eric w= rote: > Hey Chris, > > Yeah, I read that. I know there's a tendency for some people to want to t= alk about bath houses on this list, but I was going to pass on that. > > As for draft-ymbk-bgpsec-rtr-rekeying-00.txt, that draft just points out = the inadequacies of either approach and that there is no good solution. My = take is that this is indicative of a misalignment between a given architect= ure and implicit requirements. Sometimes you can't patch the holes in a lea= ky ship, you need to reassess the requirements. I think the evidence illust= rates that this is the case here. > it seems to me that putting key-material on a distant router is done today... isn't it? or are you saying that how you do it today leaves you feeling icky, and you'd rather another method be devised? Could you outline a possible method? (provide a solution, for instance) > Eric > > > ----- Original Message ----- > From: Chris Morrow [mailto:morrowc@ops-netman.net] > Sent: Friday, May 04, 2012 09:28 PM > To: Osterweil, Eric > Cc: 'Sandra.Murphy@sparta.com' ; 'danny@tcb.net= ' ; 'morrowc.lists@gmail.com' ; 'si= dr@ietf.org' ; 'sidr-chairs@tools.ietf.org' ; 'sidr-ads@tools.ietf.org' > Subject: Re: [sidr] RPKI and private keys (was RE: Interim Meeting Draft = Agenda: 04-30-2012 (April 30, 2012))) > > > > On 05/04/2012 08:59 PM, Osterweil, Eric wrote: > >> His point is NOT addressed by any draft in the wg (since you asked). > > read randy's mentioned draft? From eosterweil@verisign.com Fri May 4 19:06:59 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C36F121F847A for ; Fri, 4 May 2012 19:06:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.116 X-Spam-Level: X-Spam-Status: No, score=-6.116 tagged_above=-999 required=5 tests=[AWL=0.483, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ggZMS4mV6HU7 for ; Fri, 4 May 2012 19:06:59 -0700 (PDT) Received: from exprod6og108.obsmtp.com (exprod6og108.obsmtp.com [64.18.1.21]) by ietfa.amsl.com (Postfix) with ESMTP id 6CC7521F8476 for ; Fri, 4 May 2012 19:06:55 -0700 (PDT) Received: from peregrine.verisign.com ([216.168.239.74]) (using TLSv1) by exprod6ob108.postini.com ([64.18.5.12]) with SMTP ID DSNKT6SLNItAhG54KfcuN8YrO6ffvGsGti12@postini.com; Fri, 04 May 2012 19:06:58 PDT Received: from brn1wnexcas02.vcorp.ad.vrsn.com (brn1wnexcas02.vcorp.ad.vrsn.com [10.173.152.206]) by peregrine.verisign.com (8.13.6/8.13.4) with ESMTP id q4526hWE031813 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 4 May 2012 22:06:43 -0400 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas02.vcorp.ad.vrsn.com ([::1]) with mapi id 14.02.0247.003; Fri, 4 May 2012 22:06:43 -0400 From: "Osterweil, Eric" To: "'morrowc.lists@gmail.com'" Thread-Topic: [sidr] RPKI and private keys (was RE: Interim Meeting Draft Agenda: 04-30-2012 (April 30, 2012))) Thread-Index: AQHNKkSJz7TI33mXqEag9uIgDcAF15a6YCwkgABLHAD//7+QooAAR5SA///AeMs= Date: Sat, 5 May 2012 02:06:42 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.170.13.175] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "'sidr-chairs@tools.ietf.org'" , "'Sandra.Murphy@sparta.com'" , "'sidr-ads@tools.ietf.org'" , "'morrowc@ops-netman.net'" , "'sidr@ietf.org'" Subject: Re: [sidr] RPKI and private keys (was RE: Interim Meeting Draft Agenda: 04-30-2012 (April 30, 2012))) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 May 2012 02:06:59 -0000 Hey Chris, The implications of putting signatures on updates that are both globally vi= sible/verifiable and implicitly give object-level security to updates is WA= Y different than the semantics of the keying done today. The implications = of the scope of these keys puts them in a much different role. I was assum= ing that was clear, but maybe not? Eric ----- Original Message ----- From: Christopher Morrow [mailto:morrowc.lists@gmail.com] Sent: Friday, May 04, 2012 09:54 PM=0A= To: Osterweil, Eric Cc: morrowc@ops-netman.net ; Sandra.Murphy@sparta.c= om ; danny@tcb.net ; sidr@ietf.org= ; sidr-chairs@tools.ietf.org ; = sidr-ads@tools.ietf.org Subject: Re: [sidr] RPKI and private keys (was RE: Interim Meeting Draft Ag= enda: 04-30-2012 (April 30, 2012))) On Fri, May 4, 2012 at 9:37 PM, Osterweil, Eric w= rote: > Hey Chris, > > Yeah, I read that. I know there's a tendency for some people to want to t= alk about bath houses on this list, but I was going to pass on that. > > As for draft-ymbk-bgpsec-rtr-rekeying-00.txt, that draft just points out = the inadequacies of either approach and that there is no good solution. My = take is that this is indicative of a misalignment between a given architect= ure and implicit requirements. Sometimes you can't patch the holes in a lea= ky ship, you need to reassess the requirements. I think the evidence illust= rates that this is the case here. > it seems to me that putting key-material on a distant router is done today... isn't it? or are you saying that how you do it today leaves you feeling icky, and you'd rather another method be devised? Could you outline a possible method? (provide a solution, for instance) > Eric > > > ----- Original Message ----- > From: Chris Morrow [mailto:morrowc@ops-netman.net] > Sent: Friday, May 04, 2012 09:28 PM > To: Osterweil, Eric > Cc: 'Sandra.Murphy@sparta.com' ; 'danny@tcb.net= ' ; 'morrowc.lists@gmail.com' ; 'si= dr@ietf.org' ; 'sidr-chairs@tools.ietf.org' ; 'sidr-ads@tools.ietf.org' > Subject: Re: [sidr] RPKI and private keys (was RE: Interim Meeting Draft = Agenda: 04-30-2012 (April 30, 2012))) > > > > On 05/04/2012 08:59 PM, Osterweil, Eric wrote: > >> His point is NOT addressed by any draft in the wg (since you asked). > > read randy's mentioned draft? From morrowc@ops-netman.net Fri May 4 19:18:45 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57C1121E802B for ; Fri, 4 May 2012 19:18:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.524 X-Spam-Level: X-Spam-Status: No, score=-2.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WhD7JpehYGzS for ; Fri, 4 May 2012 19:18:44 -0700 (PDT) Received: from mailserver.ops-netman.net (mailserver.ops-netman.net [IPv6:2001:470:e495:fade:5054:ff:fe79:69db]) by ietfa.amsl.com (Postfix) with ESMTP id AFB5021E8020 for ; Fri, 4 May 2012 19:18:44 -0700 (PDT) Received: from [192.168.1.125] (c-98-204-226-233.hsd1.va.comcast.net [98.204.226.233]) (Authenticated sender: morrowc@OPS-NETMAN.NET) by mailserver.ops-netman.net (Postfix) with ESMTPSA id 68516320270; Sat, 5 May 2012 02:18:40 +0000 (UTC) Message-ID: <4FA48DFF.4060604@ops-netman.net> Date: Fri, 04 May 2012 22:18:39 -0400 From: Chris Morrow User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120410 Thunderbird/11.0.1 MIME-Version: 1.0 To: "Osterweil, Eric" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "'sidr-chairs@tools.ietf.org'" , "'Sandra.Murphy@sparta.com'" , "'sidr-ads@tools.ietf.org'" , "'sidr@ietf.org'" Subject: Re: [sidr] RPKI and private keys (was RE: Interim Meeting Draft Agenda: 04-30-2012 (April 30, 2012))) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 May 2012 02:18:45 -0000 On 05/04/2012 10:06 PM, Osterweil, Eric wrote: > Hey Chris, > > The implications of putting signatures on updates that are both > globally visible/verifiable and implicitly give object-level security > to updates is WAY different than the semantics of the keying done > today. The implications of the scope of these keys puts them in a > much different role. I was assuming that was clear, but maybe not? I think we're talking about 2 different (at least) things... > Eric > > > ----- Original Message ----- From: Christopher Morrow > [mailto:morrowc.lists@gmail.com] Sent: Friday, May 04, 2012 09:54 PM > To: Osterweil, Eric Cc: > morrowc@ops-netman.net; > Sandra.Murphy@sparta.com; > danny@tcb.net; sidr@ietf.org; > sidr-chairs@tools.ietf.org; > sidr-ads@tools.ietf.org Subject: Re: [sidr] > RPKI and private keys (was RE: Interim Meeting Draft Agenda: > 04-30-2012 (April 30, 2012))) > > On Fri, May 4, 2012 at 9:37 PM, Osterweil, > Eric wrote: >> Hey Chris, >> >> Yeah, I read that. I know there's a tendency for some people to >> want to talk about bath houses on this list, but I was going to >> pass on that. >> >> As for draft-ymbk-bgpsec-rtr-rekeying-00.txt, that draft just >> points out the inadequacies of either approach and that there is no >> good solution. My take is that this is indicative of a misalignment >> between a given architecture and implicit requirements. Sometimes >> you can't patch the holes in a leaky ship, you need to reassess the >> requirements. I think the evidence illustrates that this is the >> case here. >> > > it seems to me that putting key-material on a distant router is done > today... isn't it? or are you saying that how you do it today leaves > you feeling icky, and you'd rather another method be devised? > > Could you outline a possible method? (provide a solution, for > instance) > >> Eric >> >> >> ----- Original Message ----- From: Chris Morrow >> [mailto:morrowc@ops-netman.net] Sent: Friday, May 04, 2012 09:28 >> PM To: Osterweil, Eric Cc: >> 'Sandra.Murphy@sparta.com'; >> 'danny@tcb.net'; >> 'morrowc.lists@gmail.com'; >> 'sidr@ietf.org'; >> 'sidr-chairs@tools.ietf.org'; >> 'sidr-ads@tools.ietf.org' Subject: Re: >> [sidr] RPKI and private keys (was RE: Interim Meeting Draft Agenda: >> 04-30-2012 (April 30, 2012))) >> >> >> >> On 05/04/2012 08:59 PM, Osterweil, Eric wrote: >> >>> His point is NOT addressed by any draft in the wg (since you >>> asked). >> >> read randy's mentioned draft? From eosterweil@verisign.com Fri May 4 19:30:53 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0D0921F84A7 for ; Fri, 4 May 2012 19:30:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.185 X-Spam-Level: X-Spam-Status: No, score=-6.185 tagged_above=-999 required=5 tests=[AWL=0.414, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jBhM8cag8ZyO for ; Fri, 4 May 2012 19:30:53 -0700 (PDT) Received: from exprod6og103.obsmtp.com (exprod6og103.obsmtp.com [64.18.1.185]) by ietfa.amsl.com (Postfix) with ESMTP id 97BDD21F84A6 for ; Fri, 4 May 2012 19:30:49 -0700 (PDT) Received: from peregrine.verisign.com ([216.168.239.74]) (using TLSv1) by exprod6ob103.postini.com ([64.18.5.12]) with SMTP ID DSNKT6SQyOONjwyZTiMNLMN9fPSQdNn4qk8a@postini.com; Fri, 04 May 2012 19:30:52 PDT Received: from brn1wnexcas01.vcorp.ad.vrsn.com (brn1wnexcas01.vcorp.ad.vrsn.com [10.173.152.205]) by peregrine.verisign.com (8.13.6/8.13.4) with ESMTP id q452URCs032368 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 4 May 2012 22:30:28 -0400 Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.02.0247.003; Fri, 4 May 2012 22:30:28 -0400 From: "Osterweil, Eric" To: "'morrowc@ops-netman.net'" Thread-Topic: [sidr] RPKI and private keys (was RE: Interim Meeting Draft Agenda: 04-30-2012 (April 30, 2012))) Thread-Index: AQHNKkSJz7TI33mXqEag9uIgDcAF15a6YCwkgABLHAD//7+QooAAR5SA///AeMuAAEZlgP//wD3Y Date: Sat, 5 May 2012 02:30:26 +0000 Message-ID: In-Reply-To: <4FA48DFF.4060604@ops-netman.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.170.13.175] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "'sidr-chairs@tools.ietf.org'" , "'Sandra.Murphy@sparta.com'" , "'sidr-ads@tools.ietf.org'" , "'sidr@ietf.org'" Subject: Re: [sidr] RPKI and private keys (was RE: Interim Meeting Draft Agenda: 04-30-2012 (April 30, 2012))) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 May 2012 02:30:53 -0000 Well, when u compared the key mgmt that is done today w/ the key mgmt that = will need to be done with bgpsec keys on routers, I think there was an stra= ined analogy. I'm talking about the latter, but I was trying to indulge the= discussion. ;)=20 Eric ----- Original Message ----- From: Chris Morrow [mailto:morrowc@ops-netman.net] Sent: Friday, May 04, 2012 10:18 PM=0A= To: Osterweil, Eric Cc: 'morrowc.lists@gmail.com' ; 'Sandra.Murphy@spa= rta.com' ; 'danny@tcb.net' ; 'sidr= @ietf.org' ; 'sidr-chairs@tools.ietf.org' ; 'sidr-ads@tools.ietf.org' Subject: Re: [sidr] RPKI and private keys (was RE: Interim Meeting Draft Ag= enda: 04-30-2012 (April 30, 2012))) On 05/04/2012 10:06 PM, Osterweil, Eric wrote: > Hey Chris, > > The implications of putting signatures on updates that are both > globally visible/verifiable and implicitly give object-level security > to updates is WAY different than the semantics of the keying done > today. The implications of the scope of these keys puts them in a > much different role. I was assuming that was clear, but maybe not? I think we're talking about 2 different (at least) things... > Eric > > > ----- Original Message ----- From: Christopher Morrow > [mailto:morrowc.lists@gmail.com] Sent: Friday, May 04, 2012 09:54 PM > To: Osterweil, Eric Cc: > morrowc@ops-netman.net; > Sandra.Murphy@sparta.com; > danny@tcb.net; sidr@ietf.org; > sidr-chairs@tools.ietf.org; > sidr-ads@tools.ietf.org Subject: Re: [sidr] > RPKI and private keys (was RE: Interim Meeting Draft Agenda: > 04-30-2012 (April 30, 2012))) > > On Fri, May 4, 2012 at 9:37 PM, Osterweil, > Eric wrote: >> Hey Chris, >> >> Yeah, I read that. I know there's a tendency for some people to >> want to talk about bath houses on this list, but I was going to >> pass on that. >> >> As for draft-ymbk-bgpsec-rtr-rekeying-00.txt, that draft just >> points out the inadequacies of either approach and that there is no >> good solution. My take is that this is indicative of a misalignment >> between a given architecture and implicit requirements. Sometimes >> you can't patch the holes in a leaky ship, you need to reassess the >> requirements. I think the evidence illustrates that this is the >> case here. >> > > it seems to me that putting key-material on a distant router is done > today... isn't it? or are you saying that how you do it today leaves > you feeling icky, and you'd rather another method be devised? > > Could you outline a possible method? (provide a solution, for > instance) > >> Eric >> >> >> ----- Original Message ----- From: Chris Morrow >> [mailto:morrowc@ops-netman.net] Sent: Friday, May 04, 2012 09:28 >> PM To: Osterweil, Eric Cc: >> 'Sandra.Murphy@sparta.com'; >> 'danny@tcb.net'; >> 'morrowc.lists@gmail.com'; >> 'sidr@ietf.org'; >> 'sidr-chairs@tools.ietf.org'; >> 'sidr-ads@tools.ietf.org' Subject: Re: >> [sidr] RPKI and private keys (was RE: Interim Meeting Draft Agenda: >> 04-30-2012 (April 30, 2012))) >> >> >> >> On 05/04/2012 08:59 PM, Osterweil, Eric wrote: >> >>> His point is NOT addressed by any draft in the wg (since you >>> asked). >> >> read randy's mentioned draft? From morrowc@ops-netman.net Fri May 4 19:58:04 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BF2F21F846E for ; Fri, 4 May 2012 19:58:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.539 X-Spam-Level: X-Spam-Status: No, score=-2.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NltpZqZGnSKY for ; Fri, 4 May 2012 19:58:04 -0700 (PDT) Received: from mailserver.ops-netman.net (mailserver.ops-netman.net [IPv6:2001:470:e495:fade:5054:ff:fe79:69db]) by ietfa.amsl.com (Postfix) with ESMTP id 0A2DC21F846D for ; Fri, 4 May 2012 19:58:03 -0700 (PDT) Received: from [192.168.1.125] (c-98-204-226-233.hsd1.va.comcast.net [98.204.226.233]) (Authenticated sender: morrowc@OPS-NETMAN.NET) by mailserver.ops-netman.net (Postfix) with ESMTPSA id ABCFA32008E; Sat, 5 May 2012 02:57:57 +0000 (UTC) Message-ID: <4FA49734.5090504@ops-netman.net> Date: Fri, 04 May 2012 22:57:56 -0400 From: Chris Morrow User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120410 Thunderbird/11.0.1 MIME-Version: 1.0 To: "Osterweil, Eric" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "'sidr-chairs@tools.ietf.org'" , "'Sandra.Murphy@sparta.com'" , "'sidr-ads@tools.ietf.org'" , "'sidr@ietf.org'" Subject: Re: [sidr] RPKI and private keys (was RE: Interim Meeting Draft Agenda: 04-30-2012 (April 30, 2012))) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 May 2012 02:58:04 -0000 On 05/04/2012 10:30 PM, Osterweil, Eric wrote: > > > Well, when u compared the key mgmt that is done today w/ the key mgmt > that will need to be done with bgpsec keys on routers, I think there > was an strained analogy. I'm talking about the latter, but I was > trying to indulge the discussion. ;) tis late on a friday... and this has a tiny screen... but: I was under the impression that Danny was originally asking about how to get the AS or ROUTER key material (used to sign updates as the pass by) onto the device in question. Take for example a router of in the disputed territory of crapinderburg: 1) you either shipped a device with a person to install it (or a person with secure comms and a router arrived separately) 2) that person would install the requisite cert material/key at installation time. Alternately that person does basic config (or the device is drop-shipped with basic config) and a remote/NOC/automation-job does the rest over a secure (I hope) channel, ie: ssh/scp. This would include installing the cert/key on the device (in some form of protected storage) There was mention in danny's note of 'the rpki distribution system...' and both sandy and I (and randy?) noted that the rpki-to-rtr (or like) protocol was never meant to handle this sort of thing, that other normal router configuration/management systems were meant to do it. Are we crossed up on the rpki-rtr vs 'other means' discussion currently? For reference, here's danny's quote that got the crossed up conversation started: "From there, we can discuss the issue of, for example, HOW TO onboard and purge signing and validating certificates to routers from the RPKI [I suspect the intention was to use rpki-rtr protocol for this, but it doesn't currently support it, nor are the security implications clear]." -chris From jakob.heitz@ericsson.com Fri May 4 20:02:07 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B38CB21F847D for ; Fri, 4 May 2012 20:02:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.367 X-Spam-Level: X-Spam-Status: No, score=-6.367 tagged_above=-999 required=5 tests=[AWL=0.232, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DGAhuoFCOKgL for ; Fri, 4 May 2012 20:02:07 -0700 (PDT) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by ietfa.amsl.com (Postfix) with ESMTP id 22DC121F8473 for ; Fri, 4 May 2012 20:02:06 -0700 (PDT) Received: from eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id q453223e012473 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 4 May 2012 22:02:02 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.6]) by eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) with mapi; Fri, 4 May 2012 23:02:01 -0400 From: Jakob Heitz To: Christopher Morrow , "Osterweil, Eric" Date: Fri, 4 May 2012 23:01:59 -0400 Thread-Topic: [sidr] RPKI and private keys (was RE: Interim Meeting Draft Agenda: 04-30-2012 (April 30, 2012))) Thread-Index: Ac0qYfrnYIXqAPDPSrqhGKMwzGj1DgACLaUg Message-ID: <7309FCBCAE981B43ABBE69B31C8D213921BE2860C3@EUSAACMS0701.eamcs.ericsson.se> References: <4FA48240.9060405@ops-netman.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "morrowc@ops-netman.net" , "Sandra.Murphy@sparta.com" , "sidr@ietf.org" , "sidr-chairs@tools.ietf.org" , "sidr-ads@tools.ietf.org" Subject: Re: [sidr] RPKI and private keys (was RE: Interim Meeting Draft Agenda: 04-30-2012 (April 30, 2012))) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 May 2012 03:02:07 -0000 Might it be possible to create the key pair on the router? Then you don't have to move the private key to the router, You move the public key off the router. Much easier. --=20 Jakob Heitz. On Friday, May 04, 2012 6:54 PM, Christopher Morrow <> wrote: > On Fri, May 4, 2012 at 9:37 PM, Osterweil, Eric > wrote:=20 >> Hey Chris, >>=20 >> Yeah, I read that. I know there's a tendency for some people to want >> to talk about bath houses on this list, but I was going to pass on >> that. =20 >>=20 >> As for draft-ymbk-bgpsec-rtr-rekeying-00.txt, that draft just points >> out the inadequacies of either approach and that there is no good >> solution. My take is that this is indicative of a misalignment >> between a given architecture and implicit requirements. Sometimes >> you can't patch the holes in a leaky ship, you need to reassess the >> requirements. I think the evidence illustrates that this is the case >> here. =20 >>=20 >=20 > it seems to me that putting key-material on a distant router is done > today... isn't it? or are you saying that how you do it today leaves > you feeling icky, and you'd rather another method be devised? >=20 > Could you outline a possible method? (provide a solution, for > instance)=20 >=20 >> Eric >>=20 >>=20 >> ----- Original Message ----- >> From: Chris Morrow [mailto:morrowc@ops-netman.net] >> Sent: Friday, May 04, 2012 09:28 PM >> To: Osterweil, Eric >> Cc: 'Sandra.Murphy@sparta.com' ; >> 'danny@tcb.net' ; 'morrowc.lists@gmail.com' >> ; 'sidr@ietf.org' ; >> 'sidr-chairs@tools.ietf.org' ; >> 'sidr-ads@tools.ietf.org' =20 >> Subject: Re: [sidr] RPKI and private keys (was RE: Interim Meeting >> Draft Agenda: 04-30-2012 (April 30, 2012)))=20 >>=20 >>=20 >>=20 >> On 05/04/2012 08:59 PM, Osterweil, Eric wrote: >>=20 >>> His point is NOT addressed by any draft in the wg (since you asked). >>=20 >> read randy's mentioned draft? From morrowc@ops-netman.net Fri May 4 20:04:51 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DD5F21F847D for ; Fri, 4 May 2012 20:04:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.549 X-Spam-Level: X-Spam-Status: No, score=-2.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oN7YiK14fTfP for ; Fri, 4 May 2012 20:04:51 -0700 (PDT) Received: from mailserver.ops-netman.net (mailserver.ops-netman.net [IPv6:2001:470:e495:fade:5054:ff:fe79:69db]) by ietfa.amsl.com (Postfix) with ESMTP id 223C721F8473 for ; Fri, 4 May 2012 20:04:51 -0700 (PDT) Received: from [192.168.1.125] (c-98-204-226-233.hsd1.va.comcast.net [98.204.226.233]) (Authenticated sender: morrowc@OPS-NETMAN.NET) by mailserver.ops-netman.net (Postfix) with ESMTPSA id 3A65F3202F6; Sat, 5 May 2012 03:04:50 +0000 (UTC) Message-ID: <4FA498D1.7060201@ops-netman.net> Date: Fri, 04 May 2012 23:04:49 -0400 From: Chris Morrow User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120410 Thunderbird/11.0.1 MIME-Version: 1.0 To: Jakob Heitz References: <4FA48240.9060405@ops-netman.net> <7309FCBCAE981B43ABBE69B31C8D213921BE2860C3@EUSAACMS0701.eamcs.ericsson.se> In-Reply-To: <7309FCBCAE981B43ABBE69B31C8D213921BE2860C3@EUSAACMS0701.eamcs.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "sidr-chairs@tools.ietf.org" , "Sandra.Murphy@sparta.com" , "sidr-ads@tools.ietf.org" , "sidr@ietf.org" Subject: Re: [sidr] RPKI and private keys (was RE: Interim Meeting Draft Agenda: 04-30-2012 (April 30, 2012))) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 May 2012 03:04:51 -0000 On 05/04/2012 11:01 PM, Jakob Heitz wrote: > Might it be possible to create the key pair on the router? > Then you don't have to move the private key to the router, > You move the public key off the router. Much easier. you could, but I presume the thing being created is really a cert (ee-cert) and is signed by the 'as-cert' that is published in the RPKI so folk can say: This route I see, is signed by bloof123 which is signed by bloof-asn - that looks like AS123's cert, and the sig is in the place where AS123 is supposed to be" So, you'd need to effectively (I think) do a CSR, send that to the CA for signing, and off back with the actual Cert to the device. -chris From randy@psg.com Fri May 4 20:33:49 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF4E521F8463 for ; Fri, 4 May 2012 20:33:49 -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=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zpAbMphFOf3d for ; Fri, 4 May 2012 20:33:49 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id 4BE1121F8462 for ; Fri, 4 May 2012 20:33:49 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1SQVkf-0006pm-7D; Sat, 05 May 2012 03:33:45 +0000 Date: Fri, 04 May 2012 17:33:43 -1000 Message-ID: From: Randy Bush To: Jakob Heitz In-Reply-To: <7309FCBCAE981B43ABBE69B31C8D213921BE2860C3@EUSAACMS0701.eamcs.ericsson.se> References: <4FA48240.9060405@ops-netman.net> <7309FCBCAE981B43ABBE69B31C8D213921BE2860C3@EUSAACMS0701.eamcs.ericsson.se> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: sidr wg list Subject: Re: [sidr] RPKI and private keys (was RE: Interim Meeting Draft Agenda: 04-30-2012 (April 30, 2012))) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 May 2012 03:33:49 -0000 > Might it be possible to create the key pair on the router? > Then you don't have to move the private key to the router, > You move the public key off the router. Much easier. draft-ymbk-bgpsec-rtr-rekeying-00.txt, section 3. Router-Generated Keys From randy@psg.com Fri May 4 20:46:56 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9905211E8081 for ; Fri, 4 May 2012 20:46:56 -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=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KuqKQIPHNHjP for ; Fri, 4 May 2012 20:46:56 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id 3FF4B11E8072 for ; Fri, 4 May 2012 20:46:56 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1SQVxP-0006r8-Ec; Sat, 05 May 2012 03:46:55 +0000 Date: Fri, 04 May 2012 17:46:54 -1000 Message-ID: From: Randy Bush To: Chris Morrow In-Reply-To: <4FA49734.5090504@ops-netman.net> References: <4FA49734.5090504@ops-netman.net> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: sidr wg list Subject: Re: [sidr] RPKI and private keys (was RE: Interim Meeting Draft Agenda: 04-30-2012 (April 30, 2012))) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 May 2012 03:46:56 -0000 > "From there, we can discuss the issue of, for example, HOW TO onboard > and purge signing and validating certificates to routers from the RPKI > [I suspect the intention was to use rpki-rtr protocol for this, but it > doesn't currently support it, nor are the security implications clear]." it is very hard to understand this, but this is my guess. certificates do not sign, keys do, and not the public keys which are in the certificates, but the corresponding private keys. the public keys used to validate bgpsec signatures are in router ee certs in the rpki. indeed some of the router ee cert's data will need to be in validating routers. indeed there currently is no specification for how this is done. indeed, the rpki-rtr protocol could be extended to do this, should be trivial. but, until we have the bgpsec protocol nailed down a bit further, this would be premature. and i have said this at least once before, though possibly in private email to danny. randy From brian.peter.dickson@gmail.com Mon May 7 11:58:36 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7545C21F85E5 for ; Mon, 7 May 2012 11:58:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.205 X-Spam-Level: X-Spam-Status: No, score=-2.205 tagged_above=-999 required=5 tests=[AWL=-1.021, BAYES_40=-0.185, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1dKpYQOF74cE for ; Mon, 7 May 2012 11:58:35 -0700 (PDT) Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) by ietfa.amsl.com (Postfix) with ESMTP id 19C8E21F8534 for ; Mon, 7 May 2012 11:58:31 -0700 (PDT) Received: by wibhq2 with SMTP id hq2so719870wib.13 for ; Mon, 07 May 2012 11:58:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=IqRcpD360XO6+/4CWHFQ3VmkDO0oh4SE7uPEYGMN2GI=; b=1I4gZeAXpj0mOe/BkuQfzsBCwm3P6N1g2WYrCCxGtKxSKAwNv/O9dRm0sSSGNkm+GI ICKAElMiuZXu1TYzxinvGOeXSGTE6TEoNyA8uZtzXtLACZ2+SxbgVnsE4ERjyt5aYS4f /PwLeMRhtv1zQDOnV3sF2+d1g3p1ARGH3HIS0eIFZWFl1CBvJcQBoYIHWv3VQmFUuSUY VF5uRNpmJ4VuSnhpw8ZrCt1u2j13e22o4rB7hqqfi04l7NSoSjJ15+vs9VmVSxSFP7se AIQHgTcjElHno9louODD+tuk+m1axNj4OG3c6Gn21K0ZQuzYHuhcVm6iA9HH+lGzVa7Y yB7g== MIME-Version: 1.0 Received: by 10.180.105.69 with SMTP id gk5mr43236014wib.3.1336417111287; Mon, 07 May 2012 11:58:31 -0700 (PDT) Received: by 10.223.93.138 with HTTP; Mon, 7 May 2012 11:58:31 -0700 (PDT) Date: Mon, 7 May 2012 14:58:31 -0400 Message-ID: From: Brian Dickson To: sidr wg list Content-Type: multipart/alternative; boundary=f46d04426f1430a89804bf76db1f Subject: [sidr] Keys and algorithms for Updates - feasibility analysis? (was Re: RPKI and private keys) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 May 2012 18:58:36 -0000 --f46d04426f1430a89804bf76db1f Content-Type: text/plain; charset=ISO-8859-1 At the interim meeting (30th of April 2012), I briefly discussed the performance differential of doing something other than the proposed crypto, for "signing" updates. While the relative benefit I suggested, "100x - 1000x" raised some eyebrows, it was something I thought worth exploring a bit further. It turns out to be 7000x (to as much as 50,000x, depending on amount of entropy desired.) I did some simple benchmarks, to try to compare a very limited work-load, apples-to-apples. The test cases all presume everything/nothing regarding validation; I was interested only in the absolute and relative workloads imposed by "signing" when done by a bgpsec-speaker in sending to another bgpsec-speaker. Any of the per-session (initialization overhead) was ignored, since that is presumed only needed for setting up the initial state for the speakers' session. These test cases are designed to compare what is currently specified in the -algorithms (and referenced via the -protocol) specs, to something based on random data, where the latter would require some out-of-band method for doing validation. The results were a real eye-opener, and as such, I am hoping I'm not the only one to have done this, and that there exists some of this kind of testing, done previously. So, what I'm asking is, have such results been published or shared to the SIDR group, and if so, would someone please send me a link to them? And if not, then maybe this is something that either needs to be discussed, or is a big enough deal that I will feel obliged to work on my own stuff, outside of SIDR. Brian Simple test results follow: =================== Scenario 1: perform basic update signature once, repeat for routing table of 400,000 in size. signature operation: set message size to N bytes, representing size of previous sig, plus added elements (receiver ASN, etc.) perform sha256 on message, producing digest perform ecdsa on digest, using secp256r1, producing signature Scenario 1 platform: Macbook Pro late 2011, 15" (intel i7 single cpu, dual-core, 8GB ram) Scenario 1 results, estimated: 700 seconds Scenario 2: perform basic pseudo-signature once, repeat for routing table of 400,000 in size. pseudo-signature operation: use N distinct pseudo-random number generators (PNRG), seeded separately with state preservation (N=8 corresponds to 256 bits of entropy) call random() from each preserved state to generate a 32-bit random number, concatenate the N x 32 bit values Scenario 2 platform - same as Scenario 1 Scenario 2 results, estimated: 0.09 seconds ================== While the 7000+ relative performance is pretty substantial, the absolute time required is the deal-breaker. Getting signatures attached to one copy of the routing table, being sent over a single BGPSEC session, taking 700 seconds on modern commodity hardware is beyond the pale. And given that current generation hardware has CPUs at least an order of magnitude slower, or possibly two orders of magnitude, suggests that software-based bgpsec can never work. The fact that bgpsec is strictly an overhead function, generating no revenue, means that requiring hardware support for crypto is mandatory, for every router in the signing path. When this is contrasted with 0.09 seconds (for adding a high-entropy, unique nonce, to every prefix on a copy of the full routing table sent over a single session), the contrast is stark. If alternatives to the heavy crypto have never been explored, maybe they should be. Yes, the OOB validation presents a challenge, for validation. But, given that validation itself in the current protocol requires yet-to-be-designed methods for getting certs onto routers (with the embedded public keys), I'm not sure this is a de-facto valid criticism, or is at best hypocritical. I suspect that while I may be participating as an observer in SIDR, without looking at alternatives like this, the only real value I see in the work by SIDR is the RPKI (and maybe rpki-rtr). I do want to work on things that will provide protection against threats to BGP. However, the solution IMHO needs to be incrementally deployable, meaning on existing classes of hardware. And the threats need to include path shortening, route leaks, and replay/withdrawl-blocking. I'm not sure I expect responses from anyone in particular, but want to be clear on where I see the important issues as lying. If the work I'm interested in isn't something the WG wants to pursue, that's okay - I'll pursue it on my own. Regards, Brian --f46d04426f1430a89804bf76db1f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable At the interim meeting (30th of April 2012), I briefly discussed the perfor= mance differential of doing something other than the proposed crypto, for &= quot;signing" updates.

While the relative benefit I suggested, = "100x - 1000x" raised some eyebrows, it was something I thought w= orth exploring a bit further. It turns out to be 7000x (to as much as 50,00= 0x, depending on amount of entropy desired.)

I did some simple benchmarks, to try to compare a very limited work-loa= d, apples-to-apples.

The test cases all presume everything/nothing r= egarding validation; I was interested only in the absolute and relative wor= kloads imposed by "signing" when done by a bgpsec-speaker in send= ing to another bgpsec-speaker.

Any of the per-session (initialization overhead) was ignored, since tha= t is presumed only needed for setting up the initial state for the speakers= ' session.

These test cases are designed to compare what is curr= ently specified in the -algorithms (and referenced via the -protocol) specs= , to something based on random data, where the latter would require some ou= t-of-band method for doing validation.

The results were a real eye-opener, and as such, I am hoping I'm no= t the only one to have done this, and that there exists some of this kind o= f testing, done previously.

So, what I'm asking is, have such re= sults been published or shared to the SIDR group, and if so, would someone = please send me a link to them?

And if not, then maybe this is something that either needs to be discus= sed, or is a big enough deal that I will feel obliged to work on my own stu= ff, outside of SIDR.

Brian

Simple test results follow:
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Scenario 1= :
perform basic update signature once, repeat for routing table of 400,0= 00 in size.
=A0 signature operation:
=A0=A0=A0=A0 set message size to= N bytes, representing size of previous sig, plus added elements (receiver = ASN, etc.)
=A0=A0=A0=A0 perform sha256 on message, producing digest
=A0=A0=A0=A0 pe= rform ecdsa on digest, using secp256r1, producing signature

Scenario= 1 platform: Macbook Pro late 2011, 15" (intel i7 single cpu, dual-cor= e, 8GB ram)
Scenario 1 results, estimated: 700 seconds

Scenario 2:
perform ba= sic pseudo-signature once, repeat for routing table of 400,000 in size.
= =A0 pseudo-signature operation:
=A0=A0=A0=A0 use N distinct pseudo-rando= m number generators (PNRG), seeded separately with state preservation (N=3D= 8 corresponds to 256 bits of entropy)
=A0=A0=A0=A0 call random() from each preserved state to generate a 32-bit r= andom number, concatenate the N x 32 bit values

Scenario 2 platform = - same as Scenario 1
Scenario 2 results, estimated: 0.09 seconds

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

While the 7000+ relative performance is pretty substantial, the absolut= e time required is the deal-breaker.

Getting signatures attached to = one copy of the routing table, being sent over a single BGPSEC session, tak= ing 700 seconds on modern commodity hardware is beyond the pale.
And given that current generation hardware has CPUs at least an order of ma= gnitude slower, or possibly two orders of magnitude, suggests that software= -based bgpsec can never work.
The fact that bgpsec is strictly an overhe= ad function, generating no revenue, means that requiring hardware support f= or crypto is mandatory, for every router in the signing path.

When this is contrasted with 0.09 seconds (for adding a high-entropy, u= nique nonce, to every prefix on a copy of the full routing table sent over = a single session), the contrast is stark.

If alternatives to the hea= vy crypto have never been explored, maybe they should be.

Yes, the OOB validation presents a challenge, for validation. But, give= n that validation itself in the current protocol requires yet-to-be-designe= d methods for getting certs onto routers (with the embedded public keys), I= 'm not sure this is a de-facto valid criticism, or is at best hypocriti= cal.

I suspect that while I may be participating as an observer in SIDR, wit= hout looking at alternatives like this, the only real value I see in the wo= rk by SIDR is the RPKI (and maybe rpki-rtr).

I do want to work on th= ings that will provide protection against threats to BGP.
However, the solution IMHO needs to be incrementally deployable, meaning on= existing classes of hardware.
And the threats need to include path shor= tening, route leaks, and replay/withdrawl-blocking.

I'm not sure= I expect responses from anyone in particular, but want to be clear on wher= e I see the important issues as lying.
If the work I'm interested in isn't something the WG wants to pursu= e, that's okay - I'll pursue it on my own.

Regards,
Brian=
--f46d04426f1430a89804bf76db1f-- From christopher.morrow@gmail.com Mon May 7 13:29:18 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C7C621F867E for ; Mon, 7 May 2012 13:29:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.582 X-Spam-Level: X-Spam-Status: No, score=-103.582 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5dplLM4yPTPI for ; Mon, 7 May 2012 13:29:17 -0700 (PDT) Received: from mail-qa0-f49.google.com (mail-qa0-f49.google.com [209.85.216.49]) by ietfa.amsl.com (Postfix) with ESMTP id 775F921F8659 for ; Mon, 7 May 2012 13:29:17 -0700 (PDT) Received: by qabj40 with SMTP id j40so3563720qab.15 for ; Mon, 07 May 2012 13:29:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=gOQ2PtApbtWP0qaKWeEE7Tlu+FcFrQVmd4hbSzuUVaI=; b=Fu5ObXxrFmJgdrIEgmToPnf+nJNdXISy4ChA3pn92g8dIYAUXgWUllPeQ37VqjPEXK oEQtd2p39C00Z4+7jxNtwaRUORS5hGPBRTEjGMUklgQ8Yh0sc2IgnK4ChHT8mQoAhyN1 ksnMVsFZQwXzO12anWTw9msN7vuri1mi8jLhpvbvvVgQQ0XVmQbpZ3AWn+9hSCpK7pMF W5DgyLL4olbPsVuF3Uef4P3eSOdeazE96QZmHYTqvlD0BvPjsVb4iIIjjUGjomiuO3RC B+BIaTCOh8Mgh25qnE46YrHsEBQZFOcLimAkbzGlkDAZjGR2ttrkiWBBWsSDZMyT9+wS CaUA== MIME-Version: 1.0 Received: by 10.60.4.1 with SMTP id g1mr23327497oeg.55.1336422556763; Mon, 07 May 2012 13:29:16 -0700 (PDT) Sender: christopher.morrow@gmail.com Received: by 10.182.155.39 with HTTP; Mon, 7 May 2012 13:29:16 -0700 (PDT) In-Reply-To: References: Date: Mon, 7 May 2012 16:29:16 -0400 X-Google-Sender-Auth: u0QNM2BWmu9Si51dVdU1733XZS4 Message-ID: From: Christopher Morrow To: Brian Dickson Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: sidr wg list Subject: Re: [sidr] Keys and algorithms for Updates - feasibility analysis? (was Re: RPKI and private keys) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 May 2012 20:29:18 -0000 I'm probably confused, or the example has been simplified.. but On Mon, May 7, 2012 at 2:58 PM, Brian Dickson wrote: > Scenario 2: > perform basic pseudo-signature once, repeat for routing table of 400,000 = in > size. > =A0 pseudo-signature operation: > =A0=A0=A0=A0 use N distinct pseudo-random number generators (PNRG), seede= d > separately with state preservation (N=3D8 corresponds to 256 bits of entr= opy) > =A0=A0=A0=A0 call random() from each preserved state to generate a 32-bit= random > number, concatenate the N x 32 bit values how do I check 3 as-hops away that whatever is attached to the update means that the update was signed? you seem to be saying: "sign with some random bytes that you make up on the fly". -chris From christopher.morrow@gmail.com Mon May 7 13:52:35 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F0D321F843F for ; Mon, 7 May 2012 13:52:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.583 X-Spam-Level: X-Spam-Status: No, score=-103.583 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TN1dQsU2utVK for ; Mon, 7 May 2012 13:52:34 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4AAD221F843A for ; Mon, 7 May 2012 13:52:34 -0700 (PDT) Received: by obbeh20 with SMTP id eh20so10458539obb.31 for ; Mon, 07 May 2012 13:52:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=Xzs5JjGqkhDEjcF49GVZi33Krqe4EnUbAYbWqmAV6QM=; b=o8tOoH8yM8kvUP6J2JL6IOjiwOfC6HoSj02egG5av3ISXPg8hSO/La8SR6pzI8YS90 EpW2eRMBSPewx6wTFBge32p+zgKP3KEzPYIgfQrNP9c0ZOLnQEsDZFcml9x95IIR+uaM T5ZZk1JGlZ1Rge9c4Dg3Hn/DdX1iANeczK3zOMwP/3j2Vi1PoI/ROyyEs+0WTbVyCQjD qYGcPgZ9y051MbkPRGfTfekExLZClhFORmpJFtasv8AjnPrAn/BDwMG5wFv5gE3SKFx1 cRTRIo0Ymwa2oP+gL8RUnc01MorKhLpmqApxrZv0SJ/D0IuIinh7MrnEGhGHVRKNTGO5 4Jcg== MIME-Version: 1.0 Received: by 10.182.167.40 with SMTP id zl8mr14015180obb.39.1336423953810; Mon, 07 May 2012 13:52:33 -0700 (PDT) Sender: christopher.morrow@gmail.com Received: by 10.182.155.39 with HTTP; Mon, 7 May 2012 13:52:33 -0700 (PDT) In-Reply-To: References: Date: Mon, 7 May 2012 16:52:33 -0400 X-Google-Sender-Auth: 7Lht1Rt-uAQh2AHzvzjnzVoyS94 Message-ID: From: Christopher Morrow To: Brian Dickson Content-Type: text/plain; charset=ISO-8859-1 Cc: sidr wg list Subject: Re: [sidr] Keys and algorithms for Updates - feasibility analysis? (was Re: RPKI and private keys) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 May 2012 20:52:35 -0000 On Mon, May 7, 2012 at 2:58 PM, Brian Dickson wrote: > And given that current generation hardware has CPUs at least an order of > magnitude slower, or possibly two orders of magnitude, suggests that > software-based bgpsec can never work. for clarity, I think a 'normal': o 7200 these days ships with a 1ghz cpu o Cisco CRS ~2.13ghz Intel o Juniper M/T/MX ~2ghz Intel o Cisco 12000/XR (prp2 single-core, 3 dual-core) 1.3GHz PPC None of these is an order of magnitude smaller than a desktop-cpu. Even a 7500 with a 600mhzRISC is not an order of magnitude. (by the mhz/ghz numbers at least, speedups in math done in assembly aside) From brian.peter.dickson@gmail.com Mon May 7 13:56:32 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5A2821F8470 for ; Mon, 7 May 2012 13:56:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.298 X-Spam-Level: X-Spam-Status: No, score=-3.298 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rSIjvn-osjcD for ; Mon, 7 May 2012 13:56:32 -0700 (PDT) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id AE10021F8464 for ; Mon, 7 May 2012 13:56:31 -0700 (PDT) Received: by werf13 with SMTP id f13so2868615wer.31 for ; Mon, 07 May 2012 13:56:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=uOaqqHapWOPFFPttnKpV4NKgN3U9q4Gjnt2WN8mMMjM=; b=jykhQFG8Ru5PsW//7gZEL2mEnogIRR9q/+xQ/ZLB3Lfxl/nKHXmGqqUWM9+NL+sfJj d6Tr2gL3d+3uaoAMkAT3MhqfacPmu3ZYmhfO+vdJgYCzPEEZeWnCDDYbrmKNTLPtDd9I aKyC/1pxxBiJL+rRbQPQJNh2gisRC0ZbaxSczcIsIqTXRIongPzazUBMsQhVjmRullWC kXt/NtjLbGxwMRfl93xULfR7gMPmKKN4f0GLU/kE8O6ucE3pBVCYosNNcvp1ZM3VkDor dsK6jAtG7Fl2itzp5i37NtT1GC9d41qaCsnXWcHi4VMHCKmKhJYAYDC8rjGjoHqf9San LhOw== MIME-Version: 1.0 Received: by 10.180.100.230 with SMTP id fb6mr14111973wib.3.1336424190802; Mon, 07 May 2012 13:56:30 -0700 (PDT) Received: by 10.223.93.138 with HTTP; Mon, 7 May 2012 13:56:30 -0700 (PDT) In-Reply-To: References: Date: Mon, 7 May 2012 16:56:30 -0400 Message-ID: From: Brian Dickson To: Christopher Morrow Content-Type: multipart/alternative; boundary=f46d041824ee297ca204bf788157 Cc: sidr wg list Subject: Re: [sidr] Keys and algorithms for Updates - feasibility analysis? (was Re: RPKI and private keys) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 May 2012 20:56:33 -0000 --f46d041824ee297ca204bf788157 Content-Type: text/plain; charset=ISO-8859-1 The particulars are a bit vague at the moment, beyond a back-of-the-envelope design. For OOB validation, you need the following kinds of things: - a validator box - an auth-data source of truth - some way of knowing that the source of truth is legitimate - a way for the signing router to establish sync with the source of truth The auth-data source-of-truth could have credentials in RPKI. (Actually, this would probably be mandatory.) The router and source-of-truth would need to have some scheme for seeding PNRGs identically, e.g. using DH shared secret(s). The source-of-truth would probably need a running feed of discarded nonces (to avoid memory exhaustion), possibly via ordinals (N for Nth PNRG value, rather than the value itself), possibly using RLE (run-length encoding). The validator would need to talk to the source-of-truth, using a query/answer type protocol, preferably with cacheable answers, preferably over some secured channel (e.g. using DH shared secret). So the process for validating 3 as-hops away would be something like: - receive the nonced-update - send the relevant bits to the OOB validator (locally operated cacheing validator "box") - wait for an appropriate answer from the OOB validator, mark according to the answer received - OOB validator can be treated as a modest-latency, high-bandwidth black-box,maybe with some occasional jitter. The validator would handle a feed per peering session, per router; how it scales is a question of implementation, optimization, load issues, etc. Cacheable answers yield benefits immediately, in terms of scaling behavior. The validator would probably want to handle several aspects of its job in a smart manner - sensible behavior regarding latency to individual source-of-truth hosts - sensible behavior in the face of network issues - local optimizations intra-AS and even inter-AS for additional caching - pre-loaded data for validation of cached data (e.g. KSK DNSKEYs for zones if the validation uses DNSSEC, as an example.) - sufficient number of answer "states" which can be interpreted in a suitable fashion, like FAILED_VALIDATION, NO_ANSWER_YET, NO_ANSWER, NOT_FOUND, ORIGIN_VALIDATION_FAILED, or VALID - sane design regarding FIFO nature of BGP (mandatory) and head-of-line blocking (bad juju) Fundamentally, though, modulo caching logic, the validator would directly query the source-of-truth for the ASN which is 3 as-hops away. Brian On Mon, May 7, 2012 at 4:29 PM, Christopher Morrow wrote: > I'm probably confused, or the example has been simplified.. but > > On Mon, May 7, 2012 at 2:58 PM, Brian Dickson > wrote: > > Scenario 2: > > perform basic pseudo-signature once, repeat for routing table of 400,000 > in > > size. > > pseudo-signature operation: > > use N distinct pseudo-random number generators (PNRG), seeded > > separately with state preservation (N=8 corresponds to 256 bits of > entropy) > > call random() from each preserved state to generate a 32-bit random > > number, concatenate the N x 32 bit values > > how do I check 3 as-hops away that whatever is attached to the update > means that the update was signed? you seem to be saying: "sign with > some random bytes that you make up on the fly". > > -chris > --f46d041824ee297ca204bf788157 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable The particulars are a bit vague at the moment, beyond a back-of-the-envelop= e design.

For OOB validation, you need the following kin= ds of things:
- a validator box
- an auth-data source o= f truth
- some way of knowing that the source of truth is legitimate
- a way for the signing router to establish sync with the source of truth<= /div>

The auth-data source-of-truth could have credentia= ls in RPKI. (Actually, this would probably be mandatory.)
The router and source-of-truth would need to have some scheme for seed= ing PNRGs identically, e.g. using DH shared secret(s).
The source= -of-truth would probably need a running feed of discarded nonces (to avoid = memory exhaustion), possibly via ordinals (N for Nth PNRG value, rather tha= n the value itself), possibly using RLE (run-length encoding).
The validator would need to talk to the source-of-truth, using a query= /answer type protocol, preferably with cacheable answers, preferably over s= ome secured channel (e.g. using DH shared secret).

So the process for validating 3 as-hops away would be something like:<= /div>
- receive the nonced-update
- send the relevant bits to= the OOB validator (locally operated cacheing validator "box")
- wait for an appropriate answer from the OOB validator, mark accordin= g to the answer received
- OOB validator can be treated as a mode= st-latency, high-bandwidth black-box,maybe with some occasional jitter.

The validator would handle a feed per peering session, = per router; how it scales is a question of implementation, optimization, lo= ad issues, etc.
Cacheable answers yield benefits immediately, in = terms of scaling behavior.

The validator would probably want to handle several asp= ects of its job in a smart manner
- sensible behavior regarding l= atency to individual source-of-truth hosts
- sensible behavior in= the face of network issues
- local optimizations intra-AS and even inter-AS for additional cachin= g
- pre-loaded data for validation of cached data (e.g. KSK DNSKE= Ys for zones if the validation uses DNSSEC, as an example.)
- suf= ficient number of answer "states" which can be interpreted in a s= uitable fashion, like FAILED_VALIDATION, NO_ANSWER_YET, NO_ANSWER, NOT_FOUN= D, ORIGIN_VALIDATION_FAILED, or VALID
- sane design regarding FIFO nature of BGP (mandatory) and head-of-lin= e blocking (bad juju)

Fundamentally, though, modul= o caching logic, the validator would directly query the source-of-truth for= the ASN which is 3 as-hops away.

Brian

On Mon, May 7, = 2012 at 4:29 PM, Christopher Morrow <morrowc.lists@gmail.com>= wrote:
I'm probably confused, or the example ha= s been simplified.. but

On Mon, May 7, 2012 at 2:58 PM, Brian Dickson
<brian.peter.dickson@gm= ail.com> wrote:
> Scenario 2:
> perform basic pseudo-signature once, repeat for routing table of 400,0= 00 in
> size.
> =A0 pseudo-signature operation:
> =A0=A0=A0=A0 use N distinct pseudo-random number generators (PNRG), se= eded
> separately with state preservation (N=3D8 corresponds to 256 bits of e= ntropy)
> =A0=A0=A0=A0 call random() from each preserved state to generate a 32-= bit random
> number, concatenate the N x 32 bit values

how do I check 3 as-hops away that whatever is attached to the update=
means that the update was signed? you seem to be saying: "sign with some random bytes that you make up on the fly".

-chris

--f46d041824ee297ca204bf788157-- From brian.peter.dickson@gmail.com Mon May 7 14:00:57 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C376821F84E7 for ; Mon, 7 May 2012 14:00:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.157 X-Spam-Level: X-Spam-Status: No, score=-3.157 tagged_above=-999 required=5 tests=[AWL=0.441, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BkULrAbJp0N9 for ; Mon, 7 May 2012 14:00:57 -0700 (PDT) Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) by ietfa.amsl.com (Postfix) with ESMTP id E09B821F84E6 for ; Mon, 7 May 2012 14:00:56 -0700 (PDT) Received: by wibhq2 with SMTP id hq2so808946wib.13 for ; Mon, 07 May 2012 14:00:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=1DzJRSGnZqo1U/6WHqmMJHJ+dnUdOTO3MPLSjMINrZM=; b=PYfNiDGQdMJ4EAfkrBlalWJrheZfHHvCfVTb1WIO+o+gHqvb52C2wXmr90y3Kh3Yz8 aABg0aPvp1zXLCll2P9qFF2LSlPOEE31MJyTdoCtXxkW1NNrQ4gudgKO1Mswrzjd4U2R +b2HOtH9OlGf8o9s2shtRckJY8vjcuZswCm5hS4moHdb7bcKoMy3p1S+NKg1TJAYr2qY CQTJlTGsIVbY6dbzRzGFRbZWo140AUEBqOJc3DS+qJElW5diXNnC0fRnWD2oWiB5MpFb EZqg31NfpRe55M+ziDabahTeeBWLNJaMIF4ZjzVJ6g2EFSIwIlL8QZCKR/U2ilhr5XaE Sv7A== MIME-Version: 1.0 Received: by 10.180.100.230 with SMTP id fb6mr14140662wib.3.1336424456071; Mon, 07 May 2012 14:00:56 -0700 (PDT) Received: by 10.223.93.138 with HTTP; Mon, 7 May 2012 14:00:55 -0700 (PDT) In-Reply-To: References: Date: Mon, 7 May 2012 17:00:55 -0400 Message-ID: From: Brian Dickson To: Christopher Morrow Content-Type: multipart/alternative; boundary=f46d041824eef9281304bf7890c0 Cc: sidr wg list Subject: Re: [sidr] Keys and algorithms for Updates - feasibility analysis? (was Re: RPKI and private keys) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 May 2012 21:00:58 -0000 --f46d041824eef9281304bf7890c0 Content-Type: text/plain; charset=ISO-8859-1 Even at CPU parity, or even with modest N x CPU performance for single digit N, same ballpark. The expected performance once you load up the number of BGPSEC sessions, add on churn, etc., is a lot worse. And, my little laptop was basically idle, not doing all the other work that a router CPU needs to do. Brian On Mon, May 7, 2012 at 4:52 PM, Christopher Morrow wrote: > On Mon, May 7, 2012 at 2:58 PM, Brian Dickson > wrote: > > And given that current generation hardware has CPUs at least an order of > > magnitude slower, or possibly two orders of magnitude, suggests that > > software-based bgpsec can never work. > > for clarity, I think a 'normal': > o 7200 these days ships with a 1ghz cpu > o Cisco CRS ~2.13ghz Intel > o Juniper M/T/MX ~2ghz Intel > o Cisco 12000/XR (prp2 single-core, 3 dual-core) 1.3GHz PPC > > None of these is an order of magnitude smaller than a desktop-cpu. > Even a 7500 with a 600mhzRISC is not an order of magnitude. (by the > mhz/ghz numbers at least, speedups in math done in assembly aside) > --f46d041824eef9281304bf7890c0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Even at CPU parity, or even with modest N x CPU performance for single digi= t N, same ballpark.
The expected performance once you load up the numbe= r of BGPSEC sessions, add on churn, etc., is a lot worse.
And, my= little laptop was basically idle, not doing all the other work that a rout= er CPU needs to do.

Brian

On Mon, May 7, = 2012 at 4:52 PM, Christopher Morrow <morrowc.lists@gmail.com>= wrote:
On Mon, May 7, 2012 at 2:5= 8 PM, Brian Dickson
<brian.peter.dickson@gm= ail.com> wrote:
> And given that current generation hardware has= CPUs at least an order of
> magnitude slower, or possibly two orders of magnitude, suggests that > software-based bgpsec can never work.

for clarity, I think a 'normal':
=A0o 7200 these days ships with a 1ghz cpu
=A0o Cisco CRS ~2.13ghz Intel
=A0o Juniper M/T/MX ~2ghz Intel
=A0o Cisco 12000/XR (prp2 single-core, 3 dual-core) 1.3GHz PPC

None of these is an order of magnitude smaller than a desktop-cpu.
Even a 7500 with a 600mhzRISC is not an order of magnitude. (by the
mhz/ghz numbers at least, speedups in math done in assembly aside)

--f46d041824eef9281304bf7890c0-- From kotikalapudi.sriram@nist.gov Mon May 7 17:15:02 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A956721F8622 for ; Mon, 7 May 2012 17:15:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.569 X-Spam-Level: X-Spam-Status: No, score=-6.569 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9qGh8X-Qk8+8 for ; Mon, 7 May 2012 17:15:01 -0700 (PDT) Received: from wsget1.nist.gov (wsget1.nist.gov [129.6.13.150]) by ietfa.amsl.com (Postfix) with ESMTP id 9FF9821F8629 for ; Mon, 7 May 2012 17:15:01 -0700 (PDT) Received: from WSXGHUB2.xchange.nist.gov (129.6.18.19) by wsget1.nist.gov (129.6.13.150) with Microsoft SMTP Server (TLS) id 14.1.355.2; Mon, 7 May 2012 20:14:34 -0400 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB2.xchange.nist.gov ([129.6.18.19]) with mapi; Mon, 7 May 2012 20:13:51 -0400 From: "Sriram, Kotikalapudi" To: "Brian Dickson (brian.peter.dickson@gmail.com)" Date: Mon, 7 May 2012 20:14:35 -0400 Thread-Topic: [sidr] Keys and algorithms for Updates - feasibility analysis? (was Re: RPKI and private keys) Thread-Index: Ac0sn4X5n0UXmywbRrOKZN7PF/9/KQACMZ1AAAAFxZA= Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "sidr wg list \(sidr@ietf.org\)" Subject: Re: [sidr] Keys and algorithms for Updates - feasibility analysis? (was Re: RPKI and private keys) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 May 2012 00:15:02 -0000 Brian, Thanks. I bring this back on the SIDR list as others may be having the same= questions.=20 I have no grasp of the details of your method based on crypto fundamentals = yet, but at a different level I have some performance questions based on the des= criptions that you have provided. Per your explanation below, the validating router or the OOB validator is d= oing query/response per update. That would entail one or more round-trip messaging delays (between the vali= dating entity and each of the signing ASes or "sources-of-truth") in the validation proce= ssing time of each update.=20 These delays would need to be factored into processing speed estimate for u= pdate validation, which may be slowed down considerably as a result. Would you agree? For the signing speed, earlier you had estimated 400,000/(0.09 sec) =3D 4.4= million (approx.) signings per second. Now you are saying, "Software-based signing at 10,000/sec is still able to = produce adequate results at very low costs." What caused the drastic lowering of the signing speed estimate from 4.4 mil= lion to 10,000 per sec (or perhaps I misunderstood something)? Sriram=20 > >From: Brian Dickson [mailto:brian.peter.dickson@gmail.com] >Sent: Monday, May 07, 2012 6:21 PM >To: Sriram, Kotikalapudi >Subject: Re: [sidr] Keys and algorithms for Updates - feasibility analysis= ? (was Re: >RPKI and private keys) > >Yes, per update. > >The router would spew its incoming updates (or pieces of them) to the OOB >validator, who would be responsible for looking them up, doing retries/tim= e- >out/caching, etc. > >The router would not be doing the queries, per se. But it would pass on th= e bulk >update data, and the validator would need to possible/probably do multiple >queries per update. > >E.g. If there was a single update with AS path of "3 2 1"=A0 (originated b= y AS 1), and >nonces "N3 N2 N1", the router would send a request to the validator, sayin= g >"isvalid:3,2,1:N3,N2,N1", and the validator would then look up N3 at the s= ource- >of-truth for AS 3, as well as looking up N2 at AS 2's source-of-truth, and= N1 at AS >1's source of truth. > >Depending on how the system was built and operated, any number of things >could optimize look-ups: >- the OOB validator (for this router) might have cached values for any or = all of N1, >N2, N3 >- the lookup for N2 might start with asking the source-of-truth for AS 3, = if that >host had a cached value for N2 >- if a cached value is used, the cached value might need some other valida= tion >processing (e.g. DNSSEC validation, if the data is in DNS) > >DNS authoritative servers are known to be able to serve up data at rates >= > >100K/s. >DNS hardware-based DNSSEC signers can sign-on-the-fly Even if an AS has a >bunch of routers, and each router has a bunch of peers, the DNSSEC data wo= uld >likely be served out of a single DNSSEC zone (simplifies signing considera= bly). >Hardware-based signing with a small number of keys, with redundant hardwar= e >and redundant geographical locations, is a solved problem. >Hardware modules can be configured to make keys unrecoverable, i.e. strict= ly >kept inside the hardware, hardened against any kind of inspection. > >Managed (by a third party) DNS with DNSSEC is a viable option here. The si= gning >of data does not require exposing the private key, if the private key is i= nside >hardware and is not recoverable. > >Nobody queries the signing router directly, ever. > >The signing router sends a unidirectional feed of what range of current se= quences >are, and what updates have been over-ridden or withdrawn, over a secure >channel to the "source of truth". > >The workload of the signing router is extremely small. >The workload of the validator (OOB) is moderate, but scales well when hand= ling >multiple routers (since many of the updates will share some ancestry). >The workload of the source-of-truth is also moderate, mostly because it is= looking >up fixed values in a hash table and quickly giving an answer. >The scope of the source-of-truth is its own ASN, plus perhaps any other AS= Ns on >whose behalf it is operating the service (third party customer). >A validator would potentially need to have all the public keys of all the = ASNs in >existence, but that is not excessively large, and will generally not chang= e much at >all. >The keys can either be pre-loaded, or cached as needed, depending on the >performance characteristics of the local AS. > >The design is deliberately lightweight, and scalable. The traffic levels (= packet/sec) >might be low or high, the capacity offered performance-wise (to handle wor= st >case scenarios) should be very high, and would be low cost. > >Hardware-based DNSSEC signing would be an optimization, not a mandatory >requirement. Software-based signing at 10,000/sec is still able to produce >adequate results at very low costs. > >Brian > >>On Mon, May 7, 2012 at 5:49 PM, Sriram, Kotikalapudi >> wrote: >> >>>The validator would need to talk to the source-of-truth, using a query/a= nswer >>>type protocol, preferably with cacheable answers, preferably over some s= ecured >>>channel (e.g. using DH shared secret). >> >>Brian, >> >>Are these query/answer per update? >>Does the validating router make a query to each signing router (or AS) fo= r each >>update? >> >>Sriram From brian.peter.dickson@gmail.com Mon May 7 18:50:27 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DB9D21F8631 for ; Mon, 7 May 2012 18:50:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.245 X-Spam-Level: X-Spam-Status: No, score=-3.245 tagged_above=-999 required=5 tests=[AWL=0.353, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hg+UAaXirNZR for ; Mon, 7 May 2012 18:50:25 -0700 (PDT) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by ietfa.amsl.com (Postfix) with ESMTP id E8C4121F8616 for ; Mon, 7 May 2012 18:50:24 -0700 (PDT) Received: by wibhj6 with SMTP id hj6so127666wib.13 for ; Mon, 07 May 2012 18:50:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=EIdiOQ7KmAhyplf99u6EYTLT2nHs/zbp9T4xZaRBdf0=; b=B5E6YpRtzc8Y1nfa/rd2DJaB9UDrkOlkGVhjLWkpfmKIOoeMJSrTx0zLdqBUFEgPOQ UhHnscua0KqSUp8tL9Vuhripm9ItzE1LE5SeDKvuHub8nz0Qa7nkVIAScgCtL1p6nNUo k6JsMshKw6PsVEbn3hdhPrHqWp0hdCQYdsI6u9wACB3Vv6gGWBcjAvqH1gSAyjhF00Iw 3ILRH8LJQc/SmxfWDrHsx80Rmm7eW1vI/SwpXsbDTEtfPhc/qyBQ4Z99jhs74D+73X4K YhCqMCyunjnc6Pm1gLFHh544gPEk9j0YkQY9ok8sDQqQJwLtYXANhVPwHfPDRlc7aibi v2+g== MIME-Version: 1.0 Received: by 10.180.105.69 with SMTP id gk5mr45930344wib.3.1336441824055; Mon, 07 May 2012 18:50:24 -0700 (PDT) Received: by 10.223.93.138 with HTTP; Mon, 7 May 2012 18:50:23 -0700 (PDT) In-Reply-To: References: Date: Mon, 7 May 2012 21:50:23 -0400 Message-ID: From: Brian Dickson To: "Sriram, Kotikalapudi" Content-Type: multipart/alternative; boundary=f46d04426f142f90d204bf7c9c57 Cc: "sidr wg list \(sidr@ietf.org\)" Subject: Re: [sidr] Keys and algorithms for Updates - feasibility analysis? (was Re: RPKI and private keys) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 May 2012 01:50:27 -0000 --f46d04426f142f90d204bf7c9c57 Content-Type: text/plain; charset=ISO-8859-1 On Mon, May 7, 2012 at 8:14 PM, Sriram, Kotikalapudi < kotikalapudi.sriram@nist.gov> wrote: > Brian, > > Thanks. I bring this back on the SIDR list as others may be having the > same questions. > > I have no grasp of the details of your method based on crypto fundamentals > yet, > but at a different level I have some performance questions based on the > descriptions > that you have provided. > > Per your explanation below, the validating router or the OOB validator is > doing query/response per update. > That would entail one or more round-trip messaging delays (between the > validating entity > and each of the signing ASes or "sources-of-truth") in the validation > processing time of each update. > These delays would need to be factored into processing speed estimate for > update validation, > which may be slowed down considerably as a result. Would you agree? > > For the signing speed, earlier you had estimated 400,000/(0.09 sec) = 4.4 > million (approx.) signings per second. > Now you are saying, "Software-based signing at 10,000/sec is still able to > produce > adequate results at very low costs." > What caused the drastic lowering of the signing speed estimate from 4.4 > million to 10,000 per sec > (or perhaps I misunderstood something)? > > The router-side of things is just adding a nonce to each update. It is a substitute for signing, but technically isn't signing. That is the thing where 4+M/s is level-of-effort. The source-of-truth, for example, if it is doing DNSSEC signing, would be capable of 10K/s signatures, give or take. Hardware of course massively improves this. The point of the DNSSEC software signing is showing a low barrier to entry. Where there is reason to go bigger, outsourcing or taking advantage of already-owned DNSSEC hardware means marginal costs are lower too. For a stub edge, what the stub would need to sign would be limited to its own prefixes and its own customers' prefixes. Also, the source-of-truth could, in theory, generate signatures before deciding that they are ready to be "released". It would be bending some of the rules for DNSSEC, in the interests of using time vs space to its advantage, rather than falling behind during a burst of new updates to sign. E.g. 10,000/s x 400 seconds (working ahead of a burst) = 4M "in the pipe" which would allow a 1s burst at peak router rate with no impact to system performance. As for round-trips - they only are an issue if the latency is severe, or if there is head-of-line blocking. If the lookup OOB validator is able to continue reading from the router's queue and doing queries in parallel, the only time blocking would happen is if there were persistent failures at the front of the queue. This would be a reason for having more states to reflect lookup-failures, rather than "validate" or "fail". Caching would also be beneficial, since adjacent ASes (topologically speaking) would likely share common nonces that need to be looked up in short succession. Thanks for the questions, and hopefully this helps clarify the distinctions between nonces and signatures. (Also, rather than traditional anonymous parties, where there is no trust, having direct queries to source-of-truth over validated channels means it would be feasible to skip the DNSSEC validation when getting a direct answer. This leads to 100K/s or better levels, vs 10K/s.) Brian > Sriram > > > > >From: Brian Dickson [mailto:brian.peter.dickson@gmail.com] > >Sent: Monday, May 07, 2012 6:21 PM > >To: Sriram, Kotikalapudi > >Subject: Re: [sidr] Keys and algorithms for Updates - feasibility > analysis? (was Re: > >RPKI and private keys) > > > >Yes, per update. > > > >The router would spew its incoming updates (or pieces of them) to the OOB > >validator, who would be responsible for looking them up, doing > retries/time- > >out/caching, etc. > > > >The router would not be doing the queries, per se. But it would pass on > the bulk > >update data, and the validator would need to possible/probably do multiple > >queries per update. > > > >E.g. If there was a single update with AS path of "3 2 1" (originated by > AS 1), and > >nonces "N3 N2 N1", the router would send a request to the validator, > saying > >"isvalid:3,2,1:N3,N2,N1", and the validator would then look up N3 at the > source- > >of-truth for AS 3, as well as looking up N2 at AS 2's source-of-truth, > and N1 at AS > >1's source of truth. > > > >Depending on how the system was built and operated, any number of things > >could optimize look-ups: > >- the OOB validator (for this router) might have cached values for any or > all of N1, > >N2, N3 > >- the lookup for N2 might start with asking the source-of-truth for AS 3, > if that > >host had a cached value for N2 > >- if a cached value is used, the cached value might need some other > validation > >processing (e.g. DNSSEC validation, if the data is in DNS) > > > >DNS authoritative servers are known to be able to serve up data at rates > >> > >100K/s. > >DNS hardware-based DNSSEC signers can sign-on-the-fly Even if an AS has a > >bunch of routers, and each router has a bunch of peers, the DNSSEC data > would > >likely be served out of a single DNSSEC zone (simplifies signing > considerably). > >Hardware-based signing with a small number of keys, with redundant > hardware > >and redundant geographical locations, is a solved problem. > >Hardware modules can be configured to make keys unrecoverable, i.e. > strictly > >kept inside the hardware, hardened against any kind of inspection. > > > >Managed (by a third party) DNS with DNSSEC is a viable option here. The > signing > >of data does not require exposing the private key, if the private key is > inside > >hardware and is not recoverable. > > > >Nobody queries the signing router directly, ever. > > > >The signing router sends a unidirectional feed of what range of current > sequences > >are, and what updates have been over-ridden or withdrawn, over a secure > >channel to the "source of truth". > > > >The workload of the signing router is extremely small. > >The workload of the validator (OOB) is moderate, but scales well when > handling > >multiple routers (since many of the updates will share some ancestry). > >The workload of the source-of-truth is also moderate, mostly because it > is looking > >up fixed values in a hash table and quickly giving an answer. > >The scope of the source-of-truth is its own ASN, plus perhaps any other > ASNs on > >whose behalf it is operating the service (third party customer). > >A validator would potentially need to have all the public keys of all the > ASNs in > >existence, but that is not excessively large, and will generally not > change much at > >all. > >The keys can either be pre-loaded, or cached as needed, depending on the > >performance characteristics of the local AS. > > > >The design is deliberately lightweight, and scalable. The traffic levels > (packet/sec) > >might be low or high, the capacity offered performance-wise (to handle > worst > >case scenarios) should be very high, and would be low cost. > > > >Hardware-based DNSSEC signing would be an optimization, not a mandatory > >requirement. Software-based signing at 10,000/sec is still able to produce > >adequate results at very low costs. > > > >Brian > > > >>On Mon, May 7, 2012 at 5:49 PM, Sriram, Kotikalapudi > >> wrote: > >> > >>>The validator would need to talk to the source-of-truth, using a > query/answer > >>>type protocol, preferably with cacheable answers, preferably over some > secured > >>>channel (e.g. using DH shared secret). > >> > >>Brian, > >> > >>Are these query/answer per update? > >>Does the validating router make a query to each signing router (or AS) > for each > >>update? > >> > >>Sriram > > --f46d04426f142f90d204bf7c9c57 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Mon, May 7, 2012 at 8:14 PM, Sriram, = Kotikalapudi <kotikalapudi.sriram@nist.gov> wrote= :
Brian,

Thanks. I bring this back on the SIDR list as others may be having the same= questions.

I have no grasp of the details of your method based on crypto fundamentals = yet,
but at a different level I have some performance questions based on the des= criptions
that you have provided.

Per your explanation below, the validating router or the OOB validator is d= oing query/response per update.
That would entail one or more round-trip messaging delays (between the vali= dating entity
and each of the signing ASes or "sources-of-truth") in the valida= tion processing time of each update.
These delays would need to be factored into processing speed estimate for u= pdate validation,
which may be slowed down considerably as a result. Would you agree?

For the signing speed, earlier you had estimated 400,000/(0.09 sec) =3D 4.4= million (approx.) signings per second.
Now you are saying, "Software-based signing at 10,000/sec is still abl= e to produce
adequate results at very low costs."
What caused the drastic lowering of the signing speed estimate from 4= .4 million to 10,000 per sec
(or perhaps I misunderstood something)?


The router-side of things is just addi= ng a nonce to each update. It is a substitute for signing, but technically = isn't signing.
That is the thing where 4+M/s is level-of-effo= rt.

The source-of-truth, for example, if it is doing DNSSEC= signing, would be capable of 10K/s signatures, give or take.
Har= dware of course massively improves this.

The point= of the DNSSEC software signing is showing a low barrier to entry. Where th= ere is reason to go bigger, outsourcing or taking advantage of already-owne= d DNSSEC hardware means marginal costs are lower too.

For a stub edge, what the stub would need to sign would= be limited to its own prefixes and its own customers' prefixes.
<= div>
Also, the source-of-truth could, in theory, generate sig= natures before deciding that they are ready to be "released".
It would be bending some of the rules for DNSSEC, in the interests of = using time vs space to its advantage, rather than falling behind during a b= urst of new updates to sign.

E.g. 10,000/s x 400 s= econds (working ahead of a burst) =3D 4M "in the pipe" which woul= d allow a 1s burst at peak router rate with no impact to system performance= .

As for round-trips - they only are an issue if the late= ncy is severe, or if there is head-of-line blocking.
If the looku= p OOB validator is able to continue reading from the router's queue and= doing queries in parallel, the only time blocking would happen is if there= were persistent failures at the front of the queue.
This would be a reason for having more states to reflect lookup-failur= es, rather than "validate" or "fail".
Caching= would also be beneficial, since adjacent ASes (topologically speaking) wou= ld likely share common nonces that need to be looked up in short succession= .

Thanks for the questions, and hopefully this helps clar= ify the distinctions between nonces and signatures.

(Also, rather than traditional anonymous parties, where there is no trust= , having direct queries to source-of-truth over validated channels means it= would be feasible to skip the DNSSEC validation when getting a direct answ= er. This leads to 100K/s or better levels, vs 10K/s.)

Brian

=A0
Sriram

>
>From: Brian Dickson [mailto:brian.peter.dickson@gmail.com]
>Sent: Monday, May 07, 2012 6:21 PM
>To: Sriram, Kotikalapudi
>Subject: Re: [sidr] Keys and algorithms for Updates - feasibility analy= sis? (was Re:
>RPKI and private keys)
>
>Yes, per update.
>
>The router would spew its incoming updates (or pieces of them) to the O= OB
>validator, who would be responsible for looking them up, doing retries/= time-
>out/caching, etc.
>
>The router would not be doing the queries, per se. But it would pass on= the bulk
>update data, and the validator would need to possible/probably do multi= ple
>queries per update.
>
>E.g. If there was a single update with AS path of "3 2 1"=A0 = (originated by AS 1), and
>nonces "N3 N2 N1", the router would send a request to the val= idator, saying
>"isvalid:3,2,1:N3,N2,N1", and the validator would then look u= p N3 at the source-
>of-truth for AS 3, as well as looking up N2 at AS 2's source-of-tru= th, and N1 at AS
>1's source of truth.
>
>Depending on how the system was built and operated, any number of thing= s
>could optimize look-ups:
>- the OOB validator (for this router) might have cached values for any = or all of N1,
>N2, N3
>- the lookup for N2 might start with asking the source-of-truth for AS = 3, if that
>host had a cached value for N2
>- if a cached value is used, the cached value might need some other val= idation
>processing (e.g. DNSSEC validation, if the data is in DNS)
>
>DNS authoritative servers are known to be able to serve up data at rate= s >>
>100K/s.
>DNS hardware-based DNSSEC signers can sign-on-the-fly Even if an AS has= a
>bunch of routers, and each router has a bunch of peers, the DNSSEC data= would
>likely be served out of a single DNSSEC zone (simplifies signing consid= erably).
>Hardware-based signing with a small number of keys, with redundant hard= ware
>and redundant geographical locations, is a solved problem.
>Hardware modules can be configured to make keys unrecoverable, i.e. str= ictly
>kept inside the hardware, hardened against any kind of inspection.
>
>Managed (by a third party) DNS with DNSSEC is a viable option here. The= signing
>of data does not require exposing the private key, if the private key i= s inside
>hardware and is not recoverable.
>
>Nobody queries the signing router directly, ever.
>
>The signing router sends a unidirectional feed of what range of current= sequences
>are, and what updates have been over-ridden or withdrawn, over a secure=
>channel to the "source of truth".
>
>The workload of the signing router is extremely small.
>The workload of the validator (OOB) is moderate, but scales well when h= andling
>multiple routers (since many of the updates will share some ancestry).<= br> >The workload of the source-of-truth is also moderate, mostly because it= is looking
>up fixed values in a hash table and quickly giving an answer.
>The scope of the source-of-truth is its own ASN, plus perhaps any other= ASNs on
>whose behalf it is operating the service (third party customer).
>A validator would potentially need to have all the public keys of all t= he ASNs in
>existence, but that is not excessively large, and will generally not ch= ange much at
>all.
>The keys can either be pre-loaded, or cached as needed, depending on th= e
>performance characteristics of the local AS.
>
>The design is deliberately lightweight, and scalable. The traffic level= s (packet/sec)
>might be low or high, the capacity offered performance-wise (to handle = worst
>case scenarios) should be very high, and would be low cost.
>
>Hardware-based DNSSEC signing would be an optimization, not a mandatory=
>requirement. Software-based signing at 10,000/sec is still able to prod= uce
>adequate results at very low costs.
>
>Brian
>
>>On Mon, May 7, 2012 at 5:49 PM, Sriram, Kotikalapudi
>><kotikalapudi.sr= iram@nist.gov> wrote:
>>
>>>The validator would need to talk to the source-of-truth, using = a query/answer
>>>type protocol, preferably with cacheable answers, preferably ov= er some secured
>>>channel (e.g. using DH shared secret).
>>
>>Brian,
>>
>>Are these query/answer per update?
>>Does the validating router make a query to each signing router (or = AS) for each
>>update?
>>
>>Sriram


--f46d04426f142f90d204bf7c9c57-- From internet-drafts@ietf.org Tue May 8 13:10:52 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F8D49E800B; Tue, 8 May 2012 13:10:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.53 X-Spam-Level: X-Spam-Status: No, score=-102.53 tagged_above=-999 required=5 tests=[AWL=0.069, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rBtxTwJmDbIn; Tue, 8 May 2012 13:10:51 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3AB4F9E8009; Tue, 8 May 2012 13:10:51 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.02 Message-ID: <20120508201051.8413.91868.idtracker@ietfa.amsl.com> Date: Tue, 08 May 2012 13:10:51 -0700 Cc: sidr@ietf.org Subject: [sidr] I-D Action: draft-ietf-sidr-bgpsec-overview-02.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 May 2012 20:10:52 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Secure Inter-Domain Routing Working G= roup of the IETF. Title : An Overview of BGPSEC Author(s) : Matt Lepinski Sean Turner Filename : draft-ietf-sidr-bgpsec-overview-02.txt Pages : 10 Date : 2012-05-08 This document provides an overview of a security extension to the Border Gateway Protocol (BGP) referred to as BGPSEC. BGPSEC improves security for BGP routing. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sidr-bgpsec-overview-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-sidr-bgpsec-overview-02.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-sidr-bgpsec-overview/ From mlepinski@bbn.com Tue May 8 13:15:41 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94B0B9E8006 for ; Tue, 8 May 2012 13:15:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5X7E6r1tkp3E for ; Tue, 8 May 2012 13:15:40 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 8A4729E8007 for ; Tue, 8 May 2012 13:15:40 -0700 (PDT) Received: from mail.bbn.com ([128.33.0.48]:43640) by smtp.bbn.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1SRqoU-0009Sj-02 for sidr@ietf.org; Tue, 08 May 2012 16:15:14 -0400 Received: from [128.89.253.158] by mail.bbn.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1SRqot-0007Wg-DY for sidr@ietf.org; Tue, 08 May 2012 16:15:39 -0400 Message-ID: <4FA97EEF.3030708@bbn.com> Date: Tue, 08 May 2012 16:15:43 -0400 From: Matt Lepinski User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: sidr@ietf.org References: <20120508201051.8413.91868.idtracker@ietfa.amsl.com> In-Reply-To: <20120508201051.8413.91868.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [sidr] I-D Action: draft-ietf-sidr-bgpsec-overview-02.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 May 2012 20:15:41 -0000 No significant changes in this version of the overview document. I'd like to revisit some of the content in this document after the protocol document becomes more stable, but for now I'm happy with -bgpsec-overview as a high level introduction to BGPSEC with pointers to the other working group documents. - Matt Lepinski On 5/8/2012 4:10 PM, internet-drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Secure Inter-Domain Routing Working Group of the IETF. > > Title : An Overview of BGPSEC > Author(s) : Matt Lepinski > Sean Turner > Filename : draft-ietf-sidr-bgpsec-overview-02.txt > Pages : 10 > Date : 2012-05-08 > > This document provides an overview of a security extension to the > Border Gateway Protocol (BGP) referred to as BGPSEC. BGPSEC improves > security for BGP routing. > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-sidr-bgpsec-overview-02.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > This Internet-Draft can be retrieved at: > ftp://ftp.ietf.org/internet-drafts/draft-ietf-sidr-bgpsec-overview-02.txt > > The IETF datatracker page for this Internet-Draft is: > https://datatracker.ietf.org/doc/draft-ietf-sidr-bgpsec-overview/ > > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr > From rossjanderson@googlemail.com Thu May 10 01:35:27 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3844921F8600 for ; Thu, 10 May 2012 01:35:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XrkQtpeAmKNL for ; Thu, 10 May 2012 01:35:25 -0700 (PDT) Received: from mail-gg0-f172.google.com (mail-gg0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 04FE421F8603 for ; Thu, 10 May 2012 01:35:23 -0700 (PDT) Received: by ggmi1 with SMTP id i1so921739ggm.31 for ; Thu, 10 May 2012 01:35:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=rOQ+3BZLAXogO84j/A8pdBUD/Wbj956YaRuHYHxuT8k=; b=e8ObFGUGrjkQr7xwACmKKtpiG/Llf2lcebSdBg9uCI5Cb5IVVdmuMihSuhhoWVR6WU u+d9D/QAHfOl7lORoelTy2aBeCkIrhqSLimiO8+LDi4uUbkRd3g5AYks01whjHUofNlw K0rUFT4BBDUuTmHPqjLckKaq/Vw5rL9/iAvz4/ba+emRCM5TsxK5cJYio2NwCVXBkvVK McASul5H2yMPvzKPcpYQfymjcSA6Dths2rK53RK+bMC03BS9IXTnkeNsUBuQ8sopOptb nA5AueI2UDXjVU0PWEO0R8blmouqQo1ZgouQR0uWMgDxADRISbD57ELNusWBvCWPCDzM 5I8g== MIME-Version: 1.0 Received: by 10.50.85.196 with SMTP id j4mr3144051igz.30.1336638923305; Thu, 10 May 2012 01:35:23 -0700 (PDT) Received: by 10.50.108.73 with HTTP; Thu, 10 May 2012 01:35:23 -0700 (PDT) In-Reply-To: References: Date: Thu, 10 May 2012 09:35:23 +0100 Message-ID: From: "Ross.Anderson@cl.cam.ac.uk" To: "Sriram, Kotikalapudi" Content-Type: text/plain; charset=ISO-8859-1 Cc: "sidr wg list \(sidr@ietf.org\)" Subject: Re: [sidr] Keys and algorithms for Updates - feasibility analysis? (was Re: RPKI and private keys) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Ross.Anderson@cl.cam.ac.uk List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 May 2012 08:35:27 -0000 Sriram You can't get 10,000 signature creations and verifications a second on a standard Intel core. You can get maybe 100. Your colleagues who work on smart grid standards have experience of this. The IEC working group assumed that all LAN traffic in electricity substations could be authenticated by digital signatures. This turned out to not work, and caused a major stall in the smart grid security program. Some substation LAN traffic has a hard end-to-end latency bound of 4ms, and that simply can't be achieved on standard cores using 1024-bit RSA signatures. You need custom hardware, which brings serious export control headaches as well as significant costs. We wrote this up in http://www.cl.cam.ac.uk/~sf392/publications/S4-1010.pdf Ross On 08/05/2012, Sriram, Kotikalapudi wrote: > Brian, > > Thanks. I bring this back on the SIDR list as others may be having the same > questions. > > I have no grasp of the details of your method based on crypto fundamentals > yet, > but at a different level I have some performance questions based on the > descriptions > that you have provided. > > Per your explanation below, the validating router or the OOB validator is > doing query/response per update. > That would entail one or more round-trip messaging delays (between the > validating entity > and each of the signing ASes or "sources-of-truth") in the validation > processing time of each update. > These delays would need to be factored into processing speed estimate for > update validation, > which may be slowed down considerably as a result. Would you agree? > > For the signing speed, earlier you had estimated 400,000/(0.09 sec) = 4.4 > million (approx.) signings per second. > Now you are saying, "Software-based signing at 10,000/sec is still able to > produce > adequate results at very low costs." > What caused the drastic lowering of the signing speed estimate from 4.4 > million to 10,000 per sec > (or perhaps I misunderstood something)? > > Sriram > >> >>From: Brian Dickson [mailto:brian.peter.dickson@gmail.com] >>Sent: Monday, May 07, 2012 6:21 PM >>To: Sriram, Kotikalapudi >>Subject: Re: [sidr] Keys and algorithms for Updates - feasibility analysis? >> (was Re: >>RPKI and private keys) >> >>Yes, per update. >> >>The router would spew its incoming updates (or pieces of them) to the OOB >>validator, who would be responsible for looking them up, doing >> retries/time- >>out/caching, etc. >> >>The router would not be doing the queries, per se. But it would pass on the >> bulk >>update data, and the validator would need to possible/probably do multiple >>queries per update. >> >>E.g. If there was a single update with AS path of "3 2 1" (originated by >> AS 1), and >>nonces "N3 N2 N1", the router would send a request to the validator, >> saying >>"isvalid:3,2,1:N3,N2,N1", and the validator would then look up N3 at the >> source- >>of-truth for AS 3, as well as looking up N2 at AS 2's source-of-truth, and >> N1 at AS >>1's source of truth. >> >>Depending on how the system was built and operated, any number of things >>could optimize look-ups: >>- the OOB validator (for this router) might have cached values for any or >> all of N1, >>N2, N3 >>- the lookup for N2 might start with asking the source-of-truth for AS 3, >> if that >>host had a cached value for N2 >>- if a cached value is used, the cached value might need some other >> validation >>processing (e.g. DNSSEC validation, if the data is in DNS) >> >>DNS authoritative servers are known to be able to serve up data at rates >> >> >>100K/s. >>DNS hardware-based DNSSEC signers can sign-on-the-fly Even if an AS has a >>bunch of routers, and each router has a bunch of peers, the DNSSEC data >> would >>likely be served out of a single DNSSEC zone (simplifies signing >> considerably). >>Hardware-based signing with a small number of keys, with redundant >> hardware >>and redundant geographical locations, is a solved problem. >>Hardware modules can be configured to make keys unrecoverable, i.e. >> strictly >>kept inside the hardware, hardened against any kind of inspection. >> >>Managed (by a third party) DNS with DNSSEC is a viable option here. The >> signing >>of data does not require exposing the private key, if the private key is >> inside >>hardware and is not recoverable. >> >>Nobody queries the signing router directly, ever. >> >>The signing router sends a unidirectional feed of what range of current >> sequences >>are, and what updates have been over-ridden or withdrawn, over a secure >>channel to the "source of truth". >> >>The workload of the signing router is extremely small. >>The workload of the validator (OOB) is moderate, but scales well when >> handling >>multiple routers (since many of the updates will share some ancestry). >>The workload of the source-of-truth is also moderate, mostly because it is >> looking >>up fixed values in a hash table and quickly giving an answer. >>The scope of the source-of-truth is its own ASN, plus perhaps any other >> ASNs on >>whose behalf it is operating the service (third party customer). >>A validator would potentially need to have all the public keys of all the >> ASNs in >>existence, but that is not excessively large, and will generally not change >> much at >>all. >>The keys can either be pre-loaded, or cached as needed, depending on the >>performance characteristics of the local AS. >> >>The design is deliberately lightweight, and scalable. The traffic levels >> (packet/sec) >>might be low or high, the capacity offered performance-wise (to handle >> worst >>case scenarios) should be very high, and would be low cost. >> >>Hardware-based DNSSEC signing would be an optimization, not a mandatory >>requirement. Software-based signing at 10,000/sec is still able to produce >>adequate results at very low costs. >> >>Brian >> >>>On Mon, May 7, 2012 at 5:49 PM, Sriram, Kotikalapudi >>> wrote: >>> >>>>The validator would need to talk to the source-of-truth, using a >>>> query/answer >>>>type protocol, preferably with cacheable answers, preferably over some >>>> secured >>>>channel (e.g. using DH shared secret). >>> >>>Brian, >>> >>>Are these query/answer per update? >>>Does the validating router make a query to each signing router (or AS) for >>> each >>>update? >>> >>>Sriram > > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr > From tim@ripe.net Thu May 10 03:06:04 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6B3C21F8631 for ; Thu, 10 May 2012 03:06:04 -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=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MTJ6f2JB1foa for ; Thu, 10 May 2012 03:06:04 -0700 (PDT) Received: from postlady.ripe.net (postlady.ipv6.ripe.net [IPv6:2001:67c:2e8:11::c100:1341]) by ietfa.amsl.com (Postfix) with ESMTP id C363E21F8540 for ; Thu, 10 May 2012 03:06:03 -0700 (PDT) Received: from ayeaye.ripe.net ([193.0.23.5]) by postlady.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1SSQG2-0000uk-0J for sidr@ietf.org; Thu, 10 May 2012 12:06:03 +0200 Received: from s258-sslvpn-1.ripe.net ([193.0.20.231] helo=vpn-164.ripe.net) by ayeaye.ripe.net with esmtps (TLSv1:AES128-SHA:128) (Exim 4.72) (envelope-from ) id 1SSQG1-0001Yq-NQ; Thu, 10 May 2012 12:06:01 +0200 From: Tim Bruijnzeels Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Thu, 10 May 2012 12:03:30 +0200 To: "sidr@ietf.org wg" Message-Id: Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) X-Anti-Virus: Kaspersky Anti-Virus for Linux Mail Server 5.6.48/RELEASE, bases: 20120425 #7816066, check: 20120510 clean X-RIPE-Spam-Level: -- X-RIPE-Spam-Report: Spam Total Points: -2.9 points pts rule name description ---- ---------------------- ------------------------------------ -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -0.0 T_RP_MATCHES_RCVD Envelope sender domain matches handover relay domain -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-RIPE-Signature: 784d7acfe6559f2a0b602ec6519a0719b77beba8ececc755dd6ae6cb7f0d388d Subject: [sidr] Can you help us measure validation statistics for the current rpki infrastructure? X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 May 2012 10:06:04 -0000 Hi, As you know there are discussions about the rpki repository and = validation standards and infrastructure. There was some discussion and = people suggested that we (as a wg) should do more, distributed, = measurements. To help this effort we have now built a statistics feedback option in = our validator. If enabled it will gather statistics on the following and = send them to us after every validation run (per TA configured): =3D availability of rsync repositories =3D reachability of rsync TA repositories over IPv4 vs IPv6 =3D total time it takes to do a full validation for a trust anchor =3D frequency of finding inconsistencies for any CA where an object = mentioned on the mft can not be found, or the mft is out of sync with = some object(s) =3D some statistic about your system (OS, java version, memory, your = public ip address) to help us uniquely identify instances and see if any = of these parameters influence the performance of our tool in other ways = (i.e. this may be needed to reduce noise in measurement analysis) So, I would like to invite everyone interested on this list to download = our validator and leave it running on a server with this feedback option = enabled. New version can be downloaded here: = https://certification.ripe.net/content/public-repo/releases/net/ripe/rpki-= validator/rpki-validator-app/2.3/rpki-validator-app-2.3-bin.zip It should work fine on a linux system with openjdk 6 or 7 and rsync, and = preferably 1 GB of memory. Thanks, Tim From kotikalapudi.sriram@nist.gov Thu May 10 06:06:01 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF40A21F8667 for ; Thu, 10 May 2012 06:06:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.572 X-Spam-Level: X-Spam-Status: No, score=-6.572 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JK5jKNDa1tqO for ; Thu, 10 May 2012 06:06:00 -0700 (PDT) Received: from wsget1.nist.gov (wsget1.nist.gov [129.6.13.150]) by ietfa.amsl.com (Postfix) with ESMTP id D884821F865B for ; Thu, 10 May 2012 06:05:59 -0700 (PDT) Received: from WSXGHUB1.xchange.nist.gov (129.6.18.96) by wsget1.nist.gov (129.6.13.150) with Microsoft SMTP Server (TLS) id 14.1.355.2; Thu, 10 May 2012 09:05:52 -0400 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB1.xchange.nist.gov ([129.6.18.96]) with mapi; Thu, 10 May 2012 09:05:58 -0400 From: "Sriram, Kotikalapudi" To: "Ross.Anderson@cl.cam.ac.uk" Date: Thu, 10 May 2012 09:05:04 -0400 Thread-Topic: [sidr] Keys and algorithms for Updates - feasibility analysis? (was Re: RPKI and private keys) Thread-Index: Ac0uh7jJi2kgKr4bTGyyhoFdKRp7VgAGphxA Message-ID: References: , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Cc: "sidr wg list \(sidr@ietf.org\)" Subject: Re: [sidr] Keys and algorithms for Updates - feasibility analysis? (was Re: RPKI and private keys) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 May 2012 13:06:01 -0000 Hi Ross, The 10,000/s number is Brian Dickson's and it is not related to ECDSA (or RSA) signing/verification of BGPSEC updates. In my work on performance modeling of BGPSEC, I have used the basic signing/verification measurement data from the eBACS benchmarking effort: http://bench.cr.yp.to/results-sign.html The measurement numbers they report are in the same ballpark as yours for RSA signing. However, the BGPSEC spec draft specifies ECDSA-P256, which is much faster than RSA-2048 for signing. (Side note: ECDSA-P256 was also preferred because it results in a much lower size for BGPSEC updates and hence lower router RIB memory size. http://www.nist.gov/itl/antd/upload/BGPSEC_RIB_Estimation.pdf ) Regarding how the eBACS measurement data were used to model BGPSEC CPU performance, please see: http://ripe63.ripe.net/presentations/127-111102.ripe-crypto-cost.pdf (slides 10 and 11 summarize signing/verification speeds for various latest Intel and Cavium processors) or see, http://www.ietf.org/proceedings/83/slides/slides-83-sidr-7.pdf (slides 7 and 8). The performance modeling and measurement work is still evolving and there is still ways to go w.r.t. prototyping of BGPSEC and measurements with actual signed updates, etc. Sriram ________________________________________ From: Ross.Anderson@cl.cam.ac.uk [rossjanderson@googlemail.com] Sent: Thursday, May 10, 2012 4:35 AM To: Sriram, Kotikalapudi Cc: Brian Dickson (brian.peter.dickson@gmail.com); sidr wg list (sidr@ietf.org) Subject: Re: [sidr] Keys and algorithms for Updates - feasibility analysis? (was Re: RPKI and private keys) Sriram You can't get 10,000 signature creations and verifications a second on a standard Intel core. You can get maybe 100. Your colleagues who work on smart grid standards have experience of this. The IEC working group assumed that all LAN traffic in electricity substations could be authenticated by digital signatures. This turned out to not work, and caused a major stall in the smart grid security program. Some substation LAN traffic has a hard end-to-end latency bound of 4ms, and that simply can't be achieved on standard cores using 1024-bit RSA signatures. You need custom hardware, which brings serious export control headaches as well as significant costs. We wrote this up in http://www.cl.cam.ac.uk/~sf392/publications/S4-1010.pdf Ross From internet-drafts@ietf.org Thu May 10 10:51:58 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66C4611E8098; Thu, 10 May 2012 10:51:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.441 X-Spam-Level: X-Spam-Status: No, score=-102.441 tagged_above=-999 required=5 tests=[AWL=0.159, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id muDT1PE7DzQd; Thu, 10 May 2012 10:51:57 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B018A21F85B5; Thu, 10 May 2012 10:51:57 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.02 Message-ID: <20120510175157.22893.24636.idtracker@ietfa.amsl.com> Date: Thu, 10 May 2012 10:51:57 -0700 Cc: sidr@ietf.org Subject: [sidr] I-D Action: draft-ietf-sidr-rpsl-sig-05.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 May 2012 17:51:58 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Secure Inter-Domain Routing Working G= roup of the IETF. Title : Securing RPSL Objects with RPKI Signatures Author(s) : Robert Kisteleki Brian Haberman Filename : draft-ietf-sidr-rpsl-sig-05.txt Pages : 13 Date : 2012-05-10 This document describes a method to allow parties to electronically sign RPSL-like objects and validate such electronic signatures. This allows relying parties to detect accidental or malicious modifications on such objects. It also allows parties who run Internet Routing Registries or similar databases, but do not yet have RPSS-like authentication of the maintainers of certain objects, to verify that the additions or modifications of such database objects are done by the legitimate holder(s) of the Internet resources mentioned in those objects. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sidr-rpsl-sig-05.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-sidr-rpsl-sig-05.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-sidr-rpsl-sig/ From sra@hactrn.net Thu May 10 19:54:34 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F92C11E80B5 for ; Thu, 10 May 2012 19:54:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ju34zCDdzn8y for ; Thu, 10 May 2012 19:54:34 -0700 (PDT) Received: from cyteen.hactrn.net (cyteen.hactrn.net [66.92.66.68]) by ietfa.amsl.com (Postfix) with ESMTP id CBC6211E8094 for ; Thu, 10 May 2012 19:54:33 -0700 (PDT) Received: from thrintun.hactrn.net (thrintun.hactrn.net [IPv6:2002:425c:4242:0:219:d1ff:fe12:5d30]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "thrintun.hactrn.net", Issuer "Grunchweather Associates" (verified OK)) by cyteen.hactrn.net (Postfix) with ESMTPS id 0845728465 for ; Fri, 11 May 2012 02:54:32 +0000 (UTC) Received: from thrintun.hactrn.net (localhost [IPv6:::1]) by thrintun.hactrn.net (Postfix) with ESMTP id D05A6170C1 for ; Thu, 10 May 2012 22:54:31 -0400 (EDT) Date: Thu, 10 May 2012 22:54:31 -0400 From: Rob Austein To: sidr wg list In-Reply-To: References: <4FA48240.9060405@ops-netman.net> <7309FCBCAE981B43ABBE69B31C8D213921BE2860C3@EUSAACMS0701.eamcs.ericsson.se> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/23.4 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20120511025431.D05A6170C1@thrintun.hactrn.net> Subject: Re: [sidr] RPKI and private keys (was RE: Interim Meeting Draft Agenda: 04-30-2012 (April 30, 2012))) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 May 2012 02:54:34 -0000 At Fri, 04 May 2012 17:33:43 -1000, Randy Bush wrote: > > > Might it be possible to create the key pair on the router? > > Then you don't have to move the private key to the router, > > You move the public key off the router. Much easier. > > draft-ymbk-bgpsec-rtr-rekeying-00.txt, section 3. Router-Generated Keys Which notes that a (the?) main reason for even considering anything other than router-generated keys is that router-generated keys are somewhat problematic in hot swap scenarios. After thinking about this a bit, I'm not sure I really believe in the hot swap issue as described. Do we really care which router key is used to sign, so long as the router key in question is certified properly so that relying parties can verify the binding between key and signing AS? So I suspect one could make the router-generated model work well. One just has to plan for it (certify router keys from both the live and hot spare routers) or accept that there will be some cut-over time if one fails to plan (or if one's plans fail...). From randy@psg.com Thu May 10 21:35:46 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D934E9E8001 for ; Thu, 10 May 2012 21:35:46 -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=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mk3yIV+DXARt for ; Thu, 10 May 2012 21:35:46 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id 468E59E8007 for ; Thu, 10 May 2012 21:35:46 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1SShZx-000NU2-8T; Fri, 11 May 2012 04:35:45 +0000 Date: Thu, 10 May 2012 18:35:44 -1000 Message-ID: From: Randy Bush To: Rob Austein In-Reply-To: <20120511025431.D05A6170C1@thrintun.hactrn.net> References: <4FA48240.9060405@ops-netman.net> <7309FCBCAE981B43ABBE69B31C8D213921BE2860C3@EUSAACMS0701.eamcs.ericsson.se> <20120511025431.D05A6170C1@thrintun.hactrn.net> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: sidr wg list Subject: Re: [sidr] RPKI and private keys (was RE: Interim Meeting Draft Agenda: 04-30-2012 (April 30, 2012))) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 May 2012 04:35:47 -0000 > So I suspect one could make the router-generated model work well. One > just has to plan for it (certify router keys from both the live and > hot spare routers) or accept that there will be some cut-over time if > one fails to plan (or if one's plans fail...). at 2am, they always fail. heck, they fail at 2pm. and one often has to fly one in from depot or vendor. at up to $200k each, it's not like a spare re is sitting next to each chassis. and what spare stash facility would have an on-net chassis to plug in send up a genned key? and for which AS-router-id? would be interestd to hear from other ops if they believe they could get the folk managing spares to pre-key in a useful way. i was not comfortable, so we wrote up both. glad to be wrong. randy From Sandra.Murphy@sparta.com Fri May 11 02:57:07 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 191BB21F85EF for ; Fri, 11 May 2012 02:57:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.648 X-Spam-Level: X-Spam-Status: No, score=-102.648 tagged_above=-999 required=5 tests=[AWL=-0.049, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7jUcNkswKuU9 for ; Fri, 11 May 2012 02:57:06 -0700 (PDT) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by ietfa.amsl.com (Postfix) with ESMTP id 28D2A21F85EE for ; Fri, 11 May 2012 02:57:06 -0700 (PDT) Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.14.4/8.14.4) with ESMTP id q4B9v4GF002437 for ; Fri, 11 May 2012 04:57:04 -0500 Received: from Hermes.columbia.ads.sparta.com ([157.185.80.107]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id q4B9v4LA005416 for ; Fri, 11 May 2012 04:57:04 -0500 Received: from HERMES.columbia.ads.sparta.com ([2002:9db9:506b::9db9:506b]) by Hermes.columbia.ads.sparta.com ([::1]) with mapi id 14.01.0355.002; Fri, 11 May 2012 05:57:03 -0400 From: "Murphy, Sandra" To: "sidr@ietf.org" Thread-Topic: minutes of 30 Apr 2012 interim meeting Thread-Index: Ac0vWvM0YV1oyh/kRPqOkBhYZhRNdQ== Date: Fri, 11 May 2012 09:57:02 +0000 Message-ID: <24B20D14B2CD29478C8D5D6E9CBB29F60F708799@Hermes.columbia.ads.sparta.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [157.185.63.118] Content-Type: multipart/mixed; boundary="_002_24B20D14B2CD29478C8D5D6E9CBB29F60F708799Hermescolumbiaa_" MIME-Version: 1.0 Subject: [sidr] minutes of 30 Apr 2012 interim meeting X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 May 2012 09:57:07 -0000 --_002_24B20D14B2CD29478C8D5D6E9CBB29F60F708799Hermescolumbiaa_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The minutes of the 30 Apr 2012 interim meeting have been uploaded to the pr= oceedings site.=0A= =0A= The minutes can be found at the proceedings page for the meeting:=0A= =0A= http://www.ietf.org/proceedings/interim/2012/04/30/sidr/proceedings.html=0A= =0A= Pointers to the jabber log and the webex recording are in the minutes.=0A= =0A= The proceedings page does not yet show the uploaded files, so I am appendin= g the minutes pdf here.=0A= =0A= Please send comments, corrections or additions to the list.=0A= =0A= One disappointing note. There were many complaints on the jabber about the= distraction of the typing sounds in the audio. No one mentioned a constan= t echo in the audio. This makes the recording very difficult to listen to.= I trust (from the lack of complaint) that this was not heard at the time = by those on the conference call! I do not know why it is in the webex reco= rding.=0A= =0A= --Sandy= --_002_24B20D14B2CD29478C8D5D6E9CBB29F60F708799Hermescolumbiaa_ Content-Type: application/pdf; name="sidr.interim.30Apr2012.notes.pdf" Content-Description: sidr.interim.30Apr2012.notes.pdf Content-Disposition: attachment; filename="sidr.interim.30Apr2012.notes.pdf"; size=56366; creation-date="Fri, 11 May 2012 09:54:13 GMT"; modification-date="Fri, 11 May 2012 09:54:13 GMT" Content-ID: Content-Transfer-Encoding: base64 JVBERi0xLjQKJcfsj6IKNSAwIG9iago8PC9MZW5ndGggNiAwIFIvRmlsdGVyIC9GbGF0ZURlY29k ZT4+CnN0cmVhbQp4nO1cXW/cxhV931+xT+2y8NIckjMcFiiKOA6CpCnauEL74PRhtZJsR7bkqHIc /40Cze/t8HMOZ85dUiu5jYEkSDDgDufj3nPP/ZihflhnqcrXWfPv0Ni/WWXrL91/L1Y/rGxaNP+0 P2B7/2b95GT1+Fm1dm+dXKyytK5tVre/qXWdrausTt0vb1abdXLy/UoVqV2ffLM6+d3zzT+SbZVa ZXO7OU+KVOnK1pvTZOvG0FU2efpTslXucaWNG8Z1KCubZ3Zzk+RpYeqsgK77sXXdDWVKVUHPM3j6 KtnmqS50YTZX8PhFUqeZyat883vfYZ3kOvvnyderL05W3666/T37sm/c3EtGxqrUNDJ6vnkJ27/t J68rbL6FHv9yYkmr0uhxoa7D47jplg9b9bK69Q8vRgGlIOD3SZaaPNd5FauoFRVVEY7A1fEm2RZp WRcLVlilpS0q2y3Q7VrjO69908vihm7lLUzfS9laU7jng7L/6EYwqbVZufms3bcqXPOk6auMcdrc /MGNXOdVbSajoTx+k5hU50aVm78lW51mVeYG/qtv+hG+aOWlrNabz5NtmeY2MyW8f9NYh9HKTftV otyOrKk3T5MGgXlVug2WDj4nZw4zfkwDK6mgraBdCs/z6buDLnFBjVidJv7khXPuRfZhlKNfTwZj 7kadogVqaJ8J7Ry0VUO7gvY+2bp1uHYPZLfMMtGZN9hKZ2ttnNCcYei1Xt+cry7uZbOmapissVmk LAXtYkJlZVlOF6PLeq3qcljLfblWOWrNrV9Xx7fbvEiLvNTrbce8Z4SHv3ZKdKZjnLZ3lIc5J3d4 sGXeULKDS1lXxeabRNWpdVBvzH3AkMCnnW2WRT3YY6tt4CRoor3BII9pE1iLN5EXjiPGqW9pLTVT CnbaL8dou/neNyP5RgQSytcBGYZ67ZtUvp4E4SX/8JV/eDbZQDxT7ofPOtIpjdu8GkiHUYd1Q2yH sTLCOZMOBXTAzr2Y67JQDBjN4kb3MfC/1Q5PzSq3wzIDvLv//7YF+5+bN6rMqRZEHSu+9sGBa/Lg ACORMy8uPxh4px0SpTORzCqcFrURDDs+f8emwM4A2mthvNsQ7LUDrXfRKG7cM9iI77wbBwBUrkF5 JNJqulx4xzZyNfzsJ3gH78MUgAN4zYvEwx0p5udYIu0iX1Dbu+0hr9IyHyHPJz6IjXaK0bz8+COA rznAIwW3A731CNjFNMGX58UJD5FNdyH2gwGuBUwMpG8Nvoi9r7n+Iv20e3vvg4pr8Ovj7i7hYb+6 0gUlV/C4k37jpMZYfTuocKSD52ji1+DYet05OFM2wMD8vA02jMox1kQz+24zPo4sLiAGGIuHyijz C8h3yBL8BPjS3nedwGpw2fvRjndsgdB8BFvE7R6XJaD2PSaYHVMHJsnoEQwrAGyyyJhTf+qNv3av msH4cSjB+qn9ekoYoUwtTvQFg5EtRUdF8DnhnsXYsDHbAzaCcGQqdm9+nRDB/KJ9tCZ1Be2LMbDE YKiLsar8jjs5lP9FLHVFMSvB/sLHfSyUQD2eMub2hncZ4zeajQanXpipV9p3SS9A0wdFY/DTJ5p5 OeUzH8lDzBO70WYVffiU17lQXvEt/B0YAkfbUVVKwVCfUbucSX4xb5Iit70PoSc2tYsRYfXv6OoD kLQ6sxCxhZzVp00kaP+RBz9XLGrHUfud1Vrwk5NgLcYUTAUFhGGoogoR0ZcWKjOxQPB7HhtorqgW v05wFRAxnlGjmuxucEXgN68EE6X+dNYZ3c2fgWT7qXUDOoQMc1iXdKO+9TYOYRZBArzEjsjvki5L coM7z5M89A0MykOsc4qlC6eqwSl2TNMW5XAOAft+DuqLe5zURV76ZK6bLkjmGuD2UGmAici95ig+ l63qHhjGETAH7gm4iwqbjTQLfpLotCqMqagSgXj3OP5gGb2d2hzhso/c48QVjUkGVy5YEg38cHdP mVEhWcJ7UJjoidNBwq3F6VCrXM2vhnB+MQ2v5kIphHiwFjWAS9k0K8oSsPWfBluPn9m+vOY8Zeby 9Q7rHfB87a15Kfcl2L94+XhnAvjxhk2OHBrI4J7/nmzrtKiNESJyAZeRLIK+LNDppubi+HkqDpM6 dJVWEEeeZnkxSON+aFEkOwnDXmKP9VgCesitQMxB7eWGJXpSBec65kX56InTEz1E4dUC8jMzIVor GGObX6ZQ4TGP44Ti1bykobMw92Ez2uoyVVlRPAytPOnidWWRQdCQWBiyD+zhV8v+1bI/GcvmtWh2 un9JRO5SvEPRtFQIbmeWjlaYBsXyb0QHH8n4pKLFv+fkyysc8wcRC84W3vPlQRrqmsq1q0wLKTU/ HgN1INsD5HGMqR6hPnSwkoUjxIWNqTHN4mASiTkdaq2rwzKenhPgAoQdR9RY5akqKvsppEoFmAlN lbpoWtVKT267sKPnOOitq7mgd6qiacYT51usDE2P4ri4BG8gpXasnnkzJtkPktuFcH/KknHi03uL 8hW2wYIXrsXKAcn/KUQKcDlVFUuy44OW+b239l/q+RybG06giGE0GlzdXxHHO6dnXg9icTZeMbkP EmjiAviBmAw83MVKmYvbQwYGgsXwA2ieF2WPYG6sFQe1uqGO7699CedYXNCCX5S82uCfZr2aVOGj BCPcNOmriEWVuh3AufqwiPh8r6grJS7juGhx3hMHxecBtyB6Itm2rovn0QRZzZE1Xj6Ek2xE1nh8 1gsKjs/4+QrB2rRCHp9TH4qFpdTmTqHme1bGWgBU4TYBdmH3RjAXl/S6wDzpNNS+Q5aJkOOlT4NH hKwQ7o7zctoR6Apjoq5o79ZpNDvJnic8nsLy9WCeNwb9PIU9pes9Ax0ORwBGOSHXD+KjPvc+CndL K7ZzwS+co3h3xl9aaggHqlySIRxHgOBj6NUKr2cxqxm6TstvROmzyJW2NprXbobE+T2SuC5YSdeq wP+87A2mDYwG2PC37p0lCjdKuMCOd7hhKmr7GxQmK8aPIXp35W9tdPsHt3O3k3rfW3BMHK2CTcS3 Dz9ORfAYeija68hDVP5VkudpmVXFNGx1KZNWBolCckT3dsKhC6OXBH6U7GhghT6YL9wqoCkeLg+v fUjyOlWZ7GePX1nsk4XboUKSS1Ijvx3U9iO/HU4sr0aKUHqkiHF4IW+OZi0zLamMVarCJNZXb3Nj UmXtp5PDEZLAp7AGaB51aShk1ts5kt0LxBqX8IQwlg/LY7N5qEtXYLAPvVl5ONs8WAab7kK6RNLH lYUjXz3GlWDQ3sHcMdPGbbLCDQ4xR1JdX5tZq+/Apf4iddleFfCpWLdZ8IkfsZbud/GWTsJjIhwB bhzKdbHo+tpH9a/wnRHuW/roQOCVBdJjhbo5OcKw84QmodpLmlNFdJ+1iZUhkxCc1zKk349sFkTk /Ea31GO+GksuvkMwMVw40657PUCoq8AUlT4210Soj/PzcHWOfw5ZWBtQh3ttvk7cj8yI4Xa3Rxpu 88/hPMJP6Yq5v2R2IR0OBizZ7tT0H28FRR8/LHfNNMfkH5twnOIXYYCQ/kZdppfUciTWf+3dOz+T /J95qoPfFvAyy3osp5p6jEUB2NKm2W0B4WsdnHj2s6GXwoq5BcKL3q4F0QufB01LpY0QwIj4tyic lwLXKRfjwj8hwEqs3A6vEnJoOF+LXkDMIueL3wvega2lGCEYbOLw4sTulKOLb3/40LYpUf9C8nx9 XFQQRiy87sEvwMjZ36FS1JgfL3VVd1U09ZucGVDpwGu8anU7R8TTQAqu+LYbyqfhIHcvd7qY0VFr 3VyrGJAjfUR6THoRkitT8pIElxIxI3geKQS+lbbhEvaUfCO31eRMgEBPzp0YgZzn8/zZYvyCT0Qk Wr/HVYFA6H1xv7JFFGiFBechbgFfxq1CcL8z+w27k0Xsid+Zjb4eEGyT8J74C2KA0w9O4mPUkA44 dxww0GHuOfuUPhQ/9gwTLUk4HfZllBtiU+G3Mc/J5ySL7mPF7iMs1X3mr/bBDU/8exhroQ3dpWw9 ZgI5Oj6i5PJw2S1mGUgbiAzyZQpXgPCVL3DD/BnJgjQltoyymJpha2W6Ssv2z37BHQPxvGxBiiKu hkcUw9MD+crgrcN8pTWU11ixi/KVtstutCXB2MCyemmAZR1MYPT0T84wXApX/+iH6PMJyuI7IEIF OPL+EGm3f5/o29V/AWc1MDdlbmRzdHJlYW0KZW5kb2JqCjYgMCBvYmoKMzE0MQplbmRvYmoKMTEg MCBvYmoKPDwvTGVuZ3RoIDEyIDAgUi9GaWx0ZXIgL0ZsYXRlRGVjb2RlPj4Kc3RyZWFtCnic1Vxb j9y2FX7fXzF9myk6qiTqQvWlcJo0TlAgly7QByco9upsvN7am3Xc/o0Aze8tdSF5SH5HpLRax7Vh QJ7hUOThuXznxre7PCvKXd7/1Q8Xr0/y3efq38uTtycyE/2f4Qv6fPF698npyR+/bXfqV6fXJ3nW dTLvhu+KXVFVuzbvMvXV65P9r4fTH9VQOQ1tsrwoKqkGnl6e7Hfjl3qeoszyUozfvdh/ezhWWSkL 2ezPDiIr6lZ2+7vDUb2tbqqi3V8ejoX6T1s3+/8cii7LZdHt/3Q4llktatGo2dXYqpVlLvcP9uMf yBRXZuL7w7HNmlqtjnxIZzhLH3p/KDPRtHL/L/Kqd+R5Wk1TSzXDsclkU5S1/dlPamNZWzW1nrWr RLG/sT+iVNgNVKg6SanAvdi8gk5MVkN/94Y8089vneH6BF6iw2DeQk/AkpUMoL97f8izpixEXmkK 1LKmi7g9fH/65UlZFVnTlJp56Ax3zEaYF95B/rBPly7xY2SkQ87h1N4IS1FFxaZsS30SUjaC8MYw QZMLsb8wT7tDWec9OY6aHsdCZHKkiSX1SNOyLtslbH09ME+XC2d/9+ZTNbbMs7pQa2M5UW/O+ZV5 wzO7rr8fjnWWt7na/lZE1mJCBwREHj6lRDbieQEPzH5qKfnG7tN+eI5FyK4wI7PumGdCFbr914ej UHsTDFNRfaQXNmkF0bWFq44GYaqVnpadFqaIYgoldBRL9LhYGhJOSi2pUTsap6irCsvDtCUiD8zR AdUEzq63JFhMzl2O99WNb5nM2Z2prShek4qMgQYdRi7UYz8jLiRHQc7qEu76AXEpfQNrlqFcJm10 GGnZTK1RgYK6run53zEvcJZT9qCkaskb3h+OXab4XQ4r0FJtv88mDdFokZO5lD2nD/xTyCwXCtkY /nkEsvnrocrU2jztiFUiYTc6GPEuGdo/qudWAGs8TItfrMld1YTcN3baO45P9CHFreSMLgqhkZ4s 0DuyEp06gJUoiK6HjqHb0xSsOoZJsc54s2QKx9jjOX6awE2jflNo/rGEwTYJijB5NGdw7rwJ6fbv 9qHujwolfL8LQweoUQhBUIx9wXcHC1MtnhlJQPQ3QTEY03uKIgpOfAZZivs9bDarGV00H2K+BOhM sAkd/Y5hpZVKntLoZ8Z1sk7FIIQt57HRea+odWUxb/AzRGP7GYEDNxQpjqCmUt+0Woj0uuSw8IHH RNlkXU51/KDGx//97eT09y+0PMjKcHybl0adDs/aznftrAZzGYbobqJvLyG96QwV2cUkNqMF6TfU L/jFxLSKpBN4LDrrSXWGLYalX/mIZ/j0zDvp/gWum61P/YuDUnhV3grvSMand3A3mDKM0aFDvrbb uYeeyYNjOjWLWZUJnFofnH1qVcwV1PeuM2xBR9llRT5gHsU9dVEWjErQa1RA43urFMfjCyHHf13I UWVqjYpfMeRQPyqbSrM7OXxClzNgSV4x9KbkuoZY5QFjFQ4cY44GSrKf0LKJXSllKMRwIRqxwr4l nvuLjVRxcMISDEMkvWjRPgXgJH41fSmlytEsELtAIIBGNOcTLZYwLTbJWG2eAeUSUziTYu8JcA/O ypN5jZKR/GizrPDFUVtGtKJlsb0fMZK6C6WlH/IGihmM/tkF4R+dQcUw2RpZNb+FgzS5ck1TQOME fI/hjCMRTY+LLmL+uGIZAggNFsMYbllMGEStECubSSPAjMAiiq2xK3UekLx1ggV2/mvETwzIXaO/ HQhHeX70iWo1qkMBX+6cGSmDlF8Q5ZXtNgHka49FhnjvPXKFxp0TV+iauvCaga1AmNALZ2j9M/Vm Alqm//gByg1nAhltC238JpITqDgBhSPRqZE03vdvFFszVGYA4vTzzt3eTABCe9k4enBhVc68wfvz JC+lMqsCyctn/XPRNEJBT0JMK6g0NB1q/rJRBruWm2j+Tw6Kt0VbSjcqFVp2SqpfzFCHg0avRFBA 8Xx8zNUZWMDz3FqTZ/b7dGCbGMyG3MOwit0no7Pi2gTOBkXl3j/QtswK0UrfD/4Y/d865v9+NSYn usLgG8/TvTcbCsFu16YoNghHCf99cVA8LqQsOa9YM8N6pzh8FR1w4eWYFQWofgDZI+SiCiaPQJnu U5sKWuYvawWXtpbptVov2yCl49xrsk4T+KmumykqVGeVlH5UyLcxWN4mjmvywuhC0WZVLbbx2fFp eu70fOgsyI/BqPEwFwHVWNZilqqqGaBMScYFBsLw8pCEiEkcG2CeGGJGpFaksLZMqbHgFmFiDjAQ BK7zBG1h8gQQSW8Usk+iKZOZZOPZsRxw6A22kpYBBeU8hc0rSGmFtJRZ07abAJZ/9C+SRdu082Ut fmQRJ5cjENefhJRIkUdsPDghZAAG9mIxyrEvZA58NqTks0Es2g+LJy5mRKwPriIRe/r4FYmSTxi7 rWsX1lg6h15/K5jINsMaPqjx47OwLmU+cBpXQUy8alYD0/WT4yRHt0j12QE3CybbVjsGu2Xtxqio 1Xe1CV6EJqQqqk1MSFqQEdBkQXnRMwv6poCtGKa18YpxsyReEQs6WnEmmBeGJjCW2TjS94qhLp36 nCGpjhIWulDPh6eGuuYhIcBLai5MsukP5K2MJ+iWkID4ARn7BvO3+ZERQO69V4hnLQmeNoT8DdTC jDeFLWZCzXCYKMA2HhYk0aGwtuAto/IJH1jfHfpz5rB4JyqGyqJobkIewuKR/hHXSMaRLgOhk5MY CbrcEOVh0sWtUlmmcnhOrXc1Y0sSVOuHgU5W546bgjo3wFIueAiwVEKA94NiKSaSTCBw3HUn+3kZ EW4nrjQHvn2+txSnh8QBuVvM+VxuhQtELoFA/5dwfh7u6NSQsOXL0y6H+E+Ae3u3MB5MTYFXzP5h DizJPDsZ2KFE7taCQzcdJNzK5sXwJ6yGXQt/PgZF8KUNeiE/hztMRs6jMOBx5bpzwsW03RCWshM7 R6e9sMcA1yjjLqxHT4pV+trBgfd6V/H61kELCKkQVaM5iGyHKoRVicSa1b5pkO8ReU2Ul7T9DlZV TIcz5JCJrphoQnQFKctHhR4xZMtnlEHjDITcC1PHlF3n856Jylwz5VosnNK385V1kSOlOWsd/ahe SXYmWumXAOryzl8RXqbvwLTCCfZIUUUKdGAUDVcAPe+05E2F1tTbWlqPMQuxV8kSdnMeLzTYqU1B MmmIxGc2rmBBaykYvIe9BIw3FUljXwKmpYHIRWo2ltmIuoEwPPlgDFNV1FqAwpJ+xWmYhO9RehVm ZpY5x2H+hBJzVHBON1TfTVfVHwjZbdoIbgMmiwLq0fPGA4BCoEp2nu6rArOcp0lYhyv8W58XXZTQ IzXxmCoMGh1Ep1HDKpDgxGunlgeW1MAimWinbprpGtqNWq0M1WjHjrwjz6jGb9rotk5dRk7+N3HS iGdGt0CZhvIb6jIRNuCd0r61eQwGirTRwBz7LpKQx1c8PtZQ4SBSHOpxRHMDTYYzp27zSiher70S nME72zhf594+wKbrLqg2DXW00yrjft13n186aNE7k8A307bLLfAdCTKPLG2AEmNMrgq+T0gVil+b rlzYCkkso305LuJ2ucZVhUkXlDiFS4ZhbqMAK+pIrPVRVoPi+R7gTVGxrvMtKuOe2f7aSOFak2fF RjUx8dwbaexZDenWtfOyxx/K+ULGYnQcViwA+aDUKmObFq5sqVvqqdtoGdjSyInmbVu0JoXBdFFL CZT3L16T+ljrZRfFRSrxfp1Iotmuw6dhINPKGZ3UvXOiLzJo244gQre/vacC0fkJ7ZSrAg6LAtq4 G++f5Hdf2ztpSCXIaT9i6il4Hvge+lTQDRDxi2MWhmHhCFiNPx9xXRRuW50j43J86KIEtwlCO0gK GgNhSrBl9JkDsuvMoFcQM98V6YT554LZ017hFVeEyRf0Oz9tTUrcP1rV/hKvb3HatdfZTVigEu31 Q5eOhImY5f6NMZDQVfLb3dLSTwuNKnRCvPnChFVKNOXcXGinSK95xwrDbKf+ArAyTw2uqOvReNW9 oq7fIZFfHLCJNwdBuV+YWFoVKfAXEkN7sBKOMwUrslA0tBO0cX187VvNNAK2b216/wXRvZG8NY+L cFU105Vlde5mRVY+x0b6nP0VkRdpk2Ei+luauc8tqRNWFTQaTHdNGnODS+BhS3PCyXKZt0hLRM+g bEtE/BKvSGHDEs29VR/H+r6x7kkuxWMuUUnXucORYqWK7S+u++MEjBb7ho56JB3HdGMyYYJom8MH rNsjBmVTfbzNca+KbJxjqcGSAmPBKbEA3q9JKBZGuNm+1PDENcDUWLEYQsWvc1vUgovgMLp2zw/+ omtoSRps7Mxts6ooXQNOu0z6iAMHU1cSsK/2wLfHjmuB5dTkHsKojQvveaor5cQKsYkO3TRTHm1h JPIJr3QNrjb3kVOX4G+QCFos1eVoXqhY7TnwljP5KsZ47CkqgJE8VKR5e1Fc1qnyAGVcZGOkVAAu 9lXCsS1xXfzoLZvOJzoUGN4zk4EjpVtumh3cOvq78DaTWglkszWm+SGgJHv5DSOPnFeKCwqt+8GY VK5rf3F4KLkzgbDzgu5CKDjYs8Ql0nE0jMwouPOc3NU48spnpyffqL//A8BtnKJlbmRzdHJlYW0K ZW5kb2JqCjEyIDAgb2JqCjM0NzIKZW5kb2JqCjE1IDAgb2JqCjw8L0xlbmd0aCAxNiAwIFIvRmls dGVyIC9GbGF0ZURlY29kZT4+CnN0cmVhbQp4nN1dW3PcthV+31+xj7ttluEdoF8yzaVNPanbpMr0 wemDtJas2LKlqLbV9md0pvm9BS8ADojvECCXatwmkxmGC+JycC7fuQD6aZsmWb5N23/1w/HNJt3+ Tv33cvPTRiZF+0/3A30+vtl+frb59DuxVV+dXW3SpGlk2nS/ZdtMpluRNon66c1m9+/92SvVVA5N yyRPZVqqhmcvNrtt/6PuJysSmdfDj893v99neVJIme/e7g9qjKouM6G+OWRpUjai3h33RZJVQja7 c/P0N/VzIsq62l2ad9v281JINfTutvu8EVW9u9qr7usmLXSDpiyynSBjpeQ5I8+fkPb0W38ahdgd umGE3N3ZoW3Dd/tDnlRFXcndtbtK0+vD/tAkRSNksfvRtqY0sYvmZkZb35JnMjxtfkeaWDrap/tu TbKs1Vd/PXu6OVRlkqWKPQ7tHnZ7+7O78XWSZlkpmY3PkzQv9L5/vq8SUYhcDsO0OzQsXM2U0I4u 6oltQLf7zf5QKGYpdu9JW8s3gOTdZxfkvRpaza+qymr3krx+uW+StM5FrshyqBNZZ3k1TFi4xGS2 GK9Ds7esw9+RBgmz7/T5L/uDSGQmauH0d8nNw3yI6eXMXzM2pcpI/LquKO9dIWLduYyq+72xSx1Y ocxKNbGW+fKqUFrFqI1/7DM1B5nNHJgQ82GfJnWeFWnpfEZbX6Al07m3IqlkslYNLCWOhCZ5lXaS o2dvJOc51Gt3kPKUT2+sBGDVR/QPL9OtsHnqpPucdvXOjnULmFcUK/AMEANuNyhxjAjazq78V1BQ 7bq1zFdUzt8i+r1gpmQGoHOmSogs6xJYr5Eiz9OkyoRQzN1xfJkqc9xojh+GUCYic4ag8zGK8Nxq Kywp18hMfYAKg35GCUHMlKG9eSC07ZmkKks9bSnrQjNyK+Dv7CMR+24CtTI3hF5EoAbiEIEii9dT f+1Pt+VmqgLtzjOsP6mVx5aIVfemhTsNvQdHn2ftBpiFYSX+zpLaDn+DTf4pAttUGgdkMkmLslwF B3y3Pyi4KDPJ2fwXdkqWlV0g0MlNTVmdk0d3r0YWvdWKWKk6ZPPlBlLNRXH2d4gCwjOHumxkR8dW ghjS9vGoxlMrVsicjMeqoEhSdh9SOdN7J4WDw4m5jYBNQIdfDjBAoeSi0tzjImgzAln0DXwcWXmo 9azt7oeEtvsWrNwF67bLnxhKYrE+WvacMB1TRhsTlPGdNCeeT2ki0o5M7zFp4CMYag3msaueOmEU rHIYf8nFKJqxhxZ1I6uRUu35VSRC5JpfwxYW62Uq6BDh0en3boJMpTQaOxdVIlOxisYmHgbaFcZH ewtXPgmxpkAo0HZtE4c5TB+DjSlYAz1lYwYu0MyD9ye8rwzAZbS2t45J/z6sWzlMbaDFrUsNsBhG ewIT1EFUxwRpSagKIwnHEEJdYnP72VYO21d1/dEFLKjJAe7CuHlQp9+3IllXai0MgKGOgY8B5seQ tDRwttP2dw7fOio4MKMINoZuVtjyk1lcM8sma7Vsdos0MBXZ3n1T/FIa963zjESaVxScGBNrP/Zs T6/Hf2ZWjgG9A/qQMxQOB7GK0nhwhDR9cEy91vi2azAQLDfxw7wuEiHX8Ru+sH4DXTmUzaBxYnxD IncogkKbep5X+9GNDSp6gFsDt2WAO+joW5iG+IOzQDCeNVMWmTCNmeaViSqfHKgB7Ews+SeDGJbq gxo5DAEtPGXpYOBnGq1ik36i09LJmY2UPLHhEy1yuZIpZXWtyJ2Qq/mym2xe5ZTilCw3DljzIRUM HQagx1TY4YS1/HZfJk0p1KSI8KPoKGOTQbTJfv2akY1T44XYiSGME5Fo4mIGcGjGKyIjBkNOVMr4 KLr2E42aOEL9A3xS+/V7nxMJTSr5OIz0jVqTrLIJXA+4YSJYSDQY1obIe+JRzWQykn5G9hSrqnsS 29UtaTjrGvNKNKjwOJWBZ6evhHQMJdL3LSyGWZV3/rw/VEmqlFBJ1cyPDoIAj5wr4WHfUW/291n+ KoMsH8WgeTNqkt6fhDleX8qJdmoF/tA7RpmyjdYK2e69EPBEfJUx+ZNBOkyiH3a6q4p09Zn1g9xK hQ7FFAo55wbFfGaH/WE/ztLnVQvhsnU49Jk1+cBY8OkP+taWYBC2JKT3UjBeqgn6iEM2XJZFs3uE AoVlYS7Gk6BN6MIwfKQsHk7++JYYW2ouTDsrge6Act2zmSPAgi6ewK5rVGGPN7+A03CLiWi4DpvJ kU/SOeyjqNKqFuB7K1+UeC7zg6RjKE81AtWj5T0SpiYiAycdLsl5sOSYZfJnxGYck6O870Z5AUzk KQquaEC+FKDFL3J5RBTSoFOcXFyJLhKqo7sQTGXkr7NmIk9KwzUMOWAKUDu6TuxJvyQlBaPNGL7p zWPTTrZah+NJ9ppofkt+gInHFiOQwyUQbsjhTofNLxBrIN7kUHeMmWCL1szkSAuuWhEjvisEs3Aq clno7I5pE4aoZE33oM6Fqxu0bKyrepQCJvEozcg0e8IRfnbCHzELraFppwIT2+vWh6wTdOJY818G YDIy9sLjpbYx7e6OIThTi/sBUgfvAidoTNc4mhOKuNxYPmRrO8zzK/sdlYCJJIRvFJj841uGpnwk WLDOu1/5SrH+qkz2h3YoBfaaHEfULxCqiEjRBd3lRcCF4Zxw2g3ZAaaQAwfoOG6AzrHuQnZb3G9a KtWuCKpyBm9Yliakr/bBdNQ9a+I22BWj+2Df4hAIzm3THgSZ9eBc96cHVsf+a5S+mWlH792kDxpg aclEXpfIxKgC0goC5jYndoW8tUMmklqkHC4KhhNGyhLE2ecU7MBJhouJ2HKQvoIiU5POUCrLhpRm ngGxZL+3oTIaIAM+ySAVgod25DCLt/quUIrnP1t11y+WaAosu3PyT3HBFDdlzBXavXcFzudjUpRx DlE3lhqst4ik0HRC+EzQJdpBC/Me27CuWTVDvoMRp3Ni00D0gekKK0gzABPQQ3Mh7/5pIHHY4bpA nDpK9iuqVllOGQmUto/xAI6rrlAzHKwvIBgKT4iyfq/aFC6oTOyVoFmogTyPIxe1sqRyHZ5dtbQk lHMZDFetkKe3+xOFk4SvH7CDxGajdQaefDeZcRqbjMA5izllYOHjJMAmgWBARPFuuBDGO7LiRvAS y/S2wKuQzcgcd+btN9gh4jRAmDiT5m7AEH4sMz53wCATFOOH1eBmx8zmnJu4m/vlEIqzMYieiMTM +zmI4fSuZlyayTN6BpVhWOFMiEBt3Wfdq7VUERWZAZQVlxdDpyZGtsWuH5IdG5eXU9LYWfpfgLUm o80wi/U6rsqyTArlUA5CiCUJp0VGAA4tPRBunGA/wTn8PnfT1G2tXpQrpW6XmbFP9yIpZaHm/9QW A9JJXzNcy9i/GE/zAdWVhW1g+PAAg0PofpCzAX1JWBuI+MK+5HB1MBOJWTFwiBUWYK6c7+VW9HRA YmmSNXJ06jRm56cqOiLKK8NnqsAJX7rxWN7ij8R6J3/bI6vWZrmlz9ZN7clF7Je/xeNgM3OmBVOA qfs58eg159UuVRrm5TKtMWaGYBoxXs2bj+BZF04tzLWQIw+uHMMeIMh9JlQtMzMY8teKzE0umtpn xpGcM7cXGJXCVaAuO/Cj1ZIwQYJcNomoikesG7Ash07nzgsXWHaalTYKBzBx8OCVbTCZX+FhYkQU L5Arp5vOAU3a8wXDMBG5hhOSknmTZGnG1b7R5x6e12lb5tsDvywpcxMM9Y1K54gF6TUzwz3phbrW 368sxC1dcwH8XRRmB5BAFiwi0G7tLTFhb8kzvmChpy8xbPhGkkAp+5jHOe+bYEDo6sWc6H+H5Q7q Uhjsg+dIwjFWbK3iUQiuhHjs0OyqYS4O5q+sb2l3XFn9PK3dJFWZNsxi7c9L3YTgxk9niXDMkIsp BX2SUWP/9hHif/wvZQbWYRySj7Wng4iUzEogwEWxhWFaQ8dUW3wMdcKnnxs3luars823myyt0m2e Z+U2axSDVdv7y83V4ssJi6pRW7bNa2VM2/sJny+uePmFy50XH/Ii6oo8evFQT10R+z+cOPArNVqe /tpa69AlCMT6Bg1A2HXGY3DxHyJ6SxOB9i3aQJioAve18WyB0h6LaxvRFD36Cxnm9mmUpm+aQJPs sbmSj9pc0jPMtitsNFMIn0Cac8kOU27n3ZDgImsuH7P0TsahMKJOvesZdcDeejFkQuTSM5s1ofic ovKeskQqPzBbReJG7xn6+ecJnIQ1SqQwVjcisgsNYvBEAxekxyJKbvH8/1HSj4bACN7BVzGB9KyL YrxLUdvtZTAaiuIA0GJeuU4RGId2XpLGzrEOPVN4upluBknZDqcy01HhBBR/piZcv4uIgeMMXUSm bFFcglRmIQ534+H62p60ylA+YJ1k9RACIkUus7LVsArVLu0KmLyJa3S1niae3TVRxOMtdo+aOLcv 2ARBTz+isSP05hqi6avxCQbTARcUf/WzoLPvWiR+JXSESZAKJi6WWmdGT8/iMFjM6J8W6e8XQOoi pgSEEACluBUjaAkMnkkOnuEMlrTGB3Mgluz4yw+6RRXDsaUwujNQYDKW8VYAA2lbV5opvuppjaV1 1lWwQc8CF4U8IM8K3zk0WUidR0VIgqvgUvNaUX5peemP+Ba6Bbl7dA7Nj5P9F+HR6eX5R1QqMis4 GgulJVeOHxX889mU1ODNqHmYdZoOI5mYFBO6aoGBX0HsH77xAteyDsX5hfr/TJBqQC0i2ClgFDJn TMnsJ+qIA1R0DhtBekZ4xPSYYmSSEdwBHBOA6glKVHHwbxuE7nGeKEYKZpxGp50nzhVaKcBJLaz4 2bp/sM6YPwTxDFl5Vu361//y6B7c0QTPua1998TExUYdDnCkq/dd8kTYGz3IIb/vobd31g6W1XVR FBFyE5Elj9mnr+k+ASMR7/E9mcwjdJCHwp+jIRzM/w60C/zFilkm7NqVKCA64EPGGwbXRbBXXc2G ZsELV2OUCnMqNphewK60KZEwFxkUtWJKt3T6YztLKYcW+CxlN+1vNme/eq6jL01m74fM8VTvzc9E o6JcIhQmlPqbYrBnCP7+3bIaw2CDIhHVqAqOwhhCSB+CFYLe8fTEQjs6ik1SQmAGrzk3v3KW/k9W HS4/HWR6I8rVuTUO/LWVaZxlLmBbFeKvU+LMReBhcHta4UhYQjKomdFflnDVF84K+/i4iCyWaKvA 84o7v4UjhksjM6ddbMP5CTA4go/dTlbeEjxRZmp0zTyWBvgPqXmHLCdhwFfdbDJZcfehxdRHB3Jc Dg+Y3Pu3m/8Alv87Q2VuZHN0cmVhbQplbmRvYmoKMTYgMCBvYmoKMzk3NwplbmRvYmoKMTkgMCBv YmoKPDwvTGVuZ3RoIDIwIDAgUi9GaWx0ZXIgL0ZsYXRlRGVjb2RlPj4Kc3RyZWFtCnic7V3bjhy3 EX3fr9jHmcDTbrLvBhIjdgLHToIkzgaxHOdhtStZsqTVar2rXD4jQPy9YV9IFpunmmRPjyUDsWFg vNPdZBfrcupUkfPmPM+EPM/7f/WHq1dn+fln6r9vz96ctVnR/zN8QT9fvTr/5OLswy+bc3XXxdOz POu6Nu+G78S5yNvzJu8y9dWrs91/9xffqUvb6dIyk3mbl+rCi+uz3fn4pX6OKLJW1tOXf9t9sq+y pmhku7vby6you7zYPd8fZFYVVVHvLvdFJqqm7XY3+4OaQlW3TaseqT6XTauG2T3eH4T6oqnq3ZP9 oc7aWshq9+2+y/JaNpI+TD+iFM3ue3Vb1pR10ew+slfQB9Orn5hp2E/X5Ht6n35ytXtNrni1PxRZ 2RXkAefDzMuurXf/2OdZLUWRl+qND0K9hZLf7l97od6iFZ1+flcWYvd0kJOSAn38nf4jvdLORAlB qHesqoZIxn1BI7rAo554K9LfT4UxSbyuBhnqxbHj0uc+2Atumcdd7v9+8cWZrJqsaaRWm3s7hiNQ 82BywWt/oYZL7I3/xLMwkhiurPOiIHKwn+gzyUI+c95BD0XmRe8jMmOucFSkf1pVls4kZJX3gjpo SR16SxulZYd/IJO6t3pP5+qr1cwm/211hTEub60Hw2DG89ZvuNiOTFTzylxKBr71Va//M9bTe8/W Y7XlmhFRRq45Zz7buVjJ0Ps+wku+uGz9xcvLphSXqJW/apOBwlUbTK6QmWyNp74jfkdbyzSvomtE 2CSRDzEPfQs1AvoifrG0O3UNd3iS8b/0Fjxo2C7Rm7y0LvYpmrX5493Mf7dtXdjpETuexA/tmISv g7EUagmex6FmN8bQfhTRZnlRkkF2P7ixvM5yIcqWieUyy2WhFeTzvfr/om2letdDk9WVuvMn4ACG 0Yz8yYJbe3iGzS/GPRCtXAQGsqHQgLHxCMO1M3od9hnxhoaD2Y37oubG7+yN1HNZAdyPDqZU/9ua mI5dHxUsgFxRVoqfjL+PCAVBaS6PZ2xWifuW+IBLgzKmAUphUMRwwQdOeDF+YpIi8RNBQ6PGhYzP ioYLMXRdX9rhOFD8OGjv0bDZhVgA+wPvn6TVjIWHbTKkcNtGcTjh51h7OUP9frJD9cxCaDtMWPJ+ HM4oF5d8DQCfGe08CPd4+JpYywSw2rLopmB3KHL1bVGRaHdE5vqFGl9NoFZzplJ6xoidyTIdBK3d +D2KYshmqUc1twRB+QdkfM5ImUSBXv7a1wfGBXj6YOdCl5uuKAj5JJTa++kkLikYwznUocsUWG2L LcIA1FQm6j4xAa+UxtCu5g5/Iedbm03it7uCPunOQtQBv4miWEZR/QAE92K+ggEtM9WwNIG9hAZH N971QiTxbpSTrKQDACPy2wgtt6IKYyCOdWI5kHRYbNfzFgY/O93/6NXkDBKmRNdwBsSeuHz3kdVV TsJuVFwRr6GBv3CDsVZGf12qYQojmSSzxiYu9rGP4/WkLahDitASXwlSiLIkzLlsT9NaWL5oFAax J0fJwFhzJeuDUhryI8jNCumtu5LaKDAhlZExzpnPv+8f0uSyk0Yzymo5r5ubfxjFXMK/3jCaRGls kwWQxUWgD8iFtQbs5aG4oc7ZdwT4yWcLjsBPX+4P6vJWtO4KU4G7mGmwNZUm2zATcDQws+8flqQB JLhgr8/cd481eHaJdlcRaf4L/ykzBUxwX5FQI0hJrKMQggDlhgY3jZImEFWp9SyNGlG/sxrKha08 AsWsd9GrwLD136M8iP/2kWnvMQE0nSunfT4D7rX29k7hh5DFkRhvbfbxbGU9hOP5U12N828jpulS hwa+Ukm8wArIcWZUJwihhaIgWfmPdfmuOInT/Gv/aq1oauqM7BKjHJFPQmWeVaKuEh0qBjiLVLqX LsLVxDD3AWMZFLG8bDiNEeGU2vMQEe40wluCFAt79eClL/ErapK1zZqq0gqEXSS9DVYv1pHJdrCY KtmnIyAoHB9Ac1KhxNDkVF9TEDTJl4Bz67nW5/bj1eC6VOopptHUM5wcdBQqrM1gj/vAKJ+OX7Ym czKYheHLtZWLFWxETwQTTnDu7KV7o7calrRW8Nxb0qjM+ZaZDglY5HFXKBwt2L6f20GbPFoxcQIR eLeZa7sKdY1wFm47UEZn0WSFkIgJDpJOhAD4g/34F/vRTU0Aj80Bq4XaWtBvY+G+RfGHrCm1eSMi Si4/0f6BwFOOrhpFSlwFx0YRtZ1m1VUn8QlbUddNVrZFAzB8HK8VqkJhlpdjq+bwYXpB0AJAnBFD ajqWtUwURyQGa2lcch8O/CugGCIntCmM4xVNZVFsaRizKlOajEq1n++lzMq8FuH0ayUUguQ6rBLC hotgnxyhsOGahJrjbOGWugjXXaAraA43ihdycFCDA0SEE/Z8BXbW15oN/XzRfxa1Qjk8fY7meEwZ WfuT9SXFpBwcc91ej4nLUiRWWLkwzrgN0L5QNCeJAcmNtwuRILFwmMR9+MvClE8d76O5wiM7H1e2 0Em2uzCslItNXPNHzDANuBHDxevQII6Wj8gwz/Ku09qTyIEFQx0mnkD3RyrFp8HbMsdBki9ZtZkK Re9h8pVoZYQc83vOlWk8hWmqdQZTsbyuBcxtOehF8EQMno9nb26SdBZ7ZreDKgFpXRI/BNhYe9Ot vzCTrmtNZBrCQF1ytStgdS0YoggWozJ0ZwJ2WTC4aZbEyCbPmqr5yQewkGkhe8EIiSSins+e4bhF n02ujesOTY1J/iyZJ3AmhgJqsMP2xGz6Ovf8oRX5UYm0X89EzpBr1opu9p47aOLX8WrjtJusCrfE uqTQNHElBd8jbtsKsoKBI9DUnfiIgZTgqhrsQdoEwC0nrO4WMS8fpd5hJNvbvG2t522rrJQOYf3N bri3Lc1OsCaXZvDhs9amDsdpnOqFvRd2hR3BYt/sjd+c9ikM0/7d2cXPjNWqfNmZ7ENo4nSwP+8P VZY3oishH7W0G6Ut6x23eeIIX/QI1zI57tPGVrweiUw9tRzuVqbayrgc6JPofcT5TquRz8wy2CUA 3AX0C1yPou+AgrQTU/vjdzx5NCSz5Wlm0lbLtg15X+FFjEaMw9WMrm6+a+Bk+xZDID8GNsPuKsRX cH07SRAMKiPRa3xXsK7rzgHV5HUNWakg2gm43jCWtgKi4kz/bZ0LE9HqWkXy9j3M013r0CgPVRFR E8KUFfBUTmpagAOga0SL6B4vXICn4TLwMBMbwZIGC/yYTuJK8KQN7+dKzboeY+WM0T6fEvUukyLQ VHHKqOJ1hm27kRaFYNr3PGXzTSY32kzzG2szEZAjAIrmIFWb4NdKbdpKVG4i9Q6gzyO7D4VhoULb U7CCO10JHjSC/WpHlTKj3Ub4eAPmAAnQHVMMfr+jqQxXw/r/57E5ggF93OV2Rzn+ZDZ3HwxU/UXv N2XT1fOHatuLmbKfEYiOL1D6M6Yt9bMPcI4TaTGmcqUaTrrJmNe1Aj5Pwxu7SxjX+axTka/7P4u6 Lipdej+IHukUG7GmmyIdRq+sy4KH2Sx2eEm2if7I5FK4zTwJ23Y5X3iqjb2LRwydAEOAPoy3hu8q G8N3BdBEUKIhfgvszYT0Fke2LXd1RnXJwVYUWJiar+HYNFr4G/jJ9/TAD/c4qymjabJKiG3s/JfW NGMyeq6ODlJxrm4C99fQi99529umvm+JRp9J7M5GzGAy5vTEyi4TuVh2mPxmUm7XEcmTwtuWo8Hj 6iaH0Byi96fMZ/QUoGGua0yHhcfmQAQhHL83mHVSOsrs2mMmvlRAnUUCrvwSoHyPWrBZgVTrj9cW 1bu5G+LmQien2S7ZQeIE06PKKfEUSxXQufKjc/9cjhKcJnSqfvxtem9BpauanfeAiaEw6QsJJ78m 2MsHH+6T6I6OBzMv0QX2NV4szhI0jycVMZezd6a3zwH8PSkhPdvUjNRrw8AWnVGiEJTDfnIBCPgH a9DXXD5+hQGBkG9eyR8whAltpiUOiOmxnUSIz41YIFz8c1qwIl8C8TsL4UbdeRMV3JiNWoxcFJJw 8gVJx9e2pH+FE+MU3Q+nN2G2KIK5POa8RmIQn9k3e46SIky3bt0euX4nALvNMh0DEA0GXW6k2Mbk Op49joIk9hhqSXQ51BAlywUcfFYH3GUNSnfpR7bgKMluktUyfkpfW6sjFXxykQNpVlrNk2a9/oHC EcckLhPs2q+g2Kj/NqH2vKp0V05VKPhV+rWYsO8wr8OdUpgCnKERx3gb0v1A53HLfA5vwOiy8URW B78MamXe1Nt/MsoQ7j8hyv4A1Y+zkuhiIWNOSacLRwRokv//0ZKCv7WJ/HSCab24LZTBMnB9mMs3 OFWvZZvkwCahxL44bWpJ0WE6pruus1KabQLv/sRDyq+1ZVbWG3X2b9l9DDMucOiGc7gG2BXmbo8C G64xtPWbROaxlg13Zowfg52OaZvi040jbC6V6Lc4XwPGRpitkyHO/32RpNNq02RNtRExTfgPlHNx +SpjOvatwsdLQjNiOtIAqdRWpAjKeTBuvDSYZecf3BtLNIBDfrj9hug9TuVXdfPFhC4+hpC9Na4e aJyXt4WP85h9bUDhw6lnqO+CVKmgKP2DEun5abLt1C1yuQt7CFnvrAtbkCtyMiGvI7vvxP7V6F47 YX8JoqOg1DtmdHgfxCFFMLdpIetTfLrcDbwR64W3AXdTHtielp94egKI66Hd1wH4zZS1ln6JJjbX juCm4VkLgXLIFpxKIrqlhjfEr8o7xZ0fl9vyEayZT+xvUStEYVwfwe2gs91l5uJPQTjBCXfBqMEU X53SqX+4zoyUmhm0e66NPZuB/rLGKE7ihsOEechbnHir2undhVMjcnniiSH/Md1BVeCDl5zGZph+ rD84I/Hkl8R6K9yZsriD5XooRXVdyWxboUo7Zhr977HIGTU9UEGrwND7d+YlkiaZAqL2yKAfjw8t atNaJ+s8y7fakIxMFJ5juE0pB/DZxyKdyqRZZufgaX4gaKZO/h4J/1j66cA4v5Em4ihe+FtCkHVh FgQGz+WUZ7mwjHbYcoXltac8peK/2U10OpR1JM2uKFsyx857W5g94pvsY3V/5UfTJkLUgDbZYHO7 EQLzS176bizk2DNIJpLdu2T+uz5PEEaZXp851Tdpx3eotr3wE0W9zbD+xa9UhWMK3BL5hrECx8iX SuKsrvl9DV7VYR6nIeWS8PNxYWqBGTgSMGs54N6BO3NcW54jzhHJzGcqfn1x9if17/8ALOB6KWVu ZHN0cmVhbQplbmRvYmoKMjAgMCBvYmoKMzkzOQplbmRvYmoKMjMgMCBvYmoKPDwvTGVuZ3RoIDI0 IDAgUi9GaWx0ZXIgL0ZsYXRlRGVjb2RlPj4Kc3RyZWFtCniczV3bbiS3EX3XVwz8kpkg0+kbm92L XOANjCyMxIkdAXmw86DRrvam1WplyZvkMwLE3xv2hWSxeapJ9ow2GyPweIbNJot1PVVFfdjkWVFu 8v4f/eHy3Vm++aP6/8uzD2dtVvX/G36gny/fbZ6en/36O7lRT51fneVZ17V5N/xWbIq63si8y9RP 7862P+/O36ih7TS0yfKiqFs18Pz52XYz/qjnKcosL6vxt++3T3cik5Us2+3Dbq9eIZq6kNv73b7M RCWqRj2tvq5lW+bt9oYMeU8+0zEfd3nWlKUo5fZity+arG3zevuvXdFleVt0zljyGm66i12VFUK2 3fY5GfHcH93VVaEnbES7fUWGvDCT/KiWVGSyEQ35Us1QqCm6tiGv60dmsm4qud3vyqxqZLu9NL/S 5VKqXO32MmtEUVVk/oXVqsMQQkhCn9thMZ2crzC0x9f2a7qglzs1b1PK0mxIOLMxjzHLfLX7x/nX Z2XdqN8KzUJ4mcuUvCXvsiOZrWVk2g3z+ZvdvsuqTraU8M4R+FSdzqVtm8qZ60qv8j0ZcKe/3OxK kfdk2Gs67Isqa0daXGOOpp9vGU5/DhmWiIj98hL9/Bq/+sYnZFtX/VkNeyjaLK+ULjF7OEKXfGNF nzkDuHHLmHTd73b7Sslk5bPX8NB4Rl1e9SQf2LMWvcJR+qYpSkH4nj5FaMRxu10NEQ1vthmLE8Yl 0mJY5kDe9XurFDle/nM/m8zLriSvMJO9ZRZu6XQBGOUVIH7PBj+nadK7mWgMX44qv6hmWyKnQUZc jCpE1IoGUnOOZx5m9L22qyEf6Vi6nisrqgmmgQ5mFb1WIuYVw/NNrvS9Zu9WfbsfhUvvkigIw9bz k+1Z+S1cWFhuXlsRwHzvcWovAeSjXQJl1UdWF3/vbWVbyEZCYthPlhRUaJ9gH4VSi9OD/zFTu45O mWeiUPS07EhneGBE5S3zFl5EfG8jzOBJ/OsbXzFtWraMI0B3Z0eEnRjGgYBqFJs4fpfWZI9uh8zq yrAPfezAkP2BORq6EMp7+0J5bzLvOaDssiIvOHX9pT3PJ855DSwkpc9CgxPx4Hgc1o8YN0bURIiL eyXDcbERhXjGHGw245kvctswGMsnpT0w5nfWU3a0kzaehG04AjyCTvput6+zsi0c4ZxxjuZKe8SM KrIycOvQ0JjFS0hO+xgMoIJ+/D1WIJfAP+CcoEMoCAF+CZVBvBozlHgGjswhJ+Ae88Etw8/XeLg1 i2RpL4CW/BXjkx0czh7VUc85peYcn+pN1wpG5d2yK/aZKyqOXE8i/cKRQnlpnOS6qIl3Q7nO6q2R AkRvIUOOlYZRCXRpk1JQ4so85ZmVXubMVICsbuAU4/leJHiEdyjcJwaemIm/7fYiy2U+iyGIY4CF BjjuszglLmqaPUTeQBX1gXkb3ghWRVxYpD/qCKDJygHOGhgHRyqreX/l0QGPt5TKIJzIunxrjS0x GRNBi65OsTkBVp4Z5n/aKSCiYKWVvhj6p5S05GvGD6Q+iMMuWkTw6QT4OAK1IoKFOQoygHH3qs/e u0hy0U6jNydxMsYbhRmsstUb46L2G3cRPjJKH+Rsm10HDEAO/kZdR4Bh7hgs7xh8FQO6o5dRZ4pf NAfhl0wy1EWeyFw+uIiJEIBTv4clzsN2agh+rq2P8RP52kNTvEhppAbxOA5LyjEug+Cigq5DNEdS ZnGUHmz1JwB4GOUZRhp9nABbVOiDh4wzFw8ngQ4cT9MJIWZ4y3x25YU9C97RCGYuCjdxMXDbY2AJ 06YD8cbocbR52wrjcTSKyWtxaotD90L3mGZeGATdBaW7TNS5EoGvbbaNvv0VQ0k2CNb2xqAy9tcn +OSJFJJQM4Cgx6T3KOzrKZUkE5CGkC27SwlrJHNNK6jzXjePPnml9CdE2IKa4M5/LUOEFMXkJjiw 41Gq2dq6ZTwFJ/UwOHdSdtNYNYIal2n3xLhEJKi9kMrF04m8cIm/JEcu9vzdwJvT734KQeCUcUwK dtI1lWNzY+OY2XICyBcj9afFolOSQIP0VCqe6GotPfQFE6o0IEKY6WOqGwIOQ0iuUnD/B7vLoB9z YczoDXHaGAduohGRseMFCGa36ADOpNu3YG6wvz9yKizRUGqTbblpphse4CZDGbUI6lluA4cxl8Gl +HL0h4xCB/E+WNmIHgGnL5As4AUJOdFksnB8l5LCS7LdhjSuNhi9WJEJC52hSO8D47i+mMvq8K1d GHJRYSASEz1wSazxJaKuGZpSNUKDRu3OV25IOBKDaJQwnSEcEtIBq232ggr2YkqYNXOj7JlD29bN Z6SSlqKIWQqm/xITJDgAl4/dhRKiwSIRgAq4HitWsQHUKUYlBZeWkr4jPi8MIl5ClmWCaKQXgU6q FPfUhnvc7Rig1U8pVFJoALwuhC0Q/KvNMpDcw3n/fNE0lZrrGa46ChqQ10Dlv3C0uPpZ1p1xPGsT mItcLan9/KDgk+P88xeE81g3kKWcqAIrkWXfTCZWeZ04wXUaJDcivNCH5jkDMi+Fji9ErfSxRPHF abLBL0Px2UJBiX6QqB5s3KlBp4b+2hp3HJyPm8fB+dq4OZSk/tIm7EiW7nS2W3FvILIeIo6viNpz JFxmdVsKgWCYYB4PaLqOFbaY5MwyRMWlyhMkMJHWliSD9DSFmh5BW0FoCjnY2MzA/HGntn0an8w2 a8D4GBsSxmZ8HAvmm4YrtcDHCPJDc9+ZTsKFAFH5r8CxYA8s2AfBpRHD+2Ucit+qs+jUMTfbnAzg ColiVr2c9nAyanqoG0BPSQ2N6Za5QaWYpCbyLpko1pfT3nGbuL0qRVbVpCViZOjxv/50dv7L77e/ GcjVKu2BPgEvX5KiJNFJ3P3gIh6BKqLVgJGXTZhjR66EkU4oGgFOYdU0dgAFr5EU21dghx1Lq+Pf Gp17iY41mPe2a8GqlZiCMNj8RT+vbKumjjERI9CheLoRmne9iKE3EF8oI1hWwlUNJ6iqWs7jQiJS l9U3hijuCJyKzywLqPEbLNmMPvS/HrwwWwWIEd57m7enEMx4TMA364yzP0gx5t0DGfGefF5Vvd10 JVMIgFk4Jfm/suRG41a10FsSvRsJQpEFp9NO9ztjb+afWq301b9+MSjbH7YTRlRqCnpUJkfFoH9g S0RfBRE0OkNBRujPfSn3DzsCs/U78KGs/7puk4qe81bbNc9tUg+VTX1aLMupNJkS0ZyvY3d/5UXc /X7dVyT3nYQ6XfQ6l1oEoro+wvA1zvvGF8CG8lNJMfUtQzam7osoQVLVtgGlIngfj5cVZRKcE+Gr ThYONThnk+v6SB3P19d4Jo22uFhflKcUbaYtnF7a00gtV7oHyDGM5ySMUXMcFvDeGJDHaM7RcT+l RbAaKjqgWyr4w2/kqrkWo+RFsSHNgcgqMfLhKIsx+imUHTGpMkijQGPcq8XD8fBnDnsPZsUYSII5 TOiV4p4AWGLWA2wnsq5/sFC23yo8gyi8E/zkUHZESY99R3Tqe3jOrogE5uBaDT5qSAGbnWINaOmw 0eJ0/2XarrWFNzA8LPNUUZTiFlGUhTGrMpNd5eeu0zYRAXivcl044rAI7NKBRrRS0BbQnizE/F1R bgJS5V60Eg9LwNy3PWacJj9GgvyYCrGSrNzkqn4KZnQCrSJQpAyjousRYPmb22tqZ4KcPpNzHxYx T0UJoCUatqw/TuZNPV21CNWeX2LicrxTFemtcGW54CLrrBJVt7x+SVIdvGVwOQ/EEbWwxi35lmaX Rjqm9BUsLJRPKCUVlC6rxDlAwDmxQdBiqQR78r/XK+dEW6qPMUbEIk3pR3szEA7A7pEDtcy1QwDm SobO0BYWr0woLlsd8V6Bie98h5bxIk9hfmOzcrOIEN2nNJEP9hMHCs4WEZEQrhUIe08aukFhDCYk TiKLq/OngVT1BDKqEc+cYnsv131EEy84Wk8I/eivUU6bNBUTwYxiWonHi53i0/6uD+wQTpCmoZsb gMk2Kync8f+HN+nnv1juxYU9bJ6L9OqsvPEPBnskmGPiOpLPTkJFInhvVbkwg1DAuYALFgz7mQHQ 23PaBQbBKLus6zogGAQ8DsA0Q96SwDRRzoW272k3LCEjt2wPRmFzrnLwAlbGMSbeAqvBvCsDvaCq z5BZr/PGeczYu+kUohqOdJAUphyuWE6AxmdZHXxLTZoTenyTB6md+okxU/7tTVF3ZS5XW5D7OFGq IqxVgtooqrfkCPMwmeeezhOMIYXazSPha2whqA81LJSB+vFUhBcV0Zu69vKkoOsQ7jnAhPGKWRbu 0sAMGmHAEnNoYz23clA6E8oQQOZAvC8ulxZf3xeTCxjL3ppcOHQDzaAp2cxV9+doZUDvfaQFrRRd IFcc0Jos2wk3Epgo/8jlp5cifBrdT0eEWl5ilu/DguG8c4DbeOgNcJN/YyTvl6VwXow0wlpaqxR1 cVRhC/vwZQafOP8e3XYfwGzIZtde5kqLk3oyJfWHRfZQL4U0gXr7aTiBeZfRxtQWVpAQyMh0Kjgd aySbhWsUj/A5kgLINHPul2b1jtNaYCX8bqzA8EssZ83umNC6bAVCNTD8wTtyR/NdwPcyISgNC30Q n26MUXZxl9xGoCpay91PCq1Qa9AclFbsA/FixjPC4k9cGa5bnyQzccdEWNsGDQ2hilde4bkYVufb Ck14T/1AWKIBl+9BP87BcLLgCEqNPou5rDJXRkZnXLDMkgiQA1JCvdJUESVeqI5ZO1RzHCF1J7m9 TIWO5JZe3Xuely1oJ0hbHjOEUvokLXkWm44YDIu1UfMvsdwW5nWdS9qf3hNs/R+JwAaIRPUR0vzG DuGqqhkMBgECpFp3+rjYhH6EH/EM/UkJaNSXbiXqF8qg3jjsWboGQeK7+9nSdh89AjfDLABmDA54 ohvWAuACDvBD3gry/sM2HHVHogsxKGQyQhVDCx1QSX57YhMGk+e3wbp5G1FnuXM32xHM/Th/AIGk Y5I8YdzrE8i/zyeBaCkjpRwfMN0rmtUq/u86BFk74o+vsDf7w7UG/3ZR8ibbTC20qRf2OFYaiKwo TWYzLMi4Iyp8Z01iRThzq2jw6r0I47xcFDX4wzPkZfCHbUFQRA36RFViqyliHlOCABMdoMmtb060 6ukTpgCI0sFuNDiiY5smfd3Gkc9qOnh5FFZosKLx31bU18LpK6vrMRa4rnpRx4JLZdFR1afGehJY 2lV7o1pps1YYtmGD2Dj8bJ55jv5LdLAiyysG6H+G6GAI0oR/Yg95HySXyzVJWtUxUo6oDmKICV8u G8PPFdun2CFXNMK0bGiDxpiJk9XkLURzKWxqDt9IZtiMRtj+5ZsN+itYdX18l8kCGnZ4U1OKwaUG cIrbmlwX5u/LVmTSvVv7c+4eLafPsHu0b32d/oqemtpZ8J3ZEnfli6kjshoLO+DPkbNL53qKLnmy ZIgHu0sdXX91fvat+ud/T413mmVuZHN0cmVhbQplbmRvYmoKMjQgMCBvYmoKNDA4OQplbmRvYmoK MjcgMCBvYmoKPDwvTGVuZ3RoIDI4IDAgUi9GaWx0ZXIgL0ZsYXRlRGVjb2RlPj4Kc3RyZWFtCnic zV3Zbhy5FX3XV/RbugN3pXZWGQgGM9kMIwESj4I8ePIgySNLY9mSHWuc+Q3P8r1hLSQvyXOLZHd1 kjEGKHSxuFze5dyF1PtNnhXlJh/+qYert2f55k/y/9dn78+6rBr+G1/Q56u3m6/Oz37zQmzkV+fX Z3nW913ej++KTZF3G5H3mXz19mz78+78O9m0m5vWWZl3eS0bnr86226ml6qfosq6sp1fvtx+vds3 WS6Kvt7e7/ZykKatC7F9u9tXWd1X2293VVY0outlP/J1LTrZN/n1Qj992JVZ1fZ5tb3b7csya0TV bn/YFX2Wd4X9+Ssykunqgfx6sdu3WdcWZTP329Xt9qPsN2uqRvb7SNqagU1f/9rti0zUbWON+2m3 77Oqb9uCzPsd6WoeoW069V1fVwX9mRKJNrk1TWiH1+PcRDfSZH7/CFdPv7rSv3rkd+dzAzuTjQvZ uu9aSsnXO7kXbSlKe1jZshdNa+3KBenqn+fPz8qmyOQLxTX3HvkFt6v6tU0hNaiZUzZvVF2pQfdl VWVt3m72A9OOzPyLzeltlhdF3TGcXmZ5Wakp/263l3LRFZIkdPb+ZtmMRBeFmeqbrf7M7Bs3BGHh z/ozOsY3O83uMxGKLsurul6FCF/u8qwty6YU1qDquZPbtNfTeoD8QFZwQz477WSJlqKkN7O6M7O6 NY8XQB+Q13RjDB86e7sXWdvIOUM1Q0l0h8a9MtI3f9U3M4kl0aYVFlVeqxXmcgJPiKQTQb7DSugK qGI1lS51LP38rbvfw7BmqIw0PS3HvjBia+b0PVk/2U+4yYRf6c4CNvZUqG7M8MwVsH2mA2BCGVPj bZxrfxjjQrrQWvYilsto/2F7bDNfOYCRWhDrHr9YRddBzf/CGNMLZJ7MYLI3ySRN0wi5d5N1Gnik VTwTsjR0KD1xaNISza+DWawOvpAzka87ySPKugnZqDyVqhREk//VqE/S8nyYe9GKRhLnmfk5sEFL AnGIgI0UfUDEv8cMhJXfvc+sg/qbSS35o8glsDa0PgIyf7VrMlGJsiNiD41OBGnotOnzG+bTazTi 90v0HT/TXJ62cQDsevj9dhbGuiH61+wLBbvmvYekHLGnv9JJPPosYRk52vZamyX9OgY363Evma35 t1EptPkno2UJ5P5h0k+1yPpCMxAx6hGexStmHlwbov2093E9wZiiqhAyj9XZ41BXVMvtC9mtyBui nB9wF9zMFcIapqa5dCJg03Vzv7LpsB0j2efptlKcZUdlk0+6dKawFvCXhMfoXiN/FaN9yvCmL6Lk l80/gzsuDfcgdIqnMkOsfrQdYe3sOB+IW5MkgRh/wlxm0kQSKTDcMM+zwyR3ksARMzKew6R027yB DiUEDL+SBr8VdVnb6kaJ3peTaFZ11uWdEs1nU4RASCnWWuOZkWwCpSLwGW3yjpFishEL0YuxC/Mr 3hCM4mgP1aKjWYo864SgMjRvVVeXagEiLzWDjc9q83uxtABHirC7triAsYeCtFCLGbxPS0CGxUxL +PPZ+a9fbn8/bVpfGL+gF0vGalwXMla32DRyltS3RlSChxb/naCE1ljzGM0ABJmoBFA7oqwVVT3H 7ggYdbK1m18RKHSChx8hJ3ITeuoiyzVd3b8bDI4MAl0iNbIYAz8yKyDr/a2kbl+Kvt3mNgOPGlJU jMNNAQSw/wQH3RhdbH3kQxHW+fNCVK5e9ayQ5Q0T7fjAdACdb8YPP5rsQ4cs2alxNv7t2ERapMKK wU1eb5O1xnTRHjDiYf0E6c83haD+PLcmTVnLkIbiC/M2DII8E6XrWgu+zUshpifoP2q06AeOV9VT xHk2OI/ShzoKRMuAmS6AN0VMfwsG+/bIcApFzFN0ofZTLp43g+XO9dSkWLVNS0XIRFA4lIM9OCOj j4BsU9BZKwWEihNzMQ9wrSg8wzhwZM0MUOYWDXIlcwSzyjsSm5khV1UXWVesFJcgMZwImQdB9HeA JUWFY//kEUZBLhkF8hEJSETcCE6CfocbE0YO2xjc4iNkBmRiLpm+GB6CQ9iuNsqyaklBU1h0ZefJ jDxa9lkptO0IZhGvtM+9jNVEzBTehYjwaIBDIBTrQ2zhmWzf32Y2xCicGDf2uQszR5t2Q54ZWzeT ntg6P/zp2hja4h5OOeR8HSpXh34XrzWA2LhB5qApCAcxfLtSCePjL+Y63QG4pFlA5y1UFSSphYtZ gqU1E9p5CGgpEnZiAheYxBFhC6yxIGiMjzjeGQiM8UxEyCU12msSRZ7cjSLsyNqoDY1epAI+7UyS gDNR98gEx5pu6NcI794iwTWcqnHo0yQlEgIkhuKmWAJrN2gg8U6fgHN0C4OQ6Y4TEGK6uNKJ2oNg h6M0gS/2FItoopIiqJgufwqdSq5rGsU3bmSdtdlmB22gruG56YmmwVKyuqYHLosTr5/rorasOkw/ zKQgIo9yArBehckOYFZalpNK2OU7LPJxBXHRcIdY8ETlP/8YBLkrRIuTNoi+KFTnUPgTcpKwTgnY PkbHuUqDUTc8ZxNlgrVTEPPinCs7yrIAaeXVHIiWjlZvHNzy/G7pTLdtqfiHduGWx0QGF2kbw2Wf rCSQqbM8YGmo5rFvBmqvExJ4biwP5Rq6PREyQ2pGHiHnxFX/uN0ugcUYCQ9nWHlzvJDMxaYKhsGO 3f7Vw0/mV1R4DEuBley0WdPrmNX1YmiBdMlHGQ7zbQhUskKa0mcu8sJW1Ir0P7qYqvPqbxVDBIIU PxkCTZLZ5Z0pIpJyJXdoJcl8gbNfl2FpxLnTN1BVYcMWzg4kFcl6DOiVTJCKQh+SfECxX5gWP5kl wRnDcEiZi9DcMbNXHGvnyDSIcgY3rVUNkegrH22nnV9goAn2/pkTGdgjT3KaICcwCIXbNSLXEaGJ FDQ/k5qgeQIb6eKYBDP2a0kffrGpOjcD0vAZ6WPDPK9j6COC9nZzpQ4WnZWjHFvsNfq8EzoyE+R1 XFPjFk46s8Zm5MkssHkmUHJ24oNKNKxDGmFgAaINCiBMeyVG+LBvwZw8QiqKGQPLJJmxEc6BrEQ0 KcOE6/6vYfTNyGBE1ArGpWOElETWSOIWhASY6ACXBGCsNZn+E2tGfTYVFESEgoCDsmpynZAEhhgP CTYyujqYsQBFtPYe41ohDJAeQ51hEcW6KXyuLABscbd8JNRK+y3F80GsNQKPsCFTpde/MGBjo9FP XVVGnSoePszwAXBg0g2zr4EhHyQOHRkXMcYkFEnAC9uwVx7g8dKMn51S9wHu2MCmrixgk1gpdHRa MOIAQpID79t/R2PaieQ10i6+XsT7+ZehucjLvsTgmawT7/d8XFl0XCoDFQgwknwB9UKy+z7Vt5RZ m5cg85hW/R0OyvnnzBj5tR0q/zPa9gbBx0WGd05EkgMgRMrs1bgexUwyIniYxbRtY06WwlnYqEed xtGKbEN4lTsykOzfqlGCrs4thDU+wol0VLkYOodRUfJkIAR3XEdxzMHFZxEAGRngqBOSkyWUDNLq rBujAvwzEIwphifvMIggs71y1fzcrdI2Go4wsBKiCTMqOJvQFrLn/n8SFQ/lnnF5o5ZkAPXji85N bm3N1FoBhMJ1VlD0HYt1IJPinkeAeBpl+GwEoaoRrx3fwImbubW2XsaMVs0pzPcac3lEeQCnBVAA XY8Ma9YT0g7vwtMNHHYOovVbfTiq7XSV4L3RK/NnIwRPmgLVN6ga2MFZUOfwiUoqnFPsnjtiDl2X O2POb82jCUfQIUzqf6IRMe0xZ4OW4IRt6I1A4LpJJliwXBl4yJmmkW5mV0EEwqvNOFh+1mYTfEbh tFdXlMzW/3FXZxKeFtbWMbm5JMcJbqqfrYwu6T4RXSpm+uRAGBNuAwFy+8qapfPfw/vAPQkH1zUY pwankqTilYRrirJgkOByVDQmjntswTqD1JJuwIioaAdFXn556K1GukWuUVsoSBaRBia8AbS/nQk2 yzbRk2k+0IkLnTG/QKUGAX2fEISk1YTr33hxmlKs2OiF1FcEeGKH8zszBHbAmHBUbDrD0pkQUgF+ tnPyy6eP1q5KPXHligrQFvyRu8MNxPkw0HwxjeGtpH2F1/rg0CwxKgyjmtFA1R5TnmHrToyLIwxL juv2w4UM3K6jfCe8DTB1mvp3MLcxlKGrB8lhvz3BGYfI1OSkiCw3hREE2AcCXyqmrn/nrIUbVHet Gi4TjDmKFcTBCxs6XFLAnDCaKcK4JNxhbpQCxQnVqKzgKne+JdZGhe7ow4WGKYer/CinVcbjdsFV AtFU2MK5EzyN/v+gXDGCd6l9940fvDwgtWhpgokSx5fwGPwxyUGVYEyBup99L4DPUsSjZvcMhleu NBHg4JqIcP0AdxEYk2rHho/5EMsWjjMwBEK+jaN0FeMHi+dXOidIDkWsCsUTWZqSNJwCJCteH9XV zLRgJIxJf/kejykbXGDwH4FRZjgdGcSwJU/0OLU25FzOFfwLErxZlQFJVtvQhTHHSyd4kyusMCtz Scy1rurgs5kRsJgNBrlReI5rQqloJnoPQkUpp+diHE2lT23+nIv21J2sea3zlLg+PXQRBwerMJG5 1omllYkVkX5VziIfKOg+3wcrBLntfNSma18Iy8hmUBN+MFdfWwBNxUMOr0Y8GnukF8VBjUt7e8P0 QfsmjJl0IUEQ4C3WAcSVL0fEj3AAi5JxcqfbrKj0SaADr/hIO2e3CvFXIGLSid+JTAR0HyxR0IAl iJQ5onSi6/djMvwR0Vzdlr2MSukWhL3eMxr91iMwH9ZP9mC13sCG0Cyaq0Vi5DJQ/ZVirfGf7SCr CxwQJFl9aI6J8gTMNyXIVVmgKEkcLlpZHHtsLwEve1cIu0umwcI5rKYr+IbVEXmP1nFLUBfjVII4 sc3+gP4uhV/mcionYJ3jRnc7kdVdJSwUkHKQkd3sgRpLiHN4b5+JMM8cmgj+VaO04kUszFgz4hgd htF+hO+IKzASThEzZlZBirYoUYSOFGGFpoDtOzbkS2Wy01ddJqfdWmWRSRu1fO8oJS2slVwqgNRJ 3D+cn/1N/vsP4WdvuGVuZHN0cmVhbQplbmRvYmoKMjggMCBvYmoKMzc3NwplbmRvYmoKMzEgMCBv YmoKPDwvTGVuZ3RoIDMyIDAgUi9GaWx0ZXIgL0ZsYXRlRGVjb2RlPj4Kc3RyZWFtCnic7VzZjuW2 EX3vr+i3XAW+ikgtlAwEgQ0nAxs2ktgN5MHOQ6/Ts3bPpMfLbwwQf2+ohWRRPCVSt3UH/ZBpDCDo ci1WnVqpd6dFLuRp0f+Zh8s3J8XpM/3/+cm7kzYv+3/DD/T58s3pl2cnf/penepeZzcnRd51bdEN v4lTUbSnquhy/dObk91/s7OXumk7Na1yWbRFpRueXZ3sTscfzTiizFvZTD/+uPtXtld5K1SjdudZ mYtatd3ufSbzsumKkjxd21/fZnu9mLqphNp9nu1lXpd12eh59OtKtXru3RVpckee3SD/yfYiV1VT 98MJ3UDVze4PWZc3qpLV7gGP+9q9fuEeX8EZTL+q7HY3dhtkhPNs3+RtI2S9e64nLhqpZN9Lr6bq 2mZ3AYe9tE+OXh9IS7exYCldVQqz7qZuzSb7RzKtWwtp+vMiEUvlTaFIYzKw6/erIzlZw3jWqiUb O83+ffbNiSw1nWppWIbSxZxCW9ORHA3osujzd31jVchOktkeIGk+96hkR3DdKLNdhWubDUfeUs6k TO2Gfo3nBhSYzUIp0Ol3nRK7X7Iib6Qoi8rM3LZNaZhneJ7mq0RldjK8Ps1kXfQnsTdHse/FeDyO YLU9b5NHustxCbKWyhMrt1ra+E22LzXnlECm+k5OEGgnZmKHI0RuieRPTC+bieX2os2LsqrcRjcC OYRADIglc1jf8QEiUzKHzedGMubPEsjY0M+nLkUBsK2HTOVVK+saosAF6N9j6e/h+0Eo1mA+7Ufm voUkesBC+BzOwTR2UxN5dUhLOPF6grwqb9rWMNCV+/0vTmtw4PaFE3QfvAwS/5YJPXMrOkicnBB7 kgYtsbmS5ebSsKHKJ6y5eIzzfgBlzuG8mOFj6Efbup3dufOkupswz/WMMorTanizWF8zbH/HSJTH tEK3rmvlMy3sxoEObYOP1oOBQQyqMi+r2nDOxLdVSZkZn9aVP/GiDcKaRHa5N+YM7GFARUW7YPVE l2gHvYZA7x23XmptkG9SyaNgTgQi+piB4Esgam5iIAXgYEarNaI6riDr3bM6WvaeRaUIKCUupg1U j+FRRzr39CFcVlcfRdt/n+1181Ys8aZhPbdpBtYIrShAWR3gDpPOsGjkjF4GQLC36DAYXOVmwOJu TzS0yTz+18pN6J1pShO79Rv9Uh9iU/v2zC0Qq1ax9vo9mpmOR+0NR5MLn28Nh/2WyS4Xha936Qnc QRcn9zT2gHB1ldeyMbxDh3sW2OuLUGvhxD58xtgHjMVDYJDu5BUzN6YRXRGj2uLeqL9w63tMpCJY xxjDTuod6mEfGSv1iAYb2gDsdBR5QW2B3sgt9XFY5rborZ2pomk7uqOfdsPptZXVr9pLtSsano1E dou27cyxwpELjNV0BEFaVETKfsos8IybGbfw7cnZH380BmgnajPDsPAr0n9vt/mPbF/nhRJdhY21 W3BwQ8BhmHVL4P460+Jdtq3kFIiz0c06GdTmGMggSFUThMUH9sI1ZU0ujda1aOhYnPi9J6fleXnh ltwSGJmlSAq9pFtyztwx/e4fkxYEIaqWOSaZF7I0p/RlVueqVJqfAL5s5RVcQNpdO73rRngFgSXd kXfSoB/u3YkkkhbYLofT9gcnizBi4l6eh/BHt4yJPTPK0SktBQn5AMmC5W/ZloS/iNZ5DR+xF4TN UW6+uFeR4IIxqhq7dDDIcBVwsvJXQbZNukEUAJEBJXOhldtTU2FUbdVLamumrogALHv5nTM4Osri wRnM/TBshBOfIeozEevfmTdYe3/h4q3+zgZ/WJW7b/Vq2lr6DHiJYI7x9kisycxwFN18WAjV0QcD Ej2Yt5CRMNNRfwMfKCE3O3Woe2dxTtOAgbFV4cpNzPXwtAu3b9/TowEsfXRNLcoS55agh2rCnKLj 9dwj2IkIRgTLh9NcNHnmxgXXkdIaOiuc1biMJEfKWazwuheismw+QDv3VaHZRPOLnrgWUgQ+9XwA y1oMLj4umvXg7O1Iiu44Zu1ZP7poVF03jKpHcbuP9l1Me0YyayvDPDPIe1QihRggxMCOpnP59GCQ I8UtIoGvlJA2HhhGZWDEOmZnehQbA+KVprwNF00zDWGyG2TcYcDGBGU0C5Yhsp3JbW7Y/ALMZ09u 0xTMDvr1Keg7r4kNA00kgCnoeLQGuxVIylYlTO8hxa7ngdq2WkDrTfw2sinowt0zFArjo7OOPy/J tE/DuAkaotVSapcKFBeOJKANJYH1pOwJeaIfyioIV8N2cY8yJUG2yvGzS4N5Otr/Ycoua+6pShR0 jvqQ6yDvsP0cEGHaS6Fhoeiecor6KxzQpz0/Gtr5unII9CmVEOij4sSmhqHjYTg5ISoBRAFHV1Li JB8YUuCaKV+kwoKGCF38bO7KlT446fJ5eEzkyFxIiWQKzQey+vEo0aJZ1WtMAIj9a4q2Lpsyrpeo 0Vn+KhZbPYLGCO2y6KEsJOBi3ixz/BxfoYoNGFEDlql9hc3SxwTmxjz4UYvWOKEitlBCaHeVU7Dy KMPaRv94OKvBiibsdaR6jjARWFfa8S3LTWzBdaFE0yAWSYQlB/EqQZQweK+3r/Km6SQ2ueJBJl5w D7M3rHQyNs9VSD2/RusJmEJz5c/Z0p4SMzVWratAgJN8DLUVJ6zX1NCIQF1Ycg5iZGyIcDmVEniN 4y6JuiPFyLhUmILGZ0QWSPw8CGjO9R6WJiwstAWFWcMDxNp9omkXrnKgITuAKZgJtGQFasaGpZO8 yxrQ4jcJZMQcKps1sQPPAaOniGMFBHpsfbbh65To4jYBb7CnnhgCAMmMVzGrxDUjxofLZZMwwaIA /snQRDLvYfaFMyxL8t6v28LPVBkmpFJKZtrDi7MwNoNjnetQ3LEOGBLVK1Hy/v/56TxzIkAlfm9x aj+m6LSN6b30n8bY5eFL4jjRfx6Qr9HQVlbIl/bXbxOLtoCGeyCLDyY1okiLajQ6iG3s8b/jVCPW WMQmOXe1sLhWLArMidcCjTNvABHjeUKY5s+a0p1UXbMr3GigZuRTpM2ixIEZAS5di6iHh2X8XUx0 6x4gk+aR4aB5P076YjciYHwqepOKixwiUduQGzYtvSeyeLtQljfvdug9NM4gIDWv19jeNW7UjcPD 9HsqgpZcuOJ7ipSgEB9Z1pz1h++gfZ1JmVdFIziGRU45l9RgC/em5VLCjcHaQlvALVIwNXMMnPwA RRuEAWBAiZuIDshV8BM2DtylwfEd3jZFabOYw1t6pxfHhEeyEPsupRR+GfO6td7CDY0lhzXQORmM MzX+hupYo6KQYJJzuJZyaBynIOVyKFhwXBrlRm7AmDj0QB7eatkU1J/hOM2q+soEp3FdtmzNyPFS FOrGcZHvi0WbKowgPyJY8BWmOL5Mk15shX37UO0E4jyFtuYxOSQu1IJLCFcYiiJls8hVQeqSTswh ANaVuMUtwwYg/zIPV3NRCcx7M3sl9AKmGQcTAB72oFGV6AlsOAjeZKYzTVHAGQrR5+nQdYvvBjWg pBTYzI1/rGPl92Ds7x+dRbVsjvdZ1luiXUnylSpgv+jJqt2JdvgSb8INFViuzKlXx8oHf8IB6/D3 LoiAodLNh6ul3LCzaLt9fpbtu1wzYksZcPkSJD0s74s7QCGm69+UEp6XLtOCi68juWAORSYnpxwC mmMGR2q4tvryLZFX6O8chyS8lbSc5mGCkkyMgetJtKObhgQ1ZkbWYBpf2ieaJxppyZjAWL1MYLZY 3LfNhXJQUUCXF888HavMz7eewAUVqrhZh3uQ7qYRXoHXp7nasFwJ8IsDHlARyCnfFR/QWGV3MHfZ R8+2y7vSZnNn19dDnQwdIaaWMvVDXgDLVn3eKrGWVoXuvle52CvfkX59ApGqYez7joQjgp9g2m8m TvZbFFt6To+9NMXWVZtMaXo94sxVIrZC7Gs78XuUuJ7ePxprxzEftYMggw1mXJ8SFvU82cCm70OB LENaOiGIrS3UTcbUd/r3sdIxm7aE8dD0Ty8R8MOFrssFOTxob8GNVjP9MFmDrW4Gk2e4aANVUaRU XqZ/FGn54sv842+qkLX3VcIgBTGWujqTbdxw9EIIvg2Ka38S4pvRTEDkgtHMh2DDTPMCR7w5v1za GBtxWyJBODFn4vLUq8O42JefZVKkYwVcgF++O0pMrc/GCIzzDyL3znB6ldFRG3ymbVW6zy3o3O7H D94Ejs9ABCJEx3AV+oglLA9dJOaiYMXF27AD1AwuzMT5eZ7hae0IeAKHftzV+7IUctPfMWoLq6BI lSuyBfWT1I9t1ZIVpPi1m8T1l4I5PXfcQFxOyU29RMXOsyBMCDeOL5e/NrlaLP06dXSjICGmm/zJ yi2AJHavLsX4PsjYIZ85HUFa5E0j/XrGUtVcjfhhF+hWfAZpizpvB77j5gj6uo9RsdmUyEcA4eVu ysRpmmze61NrsnsA4I83m+dGZz/qKoX+KB10JETd1EuEX4EJ7yr2XMdwSuQeyDHd/fA+7KbOfkLM mkvCedHpZX/6chYa+uvZyT/13/8AV2UtBmVuZHN0cmVhbQplbmRvYmoKMzIgMCBvYmoKMzM5Ngpl bmRvYmoKMzUgMCBvYmoKPDwvTGVuZ3RoIDM2IDAgUi9GaWx0ZXIgL0ZsYXRlRGVjb2RlPj4Kc3Ry ZWFtCnic1V1bj922EX7fX3Eej4ocRdSV6ksRJ62R1HFdd4uicPKwF6/XyXrXsb1x8zcMNL+31IXk UPxGpHTOWbgxAgi7FEUOZ765c3/ZZKnIN1n3Tz9cvDnJNo/V/69OfjmRadH91/+CPl+82Tw6Pfny ebNRb51enWRp28qs7X8nNqIsN03WpupXb062vyenP6mhchxap5kQpVQDTy9Ptpvhl3oekadZXgy/ e7H9V7JrUimautm+TIpUVI1st++TnUibsq62f0x2eVoVVVGraXZZWjYyz+T2vHtuq7oUzfaePH/A wz8mWVrneZU322sy+sx8kHnPDqAfvJv/eF1JPUlbFoJs6z9qW2p0U9V07MtEqAFNs32X5GlRN3J7 C9d4g6d/SwbbT5m5LCnpsukX+Ml2dSprkVdo3td2Nbd2W6+SNs3qvMmdWQfyiyIr6WuEBNfuctRs ZStrd8SPp9+d5JXaSy0079hlcXuYLlcW21/nGGA4DzTrV3YP/0h2VZo1mdrln9RiFZFkVqjB3Qp3 RVYpopWbnTpU2bP/f13ZKFPFWVnJyIZ6Ka9LvcHv1PTdjhVl6eldMyd5cGHxSNEPwCL0K+RD+l7p M51en+af3xKhGEgKRyKd2TRv4PPQ05ZFqzAJ8zjhxmv0ZTr2khF7d75dmxZto3gLs84tpIx9uuSF Ua+O8rHCz6qqGpaRB0FpFajW84KCSagBo2g0S+eNQuhKHIalnyc7NVwKdYT3kC6UGq8tE1hkIbg0 kKVV0sewvo8F3WAy7SwaeMxn5v3KyshIOtGWjOqwCEx//96KNsEeSpJzhi0IhHpT9wP+Zs/1r/Yx RjQMm9ldv0l2hZK4wmH/WVkPgnC3cpfu5kAdGB4YuUyzstLcE2ZfOsKeARVBTtzumCVrebMc6Oq+ NdoEDt0keZUNEjfu2kjcC4czKHEtCxCmtaxuP3/mH2mEiQSFDcvEelnrKVxWAOibIuKYgwLh0agb irjyLUNkjE4pkagRKoVMs6I8kPZfZxoTgmPkIQMYC4BKws+M0iavuoqxTasyU8xluMwe9c9zsBG5 ttdJk5ayUOdmPkBP6g6Khn0ih03x9SYksIRxODsA8RZGILgcxns4i4DXHiiLQn3SaHwWatVsdVYU aw3eYYTMpKxYLXIOj/nCIond0z2kirOgPEurzjuyBhrnf0FNdm+NKM7pGWlVilIPkbI2FOp+fEd+ TFB6JDlBac9b69j3BnMyYfBrSDGGIAHApdQBLO7aNEaG7LeOjWqPkiptiiaXWElgiWGwLoJ9ILU4 M4vQiCzpwmNH9ZFvkzxPy0wpqGeOAajV1hlUGZfOkSl4rytRFPDMsSq70nwNrRUGjjB7QXGZiW1o OwgEA4wbXDqz0ucftnpwwB0dAHCAtEqBVasZ59rYX+Milc/leHML8RoRnbyGYz9EUUCz45r5GLCs b9C3PsD5udAN/u74YidYbxngGghLgAtjNoEoGBV4CYWVSh3GJcRZpR9mavuwihGpbxM1sJAyn4gc 8LkmMue60eO05DWjmWL8hLBBests1aAtprbhkR+S/kmWtYkq1Yr1pXNio0DJMtffa7LcsEr/rI+v xVpl6o4OP8UYeAlXTGcQZERDnr3NDFt4cnL6hxfb026gqJuqMkqwX/mUKN0u8We/79ao3mlz46sp TrK+2rXLakiLPLIhCfyNisyRMYxOjPUzi4a/JXmbikxQd398q25lxVvRhumfdGaPVCxGXTEv6tYL OIb2f1t2nYigF1wi4bUnioCyymWE2w+1zwzIaz1C6UCZh6d2rxRqmTYCpQ+IGFtbEWvRCO1A+Cpe O/e0Fm1dYiNVNpJqfWSxEKVwhej6T3uab5mVM+Ysgf+RhARMBqOsVlR8PHygFZVBWU36g5qBDxsH 5OK4t+RkPplJgtkgzqSjo63VSD+oVIAiRCVy14eD/idJF7l+opYggy4HtRCxC43BhZNV7tkJ4Juw eZQa1WHtXJhoYKw+9Zwbzzqlz99gwKRwdcuQi/HhYTCUvkcHWC57RaTXc9w78X5pfkhDhwOJiHA/ bBA8GHS69QkG9F+8m7zSyZuY2BeQv5lILwyewPStZ0t37xzbxX5YbMUZZiOb+KAsubEPzzAGmJUo 1JVBYezFABpN2QBnu/M4HDTjv7STF2RIDumyT1p9ike9/zxGDyul/3MZEz3cJ10+BeIhjmjSjIUy kIvDiMBj5K5STroybH3FMLjvdjL5O+QP711FMpUyMc9JOm6vDYYr6OkGY0JGvh4QoriA5WGqGfaO sp5NAJ5PgNmZuGTdJFOhDwstgYs+RLgu2BqiI0JxU+7jDA6GsiCzED81lngZ6YGqLNMybzQb3RIk o4ueHpqb5psJhoTzxm2Rl4wiOWh2kUtNM960l1PqDMRLYkFSY9HK9u9khMbhkcTEgoSp5cjc1iSX xxiCniqNy2UyhgwC90Amm7FKMRJM2ELLMT0yXCRl2GIP8cahuCvAcNgQPai0kvIQnYWsM5OFJLTx QhwdfyIroBKp+vRnkkF31Kg2CKIzkWuq5fz8EQ6nw2igY4ozaU/tfy/Lp7qsBApD92Do4yTOY/Jf NhYx6JY6Faa4dDBba5mzi50tJZ4uJ+iPYLFb5HnE1AqESrGghW/Oe97EL9QMX5ARJCoxkJapZ4o3 wY6Q0A2EM+iIMeXSiR+pbiHBfi1RrAWmpZtL6AVR+rA8h/OHQF2F5ZyGHVFiIbQZZq2DXHYdA7kW TOq93iPeDtcD2e2M2alGQl1UZ2lWNYfRRV9bj+faW/UkIBdUUStKiuertpCw8YULvvk0kxmZc8Ne IwOWYWGYDwmiPGBhMH8luZQOxtQI9NK6xYIN0tP0lZ7X8y4obgIxuFZ96e5mtORHNjuI4qV3DEcs 8z5d24dY5TvRpHWTVUwxPo6SExai6a6riTnb/5CYnoCJZiq9xlPZW3/d9gVEbVs2/h690stg6AKX M5AYqaGtZUIM9LeuTPo4RPJW/08FYtjN5lIvN0wpMowF9VHnTAhm6Kw5N+v9ahthLEso1GSPrZQ+ w7myqKKqBbBJkANqcew4B0vk9+4p06j6cQxbF0qETDHATM/FbDdP2AI7n5HbfgDO9mLfhQFXWHvG ZJ2c/VmaUGVhYIyBtJF0BNLW9nWdhw4YeaCKwV9NC/rCh8F1r8zHZ9DHST0bU/8VFh3OoY0uFPBE 15IE93hASD82IBNviDMa75kDxIE/piA62Hh4hfRBoGRvvxzy2RQQp1+cmhlTocYYgTn1k57rgzVK dyhgqE+hq1rZTV6K8KuKxr41a5qUapxJrjJ1Di49tbtWWFDWBXy1/SgBKug+r7Ce3bDDBBLzrOUK WHAO9QY+MnFPu/9wWxzFYmqtAhHunE810cEbiZloIRRfxqpie8UYwF9vjs0XoMSn5ki148rY2gGi aDDwiNLkE2YO2i9Rlh0ojiQLoVQZhFgqj8fwj6UJpRRT9k82RaTHFfq5Sk1m2qd2gpcB6wQ3Jthg 5LA3YvowKg6Um2CNBga+T2SqCFaXYD89T258mT+6H4UtE2IWPbWiTWuz6fPnUQakvdFAHbJvE89K DxcQnaQO2YBLOAK/R1Va1NUHNFvjhUiZgsle4Ju6O2BXa5uwKFcxOYRLX1gr4bl1Wv+SlGlbdpX7 X9sf0qom+kw7BrhCKcxh74ABxKlcEkI0YDDum4ABTgQQyfhxdP5ryQo056OQFAK3ZcG8Goo44cBr vGs1HX2FC+uCoYNQzXDYUMXaOBSfhT4xFshw3gO05iHE7C1UnTssG5M8ZEIwwVJGgGADNxZNdeRu I/PZ+ebeZrSkas2zvWAJ8uxm/TqiENnCcRLgPFWTpiOsamDxKi3qP4gXCIN90BklJfvYUMVC+sLM dUz8xHqDmFU+rq24RiMG1mLK8EeToy6UEI63PymPqGlMbgQHhx5IF62l5Sz/T3MUtHwLRIy8si7b 4DMQishd4JoQwsKrqtSmum1d4Y0VKV/BT7McRDMH+xvma7tWZKXte5xLFioxpKX2gSz+cW8vGZqz iQoYyrjKVOEnuXVH38IwFkPXLTAPaEdjVNnN2ENfCy6r4bgrGlj9VPRM7yHsrJvYRH6iYXXXoL97 XkhHGkPluH9ThBaDL4CBukgZElDtFCAp3B5AVYkgrW1YCar9Z2JBVUyKWINSurBf6wEkjtN6Tuyk u+kmryqOdT+anjhy1RsmwLJsVyQfrrVoI+QIBule+ZvwVKPtk2N6X0dqwTtbbhkqcaYqHWNpBrop FpUZY90Hm9sZHQd7+Nyx8xd2YpLwGYBJYUpbeQf/QLYZAyOi89nBghYx+mCCtmlZ+A2ogONNNidU eufmm0B+Dwupc6GKXxmEEicwCu71Bdj8fv9TK1EX5ukay9ZInCNrNCYTsYc/Gbq1yQVd88V5Dcmy NiXzEjaXMDDgsXkoaMNBLnf9oUXfddcfwtrh+QRiLdQroBcRXVQRtCHRLarzbRPEifdvYskbpUDa 6jAh+m8sM8Gqq5D4wEBI4J5nEOdDkkWW9hTGQ8OVF1Cs7qjuCdy+u7Du2bKE9lFgxhZai3NdcFPB O8it4MzlvnooqS/XRl7WVl50/lBNbTMGGCw54Xgs3IPn3yLGLXdalNNrGzckQq26rHU0jyHgPbO8 S8R9kUbS8nCiU25E2Hfu6itSr5GSqY581eiyjP6CGlX7s0/eFisGTkhmMuomMWzsmhFRXYZjnQSu 12PLA8EIxgRzcNxrIQ9nE8l9AdRkKBlJDjrHRgVqlJa0pcx1cXULbgZvGsWknlQzrLvP06keCBRH MrtfX88XLmmf9LBr4KC3c5G2XJqSpKFfej42hzJQm0CbQzn9Kb8TZtK1eAxTPCTIV9YqxiJADAPG G44L3cQ3NYJLgWC6MEZJHq0vy61agJXHUIwsM+gaHlGVJIobDFs/dNBsUWI5VJMe2ZLhCSyqChhJ R6TuWIFPpvXQ/PWFz7a3gmuT/hxDzPxl8rzPvDr3s6iucNE1vUxYFNXmxSxCox7vMQ4wojzeovGb LOjKYi4Q9j2VJQ2i+6PqQkCbRHpR+iluJ53KD2aDRiI/YOws7M3BVDEdTCzGY6AVkfm5ivmZKxvh HXYHuJo9AN6T8MhPdrrgUdL3cIMMHsGlkePN7Xck1AWhgVglMX8/7BD370XVR+u1nqNKrGXuWHzd mo244wYG4MTBqrI9AAqGOHBDGXE+dglXm8UVyAJECUfSY9pyAlZojP0/FZlfGAaEsUjHgjHmB6yP 59J+rjbwy4TpeSm7RpRpkeU5iVo/x4kB7g4DTngAE/o9JT44r/+7jaSjZBGm0bI5/ZdcmKq5RShM jEb7pxnID+nYvYlbanXX5Kko3Eqrz/ledkmevdRGdx87uVjfTyK3JjjY74J+5Bnun4BJDc7amI/Z 5TXLxIfpi1rExaFWvj0QjElpWgNM/xUlacq1/nx68nf1738T5lZAZW5kc3RyZWFtCmVuZG9iagoz NiAwIG9iago0MDgyCmVuZG9iagozOSAwIG9iago8PC9MZW5ndGggNDAgMCBSL0ZpbHRlciAvRmxh dGVEZWNvZGU+PgpzdHJlYW0KeJzVXdlyHLcVfedXjN9mUpxO74teUnacUuKKqxyFVXmQ88BFFGlR JM2Icvwb2b436AWN041zAfTMSKSsclXXNBrLxb3nrgB/XsVRkq7i9p9+OH9/FK9eqv/fHv18VEdZ +1/3Ap/P36++OTn67atqpb46uTyKo6ap46Z7l6ySuF5VcROpV++P1v/dnPykmtZD0zxK4zrOVcOT i6P1qn+p+0myqE7L4eXr9bebOCrTtEir9ZtNFiVFVTfr0/HpZrNNoyIr6mL91SaNsrKJM9Xj30++ O9pmZRSXdbPatl32vf247hrVebq+3WzVlIsqTuv1HTx/GHpscMB/bLZJVOVlofpWTfOqViuAX/U0 snJ9bR4v+m7LPMG+sIcEWjTw/ONmmGc5LKZfwp+PTn7zev2nTaJe1lU5WQPM+2GzraKyiKtUU6op 1ttx5aeeZalpJ6rbqihh1vcwO1itolza7nxerX/dpE2UxMn6/aaleJGkCXx/C99/MJs2rK6O4izP zU7twzFfG455GFmCk/+XzbaJsqYsE6EB7uAdPN/Snf2dWngZ1bVhwYMu7PebrWpeJ3W5voLxzSKB 9czOvjA/TpdO5Aob4BCGYz56WfqU/npveMo0+GCmhqPhd5fj4u4mS+4YPMmyYR1JFufQcU+Syuxf rZ4lVvvfdEcUaCRJXgs7kkZxmukNwYme+XbklIoCdvFRYDbAuEeBB4GSZlfeAD16QEiQzy/saTR5 lui+yqKezAKbANFHUl+bz6AHi0e67y0e6X41PAt9KTDJorzJGADJA7zqRSVTVIVHbHFOlImZwJsR NkVB3p1tAKBwD8l+dGwhSAmH1oAPgSfxy7ebRqnLVOkMrhVgz2F7bujjqpP2vFFIZbqVmOnSCPOd JURVvVjCt0Wu1JCyUg4Cuq8M6HIJBm356yZRi62TRgJdSZ0s0kkSBnBrw2CR2dYPPlSCNQnIwDlR aGwaGKm7ElZBgG9AIj2jt4zgHF084jW03iqdXSZpYZiKr+jctBxmmTVVYhDqsmO/tFSd5InmH8rS QBsz2TO+cj4XLo3CBuGHvHXUtajjejTJtmmeR1lcHQTx/rrZFlFcJU2O6OOC9qkmQ/Y3v/6T2RS7 dWoh/0R9jn1ayGgrTI12wmZRdngHP0bDrPKs+RTG8TebIqqySvkLOxopyKWIRB8sxJsv/cphAg5K g4jwmYANZOx5J5KKV1tYFoQTyIQpoI7qivfwtelh4PtY5gdOcFhQAMtxQafWlNHGt06Iz5N2+R2c KW2ax6XmH75kytV0WPhxymFpEfewM4wHTvtBVTD4PVfMzyV8P8dNbPKTW8vBPl3zLZPGwzbnpOdH RnLOLGBgPYxhBex/xDe/Fr3jXCqJyjAv7Bc8wfG90CungWAhrEZ2LfORXYVdCxAfCGJwK+NsWIfm 7jYGM+icui6z9TG0nbJ3Oz9gb69974tiULcfG0gb6EYt1WCrN+gHA2TQ8KT9PinLTHHWH83P0WTl k2ftFQwhrLJBHKKI5Yyhhe0UB+Rj38ywC9TQEjUB1f0Gl9Bisn96SqN4Xg8sXkSptrteC6GoY2EP zAAzRjDrT9MWgBO2/o6xb+H5Dp4n6zf83k8W+H2KwCTGZJsSYX4wNvYrYaQbgulI7TM6CMU0uoOu LRhMkJA90D8ya0ZSHqYFik9AwGeJjXZJFD3RRMLXXvOkY/VctS8azerWlFozhSpCs1/Es8nyOirL 8jnnBVJoEcOzlRdo8wF9iiRpkpGW7STNJCyjoVuPeW9txRDYd9ko3SyxzSVkX0wL7vhNrNDwuJQ0 9Me5HdckCShNLUNVpsG9TpUfNNqULw0eDWoumwkIIAjbesrKEv1046z6FO7ddxxbpGBLkI0cjtBe Q+SREKIQRCAoQDv7ZpItsKzMZd7RnC8HG9JEoZinP2NLkHI7yCQoEK126gondG+L4FyZLGDNHlvT KMlTY0boocYs1tSOwedveUADqfYvEusSlM5IEc4eQgfUeRCiAkR9u1cJ4ZdtWiojt6qeMP4yFdM0 VsauoosxdiUKTNNyMw6U/YlJtGz8iklhCGRr7H1gshm+X367isZMHbMOEmg0Av1xZR6VveCLRGg9 NnbeiknnIP5dvNksDvd9UXpsiS157xevRTkCEkw1L2Hmllan9haiZ2sNonMCXshATbD4vlc9pVGV Kq9xMLcVjw4ObVWoQb9vO1WWUjM1PJAcSH8qFKAnA0yrCIZZCc9gUNEIDpfoe7oTO7PPONqpAVHu ei+JdC6MbwbaEpNYTZ89mi+6kyrWxTl01qd2SuU4NCy1ExA2PGNY49Lr8+nsaXEWXH1OrDolEkVR jGZfJ0bdBMp4jB52pssoWQNJ/PEsf2oBPjTKgn9m1iTJo+lBMFZDHBxvyOGaTVlKLI2qdO+NdETY 5tbLQd2Lv7WR5DqpyspKxbcLZ4ZFgLtxJWwhuCHYHNAHBjFVaDMc2g0AtSD46lc8KWMGUtkyl2Ji KI+B/P3EQjbL3TD4SLyqSXxTxyfzeoxPcsUQgp1eU4IFnp4H+JqQdh2pkcpc+xtV1TCJncepXxiL ZhpLbQkLWDvKAjdFAqCPx20WxVrRRqZRHvACzI+PTGZdpUcdEED/N/QRCeopt3ExGY1+fqWZzH74 nCgM+VBcFW5DANIyAA8oQZPKlszOgafJwVhkrmAPFVI+rtHmtt+SYsRb9pm/ePISohLOAJTAd1Iu yJPAIfb/xQDGsXIXahNB9xjsYn7I7WZ7Cxb2yUiEE4cniYFbiJszclln4uqaohqdSm0Yq/ddkXvc ++kGl3saAy67c4Qdkvm8vU+FHi9Z4TfXCOYpCE+I+O4BKH6OoVXNTE9LIehbmxumbO3obO7e+u2/ 0FpNKXu2rKyRJ/WIuUr9Px2EKqOs0IxDbQ2+ECCm21WZVhyWeZTVxbMJtIL9MZbk+s7OMMeVpkVs VVJXUyAIcVB5flEyALUR5liEG0b7/SfKJiCks4fF7+NaNhxyq+b+KbP26jGNknQMs97wviQ7kldj 7UaeZdL971FhmR2U3OhZ0Nb2bIdB5jHTgTSg1SQ6/MIPNMx8BFq0rVmSF4ZTGWIV7f+Z5fs/v1oF o/xxwmZMi1Evidq/yw8SaIoGpYd0Y9hBZ5zWXZPjtrMF4ZZmhw6FTzQ4jNlGzYHiA8tSj/OwXx5r jZcWSVSaowLBZT8PWNC5TdRzFUvuj78Cktgft1QGZ2d91HOVN8uGnSE0q9sz+NMTR7CqLd+j5UFg Yx4LfmfPJdQe3fU8pP8UFrck7ukCZpWyNpjvWnscng//gmFTMAo7KuYS0BwLGmVhlQxN27M8+E6B 5mViTk4wUJfDH+8IkHOv125zulUSrosBK/scwvloCnGGd9aSOVwl/0mHpfXvvbNDLVdWDYPxPGfe mxBfaw97irOUHubIW/IC2iJP4hZd+JjdqkK2RMdzosBtZXjwllQa3M+GaDVXRk4PzuIOkLDZGpG5 dy1/zgtPlag7TB2gyV4IhT5G2Uz2wi63DLFd7eoxR/Z2aWBljBQdPLQis+PiMoXgA2svuA85VDFP kvpDxbAdfdamw0MPrlmh1DBUWo9KdaDIrEjik+UX7Z5mByicZufCQ+oY7XcBkrwKchip5dqPPrAd yA1w67f3yAHhKdwOgJcq0bPNOSumxAsWBh5qf8bxBjay6ql15dTBBXyIuVW1lOt2Vw61l2UconKI KeZnkHvXJYLKmyRH3UC6x0t5JnfTOBVRW+9aYTrjicOwO2sTTa4AXts7+iF5jV8Cr41QvwiIDYdp IA449ycWjvc6qFG8MuYq5xXkfTEExfpD1xbu4Otj13Um9sztE6H6cnK5FomQDPTitXefoYQOwWPr qyMRYjO8hiCQKWdoorkylyoPhKN3QHIhirdzmaU3T7HImGQxUbn0d97/5FalXuCqKC9y26de4LZY RUn7aAuobt7/pH/4TRVPUH3qZ3V3oR2B34UhFRahpsFDibHHr0xUxcrXzEMT3lM9QfEVHQ3KstFh gZjW0F3ZKBPwo8ADN3x6JHTDbyLhzgU/6n2NpHYnXpcUo+F3ODWevrDcyCLPIXRGtqDzXSBtgnGi lvCgdQCC/TORrKMdQ0z2iflpOktK0YADJRWpUB9LMgdGaQgp/1gmns7QPg/RPlXc6ZBVF2EhHhL8 X3bRGd167xkGaCAFOaeb7Ay5eysF9ohnM8zy2Sq+93IQWmutcxtJMU7RI3gSzS4W6rBIIAHNQ4r+ gKfMUfYB7HsLrUxjnc3B15069uh6hNaOIkLFhdNdGHxQ2ziCIQlAPGWZxMLaZX8eFRnnHaW/ZIGF RCKX+hpwyyfcYQ16WOBdj8KaHyiVjCekaPglVQv9ZN89rgdysnq0aKI6G/N/3OteZDQdhuaeU8f+ mIGhFo7M66EAn+wIvXXmtScYoInEHzhJ4ZyqcJAJGd5ja88llN1v5TS2i+lBjyWyKJkS9o2eFj2I S/C8TK7nUXgmGOThdxXwbIQ/KQLXyfEzUF674ZTqVeE84LLTbN4yqQCMle5W1DPy3q0ISKELKeqo Kgo77CNh3G5XbZgtCLhRBM6+eSpd9r+BcGkFRgesyNYGYntCLjn8LMSD2GksXt+wsHbCl4CY7bn2 oE0DuGWXOuBmviFVg245Mgls4GUs3ezwpKrC7z5x1m9bOSIrX6K1rR7PMhWcZ7yE2wFvWfpOykbT M1ZLLhTmBQB0f/yHvwLwil+bxy0eCmPzk3edU4g16rKmxfs+KlSwryF7KCT2PMcPaVDBCZ27Xjc7 PeTObxOZ39hq3Zg1Nw6tbdr7PttDKgiP7dQ9n7TPw2WjQlhDcgCFdSOwGEHvZTOLinrUkNqxnkX0 pqU75KKkz3EfVjgiLoMo6nTYtO4EEhK05LIQbHk6vr7BpK6R257un6zmW4rVBZ+qlSw9Wv8WeM3S /O48AMDdxDF4Nf5IoT/ayG/IIn+W4wv4c1x47Sb+aS567eYPJln5MC7DCtJ1i+B4Lzhm0o0gdh0M O57KfUDr1sk/nBz9Rf37P5ZWzLFlbmRzdHJlYW0KZW5kb2JqCjQwIDAgb2JqCjM3NjQKZW5kb2Jq CjQzIDAgb2JqCjw8L0xlbmd0aCA0NCAwIFIvRmlsdGVyIC9GbGF0ZURlY29kZT4+CnN0cmVhbQp4 nNVd247dthV9n68Y5KXnFDmy7pSCokHitnbioHHSAYoiKQp7xuNJPI6vYycf0B9I23xvqQvJRXFt UTpzZpAkCCDMkShqc1/WXnuTeXWcJll+nHb/movT50fp8T3939OjV0dNUnT/9D/g9enz409Pju58 rY71UyfnR2nStk3a9r9lx1naHKu0TfRPz482/9uefK9vbcZbyyRPm7TUN56cHW2Ohx/NOFmRNHk9 /vjN5g/bPGlz1dabR9siySrVtJsftjv9tqouM7V5Adf673k3jVJtftpmbZI2Wbt5vt0VSdkW3p1X cP1mu8sSVdbV5o/2Xcfd76Vq9Dw3r7c7ldRVmmWbJ3YKL4UpvNZDFHWbFpu3ejJJVVRFDW/Acc/t re4hPVSmx1JV7eY9PtOWReb+6GbiBndXTlRPYW7uGRxymIZqxlnoC/weOovP9Yv0m2o9SzemHcde 4CP3t7s2KVrVFDC5R9tdnTR1ltu5l2m1SeCxY/9ay6Zsm3rz2fafJ58f5XWuVSU3moJagc89djJ9 utVKUecq99YPbx5XrfHV5Qyu9aQzPWutv6BkHwpzRj17SXVufGFdWUXLClxekJFdi0Cf+nedds/U aTFKuL8aZdI0dbeCeZV2ctsZwe06WxuE5xblTPhuVN2XVOO5dTyhZntGhYHvAFNwloI3aHHkhRZd VsBC4A2fbNOkzvMqV5u/bXdVkqqsLb07cEZXTOsf0w95zTT824356/v+vVmhNeQ7t7qw0BeC8oWO ZPKOVSNL/g5un7gWrQ5V2qpQnP0N/qIOBlgnbWbsz87YSg/myLwU/Dzx4vb62y0TA48ERFnRpOfE 84Y5NLSX/jvBXG7DAAIf0YUS6n3wqfdO6S+cBfE54HOLPVU3C8FTmSsaNEKRTUIN3gBez/lsWEgW /uQ1D6WwxEf7Tt886U3CTnKMWU1ZdGN3SpM1SVqUpVOazS8+CKoTjSjKRgBBeZLmhbEsiLcosAvB aD5yC8X16YUVKcET+Mh3biR7J4ro0v3+JFx9rnQgQCrV77YqKZu8qkSnwJf8TLBtvOeSexxJC6Xh n3BtMH885Z8VdXZSKJDugSHHOKUBVqYNpvfNlUpy55ylz3oUMaT3Dre5DwQxXvJgEhvWjRWgszS3 +KKHLT60si55/Dzwyb7ns18LOuwWhkRggymmusuDDXfZvo+LpA3xuPCEgrKJQmtXUVWVEhX6WdRy LqmWPqMT4Yt8DRsLPeeuKpNMg1dwnbeQPzaquaH88cBKgUN7K2CSIxpoYWHfxeMaW9dPHPYc0XSq A8gCoMWH+4He4Wl8GLYlM5jg+CCFjsL43mOqLMmLxigOLjdNablzn83QDwJi7bRjnukSI62FKuNI Fq/2eSJ5VZmVRgbT9HEUFPjeMXnI8kyApS8F48GVATRBnfYt5naYa4JnCkHdNTzTmDB2r/p0WyWq UHkDrwcR8IU2Jq+KaAqyjqEyowb+PYCRdO1IrjlZ0iXg5i0PI3gLifJ+qikBKkijpdc7rZMme0qc ljVNtk4NLuRjYXXERL33UGWpAVJtFOgKQJ+AsO2EeMCCO0EmlIbgGRVnCmAxhHlxkZlRnZg8eGn9 zygG8D88moD2ATjkxsBhkpBKcWnyHIpTBWANs/HYT63AOEMHOA3H+64CmYwP+A3i5Iu/wHA9CsiM 5vJ8ySZXsV8SI/t2sKRCZzVKGUsK4AqSpzPTZ5YGU5OSriX+z63Nj84w+GePJFmdZiZO5apKytKz kDHaNKWVr+oyrRdwbVSuVXPgZRIEeNDmWQyOkMMdeD1+TFPWhkjpP+GLo5Pff7N56EL9a/s50U8I 8vHJZHEJnBbiZL90xgZD+FpjAVaIICaABYbwODXiGzBMCHE1XKpCiRzUNeDKXhhF8J9fb3f61U3W +GiBA33jI0rkAqPyRsl59TWWKLhxL7iQIYZLdGE8M5YQWdxRIxT9RXhnFAFF0zPrwmLpPs2TQUTv R7SiEtVaEnOOuV4aOKIc8nI+br8vo/lyJAoAwyWgu2gedgF5WLS4N4odfD9Plv4FkwHHCjefdHdk tar01O8Pf07b6gYIbvAHYlocQs4F4IwnxleeGhFGZlKHnPAA4GrE3DyKt2lVX6o5U+pVQhSUrBCM JOIIuJFEVN943sYyKyRv/pXoSjxDkKD8tHwoFDenQRz8AqddOasUI5OoY2QPRWsy3az0tSpbwuTM lbcOAi242QhYbb4Hxm/hCUQCeYxQhorWa9y7BCZCggeuVYAGsbkoMUe3s5oFT2sDkH1YZguCDCwd T/BoxnsVqLPPbUFEpnnSS74ehDndq0LX20GU/tVCyZSyOVmrQ6nCppvrSPiec1ZOADxS8eaZ2Bd2 93zP0D06M0A2jED1fa4hLvblOpHYDd/KU4coEJaAJrbNSfc8plp8Sk1v5euB0aEOACkjyIQeOIIE WYyhHFwmdWmpQxj1Z2MUa8oUPjUUxAva4xPnZSlyAdYHiEdqwZOSkKQlVVkaLemx86yWzJRBRpEC 0OYlBU6cRD0jrYWRcmmhwVPdtL8VsqeA6yAOdSTPX7ZlohOwrAWOh03xAr7GrHbNb71ZZgTCHeVl 3lH5OD8YoPvucbhEE8GxBFgUbf/hLBh/N45wwJpIvKQrJClRu6cNK0v6hHB61icKL+Ezeid0mjny YKBFqqRoWqM847B121To6qJsiUAaxVkojlpjNZ+9Ct/40LlrGQQYFvY271uTHqUKTpCzfnE152VP kUOc52Q5ORkWQDxyExfUN/KQsMRh/ZYdokCJgWG16Ad/JYm56GvMCLKr6YQtYUeQJo/6mClb5XTv ChMTx/VVTe9aaXXMuAD+WbS3cn47BsVVThIfu9XHr8Prf0zAIi8hHJS6YSHvEROz5JfXGIPk52No R9pcJDhDJn2vF9b0xaxMAWL1eGPrwLIdtG8OSl48cHN/5hVV3GNYuAnFv1eXSP9i6KHZD4XhYA8G 6FDXSAULNFkka/rYaTVc8t0MNutZ0DkpoSUe6v8zV9phAXkGZptXGk/20whmGv1ACT1zrNSBfLJ5 3v4Nfd6z0NY7afyXft0CBBTd+iXtNRtjWZFKXXZnWCgyI4+xbIj2DpkMIgJkIgB3TihI3YGhi++V GK+xfjPbkTlLCfG7hTo4pfPwOaDZ+Te+ZZFtpfNcshdASDCihEX0huvH+Dqp8jqz5GmHet+MLE6m 19NYWzyJ2o9epuWfPSmpIeTXabW5457abz/LEHnbZGh4wzSATlgon2J+4ZicXqzRiukdp9J/dTdA pLw7uI08z28AX98qeuI2vWTXA0uTSJevrz10xxiA6VUUwHUbHda4gFn2o60kzya04/P5LHB4HhM/ BOY6KarMNV+E/PQ1unClaVAyl7oLfKHcqjddx96CPa/olsfF2+HLwZpvKBXoEr6bgN7gfITseN8P EoL2XFY8oUROI4oU2yZIXyXtxto3ROO1C0AfcW+xhyynTkCkIlencAflpYGQkZyxoF8SMwjgbYk6 QtXPsSESFOH6JhBs3K9PnK0JHrBSpxA5SRSJ+t+oGi4gXmAjlaCSfskrGvhcSpa32g1lcyJ2LXrd KwpVeSh8wJhNUqiCVApvAIRHTXm+ZB9tiWD8dNxwvQU36IhOdeasEnv9VbDeXehC9DkIHALWSvsD w5Bal1bUHaVsMh6WbnhTVlcm3JEGyzCQ3JRHdZtJFzRg2L5C3oFx340w2yw4R4XxDae8gAEQkYN0 7wiYkGZnWUCsnzF2ShE55GFvCOyloqwtZZfpBVEaCPBY5DUM2IkFb+hTx0umfOZMlEwv66S6t6qi 2fhZkCevsKQT7tzT3v2DbiTVFHVJJeuzO5NG+nW+dnoSSC+e8Egp91tgrMHZRL38wBm+EnwGq/uA c1uBhSWnGQUcvEAY34NJvbEwIeHjpidn6bE+2KokL6qVdBXdQ+60JnLUi+AB/uRi3pfRfeOxzmJK ctw0eP57991Npmq0ULcWbLVXnsFCoh8PJXEyVsAI4oEVBpXPbdveg0AMPQlf5iUb3iNnR3FHEDts ZJLQs1rFoPnVhI6USY7wHCzZ54dRaWbz6NK4Z5WHN/1G3XbsaKN5ZN1ZwBRZd/AW2Ffn+0Et5KO1 BKfLMYsAiIOdq35nqRtryjtOnp5R1HDr/Z59IT/bKxrKJz0dZlVodwE/7DFaUKFGzs/44SWHJVmQ 63kHy6YNn4KR4jkQwxbeOlGFRVrBt/caF/3222rIQHFJfCd+AjlMjVsySOgdACpidLz6DKY4ChRs EYIg81lCkOPoBe8gxL/AF8LnOZUHO+DxkJ5LFjbqcU+8RJvHympdaAGvqTGE+wgjtQiy+kIeIbUJ rC2imimSuOJ3gA+RT9+dKWeEi9O4KJNGOp1z1SRldaAtFIfczwzPecl+nmpwVUsZp8R+cp90xQ1E CEtuGkIj8ZKuEqHOdc4c4UGQHu8kj9fQzllyz2cEwWzFeSRDwGmSvK0IMcp7Vv3zLCPW6/Reig6L tWIqSE4mgPQ8GjByBosbau9TbqdxtI9XV3BNsSPGqWEdIE5F/D3ZieOf9hc5diXiIIQ+4gUEA9dx 2k0nbIPDInyYXkiH7lFEt6ACIRm8QCjt3eXPJ8XzYJjqxKuY+s/4XN82MiZslX5GtdC2RmcXxdPx euASMHHXNZuFGY9EdQulo5Xdqx7LQgz+GSt/4LkD7sxOLGgM0qXHi684+GpqUC5iA/v+kBcaZg/v 9c33Q3hMsF9q66RZca61JjxVbfUZYG7doD/xoSPVHri9L59t8zwp09rXNFEq4VboeEEtzjKAYsOE v9BSaarcKnN45v9gonVS4y4Zg0tdQZ8ZyCxsm0pxdrf5qOlim9TYXWA/657zQw+j52MuOhnLBEFn Y2h57hyQS6wqDhbY5omqfjNbAku4vu0tgf53QT/5Xd49QcBo98G/02tUqzIvsXgWnmV1M6cmLNx9 HEElYerAMAfv2qG7bWPCXpwmyPsXgR6gmEbqaxN3So0dFG9ch+q/u/e2WaFu5qwEUDNOd9KOKSEP 3asT08e6lBGNNogdoBuchxBxp2Uk9EhnF7IwED3on0fFBfsPsHYLAjY1Fz51Aaib3aP6kdRqj/t/ vsTEsCQT59Wpa3/QeUhxgXBnD2U3AvGzINWExHC3qZ9VmXmL6CBEClBR/PEmxlighIAiFYPjO1KF /1NUSEIfuh7NzpaH0pHjWnSkG9pdalON/fPJ0Vf63/8D1ad4PmVuZHN0cmVhbQplbmRvYmoKNDQg MCBvYmoKMzkxNAplbmRvYmoKNDcgMCBvYmoKPDwvTGVuZ3RoIDQ4IDAgUi9GaWx0ZXIgL0ZsYXRl RGVjb2RlPj4Kc3RyZWFtCnic5V3Zch1HGb7XU4grzqGiyeyLiyIV45ACQgCjKi5iLizJshTvtmzj B+AFAuR56Vl6+uvu75/uGR2bUMSVqq6jXv/+96Xn1XGaZPlx2v/TjfNnR+nx1+r/x0evjtqk6P8b /oDt82fHd0+PPr/fHKtRp5dHadJ1bdoNf8uOs7I8btIuUX96drT7cX/6veraTl3rJM2yslUdTy+O dsfjH/U8WZ6keTH+7bvdr/cnZZK3WVvvHu6LJKuatts935+o1aq6zBo1WrXLps3Tdvd+nyZ1nld5 s3s0d8YOVzDQTPcOfrXGZWpg1xTQFSd7ozokTVlXMOjlMKhrKtzu632eFHXTwk83+5M8qYq6asmK 6qzn+5M6aessr3YvYHfP9ieF6lCYxlv4K4Ll2ixwPi9A14eeL4TJplN3ZZGZlc2+zQIcvsK+DPym OXMFalzqUsMN9zUD83j/t9PfHeW1wslqRhczJwWbhxXDOtj1DNrfs0s6ZzA0y36hWurmmqabNniS t3VStM3xSVYk7YDw26nhvqEGadN3xl2pfVnIemN+vqLoPsK1SwmQhgmuzQTmtNiBE8lL7+r6JXDz Nxz/DJzx16ems40pJ01SV1lRSLhi+s4/PmI3Of/1ml3+O47Jzw3VP953SVrnTW6tOXGxQgFEXWFW JkWa57tv9lmnUCXrfIgOo+wVkBo1myBneTiSRZkmjcYaH2h111YCDyC08hnsCfeHaPeW3yh2H7lz VqSlQIeEY/KO0wI9Jr1WwFBX36TV7kMPzlT10Mcps3K+mna6mTTvN5VX6UibA5hmyvwOyeSFDXKC 54gNL3zM6Ce5ECaBLrDkz4Zjt2WteUfWJmmhJOkheAdI0itKlJTCBXZyz0hazueBJMZ7aTNBpJq1 nsB4ThGAQuoMea9ylI29gIskPRbCMMD0G9p0OaLDPZgwlUQlZ2EbZfisD4SVCGQgCgeqqqLifGAC +PujSaKqP2Yz8yBEaXPTmfM+IqAR+HUU66kqTQaF4phVngEZ/NsmA4XYaZuWAhmoQXld6gPd3VdJ UzR5y1GfX6tABjDucp4MO2QwRyHwAi4WHYY63GNZUYEdksfTHSlOIcj2kLbpC3FHKZt7UvXOLIrs 8B/937tMSUULNQRyJ2hIUY9cmot8sMdLhtJvRjKo1NpNp7EmoE5KmnNY4YQz4kDO/wLoZOs3C9hk 2MZ88fMwvvKNEamT9GjbupgmUG2QviBeJxiCgOU8Ebc3sYxKMSdJen5vyO4thdkNJ9cbPs5QkmRY BrXnGSVwFJ7QsAfTSqa+ZdHJAv8WnI7Cgyuz5lfDHh3D2bdrOd95ytYyhxauJqBLut35LXDr3Gz4 2vBRgloDni9O7DKlAAr3FCatcxZch9vSyIqxfb1M1GH+p62GtJt5HjCKaTNF12RMQwpCSkAabcd4 tqM/fjCrFeaHtT1HcddrPKYQF2wV/+gLN/XEZoja/qcccYIw5Yii98Q3LjnOX/gIYWvzQE1U+Ymg Qi7McReXRt1g107neo1MUd+YpBbcN9Z0wAviXmvAESQgEbYdW1hv9bf7PE/KtLY3Cg6kRTnlbvNC WPz5SKWFEhJVpan0B6MG+dMNOv4Tawo+NdCaxIQiustUGDybwKEECHGiQQtk5oEvgTqfTgJAwcpQ JxHDeaUM67Y7jBg+qOHNvWzv0RyXOeVEnszceE3NF2o5vBRu0Oydezfs5WakXcvPQU83Ep6fWVPn P6nSiWQhubg+dn/bVphx9v0kjoukKGdCR5IWXIPUY/4vx5rO6ywpmgMh93aPtIRGoD8+5SOX8bYn Y4PjTzn+YfvCv6dhGcEAMBT4xLo8Ejf6MMtrSVOkCpqg1517C7ez5nZYw+GgHOsAxhqwoQ/7vEuy NMMtLLnf3akkr26YmeBs2orgGttWnTKgTj8kej3vSfTAUdufme6lP0HQnWIda+BPuZKSRa6xxuAn 2D+waQPiqVWm6Bvifgffhm5kXYleAbctuJtPstbEsKIinCrLiV+NmHAzIHzDuyotI2GCKxgJgmbP vArLIT1yoRPhaaZlZmLjDSTwcECBrCt3FHBXEG4Q/JLMqOX+skQQtYexIFbGvLZaABR/gayecArX BkKd1NlMlzwkOUxbp4ra8UgRPsMoRjPd0K3ZDBeK1MW5NY7c34W6jFrhrow6M2lOoAXS/Gt/oDZr ahl6oIRIRjN0AfoWNYw1oo3qLk/5IlFTd0lVpp3lyrvyEcHNFOiS0X0UDMZd+fsZbuG0b2d1XRQF jRptZ+9/2Z9UyhZMFYnQmNqSp7ROY4P2QNyjdl8qsqw1lXIPW9CxT+MSMSxQakOqgq/72XkRnuq3 xCznmJ5nJrpuUq4SGA/aCLZPKxzRatGSbjGdxaWaRTYkJ9VEhpsnJ8BJlyj8aSX31kqB66mlEj4H jRsWCgQO/G5ZexBcwuuYx8VEc21SF7NFHS2yvJ9kgbWQmvNKgBNsg4yiWqawPgcaegVs5G3sZJgR OP8lygpk4Y3+4hk9vTQ8m4a+MEYcroHtb1myaNi7fc9g4JemibIJfo5hxGvEGouzG/XuSkTKFWEn ntbmisVBcQRkHSPmdVKQTEwqUiVRHCE+N+V4ArtxmN9y5p6QGTTrsHBNJuo9wAHIiOyNRUZ4TJoE mYN05VlDHvZje7sP7z5mZ8+06ahcNA8s1osriYGAqJMjKKb9g0ZfgVbEZHFfWAlummUEHFQ93NDj Kf+q6PHQ8fouIeN0DMoxzughwOahElmgQn7gUJq2BVENu/hgkptyAsmdVD+cwAfkB9GRW1howiyG UCU7yvZUhkytcGaDkbn6BG0TkdtCPNT17keBxwZzdQ9BYLeIS9qJoH5qyiHC+lqqVUlXzzkRfzer vaQz0PqAsNzjgpmeTUhCD1KfnLii1/DzVgaKI/ucch20JhDhOJnACGQ5Wd1ZV4ph5pUkyoH4sdOs QAiGg6SGHqm4jmAKHpK7QtlODJ3YvJGooPKcU/7CF+N7tHQxPW1AFSMWFiVcm40Rr+FipqJL40He cAiOZpOYsbVG27NR2D7LdSItZM4LhClkVEfoze8oNLjUD0ZVKLc5pBN+4DB3jKwnulT/M2gDdhqW Zk1o344XwBRzUNoMpZwtqHpOMoYk2CmxLmVO93/nZIkc5a0PL5dH0vngmNsrAIMhOR5xkyIntv+J pfUcJh6oKyEefjLBcNAw+saw3KJXlfN0Nn/AdeUE6cFPE2ezAjcbbkNSSzeZ/tF1bsIgKf+Ic06x mFg43CgaqqRKOz+Q7lp5fWmYIHpMV0FFZV7GQxQEbwIvy2QFGuWO/xFIwL4ZppojWczEZ+TIKD6h irjSwwKFduCwBNUZml/147K6qdQ5gffcXrcDKjcX95xOJepviwkrnJSIohiNbFw3BNfst6Z5L5jM Ck0nchyv7kCQEWN9trkzOoDKpH8+wa/elYxHyXje7AQOVC6ecbbCxQ2hsyU7cTo8txPXI2KMP8Qv SbAKVBddKJJg06fuXTMngYDIygRE4JNQK8URPrqkmhaYhrKsHaTyeWz4vY2QAyOGsu5NQjRLqjKD 2J6G0iHSUXoQhxMMGE+ippbvoMfs80ZtKUMSeLCbxP+M7U1fyP4C2nqfnRRAZ4yd2ws8GI8z5NCj gvaDvVPBPh7hm6PTX8xCUJlhvp/EO86GZPIxPZRlbIIQpSq3wXOepEU3w3Qjk5D70zUkpJplzc+m UpbGrgQwWIxhBj3GMGPKgKn+RXcfTOWF4qLlSuTNbl/BTTqvtrK4T86i0z54g7OS6xPSCiDyRSqD qkzpf6YwaNlZZQAca77YMeig4USSwuQkhe0V1E6ygOb6jkt+cAZBSGnRrNRub1PepWYt2rqzPNoD sIFL82w97hNGnOZMZ2OCezh+FJVoIYYzKjtbeIJMa+8nGLcQdYgIuokn6wiTNcwPrBvRyMWTBdbZ 4GOqrprHPLbhSe4yjVE7JD70R8PKoPknY4iATRKjaIH5dMdnZS2yskdeAR4YAG3atqYcqWqStDrQ 4x7bDe01ZXHWLYiv0BzQa0toMKCJuKjwEZ9tK6Si2CjBxpID1vCMcOH3KNCLpnJudpSYSpqahEDv NSk3W8Xs7BZZ8yuLaremLoWraL0qg74OhYdRqEduAh6IwDVUtBhjqgryKkAg493XRj3HkUv1guAU n+TxIU4CFWTm5ZQhGqcNJNC5yd4fzXcJ7hdiBED1g9kb8Cb6GogBb7DKWXpHDKIVpESZ1jngKKHu FpqSTI0IDBB22rGqLz9zjP0qSRAe8lkbK1tMnTE/Wvm0upIDp3qwmxOsFepp3AGFgebFvKUswIl2 q3ZTdkGGvNIhatdFilyfhaPMiyKsvNfq4Fz5khHynPJdSyZgpnYPZWC8QpIZ58eTmwbfICL5ob6K jwGG06GDUrSa3W/2ZaI0IIcw14QawoF0oWpCygSyq8Xo46Bb68XwztAPhu1SaHMfu4j50dljQGdQ v/Ol8RWMOn/d5o1DPaMSVCrhMxshMZZF6PlG7BufH7qWbJeear1dKcQEESCwgEgK18JtNeKD+V6H SW8FA4HUAK2zwIO5VqwgiIQqxHQQ80y2N4ZrvSRd+prJuQUrWK/5SzVBlzcdtt6wCASmeRPzK+wo s3PDxSLe25ojYTtBSo0LURugPDrWLAFoZNoIPCA55qCnmp3Zx696Xp92Wdaqpr4dR67N7bvGWXD7 p0DjHrAzL4PE+nxVZxqbW5OWSJwNstiT2PjH1rRW5gfiXYznHUkwT/K6cEhw6ItEFnRYCJidp0mV Nc06l32ohnNl8kDICJtxBVIjIWGSlG/d4fQ4QpKKQHYkybu94ulI83eBgsJuXu4hO5gvza0BJnIF r43ba2QQMeKLulfYuv+VMHDt2xcmDPx/Ev51EUXd17y1SS9P61IcCuf7uRL3dVPmpXULE1ybvNz9 1KPMZhSmjs4cK1j8sEmzkTcRLsygzxKICe/y63WL+asrPb9Q+h0XcgjFRn11OPA5k8+MGLPPMdqN eaKOy4StfCA3KWbxQwG8jh52Gvxchy96aBaO9D5f1IUZq3GEB3Bs3wXnlP5wKSZlgVF/trlCX4oc 8gMS22NrX7NSex4g4K/04mR/6NdQQqLLuYQXHt2ixTQ8n1yKoUXU2MDXXcyTsKDIUu9h8MV2olot RYakRyhjTEv/RWb+vIVvvQ52rhUn1AG2PHPfsAzEtYJW73CrhRKlogs2yIrxKf0U2r8fcTXtqt3J fg5z9UcAspYGk4mqXHZk8m9G3D4/g4vU5Trk9YkRM9qCPiyg20oTRwqsRBQJG7y1w4ukvCvM/S35 Sx4nsBOpadl/BsSRzgXFWT57Wz2Uybq67Kac4cb+ggiwvhiIQs4Hykk/h8VnDIOfxjwRB/ajjsjk 5Y4+cD6dLlClAchK9UtLhhO/YvDhpFUvHEmRg9BL+g6K+Qiy8Oxv+CEElnxmpgg8n7tQKiqDxk9Z k1YMQSamoHseaENJp0U1ResXRKFPdeUXF7YDjFnuPJpLCquWv4AEaN8Tl+0mlhMvJvBQ34ycYhF4 13byLvRb0jEru3oBTXzw6rAPEUGEcYWT1AUS8r7P+Q0HPwwBDC9UIiG5TMMOcs+V4io1QNlR+Rrb tXQTrYVUae26rKv4pKy1H5GSggRrQmD8LojVuPz0dlsLNU7LochgYQv93CLbkuBfltgH8FLiH1+X GU2f4jXsZHoHr1JqDftQ0MpMly3fVGmLCN0y5srd8v7pTMAUl5BAzlGzdrSNbAIfuVidIHbG0ZWE hSKwkBu9nCUupV/Fcj7yVBfVGYLBZMlquYWY0DB5Nju0sjz3s7H5HrhlvC7r9YJd/WKowHuArE/a lJ7rgVCrXdqAPqv+yEA1wicT2KZ8WfbV6dGf1b//AHaTtAVlbmRzdHJlYW0KZW5kb2JqCjQ4IDAg b2JqCjQ0MDgKZW5kb2JqCjUxIDAgb2JqCjw8L0xlbmd0aCA1MiAwIFIvRmlsdGVyIC9GbGF0ZURl Y29kZT4+CnN0cmVhbQp4nNVd2ZLdthF9n6+Yl1TuTXwZgjtdSVxeVY4dO3Gmkgc7D7NobHmk8UjR EvsznOV7Ay4gDojTBEjdiWWrXEXxgiTQ6PV0N/T0NE1Udpp2f8zF5ZOT9PSB/v/rk6cnTZJ3//U/ 4PXlk9P3zk5+80V9qp86uz5Jk7Zt0rb/TZ2qojit0zbRPz052f13f/atHtqMQ6skVapo9MCzq5Pd 6fCjeY/KkjTLh9++3H2xPxRJ1qim2n2+T5Mqy8qs3r1rL/+xP6ikLqpSv+eQJkXdZGmzO9/niSrr pt0922dJXrVpvns43cORT/aHPCnafPddd7Mtq0LhS5/vD1lS5mVeOU9dT299tj/USVWqHD/wFN71 Aq7tiFu4O36jKpvuG0p/pNXLvYIRdjkw9ny+nrbI1e5yuvsNfcFt/4W2Lqvd13RmCbzsVLj+YzeL Os3azH3z9LpHdprXjEAegbuR3laOCzpUSVOprDQryttaOd/9+9kfTrKyTYqyMnzD14bvfdXzkMrT wqEU3yLYF2fBWcf1Rb37fq/aJG2U+wl/C8uiMCsuVDHcrFJNmtN9VqbdOg5mIQeVJ82wmFV7qudR ZXVGiZ0AC58K1+9bibOy89iKARc4Z4pmMtEzRKIlwvVvOz5KW6VAZh8x5rFX9gO4E7/Xq2qzpqN5 T/CySJTeAkvw3X9cdaXJkTZpIagr/VBWFYbvgHq4V5aSjxgl3+Za5pVVc1x5cXZ4ucT7/XMKRoAs 4xBUhxdw/a2dqn03yGhQnlGs8CMgj28Jage2eyac05BBMdeNo3ZhTi+8TdFjOSNeCBPFV+A0rhyy TwS58mdatU3Zvd6IxPejBmu6vxpOwql8tTNTnVgfZ/HYrg+WCtS644P5unGtEzlxAHyDa86v9v1j Vepun+UHmNoP+qYmlZav5ek0TZXjdKy6HKgG6tIKm7RtYNVBHnEzrZZCodAryPQSmqIBjU+dBbuW acck5Qsqw+fOwcXwXRjiP3Sf1Zur/SdtZkrXJBnjVcBjKVyXcP3J/tAm2sZqDfnrXlXWbbVrnAGT pOJGTeIUoLrLeY6SMNO0/I66DCdvZ/bSylEFAwYe1HqtFD2aB4PYVXmSp5PDaWfmysHkxFCRIKoE Ze47O8dpZFBRomxRQ4eD7Xf/ab8Fn3i213yRN1XLOPMhc0NGsoBcRUiTJ+LdzSuqJFAEXvpLdYUI LCE+R40pDsBp3gnX9itW0PAdF3wjY8wA7lAmiNsv9ioplMpdrYf+KxUsMJeCPsbXLa13YGXtyZaq Rk8WbBiGU5MgGH1W9FPvmUY1SZrryO8+XSmuI4k/EMch4Nn65O0Z7i1Bb98Kk5rE6mIFk/lGdxxh VGLAH3OVqvXGg1omqFnAX5hH1ZpzFmPIe2ONB8wx5iS0V4KTjbqnErgI8Ia/7A9lktaqLZwR5zTU ANvEGIC7ISx+8a1knTsa5ZiGWHK/JVuMY961ammkVGp9qH6ESKklBcXdWqTUpKuQVL19L+qkbif7 Lk38dYk2sHyTNo35sDahpeba5jgs/7dO8TaqrmoKboV8RIH5uWk+t9RE+fZtkvs94TGfWrkrXVph ZrmenMq19Zm53cfyLOP1HQe01nEwf4eD3QVIJcngFdMozttMKFm0hQXDDFXBT6UToEBjiKTO/jEc bARxc73Xn1v9AKpifG+Rxu2VsYm3EBpimAgIm4xmYgDZ0Qoc3WOal4tllh2H995XhUGbxOoCPrTI cfM5Pec+zwxZ8lG8RWBpFoYIpu+gtPtYp6XAKfZbHNMAtp1Y+TbEv8BG4RVc0g0XVjPYlybJ6sKP H1E5xIDqoOGlzQeiSGEGevqzqLQsdwdz545EpLMFLwefcBOfQ5H0NrYPMR9b4YRLHFs675jkdKQz yOkt3U1wpaziwwhCAvasTaPu1sOAHEghCEjbN8KXXzB4nMRyI9Q+yQBFMwkWIVihjv76ui7aoDje +nscDYxezrdmBHD9JQsoI1FS/RCIfYCCHh438NdgF1PtC7ZGVtGBZv5b09G5QY4bgammyMwK6zSb Jthfm+1uJbDDzg9iz1VwCc67husRd22KalzCMPFPT85+9eXug8HctspiMy1mOu0uvYDVsLTKI24+ JP4XQ9tpBCR5RfxsuqbzECzaiFakSvmeZQ/CQzQHb/vBStgwn6p/rKfo/wHh2JYsik95CwqJRajj vbYUd9R92VK0GzGFRxa+5mA8d0AFAIw6A+A+fjxhojNvdkou9pMpa0Epu29lieVgHBCl8HrNlWs+ LSbNdTnn0Iho+TrkfN0bGc1DHhn7TL5IxikNcRwy2iEvwMGYoS1zFHwkO5iAoPQgn1vuR3V24ztX c2nupqXnVfXZwbWZJl6p4iUhupvvmPRbLiq47cU7x4yjpsWd24Shx8ZjVNQzTlVJ/osfFXl5T5Bh CQVwcoG+fqLx83yH3JS174vOskw04veLQ5r+MQF1PUoplgRGC3u33uDMxCho24yPHp36dfeFUvsG zRnwnL/XElhz6X8AIrjw88DzwSIrz+cPlFhJ33zItL1dSBSyv53HjuoRUU/R8+3mvBZ2V1cxmVCz wmMeUeuPN+OVCp+Bm/FdhvR+8jKTbCLRO1b8DKafakfaMM1H+0K/KG3mvv9Snn6rcxdRvRSD9Zx1 16qqcu1teFDbrEgQIZB+2eCMsFwR4Qye+gzAgJ2IW9qACIXry4SkKi0UWMUTFKsCx4bKAteeEoDG y2rtfO3vtLKV+Jn9J2KrD2YLjixCM+snmON9qepjOneYd02F60+CJSASAHHNrAdFdIU6COJ1QR0E Z2W8ft/mP3yrVgspzbe5ArIDZjJrwrHv91mbqFSJ7AJjQWvBHB7TS0kLMsUDWSqjsItEG3XDOwrC P1SX4/02zwoLVSufp72CGqEk7Z6LJjrtLAHe17PN7ca+hLE02hypBApeKMeZZUFczHqhytv4yWPM 3mRGiXUQ2SqX3UWkj1X8DWIVSEUCFwdTusgpqFJ46VWwvFVoDIjO3RkR8vUPTx7Fg0TaP0gtvO3X BLovmPQPN5BUHiSylgKJX1cwO1/ochIV8Ipwp9E/6tYP8oPK2xd0KcUiGBWKulgJfMmYH1yhN98g b0tDU3XENYVrOEgkhny/Jlt0zhQDN1Ov7stWSCG1FDMIYsUdUNpnFmpsYB5Rx33PR3WRdUUXhn8k tHQhozxPhgpJYZybk/0yIRitVd+UfOxtK9pkqzysxb1ybLbVHgM5aHgFou8ZJlcfvPlSPkkjelZG aXfg4WF6EEeQckMj074lE4SMlweGCrGAKdyWukmBWAaShDAXDFTQJgsrialJM+y91Ip3T2yyHazl whqjzl2KeZHajTOYgPhSZwMpQ1804cZRMuRfBsAkhhEDraCi9lTkBjUdm8pylTMxEVHq2dQx1eXU fsY3g4LKYU99+flVoedjvga8vqEcTAjb+ZHfBGOygSzUKtiVE8b6OUHlEQE91f0RlYRx7ZIeCBbg NAHzWhXHccZ0exPFXMEGZHHjhDhaGA4VARa9nkCYtJpAGKyDec0O8wXI2xjuz6wZPUq8i5hJtyja Lo+PQCD2mPltnku/OouJgxdPb3C9yFnyySvL5Nk5qc3PC+mddRmTSJEq6tKMii2rc27ljp0CC3Y9 ChxBSouL+1C7x/S/gR14TpHzbARTiinKqDLTedH+X7kLDP53jPrTL1RFkqdZtvt4n2VJkVYq3CQU 8+agE2S5hzbqcQ0M3CdE6hG9JIPebZNa1YaDwj7OJVGQweIuP5ewVIo+a1SqtY+j3jy3ROBuqlAF /I6nPiFEiSl1o3lbFlZs52Hb8k7l5E9WTj6EOYCBtRL9Yh84lwYSl0s6310OJLH4ys75mRe28n8s T56qk7JSs109pfFpk3FQNIWKQCI4QmmMH6RLW+R/1cv6CIEF5IAobj0Swi807wQGJEoiPJu5D59o Ex5mEjPyd9MBCy7UG+Lp4N4J9lsK4JBptsrWCs5yfClSL3vkDoYAtgpdOh7I3g80TQ1p3bBzY+JL C6nZAOmg1RjhlkfuiqMR9vLwXcZnmiKJobOqSZTKfmKUDCyM365f56szKDMG7dKxoYpiKbAWSgRj 2NXsdsAJz10m5lUEEadSOMG+V/fG+SgioA5a8aDfdiGRcCjFrxO9Wmq2lgvspW6ZbZkQSduFANxg X7TUVotpEwuVOSWlZsZYQT9Qi9Y0CMepIL977RhFuVyxN5fUrU2yxA9d0uT8sA8ZuTTrluzeqqA5 yPEiHGH4zt68oEMZI/2cAE63TmadrpmzEW2kCIPOjodvXOmA2ZnvI1dzEfmzEH4u8M3rnwUnJcKB v1m4O3OSFnuV78YoWz+bun3YvYIKRM5MMXKnM9DKH7dXQj4maJ3n59T2Wth1Gb3MxUAQ0Ly+uzmH iARAPwip8jA7GIfDmb5Q3xk4pnQmTRwfdxnEm/PsMAExBAignBfSm0OxpHP6I/MVggcwxBgI34EQ VAGNkL6esgZt2vhyJUm2dBaW1BuqyQsHRsZUz39mWwPX5BJakJx2nE8zFgHmzbwQs1sziI5Uy83P cFpIBy6dvbs9HpHKYsyYzkYD1vppx3NNrXnuXQfbNQyDgeNiQuID+/hnXm3HjP7Mh5he6jYV+LGu VzmxyCHvWQvLqqy5IyjY3KCJ8+LxPKkaeo5rMPAIBuxmg6RGiJBRCu2BI6Su+YzZAYtoDTQAATqq O3dNjRfvNTd4qjJwqg7PQdC8ljjJ+5+j0MHN5C3Q9gUR7Uarogr4zE3wuftioEghlqpuLqZu90IZ CVr2tfr8dTzQtaIC6AgJIPqvC8yP5SkKtqMdWAy48Q0YL6lTvVAocPrb+i+lypTQKC10aVlfj1Yx S1lu1KTc2aPH9Tnl06JytUeaHOosUXn9hp/Kgscle6eydKexjAooK/Btd8LkNx95wnb9A+tnU43r nQMz29HN58DoXZqmNhqDtCrER2F9v9Q+bVUXWeHsggnSMpPnf3PPZqF1xEheVjSwGU2mGDKtNaBn LYvtnWY2a4rFgge2bMfT2MExYjsvNX0UCVtTGTrW0edKOzs5M1eTXboGHUB6DGM6hla5bh61os7P 2NKuIHHD0j+AMM+VIqZBmGDB6A2Uj4jTggVZ4WLHYNlB+Cxp1jYEkmVvRjYZBILJ0e9dCTLSpKT0 Dg4cSxmNkGMUyM4K7UMMQASYd1avO0Y1JnXaqqlhLngs0nZl5WA4PrDDS6BF2vo407as7x3TGiiM d3ANfikHgUSBtlHhQG76b3Uc1VQJsRvtTaWyvibAlOvIYmukHXSMgpIbWSH+MKx1ClP+ovRPn1G8 /2a2lsw9jHKhgPM4J2kz7H9dKVoQ4Ua7a7uVxhZ9UP2vWYG9pjbhFSvF5swW1MhXnnR4yRl+vSb3 IUDdvPyEAyLcJ5WBLHNyfJFPfp0txmM4HBaSk4alNUWfoac2+9SSZ3eU6gpDEbS2HSG0ERgFWr9W aNse6Axm4V+stS8m9qEHF9HwC5HxIziNxq1f6p72s8YzMMUMWMRS1sJw3s+CaE2kI/ZMaMsO2AV6 vvC/7dZGtI3wwyWvRu+tW1DG+pdBpfxI0r8RbC7onNFi9SeXvIawHBNjjFCDWr6arCydCp6VnttA ahBRVn6wts4+9nzsUB9qALIM5qnd4g4KR/04yayrQwyj8gx5fIsBfismw7W9hkSQ5VBrZvBoEKe7 1JjxW2ZJj2BlwlaBZc1C2KZgQ8kukpQGrko8WMlExSNLgg2YP2djVazHY+fCfXh28mf953+fyCkw ZW5kc3RyZWFtCmVuZG9iago1MiAwIG9iago0MzE4CmVuZG9iago1NSAwIG9iago8PC9MZW5ndGgg NTYgMCBSL0ZpbHRlciAvRmxhdGVEZWNvZGU+PgpzdHJlYW0KeJzVW8luHDcQvc9XzC3TgIdusrm1 LwFsOKtziCMghzgHbSPJkSxZkeLEn2Eg+d6wF3YVm1XTPSM5QCzYaM1w62K9V6+K9PtlKaRals1P fDi+WpTLr8Pfs8X7hRdV86f9Aj8fXy2fHyyevnbL0OtgsyhFXfuybr+T4TO7dGUtwldXi19Wh0Ul pHG+Xi2LdSm086r0q4tirYSpTGVXV8W6Erqu4OF06HLSdKmN1dLhLjDmHXx4Sk50WyhR2bpsRl1b 4a1UBvU/pkZCM12jBbxDz3gKGA23CEuX4RdnbGxc60rGaazxq3PUOlt82xhWh9vS8x3D69GDMTNn tmwaPGDFhJEvYYRLeo4Pxa8H3y2UNsGTghMdnATH6XdBSz1jALAU3jHCo3CnCxiL2Nt+YaWwSlal Zl5+1FGVwkjnVn8Vshall+l67plZzsFXwGp/dI29t/36bVlV1M40FjpnGitTNpZd96Zdy0r4zry/ hzmlcDbMCYttPhROW0MDa7Andn+MUfyynemUUTxyNgM4r8ECgFjcdJgaDIRgiieIK/cm3abcwil8 4qfQSfTz66rxm9aO0ouy0hoMufq7OHgbuND3XKhFWG2pOycOvdovI1E2nZTV0cOfF0a4yinMUiTL 4YU+gwbR38J2zfa31pgfinUtqtpayUxyl0wSLKdrV/GTbN86cCow7W2xdsKaUsro5yNcdUM53Bu7 fgaTEZddkIwB3x+hXqGBDC2M4UgNMeB1atHWMt7OtYxLSesd+eYXsJyznhZtaKWi12AeOmKwN2G9 yVDA0SFvif3CxQ1Y6JRk8Jt0n+LIKJbj4SRiQYWeMQ92tkRE+BHG4qI9rC2z50gBINI7DE3DwIEM kHsI1GvJPL8u1oFFvPSp/MB7/RTw+QJan2ceMGIUWH3KIoMBOS7HxvgUfYvRC3idCAFggweKkpaO /6FxeFaEOaxyCjsLZ0RSoIzwmXvnaY/JWjjpIiZPGDBsoq1IcM4wBOIxGsonU1Y7HIezttsyfY72 e9l8LK0NSp/l5bUMzO3KUcyJhspgkwmRznAIgAlmJqLRFP7wp7QmvGmDZl1rl7tk2w033pABDa3n nHKRNNQOL5f7QDNwjD7aJHuJhCfygRNyT/BmzpN1HYdmsu5zC56fm6jvpbN4p8EUOFeblj6DiTFe GAFKKkmsjuhMi5O5CdDi7m1NdHkASzTuD01jV6paJU04AntLbWaW0aZTfwlRKeWAOjStnYzRpyp5 4nxG0yV+k+/BfdN4H/kZuIGkw+uOZW0lqrKK7kO8u6+mXv0Jw3pEQvEngHkLVw7PW7zZeXjY6stj GyIuvh3FjlbJ3KPnd+j5hFY7vf0Q2SLuIiXCDeP+qB+h/DIcUvWdJN5G1ABJHU6ILFLH4AbY/0pm jVQucowjZLQ+t+n7wwMxOqkGhocLCtacwqBTGi4JZCTbDdu10zph/6yJKOzdriULoj43rqaAJONm pF6ccBpSeTChj8gjUzkzSP6JTIl5qTwP6pGXCbp5xZnOwAimYLVbXCMhN3VUdRyeP3c0/6lYG1E6 WWuaSuDDw1xqMLEcdae1FwrqtOBKHCbWGOimXLaTFpZiSMgcuR3jOfAB5ce0oEWR4ym0ZajlPbPt 8E6ftvswiTUuycafw3CTqVK7WUG5GDxDSx7GCVXL6DPjCmLbmazQkJoVhcdvixBCKm/rJGk5QM9f FVrU2muFu83PyHr3kRWWGEw9Isn1wU0GgPdGQADPN2UMcbICu+95xRPksnMqellyHRrT+dR9bpFm IUS8GgOcOb0ghBPlFQmk4+7SMv6e2mquxAUzJIW4uKm4G8L5hsD+MbF+Jog0hgvPTtdJraiLvlJo JTEjB3+qhTb2f16F3u5P3vk5/sRxOONzd3TYoTP6yaOxzRaxP6LtvErAu0L0OjAnl8QcMWZm1tvX /Z3nTsSQRs1q9R0RRkEYZNhIEM4qDj5CLEolGRudmapaK1u5jZ0s55OMgU56uaI4OstEunCGXDwc 5GLSDyvHZidQYOHkAgIBAO+3lLzzpGxLvTqGhT4QexXgMAiuvUlhB/nGltaGfhmh/Yc5FTjsDifS 2PuJmgKaiowz98R2GnKkZQ/kZueG+grkJnTtl2Es/AIjotrvOHy20BiXRGdkbsc0rdFKI8kmjU4R O9iSxCjYkkjDlA2f4CL4Q+I3Oi7CJgL/g6dvADFM/nXCGJyUBlvT/BGaEbtAU7oiTofrcwpFW8pl Yz9hDoQmTp8fxZ/po0SWh+Ib0cqLSBHys9ZUTLd5WY94o4T2w1nyJvFhvog6mSyhE6AN9b3aDaUP OyL0pfdmfESYF34JQhkFaBS2b1BQviRbkBVtyAA7u6NAPVnPJGw2AtUsNUu4Hm58Q7Y4JCUCPoFl b72Ra+aEKjJCKvajN9ElDTwEUbEeRfGJBaZSfuraGr2g/NDQeRoJGwg7JGWRFZK7DrxVUHvKUhdB COraeo9JmSa2yceJQI91BSEPGXkvLsdjfJ6JVpRTz6ouzqDyiVufXIpAVQuwa6MhyHrGTpc+yeLJ pNBDZD0xLZmtfeyd2AltdKI5s/7XKFkjUbTTLSNisTulmWwgHB1IOAQvE+jeP7rAmzhyGmMJARMN 8qpZrHelwxX8PXMwzo5k8ZK500EWmy6zwNCYPzn4iX7LnYXMSd640DCdJB5RNR3y+jOtyqcTwNPs YlqLB/ZKHIzXnZ1rUSqdFd6RX4MQP6cBj1dGay9aPs+gPo4GGZmeVHpwTzjq7l4XCSxYDzrYx9ab OKva/38E0D2J3B/cYVSgpyISE9emr64QE9PiiNY2O2YfO50Dn2JPyvGEc408TG3fViZM9e+oS0iJ ZNDtWUY0X5y9gHO7wLJSi6pUKrKsnHXv7s0qP8KbG3XGx+CkFMUNMksbQ8WypM7Y2QiBa+vtQFsr 5nLdnt1Q9YAMTmfpvaIsTKWBsN0iOR0HE4ofuJgSartQ/OT+zKFAhKUH4YLMoi/YBTAJumtyW5No pqseW0ZI5XKxB0Z6U7RrsaUcxFMdnK3Gp1utPup+e9X89kX3z8uDxY/h518NhFioZW5kc3RyZWFt CmVuZG9iago1NiAwIG9iagoyMjkyCmVuZG9iago0IDAgb2JqCjw8L1R5cGUvUGFnZS9NZWRpYUJv eCBbMCAwIDYxMiA3OTJdCi9Sb3RhdGUgMC9QYXJlbnQgMyAwIFIKL1Jlc291cmNlczw8L1Byb2NT ZXRbL1BERiAvVGV4dF0KL0ZvbnQgOSAwIFIKPj4KL0NvbnRlbnRzIDUgMCBSCj4+CmVuZG9iagox MCAwIG9iago8PC9UeXBlL1BhZ2UvTWVkaWFCb3ggWzAgMCA2MTIgNzkyXQovUm90YXRlIDAvUGFy ZW50IDMgMCBSCi9SZXNvdXJjZXM8PC9Qcm9jU2V0Wy9QREYgL1RleHRdCi9Gb250IDEzIDAgUgo+ PgovQ29udGVudHMgMTEgMCBSCj4+CmVuZG9iagoxNCAwIG9iago8PC9UeXBlL1BhZ2UvTWVkaWFC b3ggWzAgMCA2MTIgNzkyXQovUm90YXRlIDAvUGFyZW50IDMgMCBSCi9SZXNvdXJjZXM8PC9Qcm9j U2V0Wy9QREYgL1RleHRdCi9Gb250IDE3IDAgUgo+PgovQ29udGVudHMgMTUgMCBSCj4+CmVuZG9i agoxOCAwIG9iago8PC9UeXBlL1BhZ2UvTWVkaWFCb3ggWzAgMCA2MTIgNzkyXQovUm90YXRlIDAv UGFyZW50IDMgMCBSCi9SZXNvdXJjZXM8PC9Qcm9jU2V0Wy9QREYgL1RleHRdCi9Gb250IDIxIDAg Ugo+PgovQ29udGVudHMgMTkgMCBSCj4+CmVuZG9iagoyMiAwIG9iago8PC9UeXBlL1BhZ2UvTWVk aWFCb3ggWzAgMCA2MTIgNzkyXQovUm90YXRlIDAvUGFyZW50IDMgMCBSCi9SZXNvdXJjZXM8PC9Q cm9jU2V0Wy9QREYgL1RleHRdCi9Gb250IDI1IDAgUgo+PgovQ29udGVudHMgMjMgMCBSCj4+CmVu ZG9iagoyNiAwIG9iago8PC9UeXBlL1BhZ2UvTWVkaWFCb3ggWzAgMCA2MTIgNzkyXQovUm90YXRl IDAvUGFyZW50IDMgMCBSCi9SZXNvdXJjZXM8PC9Qcm9jU2V0Wy9QREYgL1RleHRdCi9Gb250IDI5 IDAgUgo+PgovQ29udGVudHMgMjcgMCBSCj4+CmVuZG9iagozMCAwIG9iago8PC9UeXBlL1BhZ2Uv TWVkaWFCb3ggWzAgMCA2MTIgNzkyXQovUm90YXRlIDAvUGFyZW50IDMgMCBSCi9SZXNvdXJjZXM8 PC9Qcm9jU2V0Wy9QREYgL1RleHRdCi9Gb250IDMzIDAgUgo+PgovQ29udGVudHMgMzEgMCBSCj4+ CmVuZG9iagozNCAwIG9iago8PC9UeXBlL1BhZ2UvTWVkaWFCb3ggWzAgMCA2MTIgNzkyXQovUm90 YXRlIDAvUGFyZW50IDMgMCBSCi9SZXNvdXJjZXM8PC9Qcm9jU2V0Wy9QREYgL1RleHRdCi9Gb250 IDM3IDAgUgo+PgovQ29udGVudHMgMzUgMCBSCj4+CmVuZG9iagozOCAwIG9iago8PC9UeXBlL1Bh Z2UvTWVkaWFCb3ggWzAgMCA2MTIgNzkyXQovUm90YXRlIDAvUGFyZW50IDMgMCBSCi9SZXNvdXJj ZXM8PC9Qcm9jU2V0Wy9QREYgL1RleHRdCi9Gb250IDQxIDAgUgo+PgovQ29udGVudHMgMzkgMCBS Cj4+CmVuZG9iago0MiAwIG9iago8PC9UeXBlL1BhZ2UvTWVkaWFCb3ggWzAgMCA2MTIgNzkyXQov Um90YXRlIDAvUGFyZW50IDMgMCBSCi9SZXNvdXJjZXM8PC9Qcm9jU2V0Wy9QREYgL1RleHRdCi9G b250IDQ1IDAgUgo+PgovQ29udGVudHMgNDMgMCBSCj4+CmVuZG9iago0NiAwIG9iago8PC9UeXBl L1BhZ2UvTWVkaWFCb3ggWzAgMCA2MTIgNzkyXQovUm90YXRlIDAvUGFyZW50IDMgMCBSCi9SZXNv dXJjZXM8PC9Qcm9jU2V0Wy9QREYgL1RleHRdCi9Gb250IDQ5IDAgUgo+PgovQ29udGVudHMgNDcg MCBSCj4+CmVuZG9iago1MCAwIG9iago8PC9UeXBlL1BhZ2UvTWVkaWFCb3ggWzAgMCA2MTIgNzky XQovUm90YXRlIDAvUGFyZW50IDMgMCBSCi9SZXNvdXJjZXM8PC9Qcm9jU2V0Wy9QREYgL1RleHRd Ci9Gb250IDUzIDAgUgo+PgovQ29udGVudHMgNTEgMCBSCj4+CmVuZG9iago1NCAwIG9iago8PC9U eXBlL1BhZ2UvTWVkaWFCb3ggWzAgMCA2MTIgNzkyXQovUm90YXRlIDAvUGFyZW50IDMgMCBSCi9S ZXNvdXJjZXM8PC9Qcm9jU2V0Wy9QREYgL1RleHRdCi9Gb250IDU3IDAgUgo+PgovQ29udGVudHMg NTUgMCBSCj4+CmVuZG9iagozIDAgb2JqCjw8IC9UeXBlIC9QYWdlcyAvS2lkcyBbCjQgMCBSCjEw IDAgUgoxNCAwIFIKMTggMCBSCjIyIDAgUgoyNiAwIFIKMzAgMCBSCjM0IDAgUgozOCAwIFIKNDIg MCBSCjQ2IDAgUgo1MCAwIFIKNTQgMCBSCl0gL0NvdW50IDEzCj4+CmVuZG9iagoxIDAgb2JqCjw8 L1R5cGUgL0NhdGFsb2cgL1BhZ2VzIDMgMCBSCi9NZXRhZGF0YSA1OSAwIFIKPj4KZW5kb2JqCjkg MCBvYmoKPDwvUjcKNyAwIFIvUjgKOCAwIFI+PgplbmRvYmoKMTMgMCBvYmoKPDwvUjcKNyAwIFIv UjgKOCAwIFI+PgplbmRvYmoKMTcgMCBvYmoKPDwvUjcKNyAwIFIvUjgKOCAwIFI+PgplbmRvYmoK MjEgMCBvYmoKPDwvUjcKNyAwIFIvUjgKOCAwIFI+PgplbmRvYmoKMjUgMCBvYmoKPDwvUjcKNyAw IFIvUjgKOCAwIFI+PgplbmRvYmoKMjkgMCBvYmoKPDwvUjcKNyAwIFIvUjgKOCAwIFI+PgplbmRv YmoKMzMgMCBvYmoKPDwvUjcKNyAwIFIvUjgKOCAwIFI+PgplbmRvYmoKMzcgMCBvYmoKPDwvUjcK NyAwIFIvUjgKOCAwIFI+PgplbmRvYmoKNDEgMCBvYmoKPDwvUjcKNyAwIFIvUjgKOCAwIFI+Pgpl bmRvYmoKNDUgMCBvYmoKPDwvUjcKNyAwIFIvUjgKOCAwIFI+PgplbmRvYmoKNDkgMCBvYmoKPDwv UjcKNyAwIFIvUjgKOCAwIFI+PgplbmRvYmoKNTMgMCBvYmoKPDwvUjcKNyAwIFIvUjgKOCAwIFI+ PgplbmRvYmoKNTcgMCBvYmoKPDwvUjcKNyAwIFIvUjgKOCAwIFI+PgplbmRvYmoKNyAwIG9iago8 PC9CYXNlRm9udC9UaW1lcy1Sb21hbi9UeXBlL0ZvbnQKL0VuY29kaW5nIDU4IDAgUi9TdWJ0eXBl L1R5cGUxPj4KZW5kb2JqCjU4IDAgb2JqCjw8L1R5cGUvRW5jb2RpbmcvRGlmZmVyZW5jZXNbCjM5 L3F1b3Rlc2luZ2xlCjEzMy9lbGxpcHNpcwoxNDYvcXVvdGVyaWdodC9xdW90ZWRibGxlZnQvcXVv dGVkYmxyaWdodC9idWxsZXQvZW5kYXNoXT4+CmVuZG9iago4IDAgb2JqCjw8L0Jhc2VGb250L0hl bHZldGljYS9UeXBlL0ZvbnQKL1N1YnR5cGUvVHlwZTE+PgplbmRvYmoKNTkgMCBvYmoKPDwvVHlw ZS9NZXRhZGF0YQovU3VidHlwZS9YTUwvTGVuZ3RoIDE3OTc+PnN0cmVhbQo8P3hwYWNrZXQgYmVn aW49J++7vycgaWQ9J1c1TTBNcENlaGlIenJlU3pOVGN6a2M5ZCc/Pgo8P2Fkb2JlLXhhcC1maWx0 ZXJzIGVzYz0iQ1JMRiI/Pgo8eDp4bXBtZXRhIHhtbG5zOng9J2Fkb2JlOm5zOm1ldGEvJyB4Onht cHRrPSdYTVAgdG9vbGtpdCAyLjkuMS0xMywgZnJhbWV3b3JrIDEuNic+CjxyZGY6UkRGIHhtbG5z OnJkZj0naHR0cDovL3d3dy53My5vcmcvMTk5OS8wMi8yMi1yZGYtc3ludGF4LW5zIycgeG1sbnM6 aVg9J2h0dHA6Ly9ucy5hZG9iZS5jb20vaVgvMS4wLyc+CjxyZGY6RGVzY3JpcHRpb24gcmRmOmFi b3V0PSdkZDkxNGNmOC05ZGE3LTExZTEtMDAwMC1lZmU3NTQ2N2MxMTUnIHhtbG5zOnBkZj0naHR0 cDovL25zLmFkb2JlLmNvbS9wZGYvMS4zLyc+PHBkZjpQcm9kdWNlcj5HUEwgR2hvc3RzY3JpcHQg OC43MDwvcGRmOlByb2R1Y2VyPgo8cGRmOktleXdvcmRzPigpPC9wZGY6S2V5d29yZHM+CjwvcmRm OkRlc2NyaXB0aW9uPgo8cmRmOkRlc2NyaXB0aW9uIHJkZjphYm91dD0nZGQ5MTRjZjgtOWRhNy0x MWUxLTAwMDAtZWZlNzU0NjdjMTE1JyB4bWxuczp4bXA9J2h0dHA6Ly9ucy5hZG9iZS5jb20veGFw LzEuMC8nPjx4bXA6TW9kaWZ5RGF0ZT4yMDEyLTA1LTExVDA1OjMzOjA2LTA0OjAwPC94bXA6TW9k aWZ5RGF0ZT4KPHhtcDpDcmVhdGVEYXRlPjIwMTItMDUtMTFUMDU6MzM6MDYtMDQ6MDA8L3htcDpD cmVhdGVEYXRlPgo8eG1wOkNyZWF0b3JUb29sPlwzNzZcMzc3XDAwMFBcMDAwRFwwMDBGXDAwMENc MDAwclwwMDBlXDAwMGFcMDAwdFwwMDBvXDAwMHJcMDAwIFwwMDBWXDAwMGVcMDAwclwwMDBzXDAw MGlcMDAwb1wwMDBuXDAwMCBcMDAwMFwwMDAuXDAwMDlcMDAwLlwwMDA5PC94bXA6Q3JlYXRvclRv b2w+PC9yZGY6RGVzY3JpcHRpb24+CjxyZGY6RGVzY3JpcHRpb24gcmRmOmFib3V0PSdkZDkxNGNm OC05ZGE3LTExZTEtMDAwMC1lZmU3NTQ2N2MxMTUnIHhtbG5zOnhhcE1NPSdodHRwOi8vbnMuYWRv YmUuY29tL3hhcC8xLjAvbW0vJyB4YXBNTTpEb2N1bWVudElEPSdkZDkxNGNmOC05ZGE3LTExZTEt MDAwMC1lZmU3NTQ2N2MxMTUnLz4KPHJkZjpEZXNjcmlwdGlvbiByZGY6YWJvdXQ9J2RkOTE0Y2Y4 LTlkYTctMTFlMS0wMDAwLWVmZTc1NDY3YzExNScgeG1sbnM6ZGM9J2h0dHA6Ly9wdXJsLm9yZy9k Yy9lbGVtZW50cy8xLjEvJyBkYzpmb3JtYXQ9J2FwcGxpY2F0aW9uL3BkZic+PGRjOnRpdGxlPjxy ZGY6QWx0PjxyZGY6bGkgeG1sOmxhbmc9J3gtZGVmYXVsdCc+XDM3NlwzNzdcMDAwc1wwMDBpXDAw MGRcMDAwclwwMDAuXDAwMGlcMDAwblwwMDB0XDAwMGVcMDAwclwwMDBpXDAwMG1cMDAwLlwwMDAz XDAwMDBcMDAwQVwwMDBwXDAwMHJcMDAwMlwwMDAwXDAwMDFcMDAwMlwwMDAuXDAwMG5cMDAwb1ww MDB0XDAwMGVcMDAwczwvcmRmOmxpPjwvcmRmOkFsdD48L2RjOnRpdGxlPjxkYzpjcmVhdG9yPjxy ZGY6U2VxPjxyZGY6bGk+XDM3NlwzNzdcMDAwc1wwMDBhXDAwMG5cMDAwZFwwMDB5PC9yZGY6bGk+ PC9yZGY6U2VxPjwvZGM6Y3JlYXRvcj48ZGM6ZGVzY3JpcHRpb24+PHJkZjpTZXE+PHJkZjpsaT4o KTwvcmRmOmxpPjwvcmRmOlNlcT48L2RjOmRlc2NyaXB0aW9uPjwvcmRmOkRlc2NyaXB0aW9uPgo8 L3JkZjpSREY+CjwveDp4bXBtZXRhPgogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAKICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCjw/ eHBhY2tldCBlbmQ9J3cnPz4KZW5kc3RyZWFtCmVuZG9iagoyIDAgb2JqCjw8L1Byb2R1Y2VyKEdQ TCBHaG9zdHNjcmlwdCA4LjcwKQovQ3JlYXRpb25EYXRlKEQ6MjAxMjA1MTEwNTMzMDYtMDQnMDAn KQovTW9kRGF0ZShEOjIwMTIwNTExMDUzMzA2LTA0JzAwJykKL1RpdGxlKFwzNzZcMzc3XDAwMHNc MDAwaVwwMDBkXDAwMHJcMDAwLlwwMDBpXDAwMG5cMDAwdFwwMDBlXDAwMHJcMDAwaVwwMDBtXDAw MC5cMDAwM1wwMDAwXDAwMEFcMDAwcFwwMDByXDAwMDJcMDAwMFwwMDAxXDAwMDJcMDAwLlwwMDBu XDAwMG9cMDAwdFwwMDBlXDAwMHMpCi9DcmVhdG9yKFwzNzZcMzc3XDAwMFBcMDAwRFwwMDBGXDAw MENcMDAwclwwMDBlXDAwMGFcMDAwdFwwMDBvXDAwMHJcMDAwIFwwMDBWXDAwMGVcMDAwclwwMDBz XDAwMGlcMDAwb1wwMDBuXDAwMCBcMDAwMFwwMDAuXDAwMDlcMDAwLlwwMDA5KQovQXV0aG9yKFwz NzZcMzc3XDAwMHNcMDAwYVwwMDBuXDAwMGRcMDAweSkKL0tleXdvcmRzKCkKL1N1YmplY3QoKT4+ ZW5kb2JqCnhyZWYKMCA2MAowMDAwMDAwMDAwIDY1NTM1IGYgCjAwMDAwNTE4MDMgMDAwMDAgbiAK MDAwMDA1NDUyNyAwMDAwMCBuIAowMDAwMDUxNjU5IDAwMDAwIG4gCjAwMDAwNDk3OTAgMDAwMDAg biAKMDAwMDAwMDAxNSAwMDAwMCBuIAowMDAwMDAzMjI2IDAwMDAwIG4gCjAwMDAwNTIzNzQgMDAw MDAgbiAKMDAwMDA1MjU4OSAwMDAwMCBuIAowMDAwMDUxODY4IDAwMDAwIG4gCjAwMDAwNDk5MzEg MDAwMDAgbiAKMDAwMDAwMzI0NiAwMDAwMCBuIAowMDAwMDA2NzkwIDAwMDAwIG4gCjAwMDAwNTE5 MDYgMDAwMDAgbiAKMDAwMDA1MDA3NSAwMDAwMCBuIAowMDAwMDA2ODExIDAwMDAwIG4gCjAwMDAw MTA4NjAgMDAwMDAgbiAKMDAwMDA1MTk0NSAwMDAwMCBuIAowMDAwMDUwMjE5IDAwMDAwIG4gCjAw MDAwMTA4ODEgMDAwMDAgbiAKMDAwMDAxNDg5MiAwMDAwMCBuIAowMDAwMDUxOTg0IDAwMDAwIG4g CjAwMDAwNTAzNjMgMDAwMDAgbiAKMDAwMDAxNDkxMyAwMDAwMCBuIAowMDAwMDE5MDc0IDAwMDAw IG4gCjAwMDAwNTIwMjMgMDAwMDAgbiAKMDAwMDA1MDUwNyAwMDAwMCBuIAowMDAwMDE5MDk1IDAw MDAwIG4gCjAwMDAwMjI5NDQgMDAwMDAgbiAKMDAwMDA1MjA2MiAwMDAwMCBuIAowMDAwMDUwNjUx IDAwMDAwIG4gCjAwMDAwMjI5NjUgMDAwMDAgbiAKMDAwMDAyNjQzMyAwMDAwMCBuIAowMDAwMDUy MTAxIDAwMDAwIG4gCjAwMDAwNTA3OTUgMDAwMDAgbiAKMDAwMDAyNjQ1NCAwMDAwMCBuIAowMDAw MDMwNjA4IDAwMDAwIG4gCjAwMDAwNTIxNDAgMDAwMDAgbiAKMDAwMDA1MDkzOSAwMDAwMCBuIAow MDAwMDMwNjI5IDAwMDAwIG4gCjAwMDAwMzQ0NjUgMDAwMDAgbiAKMDAwMDA1MjE3OSAwMDAwMCBu IAowMDAwMDUxMDgzIDAwMDAwIG4gCjAwMDAwMzQ0ODYgMDAwMDAgbiAKMDAwMDAzODQ3MiAwMDAw MCBuIAowMDAwMDUyMjE4IDAwMDAwIG4gCjAwMDAwNTEyMjcgMDAwMDAgbiAKMDAwMDAzODQ5MyAw MDAwMCBuIAowMDAwMDQyOTczIDAwMDAwIG4gCjAwMDAwNTIyNTcgMDAwMDAgbiAKMDAwMDA1MTM3 MSAwMDAwMCBuIAowMDAwMDQyOTk0IDAwMDAwIG4gCjAwMDAwNDczODQgMDAwMDAgbiAKMDAwMDA1 MjI5NiAwMDAwMCBuIAowMDAwMDUxNTE1IDAwMDAwIG4gCjAwMDAwNDc0MDUgMDAwMDAgbiAKMDAw MDA0OTc2OSAwMDAwMCBuIAowMDAwMDUyMzM1IDAwMDAwIG4gCjAwMDAwNTI0NTYgMDAwMDAgbiAK MDAwMDA1MjY1MyAwMDAwMCBuIAp0cmFpbGVyCjw8IC9TaXplIDYwIC9Sb290IDEgMCBSIC9JbmZv IDIgMCBSCi9JRCBbPDdENDNBQ0RGNTFCNzBBN0VFQzZDNzBEREY0NUJBQkQ3Pjw3RDQzQUNERjUx QjcwQTdFRUM2QzcwRERGNDVCQUJENz5dCj4+CnN0YXJ0eHJlZgo1NTAxMgolJUVPRgo= --_002_24B20D14B2CD29478C8D5D6E9CBB29F60F708799Hermescolumbiaa_-- From Sandra.Murphy@sparta.com Fri May 11 04:07:39 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E49821F8476 for ; Fri, 11 May 2012 04:07:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.646 X-Spam-Level: X-Spam-Status: No, score=-102.646 tagged_above=-999 required=5 tests=[AWL=-0.047, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eUeU51xvi+uM for ; Fri, 11 May 2012 04:07:38 -0700 (PDT) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by ietfa.amsl.com (Postfix) with ESMTP id C7BCA21F8473 for ; Fri, 11 May 2012 04:07:38 -0700 (PDT) Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.14.4/8.14.4) with ESMTP id q4BB7cd5002663 for ; Fri, 11 May 2012 06:07:38 -0500 Received: from Hermes.columbia.ads.sparta.com ([157.185.80.107]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id q4BB7cWa006128 for ; Fri, 11 May 2012 06:07:38 -0500 Received: from HERMES.columbia.ads.sparta.com ([2002:9db9:506b::9db9:506b]) by Hermes.columbia.ads.sparta.com ([::1]) with mapi id 14.01.0355.002; Fri, 11 May 2012 07:07:37 -0400 From: "Murphy, Sandra" To: "sidr@ietf.org" Thread-Topic: IETF83 minutes augmented Thread-Index: Ac0vZeU4mUe6S2lRS0Kd3mf74VaMgQ== Date: Fri, 11 May 2012 11:07:35 +0000 Message-ID: <24B20D14B2CD29478C8D5D6E9CBB29F60F7087DF@Hermes.columbia.ads.sparta.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.185.63.118] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [sidr] IETF83 minutes augmented X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 May 2012 11:07:39 -0000 John Scudder took minutes for both IETF83 sessions in etherpad, which I upl= oaded to the proceedings page.=0A= =0A= (Note to the wg: the etherpad is a useful way to take mintues, as they are = visible in real time as they are being entered. It is also a collaborative= tool.)=0A= =0A= I just uploaded a new version with a few additions (mostly from Sriram) and= pointers to the jabber logs.=0A= =0A= The new version appears on the proceedings page, http://www.ietf.org/procee= dings/83/minutes/minutes-83-sidr.txt=0A= =0A= Final versions are due May 16th, so please get any comments, corrections or= additions to the sidr chairs.=0A= =0A= --Sandy=0A= =0A= From christopher.morrow@gmail.com Fri May 11 10:15:59 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AA2D21F85FC for ; Fri, 11 May 2012 10:15:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.584 X-Spam-Level: X-Spam-Status: No, score=-103.584 tagged_above=-999 required=5 tests=[AWL=0.015, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jvSOu2nLdKRw for ; Fri, 11 May 2012 10:15:58 -0700 (PDT) Received: from mail-gg0-f172.google.com (mail-gg0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7E5AA21F85E7 for ; Fri, 11 May 2012 10:15:58 -0700 (PDT) Received: by ggnc4 with SMTP id c4so51464ggn.31 for ; Fri, 11 May 2012 10:15:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=8s+69wwcV8eVbTu5Jzs3jn5SRRWvH+MiMtjZjQ4n6o0=; b=P43PbGtoN1hr6rlAqz3eLpTJCSBJnQU8nMMH4MDIXTbUMJX1vjEExiPgVC5NTXCobM D0dJk206jQC2EFI1jwUf2czw08HSNgkFnd41ynBPKTVb9HVMnkjEwhZJjnOULwHIjLvH WhCB3Qg+kVY+1wr+IOT7LQ6cjzDAk1xzdi5cAYfFzVlahaihCakaDffegNDwl5/WcShh gsv97tsIWFnReIZM3AkvLhwrtS21rW1eHJxXMCEZuQOJRsBgSXAMhV2ZjsT5OwFuftkh pPwZi2cxq3/kBNz6Y/QiugUjSRXXtxHGMr2gqimlniLvAA8U8Rd8ZlC8BOLw7l1f91hX tqkA== MIME-Version: 1.0 Received: by 10.60.19.129 with SMTP id f1mr2704857oee.1.1336756557928; Fri, 11 May 2012 10:15:57 -0700 (PDT) Sender: christopher.morrow@gmail.com Received: by 10.182.166.71 with HTTP; Fri, 11 May 2012 10:15:57 -0700 (PDT) In-Reply-To: References: <4FA48240.9060405@ops-netman.net> <7309FCBCAE981B43ABBE69B31C8D213921BE2860C3@EUSAACMS0701.eamcs.ericsson.se> <20120511025431.D05A6170C1@thrintun.hactrn.net> Date: Fri, 11 May 2012 13:15:57 -0400 X-Google-Sender-Auth: VpqgRtEamvfhG12g4fVCxC0HNTk Message-ID: From: Christopher Morrow To: Randy Bush Content-Type: text/plain; charset=ISO-8859-1 Cc: Rob Austein , sidr wg list Subject: Re: [sidr] RPKI and private keys (was RE: Interim Meeting Draft Agenda: 04-30-2012 (April 30, 2012))) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 May 2012 17:15:59 -0000 On Fri, May 11, 2012 at 12:35 AM, Randy Bush wrote: > would be interestd to hear from other ops if they believe they could get > the folk managing spares to pre-key in a useful way. no way that'll happen 'reliably'. though I contend you have time between 'card fail' and 'router back to normal' to ship a key in the ether/ssh to the device too. From Sandra.Murphy@sparta.com Fri May 11 11:00:51 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70C1421F86F8 for ; Fri, 11 May 2012 11:00:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.644 X-Spam-Level: X-Spam-Status: No, score=-102.644 tagged_above=-999 required=5 tests=[AWL=-0.045, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id avprliXR+gGF for ; Fri, 11 May 2012 11:00:48 -0700 (PDT) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by ietfa.amsl.com (Postfix) with ESMTP id 7468121F86F7 for ; Fri, 11 May 2012 11:00:48 -0700 (PDT) Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.14.4/8.14.4) with ESMTP id q4BI0cko006399; Fri, 11 May 2012 13:00:38 -0500 Received: from Hermes.columbia.ads.sparta.com ([157.185.80.107]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id q4BI0bKX017471; Fri, 11 May 2012 13:00:38 -0500 Received: from HERMES.columbia.ads.sparta.com ([2002:9db9:506b::9db9:506b]) by Hermes.columbia.ads.sparta.com ([::1]) with mapi id 14.01.0355.002; Fri, 11 May 2012 14:00:37 -0400 From: "Murphy, Sandra" To: "Sriram, Kotikalapudi" , "Ross.Anderson@cl.cam.ac.uk" Thread-Topic: [sidr] Keys and algorithms for Updates - feasibility analysis? (was Re: RPKI and private keys) Thread-Index: Ac0sn4X5MzR08xoIOkyL58SFwPpB3QACMZ1AAAAFxZAAgD6ygAAJaygAAAyS9W8= Date: Fri, 11 May 2012 18:00:36 +0000 Message-ID: <24B20D14B2CD29478C8D5D6E9CBB29F60F70871E@Hermes.columbia.ads.sparta.com> References: , , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.185.63.118] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "sidr wg list \(sidr@ietf.org\)" Subject: Re: [sidr] Keys and algorithms for Updates - feasibility analysis? (was Re: RPKI and private keys) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 May 2012 18:00:51 -0000 Before we get too involved in discussing performance and different methods = of measuring performance, I think it is very important to address the featu= res of what Brian is suggesting;=0A= =0A= such as:=0A= =0A= what security services are being supplied?=0A= who is involved in the service - where is the service applied and where val= idated?=0A= what is being protected?=0A= what are the components and the architecture?=0A= =0A= etc.=0A= =0A= --Sandy, speaking as wg co-chair=0A= =0A= =0A= ________________________________________=0A= From: sidr-bounces@ietf.org [sidr-bounces@ietf.org] on behalf of Sriram, Ko= tikalapudi [kotikalapudi.sriram@nist.gov]=0A= Sent: Thursday, May 10, 2012 9:05 AM=0A= To: Ross.Anderson@cl.cam.ac.uk=0A= Cc: sidr wg list (sidr@ietf.org)=0A= Subject: Re: [sidr] Keys and algorithms for Updates - feasibility analysis?= (was Re: RPKI and private keys)=0A= =0A= Hi Ross,=0A= =0A= The 10,000/s number is Brian Dickson's and=0A= it is not related to ECDSA (or RSA) signing/verification of BGPSEC updates.= =0A= =0A= In my work on performance modeling of BGPSEC, I have used the basic=0A= signing/verification measurement data from the eBACS benchmarking effort:= =0A= http://bench.cr.yp.to/results-sign.html=0A= The measurement numbers they report are in the same ballpark as yours for R= SA signing.=0A= However, the BGPSEC spec draft specifies ECDSA-P256, which is much faster t= han RSA-2048 for signing.=0A= (Side note: ECDSA-P256 was also preferred because it results in a much lowe= r size for BGPSEC updates=0A= and hence lower router RIB memory size.=0A= http://www.nist.gov/itl/antd/upload/BGPSEC_RIB_Estimation.pdf )=0A= =0A= Regarding how the eBACS measurement data were used to model BGPSEC CPU perf= ormance,=0A= please see:=0A= http://ripe63.ripe.net/presentations/127-111102.ripe-crypto-cost.pdf=0A= (slides 10 and 11 summarize signing/verification speeds for various latest = Intel and Cavium processors)=0A= or see,=0A= http://www.ietf.org/proceedings/83/slides/slides-83-sidr-7.pdf=0A= (slides 7 and 8).=0A= =0A= The performance modeling and measurement work is still evolving and there i= s still ways to go=0A= w.r.t. prototyping of BGPSEC and measurements with actual signed updates, e= tc.=0A= =0A= Sriram=0A= =0A= ________________________________________=0A= From: Ross.Anderson@cl.cam.ac.uk [rossjanderson@googlemail.com]=0A= Sent: Thursday, May 10, 2012 4:35 AM=0A= To: Sriram, Kotikalapudi=0A= Cc: Brian Dickson (brian.peter.dickson@gmail.com); sidr wg list (sidr@ietf.= org)=0A= Subject: Re: [sidr] Keys and algorithms for Updates - feasibility analysis?= (was Re: RPKI and private keys)=0A= =0A= Sriram=0A= =0A= You can't get 10,000 signature creations and verifications a second on=0A= a standard Intel core. You can get maybe 100.=0A= =0A= Your colleagues who work on smart grid standards have experience of=0A= this. The IEC working group assumed that all LAN traffic in=0A= electricity substations could be authenticated by digital signatures.=0A= This turned out to not work, and caused a major stall in the smart=0A= grid security program. Some substation LAN traffic has a hard=0A= end-to-end latency bound of 4ms, and that simply can't be achieved on=0A= standard cores using 1024-bit RSA signatures. You need custom=0A= hardware, which brings serious export control headaches as well as=0A= significant costs. We wrote this up in=0A= =0A= http://www.cl.cam.ac.uk/~sf392/publications/S4-1010.pdf=0A= =0A= Ross=0A= _______________________________________________=0A= sidr mailing list=0A= sidr@ietf.org=0A= https://www.ietf.org/mailman/listinfo/sidr=0A= From internet-drafts@ietf.org Fri May 11 11:19:58 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A5A921F86E2; Fri, 11 May 2012 11:19:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.428 X-Spam-Level: X-Spam-Status: No, score=-102.428 tagged_above=-999 required=5 tests=[AWL=0.171, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ppkZPvLb6dCn; Fri, 11 May 2012 11:19:58 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28DCC21F84B3; Fri, 11 May 2012 11:19:58 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.02 Message-ID: <20120511181958.24753.58644.idtracker@ietfa.amsl.com> Date: Fri, 11 May 2012 11:19:58 -0700 Cc: sidr@ietf.org Subject: [sidr] I-D Action: draft-ietf-sidr-bgpsec-protocol-03.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 May 2012 18:19:58 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Secure Inter-Domain Routing Working G= roup of the IETF. Title : BGPSEC Protocol Specification Author(s) : Matthew Lepinski Filename : draft-ietf-sidr-bgpsec-protocol-03.txt Pages : 31 Date : 2012-05-11 This document describes BGPSEC, an extension to the Border Gateway Protocol (BGP) that provides security for the AS-PATH attribute in BGP update messages. BGPSEC is implemented via a new optional non- transitive BGP path attribute that carries a digital signature produced by each autonomous system on the AS-PATH. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sidr-bgpsec-protocol-03.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-sidr-bgpsec-protocol-03.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-sidr-bgpsec-protocol/ From mlepinski@bbn.com Fri May 11 11:20:47 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2A9521F8686 for ; Fri, 11 May 2012 11:20:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8iIzseQY8-xy for ; Fri, 11 May 2012 11:20:46 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 2F98121F8427 for ; Fri, 11 May 2012 11:20:46 -0700 (PDT) Received: from mail.bbn.com ([128.33.0.48]:48762) by smtp.bbn.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1SSuRv-0005RD-BI for sidr@ietf.org; Fri, 11 May 2012 14:20:19 -0400 Received: from [128.89.254.35] by mail.bbn.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1SSuSK-00017R-1I for sidr@ietf.org; Fri, 11 May 2012 14:20:45 -0400 Message-ID: <4FAD588D.8070206@bbn.com> Date: Fri, 11 May 2012 14:21:01 -0400 From: Matt Lepinski User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: sidr@ietf.org References: <20120511181958.24753.25182.idtracker@ietfa.amsl.com> In-Reply-To: <20120511181958.24753.25182.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20120511181958.24753.25182.idtracker@ietfa.amsl.com> Content-Type: multipart/alternative; boundary="------------050904050906070903060307" Subject: [sidr] Fwd: New Version Notification for draft-ietf-sidr-bgpsec-protocol-03.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 May 2012 18:20:47 -0000 This is a multi-part message in MIME format. --------------050904050906070903060307 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit I have just submitted a revised -03 version of the core BGPSEC specification. This version incorporates the new format for the BGPSEC_Path_Signatures attribute and other changes that were discussed at the Paris IETF meeting. A known issue in the -03 version of this document is that it does not solve the confederation issue (which was discussed at the April 30 interim meeting). - Matt Lepinski -------- Original Message -------- Subject: New Version Notification for draft-ietf-sidr-bgpsec-protocol-03.txt Date: Fri, 11 May 2012 11:19:58 -0700 From: internet-drafts@ietf.org To: mlepinski@bbn.com A new version of I-D, draft-ietf-sidr-bgpsec-protocol-03.txt has been successfully submitted by Matthew Lepinski and posted to the IETF repository. Filename: draft-ietf-sidr-bgpsec-protocol Revision: 03 Title: BGPSEC Protocol Specification Creation date: 2012-05-11 WG ID: sidr Number of pages: 31 Abstract: This document describes BGPSEC, an extension to the Border Gateway Protocol (BGP) that provides security for the AS-PATH attribute in BGP update messages. BGPSEC is implemented via a new optional non- transitive BGP path attribute that carries a digital signature produced by each autonomous system on the AS-PATH. The IETF Secretariat --------------050904050906070903060307 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit I have just submitted a revised -03 version of the core BGPSEC specification.

This version incorporates the new format for the BGPSEC_Path_Signatures attribute and other changes that were discussed at the Paris IETF meeting.

A known issue in the -03 version of this document is that it does not solve the confederation issue (which was discussed at the April 30 interim meeting).

- Matt Lepinski

-------- Original Message --------
Subject: New Version Notification for draft-ietf-sidr-bgpsec-protocol-03.txt
Date: Fri, 11 May 2012 11:19:58 -0700
From: internet-drafts@ietf.org
To: mlepinski@bbn.com 


A new version of I-D, draft-ietf-sidr-bgpsec-protocol-03.txt has been successfully submitted by Matthew Lepinski and posted to the IETF repository.

Filename:	 draft-ietf-sidr-bgpsec-protocol
Revision:	 03
Title:		 BGPSEC Protocol Specification
Creation date:	 2012-05-11
WG ID:		 sidr
Number of pages: 31

Abstract:
   This document describes BGPSEC, an extension to the Border Gateway
   Protocol (BGP) that provides security for the AS-PATH attribute in
   BGP update messages.  BGPSEC is implemented via a new optional non-
   transitive BGP path attribute that carries a digital signature
   produced by each autonomous system on the AS-PATH.


                                                                                  


The IETF Secretariat
--------------050904050906070903060307-- From randy@psg.com Fri May 11 11:43:52 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FC8A21F86CF for ; Fri, 11 May 2012 11:43:52 -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=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P5d-+MSGfQCI for ; Fri, 11 May 2012 11:43:51 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id B291A21F86CB for ; Fri, 11 May 2012 11:43:51 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1SSuog-000P0J-55; Fri, 11 May 2012 18:43:50 +0000 Date: Fri, 11 May 2012 08:43:49 -1000 Message-ID: From: Randy Bush To: Christopher Morrow In-Reply-To: References: <4FA48240.9060405@ops-netman.net> <7309FCBCAE981B43ABBE69B31C8D213921BE2860C3@EUSAACMS0701.eamcs.ericsson.se> <20120511025431.D05A6170C1@thrintun.hactrn.net> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: Rob Austein , sidr wg list Subject: Re: [sidr] RPKI and private keys (was RE: Interim Meeting Draft Agenda: 04-30-2012 (April 30, 2012))) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 May 2012 18:43:52 -0000 >> would be interestd to hear from other ops if they believe they could >> get the folk managing spares to pre-key in a useful way. > no way that'll happen 'reliably'. agree > though I contend you have time between 'card fail' and 'router back to > normal' to ship a key in the ether/ssh to the device too. by the time the replacement re is sufficiently on net to create and send a public key to the noc for signing and publishing, the router is up and has at least some routing data. so the subsequent publication delay would be a critical path delay (in the pert sense) to full, i.e. bgpsec, use. randy From christopher.morrow@gmail.com Fri May 11 11:51:05 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5350B21F86FE for ; Fri, 11 May 2012 11:51:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.284 X-Spam-Level: X-Spam-Status: No, score=-103.284 tagged_above=-999 required=5 tests=[AWL=-0.285, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HRTCOP5Him+4 for ; Fri, 11 May 2012 11:51:04 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id B2F5B21F8705 for ; Fri, 11 May 2012 11:51:00 -0700 (PDT) Received: by obbeh20 with SMTP id eh20so4348851obb.31 for ; Fri, 11 May 2012 11:51:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=TbMAxnBKOME2KbA3XLXQbwND5OwtysK2L1EoZj0hAGs=; b=OVMslg+upmcDjz56aB2Lep10DifX/0eg3ZvGTM6oF2A0cKwHm4Nvn9Pmrlqcl1k18d fMf5z4hMAkQOeKwGCgm3Gp3aIsF5PQoeGdd+WAoYQBHvaqQgUvczfEFB5QX3zNm17aSg WGngxZWtZMN/JsGrl0r36dYoY9wU9Ovd+MKOamoM+3XjwFFudixSTyLlH45vXWu4FofL adB1ksMyPxjJfELOJCaza/h8LI9nt6DIgra/n0YtLwPCQeSmzj68rJVk0rp4mLuTid55 dr8G78zKZB5+6Q8jUakBfkbcLi5qmPEoGLpgi3pcTR8A3Aj5Jc/sSRzRTppHksCrixrF W4Yw== MIME-Version: 1.0 Received: by 10.60.1.67 with SMTP id 3mr13251436oek.15.1336762260313; Fri, 11 May 2012 11:51:00 -0700 (PDT) Sender: christopher.morrow@gmail.com Received: by 10.182.166.71 with HTTP; Fri, 11 May 2012 11:51:00 -0700 (PDT) In-Reply-To: References: <4FA48240.9060405@ops-netman.net> <7309FCBCAE981B43ABBE69B31C8D213921BE2860C3@EUSAACMS0701.eamcs.ericsson.se> <20120511025431.D05A6170C1@thrintun.hactrn.net> Date: Fri, 11 May 2012 14:51:00 -0400 X-Google-Sender-Auth: M9B_GG2Jpm5UotiSaO8FMvmpnZc Message-ID: From: Christopher Morrow To: Randy Bush Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Rob Austein , sidr wg list Subject: Re: [sidr] RPKI and private keys (was RE: Interim Meeting Draft Agenda: 04-30-2012 (April 30, 2012))) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 May 2012 18:51:06 -0000 On Fri, May 11, 2012 at 2:43 PM, Randy Bush wrote: >> though I contend you have time between 'card fail' and 'router back to >> normal' to ship a key in the ether/ssh to the device too. > > by the time the replacement re is sufficiently on net to create and send > a public key to the noc for signing and publishing, the router is up and > has at least some routing data. =A0so the subsequent publication delay > would be a critical path delay (in the pert sense) to full, i.e. bgpsec, > use. hrm, so... normally something like this happens: 1) router go boom 2) troubleshooting ensues to see where the problem is (what to fix) 3) RE/RSP is determined to be at fault 4) spares call placed 5) spare arrives and is placed into the chassis 6) reboot/checkout happens 7) customer links brought back online 8) things return to 'normal' I think that at 1 all routing stops (or enough stops that you stop it all anyway). I think that at 6 you are in a state where at a minimum the router has core-facing connectivity and you are placing the config back on the device + relevant other bits (the key in question). So... I agree you can make a key locally, you can ALSO probably just re-ship the current stored-in-a-safe key to the device, because you've got an extra 10 seconds for a complete new SSH session to come up/down while scp'ing the file-o-key-material to the remote device. -chris From wesley.george@twcable.com Fri May 11 12:14:42 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37A6B21F8700 for ; Fri, 11 May 2012 12:14:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.987 X-Spam-Level: X-Spam-Status: No, score=-0.987 tagged_above=-999 required=5 tests=[AWL=0.476, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z5u-e5981fiY for ; Fri, 11 May 2012 12:14:41 -0700 (PDT) Received: from cdpipgw01.twcable.com (cdpipgw01.twcable.com [165.237.59.22]) by ietfa.amsl.com (Postfix) with ESMTP id C346E21F86F8 for ; Fri, 11 May 2012 12:14:39 -0700 (PDT) X-SENDER-IP: 10.136.163.12 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.75,572,1330923600"; d="scan'208";a="379884046" Received: from unknown (HELO PRVPEXHUB03.corp.twcable.com) ([10.136.163.12]) by cdpipgw01.twcable.com with ESMTP/TLS/RC4-MD5; 11 May 2012 15:14:36 -0400 Received: from PRVPEXVS03.corp.twcable.com ([10.136.163.26]) by PRVPEXHUB03.corp.twcable.com ([10.136.163.12]) with mapi; Fri, 11 May 2012 15:14:38 -0400 From: "George, Wes" To: Christopher Morrow , Randy Bush Date: Fri, 11 May 2012 15:14:37 -0400 Thread-Topic: [sidr] RPKI and private keys (was RE: Interim Meeting Draft Agenda: 04-30-2012 (April 30, 2012))) Thread-Index: Ac0vpweO35je9+ncQsikLofsCCTIbgAAnUQA Message-ID: References: <4FA48240.9060405@ops-netman.net> <7309FCBCAE981B43ABBE69B31C8D213921BE2860C3@EUSAACMS0701.eamcs.ericsson.se> <20120511025431.D05A6170C1@thrintun.hactrn.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Rob Austein , sidr wg list Subject: Re: [sidr] RPKI and private keys (was RE: Interim Meeting Draft Agenda: 04-30-2012 (April 30, 2012))) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 May 2012 19:14:42 -0000 > -----Original Message----- > From: sidr-bounces@ietf.org [mailto:sidr-bounces@ietf.org] On Behalf Of > Christopher Morrow > Sent: Friday, May 11, 2012 2:51 PM > hrm, so... normally something like this happens: > 1) router go boom > 2) troubleshooting ensues to see where the problem is (what to fix) > 3) RE/RSP is determined to be at fault > 4) spares call placed > 5) spare arrives and is placed into the chassis > 6) reboot/checkout happens > 7) customer links brought back online > 8) things return to 'normal' > > I think that at 1 all routing stops (or enough stops that you stop it all= anyway). > [WEG] How prevalent is this scenario going to be in the hardware of suffici= ent burliness and shiny newness to manage BGPSec in the first place? Isn't = it far more likely that the router going boom because of an RE/RP problem i= s a transient while it switches to the backup, and the sync of the config b= etween primary and backup includes syncing the keys? (and replacing the spa= re is now only to restore full redundancy) I do think that it's fair to know what the scenario looks like if you have = a router that actually does go totally Tango Uniform and has to be resuscit= ated from spares including rebuilt configs and pushing keys, but I'm thinki= ng that if it's a little more complex, that's not as big of a deal because = of the fact that it's likely to be less common. Wes George This E-mail and any of its attachments may contain Time Warner Cable propri= etary information, which is privileged, confidential, or subject to copyrig= ht belonging to Time Warner Cable. This E-mail is intended solely for the u= se of the individual or entity to which it is addressed. If you are not the= intended recipient of this E-mail, you are hereby notified that any dissem= ination, distribution, copying, or action taken in relation to the contents= of and attachments to this E-mail is strictly prohibited and may be unlawf= ul. If you have received this E-mail in error, please notify the sender imm= ediately and permanently delete the original and any copy of this E-mail an= d any printout. From brian.peter.dickson@gmail.com Fri May 11 12:44:45 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8742B21F873C for ; Fri, 11 May 2012 12:44:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.448 X-Spam-Level: X-Spam-Status: No, score=-3.448 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N1d2JGHsL5u4 for ; Fri, 11 May 2012 12:44:44 -0700 (PDT) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 9D0B521F873B for ; Fri, 11 May 2012 12:44:43 -0700 (PDT) Received: by wgbdr13 with SMTP id dr13so2123628wgb.13 for ; Fri, 11 May 2012 12:44:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=CwJwbwsVsyJMNd2pwArDG0LXCYQOgVZndyNLIcvEhSY=; b=any5EOMHMnowGRMw3ya3ucnE/QgA2u90SfjasQ2aXDoEQa/O8K76H8mtST545GCAKr zpgrAwPNHX9etXtYXpUZAERNrGExvJV4eUEn7myD+KFskBXbafefbha90osSrP4QHHRq C2zlaT2ERI9DQEHPhVkCJQdHIvSloLCOGDCBMd6VOsMqV9F+5DamrGIxDt8klgTmR7QZ BrBC6kHVHt86wPvKDF91wLXS+NDcdCHiDNZCCR4crktTBO1YFNW9ONtoQRiGp2Vug4FD PlygQDCKhFpE48vgKHvel/fL6p6j+PR29vUIPCXMvnk1PJQ36f0a+cRw/aohE9NuTHPA C6ig== MIME-Version: 1.0 Received: by 10.180.75.241 with SMTP id f17mr9415809wiw.11.1336765482683; Fri, 11 May 2012 12:44:42 -0700 (PDT) Received: by 10.223.93.138 with HTTP; Fri, 11 May 2012 12:44:42 -0700 (PDT) In-Reply-To: <24B20D14B2CD29478C8D5D6E9CBB29F60F70871E@Hermes.columbia.ads.sparta.com> References: <24B20D14B2CD29478C8D5D6E9CBB29F60F70871E@Hermes.columbia.ads.sparta.com> Date: Fri, 11 May 2012 15:44:42 -0400 Message-ID: From: Brian Dickson To: "Murphy, Sandra" Content-Type: multipart/alternative; boundary=f46d043c801cbe4d8804bfc7f713 Cc: "sidr wg list \(sidr@ietf.org\)" , "Sriram, Kotikalapudi" Subject: Re: [sidr] Keys and algorithms for Updates - feasibility analysis? (was Re: RPKI and private keys) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 May 2012 19:44:45 -0000 --f46d043c801cbe4d8804bfc7f713 Content-Type: text/plain; charset=ISO-8859-1 On Fri, May 11, 2012 at 2:00 PM, Murphy, Sandra wrote: > Before we get too involved in discussing performance and different methods > of measuring performance, I think it is very important to address the > features of what Brian is suggesting; > > Would you be so kind as to explain why you believe this is important? It's not like the WG mailing list is overloaded or the participants doing much (or even responding very much, it would seem.) I was asked about this at the interim meeting, and there were many SIDR participants who were not at the meeting (physically or remotely.) My follow-up is pretty much required, just to inform the rest of the participants. We have not had, to the best of my knowledge, any (or much at all if there was some) in-SIDR discussion of performance metrics on the proposed mechanisms, when implemented in software, or when implemented in hardware. It has been proposed that a roadmap timeframe of 5-7 years is acceptable, in order that vendors provide hardware-based implementations. No justification for this has been offered, beyond "well, it is common sense". The requirements doc explicitly calls out hardware-based solutions as acceptable, without any cost analysis or cost/benefit analysis, or absolute performance metrics for requirements. I think the starting point should have been previously, and in the context of the current suggestions should be, performance numbers based on actual experiments using the protocols in question (and alternatives where alternatives have been suggested). In fact, the results from such testing should help inform discussion on acceptable performance, and those acceptable levels should be based on real-world observations of absolute rates. > such as: > > what security services are being supplied? > who is involved in the service - where is the service applied and where > validated? > what is being protected? > what are the components and the architecture? > > etc. > This can be addressed, for the moment, in a "Napoleon Dynamite" fashion. - whatever is needed - whoever wants to & what do you mean by "service being validated"? - bgp paths vs threats - whatever they need to be, and whatever works The basic thing here is, I'm asking the question, "Why is the heavy-duty crypto needed?". When I start using formal logic, I take a bunch of axioms, and rules based off those axioms. Then, take a hypothetical additional piece of logic (rule or assumption), and see what it can be reduced to, in terms of which axioms or rules are violated. Working backwards, it appears the crypto is needed because all the validation is based on information passed in-band. Without the crypto, anyone can take part of another update, and forge additions to it, or changes to it, trivially. (That's the case with vanilla BGP, too.) The additional assumption is, assume some OOB validation process, e.g. suing an outside-of-BGP communication path of some sort. And my question was, if we start the analysis by ignoring the details of the OOB system, but merely presume it exists as an adjunct, what are the minimum things we can do to tie into that system by adding _something_ to BGP updates, and how does that change the performance (and thus cost) of on-router stuff? The reason it is fair to ignore the OOB element is, that unlike on-router stuff, the possibility of achieving scaling benefits exists, since multiple routers could conceivably use a shared OOB black box. By definition, on-router stuff can't achieve scaling benefits of this sort. And, also by definition, there is no requirement that the OOB component look anything like the in-band stuff. The OOB could conceivably be anything under the sun, and be implemented by any existing or new technology. It could use DNSSEC, it could use IPSEC, it could use LDAP, it could use Kerberos (how, I don't know, but it could), it could even use carrier pigeons or SMTP or SNMP or quantum encryption. And systemically, any number of topologies are possible, since they are not fundamentally tied to the topology of the BGP infrastructure itself. > > --Sandy, speaking as wg co-chair > > When you speak as wg co-chair, I think it is important to be clear on the rationale for any attempt to moderate on-topic discussion. No offense intended, but not providing rationale looks to WG participants as political. Thanks, Brian > ________________________________________ > From: sidr-bounces@ietf.org [sidr-bounces@ietf.org] on behalf of Sriram, > Kotikalapudi [kotikalapudi.sriram@nist.gov] > Sent: Thursday, May 10, 2012 9:05 AM > To: Ross.Anderson@cl.cam.ac.uk > Cc: sidr wg list (sidr@ietf.org) > Subject: Re: [sidr] Keys and algorithms for Updates - feasibility > analysis? (was Re: RPKI and private keys) > > Hi Ross, > > The 10,000/s number is Brian Dickson's and > it is not related to ECDSA (or RSA) signing/verification of BGPSEC updates. > > In my work on performance modeling of BGPSEC, I have used the basic > signing/verification measurement data from the eBACS benchmarking effort: > http://bench.cr.yp.to/results-sign.html > The measurement numbers they report are in the same ballpark as yours for > RSA signing. > However, the BGPSEC spec draft specifies ECDSA-P256, which is much faster > than RSA-2048 for signing. > (Side note: ECDSA-P256 was also preferred because it results in a much > lower size for BGPSEC updates > and hence lower router RIB memory size. > http://www.nist.gov/itl/antd/upload/BGPSEC_RIB_Estimation.pdf ) > > Regarding how the eBACS measurement data were used to model BGPSEC CPU > performance, > please see: > http://ripe63.ripe.net/presentations/127-111102.ripe-crypto-cost.pdf > (slides 10 and 11 summarize signing/verification speeds for various latest > Intel and Cavium processors) > or see, > http://www.ietf.org/proceedings/83/slides/slides-83-sidr-7.pdf > (slides 7 and 8). > > The performance modeling and measurement work is still evolving and there > is still ways to go > w.r.t. prototyping of BGPSEC and measurements with actual signed updates, > etc. > > Sriram > > ________________________________________ > From: Ross.Anderson@cl.cam.ac.uk [rossjanderson@googlemail.com] > Sent: Thursday, May 10, 2012 4:35 AM > To: Sriram, Kotikalapudi > Cc: Brian Dickson (brian.peter.dickson@gmail.com); sidr wg list ( > sidr@ietf.org) > Subject: Re: [sidr] Keys and algorithms for Updates - feasibility > analysis? (was Re: RPKI and private keys) > > Sriram > > You can't get 10,000 signature creations and verifications a second on > a standard Intel core. You can get maybe 100. > > Your colleagues who work on smart grid standards have experience of > this. The IEC working group assumed that all LAN traffic in > electricity substations could be authenticated by digital signatures. > This turned out to not work, and caused a major stall in the smart > grid security program. Some substation LAN traffic has a hard > end-to-end latency bound of 4ms, and that simply can't be achieved on > standard cores using 1024-bit RSA signatures. You need custom > hardware, which brings serious export control headaches as well as > significant costs. We wrote this up in > > http://www.cl.cam.ac.uk/~sf392/publications/S4-1010.pdf > > Ross > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr > --f46d043c801cbe4d8804bfc7f713 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Fri, May 11, 2012 at 2:00 PM, Murphy,= Sandra <Sandra.Murphy@sparta.com> wrote:
Before we get too involved in discussing performance and different methods = of measuring performance, I think it is very important to address the featu= res of what Brian is suggesting;


Would you be so kind as to explain why= you believe this is important? It's not like the WG mailing list is ov= erloaded or the participants doing much (or even responding very much, it w= ould seem.)
I was asked about this at the interim meeting, and there were many SID= R participants who were not at the meeting (physically or remotely.) My fol= low-up is pretty much required, just to inform the rest of the participants= .

We have not had, to the best of my knowledge, any (or m= uch at all if there was some) in-SIDR discussion of performance metrics on = the proposed mechanisms, when implemented in software, or when implemented = in hardware.

It has been proposed that a roadmap timeframe of 5-7 ye= ars is acceptable, in order that vendors provide hardware-based implementat= ions. No justification for this has been offered, beyond "well, it is = common sense".

The requirements doc explicitly calls out hardware-base= d solutions as acceptable, without any cost analysis or cost/benefit analys= is, or absolute performance metrics for requirements.

I think the starting point should have been previously, and in the con= text of the current suggestions should be, performance numbers based on act= ual experiments using the protocols in question (and alternatives where alt= ernatives have been suggested). In fact, the results from such testing shou= ld help inform discussion on acceptable performance, and those acceptable l= evels should be based on real-world observations of absolute rates.

=A0
such as:

what security services are being supplied?
who is involved in the service - where is the service applied and where val= idated?
what is being protected?
what are the components and the architecture?

etc.

This can be addressed, for the mom= ent, in a "Napoleon Dynamite" fashion.
- whatever is ne= eded
- whoever wants to=A0=A0& what do you mean by "serv= ice being validated"?
- bgp paths vs threats
- whatever they need to be, and whate= ver works

The basic thing here is, I'm asking = the question, "Why is the heavy-duty crypto needed?".
When I start using formal logic, I take a bunch of axioms, and rules based = off those axioms.
Then, take a hypothetical additional piece of l= ogic (rule or assumption), and see what it can be reduced to, in terms of w= hich axioms or rules are violated.

Working backwards, it appears the crypto is needed beca= use all the validation is based on information passed in-band.
Wi= thout the crypto, anyone can take part of another update, and forge additio= ns to it, or changes to it, trivially. (That's the case with vanilla BG= P, too.)

The additional assumption is, assume some OOB validatio= n process, e.g. suing an outside-of-BGP communication path of some sort.

And my question was, if we start the analysis by ign= oring the details of the OOB system, but merely presume it exists as an adj= unct, what are the minimum things we can do to tie into that system by addi= ng _something_ to BGP updates, and how does that change the performance (an= d thus cost) of on-router stuff?

The reason it is fair to ignore the OOB element is, tha= t unlike on-router stuff, the possibility of achieving scaling benefits exi= sts, since multiple routers could conceivably use a shared OOB black box.

By definition, on-router stuff can't achieve scalin= g benefits of this sort.

And, also by definition, = there is no requirement that the OOB component look anything like the in-ba= nd stuff. The OOB could conceivably be anything under the sun, and be imple= mented by any existing or new technology. It could use DNSSEC, it could use= IPSEC, it could use LDAP, it could use Kerberos (how, I don't know, bu= t it could), it could even use carrier pigeons or SMTP or SNMP or quantum e= ncryption.

And systemically, any number of topologies are possible= , since they are not fundamentally tied to the topology of the BGP infrastr= ucture itself.

=A0

--Sandy, speaking as wg co-chair



When you speak as wg co= -chair, I think it is important to be clear on the rationale for any attemp= t to moderate on-topic discussion. No offense intended, but not providing r= ationale looks to WG participants as political.

Thanks,
Brian
=A0
=A0
________________________________________
From: sidr-bounces@ietf.org [<= a href=3D"mailto:sidr-bounces@ietf.org">sidr-bounces@ietf.org] on behal= f of Sriram, Kotikalapudi [= kotikalapudi.sriram@nist.gov]
Sent: Thursday, May 10, 2012 9:05 AM
To: Ross.Anderson@cl.cam.ac.u= k
Cc: sidr wg list (sidr@ietf.org)
Subject: Re: [sidr] Keys and algori= thms for Updates - feasibility analysis? (was Re: RPKI and private keys)
Hi Ross,

The 10,000/s number is Brian Dickson's and
it is not related to ECDSA (or RSA) signing/verification of BGPSEC updates.=

In my work on performance modeling of BGPSEC, I have used the basic
signing/verification measurement data from the eBACS benchmarking effort: http:= //bench.cr.yp.to/results-sign.html
The measurement numbers they report are in the same ballpark as yours for R= SA signing.
However, the BGPSEC spec draft specifies ECDSA-P256, which is much faster t= han RSA-2048 for signing.
(Side note: ECDSA-P256 was also preferred because it results in a much lowe= r size for BGPSEC updates
and hence lower router RIB memory size.
http://www.nist.gov/itl/antd/upload/BGPSEC_RIB_Estimation.= pdf =A0)

Regarding how the eBACS measurement data were used to model BGPSEC CPU perf= ormance,
please see:
http://ripe63.ripe.net/presentations/127-111102.rip= e-crypto-cost.pdf
(slides 10 and 11 summarize signing/verification speeds for various latest = Intel and Cavium processors)
or see,
http://www.ietf.org/proceedings/83/slides/slides-83-sidr-= 7.pdf
(slides 7 and 8).

The performance modeling and measurement work is still evolving and there i= s still ways to go
w.r.t. prototyping of BGPSEC and measurements with actual signed updates, e= tc.

Sriram

________________________________________
From: Ross.Anderson@cl.cam.ac= .uk [rossjanderson@goog= lemail.com]
Sent: Thursday, May 10, 2012 4:35 AM
To: Sriram, Kotikalapudi
Cc: Brian Dickson (brian.p= eter.dickson@gmail.com); sidr wg list (sidr@ietf.org)
Subject: Re: [sidr] Keys and algorithms for Updates - feasibility analysis?= (was Re: RPKI and private keys)

Sriram

You can't get 10,000 signature creations and verifications a second on<= br> a standard Intel core. You can get maybe 100.

Your colleagues who work on smart grid standards have experience of
this. The IEC working group assumed that all LAN traffic in
electricity substations could be authenticated by digital signatures.
This turned out to not work, and caused a major stall in the smart
grid security program. Some substation LAN traffic has a hard
end-to-end latency bound of 4ms, and that simply can't be achieved on standard cores using 1024-bit RSA signatures. You need custom
hardware, which brings serious export control headaches as well as
significant costs. We wrote this up in

=A0http://www.cl.cam.ac.uk/~sf392/publications/S4-1010.pdf<= br>
Ross
_______________________= ________________________
sidr mailing list
sidr@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/sidr
_______________________________________________
sidr mailing list
sidr@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/sidr

--f46d043c801cbe4d8804bfc7f713-- From christopher.morrow@gmail.com Fri May 11 13:20:19 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B931321F873A for ; Fri, 11 May 2012 13:20:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.574 X-Spam-Level: X-Spam-Status: No, score=-103.574 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T5zfBJ0kcKrn for ; Fri, 11 May 2012 13:20:19 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3353821F8716 for ; Fri, 11 May 2012 13:20:19 -0700 (PDT) Received: by obbeh20 with SMTP id eh20so4452044obb.31 for ; Fri, 11 May 2012 13:20:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=kkSsjv7vn+AnINarAdISAag3B3uNvy7wSO9jiojebbw=; b=sJu/QvVOZEkodKSVnnawGA8KBS0dy8vd7olLQRPWlNlXQOh7UYaoBQwT5emcFGGNDw nYsq4CKTBKTQGhw5xrFJaIcgPgmzK5FddqV04iU876A1wPksQP2Che+yCAM2/GTBEcPy 90t31WG95iVA0Lr0MX6+Poniad5JL/ojTaYIBfEB2bAApr+za54ycqLlhIe/jwgR8ZLL m+U986CXVuEJrti/tDbzDludn8XnorHl48XlmAVD3TuaKwdTftLgOMnCN4KNuyzm+9DJ POaZcLPO5tzIDiay6sBk/HOEZSvzhvACcWSedekSPLZWqDQ2drhglTB/t6et91eujWAO NARQ== MIME-Version: 1.0 Received: by 10.182.31.11 with SMTP id w11mr13509839obh.64.1336767618859; Fri, 11 May 2012 13:20:18 -0700 (PDT) Sender: christopher.morrow@gmail.com Received: by 10.182.166.71 with HTTP; Fri, 11 May 2012 13:20:18 -0700 (PDT) In-Reply-To: References: <24B20D14B2CD29478C8D5D6E9CBB29F60F70871E@Hermes.columbia.ads.sparta.com> Date: Fri, 11 May 2012 16:20:18 -0400 X-Google-Sender-Auth: 5LMQPsjmYkPYBStp2kqcfFJ9ARQ Message-ID: From: Christopher Morrow To: Brian Dickson Content-Type: text/plain; charset=ISO-8859-1 Cc: "Sriram, Kotikalapudi" , "Murphy, Sandra" , "sidr wg list \(sidr@ietf.org\)" Subject: Re: [sidr] Keys and algorithms for Updates - feasibility analysis? (was Re: RPKI and private keys) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 May 2012 20:20:19 -0000 On Fri, May 11, 2012 at 3:44 PM, Brian Dickson wrote: > It has been proposed that a roadmap timeframe of 5-7 years is acceptable, in > order that vendors provide hardware-based implementations. No justification > for this has been offered, beyond "well, it is common sense". I believe the timeframes take into account common larger-network depreciation rates for equipment. core -> agg -> fastedge -> hinter-lands-edge -> gone takes ~4-7 years... or so network folk had said (this came out in the RAWS WG as well, in 2006) -chris From Sandra.Murphy@sparta.com Fri May 11 13:31:15 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8380D21F86D8 for ; Fri, 11 May 2012 13:31:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.64 X-Spam-Level: X-Spam-Status: No, score=-102.64 tagged_above=-999 required=5 tests=[AWL=-0.041, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xFL69pZJdd63 for ; Fri, 11 May 2012 13:31:14 -0700 (PDT) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by ietfa.amsl.com (Postfix) with ESMTP id DEE8921F86CB for ; Fri, 11 May 2012 13:31:13 -0700 (PDT) Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.14.4/8.14.4) with ESMTP id q4BKV7b4007859; Fri, 11 May 2012 15:31:07 -0500 Received: from Hermes.columbia.ads.sparta.com ([157.185.80.107]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id q4BKV3vT022089; Fri, 11 May 2012 15:31:03 -0500 Received: from HERMES.columbia.ads.sparta.com ([2002:9db9:506b::9db9:506b]) by Hermes.columbia.ads.sparta.com ([::1]) with mapi id 14.01.0355.002; Fri, 11 May 2012 16:31:03 -0400 From: "Murphy, Sandra" To: Brian Dickson Thread-Topic: [sidr] Keys and algorithms for Updates - feasibility analysis? (was Re: RPKI and private keys) Thread-Index: Ac0sn4X5MzR08xoIOkyL58SFwPpB3QACMZ1AAAAFxZAAgD6ygAAJaygAAAyS9W8AM6ymAP//vb/c Date: Fri, 11 May 2012 20:31:02 +0000 Message-ID: <24B20D14B2CD29478C8D5D6E9CBB29F60F709A01@Hermes.columbia.ads.sparta.com> References: <24B20D14B2CD29478C8D5D6E9CBB29F60F70871E@Hermes.columbia.ads.sparta.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.185.63.118] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "sidr wg list \(sidr@ietf.org\)" , "Sriram, Kotikalapudi" Subject: Re: [sidr] Keys and algorithms for Updates - feasibility analysis? (was Re: RPKI and private keys) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 May 2012 20:31:15 -0000 Answering a response to a statement made as wg chair=0A= =0A= wrt:=0A= =0A= Brian Dickson [brian.peter.dickson@gmail.com] said on Friday, May 11, 2012 = 3:44 PM=0A= =0A= >On Fri, May 11, 2012 at 2:00 PM, Murphy, Sandra =0A= > wrote:=0A= >=0A= >=0A= >>Before we get too involved in discussing performance and different =0A= >>methods of measuring performance, I think it is very important to =0A= >>address the features of what Brian is suggesting;=0A= =0A= =0A= >Would you be so kind as to explain why you believe this is important? =0A= =0A= I believe that analyzing performance measures of a system is premature befo= re its features are at least well enough established to understand that it = meets the requirements and does not have systemic architectural drawbacks.= =0A= =0A= To choose an extreme example, for illustrative purposes only, the NULL algo= rithm has really wonderful performance measures, but would not suit the pur= pose.=0A= =0A= Furthermore, it is difficult to know what performance to measure if the sys= tem is not understood to some degree.=0A= =0A= --Sandy, answering as wg co-chair=0A= =0A= =0A= From: Brian Dickson [brian.peter.dickson@gmail.com]=0A= =0A= Sent: Friday, May 11, 2012 3:44 PM=0A= =0A= To: Murphy, Sandra=0A= =0A= Cc: Sriram, Kotikalapudi; Ross.Anderson@cl.cam.ac.uk; sidr wg list (sidr@ie= tf.org)=0A= =0A= Subject: Re: [sidr] Keys and algorithms for Updates - feasibility analysis?= (was Re: RPKI and private keys)=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= On Fri, May 11, 2012 at 2:00 PM, Murphy, Sandra =0A= wrote:=0A= =0A= =0A= Before we get too involved in discussing performance and different methods = of measuring performance, I think it is very important to address the featu= res of what Brian is suggesting;=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Would you be so kind as to explain why you believe this is important? It's = not like the WG mailing list is overloaded or the participants doing much (= or even responding very much, it would seem.)=0A= I was asked about this at the interim meeting, and there were many SIDR par= ticipants who were not at the meeting (physically or remotely.) My follow-u= p is pretty much required, just to inform the rest of the participants.=0A= =0A= =0A= =0A= We have not had, to the best of my knowledge, any (or much at all if there = was some) in-SIDR discussion of performance metrics on the proposed mechani= sms, when implemented in software, or when implemented in hardware.=0A= =0A= =0A= =0A= It has been proposed that a roadmap timeframe of 5-7 years is acceptable, i= n order that vendors provide hardware-based implementations. No justificati= on for this has been offered, beyond "well, it is common sense".=0A= =0A= =0A= =0A= The requirements doc explicitly calls out hardware-based solutions as accep= table, without any cost analysis or cost/benefit analysis, or absolute perf= ormance metrics for requirements.=0A= =0A= =0A= =0A= I think the starting point should have been previously, and in the context = of the current suggestions should be, performance numbers based on actual e= xperiments using the protocols in question (and alternatives where alternat= ives have been suggested).=0A= In fact, the results from such testing should help inform discussion on ac= ceptable performance, and those acceptable levels should be based on real-w= orld observations of absolute rates.=0A= =0A= =0A= =0A= =0A= =0A= such as:=0A= =0A= =0A= =0A= what security services are being supplied?=0A= =0A= who is involved in the service - where is the service applied and where val= idated?=0A= =0A= what is being protected?=0A= =0A= what are the components and the architecture?=0A= =0A= =0A= =0A= etc.=0A= =0A= =0A= =0A= =0A= =0A= This can be addressed, for the moment, in a "Napoleon Dynamite" fashion.=0A= - whatever is needed=0A= - whoever wants to & what do you mean by "service being validated"?=0A= - bgp paths vs threats=0A= - whatever they need to be, and whatever works=0A= =0A= =0A= =0A= The basic thing here is, I'm asking the question, "Why is the heavy-duty cr= ypto needed?".=0A= When I start using formal logic, I take a bunch of axioms, and rules based = off those axioms.=0A= Then, take a hypothetical additional piece of logic (rule or assumption), a= nd see what it can be reduced to, in terms of which axioms or rules are vio= lated.=0A= =0A= =0A= =0A= Working backwards, it appears the crypto is needed because all the validati= on is based on information passed in-band.=0A= Without the crypto, anyone can take part of another update, and forge addit= ions to it, or changes to it, trivially. (That's the case with vanilla BGP,= too.)=0A= =0A= =0A= =0A= The additional assumption is, assume some OOB validation process, e.g. suin= g an outside-of-BGP communication path of some sort.=0A= =0A= =0A= =0A= And my question was, if we start the analysis by ignoring the details of th= e OOB system, but merely presume it exists as an adjunct, what are the mini= mum things we can do to tie into that system by adding _something_ to BGP u= pdates, and how does that change=0A= the performance (and thus cost) of on-router stuff?=0A= =0A= =0A= =0A= The reason it is fair to ignore the OOB element is, that unlike on-router s= tuff, the possibility of achieving scaling benefits exists, since multiple = routers could conceivably use a shared OOB black box.=0A= =0A= =0A= =0A= By definition, on-router stuff can't achieve scaling benefits of this sort.= =0A= =0A= =0A= =0A= And, also by definition, there is no requirement that the OOB component loo= k anything like the in-band stuff. The OOB could conceivably be anything un= der the sun, and be implemented by any existing or new technology. It could= use DNSSEC, it could use IPSEC,=0A= it could use LDAP, it could use Kerberos (how, I don't know, but it could)= , it could even use carrier pigeons or SMTP or SNMP or quantum encryption.= =0A= =0A= =0A= =0A= And systemically, any number of topologies are possible, since they are not= fundamentally tied to the topology of the BGP infrastructure itself.=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= --Sandy, speaking as wg co-chair=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= When you speak as wg co-chair, I think it is important to be clear on the r= ationale for any attempt to moderate on-topic discussion. No offense intend= ed, but not providing rationale looks to WG participants as political.=0A= =0A= =0A= =0A= Thanks,=0A= Brian=0A= =0A= =0A= =0A= =0A= ________________________________________=0A= =0A= From: =0A= sidr-bounces@ietf.org [sidr-bounces@ietf.org] on behalf of Sriram, Kotikala= pudi [kotikalapudi.sriram@nist.gov]=0A= =0A= Sent: Thursday, May 10, 2012 9:05 AM=0A= =0A= To: =0A= Ross.Anderson@cl.cam.ac.uk=0A= =0A= Cc: sidr wg list (sidr@ietf.org)=0A= =0A= =0A= Subject: Re: [sidr] Keys and algorithms for Updates - feasibility analysis?= (was Re: RPKI and private keys)=0A= =0A= =0A= =0A= Hi Ross,=0A= =0A= =0A= =0A= The 10,000/s number is Brian Dickson's and=0A= =0A= it is not related to ECDSA (or RSA) signing/verification of BGPSEC updates.= =0A= =0A= =0A= =0A= In my work on performance modeling of BGPSEC, I have used the basic=0A= =0A= signing/verification measurement data from the eBACS benchmarking effort:= =0A= =0A= http://bench.cr.yp.to/results-sign.html=0A= =0A= The measurement numbers they report are in the same ballpark as yours for R= SA signing.=0A= =0A= However, the BGPSEC spec draft specifies ECDSA-P256, which is much faster t= han RSA-2048 for signing.=0A= =0A= (Side note: ECDSA-P256 was also preferred because it results in a much lowe= r size for BGPSEC updates=0A= =0A= and hence lower router RIB memory size.=0A= =0A= http://www.nist.gov/itl/antd/upload/BGPSEC_RIB_Estimation.pdf )=0A= =0A= =0A= =0A= Regarding how the eBACS measurement data were used to model BGPSEC CPU perf= ormance,=0A= =0A= please see:=0A= =0A= http://ripe63.ripe.net/presentations/127-111102.ripe-crypto-cost.pdf=0A= =0A= (slides 10 and 11 summarize signing/verification speeds for various latest = Intel and Cavium processors)=0A= =0A= or see,=0A= =0A= http://www.ietf.org/proceedings/83/slides/slides-83-sidr-7.pdf=0A= =0A= (slides 7 and 8).=0A= =0A= =0A= =0A= The performance modeling and measurement work is still evolving and there i= s still ways to go=0A= =0A= w.r.t. prototyping of BGPSEC and measurements with actual signed updates, e= tc.=0A= =0A= =0A= =0A= Sriram=0A= =0A= =0A= =0A= ________________________________________=0A= =0A= From: =0A= Ross.Anderson@cl.cam.ac.uk [rossjanderson@googlemail.com]=0A= =0A= Sent: Thursday, May 10, 2012 4:35 AM=0A= =0A= To: Sriram, Kotikalapudi=0A= =0A= Cc: Brian Dickson (brian.peter.dickson@gmail.com); sidr wg list (sidr@ietf.= org)=0A= =0A= Subject: Re: [sidr] Keys and algorithms for Updates - feasibility analysis?= (was Re: RPKI and private keys)=0A= =0A= =0A= =0A= Sriram=0A= =0A= =0A= =0A= You can't get 10,000 signature creations and verifications a second on=0A= =0A= a standard Intel core. You can get maybe 100.=0A= =0A= =0A= =0A= Your colleagues who work on smart grid standards have experience of=0A= =0A= this. The IEC working group assumed that all LAN traffic in=0A= =0A= electricity substations could be authenticated by digital signatures.=0A= =0A= This turned out to not work, and caused a major stall in the smart=0A= =0A= grid security program. Some substation LAN traffic has a hard=0A= =0A= end-to-end latency bound of 4ms, and that simply can't be achieved on=0A= =0A= standard cores using 1024-bit RSA signatures. You need custom=0A= =0A= hardware, which brings serious export control headaches as well as=0A= =0A= significant costs. We wrote this up in=0A= =0A= =0A= =0A= http://www.cl.cam.ac.uk/~sf392/publications/S4-1010.pdf=0A= =0A= =0A= =0A= Ross=0A= =0A= =0A= =0A= =0A= _______________________________________________=0A= =0A= sidr mailing list=0A= =0A= sidr@ietf.org=0A= =0A= https://www.ietf.org/mailman/listinfo/sidr=0A= =0A= _______________________________________________=0A= =0A= sidr mailing list=0A= =0A= sidr@ietf.org=0A= =0A= https://www.ietf.org/mailman/listinfo/sidr=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= From brian.peter.dickson@gmail.com Fri May 11 14:19:07 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F4EF21F85AF for ; Fri, 11 May 2012 14:19:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.498 X-Spam-Level: X-Spam-Status: No, score=-3.498 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2jnKDevuvQez for ; Fri, 11 May 2012 14:19:05 -0700 (PDT) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 9EF8221F8566 for ; Fri, 11 May 2012 14:19:04 -0700 (PDT) Received: by wgbdr13 with SMTP id dr13so2168237wgb.13 for ; Fri, 11 May 2012 14:19: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:date:message-id:subject:from:to :cc:content-type; bh=AkKYDpBncEklqZj1r2EWP6KmvFpC4wIZammPbqIqAYU=; b=Q361/V1a5m7DioEckkIYBo/QjyVQ+MILiJCbGxADT0jXKm4rkpytCgNLhPhgaTt2gy aaEoBFRICKPRDtDASERBKngfS7s0TcjoiNcWAzW9vBTapX++RAngwBKOFQ5XK19FZuui p47FZcXr6P49sxMvaQChw7/96cEsnALAGSyO+361PmOIPmU4Ym4bXvbVwICKcf/CspGY RYJnRzigpcTHqGFV1gBC1Ex0fjGtxLO4w02/eVoAnF2aHYeoBYkf1BbSg0xUfClhsQeX nYClEjOriq7TwFlJBHW9UCHKKvTItUplAMPOaWF4gQS95AwNtETW3khRJJs9mGuXM5qt cEzw== MIME-Version: 1.0 Received: by 10.180.106.9 with SMTP id gq9mr11239670wib.17.1336771143742; Fri, 11 May 2012 14:19:03 -0700 (PDT) Received: by 10.223.93.138 with HTTP; Fri, 11 May 2012 14:19:03 -0700 (PDT) In-Reply-To: <24B20D14B2CD29478C8D5D6E9CBB29F60F709A01@Hermes.columbia.ads.sparta.com> References: <24B20D14B2CD29478C8D5D6E9CBB29F60F70871E@Hermes.columbia.ads.sparta.com> <24B20D14B2CD29478C8D5D6E9CBB29F60F709A01@Hermes.columbia.ads.sparta.com> Date: Fri, 11 May 2012 17:19:03 -0400 Message-ID: From: Brian Dickson To: "Murphy, Sandra" Content-Type: multipart/alternative; boundary=f46d04451a152b35d104bfc949cb Cc: "sidr wg list \(sidr@ietf.org\)" , "Sriram, Kotikalapudi" Subject: Re: [sidr] Keys and algorithms for Updates - feasibility analysis? (was Re: RPKI and private keys) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 May 2012 21:19:07 -0000 --f46d04451a152b35d104bfc949cb Content-Type: text/plain; charset=ISO-8859-1 While analysis of a completed system is valuable, it also requires analysis of the components of the system. If we want to consider any solution to the requirements, I believe we need to perform analysis on the performance of the components, as well as of the system, and validate that it meets the requirements. So, when do you suggest doing that for the system and components specified in the -protocol document and in the -requirements document? If you aren't going to do that, then I suggest that doing analysis and comparison on components is valid. What I am looking at is exclusively the following elements: (1) the signatures for the -protocol document (and _explicitly_ excluding the validation steps, which will be necessary regardless of solution), versus (2) the nonces for my comparative performance suggestion (N bit nonces constructed using N/32 independently generated PNRG 32-bit values (with N/32 different seeds)). Comparative analysis of the validation components and system of the -protocol, along with suggested OOB methods (plural - once you go OOB you have as many options as you want, and those aren't limited to ones already suggested by me) are still going to be needed to do a complete comparison. However, the results for (1) and (2) are likely to provide motivation for the related follow-on work. Your choice of NULL as a way of discrediting alternatives is quite telling. What about the risks vs performance of CRC-32, or MD4, or ROT13? Shared-key cyphers are well-known and have superb performance characteristics with predictable risk. It is suitable for the purpose, IFF the architecture avoids exposing key data. You have already said that you presume (in the case of on-router private key data) that key data would never be exposed. So, does this mean we can now make similar assumptions about competing architectures? Or do you want to supply a legitimate risk analysis of key management practices, predictable-text risks, entropy sources, etc., for the primary SIDR proposal(s)? Brian P.S. The same argument for the incompletely specified proposals holds - the SIDR bgpsec system is incompletely specified, so it follows there is no reason to not allow competing (incompletely specified) proposals, certainly not on the basis of being incompletely specified, nor on the basis of quantitative benefits of system components. On Fri, May 11, 2012 at 4:31 PM, Murphy, Sandra wrote: > Answering a response to a statement made as wg chair > > wrt: > > Brian Dickson [brian.peter.dickson@gmail.com] said on Friday, May 11, > 2012 3:44 PM > > >On Fri, May 11, 2012 at 2:00 PM, Murphy, Sandra > > wrote: > > > > > >>Before we get too involved in discussing performance and different > >>methods of measuring performance, I think it is very important to > >>address the features of what Brian is suggesting; > > > >Would you be so kind as to explain why you believe this is important? > > I believe that analyzing performance measures of a system is premature > before its features are at least well enough established to understand that > it meets the requirements and does not have systemic architectural > drawbacks. > > To choose an extreme example, for illustrative purposes only, the NULL > algorithm has really wonderful performance measures, but would not suit the > purpose. > > Furthermore, it is difficult to know what performance to measure if the > system is not understood to some degree. > > --Sandy, answering as wg co-chair > > > From: Brian Dickson [brian.peter.dickson@gmail.com] > > Sent: Friday, May 11, 2012 3:44 PM > > To: Murphy, Sandra > > Cc: Sriram, Kotikalapudi; Ross.Anderson@cl.cam.ac.uk; sidr wg list ( > sidr@ietf.org) > > Subject: Re: [sidr] Keys and algorithms for Updates - feasibility > analysis? (was Re: RPKI and private keys) > > > > > > > > > > On Fri, May 11, 2012 at 2:00 PM, Murphy, Sandra > wrote: > > > Before we get too involved in discussing performance and different methods > of measuring performance, I think it is very important to address the > features of what Brian is suggesting; > > > > > > > > Would you be so kind as to explain why you believe this is important? It's > not like the WG mailing list is overloaded or the participants doing much > (or even responding very much, it would seem.) > I was asked about this at the interim meeting, and there were many SIDR > participants who were not at the meeting (physically or remotely.) My > follow-up is pretty much required, just to inform the rest of the > participants. > > > > We have not had, to the best of my knowledge, any (or much at all if there > was some) in-SIDR discussion of performance metrics on the proposed > mechanisms, when implemented in software, or when implemented in hardware. > > > > It has been proposed that a roadmap timeframe of 5-7 years is acceptable, > in order that vendors provide hardware-based implementations. No > justification for this has been offered, beyond "well, it is common sense". > > > > The requirements doc explicitly calls out hardware-based solutions as > acceptable, without any cost analysis or cost/benefit analysis, or absolute > performance metrics for requirements. > > > > I think the starting point should have been previously, and in the context > of the current suggestions should be, performance numbers based on actual > experiments using the protocols in question (and alternatives where > alternatives have been suggested). > In fact, the results from such testing should help inform discussion on > acceptable performance, and those acceptable levels should be based on > real-world observations of absolute rates. > > > > > > such as: > > > > what security services are being supplied? > > who is involved in the service - where is the service applied and where > validated? > > what is being protected? > > what are the components and the architecture? > > > > etc. > > > > > > This can be addressed, for the moment, in a "Napoleon Dynamite" fashion. > - whatever is needed > - whoever wants to & what do you mean by "service being validated"? > - bgp paths vs threats > - whatever they need to be, and whatever works > > > > The basic thing here is, I'm asking the question, "Why is the heavy-duty > crypto needed?". > When I start using formal logic, I take a bunch of axioms, and rules based > off those axioms. > Then, take a hypothetical additional piece of logic (rule or assumption), > and see what it can be reduced to, in terms of which axioms or rules are > violated. > > > > Working backwards, it appears the crypto is needed because all the > validation is based on information passed in-band. > Without the crypto, anyone can take part of another update, and forge > additions to it, or changes to it, trivially. (That's the case with vanilla > BGP, too.) > > > > The additional assumption is, assume some OOB validation process, e.g. > suing an outside-of-BGP communication path of some sort. > > > > And my question was, if we start the analysis by ignoring the details of > the OOB system, but merely presume it exists as an adjunct, what are the > minimum things we can do to tie into that system by adding _something_ to > BGP updates, and how does that change > the performance (and thus cost) of on-router stuff? > > > > The reason it is fair to ignore the OOB element is, that unlike on-router > stuff, the possibility of achieving scaling benefits exists, since multiple > routers could conceivably use a shared OOB black box. > > > > By definition, on-router stuff can't achieve scaling benefits of this sort. > > > > And, also by definition, there is no requirement that the OOB component > look anything like the in-band stuff. The OOB could conceivably be anything > under the sun, and be implemented by any existing or new technology. It > could use DNSSEC, it could use IPSEC, > it could use LDAP, it could use Kerberos (how, I don't know, but it > could), it could even use carrier pigeons or SMTP or SNMP or quantum > encryption. > > > > And systemically, any number of topologies are possible, since they are > not fundamentally tied to the topology of the BGP infrastructure itself. > > > > > > > > --Sandy, speaking as wg co-chair > > > > > > > > > > > When you speak as wg co-chair, I think it is important to be clear on the > rationale for any attempt to moderate on-topic discussion. No offense > intended, but not providing rationale looks to WG participants as political. > > > > Thanks, > Brian > > > > > ________________________________________ > > From: > sidr-bounces@ietf.org [sidr-bounces@ietf.org] on behalf of Sriram, > Kotikalapudi [kotikalapudi.sriram@nist.gov] > > Sent: Thursday, May 10, 2012 9:05 AM > > To: > Ross.Anderson@cl.cam.ac.uk > > Cc: sidr wg list (sidr@ietf.org) > > > Subject: Re: [sidr] Keys and algorithms for Updates - feasibility > analysis? (was Re: RPKI and private keys) > > > > Hi Ross, > > > > The 10,000/s number is Brian Dickson's and > > it is not related to ECDSA (or RSA) signing/verification of BGPSEC updates. > > > > In my work on performance modeling of BGPSEC, I have used the basic > > signing/verification measurement data from the eBACS benchmarking effort: > > http://bench.cr.yp.to/results-sign.html > > The measurement numbers they report are in the same ballpark as yours for > RSA signing. > > However, the BGPSEC spec draft specifies ECDSA-P256, which is much faster > than RSA-2048 for signing. > > (Side note: ECDSA-P256 was also preferred because it results in a much > lower size for BGPSEC updates > > and hence lower router RIB memory size. > > http://www.nist.gov/itl/antd/upload/BGPSEC_RIB_Estimation.pdf ) > > > > Regarding how the eBACS measurement data were used to model BGPSEC CPU > performance, > > please see: > > http://ripe63.ripe.net/presentations/127-111102.ripe-crypto-cost.pdf > > (slides 10 and 11 summarize signing/verification speeds for various latest > Intel and Cavium processors) > > or see, > > http://www.ietf.org/proceedings/83/slides/slides-83-sidr-7.pdf > > (slides 7 and 8). > > > > The performance modeling and measurement work is still evolving and there > is still ways to go > > w.r.t. prototyping of BGPSEC and measurements with actual signed updates, > etc. > > > > Sriram > > > > ________________________________________ > > From: > Ross.Anderson@cl.cam.ac.uk [rossjanderson@googlemail.com] > > Sent: Thursday, May 10, 2012 4:35 AM > > To: Sriram, Kotikalapudi > > Cc: Brian Dickson (brian.peter.dickson@gmail.com); sidr wg list ( > sidr@ietf.org) > > Subject: Re: [sidr] Keys and algorithms for Updates - feasibility > analysis? (was Re: RPKI and private keys) > > > > Sriram > > > > You can't get 10,000 signature creations and verifications a second on > > a standard Intel core. You can get maybe 100. > > > > Your colleagues who work on smart grid standards have experience of > > this. The IEC working group assumed that all LAN traffic in > > electricity substations could be authenticated by digital signatures. > > This turned out to not work, and caused a major stall in the smart > > grid security program. Some substation LAN traffic has a hard > > end-to-end latency bound of 4ms, and that simply can't be achieved on > > standard cores using 1024-bit RSA signatures. You need custom > > hardware, which brings serious export control headaches as well as > > significant costs. We wrote this up in > > > > http://www.cl.cam.ac.uk/~sf392/publications/S4-1010.pdf > > > > Ross > > > > > _______________________________________________ > > sidr mailing list > > sidr@ietf.org > > https://www.ietf.org/mailman/listinfo/sidr > > _______________________________________________ > > sidr mailing list > > sidr@ietf.org > > https://www.ietf.org/mailman/listinfo/sidr > > > > > > > > > > > --f46d04451a152b35d104bfc949cb Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable While analysis of a completed system is valuable, it also requires analysis= of the components of the system.

If we want to consider= any solution to the requirements, I believe we need to perform analysis on= the performance of the components, as well as of the system, and validate = that it meets the requirements.

So, when do you suggest doing that for the system and c= omponents specified in the -protocol document and in the -requirements docu= ment?

If you aren't going to do that, then I s= uggest that doing analysis and comparison on components is valid.

What I am looking at is exclusively the following eleme= nts:
(1) the signatures for the -protocol document (and _explicit= ly_ excluding the validation steps, which will be necessary regardless of s= olution), versus
(2) the nonces for my comparative performance suggestion (N bit nonces= constructed using N/32 independently generated PNRG 32-bit values (with N/= 32 different seeds)).

Comparative analysis of the = validation components and system of the -protocol, along with suggested OOB= methods (plural - once you go OOB you have as many options as you want, an= d those aren't limited to ones already suggested by me) are still going= to be needed to do a complete comparison.

However, the results for (1) and (2) are likely to prov= ide motivation for the related follow-on work.

You= r choice of NULL as a way of discrediting alternatives is quite telling. Wh= at about the risks vs performance of CRC-32, or MD4, or ROT13?

Shared-key cyphers are well-known and have superb perfo= rmance characteristics with predictable risk. It is suitable for the purpos= e, IFF the architecture avoids exposing key data.

You have already said that you presume (in the case of on-router private ke= y data) that key data would never be exposed.

So, = does this mean we can now make similar assumptions about competing architec= tures?

Or do you want to supply a legitimate risk analysis of = key management practices, predictable-text risks, entropy sources, etc., fo= r the primary SIDR proposal(s)?

Brian

P.S. The same argument for the incompletely specified propos= als holds - the SIDR bgpsec system is incompletely specified, so it follows= there is no reason to not allow competing (incompletely specified) proposa= ls, certainly not on the basis of being incompletely specified, nor on the = basis of quantitative benefits of system components.

On Fri, May 11, 2012 at 4:31 PM, Murphy, San= dra <Sandra.Murphy@sparta.com> wrote:
Answering a response to a statement made as wg chair

wrt:

Brian Dickson [brian.peter= .dickson@gmail.com] said on Friday, May 11, 2012 3:44 PM

>On Fri, May 11, 2012 at 2:00 PM, Murphy, Sandra
><Sandra.Murphy@sparta.co= m> wrote:
>
>
>>Before we get too involved in discussing performance and different<= br> >>methods of measuring performance, I think it is very important to >>address the features of what Brian is suggesting;


>Would you be so kind as to explain why you believe this is important?
I believe that analyzing performance measures of a system is prematur= e before its features are at least well enough established to understand th= at it meets the requirements and does not have systemic architectural drawb= acks.

To choose an extreme example, for illustrative purposes only, the NULL algo= rithm has really wonderful performance measures, but would not suit the pur= pose.

Furthermore, it is difficult to know what performance to measure if the sys= tem is not understood to some degree.

--Sandy, answering as wg co-chair


From: Brian Dickson [brian= .peter.dickson@gmail.com]

Sent: Friday, May 11, 2012 3:44 PM

To: Murphy, Sandra

Cc: Sriram, Kotikalapudi; Ros= s.Anderson@cl.cam.ac.uk; sidr wg list (sidr@ietf.org)

Subject: Re: [sidr] Keys and algorithms for Updates - feasibility analysis?= (was Re: RPKI and private keys)









On Fri, May 11, 2012 at 2:00 PM, Murphy, Sandra
<Sandra.Murphy@sparta.com> wrote:


Before we get too involved in discussing performance and different methods = of measuring performance, I think it is very important to address the featu= res of what Brian is suggesting;







Would you be so kind as to explain why you believe this is important? It= 9;s not like the WG mailing list is overloaded or the participants doing mu= ch (or even responding very much, it would seem.)
I was asked about this at the interim meeting, and there were many SIDR par= ticipants who were not at the meeting (physically or remotely.) My follow-u= p is pretty much required, just to inform the rest of the participants.



We have not had, to the best of my knowledge, any (or much at all if there = was some) in-SIDR discussion of performance metrics on the proposed mechani= sms, when implemented in software, or when implemented in hardware.



It has been proposed that a roadmap timeframe of 5-7 years is acceptable, i= n order that vendors provide hardware-based implementations. No justificati= on for this has been offered, beyond "well, it is common sense".<= br>


The requirements doc explicitly calls out hardware-based solutions as accep= table, without any cost analysis or cost/benefit analysis, or absolute perf= ormance metrics for requirements.



I think the starting point should have been previously, and in the context = of the current suggestions should be, performance numbers based on actual e= xperiments using the protocols in question (and alternatives where alternat= ives have been suggested).
=A0In fact, the results from such testing should help inform discussion on = acceptable performance, and those acceptable levels should be based on real= -world observations of absolute rates.





such as:



what security services are being supplied?

who is involved in the service - where is the service applied and where val= idated?

what is being protected?

what are the components and the architecture?



etc.





This can be addressed, for the moment, in a "Napoleon Dynamite" f= ashion.
- whatever is needed
- whoever wants to =A0& what do you mean by "service being validat= ed"?
- bgp paths vs threats
- whatever they need to be, and whatever works



The basic thing here is, I'm asking the question, "Why is the heav= y-duty crypto needed?".
When I start using formal logic, I take a bunch of axioms, and rules based = off those axioms.
Then, take a hypothetical additional piece of logic (rule or assumption), a= nd see what it can be reduced to, in terms of which axioms or rules are vio= lated.



Working backwards, it appears the crypto is needed because all the validati= on is based on information passed in-band.
Without the crypto, anyone can take part of another update, and forge addit= ions to it, or changes to it, trivially. (That's the case with vanilla = BGP, too.)



The additional assumption is, assume some OOB validation process, e.g. suin= g an outside-of-BGP communication path of some sort.



And my question was, if we start the analysis by ignoring the details of th= e OOB system, but merely presume it exists as an adjunct, what are the mini= mum things we can do to tie into that system by adding _something_ to BGP u= pdates, and how does that change
=A0the performance (and thus cost) of on-router stuff?



The reason it is fair to ignore the OOB element is, that unlike on-router s= tuff, the possibility of achieving scaling benefits exists, since multiple = routers could conceivably use a shared OOB black box.



By definition, on-router stuff can't achieve scaling benefits of this s= ort.



And, also by definition, there is no requirement that the OOB component loo= k anything like the in-band stuff. The OOB could conceivably be anything un= der the sun, and be implemented by any existing or new technology. It could= use DNSSEC, it could use IPSEC,
=A0it could use LDAP, it could use Kerberos (how, I don't know, but it = could), it could even use carrier pigeons or SMTP or SNMP or quantum encryp= tion.



And systemically, any number of topologies are possible, since they are not= fundamentally tied to the topology of the BGP infrastructure itself.







--Sandy, speaking as wg co-chair










When you speak as wg co-chair, I think it is important to be clear on the r= ationale for any attempt to moderate on-topic discussion. No offense intend= ed, but not providing rationale looks to WG participants as political.



Thanks,
Brian




________________________________________

From:
sidr-bounces@ietf.org [sidr-bounces@ietf.org] on behalf of S= riram, Kotikalapudi [kotika= lapudi.sriram@nist.gov]

Sent: Thursday, May 10, 2012 9:05 AM

To:
Ross.Anderson@cl.cam.ac.uk

Cc: sidr wg list (sidr@ietf.org)


Subject: Re: [sidr] Keys and algorithms for Updates - feasibility analysis?= (was Re: RPKI and private keys)



Hi Ross,



The 10,000/s number is Brian Dickson's and

it is not related to ECDSA (or RSA) signing/verification of BGPSEC updates.=



In my work on performance modeling of BGPSEC, I have used the basic

signing/verification measurement data from the eBACS benchmarking effort:
http:= //bench.cr.yp.to/results-sign.html

The measurement numbers they report are in the same ballpark as yours for R= SA signing.

However, the BGPSEC spec draft specifies ECDSA-P256, which is much faster t= han RSA-2048 for signing.

(Side note: ECDSA-P256 was also preferred because it results in a much lowe= r size for BGPSEC updates

and hence lower router RIB memory size.

http://www.nist.gov/itl/antd/upload/BGPSEC_RIB_Estimation.= pdf =A0)



Regarding how the eBACS measurement data were used to model BGPSEC CPU perf= ormance,

please see:

http://ripe63.ripe.net/presentations/127-111102.rip= e-crypto-cost.pdf

(slides 10 and 11 summarize signing/verification speeds for various latest = Intel and Cavium processors)

or see,

http://www.ietf.org/proceedings/83/slides/slides-83-sidr-= 7.pdf

(slides 7 and 8).



The performance modeling and measurement work is still evolving and there i= s still ways to go

w.r.t. prototyping of BGPSEC and measurements with actual signed updates, e= tc.



Sriram



________________________________________

From:
Ross.Anderson@cl.cam.ac.uk [rossjanderson@googlemail= .com]

Sent: Thursday, May 10, 2012 4:35 AM

To: Sriram, Kotikalapudi

Cc: Brian Dickson (brian.p= eter.dickson@gmail.com); sidr wg list (sidr@ietf.org)

Subject: Re: [sidr] Keys and algorithms for Updates - feasibility analysis?= (was Re: RPKI and private keys)



Sriram



You can't get 10,000 signature creations and verifications a second on<= br>
a standard Intel core. You can get maybe 100.



Your colleagues who work on smart grid standards have experience of

this. The IEC working group assumed that all LAN traffic in

electricity substations could be authenticated by digital signatures.

This turned out to not work, and caused a major stall in the smart

grid security program. Some substation LAN traffic has a hard

end-to-end latency bound of 4ms, and that simply can't be achieved on
standard cores using 1024-bit RSA signatures. You need custom

hardware, which brings serious export control headaches as well as

significant costs. We wrote this up in



=A0http://www.cl.cam.ac.uk/~sf392/publications/S4-1010.pdf


Ross




_______________________________________________

sidr mailing list

sidr@ietf.org

ht= tps://www.ietf.org/mailman/listinfo/sidr

_______________________________________________

sidr mailing list

sidr@ietf.org

ht= tps://www.ietf.org/mailman/listinfo/sidr











--f46d04451a152b35d104bfc949cb-- From brian.peter.dickson@gmail.com Fri May 11 14:27:54 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D81321F86B3 for ; Fri, 11 May 2012 14:27:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.523 X-Spam-Level: X-Spam-Status: No, score=-3.523 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dlnElReZQeiR for ; Fri, 11 May 2012 14:27:53 -0700 (PDT) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id EFEB721F862F for ; Fri, 11 May 2012 14:27:52 -0700 (PDT) Received: by wgbdr13 with SMTP id dr13so2171582wgb.13 for ; Fri, 11 May 2012 14:27:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=P6Unc8CzLPIQOCKlY5pUJ+z/q24hOJc4i0+hTAFIX1M=; b=trE3xV0R0afqngTrdM+cudUCG1gphjnIA8Ylt19tFZ6dqvTl5npiuNc63IVz088kvS F3pk1AiyrXa5buawwlMO+7nQ5l0SrKDyYa2ueIKU1bu/7g7O+mXpMnOExUei/gUKo3rX CIfmytqKqiro5mMTX5qEWDLAZiFqGxYRLX8nd6f8hAePRYd7R57s6DVWDYHobfURhmQw ikzkgFglYRuLN/eXQ9Z8xx9gHy699d8sew+wdCpBApe7MeOoiUIx0O8dfqzSaixOB8g7 PJvxoJWeilCDw9pCzc9wIQ6mQFBCJLzbwOfHh14Zw26/htDf5pP3yjNcWPTbkt5eS+kt tekA== MIME-Version: 1.0 Received: by 10.180.83.196 with SMTP id s4mr4354167wiy.15.1336771672130; Fri, 11 May 2012 14:27:52 -0700 (PDT) Received: by 10.223.93.138 with HTTP; Fri, 11 May 2012 14:27:51 -0700 (PDT) In-Reply-To: References: <24B20D14B2CD29478C8D5D6E9CBB29F60F70871E@Hermes.columbia.ads.sparta.com> Date: Fri, 11 May 2012 17:27:51 -0400 Message-ID: From: Brian Dickson To: Christopher Morrow Content-Type: multipart/alternative; boundary=f46d04428eeea9c3bf04bfc9680f Cc: "Sriram, Kotikalapudi" , "Murphy, Sandra" , "sidr wg list \(sidr@ietf.org\)" Subject: Re: [sidr] Keys and algorithms for Updates - feasibility analysis? (was Re: RPKI and private keys) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 May 2012 21:27:54 -0000 --f46d04428eeea9c3bf04bfc9680f Content-Type: text/plain; charset=ISO-8859-1 I was referring to the use of HW-based crypto (which is not cheap), not the timeframe (5-7 years), as having lack of quantitative analysis on cost/benefit, cost barrier to entry, or other supporting justification. The argument that "we can't do the crypto without HW" is circular, when the argument for crypto is "we can include the HW for crypto in the next go-around of HW". If crypto requires HW, the incremental cost needs to be considered, along with justification that shows that the market will accept and fully adopt HW crypto universally. The premise is bgpsec requires universal adoption to have end-to-end delivery of protection. The deployment scenario where anything less than the vast majority of ASNs do bgpsec, quickly devolves to negative cost-benefit. If the only parties deploying bgpsec are a closed set of peers who already trust each other and already do TCP-AO (aka MD5), the net benefit is zero. So, who is going to write up the cost benefit, deployment model (inter-as), and critical mass required document? Or the market analysis (how many routers with this will be needed), vendor survey with committed roadmap (when will this be available, on what platforms)? Or the export restrictions limitations to deployment (serious crypto hardware being deployed to the state-department listed countries?) and/or alternative vendor support? Basically, if the assumption is HW crypto, please go the extra mile and show that this assumption is based on verifiable "stuff", i.e. that this is not just fantasy. Brian On Fri, May 11, 2012 at 4:20 PM, Christopher Morrow wrote: > On Fri, May 11, 2012 at 3:44 PM, Brian Dickson > wrote: > > It has been proposed that a roadmap timeframe of 5-7 years is > acceptable, in > > order that vendors provide hardware-based implementations. No > justification > > for this has been offered, beyond "well, it is common sense". > > I believe the timeframes take into account common larger-network > depreciation rates for equipment. > core -> agg -> fastedge -> hinter-lands-edge -> gone > > takes ~4-7 years... or so network folk had said (this came out in the > RAWS WG as well, in 2006) > > -chris > --f46d04428eeea9c3bf04bfc9680f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I was referring to the use of HW-based crypto (which is not cheap), not the= timeframe (5-7 years), as having lack of quantitative analysis on cost/ben= efit, cost barrier to entry, or other supporting justification.
The arg= ument that "we can't do the crypto without HW" is circular, w= hen the argument for crypto is "we can include the HW for crypto in th= e next go-around of HW".
If crypto requires HW, the incremental cost needs to be considered, al= ong with justification that shows that the market will accept and fully ado= pt HW crypto universally.
The premise is bgpsec requires universa= l adoption to have end-to-end delivery of protection.
The deployment scenario where anything less than the vast majority of = ASNs do bgpsec, quickly devolves to negative cost-benefit.
If the= only parties deploying bgpsec are a closed set of peers who already trust = each other and already do TCP-AO (aka MD5), the net benefit is zero.

So, who is going to write up the cost benefit, deployme= nt model (inter-as), and critical mass required document?
Or the = market analysis (how many routers with this will be needed), vendor survey = with committed roadmap (when will this be available, on what platforms)?
Or the export restrictions limitations to deployment (serious crypto h= ardware being deployed to the state-department listed countries?) and/or al= ternative vendor support?

Basically, if the assump= tion is HW crypto, please go the extra mile and show that this assumption i= s based on verifiable "stuff", i.e. that this is not just fantasy= .

Brian

On Fri, May 11,= 2012 at 4:20 PM, Christopher Morrow <morrowc.lists@gmail.com>= ; wrote:
On Fri, May 11, 2012 at 3:= 44 PM, Brian Dickson
<brian.peter.dickson@gm= ail.com> wrote:
> It has been proposed that a roadmap timeframe of 5-7 years is acceptab= le, in
> order that vendors provide hardware-based implementations. No justific= ation
> for this has been offered, beyond "well, it is common sense"= .

I believe the timeframes take into account common larger-network
depreciation rates for equipment.
=A0core -> agg -> fastedge -> hinter-lands-edge -> gone

takes ~4-7 years... or so network folk had said (this came out in the
RAWS WG as well, in 2006)

-chris

--f46d04428eeea9c3bf04bfc9680f-- From christopher.morrow@gmail.com Fri May 11 18:23:24 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 281DE21F85BE for ; Fri, 11 May 2012 18:23:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.575 X-Spam-Level: X-Spam-Status: No, score=-103.575 tagged_above=-999 required=5 tests=[AWL=0.024, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NT0Y1QSn3H64 for ; Fri, 11 May 2012 18:23:23 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 99B0321F8569 for ; Fri, 11 May 2012 18:23:23 -0700 (PDT) Received: by obbeh20 with SMTP id eh20so4789202obb.31 for ; Fri, 11 May 2012 18:23:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=MVK/kqWkm+0tLECX06sMW3VCUr1/TOG8reuCIEAmuuw=; b=O/QW3G/UEmBTfm2/HDBVCrk1X2tD4nSRbjXSBevmZCSBius81uh/dcERfyFRy1kzFO wCwjcSj6BZP8vNs3/9knBCALBH0eZAo3Xz2WYyJQ4BRMeSQ0XjcHlQsnOLSO8oQGLsod LmM/pPjlgL5ufBpOGK4wVxeY+90CTirGk9f1cffCJJ51odxcu6zBo4bSoWXnHY1QgAAp 5RTz7faqV4nOeinvBEelNDdbnmFYIA3D2OZKvlAaNOkEIV1NpXf/a4jHrnDjGPOGZwnv jBNoWt0J+02UwkM1v7nUMZnlYPQ/hQbqcH7T6cwqKYJferexB0BrEQLW91rxKmRYNCJP HRHQ== MIME-Version: 1.0 Received: by 10.60.1.67 with SMTP id 3mr363565oek.15.1336785803263; Fri, 11 May 2012 18:23:23 -0700 (PDT) Sender: christopher.morrow@gmail.com Received: by 10.182.166.71 with HTTP; Fri, 11 May 2012 18:23:23 -0700 (PDT) In-Reply-To: References: <24B20D14B2CD29478C8D5D6E9CBB29F60F70871E@Hermes.columbia.ads.sparta.com> Date: Fri, 11 May 2012 21:23:23 -0400 X-Google-Sender-Auth: -xDwsNPSE2vG8qNWHTgAyjdulaA Message-ID: From: Christopher Morrow To: Brian Dickson Content-Type: text/plain; charset=ISO-8859-1 Cc: "Sriram, Kotikalapudi" , "Murphy, Sandra" , "sidr wg list \(sidr@ietf.org\)" Subject: Re: [sidr] Keys and algorithms for Updates - feasibility analysis? (was Re: RPKI and private keys) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 May 2012 01:23:24 -0000 On Fri, May 11, 2012 at 5:27 PM, Brian Dickson wrote: > The argument that "we can't do the crypto without HW" i didn't see anyone say that though. From brian.peter.dickson@gmail.com Mon May 14 07:27:37 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1276921F84FF for ; Mon, 14 May 2012 07:27:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.538 X-Spam-Level: X-Spam-Status: No, score=-3.538 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QV4LMUd0mLOe for ; Mon, 14 May 2012 07:27:36 -0700 (PDT) Received: from mail-wg0-f42.google.com (mail-wg0-f42.google.com [74.125.82.42]) by ietfa.amsl.com (Postfix) with ESMTP id E456921F850C for ; Mon, 14 May 2012 07:27:35 -0700 (PDT) Received: by wgbds11 with SMTP id ds11so3436285wgb.1 for ; Mon, 14 May 2012 07:27: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:date:message-id:subject:from:to :cc:content-type; bh=xP/iYbCGP4rfgLiTeEWP1KisJP+4Cm9y5AzSnpO+Dms=; b=XYSJpG0d9gKZqBgSjdcCRyswGGk1ZkzxZUKSAxJklTzyYq3fBMl+Ks0W0HREI39AVC xsygx/vosGH8hKM5+A3tB7Q3WosVHinbgCHKp8Fax0m6kLNxkT644XWVmOmI8bWUfRD8 vySlkfZDTLQLYspvftvgNRj1K+ziQWhX8uDQTUzCB+QvrJORl5TI2CqxGAy9MAZRp8Ec Tj953q885jS69F3RSi7qTJftE2rFsqgwP7A+cOQ6aQrXp1gURh+p+pqtT6ESJSps+eCt pSng4W36bsvYFRhC/o9Md/lQq8tFlZCL2G5AXV9wB1d/XmljxQ8uPYSGan0nRlQaqhem HAEA== MIME-Version: 1.0 Received: by 10.180.87.35 with SMTP id u3mr20414593wiz.11.1337005654943; Mon, 14 May 2012 07:27:34 -0700 (PDT) Received: by 10.223.39.19 with HTTP; Mon, 14 May 2012 07:27:34 -0700 (PDT) In-Reply-To: References: <24B20D14B2CD29478C8D5D6E9CBB29F60F70871E@Hermes.columbia.ads.sparta.com> Date: Mon, 14 May 2012 10:27:34 -0400 Message-ID: From: Brian Dickson To: Christopher Morrow Content-Type: multipart/alternative; boundary=f46d044402be20265a04bfffe3d0 Cc: "Sriram, Kotikalapudi" , "Murphy, Sandra" , "sidr wg list \(sidr@ietf.org\)" Subject: Re: [sidr] Keys and algorithms for Updates - feasibility analysis? (was Re: RPKI and private keys) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 May 2012 14:27:37 -0000 --f46d044402be20265a04bfffe3d0 Content-Type: text/plain; charset=ISO-8859-1 We can't do the crypto without HW on some of the routers involved in deployment of bgpsec. I've heard just about everyone say that, quite possibly including yourself. One of the reasons for questioning the choice of crypto, is exploring the feasibility of solutions which do not require on-router HW for doing signing. Brian On Fri, May 11, 2012 at 9:23 PM, Christopher Morrow wrote: > On Fri, May 11, 2012 at 5:27 PM, Brian Dickson > wrote: > > The argument that "we can't do the crypto without HW" > > i didn't see anyone say that though. > --f46d044402be20265a04bfffe3d0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable We can't do the crypto without HW on some of the routers involved in de= ployment of bgpsec.

I've heard just about everyone say that, qui= te possibly including yourself.

One of the reasons for questioning t= he choice of crypto, is exploring the feasibility of solutions which do not= require on-router HW for doing signing.

Brian

On Fri, May 11, 2012 at 9:23 PM= , Christopher Morrow <morrowc.lists@gmail.com> wrote:<= br>
On Fri, May 11, 2012 at 5:27 PM, Brian Dickson
<brian.peter.dickson@gm= ail.com> wrote:
> The argument that "we can't do the crypto without HW"
i didn't see anyone say that though.

--f46d044402be20265a04bfffe3d0-- From christopher.morrow@gmail.com Mon May 14 07:37:10 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CA5121F87F2 for ; Mon, 14 May 2012 07:37:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.576 X-Spam-Level: X-Spam-Status: No, score=-103.576 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YkwzlybbIHxJ for ; Mon, 14 May 2012 07:37:09 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id C42B121F87F1 for ; Mon, 14 May 2012 07:37:09 -0700 (PDT) Received: by yhq56 with SMTP id 56so5231565yhq.31 for ; Mon, 14 May 2012 07:37:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=PnqsKbxaM4rhp5TIvJoZPzStCXRwgXv2MBJ9oOPhxGQ=; b=A5O2wSKKDzxwjRZo3Wrfe0uWci8oF0aJn6zqaJx5a+xywSNh4/UBwsImqv00P8ScLi W4u2biJwpQUzMoUfU1hlLskOlBuS7nfX5bAvgIR19QBpxNE5aghmi4sDK99YMY4L4wFD A1faAGIPmH7XMaLGiHmXPDgJgS1NpzL6Owj3MW5tYMmq4olAX77esZt0Icz68dDzkDdu STPjvDwQp3U2tLx0GlKAqlMviwNBLNidsNpoyR6JeDIJxI6sMy8PTqaCo3ziI4BzS4ig X/8cIUj5/mOUJe4goU1UuwwqVAhC8Ucok15894tnaAPRA3K7t7p2JoLFzvNYmAJp77J4 1z3A== MIME-Version: 1.0 Received: by 10.60.9.102 with SMTP id y6mr11836944oea.46.1337006229274; Mon, 14 May 2012 07:37:09 -0700 (PDT) Sender: christopher.morrow@gmail.com Received: by 10.182.166.71 with HTTP; Mon, 14 May 2012 07:37:09 -0700 (PDT) In-Reply-To: References: <24B20D14B2CD29478C8D5D6E9CBB29F60F70871E@Hermes.columbia.ads.sparta.com> Date: Mon, 14 May 2012 10:37:09 -0400 X-Google-Sender-Auth: MJc-CJP0NqogUyNq-fKGe8sgCIQ Message-ID: From: Christopher Morrow To: Brian Dickson Content-Type: text/plain; charset=ISO-8859-1 Cc: "Sriram, Kotikalapudi" , "Murphy, Sandra" , "sidr wg list \(sidr@ietf.org\)" Subject: Re: [sidr] Keys and algorithms for Updates - feasibility analysis? (was Re: RPKI and private keys) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 May 2012 14:37:10 -0000 On Mon, May 14, 2012 at 10:27 AM, Brian Dickson wrote: > We can't do the crypto without HW on some of the routers involved in > deployment of bgpsec. > > I've heard just about everyone say that, quite possibly including yourself. I don't think I've said that recently, one of the items brought out during discussions of this was that often the hardware accelerators for this are optimised for 'use one key a lot', not for 'swap in a new key for every operation' (the key swap is very costly). Sriram has some numbers for different co-processors which are interesting, but I don't think that means we need on-board crypto accelerators. > One of the reasons for questioning the choice of crypto, is exploring the > feasibility of solutions which do not require on-router HW for doing > signing. sure, but you also invented a whole other (seemingly complex) system to keep track of data (nonces and such) across multiple trust/administrative domains. it seems unwieldy, to me at least. One of the larger stumbling blocks though is ram for RIB storage. (or that seems to be one of the larger problems to address) -chris > > Brian > > > On Fri, May 11, 2012 at 9:23 PM, Christopher Morrow > wrote: >> >> On Fri, May 11, 2012 at 5:27 PM, Brian Dickson >> wrote: >> > The argument that "we can't do the crypto without HW" >> >> i didn't see anyone say that though. > > From warren@kumari.net Mon May 14 07:37:27 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5339521F8462 for ; Mon, 14 May 2012 07:37:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.698 X-Spam-Level: X-Spam-Status: No, score=-105.698 tagged_above=-999 required=5 tests=[AWL=0.301, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BEFZvNi2737q for ; Mon, 14 May 2012 07:37:26 -0700 (PDT) Received: from vimes.kumari.net (vimes.kumari.net [198.186.192.250]) by ietfa.amsl.com (Postfix) with ESMTP id B559421F845C for ; Mon, 14 May 2012 07:37:26 -0700 (PDT) Received: from dhcp-172-19-118-235.cbf.corp.google.com (unknown [64.13.52.115]) by vimes.kumari.net (Postfix) with ESMTPSA id BAA2F1B402E9; Mon, 14 May 2012 10:37:25 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Warren Kumari In-Reply-To: Date: Mon, 14 May 2012 10:37:24 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <36B96241-E65B-4AF4-9B62-579EC3245D33@kumari.net> References: <4FA48240.9060405@ops-netman.net> <7309FCBCAE981B43ABBE69B31C8D213921BE2860C3@EUSAACMS0701.eamcs.ericsson.se> <20120511025431.D05A6170C1@thrintun.hactrn.net> To: Christopher Morrow X-Mailer: Apple Mail (2.1084) Cc: Rob Austein , sidr wg list Subject: Re: [sidr] RPKI and private keys (was RE: Interim Meeting Draft Agenda: 04-30-2012 (April 30, 2012))) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 May 2012 14:37:27 -0000 On May 11, 2012, at 2:51 PM, Christopher Morrow wrote: > On Fri, May 11, 2012 at 2:43 PM, Randy Bush wrote: >=20 >>> though I contend you have time between 'card fail' and 'router back = to >>> normal' to ship a key in the ether/ssh to the device too. >>=20 >> by the time the replacement re is sufficiently on net to create and = send >> a public key to the noc for signing and publishing, the router is up = and >> has at least some routing data. so the subsequent publication delay >> would be a critical path delay (in the pert sense) to full, i.e. = bgpsec, >> use. >=20 > hrm, so... normally something like this happens: > 1) router go boom > 2) troubleshooting ensues to see where the problem is (what to fix) > 3) RE/RSP is determined to be at fault > 4) spares call placed > 5) spare arrives and is placed into the chassis > 6) reboot/checkout happens > 7) customer links brought back online > 8) things return to 'normal' So, what if[0] the keying material itself is stored in a small EEPROM on = the chassis (well, backplane) itself? The number of times the backplane fails pales in comparison to the = number of RE / line-card failures, and many (most?) architectures = already have an I2C EEPROM on the [back|mid]plane. A 1Mb I2C EEPROM costs around ~$1.35 (or ~$0.60 more than a 8Kb). Yes, you still have the "OMG, my chassis just caught on fire" problem, = but this should (hopefully!) happen much much less often then "OMG, my = RE just tossed it's RAM | HDD | CF, etc". This would allow you to just pull the old RE and slap in a new one and = have things "Just Work". Yes, we are way down in the weeds of vendor / implementation stuff, but = I guess my point is that, having an RE fail (not uncommon) doesn't = *need* to mean having to roll keys. W >=20 > I think that at 1 all routing stops (or enough stops that you stop it > all anyway). > I think that at 6 you are in a state where at a minimum the router has > core-facing connectivity and you are placing the config back on the > device + relevant other bits (the key in question). >=20 > So... I agree you can make a key locally, you can ALSO probably just > re-ship the current stored-in-a-safe key to the device, because you've > got an extra 10 seconds for a complete new SSH session to come up/down > while scp'ing the file-o-key-material to the remote device. >=20 > -chris > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr >=20 From rossjanderson@googlemail.com Mon May 14 08:18:39 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17D7D21F8752 for ; Mon, 14 May 2012 08:18:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hAlB5pyjWcxr for ; Mon, 14 May 2012 08:18:38 -0700 (PDT) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4989621F8751 for ; Mon, 14 May 2012 08:18:38 -0700 (PDT) Received: by wibhj8 with SMTP id hj8so1527656wib.13 for ; Mon, 14 May 2012 08:18:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=boJ+bXfPXWYFUfG8UST66DZlHqOJpcirvk/KN2t7Lmc=; b=BskSJqUUjyiSw0zxXa0v84TDweosAXp1TM2PX8VvqSWBYKfaKBUOuG5PKYybLvaHGm MNUzZP+5AbB79QlihQ414Pz1vLnAO+0ud93jcoj87gvL3FBJGe49nVmf8LF4G7vxb/Qk 0rxhLc8dfnw2/WnK9wcNbHpM95AuokEiwvCSOIG5BlBZ/61FIkarlR+Vx9Y0NiKXmXY+ ypyxLwxkKp0x2beUi01/lcGz0rDzICLcIoOgA23tu7FObJoNrzxItxlTT4jePzZ4y47W 4WtuqA9Wokw88iXqCtCpcO+LZbd6ZEXT0q6I21modT5WlNHhrAvCI+wUWupJXBH4w/2x Y7RA== MIME-Version: 1.0 Received: by 10.50.222.200 with SMTP id qo8mr4454354igc.20.1337008716894; Mon, 14 May 2012 08:18:36 -0700 (PDT) Received: by 10.50.108.73 with HTTP; Mon, 14 May 2012 08:18:36 -0700 (PDT) In-Reply-To: References: <24B20D14B2CD29478C8D5D6E9CBB29F60F70871E@Hermes.columbia.ads.sparta.com> Date: Mon, 14 May 2012 16:18:36 +0100 Message-ID: From: "Ross.Anderson@cl.cam.ac.uk" To: Christopher Morrow Content-Type: text/plain; charset=ISO-8859-1 Cc: "Murphy, Sandra" , "Sriram, Kotikalapudi" , "sidr wg list \(sidr@ietf.org\)" Subject: Re: [sidr] Keys and algorithms for Updates - feasibility analysis? (was Re: RPKI and private keys) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Ross.Anderson@cl.cam.ac.uk List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 May 2012 15:18:39 -0000 Hardware cryptoprocessors raise the issue of export licenses. They are also expensive. There will have to be software alternatives. If we want widespread adoption, there must be an option to "just turn it on" without having to shell out a load of extra money and fill a lot of forms. Security usability means more than just a zero-marginal-cost software implementation. It means easy setup of keys and certificates, and probably the option of running in "advisory more" where verification failures raise error messages but do not cause routes to fail. That will enable ASes to try, watch, and gain the confidence to turn it on. Who's looking at security usability? Ross On 14/05/2012, Christopher Morrow wrote: > On Mon, May 14, 2012 at 10:27 AM, Brian Dickson > wrote: >> We can't do the crypto without HW on some of the routers involved in >> deployment of bgpsec. >> >> I've heard just about everyone say that, quite possibly including >> yourself. > > I don't think I've said that recently, one of the items brought out > during discussions of this was that often the hardware accelerators > for this are optimised for 'use one key a lot', not for 'swap in a new > key for every operation' (the key swap is very costly). > > Sriram has some numbers for different co-processors which are > interesting, but I don't think that means we need on-board crypto > accelerators. > >> One of the reasons for questioning the choice of crypto, is exploring the >> feasibility of solutions which do not require on-router HW for doing >> signing. > > sure, but you also invented a whole other (seemingly complex) system > to keep track of data (nonces and such) across multiple > trust/administrative domains. it seems unwieldy, to me at least. > > One of the larger stumbling blocks though is ram for RIB storage. (or > that seems to be one of the larger problems to address) > > -chris > >> >> Brian >> >> >> On Fri, May 11, 2012 at 9:23 PM, Christopher Morrow >> wrote: >>> >>> On Fri, May 11, 2012 at 5:27 PM, Brian Dickson >>> wrote: >>> > The argument that "we can't do the crypto without HW" >>> >>> i didn't see anyone say that though. >> >> > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr > From morrowc@ops-netman.net Mon May 14 08:19:34 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADA4021F87D7 for ; Mon, 14 May 2012 08:19:34 -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=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3TcwXKOH9Xr6 for ; Mon, 14 May 2012 08:19:34 -0700 (PDT) Received: from mailserver.ops-netman.net (mailserver.ops-netman.net [IPv6:2001:470:e495:fade:5054:ff:fe79:69db]) by ietfa.amsl.com (Postfix) with ESMTP id EC7B821F8752 for ; Mon, 14 May 2012 08:19:33 -0700 (PDT) Received: from donkey.her.corp.google.com (unknown [74.202.225.33]) (Authenticated sender: morrowc@OPS-NETMAN.NET) by mailserver.ops-netman.net (Postfix) with ESMTPSA id 27B7B320302; Mon, 14 May 2012 15:19:33 +0000 (UTC) Message-ID: <4FB12285.7070704@ops-netman.net> Date: Mon, 14 May 2012 11:19:33 -0400 From: Chris Morrow User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: "sidr-chairs@tools.ietf.org" , sidr wg X-Enigmail-Version: 1.4.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [sidr] WG Adoption: draft-ymbk-bgpsec-rtr-rekeying-00.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 May 2012 15:19:34 -0000 Howdy WG folk, The authors of: Would like to see if the document meets WG usefulness levels high enough to be included as a WG document. The abstract of the doc is (for the click-lazy): BGPsec-speaking routers must be provisioned with private keys and the corresponding public key must be published in the global Resource PKI. This document describes two ways of doing so, router-driven and operator-driven. This seems to fit into at least one of the current list-discussions, so topicality seems on-point. Please discuss this, review the doc and let's conclude this decision process 28 May 2012 (5/28/2012 or 28/5/2012). -chris From dougm@nist.gov Mon May 14 08:38:30 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97EF621F87F4 for ; Mon, 14 May 2012 08:38:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.051 X-Spam-Level: X-Spam-Status: No, score=-6.051 tagged_above=-999 required=5 tests=[AWL=-0.052, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tMuTysdib3zP for ; Mon, 14 May 2012 08:38:30 -0700 (PDT) Received: from wsget1.nist.gov (wsget1.nist.gov [129.6.13.150]) by ietfa.amsl.com (Postfix) with ESMTP id C1B3B21F87E7 for ; Mon, 14 May 2012 08:38:29 -0700 (PDT) Received: from WSXGHUB1.xchange.nist.gov (129.6.18.96) by wsget1.nist.gov (129.6.13.150) with Microsoft SMTP Server (TLS) id 14.1.355.2; Mon, 14 May 2012 11:38:15 -0400 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB1.xchange.nist.gov ([129.6.18.96]) with mapi; Mon, 14 May 2012 11:38:28 -0400 From: "Montgomery, Douglas" To: Warren Kumari , Christopher Morrow Date: Mon, 14 May 2012 11:33:48 -0400 Thread-Topic: [sidr] RPKI and private keys (was RE: Interim Meeting Draft Agenda: 04-30-2012 (April 30, 2012))) Thread-Index: Ac0x53KDm8oB0Y6XTj2wGpctIRFemA== Message-ID: In-Reply-To: <36B96241-E65B-4AF4-9B62-579EC3245D33@kumari.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.2.120421 acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Rob Austein , sidr wg list Subject: Re: [sidr] RPKI and private keys (was RE: Interim Meeting Draft Agenda: 04-30-2012 (April 30, 2012))) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 May 2012 15:38:30 -0000 Work is brewing for BIOS authentication in network devices .... While not exactly the same thing, it will require a trusted key store in ROM. --=20 Doug Montgomery =AD Mgr. Internet & Scalable Systems Research / ITL / NIST On 5/14/12 10:37 AM, "Warren Kumari" wrote: > >On May 11, 2012, at 2:51 PM, Christopher Morrow wrote: > >> On Fri, May 11, 2012 at 2:43 PM, Randy Bush wrote: >>=20 >>>> though I contend you have time between 'card fail' and 'router back to >>>> normal' to ship a key in the ether/ssh to the device too. >>>=20 >>> by the time the replacement re is sufficiently on net to create and >>>send >>> a public key to the noc for signing and publishing, the router is up >>>and >>> has at least some routing data. so the subsequent publication delay >>> would be a critical path delay (in the pert sense) to full, i.e. >>>bgpsec, >>> use. >>=20 >> hrm, so... normally something like this happens: >> 1) router go boom >> 2) troubleshooting ensues to see where the problem is (what to fix) >> 3) RE/RSP is determined to be at fault >> 4) spares call placed >> 5) spare arrives and is placed into the chassis >> 6) reboot/checkout happens >> 7) customer links brought back online >> 8) things return to 'normal' > >So, what if[0] the keying material itself is stored in a small EEPROM on >the chassis (well, backplane) itself? > >The number of times the backplane fails pales in comparison to the number >of RE / line-card failures, and many (most?) architectures already have >an I2C EEPROM on the [back|mid]plane. >A 1Mb I2C EEPROM costs around ~$1.35 (or ~$0.60 more than a 8Kb). > >Yes, you still have the "OMG, my chassis just caught on fire" problem, >but this should (hopefully!) happen much much less often then "OMG, my RE >just tossed it's RAM | HDD | CF, etc". >This would allow you to just pull the old RE and slap in a new one and >have things "Just Work". > >Yes, we are way down in the weeds of vendor / implementation stuff, but I >guess my point is that, having an RE fail (not uncommon) doesn't *need* >to mean having to roll keys. > >W > > >>=20 >> I think that at 1 all routing stops (or enough stops that you stop it >> all anyway). >> I think that at 6 you are in a state where at a minimum the router has >> core-facing connectivity and you are placing the config back on the >> device + relevant other bits (the key in question). >>=20 >> So... I agree you can make a key locally, you can ALSO probably just >> re-ship the current stored-in-a-safe key to the device, because you've >> got an extra 10 seconds for a complete new SSH session to come up/down >> while scp'ing the file-o-key-material to the remote device. >>=20 >> -chris >> _______________________________________________ >> sidr mailing list >> sidr@ietf.org >> https://www.ietf.org/mailman/listinfo/sidr >>=20 > >_______________________________________________ >sidr mailing list >sidr@ietf.org >https://www.ietf.org/mailman/listinfo/sidr From Sandra.Murphy@sparta.com Mon May 14 08:55:35 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA22E21F87FD for ; Mon, 14 May 2012 08:55:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.325 X-Spam-Level: X-Spam-Status: No, score=-102.325 tagged_above=-999 required=5 tests=[AWL=-0.326, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BPU8-gG79U82 for ; Mon, 14 May 2012 08:55:35 -0700 (PDT) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by ietfa.amsl.com (Postfix) with ESMTP id B553821F87FC for ; Mon, 14 May 2012 08:55:34 -0700 (PDT) Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.14.4/8.14.4) with ESMTP id q4EFtUft023746; Mon, 14 May 2012 10:55:30 -0500 Received: from Hermes.columbia.ads.sparta.com ([157.185.80.107]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id q4EFtTXn003680; Mon, 14 May 2012 10:55:29 -0500 Received: from HERMES.columbia.ads.sparta.com ([2002:9db9:506b::9db9:506b]) by Hermes.columbia.ads.sparta.com ([::1]) with mapi id 14.01.0355.002; Mon, 14 May 2012 11:55:29 -0400 From: "Murphy, Sandra" To: "Montgomery, Douglas" , Warren Kumari , Christopher Morrow Thread-Topic: [sidr] RPKI and private keys (was RE: Interim Meeting Draft Agenda: 04-30-2012 (April 30, 2012))) Thread-Index: AQHNMeegcw8QBQz9MEGlmWb1TeJBkJbJb/F9 Date: Mon, 14 May 2012 15:55:27 +0000 Message-ID: <24B20D14B2CD29478C8D5D6E9CBB29F60F709BF2@Hermes.columbia.ads.sparta.com> References: <36B96241-E65B-4AF4-9B62-579EC3245D33@kumari.net>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.185.63.118] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Rob Austein , sidr wg list Subject: Re: [sidr] RPKI and private keys (was RE: Interim Meeting Draft Agenda: 04-30-2012 (April 30, 2012))) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 May 2012 15:55:36 -0000 Brewing where? (Astonishing, would like to hear more.)=0A= =0A= --Sandy=0A= =0A= ________________________________________=0A= From: sidr-bounces@ietf.org [sidr-bounces@ietf.org] on behalf of Montgomery= , Douglas [dougm@nist.gov]=0A= Sent: Monday, May 14, 2012 11:33 AM=0A= To: Warren Kumari; Christopher Morrow=0A= Cc: Rob Austein; sidr wg list=0A= Subject: Re: [sidr] RPKI and private keys (was RE: Interim Meeting Draft Ag= enda: 04-30-2012 (April 30, 2012)))=0A= =0A= Work is brewing for BIOS authentication in network devices .... While not= =0A= exactly the same thing, it will require a trusted key store in ROM.=0A= --=0A= Doug Montgomery =AD Mgr. Internet & Scalable Systems Research / ITL / NIST= =0A= =0A= =0A= =0A= =0A= =0A= =0A= On 5/14/12 10:37 AM, "Warren Kumari" wrote:=0A= =0A= >=0A= >On May 11, 2012, at 2:51 PM, Christopher Morrow wrote:=0A= >=0A= >> On Fri, May 11, 2012 at 2:43 PM, Randy Bush wrote:=0A= >>=0A= >>>> though I contend you have time between 'card fail' and 'router back to= =0A= >>>> normal' to ship a key in the ether/ssh to the device too.=0A= >>>=0A= >>> by the time the replacement re is sufficiently on net to create and=0A= >>>send=0A= >>> a public key to the noc for signing and publishing, the router is up=0A= >>>and=0A= >>> has at least some routing data. so the subsequent publication delay=0A= >>> would be a critical path delay (in the pert sense) to full, i.e.=0A= >>>bgpsec,=0A= >>> use.=0A= >>=0A= >> hrm, so... normally something like this happens:=0A= >> 1) router go boom=0A= >> 2) troubleshooting ensues to see where the problem is (what to fix)=0A= >> 3) RE/RSP is determined to be at fault=0A= >> 4) spares call placed=0A= >> 5) spare arrives and is placed into the chassis=0A= >> 6) reboot/checkout happens=0A= >> 7) customer links brought back online=0A= >> 8) things return to 'normal'=0A= >=0A= >So, what if[0] the keying material itself is stored in a small EEPROM on= =0A= >the chassis (well, backplane) itself?=0A= >=0A= >The number of times the backplane fails pales in comparison to the number= =0A= >of RE / line-card failures, and many (most?) architectures already have=0A= >an I2C EEPROM on the [back|mid]plane.=0A= >A 1Mb I2C EEPROM costs around ~$1.35 (or ~$0.60 more than a 8Kb).=0A= >=0A= >Yes, you still have the "OMG, my chassis just caught on fire" problem,=0A= >but this should (hopefully!) happen much much less often then "OMG, my RE= =0A= >just tossed it's RAM | HDD | CF, etc".=0A= >This would allow you to just pull the old RE and slap in a new one and=0A= >have things "Just Work".=0A= >=0A= >Yes, we are way down in the weeds of vendor / implementation stuff, but I= =0A= >guess my point is that, having an RE fail (not uncommon) doesn't *need*=0A= >to mean having to roll keys.=0A= >=0A= >W=0A= >=0A= >=0A= >>=0A= >> I think that at 1 all routing stops (or enough stops that you stop it=0A= >> all anyway).=0A= >> I think that at 6 you are in a state where at a minimum the router has= =0A= >> core-facing connectivity and you are placing the config back on the=0A= >> device + relevant other bits (the key in question).=0A= >>=0A= >> So... I agree you can make a key locally, you can ALSO probably just=0A= >> re-ship the current stored-in-a-safe key to the device, because you've= =0A= >> got an extra 10 seconds for a complete new SSH session to come up/down= =0A= >> while scp'ing the file-o-key-material to the remote device.=0A= >>=0A= >> -chris=0A= >> _______________________________________________=0A= >> sidr mailing list=0A= >> sidr@ietf.org=0A= >> https://www.ietf.org/mailman/listinfo/sidr=0A= >>=0A= >=0A= >_______________________________________________=0A= >sidr mailing list=0A= >sidr@ietf.org=0A= >https://www.ietf.org/mailman/listinfo/sidr=0A= =0A= _______________________________________________=0A= sidr mailing list=0A= sidr@ietf.org=0A= https://www.ietf.org/mailman/listinfo/sidr=0A= From christopher.morrow@gmail.com Mon May 14 09:48:26 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B04021F881C for ; Mon, 14 May 2012 09:48:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.577 X-Spam-Level: X-Spam-Status: No, score=-103.577 tagged_above=-999 required=5 tests=[AWL=0.022, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ty9VuhmVleuA for ; Mon, 14 May 2012 09:48:25 -0700 (PDT) Received: from mail-qa0-f49.google.com (mail-qa0-f49.google.com [209.85.216.49]) by ietfa.amsl.com (Postfix) with ESMTP id AD77821F880D for ; Mon, 14 May 2012 09:48:25 -0700 (PDT) Received: by qabj40 with SMTP id j40so3838652qab.15 for ; Mon, 14 May 2012 09:48:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=8/zokmNshvDtAxwz0Q+HanUAy9BWFuYWzkW886bhEpU=; b=y5WSjDg+3PxiIBCyKk/4EH80Z0t3P/5Rj/LYUjlEckEbru8FsNfDc+KS13c1xcoDjr bmwfycIEd6ERe0PIyaYCV8isiJ0teYftiIke/4XTrghrdUETlbAXPv1NbwjZr7jHd8mg APFRJquOh+cnn/p+rLnGQjCsRHa5WElcMyV+EhCaV8AJKwPFWwTndEwRBmCUWfz74zYV tIqWop0JBQaS+RthKWetIWf6DXlL6kZar5w00Gcny5lUnPT9267DUnzORTs1BNMBlIDV k4mw1Qci381rwTxC/aj+3XGHb+ijacvs8f4+Y+Vj8aIhOv0asZ+KFtqwjGHPkiyME6Q3 h6BQ== MIME-Version: 1.0 Received: by 10.60.7.200 with SMTP id l8mr1754162oea.52.1337014104969; Mon, 14 May 2012 09:48:24 -0700 (PDT) Sender: christopher.morrow@gmail.com Received: by 10.182.166.71 with HTTP; Mon, 14 May 2012 09:48:24 -0700 (PDT) In-Reply-To: References: <24B20D14B2CD29478C8D5D6E9CBB29F60F70871E@Hermes.columbia.ads.sparta.com> Date: Mon, 14 May 2012 12:48:24 -0400 X-Google-Sender-Auth: r4nF5nwFHGCe0QnejVdcG5v7gIw Message-ID: From: Christopher Morrow To: Ross.Anderson@cl.cam.ac.uk Content-Type: text/plain; charset=ISO-8859-1 Cc: "Murphy, Sandra" , "Sriram, Kotikalapudi" , "sidr wg list \(sidr@ietf.org\)" Subject: Re: [sidr] Keys and algorithms for Updates - feasibility analysis? (was Re: RPKI and private keys) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 May 2012 16:48:26 -0000 On Mon, May 14, 2012 at 11:18 AM, Ross.Anderson@cl.cam.ac.uk wrote: > Hardware cryptoprocessors raise the issue of export licenses. They are > also expensive. There will have to be software alternatives. the vendors who've been involved so far didn't mention export-problems, but that's a fair thing to keep in mind. The cost is also interesting, but on the other side of a 200k USD device, is the coprocessor (if needed at all, and if ONLY used for this function) a show stopper at 100 USD/item? (at 1000? what is an average cost Sriram?) > If we want widespread adoption, there must be an option to "just turn > it on" without having to shell out a load of extra money and fill a > lot of forms. sure. > Security usability means more than just a zero-marginal-cost software > implementation. It means easy setup of keys and certificates, and > probably the option of running in "advisory more" where verification > failures raise error messages but do not cause routes to fail. That I think in no case will the validation just drop a route, or the plan so far has simply been adding an ability to mark an update with some key (community, localpref, etc) and use that in determining what to do with the route. If you can match on validity state you COULD simply DROP the route, but I don't think that'll be the end state for a very, very long time. > will enable ASes to try, watch, and gain the confidence to turn it on. > > Who's looking at security usability? smb? would you like to help? :) ^^^ - probably others as well, but he's been a voice so far, as has mr turner. -chris > Ross > > > On 14/05/2012, Christopher Morrow wrote: >> On Mon, May 14, 2012 at 10:27 AM, Brian Dickson >> wrote: >>> We can't do the crypto without HW on some of the routers involved in >>> deployment of bgpsec. >>> >>> I've heard just about everyone say that, quite possibly including >>> yourself. >> >> I don't think I've said that recently, one of the items brought out >> during discussions of this was that often the hardware accelerators >> for this are optimised for 'use one key a lot', not for 'swap in a new >> key for every operation' (the key swap is very costly). >> >> Sriram has some numbers for different co-processors which are >> interesting, but I don't think that means we need on-board crypto >> accelerators. >> >>> One of the reasons for questioning the choice of crypto, is exploring the >>> feasibility of solutions which do not require on-router HW for doing >>> signing. >> >> sure, but you also invented a whole other (seemingly complex) system >> to keep track of data (nonces and such) across multiple >> trust/administrative domains. it seems unwieldy, to me at least. >> >> One of the larger stumbling blocks though is ram for RIB storage. (or >> that seems to be one of the larger problems to address) >> >> -chris >> >>> >>> Brian >>> >>> >>> On Fri, May 11, 2012 at 9:23 PM, Christopher Morrow >>> wrote: >>>> >>>> On Fri, May 11, 2012 at 5:27 PM, Brian Dickson >>>> wrote: >>>> > The argument that "we can't do the crypto without HW" >>>> >>>> i didn't see anyone say that though. >>> >>> >> _______________________________________________ >> sidr mailing list >> sidr@ietf.org >> https://www.ietf.org/mailman/listinfo/sidr >> From dougm@nist.gov Mon May 14 10:16:57 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E628C11E8096 for ; Mon, 14 May 2012 10:16:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.338 X-Spam-Level: X-Spam-Status: No, score=-6.338 tagged_above=-999 required=5 tests=[AWL=0.261, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1vpw43XMVA1G for ; Mon, 14 May 2012 10:16:57 -0700 (PDT) Received: from wsget2.nist.gov (wsget2.nist.gov [129.6.13.151]) by ietfa.amsl.com (Postfix) with ESMTP id 2D0D711E8095 for ; Mon, 14 May 2012 10:16:57 -0700 (PDT) Received: from WSXGHUB2.xchange.nist.gov (129.6.18.19) by wsget2.nist.gov (129.6.13.151) with Microsoft SMTP Server (TLS) id 14.1.355.2; Mon, 14 May 2012 13:16:41 -0400 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB2.xchange.nist.gov ([129.6.18.19]) with mapi; Mon, 14 May 2012 13:15:43 -0400 From: "Montgomery, Douglas" To: Christopher Morrow , "Ross.Anderson@cl.cam.ac.uk" Date: Mon, 14 May 2012 13:16:34 -0400 Thread-Topic: [sidr] Keys and algorithms for Updates - feasibility analysis? (was Re: RPKI and private keys) Thread-Index: Ac0x9TFQGwlWle8jRCm4yj1Uu5k4VA== Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.2.120421 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Cc: "Sriram, Kotikalapudi" , "Murphy, Sandra" , "sidr wg list \(sidr@ietf.org\)" Subject: Re: [sidr] Keys and algorithms for Updates - feasibility analysis? (was Re: RPKI and private keys) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 May 2012 17:16:58 -0000 > >> will enable ASes to try, watch, and gain the confidence to turn it on. >> >> Who's looking at security usability? > >smb? would you like to help? :) >^^^ - probably others as well, but he's been a voice so far, as has mr >turner. We have a usability group that has several projects underway on security. Not this particular topic though. http://www.nist.gov/itl/iad/vug/ Is there a specific usability question in this space to be posed? Dougm From christopher.morrow@gmail.com Mon May 14 10:25:51 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B2E721F88E3 for ; Mon, 14 May 2012 10:25:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.577 X-Spam-Level: X-Spam-Status: No, score=-103.577 tagged_above=-999 required=5 tests=[AWL=0.022, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iFK8eJ7marXq for ; Mon, 14 May 2012 10:25:50 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 6F51D21F88D3 for ; Mon, 14 May 2012 10:25:50 -0700 (PDT) Received: by obbeh20 with SMTP id eh20so9381011obb.31 for ; Mon, 14 May 2012 10:25:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=M4Crm5BSbgUHmATBHrKCB4NqR8oJX/rsh4s5lExmcRQ=; b=T1QqEZHcTPS1btPbRqeuiZY/8ZtxyVLtEQ1TJj7ABrxBDQi6Ny3AlfiHv0Ta2vN7el PqT05UjSF/uljloZCKMCpNLts96/iiY5Xwm5JvGQ5M6nUEKyXWDznpMTnqeBJxqEgcA/ o6Ej4gn9pxdQcDXFzzluYeepJtJA7gAN8vtUDFKMVuTDqxw3/O3gJ7w2/wcwOMblC1k5 fuD2LbtRv5iVQepBj5l3+rSjYOfHoQVxlZHK/u4cLTMfiTCqgEn+YSRxMmu2QUORDfpx uPhf0mPY+poO4hRrhY3e71VF1P9y4LjNhlICVLfbJDALG3KZSx2e9iObPt/YK9o2BdMT EYKQ== MIME-Version: 1.0 Received: by 10.182.37.37 with SMTP id v5mr13088552obj.51.1337016350036; Mon, 14 May 2012 10:25:50 -0700 (PDT) Sender: christopher.morrow@gmail.com Received: by 10.182.166.71 with HTTP; Mon, 14 May 2012 10:25:50 -0700 (PDT) In-Reply-To: <4FB12285.7070704@ops-netman.net> References: <4FB12285.7070704@ops-netman.net> Date: Mon, 14 May 2012 13:25:50 -0400 X-Google-Sender-Auth: Tfnfn8JhaC2YqKH6--rbpy9AUNY Message-ID: From: Christopher Morrow To: Chris Morrow Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "sidr-chairs@tools.ietf.org" , sidr wg Subject: Re: [sidr] WG Adoption: draft-ymbk-bgpsec-rtr-rekeying-00.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 May 2012 17:25:51 -0000 oh, for reasons I can't explain we already did this, yay! (mar 26 or so) even better I think we said it concluded successfully... and it someone (me) should fix the document location/train in the tools interface. so, hopefully people didn't read too much of this version already :) -chris On Mon, May 14, 2012 at 11:19 AM, Chris Morrow wro= te: > Howdy WG folk, > The authors of: > =A0 > > Would like to see if the document meets WG usefulness levels high enough > to be included as a WG document. The abstract of the doc is (for the > click-lazy): > > =A0 BGPsec-speaking routers must be provisioned with private keys and the > =A0 corresponding public key must be published in the global Resource > =A0 PKI. =A0This document describes two ways of doing so, router-driven a= nd > =A0 operator-driven. > > This seems to fit into at least one of the current list-discussions, so > topicality seems on-point. > > Please discuss this, review the doc and let's conclude this decision > process 28 May 2012 (5/28/2012 or 28/5/2012). > > -chris > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr From internet-drafts@ietf.org Mon May 14 11:52:34 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0158921F889D; Mon, 14 May 2012 11:52:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.515 X-Spam-Level: X-Spam-Status: No, score=-102.515 tagged_above=-999 required=5 tests=[AWL=0.084, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iaSFV54TCJSz; Mon, 14 May 2012 11:52:33 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F65A21F8880; Mon, 14 May 2012 11:52:33 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.02 Message-ID: <20120514185233.8866.7399.idtracker@ietfa.amsl.com> Date: Mon, 14 May 2012 11:52:33 -0700 Cc: sidr@ietf.org Subject: [sidr] I-D Action: draft-ietf-sidr-rtr-keying-00.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 May 2012 18:52:34 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Secure Inter-Domain Routing Working G= roup of the IETF. Title : Router Keying for BGPsec Author(s) : Sean Turner Keyur Patel Randy Bush Filename : draft-ietf-sidr-rtr-keying-00.txt Pages : 7 Date : 2012-05-14 BGPsec-speaking routers must be provisioned with private keys and the corresponding public key must be published in the global Resource PKI. This document describes two ways of doing so, router-driven and operator-driven. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sidr-rtr-keying-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-sidr-rtr-keying-00.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-sidr-rtr-keying/ From Sandra.Murphy@sparta.com Mon May 14 11:54:24 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48EF521F88E3 for ; Mon, 14 May 2012 11:54:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.619 X-Spam-Level: X-Spam-Status: No, score=-102.619 tagged_above=-999 required=5 tests=[AWL=-0.020, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kaf88olqOr2k for ; Mon, 14 May 2012 11:54:23 -0700 (PDT) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by ietfa.amsl.com (Postfix) with ESMTP id AA6F121F88E2 for ; Mon, 14 May 2012 11:54:23 -0700 (PDT) Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.14.4/8.14.4) with ESMTP id q4EIsJDT026443; Mon, 14 May 2012 13:54:19 -0500 Received: from Hermes.columbia.ads.sparta.com ([157.185.80.107]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id q4EIsFE2011530; Mon, 14 May 2012 13:54:15 -0500 Received: from HERMES.columbia.ads.sparta.com ([2002:9db9:506b::9db9:506b]) by Hermes.columbia.ads.sparta.com ([::1]) with mapi id 14.01.0355.002; Mon, 14 May 2012 14:54:15 -0400 From: "Murphy, Sandra" To: Christopher Morrow , Chris Morrow Thread-Topic: [sidr] WG Adoption: draft-ymbk-bgpsec-rtr-rekeying-00.txt Thread-Index: AQHNMeT85aKLF3wLiU2lqcShdrU5JJbJzHoA///VW/0= Date: Mon, 14 May 2012 18:54:14 +0000 Message-ID: <24B20D14B2CD29478C8D5D6E9CBB29F60F709D64@Hermes.columbia.ads.sparta.com> References: <4FB12285.7070704@ops-netman.net>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.185.63.118] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "sidr-chairs@tools.ietf.org" , sidr wg Subject: Re: [sidr] WG Adoption: draft-ymbk-bgpsec-rtr-rekeying-00.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 May 2012 18:54:24 -0000 The call for adoption having completed successfully, the authors may submit= a wg draft draft-ietf-sidr-xxx-00 at their convenience.=0A= =0A= --Sandy. speaking as wg co-chair=0A= ________________________________________=0A= From: sidr-bounces@ietf.org [sidr-bounces@ietf.org] on behalf of Christophe= r Morrow [morrowc.lists@gmail.com]=0A= Sent: Monday, May 14, 2012 1:25 PM=0A= To: Chris Morrow=0A= Cc: sidr-chairs@tools.ietf.org; sidr wg=0A= Subject: Re: [sidr] WG Adoption: draft-ymbk-bgpsec-rtr-rekeying-00.txt=0A= =0A= oh, for reasons I can't explain we already did this, yay! (mar 26 or so)=0A= even better I think we said it concluded successfully... and it=0A= someone (me) should fix the document location/train in the tools=0A= interface.=0A= =0A= so, hopefully people didn't read too much of this version already :)=0A= =0A= -chris=0A= =0A= On Mon, May 14, 2012 at 11:19 AM, Chris Morrow wro= te:=0A= > Howdy WG folk,=0A= > The authors of:=0A= > =0A= >=0A= > Would like to see if the document meets WG usefulness levels high enough= =0A= > to be included as a WG document. The abstract of the doc is (for the=0A= > click-lazy):=0A= >=0A= > BGPsec-speaking routers must be provisioned with private keys and the= =0A= > corresponding public key must be published in the global Resource=0A= > PKI. This document describes two ways of doing so, router-driven and= =0A= > operator-driven.=0A= >=0A= > This seems to fit into at least one of the current list-discussions, so= =0A= > topicality seems on-point.=0A= >=0A= > Please discuss this, review the doc and let's conclude this decision=0A= > process 28 May 2012 (5/28/2012 or 28/5/2012).=0A= >=0A= > -chris=0A= > _______________________________________________=0A= > sidr mailing list=0A= > sidr@ietf.org=0A= > https://www.ietf.org/mailman/listinfo/sidr=0A= _______________________________________________=0A= sidr mailing list=0A= sidr@ietf.org=0A= https://www.ietf.org/mailman/listinfo/sidr=0A= From randy@psg.com Mon May 14 13:07:57 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F05A521F887D for ; Mon, 14 May 2012 13:07:57 -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=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5w-k2S9tz9Z4 for ; Mon, 14 May 2012 13:07:57 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id 8618721F8877 for ; Mon, 14 May 2012 13:07:57 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1SU1Yi-000Az1-Hv; Mon, 14 May 2012 20:07:56 +0000 Date: Mon, 14 May 2012 10:07:55 -1000 Message-ID: From: Randy Bush To: Warren Kumari In-Reply-To: <36B96241-E65B-4AF4-9B62-579EC3245D33@kumari.net> References: <4FA48240.9060405@ops-netman.net> <7309FCBCAE981B43ABBE69B31C8D213921BE2860C3@EUSAACMS0701.eamcs.ericsson.se> <20120511025431.D05A6170C1@thrintun.hactrn.net> <36B96241-E65B-4AF4-9B62-579EC3245D33@kumari.net> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: sidr wg list Subject: Re: [sidr] RPKI and private keys (was RE: Interim Meeting Draft Agenda: 04-30-2012 (April 30, 2012))) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 May 2012 20:07:58 -0000 > The number of times the backplane fails pales in comparison to the > number of RE / line-card failures, and many (most?) architectures > already have an I2C EEPROM on the [back|mid]plane. A 1Mb I2C EEPROM > costs around ~$1.35 (or ~$0.60 more than a 8Kb). i don't even want to watch while you try to sell this to the vendor hardware folk. randy From warren@kumari.net Mon May 14 14:17:11 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82F9821F8907 for ; Mon, 14 May 2012 14:17:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.013 X-Spam-Level: X-Spam-Status: No, score=-106.013 tagged_above=-999 required=5 tests=[AWL=0.586, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LY0plJ6nB9Mv for ; Mon, 14 May 2012 14:17:11 -0700 (PDT) Received: from vimes.kumari.net (vimes.kumari.net [198.186.192.250]) by ietfa.amsl.com (Postfix) with ESMTP id 0AF8721F88DA for ; Mon, 14 May 2012 14:17:10 -0700 (PDT) Received: from dhcp-172-19-118-235.cbf.corp.google.com (unknown [64.13.52.115]) by vimes.kumari.net (Postfix) with ESMTPSA id 3DB861B402EB; Mon, 14 May 2012 17:17:10 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Warren Kumari In-Reply-To: Date: Mon, 14 May 2012 17:17:08 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <0525DE26-A03D-4A70-A5F9-4295DDB0FCF3@kumari.net> References: <4FA48240.9060405@ops-netman.net> <7309FCBCAE981B43ABBE69B31C8D213921BE2860C3@EUSAACMS0701.eamcs.ericsson.se> <20120511025431.D05A6170C1@thrintun.hactrn.net> <36B96241-E65B-4AF4-9B62-579EC3245D33@kumari.net> To: Randy Bush X-Mailer: Apple Mail (2.1084) Cc: sidr wg list Subject: Re: [sidr] RPKI and private keys (was RE: Interim Meeting Draft Agenda: 04-30-2012 (April 30, 2012))) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 May 2012 21:17:11 -0000 On May 14, 2012, at 4:07 PM, Randy Bush wrote: >> The number of times the backplane fails pales in comparison to the >> number of RE / line-card failures, and many (most?) architectures >> already have an I2C EEPROM on the [back|mid]plane. A 1Mb I2C EEPROM >> costs around ~$1.35 (or ~$0.60 more than a 8Kb). >=20 > i don't even want to watch while you try to sell this to the vendor > hardware folk. Really? Seems like it could provide opportunity for much entertainment = and talking past each other... W >=20 > randy >=20 From randy@psg.com Mon May 14 14:18:10 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42A7A21F8441 for ; Mon, 14 May 2012 14:18:10 -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=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id idEyL9vSqMTT for ; Mon, 14 May 2012 14:18:09 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id CB34621F8917 for ; Mon, 14 May 2012 14:18:08 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1SU2ee-000B8w-0I; Mon, 14 May 2012 21:18:08 +0000 Date: Mon, 14 May 2012 11:18:06 -1000 Message-ID: From: Randy Bush To: Warren Kumari In-Reply-To: <0525DE26-A03D-4A70-A5F9-4295DDB0FCF3@kumari.net> References: <4FA48240.9060405@ops-netman.net> <7309FCBCAE981B43ABBE69B31C8D213921BE2860C3@EUSAACMS0701.eamcs.ericsson.se> <20120511025431.D05A6170C1@thrintun.hactrn.net> <36B96241-E65B-4AF4-9B62-579EC3245D33@kumari.net> <0525DE26-A03D-4A70-A5F9-4295DDB0FCF3@kumari.net> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: sidr wg list Subject: Re: [sidr] RPKI and private keys (was RE: Interim Meeting Draft Agenda: 04-30-2012 (April 30, 2012))) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 May 2012 21:18:10 -0000 >> i don't even want to watch while you try to sell this to the vendor >> hardware folk. > > Really? Seems like it could provide opportunity for much entertainment > and talking past each other... ietf meetings are insufficient? From tim@ripe.net Tue May 15 02:27:20 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92B8921F84CD for ; Tue, 15 May 2012 02:27:20 -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=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MbKpoMs16ZVR for ; Tue, 15 May 2012 02:27:19 -0700 (PDT) Received: from postlady.ripe.net (postlady.ipv6.ripe.net [IPv6:2001:67c:2e8:11::c100:1341]) by ietfa.amsl.com (Postfix) with ESMTP id 50B7621F844A for ; Tue, 15 May 2012 02:27:19 -0700 (PDT) Received: from dodo.ripe.net ([193.0.23.4]) by postlady.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1SUE2H-0005Tk-9M for sidr@ietf.org; Tue, 15 May 2012 11:27:18 +0200 Received: from s258-sslvpn-1.ripe.net ([193.0.20.231] helo=vpn-30.ripe.net) by dodo.ripe.net with esmtps (TLSv1:AES128-SHA:128) (Exim 4.72) (envelope-from ) id 1SUE2G-0005i5-PE; Tue, 15 May 2012 11:27:16 +0200 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Tim Bruijnzeels In-Reply-To: Date: Tue, 15 May 2012 11:27:15 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4FA48240.9060405@ops-netman.net> <7309FCBCAE981B43ABBE69B31C8D213921BE2860C3@EUSAACMS0701.eamcs.ericsson.se> <20120511025431.D05A6170C1@thrintun.hactrn.net> <36B96241-E65B-4AF4-9B62-579EC3245D33@kumari.net> <0525DE26-A03D-4A70-A5F9-4295DDB0FCF3@kumari.net> To: sidr wg list X-Mailer: Apple Mail (2.1084) X-Anti-Virus: Kaspersky Anti-Virus for Linux Mail Server 5.6.48/RELEASE, bases: 20120425 #7816066, check: 20120515 clean X-RIPE-Spam-Level: -- X-RIPE-Spam-Report: Spam Total Points: -2.9 points pts rule name description ---- ---------------------- ------------------------------------ -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -0.0 T_RP_MATCHES_RCVD Envelope sender domain matches handover relay domain -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-RIPE-Signature: 784d7acfe6559f2a0b602ec6519a0719d62df1d342cf64387a1ef6db36960e66 Subject: Re: [sidr] RPKI and private keys (was RE: Interim Meeting Draft Agenda: 04-30-2012 (April 30, 2012))) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 May 2012 09:27:20 -0000 Not replying to anyone in particular here..=20 I just want to say though that this exporting of keys of routers makes = me nervous. I think this will degrade the level of trust that people can = place in bgpsec, and therefore I think it's not a good idea to include = this in the standards. I understand that this may mean that in certain failure scenarios people = will find that they haven't provisioned replacement routers. To this I would say: - BCP should be to provision new hardware in advance, eg upon = installation. A well documented and simple way to get CSRs out of the = router would be useful here. - The rpki repository and fetch mechanisms should be improved to support = propagation of new router certs to RPs in hours max. (not days). It = should also support a potentially large number of router certs (just = like it should be able to support 500k ROAs). - I think that bgpsec validation semantics should support 'graceful' = degradation where an AS may sign some, but not all, updates if they come = from different hardware. I think this is also needed for initial, = incremental, deployment. Tim From Sandra.Murphy@sparta.com Tue May 15 07:59:20 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0750921F88BB for ; Tue, 15 May 2012 07:59:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.618 X-Spam-Level: X-Spam-Status: No, score=-102.618 tagged_above=-999 required=5 tests=[AWL=-0.019, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jBU8sbkYC5SK for ; Tue, 15 May 2012 07:59:19 -0700 (PDT) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by ietfa.amsl.com (Postfix) with ESMTP id 7825121F889C for ; Tue, 15 May 2012 07:59:19 -0700 (PDT) Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.14.4/8.14.4) with ESMTP id q4FExICM001399 for ; Tue, 15 May 2012 09:59:18 -0500 Received: from Hermes.columbia.ads.sparta.com ([157.185.80.107]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id q4FExIRW001961 for ; Tue, 15 May 2012 09:59:18 -0500 Received: from HERMES.columbia.ads.sparta.com ([2002:9db9:506b::9db9:506b]) by Hermes.columbia.ads.sparta.com ([::1]) with mapi id 14.01.0355.002; Tue, 15 May 2012 10:59:18 -0400 From: "Murphy, Sandra" To: "sidr@ietf.org" Thread-Topic: reminder of minutes deadline for IETF83 Thread-Index: Ac0yq0zUHVa/PX33QwOJ3zr/tjU8Zw== Date: Tue, 15 May 2012 14:59:17 +0000 Message-ID: <24B20D14B2CD29478C8D5D6E9CBB29F60F709F62@Hermes.columbia.ads.sparta.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.185.63.118] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [sidr] reminder of minutes deadline for IETF83 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 May 2012 14:59:20 -0000 Final versions of minutes are due tomorrow:=0A= =0A= 2012-05-16 (Wednesday): Proceedings submission corrections cutoff date by 1= 7:00 PT (UTC -7),=0A= =0A= If you have any corrections to what was uploaded, get them to the chairs.= =0A= =0A= --Sandy=0A= From Sandra.Murphy@sparta.com Wed May 16 15:05:25 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DB8021F85D9 for ; Wed, 16 May 2012 15:05:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.618 X-Spam-Level: X-Spam-Status: No, score=-102.618 tagged_above=-999 required=5 tests=[AWL=-0.019, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WVsrZ3c64ZRt for ; Wed, 16 May 2012 15:05:25 -0700 (PDT) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by ietfa.amsl.com (Postfix) with ESMTP id D0B8121F85C0 for ; Wed, 16 May 2012 15:05:24 -0700 (PDT) Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.14.4/8.14.4) with ESMTP id q4GM5NBR016798 for ; Wed, 16 May 2012 17:05:23 -0500 Received: from Hermes.columbia.ads.sparta.com ([157.185.80.107]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id q4GM5KeW017131 for ; Wed, 16 May 2012 17:05:20 -0500 Received: from HERMES.columbia.ads.sparta.com ([2002:9db9:506b::9db9:506b]) by Hermes.columbia.ads.sparta.com ([::1]) with mapi id 14.01.0355.002; Wed, 16 May 2012 18:05:18 -0400 From: "Murphy, Sandra" To: "sidr@ietf.org" Thread-Topic: request for agenda items for interim meeting 6 Jun Thread-Index: AQHNM6/4vkOTGr4FY0qnZHxk5Z062g== Date: Wed, 16 May 2012 22:05:17 +0000 Message-ID: <24B20D14B2CD29478C8D5D6E9CBB29F60F70A267@Hermes.columbia.ads.sparta.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.185.63.118] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [sidr] request for agenda items for interim meeting 6 Jun X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 May 2012 22:05:25 -0000 Potential agenda items for the 6 Jun interim meeting.=0A= =0A= The agenda needs to be announced two weeks ahead of time, which is next Wed= nesday.=0A= =0A= Please send suggested topics to the list. Below are two suggestions to spa= rk the discussion.=0A= =0A= (1) AS_PATH=0A= =0A= There was one agenda topic that we never directly addressed at the 30 Apr m= eeting. That topic was the absence of the AS_PATH attribute from the bgpse= c protocol. (The info normally contained in the AS_PATH is contained in th= e bgpsec attributes.)=0A= =0A= The absence of the AS_PATH did come up in discussing other topics (see the = minutes), but we did not discuss it directly.=0A= =0A= (2) router private key provisioning.=0A= =0A= In the interim in San Diego, there were requests (from operators) that guid= ance to operators of how to provision a router with the needed keys would b= e a good idea. We had some discussion in the Paris meeting of two drafts = discussing provisioning the routers with their needed private keys. There'= s also been a recent flurry of discussion on the list.=0A= =0A= --Sandy, speaking as wg co-chair= From ietfc@btconnect.com Thu May 17 01:31:31 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A72D21F86CF for ; Thu, 17 May 2012 01:31:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.549 X-Spam-Level: X-Spam-Status: No, score=-3.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 92LMLdGrOsyD for ; Thu, 17 May 2012 01:31:31 -0700 (PDT) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe002.messaging.microsoft.com [216.32.180.12]) by ietfa.amsl.com (Postfix) with ESMTP id EA7C421F86CB for ; Thu, 17 May 2012 01:31:30 -0700 (PDT) Received: from mail67-va3-R.bigfish.com (10.7.14.239) by VA3EHSOBE003.bigfish.com (10.7.40.23) with Microsoft SMTP Server id 14.1.225.23; Thu, 17 May 2012 08:31:22 +0000 Received: from mail67-va3 (localhost [127.0.0.1]) by mail67-va3-R.bigfish.com (Postfix) with ESMTP id 6146C2A00B2; Thu, 17 May 2012 08:31:22 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.55.224.141; KIP:(null); UIP:(null); IPV:NLI; H:DB3PRD0702HT007.eurprd07.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -22 X-BigFish: PS-22(zz9371I542Mzz1202hzz1033IL8275bh8275dhz2dh2a8h5a9h668h839hd24h304l) Received: from mail67-va3 (localhost.localdomain [127.0.0.1]) by mail67-va3 (MessageSwitch) id 1337243480326720_8989; Thu, 17 May 2012 08:31:20 +0000 (UTC) Received: from VA3EHSMHS017.bigfish.com (unknown [10.7.14.242]) by mail67-va3.bigfish.com (Postfix) with ESMTP id 4C9E5C0045; Thu, 17 May 2012 08:31:20 +0000 (UTC) Received: from DB3PRD0702HT007.eurprd07.prod.outlook.com (157.55.224.141) by VA3EHSMHS017.bigfish.com (10.7.99.27) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 17 May 2012 08:31:20 +0000 Received: from BL2PRD0410HT003.namprd04.prod.outlook.com (157.56.240.85) by pod51017.outlook.com (10.3.4.168) with Microsoft SMTP Server (TLS) id 14.15.74.2; Thu, 17 May 2012 08:31:26 +0000 Message-ID: <012c01cd3407$14852d20$4001a8c0@gateway.2wire.net> From: t.petch To: "Murphy, Sandra" , References: <24B20D14B2CD29478C8D5D6E9CBB29F60F708799@Hermes.columbia.ads.sparta.com> Date: Thu, 17 May 2012 09:28:36 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [157.56.240.85] X-OriginatorOrg: btconnect.com Subject: Re: [sidr] minutes of 30 Apr 2012 interim meeting X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 May 2012 08:31:31 -0000 Mmmm The proceedings page still has no link for Minutes or Agenda, 18 days on. The attachment to this, which makes the size of the e-mail trip a spam trap for me, is in .pdf, which I do not find friendly, not having an Acrobat licence. The jabber log lists 11 (and rising) logs for May 2012 - is the meeting still going on:-) Mmm Tom Petch ----- Original Message ----- From: "Murphy, Sandra" To: Sent: Friday, May 11, 2012 10:57 AM Subject: [sidr] minutes of 30 Apr 2012 interim meeting The minutes of the 30 Apr 2012 interim meeting have been uploaded to the proceedings site. The minutes can be found at the proceedings page for the meeting: http://www.ietf.org/proceedings/interim/2012/04/30/sidr/proceedings.html Pointers to the jabber log and the webex recording are in the minutes. The proceedings page does not yet show the uploaded files, so I am appending the minutes pdf here. Please send comments, corrections or additions to the list. One disappointing note. There were many complaints on the jabber about the distraction of the typing sounds in the audio. No one mentioned a constant echo in the audio. This makes the recording very difficult to listen to. I trust (from the lack of complaint) that this was not heard at the time by those on the conference call! I do not know why it is in the webex recording. --Sandy ------------------------------------------------------------------------ -------- > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr > From weiler@watson.org Thu May 17 04:10:21 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07AA721F8674 for ; Thu, 17 May 2012 04:10:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_15=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 449Cu-6nQEIN for ; Thu, 17 May 2012 04:10:20 -0700 (PDT) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by ietfa.amsl.com (Postfix) with ESMTP id 2070021F866D for ; Thu, 17 May 2012 04:10:19 -0700 (PDT) Received: from fledge.watson.org (localhost.watson.org [127.0.0.1]) by fledge.watson.org (8.14.4/8.14.4) with ESMTP id q4HBAH1S088065; Thu, 17 May 2012 07:10:17 -0400 (EDT) (envelope-from weiler@watson.org) Received: from localhost (weiler@localhost) by fledge.watson.org (8.14.4/8.14.4/Submit) with ESMTP id q4HBAGEq088060; Thu, 17 May 2012 07:10:17 -0400 (EDT) (envelope-from weiler@watson.org) X-Authentication-Warning: fledge.watson.org: weiler owned process doing -bs Date: Thu, 17 May 2012 07:10:16 -0400 (EDT) From: Samuel Weiler To: "t.petch" In-Reply-To: <012c01cd3407$14852d20$4001a8c0@gateway.2wire.net> Message-ID: References: <24B20D14B2CD29478C8D5D6E9CBB29F60F708799@Hermes.columbia.ads.sparta.com> <012c01cd3407$14852d20$4001a8c0@gateway.2wire.net> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.3 (fledge.watson.org [127.0.0.1]); Thu, 17 May 2012 07:10:17 -0400 (EDT) Cc: sidr@ietf.org Subject: Re: [sidr] minutes of 30 Apr 2012 interim meeting X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 May 2012 11:10:21 -0000 On Thu, 17 May 2012, t.petch wrote: > The attachment to this, which makes the size of the e-mail trip a spam > trap for me, is in .pdf, which I do not find friendly, not having an > Acrobat licence. Try an open-source PDF viewer. xpdf and evince work fine for me. > The jabber log lists 11 (and rising) logs for May 2012 - is the meeting > still going on:-) Read the logs and find out. :-) -- Sam From Sandra.Murphy@sparta.com Thu May 17 09:30:45 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A52121F866D for ; Thu, 17 May 2012 09:30:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.017 X-Spam-Level: X-Spam-Status: No, score=-102.017 tagged_above=-999 required=5 tests=[AWL=-0.618, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, J_CHICKENPOX_52=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E0fE8foQnKOW for ; Thu, 17 May 2012 09:30:42 -0700 (PDT) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by ietfa.amsl.com (Postfix) with ESMTP id 6E18921F8644 for ; Thu, 17 May 2012 09:30:42 -0700 (PDT) Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.14.4/8.14.4) with ESMTP id q4HGUdsL023132; Thu, 17 May 2012 11:30:39 -0500 Received: from Hermes.columbia.ads.sparta.com ([157.185.80.107]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id q4HGUcxQ003474; Thu, 17 May 2012 11:30:39 -0500 Received: from HERMES.columbia.ads.sparta.com ([2002:9db9:506b::9db9:506b]) by Hermes.columbia.ads.sparta.com ([::1]) with mapi id 14.01.0355.002; Thu, 17 May 2012 12:30:38 -0400 From: "Murphy, Sandra" To: "t.petch" , "sidr@ietf.org" Thread-Topic: [sidr] minutes of 30 Apr 2012 interim meeting Thread-Index: Ac0vWvM0YV1oyh/kRPqOkBhYZhRNdQErISatABC0L3U= Date: Thu, 17 May 2012 16:30:38 +0000 Message-ID: <24B20D14B2CD29478C8D5D6E9CBB29F625F05226@Hermes.columbia.ads.sparta.com> References: <24B20D14B2CD29478C8D5D6E9CBB29F60F708799@Hermes.columbia.ads.sparta.com>, <012c01cd3407$14852d20$4001a8c0@gateway.2wire.net> In-Reply-To: <012c01cd3407$14852d20$4001a8c0@gateway.2wire.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [157.185.63.118] Content-Type: multipart/mixed; boundary="_002_24B20D14B2CD29478C8D5D6E9CBB29F625F05226Hermescolumbiaa_" MIME-Version: 1.0 Subject: Re: [sidr] minutes of 30 Apr 2012 interim meeting X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 May 2012 16:30:45 -0000 --_002_24B20D14B2CD29478C8D5D6E9CBB29F625F05226Hermescolumbiaa_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Mmm, indeed.=0A= =0A= The meeting materials page records that minutes and agenda were uploaded su= ccessfully. So I do not know why it is not appearing in the proceedings pa= ge.=0A= =0A= Thanks for the alert. I'll check with the secretariat as to what happened.= =0A= =0A= As for the pdf - the Acrobat reader is openly available without a license, = as far as I know. As noted, there are other openly available readers. And= it is one of the accepted formats for submitting minutes. So publishing i= n pdf is within requirements. =0A= =0A= That of course doesn't help you all that much, so I've constructed a .txt = file which is appended. Some formatting was lost, so I'd advise viewing th= e pdf if you can.=0A= =0A= As for the jabber logs - there are jabber logs for many more days than the = wg has scheduled meetings. Access to the jabber room is open to all at any= time. You can not conclude that there was a meeting from the existence of= a jabber log for any day.=0A= =0A= --Sandy=0A= ________________________________________=0A= From: t.petch [ietfc@btconnect.com]=0A= Sent: Thursday, May 17, 2012 4:28 AM=0A= To: Murphy, Sandra; sidr@ietf.org=0A= Subject: Re: [sidr] minutes of 30 Apr 2012 interim meeting=0A= =0A= Mmmm=0A= =0A= The proceedings page still has no link for Minutes or Agenda, 18 days=0A= on.=0A= =0A= The attachment to this, which makes the size of the e-mail trip a spam=0A= trap for me, is in .pdf, which I do not find friendly, not having an=0A= Acrobat licence.=0A= =0A= The jabber log lists 11 (and rising) logs for May 2012 - is the meeting=0A= still going on:-)=0A= =0A= Mmm=0A= =0A= Tom Petch=0A= =0A= ----- Original Message -----=0A= From: "Murphy, Sandra" =0A= To: =0A= Sent: Friday, May 11, 2012 10:57 AM=0A= Subject: [sidr] minutes of 30 Apr 2012 interim meeting=0A= =0A= =0A= The minutes of the 30 Apr 2012 interim meeting have been uploaded to the=0A= proceedings site.=0A= =0A= The minutes can be found at the proceedings page for the meeting:=0A= =0A= http://www.ietf.org/proceedings/interim/2012/04/30/sidr/proceedings.html=0A= =0A= Pointers to the jabber log and the webex recording are in the minutes.=0A= =0A= The proceedings page does not yet show the uploaded files, so I am=0A= appending the minutes pdf here.=0A= =0A= Please send comments, corrections or additions to the list.=0A= =0A= One disappointing note. There were many complaints on the jabber about=0A= the distraction of the typing sounds in the audio. No one mentioned a=0A= constant echo in the audio. This makes the recording very difficult to=0A= listen to. I trust (from the lack of complaint) that this was not heard=0A= at the time by those on the conference call! I do not know why it is in=0A= the webex recording.=0A= =0A= --Sandy=0A= =0A= =0A= ------------------------------------------------------------------------=0A= --------=0A= =0A= =0A= > _______________________________________________=0A= > sidr mailing list=0A= > sidr@ietf.org=0A= > https://www.ietf.org/mailman/listinfo/sidr=0A= >=0A= =0A= =0A= --_002_24B20D14B2CD29478C8D5D6E9CBB29F625F05226Hermescolumbiaa_ Content-Type: text/plain; name="sidr.interim.30Apr2012.notes.txt" Content-Description: sidr.interim.30Apr2012.notes.txt Content-Disposition: attachment; filename="sidr.interim.30Apr2012.notes.txt"; size=30485; creation-date="Thu, 17 May 2012 16:30:03 GMT"; modification-date="Thu, 17 May 2012 16:30:03 GMT" Content-ID: Content-Transfer-Encoding: base64 DQpXZWJleCByZWNvcmRpbmc6IA0KaHR0cHM6Ly9pZXRmLndlYmV4LmNvbS9pZXRmL2xzci5waHA/ QVQ9cGImU1A9RUMmcklEPTY3MTQxMjcmcktleT0wYWQ1ZGQyOTdjZjQNCmIxM2UNCg0KSmFiYmVy IExvZzogaHR0cDovL3d3dy5pZXRmLm9yZy9qYWJiZXIvbG9ncy9zaWRyLzIwMTItMDQtMzAuaHRt bA0KDQoNCk1lZXRpbmcgZGVsYXllZCBkdWUgdG8gdGVjaG5pY2FsIGRpZmZpY3VsdGllcyCWIGdl dHRpbmcgcmVtb3RlIHBhcnRpY2lwYXRpb24gdG9vbHMgd29ya2luZyANCnRvZ2V0aGVyICh0ZWxl Y29uZmVyZW5jZSBjYWxsLCB3ZWJleCBzZXNzaW9uLCB3ZWJleCBpbnRlZ3JhdGVkIGNvbmZlcmVu Y2UgY2FsbCwgDQpjb25mZXJlbmNlIHBob25lLCBmZWVkYmFjaywgZXRjLikNCg0KQ2hyaXMgTW9y cm93IGFuZCBTYW5keSBNdXJwaHkgc2VydmluZyBhcyBjaGFpcnMNCg0KSW50cm8gc2xpZGVzIChu b3RlIHdlbGwsIGhvdXNla2VlcGluZyB0YXNrcywgYWdlbmRhKSB2aWV3ZWQNCg0KKG5vdGVzIHNs aWRlIDIpDQpCYXNpYyBJbmNyZW1lbnRhbCBEZXBsb3ltZW50IFN0cmF0ZWd5DQqVCU9yaWdpbiBW YWxpZGF0aW9uDQqWCURlcGxveSBjb2RlDQqWCVN0YXJ0IGRvaW5nIHNvbWUgbWV0cmljcw0KlglT dGFydCB0dXJuaW5nIGl0IG9uDQqVCUJncHNlYw0KlglEZXBsb3kgY29kZQ0KlglTdGFydCBkb2lu ZyBzb21lIG1ldHJpY3MNCpYJU3RhcnQgY2hlY2tpbmcgliBsb2dnaW5nDQqWCURvbpJ0IG5lZWQg dG8gd29ycnkgYWJvdXQgbG9jYWwgb3JpZ2luYXRlZCByb3V0ZQ0KDQoobm90ZXMgc2xpZGUgMykN Ck9wZXJhdGlvbmFsIElzc3VlcyBpbiBJbmNyZW1lbnRhbCBEZXBsb3ltZW50DQqVCUJncHNlYyBp bmNyZW1lbnRhbCBkZXBsb3ltZW50DQqWCVJhbmR5OiBpZiBJIGFtIG9uIHRoaXMgcm91dGVyLCBJ IHdhbnQgb3JpZ2luIHZhbGlkYXRpb24gY2hlY2tlZCBub3cgb24gdGhpcyANCnJvdXRlciCWIGRv bpJ0IHdhbnQgdG8gZmluZCBvdXQgZnJvbSBuZWlnaGJvcnMgdGhhdCB0aGluZ3MgYXJlIGJhZA0K lglDaHJpcyBzYXlzIHdhbnQgdG8gY2hlY2sgc2lnbmF0dXJlcyB0byBtYWtlIHN1cmUgdGhlIG9y aWdpbiBpcyB2YWxpZGF0ZWQgDQphbmQgYXV0aGVudGljDQqWCUNocmlzOklmIHlvdSBkb26SdCBo YXZlIFJScywgeW91IGhhdmUgZnVsbCBtZXNoLCBzaW1wbGVzdCBjYXNlDQqWCVJhbmR5OiBpZiBh IFJSIGFuZCBpdHMgY2xpZW50cyBoYXZlIG5vIGV4dGVybmFscywgdGhlbiB0aG9zZSBSUnMgZG9u knQgDQpuZWVkIHRvIHNwZWFrIGJncHNlYw0KlglKb2huOiB0byByZXBlYXQ6IGluIGdlbmVyYWwg UlJzIGhhdmUgdG8gYmUgYmdwc2VjIGF3YXJlIGJlY2F1c2UgYmdwc2VjIA0KYXR0cmJzIGFyZSBu b24tdHJhbnNpdGl2ZS4gQnV0IG9ubHkgdGhvc2UgUlJzIGluIGEgY29udHJvbCBwYXRoIGJldHcg dHdvIA0KZWJncCBib3JkZXJzIG5lZWQgdG8gaGF2ZSBiZ3BzZWMgZW5hYmxlZC4NCpYJQ2hyaXM6 IGluIHRoZSBjYXNlIG9mIGJncHNlYyBjYXBhYmlsaXR5IG5lZ290aWF0ZWQgliBkb26SdCBzZW5k IGF0dHJicy4gIFNvIGlmIA0KUlIgaXMgbm90IGJncHNlYyBhd2FyZSB3aWxsIG5vdCByZWNlaXZl IGF0dHJicyBhbmQgdGhleSBkb26SdCBnZXQgdG8gb3RoZXIgDQpzaWRlIG9mIEFTLiAgU28gUlJz IG5lZWQgdG8gYmUgdXBncmFkZWQgd2hlbiB0aGV5IGFyZSBpbiB0aGUgY29udHJvbCBwYXRoIA0K YmV0d2VlbiBlYmdwIHJvdXRlcnMuDQqWCVJhbmR5OiB0aGVyZSBhcmUgcm91dGVycyBpbiB5b3Vy IHRvcG9sb2d5IHRoYXQgd2lsbCBub3QgbmVlZCB0byBiZSBiZ3BzZWMgDQphd2FyZSBmb3IgeW91 ciBBUyB0byBiZSBiZ3BzZWMgY2FwYWJsZS4gIFNvbWUgcm91dGVycyB3aWxsIGJlIGJncHNlYyAN CmNhcGFibGUgYnV0IG1heSBub3QgdmFsaWRhdGUgYW5kIG1heSBzaWduIGFueXdheS4gDQqWCUZv ciBsb2NhbGx5IG9yaWdpbmF0ZWQgcm91dGVzIJYgeW91IG9ubHkgYXBwbHkgYmdwc2VjIGF0dHJi cyAoc2lnbmF0dXJlcykgDQp3aGVuIHlvdSBhcmUgc2VuZGluZyB0aGUgdXBkYXRlIG92ZXIgYW4g ZWJncCBzZXNzaW9uDQoNCihub3RlcyBzbGlkZSA0KQ0KW1NpZGViYXI6IElzc3VlcyBpbiBQcm90 b2NvbCBEZXBsb3ltZW50XQ0KlQlTdGFjayBvZiB0byBiZSBkaXNjdXNzZWQNCpYJQ29uZmVkcw0K lglBZGQtcGF0aA0KlglBUyBhbGlhc2VzIChyZXBsYWNlLWFzIGluIGp1bmlwZXIgc3BlYWspDQqW CUZvcndhcmQgcG9saWN5IChlZyByb3V0ZSBzZXJ2ZXJzKSCWYnJpZWYgZGlzY3Vzc2lvbiBwb2lu dGVkIHRvIG5lZWQgZm9yIA0KZmlybSBkZWZpbml0aW9uIChpcyByb3V0ZSBzZXJ2ZXIgZXhhbXBs ZSBvbmx5IGNhc2U/IEV0Yy4pDQqWCUJyaWFuknMgQUgtSEEgdG8gYmUgZXhwbGFpbmVkIGxhdGVy DQoNCihub3RlcyBzbGlkZSA1KQ0KT3BlcmF0aW9uYWwgSXNzdWVzIGluIEluY3JlbWVudGFsIERl cGxveW1lbnQgKGNvbnRpbnVlZCkNCpUJSW4gYmdwc2VjIHdlIG9ubHkgZG8gc2lnbmF0dXJlcyBh bmQgdmFsaWRhdGlvbnMgb2Ygc2lnbmF0dXJlcyBhdCB0aGUgYm9yZGVycw0KlglXaGF0IGFib3V0 IFJScyBkb2luZyBiZXN0IHBhdGggc2VsZWN0aW9uDQqWCUE6RWRnZSByb3V0ZXIgcGFzc2VzIG9u IHJlc3VsdHMgb2YgaXRzIHNpZ25hdHVyZSB2YWxpZGF0aW9uIGluIHNvbWUgQVMgDQpzcGVjaWZp YyBwb2xpY3kga25vYiAoY29tbXVuaXR5LCBsb2NhbHByZWYsIGV0YykNCpYJUTogaXMgdGhlcmUg YW55IHJlcXVpcmVtZW50IHRoYXQgUlIgY29uc2lkZXIgc2lnbmF0dXJlcyBpbiBiZXN0IHBhdGgg DQpzZWxlY3Rpb24NCpYJQTogKFJ1ZWRpZ2VyKSBSUiBzaG91bGQgZG8gaXRzIGJlc3QgcGF0aCBz ZWxlY3Rpb24gYmFzZWQgb24gdGhpcyBsb2NhbCANCnBvbGljeSBrbm9iDQqWCUE6IChKYXNvbikg dGhlIGxvY2FsIHBvbGljeSBrbm9iIGlzIG5vdCBiZ3BzZWMgYXR0cmlidXRlIHNvIGFueSByb3V0 ZXIgY2FuIA0KbWFrZSBhIGRlY2lzaW9uIGJhc2VkIG9uIHRoYXQuICBPcGVyYXRpb25hbCBxdWly ayCWIGhhdmUgdG8gc2V0IHVwIFJSIHRvIA0KbWFrZSBkZWNpc2lvbnMgb24gbG9jYWxseSBvcmln aW5hdGVkIHJvdXRlcyBhcyBpZiB0aGV5IHdlcmUgc2lnbmVkLg0KlglBOiBSYW5keTogcm91dGVz IGlzIG1hcmtlZCBzb21laG93IJYgYW5kIHRoZSBtYXJrIGlzIGF2YWlsYWJsZSB0byB5b3VyIA0K cG9saWN5Lg0KlglBOiBKb2huOiB5b3Ugc2hvdWxkIG1hcmsgdGhlIHJvdXRlIGFzIGlmIGl0IGhh ZCBiZWVuIHNpZ25hdHVyZSBjaGVja2VkIGFuZCANCm1hcmtlZCAoeW91IHRydXN0IHlvdXJzZWxm IHRvIGhhdmUgbG9jYWxseSBvcmlnaW5hdGVkKQ0KlglROiBTYW5keTogeW91IGhhdmUgdG8gYmUg Y2FyZWZ1bCB0byBtYWtlIHN1cmUgdGhhdCB0aGVyZZJzIG5vIHN0cmFuZ2Ugd2F5IA0KdG8gbWFr ZSB0aGUgQVNfUEFUSCBudWxsIHNvIGFuIGV4dGVybmFsIHBhdGggZG9lc26SdCBsb29rIGxvY2Fs IChhcyBhbiANCmF0dGFjaykNCpYJQTogQnJpYW46IGlmIHlvdSByZWRpc3RyaWJ1dGUgZnJvbSBi Z3AgdG8gaWdwIGFuZCBiYWNrIHRvIGJncCwgb3JpZ2luIA0KdmFsaWRhdGlvbiBzaG91bGQgY2F0 Y2ggdGhhdC4NCihub3RlcyBzbGlkZSA2KQ0KlQlBbm90aGVyIGluZmxlY3Rpb24gcG9pbnQ6DQqW CUdvaW5nIGZyb20gbm90IGRvaW5nIGJncHNlYyB0byBkb2luZyBiZ3BzZWMNCpYJQ291bGQgY2hh bmdlIHByZWZlcmVuY2Ugb2YgYmVzdCBwYXRoIA0KlQlDb3VsZCBtYWtlIGJpZyBjaGFuZ2VzIGlu IHRyYWZmaWMgbW92ZW1lbnQgaW4geW91ciBBUywgdHJhZmZpYyANCnN3aW5ncw0KlglSYW5keTog YXQgbGF5ZXIgOSwgd2UgYXJlIGdvaW5nIHRvIGEgbW9yZSBzZWN1cmUgbmV0d29yaywgdGhhdJJz IGEgZmVhdHVyZSENCpYJQ2hyaXM6IGhvcGVmdWxseSB5b3UgZG8gc29tZSBtb2RlbGluZyBmaXJz dA0KlQlJbiBjYXNlIG9mIDcwMSwgYXMtcGF0aCB3aW5zLCBub3QgcGVlcg0KlglCcmlhbjogbXVj aCBiaWdnZXIgdGhhbiB0aGF0LiAgV2hlbiBjaGFuZ2Ugb2YgcG9saWN5IG9mIHR3byBiZ3BzZWMg DQpjYXBhYmxlIHBlZXJzLCB0byBjaGFuZ2UgdG8gcHJlZmVyIHNpZ25lZCByb3V0ZXMsIHlvdSBt YXkgaGF2ZSBkaWZmaWN1bHRpZXMgDQptYWtpbmcgdGhhdCBhbiBpbmNyZW1lbnRhbCBjaGFuZ2UN CpYJUmFuZHk6IHlvdSBhcmUgY2hhbmdpbmcgeW91ciBwb2xpY3ksIHlvdSBrbm93IHRoZXJlIHdp bGwgYmUgDQpjb25zZXF1ZW5jZXMsIHRoZXNlIGFyZSBjb25zZXF1ZW5jZXMgeW91IHdhbnQgdG8g aGF2ZSBoYXBwZW4uDQqWCVdlczogbmVlZCB0b29scyBSYW5keTogaGF2ZSB0b29scyBub3cgdG8g bW9kZWwgcG9saWN5IGNoYW5nZQ0KlglCcmlhbjogYnV0IHRoZXJlIG1heSBub3QgYmUgYSB3YXkg dG8gdGVsbCB3aG8gZ29lcyBmaXJzdCCWIGNoaWNrZW4gYW5kIGVnZw0KlglDaHJpczogaW50ZXJu YWxseSwgeW91IG1heSBjaG9vc2UgdG8gcHJlZmVyIHNpZ25lZCwgYnV0IHByb2Nlc3Mgd2lsbCBi ZToNCpUJRGVwbG95IGNvZGUNCpUJRmlyc3QgbWFyayByb3V0ZXMgd2l0aCBwb3RlbnRpYWwgYmdw c2VjIHJlc3VsdA0KlQlMb29rIGFuZCBzZWUgd2hhdCBpcyByaWdodCBhbmQgd2hhdCBpcyB3cm9u Zw0KlQlTdGlsbCBiZWxpZXZlIHRoaXMgd2lsbCBiZSBtdWx0aS15ZWFyIHByb2Nlc3MgKDU/IDc/ KQ0KlQlOb3QgYSBmbGFnIGRheS4NCpYJV2VzOiBpbiBkb2N1bWVudGF0aW9uIG9mIHNpbXBsZSBj YXNlIG9yIHNvbWV3aGVyZQ0KlQlVcGRhdGUgY29kZQ0KlQlXYXRjaCB3aGF0IGdvZXMgYnkgYW5k IHNlZSB3aGF0IGNoYW5nZXMgliBkdW1wIHNvbWV3aGVyZSBlbHNlDQqVCVJpZ2h0IHBvbGljeSBi YXNlZCBvbiB0aGF0LCBiZWZvcmUgeW91IHB1bGwgdHJpZ2dlciBvbiBwb2xpY3kgDQpjaGFuZ2UN CpUJRG9uknQgZHJvcCBpbnZhbGlkIGluaXRpYWxseSwganVzdCBkb3ducHJlZiBpdC4NCpUJTWF5 YmUgdGhpcyBnb2VzIGluIGEgc2Vjb3BzIGRyb3ANCihub3RlcyBzbGlkZSA3KQ0KlQlSYW5keTog b3BzIGRvIHRoZXNlIHRoaW5ncyBldmVyeSBkYXksIHdlIGhhdmUgdG9vbHMgKG5vdCBncmVhdCks IHdlIGRvIA0KZGVwbG95bWVudHMsIHVwZ3JhZGUgbGlua3MsIGV0Yy4NCpUJQnJpYW46IGltcGFj dCBpcyBtaW5pbWl6ZWQgYnkgbWFraW5nIHBvbGljeSBjaGFuZ2UgbGF0ZQ0KlQlDaHJpczogZXZl cnkgbmV0d29yayB3aWxsIG1ha2UgYSBkaWZmZXJlbnQgY2hvaWNlLiAgQW5kIGEgZGVwbG95bWVu dCB0aW1lIGZyYW1lIA0Kb2YgeWVhcnMuICBCdXQgbm90IGEga25pZmUgZWRnZSBkZXBsb3ltZW50 IJYgdGFrZXMgYSBjb3VwbGUgeWVhcnMgb2YNCpUJQ2hyaXMvSm9objogZG8gd2UgbmVlZCBhbiBS RkMsIG9yIGEgcHJlc2VudGF0aW9uLCBKb2huOiBidXQgY29uZmVkcyBtYXkgbmVlZCANCnByb3Rv Y29sIGNoYW5nZSwgQ2hyaXMvSm9objogc29tZSBjb21tb24gZGVwbG95bWVudCtuZXR3b3JrIG1v ZGVscw0KlQlXYXJyZW46IGlzbpJ0IHRoaXMganVzdCBhbm90aGVyIGtub2IgaW4gcG9saWN5PyAg QnV0IHRoZW4gdGhlcmUgYXJlIHByZXNlbnRhdGlvbnMgDQphYm91dCBob3cgeW91IHR1bmUgbWVk cywgc28gbWF5YmUuDQqVCUNocmlzOiBkb26SdCB0aGluayB0aGlzIGlzIFJGQywgbWF5YmUgdmVu ZG9yIGRvY3MuDQqVCUJyaWFuOiB0aGluayBSRkMgaXMgcmlnaHQgZG9jdW1lbnRhdGlvbiBtb2Rl bCAganVzdCBzaW1wbGUgY2FzZSB3aXRoIFJScy4gIA0KKEhhdmVuknQgcHJvdmVkIGl0IGlzIHNj YWxhYmxlIGlmIHlvdSBjYW6SdCBzaG93IHlvdZJ2ZSBjb25zaWRlcmVkIHRoYXQuKSAgQnJpYW4g DQp2b2x1bnRlZXJzIHRvIHdyaXRlIHVwIHNpbXBsZSBjYXNlIHdpdGggUlJzLg0KlQlSdWVkaWdl cjogcmVtZW1iZXIgNGJ5dGUgQVMgYXR0cmlidXRlIJYgdGhlcmUgd2FzIG5vIGRlcGxveW1lbnQg ZHJhZnQuICBDaHJpczogDQp0byBSdWVkaWdlciCWIGFyZSB5b3Ugc2F5aW5nIHRoYXQgd2VudCB3 ZWxsIGFuZCBpcyBwcm9vZiB3ZSBkb26SdCBuZWVkIGEgZHJhZnQsIG9yIA0KdGhhdCBpcyBhIHdh cm5pbmcgdGhhdCB3ZSBETyBuZWVkIG9uZS4NCpUJUmFuZHk6IGNhbpJ0IHdyaXRlIGRvY3MgZm9y IGFsbCB0aGUgcG9zc2libGUgdGhpbmdzIGl0IHdvdWxkIGJlIGdvb2QgdG8ga25vdy4gIA0KV2hl cmUgZG8geW91IGRyYXcgYSBsaW5lLiAgTmVlZCBhIGRlY2lzaW9uIG9mIHdoYXQgTVVTVCBnbyBp bi4gIEhlYXRoZXI6IGRvY3MgDQpjYW6SdCBodXJ0IJYgd2hhdCBpcyB0aGUgZG93biBzaWRlPw0K KG5vdGVzIHNsaWRlIDgpDQpBZnRlciBCcmVhayCWIE5leHQgVG9waWNzPzogRm9yd2FyZCBQb2xp Y3kgU2lnbmluZw0KlQlKb2huOiB2b3RlcyB0byBkaXNjdXNzIHRoaW5ncyB0aGF0IGNoYW5nZSBw cm90b2NvbCBzcGVjLiAgRWcgY29uZmVkcw0KlQlCcmlhbiBiZWdpbnM6IG5lZWQgc29tZSB3YXkg Zm9yIHNpZ25lciBzZW5kaW5nIHVwZGF0ZSB0byBleHByZXNzIHdoYXQgaXQgd2FzIA0KYXV0aG9y aXppbmcgdGhlIHJlY2lwaWVudCB0byBkby4gIGVnLjogYXV0aG9yaXppbmcgcm91dGUgc2VydmVy IHRvIHJlbW92ZSBpdHNlbGYgZnJvbSANCmFzLXBhdGgNCpYJSWYgdGhlIHJlY2lwaWVudCBtaWdo dCBkbyBzb21ldGhpbmcgb3RoZXIgdGhhbiBqdXN0IGFkZCBpdHMgYXMgdG8gdGhlIGFzLXBhdGgs IA0KdGhlcmUgc2hvdWxkIGJlIHNvbWV3aGVyZSB0aGF0IHRoaXMgYXV0aG9yaXphdGlvbiBzaG91 bGQgYmUgZXhwcmVzc2VkLg0KlQlKb2huOiBpbnRlcmVzdGluZywgYnV0IG9sZCBiZ3BzZWMgZ29h bCB3YXMgdG8gcHJvdGVjdCB3aGF0IGlzIGN1cnJlbnRseSBpbiBiZ3AgDQp3aXRob3V0IGNoYW5n aW5nIHRoZSBzcGVjkmQgbW9kZWwuIFlvdSBhcmUgdGFsa2luZyBhYm91dCBjaGFuZ2luZyB0aGUg YmdwIA0Kc3BlY5JkIGJlaGF2aW9yLiAgTWlnaHQgYmUgYSBub24tdHJpdmlhbCBjaGFuZ2UuDQqV CVJvYjogeW91IG1pZ2h0IHdhbnQgdG8gdGhpbmsgYWJvdXQgd2hldGhlciB0aGlzIG5lZWRzIHRv IGJlIGluIHRoZSBiZ3BzZWMgDQpwcm90b2NvbCCWIG1heWJlIGEgbmV3IHJwa2kgb2JqZWN0Pw0K lQlXYXJyZW46IHlvdSBoYXZlIG9uZSBzdWdnZXN0aW9uIJYgYnV0IHRoZXJlIGFyZSBsb3RzIG9m IG90aGVycy4gIENhcnJ5aW5nIHBvbGljeSANCmFyb3VuZA0KlQlSYW5keTogbm90IGNhcnJ5aW5n IHBvbGljeSCWIGNhcnJ5aW5nIGEgcG9saWN5IG9mIHdoYXQgWU9VIGNhbiBkbyCWIGEgdmVyeSBk ZWVwIA0KaG9sZQ0KlQlKb2huOiBpcyB0aGVyZSBnb29kIHNlbWFudGljcyBpbiB3aGF0IHdlIGhh dmUgbm93PyAgSXMgdGhlcmUgcm9vbSBmb3IgbGF0ZXIgYWRkZWQgDQpzZW1hbnRpY3M/ICBUaG9z ZSBzaG91bGQgYmUgdGhlIGRlY2lzaW9uIHBvaW50cw0KlQlCcmlhbjogYnV0IGJncHNlYyBpcyBh dXRob3JpemluZyB0aGUgcGF0aCB2YWxpZGF0aW9uIHRoYXQgY29tZXMgdG8geW91DQqVCVJhbmR5 OiBidXQgd2UgZm9yd2FyZCBvbiBkZXN0aW5hdGlvbiwgd2UgYWNjZXB0IGFzLXBhdGggYW5kIHBy b3BhZ2F0ZQ0KlQlCcmlhbjogYnV0IHdlIGFyZSB2YWxpZGF0aW5nIHRoZSBwYXRoLCByaWdodD8N CpUJUmFuZHkvSm9objogeWVzLCBwYXRoIHdlIGdvdCwgIHlvdSBhcmUgdGFsa2luZyBhYm91dCBw YXRoIGZvcndhcmQuDQoobm90ZXMgc2xpZGUgOSkNClJvdXRlIFNlcnZlcg0KlQlZIGRvZXMgbm90 IGtub3cgdGhhdCBSUyBpcyByZWFsbHkgYSByb3V0ZSBzZXJ2ZXINCpUJWCBhbmQgWSBzaG91bGQg YXV0aG9yaXplIGFuZCBjaGVjayB0aGUgcm9sZSBvZiB0aGUgcm91dGUgc2VydmVyDQqVCVJhbmR5 OiBZIGNhbiB2YWxpZGF0ZSB0aGF0IHNvbWVvbmUgZG9pbmcgcGNvdW50PTAgaXMgYSByb3V0ZSBz ZXJ2ZXIgdG8gaXQNCpUJSG93IGRvZXMgWiBrbm93IHRoYXQgWSB3YXMgY29ycmVjdCBpbiB3aGF0 IGl0IGRpZA0KICAgICAgICAgICAgICAgICAgICAgICAgWCAgIC0tLS0tPiAgICAgUlMgICAtLS0t PiAgWSAgIC0tLT4gICBaDQqVCVJhbmR5OiBYIHNheWluZyB0aGF0IFJTIGlzIGFuIGF1dGhvcml6 ZWQgcm91dGUgc2VydmVyIGlzIGZvcndhcmQgcG9saWN5IHJlc3RyaWN0aW9uDQqVCUFuZCBpcyBh IGJpZyBob2xlDQqVCVJhbmR5OiB3ZSBhcmUgdHJ5aW5nIHRvIHByb3RlY3QgdGhlIHByb3RvY29s IGZyb20gYmVpbmcgdmlvbGF0ZWQsIG5vdCB0aGUgYnVzaW5lc3MgDQpyZWxhdGlvbnNoaXANCpUJ Sm9objoga2luZGEgYW5hbGdvdXMgdG8gcm91dGUgbGVha3MgliB5b3Ugd2FudCBaIHRvIHNlY29u ZCBndWVzcyBpZiB3aGF0IFkgZGlkIA0Kd2FzIGluIGFjY29yZGFuY2Ugd2l0aCB3aGF0IFggd2Fu dGVkIGl0IHRvIGRvLiAgIEdpdmVuIHRoYXQgd2UgaGF2ZSB0aGUgb3B0aW9uIA0KZm9yIFkgdG8g Y2hlY2sgdGhlIHVzZSBvZiBwY291bnQgYW5kIHJpZ2h0IG5vdyBaIG11c3QgdHJ1c3QgdGhhdC4g IFN1cHBvc2UgeW91IA0Kc3R1Y2sgc29tZXRoaW5nIGluIFJQS0kgliB3aG8gd291bGQgYmUgbWFr aW5nIHRoZSBhdXRob3JpemF0aW9uDQqVCUJyaWFuOiBhbGwgbWVtYmVycyBvZiB0aGUgcm91dGUg c2VydmVyIHdvdWxkIGF1dGhvcml6ZSByb3V0ZSBzZXJ2ZXINCpUJSmFzb246IGViZ3AgbXVsdGkt aG9wIGFuZCBncmUgdHVubmVscyBzaG91bGQgYmUgY29uc2lkZXJlZCBhcyB3ZWxsLg0KKG5vdGVz IHNsaWRlIDEwKQ0KRGlzY3Vzc2lvbiBvZiBDb25mZWRzDQqVCUlzIHRoZXJlIHNvbWUgd2F5IHRv IGluZGljYXRlIHRoYXQgdGhlIGFzLXBhdGggaXMgb25seSBmb3IgaW4gdGhlIGJvdW5kYXJ5IG9m IGEgDQpjb25mZWQ/DQqVCUlzIHRoZXJlIGEgd2F5IHRvIGluZGljYXRlIHNlbWFudGljcyBub3Qg YWxyZWFkeSBjb3ZlcmVkIGluIHRoZSBiZ3BzZWMgYXR0cmI/DQqVCUlzc3VlIHdpdGggY29uZmVk czoNCpYJSW4gY3VycmVudCByZWFsIHdvcmxkIJYgeW91IGhhdmUgc29tZSBzdWItYXOScywgYWRk aW5nIHRoZW1zZWx2ZXMgdG8gdGhlIA0KcGF0aCBhcyBhcy1jb25mZWQgc2VxdWVuY2VzLCBnZXQg cmVtb3ZlZCBhdCBib3VuZGFyaWVzLg0KlglCdXQgbm8gd2F5IHRvIGFkZCB0aGVzZSBhcy1jb25m ZWQgdHlwZSB0aGluZ3MgaW4gdGhlIGFzLXBhdGguICBOZWVkZWQgZm9yIA0KbG9vcCBkZXRlY3Rp b24uDQqWCU5lZWQgc29tZSBmbGFnIGluIHNpZyBhdHRyYj8gIE1hcmsgZWFjaCCWIHRocm93IGF3 YXkgYWxsIG9mIHRoZSBjb25mZWQtDQptYXJrZWQgc2lnIGF0dHJiLg0KlglXYXJyZW46IGRvbpJ0 IHlvdSBrbm93IGFsbCB0aGUgYXOScyB1c2VkIGluc2lkZSB0aGUgYm91bmRhcnk/IEE6IHlvdSAN CmRvbpJ0IGtub3cgdGhlIGVudW1lcmF0aW9uDQqWCVJhbmR5OiBzcGVjIHNheXMgaXQgY2FuIGJl IGFyYml0cmFyeSB0b3BvbG9naWVzLCBidXQgZGVwbG95ZWQgdG9wb2xvZ2llcyANCmFyZSBtb3Jl IHNpbXBsZSCWIGEgY29yZSBBUyB3aXRoIHNvbWUgc3R1YiBBU3MgYXR0YWNoZWQgdG8gY29yZS4N CpYJUTpTYW5keSCWIGV4dGVybmFsIGxpbmtzIGNvbWUgaW4gd2hlcmU/DQqWCVJhbmR5OiB0aGUg c2ltcGxlIGNhc2UgliBvbmx5IHBvc3NpYmxlIGxvb3BzIGluIHRoaXMgY2FzZSB3b3VsZCBiZSBz b2x2ZWQgDQpieSBhZGRpbmcgbm9ybWFsIHNpZyBhdHRyYnMgYW5kIHRoZW4gZHJvcHBpbmcgYXQg dGhlIGJvdW5kYXJpZXMuDQqWCVJvYjogdGhpbmsgSm9obiBzYXlzOiBtYXJrIGNvbmZlZHMgaW5z aWRlIGNvbmZlZCBzbyB0aGVyZSBpcyBhbiBlYXN5IHdheSANCnRvIHN0cmlwIHRoZSBjb25mZWQg c2lncy4gIFJhbmR5IHNheXM6IGluc2lkZSBjb25mZWQsIGFkZCBzaWdzIGFzIHVzdWFsIGFuZCAN CnN0cmlwIGF0IGJvcmRlci4NCpYJSm9objogY3VycmVudCBiZ3AgaW1wbGVtZW50YXRpb24gc3Ry aXBzIGFsbCBjb25mZWQgc2VxdWVuY2VzIGFuZCBkb2VzIG5vdCANCmNvbnNpZGVyIHRoZSBhcyBu dW1iZXINCpYJSm9objogdGhpcyBpcyBwYXJ0IG9mIGRpc2N1c3Npb24gb2YgY2FuIHdlIGdldCBy aWQgb2YgQVMtUEFUSCBlbnRpcmVseQ0KlglSYW5keTogZXh0ZXJuYWwgQVMgbmVpZ2hib3Igb2Yg c3R1YiBBUyBpbiB0aGUgY29uZmVkIHRvcG9sZ3kga25vd3Mgb25seSANCnRoZSBjb3JlIEFTIG51 bWJlci4gIEV4dGVybmFsbHkgb25seSBjb3JlIEFTIG51bWJlciBpcyBzZWVuLg0KlglCcmlhbjog d2UgY291bGQgZG8gdGhpcyB1c2luZyBwY291bnQ9MCwgdXNpbmcgc29tZSBsb2NhbCBBUw0KDQo8 PDwgcGljdHVyZSBhdCBib2FyZCB3YXMgbGFyZ2UgY2lyY2xlIGxhYmVsZWQgImNvcmVBUyIgd2l0 aCBzbWFsbGVyIGNpcmNsZXMgYWRqb2luaW5nIGF0IA0KdGhlIGJvdW5kYXJ5IGJlaW5nIHRoZSBz dHViIEFTcz4+Pg0KDQoobm90ZXMgc2xpZGUgMTEpDQqVCUpvaG46IGJ5IGRlZm46IHlvdSBkb26S dCB1c2UgY29yZSBBUyBhcyB0aGUgcHVibGljIEFTLiAgUmFuZHk6IG9oLCBubywgbm90IHRydWUu ICANCkpvaG46IG9vbywgZGlkIG5vdCBrbm93IHRoYXQgY291bGQgaGFwcGVuLiAgV2VzOiB0aGF0 knMgaG93IHdlIGRvIGl0IGFsc28uDQqVCUNocmlzOiBleHRlcm5hbCB0byBlYmdwIHJvdXRlciBp biBzdWJBUywgY2JncCBmcm9tIHN1YkFTIHRvIGNvcmUsIEV4dGVybmFsIA0KZm9yd2FyZCBzaWdu cyB0byBlYmdwIGN1c3RvbWVyIGZhY2lnbiByb3V0ZXIsIGNiZ3BzIGZvcndhcmQgc2lnbnMgdG8g Y29yZSwgY2JncCANCmJ5IGNvcmUgdG8gc3ViQVMsIHRoZW4gc3ViQVMgZWJncCByb3V0ZXIgd2Fu dHMgdG8gc3RyaXAgdGhlIGZpcnN0IHN1YkFTIG51bWJlciANCmFuZCBkb2VzIG5vdCBrbm93IHRo YXQgc3ViQVMgbnVtYmVyLiAoSGFyZCB0byBkbyB0aGlzIGluIHRleHQpLg0KlQlKb2huOiAgT25l IHdheSB0byB0ZWxsIHdoYXQgdG8gc3RyaXA6IHN0YXJ0IGF0IG9yaWdpbi4gIFdoZW4geW91IGZp bmQgYSBmb3J3YXJkIHNpZ24gDQp0byB5b3VyIHB1YmxpYyBBUywgc3RyaXAgZXZlcnl0aGluZyBw YXN0IHRoYXQuDQqVCShFeHRlcm5hbCBuZWlnaGJvciB0aGlua3MgaXQgaXMgY29ubmVjdGluZyB0 byB0aGUgcHVibGljIEFTLiAgQmVjYXVzZSBzb21lIHBlb3BsZSANCnVzZSB0aGUgcHVibGljIEFT IGFzIHRoZSBjb3JlIEFTLCBjYW6SdCB1c2UgdGhlIGNvcmUgQVMgYXMgdGhlIG1hcmtlciBvZiB0 aGUgDQpjb25mZWQgdG9wb2xvZ3kgYm9yZGVyLikNCpUJT25lIHRoaW5nIHRoYXQgdGhpcyBoYWNr IGRvZXMgYnJlYWs6IHJpZ2h0IG5vdyBpbiB0aGUgcHJvdG9jb2wsIG15IEFTIGNhbiBhcHBlYXIg DQppbiB0aGUgcHJvdG9jb2wgbW9yZSB0aGFuIG9uY2UgliB0aGUgYWxsb3cgbG9vcHMgKGFsbG93 IG93bkFTIGluIChpbiBjaXNjbyksIA0KbG9vcHMgKGluIGp1bmlwZXIpKQ0KlQlIZWF0aGVyOiBs aWVzIGFyZSBiYWQsIHNvIGRyb3BwaW5nIGxpZXMgYXJlIHBlcmZlY3RseSBmaW5lLg0KlQlXYXJy ZW46IHdoYXQgYWJvdXQgcGF0aCBwb2lzb25pbmc/ICBBOiBwYXRoIHBvaXNvbmluZyB3aWxsIG5v dCB3b3JrIGluIGJncHNlYy4gIA0KRW5kIHN0b3J5Lg0KlQkoV29yayBhdCBib2FyZCBlbXBoYXNp emluZyB0aGF0IGN1c3RvbWVyIGV4dGVybmFsIEFTIGNvbmZpZ3MgaXRzZWxmIGFzIHBlZXJpbmcg DQp3aXRoIHRoZSBwdWJsaWMgQVMuICBXZXMgd2FudHMgdG8gY29uZmlybSB3aXRoIGhpcyBuZXR3 b3JrLikNCihub3RlcyBzbGlkZSAxMikNCk1vcmUgQWdlbmRhIEJhc2hpbmcNCpUJU29tZSBlYXJs eSBkZXBhcnR1cmVzIHdhbnQgdG8gaW5mbHVlbmNlIHRoZSBhZ2VuZGEgb3JkZXJpbmcuDQqWCUNv bmZlZHMgKGNvbnSSZCkNCpYJQWRkLXBhdGgNCpYJQVMgYWxpYXNpbmcgKHJlcGxhY2UtQVMsIGxv Y2FsLUFTLCBldGMuKQ0KlglSZXZpc2l0IHRoZSBpbmNyZW1lbnRhbCBpbnRyYS1BUyBkZXBsb3lt ZW50IJYgYW55dGhpbmcgbW9yZSB0aGVyZT8NCpYJQVMtUEFUSCCWIGluIHRoZSBwcm90b2NvbA0K lQlCcmlhbiB0b29rIGZpdmUgbWluIHRvIGRpc2N1c3MgYSBvdXQtb2YtdGhlIGJveCB3YXkgdG8g ZG8gZGlmZmVyZW50IGNyeXB0byAobWF5YmUgDQpzaGFyZWQgc2VjcmV0IGJhc2VkKSCWIG9uIHRo ZSBsaXN0LiAgKFNlZSBCcmlhbidzIEFILUhBIGluIG5vdGVzIHNsaWRlIDMpDQoobm90ZXMgc2xp ZGUgMTMpDQpEaXNjdXNzaW9uIG9mIENvbmZlZHMgKGNvbnRkKQ0KlQlDb25mZWRzIHNvbHV0aW9u Og0KlglVc2UgcGNvdW50PTAgZXZlcnl3aGVyZSBhbmQgc3RyaXAgYWxsIHBjb3VudD0wIHRoYXQg aGF2ZSB5b3VyIEFTIGluIA0KdGhlbS4NCpUJUHJvYmxlbSCWIHlvdSBtYXkgYmUgdXNpZ24gYSBz dWItYXMgdG8gcGVlciB3aXRoIGEgUlMNCpUJSGF2ZSBhbiBhdHRyaWJ1dGUgdGhhdCBoYXMgYW4g YXR0cmliIHRoYXQgY2FycmllZCB0aGUgY29uZmVkIG5hdHVyZSBvZiBwYXRocy4gIEpvaG4gDQpw cm9wb3NlcyB0aGF0IHRoYXQgYXR0cmIgaXMgdGhlIGFzLXBhdGgsIGJ1dCB0aGF0IGF0dHJiIGlz IG5vdCBjdXJyZW50bHkgaW4gdGhlIGJncHNlYyANCnByb3RvY29sDQqWCVNyaXJhbTogdGhlIGFz knMgYXJlIGluIHRoZSBiZ3BzZWMgYXR0cmIgQTogYnV0IHdlIGFyZSBzcGVha2luZyBhYm91dCB0 aGUgDQpyZWFsIGJncCBhcy1wYXRoIGF0dHJiDQqWCVdhcnJlbjogd2FzIG5vdCB0aGlua2luZyBv ZiB1c2luZyBhcy1wYXRoIGF0dHJiLCBhIGJyYW5kIG5ldyBhdHRyYi4NCpUJSm9objogQXVnbWVu dCBjdXJyZW50IGJncHNlYyBzaWcgYXR0cmIgd2l0aCBhIGZsYWcgZmllbGQgdGhhdCBzYXlzIJNj b25mZWSULg0KlQlSb2I6IGxpa2VzIGhhdmluZyBhIHNlcGFyYXRlIGF0dHJiLCBzbyBwZW9wbGUg d2hvIHdhbnQgdGhpcyBwYXkgdGhlIHBhaW4sIG5vdCB0aGUgDQp3aG9sZSB3b3JsZC4gIEpvaG46 IGJ1dCBiZ3AgYXR0cmIgc3BhY2UgaXMgbGltaXRlZCwgd291bGQgcmF0aGVyIG5vdCB1c2UgYW5v dGhlciANCmJpdCBmb3IgdGhpcy4gIFNtYWxsIHBvaW50LCBidXQuDQqVCVNpcnJhbTogd2hhdCBk aXN0aW5ndWlzaGVzIGNvbmZlZHMgaW4gY3VycmVudCBiZ3A/ICBKb2huOiB0eXBlIGNvZGUuICBX ZSBkb26SdCANCmhhdmUgdGhhdCBpbiBiZ3BzZWMgcHJvdG9jb2wuICBNYXliZSB3ZSBjYW4gYWRk IHRoYXQuICAocmFuZHk6IHdoeSBoYXZlIGV4dHJhIA0KY29tcGxleGl0eSCWIHBlb3BsZSB3aWxs IHRoaW5rIHVwIHdheXMgdG8gdXNlIGl0IJYgY2FuJ3QgcHJlZGljdCBmdXR1cmUpDQqVCUpvaG6S cyBzdW1tYXRpb24NCpYJMSAgcmV3aW5kIChzdGFydCBmcm9tIG9yaWdpbiB0byBmaXJzdCBzaWdu aW5nIG1lbnRpb25pbmcgcHVibGljIGFzIJYgcmVsaWVzIA0Kb24gZXh0ZXJuYWwgc2Vzc2lvbiBn b2luZyB0byBwdWJsaWMgQVMpDQqWCTIgRmxhZyBpbiBzaWcgYXR0cg0KlgkzIENoaWxkLW9mLUFT LXBhdGggKHNvbWUgb3RoZXIgYXR0cmlidXRlIHRoYXQgY2FycmllcyCTY29uZmVklCANCmNoYXJh Y3RlcmlzdGljDQqVCVdhcnJlbjogY2FuIHdlIGp1c3QgdXNlIGEgbWFya2VyIGluIHRoZSBzaWcg YXR0cmI/DQqWCVRydXN0IG1vZGVsOiBza2kgbGVuZ3RoIDAgLCBzaWcgbGVuZ3RoIDAsIC0tLSBt YXJrZXIgliBkb26SdCBuZWVkIHRvIHNpZ24gDQpvdmVyIGl0Lg0KlglSb2I6IHJlcHVycG9zZSB3 aG9sZSBiZ3BzZWMgc2lnIGF0dHJiIHRvIGNhcnJ5IHRoaXMgSm9objogdGhhdJJzIHdoYXQgd2Ug DQpiaXQgaW50byB3aGVuIHdlIGdvdCByaWQgb2YgYXMtcGF0aA0KlQlKb2huIGFkZHMNCpYJNCBl eHBsaWNpdCCTZW50ZXJlZCBjb25mZWSUIG1hcmtlcg0KlQlNZTogaXMgdGhpcyBhIHByb2JsZW0g d2l0aCBzb21lb25lIGVudGVyaW5nIHRoZSBtYXJrZXIgd2hvIHNob3VsZCBub3QgZG8gc28/DQqW CUE6IGVudHJ5IHBvaW50IGludG8gY29uZmVkIGtub3dzIHRoYXQgaXQgaXMgaW4gYSBjb25mZWQg YW5kIGtub3dzIGl0IGlzIHRoZSANCmVudHJ5IHBvaW50DQqWCUFuZCBjYW4gYmUgcmVxdWlyZWQg dG8gY2hlY2sgaW5jb21pbmcgZGF0YSBmb3IgZW50ZXJlZCBjb25mZWQgbWFya2VyIJYgDQphbmQg dGhyb3cgZXJyb3INCpUJSm9objogbGlrZXMgbWFya2VyLCBvbmx5IHRoaW5nIGJldHRlciBhYm91 dCBmbGFnIGlzIGl0IGZpdHMgZXhpc3Rpbmcgc3RydWN0dXJlDQqVCVdhcnJlbjogZG9lc24ndCBs aWtlIGZsYWcgYmVjYXVzZSBpdCBnaXZlcyA3IGV4dHJhIGJpdHMgIE1hdHQ6IGFkZGl0aW9uYWwg Yml0cyB3b3VsZCANCmFsbG93IHNvbWUgY29sb3JpbmcNCpUJV2VzOiBhZGRpdGlvbmFsIGJpdHMg aW4gYXR0cmIgliBkb2VzIHRoYXQgZ2V0IHNpZ25lZD8gIEE6IHllcy4NCpUJV2FycmVuOiB0aGF0 IG1lYW5zIGFsbCByb3V0ZXJzIGhhdmUgdG8gc2lnbiBvbiBlbnRyeSBhbmQgZXhpdCBmcm9tIGNv bmZlZHMgliANCmluY3JlbWVudGFsIGRlcGxveW1lbnQgaXNzdWUNCpUJUmFuZHk6IGxlYXJuaW5n IGFueXRoaW5nIG1vcmU/IEpvaG46IHByb2JhYmx5IG5vdC4gIEdvIG9mZiwgdGhpbmsgYWJvdXQg aXQsIA0KZGlzY3VzcyBvbiBlbWFpbD8NCihub3RlcyBzbGlkZSAxNCkNCkFkZC1QYXRocw0KlQlJ c3N1ZTogb25seSBzaWduIHlvdXIgYmVzdCBwYXRoDQqWCUJ1dCB0aGF0IGJyZWFrcyBhZGQtcGF0 aA0KlglTcmlyYW0gaGFkIHRleHQgYW5kIHdpbGwgc2VuZCBpdCB0byB0aGUgc2lkciBsaXN0Lg0K KG5vdGVzIHNsaWRlMTUpDQpBUyBhbGlhc2luZyBSZXBsYWNlIEFTIExvY2FsIEFTDQqVCVdlczog Y2hhbm5lbGluZyBTaGFuZSCWIHdoYXQgYWJvdXQgQVMgbWVyZ2luZz8NCpUJQW5kIHBhdGggcG9p c29uaW5nDQqVCUpvaG46IGluIG15IGltcGxlbWVudGF0aW9uDQqWCVRoZXJlknMgc29tZXRoaW5n IHRoYXQgbGV0cyBtZSBiZSBhbnkgb25lIG9mIGEgc2V0IG9mIEFTcyB3aGVuIEkgdGFsayB0byAN CmFuIGV4dGVybmFsIHBlZXINCpYJU3RyaXAgcHJpdmF0ZSBBU3MgliBvayBpZiB0aGV5IGFyZSBh bGwgb24gdGhlIHJpZ2h0IHNpZGUgb2YgdGhlIHBhdGgNCpUJV2FycmVuOiBEb26SdCB5b3UgaGF2 ZSB0byByZXdpbmQgdW50aWwgeW91IGZpbmQgdGhlIGZpcnN0IHRoYXQgaXMgDQpub3QgcHJpdmF0 ZSBhbmQgIG5vdCBpbiB5b3VyIG1lbWJlciBsaXN0DQqVCVdvdWxkIHRoYXQgbm90IHdvcmsgZm9y IGNvbmZlZHM/DQqWCVJlcGxhY2UgYXJiaXRyYXJ5IEFTIGluIHRoZSBtaWRkbGUgb2YgdGhlIHBh dGggliB0aGF0knMgbmV2ZXIgZ29pbmcgdG8gDQp3b3JrLCBnaXZlIGl0IHVwDQoobm90ZXMgc2xp ZGUgMTYpDQpSZXBsYWNlIGFzIJYgQVMgbWlncmF0aW9uDQqVCUFTIDEgaXMgY29ubmVjdGVkIHRv IDIgYW5kIDMuICBidXQgMyB0aGlua3MgMSBpcyA1DQogICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgMiAgLS0tLS0gICAgIDEgICAgIC0tLS0tICAzDQqWCU9uZSB3YXkgaXMgdXNlIHBj b3VudD0wLg0KlglUaGlzIGV4cG9zZXMgdGhlIGZhY3QgdGhhdCAxIGV4aXN0cyB0byAzDQqWCVJh bmR5OiB3aGF0IGRvZXMgMyBzZWUgZnJvbSAxPyAgSmFzb246IEl0IG1pZ2h0IHNlZSA1IDEgMiBv ciA1IDIsIGRlcGVuZHMgDQpvbiB0aGUgY29uZmlnLiAgRnJvbSAzIHRvIDIsIDIgc2VlcyAzIDEg b3IgMyA1IDEuDQqWCUdvaW5nIHRvIGhhdmUgdG8gYmUga25vYi4NCpUJRG9jdW1lbnRlZD8gIChr ZWVwcyBjb21pbmcgdXAsIHNvIHNob3VsZCBiZSBkb2N1bWVudGVkKSAgKE1hdHQ6IGRvZXNuknQg dGhpbmsgDQppdCBiZWxvbmdzIGluIGNvcmUgc3BlYywgR2VvZmYgYWdyZWVzIG9uIGphYmJlciwg UmFuZHkgYWdyZWVzIHRvIGdvIGludG8gYmdwc2VjIA0Kb3BzKQ0KlQlSZW1vdmUgcHJpdmF0ZSBo YWNrOiB3aGF0IGFib3V0IGZvcndhcmQgc2lnbmluZyBwcm9ibGVtIGlmIGV4dGVybmFsIHBlZXIg c2lnbnMgDQp0byBwcml2YXRlDQqWCVdlczogY2FuIHlvdSB0cmFuc2l0IGEgcHJpdmF0ZSBBUz8N CpYJUmFuZHk6IGtleXMgdXNlZCB0byBzaWduIGZvciByb3V0ZXIgd2l0aCBwcml2YXRlIEFTIGRl Y2VuZCBmcm9tIGEgdHJ1c3QgDQphbmNob3IgdGhhdCBhbnlvbmUgd2FudGluZyB0byB2YWxpZGF0 ZSB0aGUgc2lnbmF0dXJlcyBtdXN0IGhhdmUgdGhhdCBzYW1lIA0KcHJpdmF0ZSB0cnVzdCBhbmNo b3IgKG9wZXJhdGlvbmFsbHkgcXVpdGUgbWVzc3kpDQqWCUdlb2ZmIG9uIGphYmJlcjogdGhhdCB3 b3VsZCBtZWFuIHRoYXQgaWYgYSBwcml2YXRlIEFTIHRoZSByZXN0IG9mIHRoZSANCkludGVybmV0 IG11c3QgaGF2ZSB0aGF0IHByaXZhdGUgdHJ1c3QgYW5jaG9yDQqWCVJhbmR5OiBjYW6SdCB0cmFu c2l0IGEgcHJpdmF0ZSBBUyBpbiBiZ3BzZWMNCpYJV2VzOiBidXQgd2hhdCBhYm91dCBleHRlcm5h bCBwZXJzb24gcGVlcmluZyB3aXRoIHRoZSBwcml2YXRlIEFTPw0KlQlKb2huOiBidXQgd2UgaGF2 ZSA0IGJ5dGUgQVMgliB3aHkgZG8gd2UgbmVlZCBwcml2YXRlIEFTcw0KlQlSdWVkaWdlcjogcHJp dmF0ZSBBUyBhcyBzdHViIGlzIE9LIJYgcmVtb3ZlIHByaXZhdGUgQVMgYW5kIG9yaWdpbmF0ZSBh dCANCnVwc3RyZWFtIHdoZXJlIHByaXZhdGUgQVMgaXMgc3RyaXBwZWQuDQqVCVdlczogaXMgaXQg b2sgdG8gbWFrZSBpdCBpbXBvc3NpYmxlIHRvIHRyYW5zaXQgYSBwcml2YXRlIEFTIJYgYmVjYXVz ZSB5b3UgcnVuIGludG8gDQphbGwgdGhlc2UgcHJvYmxlbXMuDQqVCUJyaWFuOiB1c2UgcHVibGlj IElQIGFkZHJlc3MgZm9yIHRoZSByb3V0ZXI/ICAoYnV0IGhvdyB0byBlc3RhYmxpc2ggcmVsYXRp b25zaGlwIA0KYmV0d2VlbiByb3V0ZXIgSVAgYWRkciBhbmQgQVMgbnVtYmVyKQ0KKG5vdGVzIHNs aWRlIDE3KQ0KVGhlcmUgTWlnaHQgQmUgNTAgV2F5cyB0byBMZWF2ZSBZb3VyIExvdmVyIGJ1dCAx NTAgV2F5cyB0byBNZXNzIFlvdXJzZWxmIFVwIGluIA0KQkdQDQqVCVJ1ZWRpZ2VyOiBkb26SdCBh ZGQgY29tcGxleGl0eSBmb3IgdGhvc2UgNTAwMCBBUyBudW1iZXJzLiAgRG8gbm90IHByb3BhZ2F0 ZSANCnByaXZhdGUgQVNzIGludG8gdGhlIHB1YmxpYyBpbnRlcm5ldC4NCpUJUnVlZGlnZXI6IHNv bWUgY3VzdG9tZXIgaXMgc2VuZGluZyAyMDAgLzMycyB3aXRoIHByaXZhdGUgQVNzLg0KlQlHZW9m ZjogSSBzZWUgYWJvdXQgMTAgb2YgdGhlbS4NCpUJUm9iOiBidXQgdGhlc2UgYXJlIHN1cHBvc2Vk IHRvIGJlIHVzZWQgaW4gdHJ1c3QgYm91bmRhcmllcyBhbmQgc3RyaXBwZWQgb3V0c2lkZSCWIA0K dHJhbnNpdGluZyBpcyBkaWZmZXJlbnQgYW5kIGhhcmQgdG8gZGVmaW5lIHRydXN0IG1vZGVsLg0K lQlXZXM6IGlmIHlvdSBoYXZlIGEgcmVhc29uIHlvdSBuZWVkIHRvIHRyYW5zaXQgdGhlIEFTIHRo YXQgaXMgdXNpbmcgYSBwcml2YXRlIEFTLCANCnVzZSBhIHB1YmxpYyBBUyAobWF5YmUgb25lIHRo YXQgaXMgc2hhcmVkIGZvciB0aGlzIHB1cnBvc2UpLg0KlQlDaHJpczogbmVlZCB0byBhZGRyZXNz IHRoaXMgaWYgdGhlcmUgaXMgYSB1c2UgY2FzZSB3aGVyZSBpdCB3b3Vsb2QgYmUgdmVyeSBwYWlu ZnVsIHRvIA0KdXNlIGFueSBvdGhlciBtZWNoYW5pc20uDQqVCUJyaWFuOiBwZW9wbGUgYXJlIHVz aW5nIEJHUCBidXQgdGhlaXIgZW5naW5lZXJpbmcgd2FzIGRvbmUgYnkgY29uc3VsdGFudHMgd2hv IA0KaGF2ZSBiZWVuIGdvbmUgliBhbmQgd2FudCB0byBhZGQgYmdwc2VjLg0KlQlTbyB1bnRpbCB3 ZSBmaW5kIHRoZSBwYWluZnVsIGNhbpJ0LWRvLXRoaXMtYW55LW90aGVyLXdheSBjYXNlLCB3ZSB3 aWxsIG1vdmUgb24uDQqVCUphc29uOiB3aGVuIHBlb3BsZSBhcmUgdXNpbmcgcHJpdmF0ZSBBUywg ZG8gdGhleSBzaWduPyBBbHdheXM/IE5ldmVyPyANClNvbWV0aW1lcz8gIA0KlQlCcmFkIE5UVDog c29tZSBjdXN0b21lciB3aG8gc2hhcmUgYSBwdWJsaWMgQVMgbnVtYmVyLiAgW1JGQzIyNzAgc29y dCBvZiANCkFTTl0gIJYgKDcwMSB1c2VzIG9uZSBvZiB0aGVzZSB0aGluZ3MgYXMgYSBzaGFyZWQg Y3V0b21lciBBUyBudW1iZXIpIJYgNzAxIA0KY291bGQgc2lnbiB0aGUgcHJlZml4IGFzIFtSRkMy MjcwIEFTTl0gYW5kIDcwMS4gIFRoZSBbUkZDMjI3MCBBU05dIGNvdWxkIGJlIA0Kc3RyaXBwZWQg KFdlczogZm9yIFNwcmludCB0aGlzIGRvZXMgZ2V0IHN0cmlwcGVkLikgIElmIHRoZSBJUCBhZGRy IGJlbG9uZ3MgdG8gdGhlIA0KY3VzdG9tZXIsIHRoZSBbUkZDMjI3MCBBU05dIGlzIG5vdCBzdHJp cHBlZC4gIEFsbG93cyBvbmUgY3VzdG9tZXIgdG8gc2lnbiBhbiANCmFubm91bmNlbWVudCBvcmln aW5hdGluZyBhbm90aGVyIFtSRkMyMjcwIEFTXSBjdXN0b21lcpJzIHNwYWNlIChiZWNhdXNlIGVh Y2ggDQpjdXN0b21lciB3b3VsZCBhbGxvdyBbUkZDIDIyNzAgQVNdIHRvIG9yaWdpbmF0ZSB0aGVp ciBJUCBwcmVmaXgpDQqVCURpc2N1c3Npb24gb2YgRE5TIGFuYWxvZ3kgdGhhdCBJIG1pc3NlZCBh Ym91dCBwcmltYXJpZXMgYW5kIHNlY29uZGFyaWVzIGFuZCANCm11ZGR5aW5nIHRoZSB3YXRlcnMu DQqVCVdoZW4gdGhlcmWScyBhIHJvdXRpbmcgaXNzdWUgYmVjYXVzZSBhIC8yNCBpcyBmbGFwcGlu ZywgeW91IHdhbnQgaXQgdG8gYmUgb2J2aW91cyANCnlvdXIgY3VzdG9tZXKScyBmYXVsdCBub3Qg eW91cnMgYW5kIHRoYXQgaXMgd2h5IHlvdSBkbyBub3Qgc3RyaXAgdGhlaXIgdXNlIG9mIA0KUkZD MjI3MCBBUw0KlQlCcmlhbjogaWYgdGhlIFtSRkMyMjcwIEFTXSBpcyBkb2luZyB0aGUgc2lnbmlu ZyBvbiBhIHJvdXRlciB0aGF0IGlzIG5vdCB1bmRlciB0aGUgDQpjdXN0b21lciBjb250cm9sDQqV CUNhbpJ0IHRlbGwgdGhlIEFTIGp1c3QgZ28gZ2V0IHlvdXIgb3duIHB1YmxpYyBBUywgYmVjYXVz ZSB0aGV5IGFyZSBub3QgbXVsdGktDQpob21lZCBhbmQgZG8gbm90IHF1YWxpZnkgdW5kZXIgUklS IHBvbGljeS4NCpYJSnVzdCBmaXggdGhlIFJJUiBwb2xpY3kNCihub3RlcyBzbGlkZSAxOCkNClBh dGggUG9pc29uaW5nDQqVCUp1c3QgY2FuIG5vdCB3b3JrDQqVCURlYWwhDQoobm90ZXMgc2xpZGUg MTkpDQpJbnRyYS1hcyBkZXBsb3ltZW50DQqVCUFyZSB3ZSBkb25lPw0KlQlDaHJpczogd2UgaGF2 ZSBhIHBhdGggZm9yd2FyZA0KlgkgYnJpYW4gdm9sdW50ZWVyZWQgdG8gd3JpdGUgYSBzaW1wbGUg UlIgY2FzZQ0KlglBbmQgdGhlbiB0aGluZ3Mgd2lsbCBnbyBmb3J3YXJkDQqVCVJhbmR5OiBkbyB3 ZSB1bmRlcnN0YW5kIHRoZSB0ZWNobm9sb2d5IGFuZCBhcmUgY29tZm9ydGFibGUgd2l0aCBpdC4N CpYJU2ltcGxlIGV4YW1wbGUgc2VlbXMgdG8gd29yay4NCpUJQnJpYW4gYnV0IHdoYXQgYWJvdXQg Y2FzZSB3aGVyZSBBUyB3YW50cyB0byBzaWduIHRoZSBvcmlnaW4gDQpSYW5keTogd2hlbiBpbmpl Y3Rpb24gb2NjdXJzIGZyb20gYW5vdGhlciBwcm90b2NvbCBpbnRvIG15IGJncCwgDQp0aGVyZSBp cyBubyBBUy1QQVRILiAgSW5zaWRlIG15IEFTLCBJIGtub3cgaXQgaXMgbWluZSwgc28gSSBrbm93 IA0Kd2hhdCB0aGUgQVMgbnVtYmVyIGlzLCBzbyBJIGNhbiBhZGQgdGhhdCBmaXJzdCBzaWduYXR1 cmUuDQoobm90ZXMgc2xpZGUgMjApDQpEaXNjdXNzaW9uIG9mIFNpZ25pbmcgb3ZlciBJQkdQIFNl c3Npb25zDQqVCUpvaG46IHdoYXQgaXMgdXNlIGNhc2UgZm9yIHNpZ25pbmcgb3ZlciBpYmdwIHNl c3Npb24/ICBEb26SdCB0cnVzdCByb3V0ZXI/ICANCpUJQnJpYW46IHlvdSBhcmUgbGVhc2luZyBy b3V0ZXJzLCBsZWFzaW5nIGJhbmR3aWR0aCwgcGVvcGxlIGNhbiBwdXQgdGhlbXNlbHZlcyBpbiAN Ck1JVE0gcG9zaXRpb24uICBTb21lIHBlb3BsZSBtYXkgd2FudCB0byB1c2UgYmdwc2VjIG9uIGli Z3Agc2Vzc2lvbnMgcmF0aGVyIA0KdGhhbiB0cmFuc3BvcnQgb24gdGhlaXIgc2Vzc2lvbnMuICAN CpUJV2FycmVuOiBob3cgbWFueSBwZW9wbGUgYXJlIHVzaW5nIHRyYW5zcG9ydCBzZWN1cml0eSBv biB0aGVpciBpYmdwIHNlc3Npb25zPyAgQTogDQptb3N0IG9mIHRoZSBiaWcgZ3V5cyB3aWxsIGRv IHRoYXQhISEgIA0KlQlSb2I6IGhhcmQgdG8gc2F5IHRoZXJlIG1heSBiZSBhIG5lZWQgZm9yIHRo aXMgc29tZWRheSBzbyBsZXRzIGFkZCB0aGlzIGNvbXBsZXhpdHkgDQpub3cuICANCpUJR2VvZmY6 IGhhcmQgdG8gYWRkcmVzcyB1bmxlc3Mgd2UgdW5kZXJzdGFuZCB0aHJlYXQgbW9kZWwuICANCpUJ QnJpYW46IHdhcyByYWlzZWQgb24gbGlzdCBhcyBjb21tZW50IG9uIHRocmVhdCBtb2RlbCBkb2N1 bWVudCBhbmQgk3Nob3V0ZWQgDQpkb3duIGJ5IGNoYWlyc5QuICANCpUJUnVlZGlnZXI6IGRvIHlv dSB3YW50IHRoZSB0aG91c2FuZHMgb2YgaWJncCByb3V0ZXMgSSBjYXJyeSBpbnRlcm5hbGx5IGlu IG15IA0KbmV0d29yayB0byBoYXZlIHRoaXMgcHJvdGVjdGlvbj8gIA0KlQlSdWVkaWdlcjogQnJp YW4sIHdoYXQgeW91IGFyZSBpbnRlcmVzdGVkIGluIGlzIHByb3RlY3RpbmcgdGhlIG90aGVyIGF0 dHJicyBpbiB0aGUgDQp1cGRhdGUsIG5vdCB0aGUgZW1wdHkgYXMtcGF0aC4gIA0KlQlKb2huOiBz aW5jZSBJIGRvbpJ0IHVuZGVyc3RhbmQgdGhlIHVzZSBjYXNlOiAoYSkgdHJhbnNwb3J0IHNlY3Vy aXR5IHdpbGwgbm90IHNvbHZlIA0KcHJvYmxlbT8gb3IgKGIpIEkgZG9uknQgd2FudCB0byB1c2Ug dHJhbnNwb3J0IHNlY3VyaXR5PyAgDQqVCUJyaWFuOiBJIGRvbpJ0IHdhbnQgdG8gdXNlIHRyYW5z cG9ydCBzZWN1cml0eS4gIERvbpJ0IHdhbnQgdG8gaGF2ZSB0byBkZXBsb3kgDQp0cmFuc3BvcnQg IC0gdHdvIHNlY3VyaXR5IHNvbHV0aW9ucyBhdCB0aGUgc2FtZSB0aW1lLiAgDQqVCVNhbmR5OiBi dXQgdHJhbnNwb3J0IHNlY3VyaXR5IHByb3RlY3RzIGFnYWluc3Qgb3RoZXIgdnVsbmVyYWJpbGl0 aWVzIHRoYXQgYmdwc2VjIG9mIA0KaWJncCB1cGRhdGVzIHdvdWxkIGxlYXZlIHVucHJvdGVjdGVk LiAgDQqVCUJyaWFuOiB1bmRlcnN0YW5kIHRoYXQsIHByZXNlbnRpbmcgdGhpcyBhcyBhIGluY3Jl bWVudGFsIHdheSB0byBnZXQgYmdwc2VjIA0KZGVwbG95ZWQuICANCpUJUm9iOiB0aGlua3Mgc2Vj dXJpdHkgQURzIHdvdWxkIG9iamVjdCB0byBhIHNvbHV0aW9uIHRoYXQgd291bGQgbGVhdmUgc3Vj aCBhbiANCm9idmlvdXMgdnVsbmVyYWJpbGl0eSB1bmNvdmVyZWQuICANCpUJUnVlZGlnZXI6IGRv ZXMgeW91ciBwcm9wb3NhbCBhcHBseSBvbmx5IHRvIG9yaWdpbmF0ZWQgcm91dGVzPyAgQXJlIG90 aGVyIGF0dHJicyANCnRoYXQgYXJlIG5vdCB1c2VkIGV4dGVybmFsbHkgKGlmIHlvdSBkb26SdCB5 b3VyIG93biBuZXR3b3JrKSBhbHNvIHRvIGJlIHNpZ25lZC4gIA0KSW50ZXJlc3RlZCB3aGVuIG1p dG0gY2FuIGluamVjdCByb3V0ZXMuICBUaGluayBpZiB5b3UgY2FuknQgdHJ1c3QgeW91ciBvd24g aW50ZXJuYWwgDQpuZXR3b3JrLCBzb21lb25lIGNhbiBpbmplY3Qgc29tZXRoaW5nIGJhZA0KKG5v dGVzIHNsaWRlIDIxKQ0KUHJlcGVuZGluZyBJc3N1ZXMNCpUJPGFub255bW91cz4gcmVwb3J0cyBm cm9tIG1lc3NhZ2UgZnJvbSBKZWZmIEhhYXMuICBJbiBiZ3AgdG9kYXksIHVwc3RyZWFtcyBjYW4g DQphZGQgcHJlcGVuZHMgb2YgbXkgQVMgbnVtYmVyICh3aXRoIG9yIHdpdGhvdXQgbXkgcGVybWlz c2lvbikgYW5kIHRob3NlIA0KcHJlcGVuZHMgc3RheSB3aGVuIHVwc3RyZWFtIHByb3BhZ3RlcyB0 aGUgdXBkYXRlLg0KlglKb2huOiBzb21lIGltcGxlbWVudGF0aW9ucyBkbyBsb29wIGRldGVjdGlv biBvbiBpYmdwIGFzIHdlbGwgYXMgZWJncCwgDQp3aGljaCBtZWFucyBwcmVwZW5kZWQgbG9va3Mg bGlrZSBhIGxvb3AuDQqVCTxhbm9ueW1vdXM+IHByZXBlbmQgYSBwcml2YXRlIEFTIHRoZSBuZWVk ZWQgbnVtYmVyIG9mIHRpbWVzIGFuZCB0cmFuc2xhdGUgdG8gDQpteSBwdWJsaWMgQVMgbnVtYmVy IA0KlQkoQnJpYW4gcmVwb3J0cyBhIHNvbHV0aW9uIHRvIGhpcyBvd24gY29uY2VybiBhYm91dCB1 bnRydXN0d29ydGh5IGludGVybmFsIA0KbmV0d29ya3M6IHVzZSBwcml2YXRlIEFTIGludGVybmFs bHkgdG8gc2lnbiB3aXRoLCB0aGVuIHN0cmlwIG9uIGV4aXQpDQoobm90ZXMgc2xpZGUgMjIpDQpQ cm90ZWN0aW5nIE90aGVyIEF0dHJpYnV0ZXMNCpUJQnJpYW46IFJ1ZWRpZ2VyIGJyb3VnaHQgdXAg YSBwb2ludCCWIGlzIHRoZXJlIGFueSB3YXkgdG8gcHJvdGVjdCBhbnkgYXR0cmlidXRlIHRoYW4g DQpBU19QQVRIDQqWCVJhbmR5OiB1bnN1cmUgb2YgdHJ1c3QgbW9kZWwgb2Ygb3RoZXIgYXR0cmIN CpYJUmFuZHk6IHR3byBwb3NzaWJpbGl0aWVzIHByZXNlbnRseSANCpUJQnVzaW5lc3MgcmVsYXRp b25zaGlwIChyb3V0ZSBsZWFrcykNCpUJU2lnbmF0dXJlIGV4cGlyYXRpb24gdGltZQ0KlQlHZW9m ZiBvbiBqYWJiZXI6IEJyaWFuIG5lZWRzIHRvIGdvIGJhY2sgdG8gU3RldmVLZW50knMgYW5hbHlz aXMgb2Ygd2hhdCBuZWVkcyB0byANCmJlIHNpZ25lZC4NCihub3RlcyBzbGlkZSAyMykNCkZyZXNo bmVzcw0KlQlTdGV2ZUJlbGxvdmluOiBzdGlsbCBjb25jZXJuZWQgdGhhdCB3ZSBkb26SdCBoYXZl IGEgd2F5IGluIGEgc2hvcnQgdGltZSBmcmFtZSB0byANCnJvbGwgYSByb3V0ZXIgc2lnbmluZyBr ZXkuDQqWCVJhbmR5OiBjb25jZXJuIGlzIHNlY3VyaXR5IGNvbXByb21pc2U/ICBZZXMNCpYJQmVh Y29uaW5nIGRvZXMgbm90IHNlZW0gdG8gd29yaw0KlQlPbmUgc3VnZ2VzdGlvbiAoU3RldmUgS2Vu dJJzID8/KSBmbG9vZCBhIJNyZWZyZXNoIHlvdXIgcnBraZQgaW4gYmdwLiBSYW5keTogDQppbmJh bmQ/ICBUaGUgb25lIHRoYXQgd2FudHMgdG8gZG8gdGhpcyBpcyBjb21wcm9taXNlZCByb3V0ZXIg U3RldmVCL0pvaG46IG9yIHRoZSANCkFTL05PQw0KlglCZWFjb25pbmcgaGFzIHByb2JsZW0gdGhh dCB0aGVyZSBpcyBpbmNlbnRpdmUgdG8gYmVhY29uIHRvbyBvZnRlbiwgdGhpcyANCmRvZXMgbm90 DQqVCUE6IGRvZXMgdGhpcyBhY2NvbXBsaXNoIHRoaXMgIEI6IGRvZXMgaXQgd29yaw0KlQlSb2I6 IGhvdyBkbyB5b3UgYXV0aGVudGljYXRlIHRoaXM/ICBBOiB3aGF0IHlvdSB3YW50IHRvIGRvIGlz IHJhdGUgbGltaXQgdGhpcy4gIFE6IA0KaG93IHRvIHNpZ24gIEE6IEFTIG51bWJlci1pc2gNCpUJ PEdlb2ZmIEh1c3Rvbj4gYSBicm9hZGNhc3QgbWVzc2FnZSB0byBldmVyeW9uZSBlbHNlIHRoYXQg c2F5cyAiZ2VuZXJhdGUgcmVmcmVzaCANCnF1ZXJpZXMgdG8gdGhlIHJlcG9zaXRvcmllcyIgaXMg YSBncmVhdCBET1MgYXR0YWNrDQqVCVdhcnJlbjogc29tZW9uZSBvd25zIG15IHJvdXRlciBhbmQg aXNzdWVzIGVub3VnaCBvZiB0aGVzZSB0byBtYWtlIHJhdGUgbGltaXRlciANCnRocm93IGFsYXJt IGFuZCByb3V0ZXKScyBrZXkgZ2V0cyByb2xsZWQuICAoaWYgbm9jIGdldHMgY29tcHJvbWlzZWQs IGdhbWUgb3ZlcikgIA0KV2VzOiBvciBlbXBsb3llZSBsZWF2ZXMuICBUaGVyZSBhcmUgbWV0aG9k cyB0byBtYW5hZ2UgdGhpcy4NCpUJQnJpYW46IGlmIHlvdSBjb3VsZCBmbG9vZCBpbmZvIGFuZCBp ZGVudGlmeSBhbHRlcm5hdGUgcGF0aHMsIGNvdWxkIHNpZ25hbCB3aXRoIHJvdXRlIA0KbGVhayBt YXRlcmlhbCB0byBlbnN1cmUgcGVvcGxlIHdobyBuZWVkIHRoZSBuZXcgaW5mbyBnZXQgaXQuICBD aHJpczogbm90IHRhbGtpbmcgDQphYm91dCBCR1AgZGF0YSwgdGFsa2luZyBhYm91dCBSUEtJIGRh dGEgbGlrZSBDUkxzLiAgQnJpYW46IHVzaW5nIEJHUCB0byBzaWduYWwNCihub3RlcyBzbGlkZSAy NCkNCkZyZXNobmVzcyAoQ29udCdkKQ0KlQlCYWNrIHRvIGZyZXNobmVzcyBhbmQgc3RvbGVuIGtl eXOFDQqVCUNocmlzOiBwcm9ibGVtIGlzIHRoYXQgd2UgaGF2ZSBhbGwgZGF0YSBpbiBzYW1lIHBs YWNlIGFuZCBzbyBzYW1lIGZldGNoIHByb2Nlc3MgDQphcHBsaWVzIChwb2xsIGZyb20gcmVwb3Np dG9yeSkNCpYJQ2FuIHdlIGhhdmUgYSBzZXBhcmF0ZSBjb21tdW5pY2F0aW9uIG1lY2hhbmlzbSBm b3Igc29tZSBvYmplY3RzPw0KlglSb2I6IHRoZXJlIGlzIGEgcHJvdG9jb2wgZm9yIHJldHJpZXZp bmcgQ1JMcyBpbiByZWFsIHRpbWUsIGJ1dCB3ZSBhcmUgdHJ5aW5nIA0KdG8gYXZvaWQgaXQhDQqW CUNocmlzOiBEYW5ueSBhc2tzIHdoeSB0d2l0dGVyIGNhbiBjb21tdW5pY2F0ZSBpbiBuZWFyIHJl YWwgdGltZQ0KlQlCcmlhbjogaWYgMTMgcm91dGVycyBhcmUgY29tcHJvbWlzZWSFICB3YXJyZW46 IGlmIHNvbWVvbmUgb3ducyAxMyByb3V0ZXJzIHRoZXkgDQpjb3VsZCBqdXN0IHR1cm4gdGhlbSBv ZmYuDQqVCXN0ZXZlQiBoYXMgbGVmdCBidXQgaGUgc2FpZCBoZSB3b3VsZCBiZSBoYXBwaWVyIGlm IHRoZXJlIHdhcyBhIHdheSB0byBnZXQgdGhlIGtleSANCmNoYW5nZSBkaXN0cmlidXRlZCBmYXN0 ZXIuICBSb2I6IG1lIHRvbywgSSBqdXN0IGRvbpJ0IGtub3cgaG93IHRvIGRvIGl0IGNoZWFwbHku DQqVCUNocmlzOiBhIHdheSBmb3IgcmVwb3NpdG9yeSB0byBzYXkgk29rLCBvaywgb2ssIG5ldyBp bmZvlA0KlQlSb2I6IHBvbGwgb3IgZmxvb2QsIHRha2UgeW91ciBwaWNrDQqVCUNocmlzOiBqdXN0 IHRyeWluZyB0byBzYXkgdGhhdCB0aGVyZSBhcmUgZGlmZmVyZW50IGNsYXNzZXMgb2YgZGF0YSBh bmQgc29tZSBoYXZlIA0KZGlmZmVyZW50IGZyZXNobmVzcyBjb25jZXJucy4gIFJvYjogYnV0IGp1 c3QgdGFsa2luZyBhYm91dCBkaWZmZXJlbnQgcHJvdG9jb2xzLiAgDQpXb3VsZCBsaWtlIHRvIHRh bGsgdG8gdGhpcyB3aXRoIFRpbSBhbmQgU3RldmVCIGluIHRoZSByb29tLiAgICBDaHJpczogYmVz aWRlcyANCmRpZmZlcmVudCBwcm90b2NvbHMgY2FuIHdlIGNvbmNlcm4gb3Vyc2VsdmVzIHdpdGgg ZGlmZmVyZW50IHJlcXVpcmVtZW50cyBmb3IgDQpkaWZmZXJlbnQgb2JqZWN0cz8gIE5lZWQgREFU QS4gIFRpbSBtaWdodCBiZSBpbnRlcmVzdGVkIGluIHNvbWUgbG9uZyB0ZXJtIA0KbWVhc3VyZW1l bnRzLiAgUm9iOiBSYW5keSBzYXlzIHdlIGRvbpJ0IGhhdmUgYSBsb25nIHRlcm0gYmFzZWxpbmUg Zm9yIGhvdyB0aGlzIA0Kd291bGQgd29yayBpbiB0aGUgZnV0dXJlIJYgd2UgZG9uknQga25vdyB3 aGF0IHRoZSBleHBlY3RlZCBiZWhhdmlvciB3b3VsZCBiZS4gIA0KU2hvdWxkIGJlLg0KlQlSZXBv cnRzIHRoYXQgcnN5bmMgaGFzIHNvbWUgZmVhdHVyZXMgdGhhdCBkb26SdCB3b3JrIHdlbGwgaW4g dmFsaWRhdG9ycy4gIFJvYjogbGlrZSANCm1heWJlIGFuIGF0b21pYyBwdWJsaWNhdGlvbiBvZiBh IGJ1bmNoIG9mIGRhdGEuDQqVCUNocmlzOiBmcmVzaG5lc3MgcmVxdWlyZW1lbnQgliBzb21lIHRp bWUgdG8gbGl2ZSCWIGNlcnQgZXhwaXJhdGlvbiB0aW1lIGdldHMgDQpyZWFjaGVkLg0KlQlSb2I6 IEROU1NFQyBoYXMgc2lnbmF0dXJlIGxpZmV0aW1lcyBBTkQgdHRscy4gIFNob3VsZCBub3QgYmUg Y29tYmluZWQuICANClNpZ25hdHVyZXMgYXJlIGVuZC1lbmQsIHR0bHMgYXJlIGNhY2hlIGJlaGF2 aW9yLiAgRGlmZmVyZW50IGFuaW1hbHMuDQoobm90ZXMgc2xpZGUgMjUpDQpSZXBvc2l0b3J5IERp c2N1c3Npb24NCpUJQ2hyaXM6IGlmIEkgYW0gZ2F0aGVyaW5nIGZyb20gdGhlIHdvcmxkIGJ1dCB5 b3Ugd29uknQgZ2l2ZSBtZSB0aGlzIG9uZSBvYmplY3Qgc28gSSANCmtlZXAgdXNpbmcgdGhlIG9i amVjdCBJIGhhdmUgYnV0IHRoZW4gdGhlIHNpZyBleHBpcmVzIGFuZCBPT1BTLiAgQTogeWVwLg0K lQlSb2I6IGZvciBhbnkgcHVibGljYXRpb24gbWVjaGFuaXNtLCB5b3UgaGF2ZSB0byB3b3JyeSBh Ym91dCBob3cgbG9uZyBpdCB0YWtlcyANCmZvciBkYXRhIHRvIGdldCB0aHJvdWdoIHRoZSBzeXN0 ZW0uDQqVCVNhbVdlaWxlcjogYW55IHJlYWwgbmVlZCB0byBoYXZlIGEgcHVzaCBvZiBkYXRhPyAg KEFjdHVhbGx5IGEgbm90aWZ5IJYgZ28gZ2V0IG5ldyANCmluZm8pLiAgSUVURiBoYXMgYW4gb2xk IHByb3RvY29sIDIyNDQgY2FsbGVkIEFDQVAgYW5kIGFzayBmb3Igbm90aWZpZXMgZm9yIA0KYW55 dGhpbmcgdGhhdCB3b3VsZCBtZWV0IHRoYXQgc2VhcmNoIGNyaXRlcmlhLiAgPDxzb21ldGhpbmcg YWJvdXQgaXQgZG9lcyBub3QgDQpzY2FsZT4+ICBCcmlhbjogYnV0IHlvdSBjYW6SdCBibG9jayBh IG5vdGlmeSAgUm9iOiBvaCwgeWVzIHlvdSBjYW4uICBTYW1XZWlsZXI6IA0KYWNhcCBoYXMgYXV0 aGVudGljYXRpb24gcGVyIHVzZXIuDQoobm90ZXMgc2xpZGUgMjYpDQpSZXBvc2l0b3J5IERpc2N1 c3Npb24gKENvbnQnZCkNCpUJQ2hyaXM6IHJxbXRzIGFib3V0IHJlcG9zaXRvcnkgliBob3cgbWFu eSBvYmplY3RzLCBob3cgbWFueSByZXRyaWV2YWxzLCBob3cgDQpvZnRlbiwgZXRjLg0KlglSb2I6 IEdlb3JnZSBNaWNoYWVsc29uIGluIFJJUiBncm91cCBsb29raW5nIGF0IHRoaXMgbG9uZyBhZ28g liAxMEstDQoxMDBLIG9mIG9iamVjdHMgaW4gdGhlIHJwa2kuICBTbyBub3dhZGF5cywgbWF5YmUg MTAwSy0xTS4gIE9yaWdpbmFsbHkgDQpyZXRyaWV2YWxzIG9uY2UgcGVyIGRheSwgbm93IEkgcG9s bCBvbmNlIHBlciBob3VyLCBjb3VsZCBwb2xsIHNldmVyYWwgdGltZXMgDQphIGRheSAoNC02aHJz KSBidXQgMS9kYXkgaXMgYSBiaXQgc2xvdy4NCpYJSWYgeW91IGFyZSBkb2luZyBhIG1ha2UgYmVm b3JlIGJyZWFrLCBldmVyeW9uZSBuZWVkcyB0byBnZXQgdGhlIG1ha2UgDQpiZWZvcmUgeW91IGRv IHRoZSBicmVhaywgc28gYW55IHNsb3dlciB0aGFuIDEvZGF5IG1lYW50IHlvdSBkZXNlcnZlZCB0 byANCmxvc2UuDQqWCVJPQXMgYXJlIG1vc3QgZnJlcXVlbnQgZGF0YSBjaGFuZ2UuICBNYW5pZmVz dHMgY2hhbmdlIHdoZW4gYW55IGRhdGEgDQpjaGFuZ2VzLiAgQ3JscyBjaGFuZ2UgLi48bWlzc2Vk Pg0KlQlDaHJpczogd2UgaGF2ZSAxTSBvYmplY3RzIG5vdywgaW4gZnV0dXJlIGJvdW5kZWQgYnkg KG11bHRpcGxlIG9mIHRoZSkgc2l6ZSBvZiANCnJvdXRpbmcgc3lzdGVtLiBDdXJyZW50bHkgNDA1 Sys4SyByb3V0ZXMgKHY0K3Y2KS4gR2VvZmYgcmVwb3J0cyBoaXMgZXh0cmVtZSANCm91dHNpZGUg dmlldyBpcyB1cHBlciBib3VuZCAyNSUgZ3Jvd3RoIHBlciB5ZWFyLg0KlQlDaHVybiBpcyBsb3cs IG51bWJlciBvZiBvYmplY3RzIGlzIGxhcmdlLg0KlQlHZW9mZjogdjYgQVMgYWR2ZXJ0aXNlcyAy IHJvdXRlcywgdjQgQVMgYWR2ZXJ0aXNlcyA0IHJvdXRlcy4NCpUJV2FycmVuOiBkZWFnZ3JlYWdl cyBteSByb3V0ZXMgaXMgYW4gYWR2YW50YWdlLCBkZWFnZ3JlZ2F0ZXMgbXkgUk9BcyBpcyBub3Qu ICANCkdlb2ZmOiBidXQgeW91IHdhbnQgdG8gaGF2ZSBldmVyeSBhbHRlcm5hdGl2ZSBjb3ZlcmVk LiAgV291bGQgcHJlLXByb3Zpc2lvbiBhbGwgNSANCm5laWdoYm9ycyBldmVuIHRob3VnaCBjdXJy ZW50bHkgYW5ub3VuY2luZyB0byBqdXN0IDIuDQoobm90ZSBzbGlkZSAyNykNCkRpc2N1c3Npb24g b2YgUmVwb3NpdG9yeSBTaXplDQqVCUNocmlzOiBhcmUgdGhlcmUgb3RoZXIgdGhpbmdzIHRoYXQg SSBtaWdodCB3YW50IHRvIGNlcnRpZnkgdGhhdCBJIG1pZ2h0IHdhbnQgdG8gdXNlIA0KdGhlIHJw a2kgc3lzdGVtIGZvcj8NCpYJR2VvZmY6IG1heSB3YW50IG93biBzeXN0ZW0gZm9yIGVhY2gNCpYJ Um9iOiB0aGVyZSBhcmUgcm91dGVyIGtleXMsIGNybHMsIG1hbmlmZXN0cywgZXRjLg0KlglDaHJp czogc2l6ZSBvZiByb3V0aW5nIHN5c3RlbSB0aW1lcyBtdWx0aXBsZSBvZiAyPyBGb3IgcmlnaHQg bm93LiAgVGhhdCANCnNlZW1zIHRvIGdpdmUgbG90cyBvZiByb29tIGFuZCBhIHNhZmUgdXBwZXIg Ym91bmQuDQqWCUdlb2ZmOiA2MDBLIGluIGZpdmUgeWVhcnMgIENocmlzOiBzbyB5b3Ugd2lsbCBu ZWVkIDEuMS0xLjJLIG9iamVjdHMgaW4gZml2ZSANCnllYXJzLiAgSWYgdGhlIGNoYW5nZSByYXRl IGlzIDIwJSB0aGVuIHlvdSBuZWVkIHRvIGV4dHJhbmN0IDI1MEsgb2JqZWN0cyANCmVhY2ggaW50 ZXJ2YWwuDQqWCUdlb2ZmOiB5b3UgYXJlIG5lZWRpbmcgYSBuZXcgb2JqZWN0LCBub3QgYSByZXR1 cm4gdG8gcHJldmlvdXNseSBhbm5vdW5jZWQgDQpzdGF0ZS4NCpYJR2VvZmY6IDEwLTEyIG5ldyBB U3MgYSBkYXksIDMwIG5ldyByb3V0ZXMuDQqWCVJvYjogdXNlIG5ldyBrZXlzIGVhY2ggdGltZSwg c28gYSByZXR1cm4gdG8gcHJldmlvdXMgc3RhdGUgc3RpbGwgbG9va3MgdGhlIA0Kc2FtZS4NCpYJ Q2hyaXM6IG5lZWQgdG8gdW5kZXJzdGFuZCB0aGUgc2l6ZSBhbmQgdGhlIHNwZWVkIG9mIGNoYW5n ZS4gIE5lZWQgdG8gDQpjb2xsZWN0IHRoZSBkYXRhIG9yIGV4dHJhY3QgZnJvbSByb3V0aW5nIGhp c3RvcnkNCpYJR2VvZmY6IHRyb2xsIHRocm91Z2ggUlYgYW5kIFJJUyBhbmQgcHJlc3VtZSBpdCBp cyBhbGwgY2VydGlmaWVkLg0KlglDaHJpczogdGhhdCBpcyB3aGF0IFRpbSBhbmQgKFJJUEUgZ3V5 IGZyb20gQ2FuYWRhKSBhcmUgaW50ZXJlc3RlZCBpbiB0aGlzIA0KKENhbmFkYSBndXkgPSBhbmRy ZSB0b29rKSBhbmQgYXJlIHRyeWluZyB0byBwcmVwYXJlIGZvciBpZXRmIHZhbmNvdXZlci4NCpYJ Um9iOiBpZiB5b3UgYXJlIHJ1bm5pbmcgdGhpcyB3aXRoIHJzeW5jIHRoYXQgaXMgYmluYXJ5IG9u bHkgYW5kIHVzZXMgaW5vZGVzLCANCnlvdSBtaWdodCB3YW50ICB0byBiZSBsb29raW5nIGF0IGRh dGFiYXNlLg0KlglDaHJpczogcnN5bmMgd29ya3MgKFJvYjogaGFzIGEgbG90IG9mIHRoZSBuaWNl IHByb3BlcnRpZXMpIGJ1dCBoYXZpbmcgbW9yZSANCnByb3RvY29scyBpcyBPSy4gIChwZW9wbGUg dHJvdWJsZWQgYnkgaGF2aW5nIGEgbGFyZ2UgbnVtYmVyKS4gIE5lZWQgOTklIA0KdXB0aW1lLiAg Um9iOiBubyBTTEEgZm9yIEROUyBzZXJ2ZXJzLiAgQnJpYW46IHRoZXJlIGlzIGZvciByb290IHNl cnZlcnMuICANCkNocmlzOiBmb3IgUklScywgdGhpcyBtaWdodCBiZSBsaWtlIHJvb3Qgc2VydmVy cywgYnV0IGZvciBtZSwgaXQgaXMgbW9yZSBsaWtlIA0KbXkgbG9jYWwgZG5zIHNlcnZlcg0KKG5v dGUgc2xpZGUgMjgpDQpSZXBvc2l0b3J5IERpc2N1c3Npb24gKENvbnQnZCkNCpUJQ2hyaXM6IHN0 dWZmIHlvdSByZXRyaWV2ZSBuZWVkcyB0byBiZSBoaWdoIHJhdGUsIHN0dWZmIHlvdSBzZXJ2ZSBt YXkgbm90IG5lZWQgdG8gYmUgDQp1cGRhdGVkIGF0IGxvd2VyIHJhdGUuICBSb2I6IHByb2JhYmx5 IG1vcmUgbmVjZXNzYXJ5IHRvIGJlIGF2YWlsYWJsZSBmb3IgcGVvcGxlIHRvIA0KcmV0cmlldmUg dGhhbiBmb3IgbWUgdG8gYmUgYWJsZSB0byB1cGRhdGUgcXVpY2tseQ0KlQlXZXM6IHRoaXMgbWF5 IGNoYW5nZSBpZiB3ZSBhcmUgZHJvcHBpbmcgaW52YWxpZHMuICBJIHJlY2FsbCBjYWxscyB0byBu b2MgdGhhdCBzYXlzIA0Kk3lvdSBtdXN0IHVwZGF0ZSB5b3VyIGRucyBzZXJ2ZXIgaW1tZWRpYXRl bHmULiAgSSBkb26SdCB0aGluayB0aGF0IGl0IGlzIHZhbGlkIHRvIA0KYXNzdW1lIHRob3NlIGNh bGxzIHdvbpJ0IGNvbWUgaW4uICBSb2I6IGRpc3RpbmN0aW9uIHRoYXQgeW91ciBjdXN0b21lcnMg d2lsbCB3YW50IA0KYSBpbW1lZGlhdGUgcmVhY3Rpb24gYW5kIHRoZSBjaGFuY2UgdGhhdCB0aGUg Y2FsbCB3aWxsIGNvbWUgaW4gd2hlbiB5b3UgaGF2ZSB0aGUgDQpzeXN0ZW0gZG93biBmb3IgbWFp bnRlbmFuY2UuDQqVCUJyaWFuOiB5b3Ugd2FudCB5b3VyIHNlcnZlcnMgYXZhaWxhYmxlIHRvIHlv dXIgbmVpZ2hib3JzIHRoYW4gdG8gdGhlIHBlb3BsZSAxMiANCnpvbmVzIGF3YXkuICBSb2IvQ2hy aXM6IGRvbpJ0IGJ1eSB0aGF0IJYgZ2xvYmFsIG5lZWQgZm9yIHRoaXMgZGF0YS4gIEV2ZXJ5b25l IA0Kd2FudHMgYSBjb3B5IG9mIHRoZSB3b3JsZHdpZGUgc3lzdGVtLg0KlQlXYXJyZW46IGhvdyBt dWNoIGRhdGEgaXMgMU0gb2JqZWN0cz8gIFJvYjogMUsgcGVyIG9iamVjdCwgbWF4LiAgV2FycmVu OiAgcm91bmQgDQp0cmlwIHRvIGhpbWFseWFzIGlzIDEwIHNlYy4gIFJvYjogd29ycmllZCBhYm91 dCBwb3VuZGluZyBwcmltYXJ5IHNlcnZlcnMgaW50byB0aGUgDQpncm91bmQuDQqVCVNyaXJhbTog aWYgd2UgYXJlIGRvaW5nIEJyaWFuVy9Sb3F1ZZJzIHByb3Bvc2FsIGZyb20gbGFzdCBJRVRGIGZv ciByZXBsYXkgDQpwcm90ZWN0aW9uLCB5b3UgY291bGQgaW5jcmVhc2UgY2h1cm4gc2lnbmlmaWNh bnRseS4NCpUJQnJpYW46IHlvdSBjb3VsZCBkbyBpdCB0aGF0IGZyZXF1ZW50bHksIGJ1dCB3ZSB3 ZXJlbpJ0IHByb3Bvc2luZyB0aGF0IHlvdSBkbyBpdCB0aGF0IA0KcXVpY2tseS4gIElmIHlvdSBh cmUgd29ycmllZCBhYm91dCBzb21lIHBhcnRpY3VsYXIgZXZlbnQgLCB5b3UgY291bGQgaW5jcmVh c2UgcmF0ZS4NCpUJUnVzc0g6IGR1cmluZyBhbGdvcml0aG0gcm9sbG92ZXIsIHlvdSBuZWVkIGFu b3RoZXIgZmFjdG9yIG9mIDIgaW4gdGhhdCCWIG11bHRpcGxpZXIgDQppcyAyIGF0IHRoZSBwZWFr IGFuZCBidWlsZHMgdXAgYW5kIGZhbGxzIG9mZiBmcm9tIHRoZXJlLg0KlQlDaHJpczogYWxzbyB0 aGluayB3ZSBuZWVkIHRvIGNhcHR1cmUgdGhlIGVudGlyZSBzaXplIG9mIHRoZSByZXBvc2l0b3J5 DQqVCVJvYjogQ1JMUyBhcmUgcG90ZW50aWFsbHkgdW5ib3VuZGVkIGJlY2F1c2UgcGVvcGxlIG1p Z2h0IGhhdmUgdG9vIGxvbmcgDQpleHBpcmF0aW9uIHRpbWVzLCB3aGljaCBtZWFucyBub3RoaW5n IGV2ZXIgZXhwaXJlcyBmcm9tIENSTC4gIChzdG9yeSBvZiB2ZXJ5IA0KdmVyeSB2ZXJ5IGxhcmdl IENSTFMgYmVjYXVzZSBvZiBsb25nIGV4cGlyYXRpb24gdGltZXMpDQoNCg0KDQo= --_002_24B20D14B2CD29478C8D5D6E9CBB29F625F05226Hermescolumbiaa_-- From randy@psg.com Thu May 17 11:52:05 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0FFA21F8737 for ; Thu, 17 May 2012 11:52:05 -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=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k6g10X6BYl8N for ; Thu, 17 May 2012 11:52:05 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id 2A40C21F86A6 for ; Thu, 17 May 2012 11:52:05 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1SV5nw-000LUQ-3T; Thu, 17 May 2012 18:52:04 +0000 Date: Thu, 17 May 2012 08:52:03 -1000 Message-ID: From: Randy Bush To: Sandra Murphy In-Reply-To: <24B20D14B2CD29478C8D5D6E9CBB29F625F05226@Hermes.columbia.ads.sparta.com> References: <24B20D14B2CD29478C8D5D6E9CBB29F60F708799@Hermes.columbia.ads.sparta.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: sidr wg list Subject: Re: [sidr] minutes of 30 Apr 2012 interim meeting X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 May 2012 18:52:05 -0000 thanks for the ascii. as i want to copy and paste, edit, ..., and am an emacs user, ascii text is really nice. otoh, i am happy to read pdf when it is needed for diagrams etc. randy From Sandra.Murphy@sparta.com Thu May 17 14:11:30 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0524B21F8812 for ; Thu, 17 May 2012 14:11:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.606 X-Spam-Level: X-Spam-Status: No, score=-102.606 tagged_above=-999 required=5 tests=[AWL=-0.007, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bwjqmqBC35vC for ; Thu, 17 May 2012 14:11:29 -0700 (PDT) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by ietfa.amsl.com (Postfix) with ESMTP id 53C3D21F8811 for ; Thu, 17 May 2012 14:11:29 -0700 (PDT) Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.14.4/8.14.4) with ESMTP id q4HLBQsB026947; Thu, 17 May 2012 16:11:26 -0500 Received: from Hermes.columbia.ads.sparta.com ([157.185.80.107]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id q4HLBPda014897; Thu, 17 May 2012 16:11:26 -0500 Received: from HERMES.columbia.ads.sparta.com ([2002:9db9:506b::9db9:506b]) by Hermes.columbia.ads.sparta.com ([::1]) with mapi id 14.01.0355.002; Thu, 17 May 2012 17:11:24 -0400 From: "Murphy, Sandra" To: "t.petch" , "sidr@ietf.org" Thread-Topic: [sidr] minutes of 30 Apr 2012 interim meeting Thread-Index: Ac0vWvM0YV1oyh/kRPqOkBhYZhRNdQErISatABC0L3UACb8M7Q== Date: Thu, 17 May 2012 21:11:23 +0000 Message-ID: <24B20D14B2CD29478C8D5D6E9CBB29F625F0837E@Hermes.columbia.ads.sparta.com> References: <24B20D14B2CD29478C8D5D6E9CBB29F60F708799@Hermes.columbia.ads.sparta.com>, <012c01cd3407$14852d20$4001a8c0@gateway.2wire.net>, <24B20D14B2CD29478C8D5D6E9CBB29F625F05226@Hermes.columbia.ads.sparta.com> In-Reply-To: <24B20D14B2CD29478C8D5D6E9CBB29F625F05226@Hermes.columbia.ads.sparta.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.185.63.118] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sidr] minutes of 30 Apr 2012 interim meeting X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 May 2012 21:11:30 -0000 As for the proceedings page:=0A= =0A= I reported the problem to the secretariat. They said they could see the mi= nutes had been uploaded and could open them. The problem is now fixed and = the proceedings page links now work.=0A= =0A= Again, thanks for the alert.=0A= =0A= --Sandy, speaking as wg co-chair=0A= =0A= ________________________________________=0A= From: Murphy, Sandra=0A= Sent: Thursday, May 17, 2012 12:30 PM=0A= To: t.petch; sidr@ietf.org=0A= Subject: RE: [sidr] minutes of 30 Apr 2012 interim meeting=0A= =0A= Mmm, indeed.=0A= =0A= The meeting materials page records that minutes and agenda were uploaded su= ccessfully. So I do not know why it is not appearing in the proceedings pa= ge.=0A= =0A= Thanks for the alert. I'll check with the secretariat as to what happened.= =0A= =0A= From Sandra.Murphy@sparta.com Mon May 21 15:27:03 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1794421F85F2 for ; Mon, 21 May 2012 15:27:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rbs46G1rQEo0 for ; Mon, 21 May 2012 15:27:02 -0700 (PDT) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by ietfa.amsl.com (Postfix) with ESMTP id 7C2F221F85EE for ; Mon, 21 May 2012 15:27:02 -0700 (PDT) Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.14.4/8.14.4) with ESMTP id q4LMR1Ln022332 for ; Mon, 21 May 2012 17:27:01 -0500 Received: from Hermes.columbia.ads.sparta.com ([157.185.80.107]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id q4LMR1B1003813 for ; Mon, 21 May 2012 17:27:01 -0500 Received: from HERMES.columbia.ads.sparta.com ([2002:9db9:506b::9db9:506b]) by Hermes.columbia.ads.sparta.com ([::1]) with mapi id 14.01.0355.002; Mon, 21 May 2012 18:27:01 -0400 From: "Murphy, Sandra" To: "sidr@ietf.org" Thread-Topic: request for agenda items for interim meeting 6 Jun Thread-Index: AQHNM6/4vkOTGr4FY0qnZHxk5Z062pbU2chy Date: Mon, 21 May 2012 22:27:00 +0000 Message-ID: <24B20D14B2CD29478C8D5D6E9CBB29F625F0975D@Hermes.columbia.ads.sparta.com> References: <24B20D14B2CD29478C8D5D6E9CBB29F60F70A267@Hermes.columbia.ads.sparta.com> In-Reply-To: <24B20D14B2CD29478C8D5D6E9CBB29F60F70A267@Hermes.columbia.ads.sparta.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.185.63.118] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sidr] request for agenda items for interim meeting 6 Jun X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 May 2012 22:27:03 -0000 Agenda deadline is Wed 23 Jun (day after tomorrow).=0A= =0A= Please send suggestions to the list.=0A= =0A= --Sandy, speaking as wg co-chair=0A= ________________________________________=0A= From: sidr-bounces@ietf.org [sidr-bounces@ietf.org] on behalf of Murphy, Sa= ndra [Sandra.Murphy@sparta.com]=0A= Sent: Wednesday, May 16, 2012 6:05 PM=0A= To: sidr@ietf.org=0A= Subject: [sidr] request for agenda items for interim meeting 6 Jun=0A= =0A= Potential agenda items for the 6 Jun interim meeting.=0A= =0A= The agenda needs to be announced two weeks ahead of time, which is next Wed= nesday.=0A= =0A= Please send suggested topics to the list. Below are two suggestions to spa= rk the discussion.=0A= =0A= (1) AS_PATH=0A= =0A= There was one agenda topic that we never directly addressed at the 30 Apr m= eeting. That topic was the absence of the AS_PATH attribute from the bgpse= c protocol. (The info normally contained in the AS_PATH is contained in th= e bgpsec attributes.)=0A= =0A= The absence of the AS_PATH did come up in discussing other topics (see the = minutes), but we did not discuss it directly.=0A= =0A= (2) router private key provisioning.=0A= =0A= In the interim in San Diego, there were requests (from operators) that guid= ance to operators of how to provision a router with the needed keys would b= e a good idea. We had some discussion in the Paris meeting of two drafts = discussing provisioning the routers with their needed private keys. There'= s also been a recent flurry of discussion on the list.=0A= =0A= --Sandy, speaking as wg co-chair=0A= _______________________________________________=0A= sidr mailing list=0A= sidr@ietf.org=0A= https://www.ietf.org/mailman/listinfo/sidr=0A= From internet-drafts@ietf.org Mon May 21 19:22:32 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38D5821F85AE; Mon, 21 May 2012 19:22:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pr6u7RfeWoNq; Mon, 21 May 2012 19:22:31 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7A5D21F8516; Mon, 21 May 2012 19:22:31 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.02 Message-ID: <20120522022231.22474.27093.idtracker@ietfa.amsl.com> Date: Mon, 21 May 2012 19:22:31 -0700 Cc: sidr@ietf.org Subject: [sidr] I-D Action: draft-ietf-sidr-pfx-validate-06.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 May 2012 02:22:32 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Secure Inter-Domain Routing Working G= roup of the IETF. Title : BGP Prefix Origin Validation Author(s) : Pradosh Mohapatra John Scudder David Ward Randy Bush Rob Austein Filename : draft-ietf-sidr-pfx-validate-06.txt Pages : 11 Date : 2012-05-21 To help reduce well-known threats against BGP including prefix mis- announcing and monkey-in-the-middle attacks, one of the security requirements is the ability to validate the origination AS of BGP routes. More specifically, one needs to validate that the AS number claiming to originate an address prefix (as derived from the AS_PATH attribute of the BGP route) is in fact authorized by the prefix holder to do so. This document describes a simple validation mechanism to partially satisfy this requirement. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sidr-pfx-validate-06.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-sidr-pfx-validate-06.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-sidr-pfx-validate/ From Sandra.Murphy@sparta.com Tue May 22 07:08:34 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D87D721F85FD for ; Tue, 22 May 2012 07:08:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lC+ns1gjPE9L for ; Tue, 22 May 2012 07:08:34 -0700 (PDT) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by ietfa.amsl.com (Postfix) with ESMTP id 2453621F85EA for ; Tue, 22 May 2012 07:08:34 -0700 (PDT) Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.14.4/8.14.4) with ESMTP id q4ME8WK0026290 for ; Tue, 22 May 2012 09:08:32 -0500 Received: from Hermes.columbia.ads.sparta.com ([157.185.80.107]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id q4ME8QZc016362 for ; Tue, 22 May 2012 09:08:29 -0500 Received: from HERMES.columbia.ads.sparta.com ([2002:9db9:506b::9db9:506b]) by Hermes.columbia.ads.sparta.com ([::1]) with mapi id 14.01.0355.002; Tue, 22 May 2012 10:08:26 -0400 From: "Murphy, Sandra" To: "sidr@ietf.org" Thread-Topic: request for agenda items for interim meeting 6 Jun Thread-Index: AQHNM6/4vkOTGr4FY0qnZHxk5Z062pbU2chygAEHCc0= Date: Tue, 22 May 2012 14:08:25 +0000 Message-ID: <24B20D14B2CD29478C8D5D6E9CBB29F625F09827@Hermes.columbia.ads.sparta.com> References: <24B20D14B2CD29478C8D5D6E9CBB29F60F70A267@Hermes.columbia.ads.sparta.com>, <24B20D14B2CD29478C8D5D6E9CBB29F625F0975D@Hermes.columbia.ads.sparta.com> In-Reply-To: <24B20D14B2CD29478C8D5D6E9CBB29F625F0975D@Hermes.columbia.ads.sparta.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.185.63.118] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sidr] request for agenda items for interim meeting 6 Jun X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 May 2012 14:08:35 -0000 An eagle eye reader points out that the agenda deadline before the June mee= ting is in May, not June, and the day after tomorrow is still May, not June= .=0A= =0A= Still. Get any requests for topics in asap. Agenda deadline is Wed 23 May= (tomorrow).=0A= =0A= --Sandy, speaking as wg co-chair=0A= ________________________________________=0A= From: sidr-bounces@ietf.org [sidr-bounces@ietf.org] on behalf of Murphy, Sa= ndra [Sandra.Murphy@sparta.com]=0A= Sent: Monday, May 21, 2012 6:27 PM=0A= To: sidr@ietf.org=0A= Subject: Re: [sidr] request for agenda items for interim meeting 6 Jun=0A= =0A= Agenda deadline is Wed 23 Jun (day after tomorrow).=0A= =0A= Please send suggestions to the list.=0A= =0A= --Sandy, speaking as wg co-chair=0A= ________________________________________=0A= From: sidr-bounces@ietf.org [sidr-bounces@ietf.org] on behalf of Murphy, Sa= ndra [Sandra.Murphy@sparta.com]=0A= Sent: Wednesday, May 16, 2012 6:05 PM=0A= To: sidr@ietf.org=0A= Subject: [sidr] request for agenda items for interim meeting 6 Jun=0A= =0A= Potential agenda items for the 6 Jun interim meeting.=0A= =0A= The agenda needs to be announced two weeks ahead of time, which is next Wed= nesday.=0A= =0A= Please send suggested topics to the list. Below are two suggestions to spa= rk the discussion.=0A= =0A= (1) AS_PATH=0A= =0A= There was one agenda topic that we never directly addressed at the 30 Apr m= eeting. That topic was the absence of the AS_PATH attribute from the bgpse= c protocol. (The info normally contained in the AS_PATH is contained in th= e bgpsec attributes.)=0A= =0A= The absence of the AS_PATH did come up in discussing other topics (see the = minutes), but we did not discuss it directly.=0A= =0A= (2) router private key provisioning.=0A= =0A= In the interim in San Diego, there were requests (from operators) that guid= ance to operators of how to provision a router with the needed keys would b= e a good idea. We had some discussion in the Paris meeting of two drafts = discussing provisioning the routers with their needed private keys. There'= s also been a recent flurry of discussion on the list.=0A= =0A= --Sandy, speaking as wg co-chair=0A= _______________________________________________=0A= sidr mailing list=0A= sidr@ietf.org=0A= https://www.ietf.org/mailman/listinfo/sidr=0A= _______________________________________________=0A= sidr mailing list=0A= sidr@ietf.org=0A= https://www.ietf.org/mailman/listinfo/sidr=0A= From alexey.melnikov@isode.com Tue May 22 07:52:39 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B59AF21F85DF for ; Tue, 22 May 2012 07:52:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.203 X-Spam-Level: X-Spam-Status: No, score=-101.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z8cMCL+IbuYB for ; Tue, 22 May 2012 07:52:38 -0700 (PDT) Received: from rufus.isode.com (cl-125.lon-03.gb.sixxs.net [IPv6:2a00:14f0:e000:7c::2]) by ietfa.amsl.com (Postfix) with ESMTP id EBC5521F8568 for ; Tue, 22 May 2012 07:52:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1337698355; d=isode.com; s=selector; i=@isode.com; bh=3U2k2ooK7MA5wY9DOlQH4jiR7dH6KZkEaAR6N9+Em4o=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=CLFGQu8MSybn/1jou5SrbmgLq07uJ7PusJ9UOAqo/AVlZXcrg71v69dpOpq4RrAP+jGJW0 ZNqrNgATiXE03TgU9A/YW2uL/FYslBj3ogBjGnTm1Akx9wOAVQM5zHd/OK3U533AYppkeu gty8VaR6vO6ZYjQwe178IQdQ20X6HBk=; Received: from [10.0.0.102] (173-164-130-65-SFBA.hfc.comcastbusiness.net [173.164.130.65]) by rufus.isode.com (submission channel) via TCP with ESMTPSA id ; Tue, 22 May 2012 15:52:35 +0100 References: <24B20D14B2CD29478C8D5D6E9CBB29F60F70A267@Hermes.columbia.ads.sparta.com> <24B20D14B2CD29478C8D5D6E9CBB29F625F0975D@Hermes.columbia.ads.sparta.com> <24B20D14B2CD29478C8D5D6E9CBB29F625F09827@Hermes.columbia.ads.sparta.com> In-Reply-To: <24B20D14B2CD29478C8D5D6E9CBB29F625F09827@Hermes.columbia.ads.sparta.com> Message-Id: <2822D611-CAC9-4239-B4BB-CE3998C31D07@isode.com> X-Mailer: iPad Mail (9B206) From: Alexey Melnikov Date: Tue, 22 May 2012 07:52:31 -0700 To: "sidr@ietf.org" MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: "Murphy, Sandra" Subject: Re: [sidr] request for agenda items for interim meeting 6 Jun X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 May 2012 14:52:39 -0000 Hi WG, On 22 May 2012, at 07:08, "Murphy, Sandra" wrote:= > An eagle eye reader points out that the agenda deadline before the June me= eting is in May, not June, and the day after tomorrow is still May, not June= . >=20 > Still. Get any requests for topics in asap. Agenda deadline is Wed 23 Ma= y (tomorrow). I would like to add to this: if there are no topics to discuss, chairs reser= ve the right to cancel the interim. So in absence of new topics, some confir= mation that what Sandy suggested as the agenda earlier would be good. >=20 > --Sandy, speaking as wg co-chair > ________________________________________ > From: sidr-bounces@ietf.org [sidr-bounces@ietf.org] on behalf of Murphy, S= andra [Sandra.Murphy@sparta.com] > Sent: Monday, May 21, 2012 6:27 PM > To: sidr@ietf.org > Subject: Re: [sidr] request for agenda items for interim meeting 6 Jun >=20 > Agenda deadline is Wed 23 Jun (day after tomorrow). >=20 > Please send suggestions to the list. >=20 > --Sandy, speaking as wg co-chair > ________________________________________ > From: sidr-bounces@ietf.org [sidr-bounces@ietf.org] on behalf of Murphy, S= andra [Sandra.Murphy@sparta.com] > Sent: Wednesday, May 16, 2012 6:05 PM > To: sidr@ietf.org > Subject: [sidr] request for agenda items for interim meeting 6 Jun >=20 > Potential agenda items for the 6 Jun interim meeting. >=20 > The agenda needs to be announced two weeks ahead of time, which is next We= dnesday. >=20 > Please send suggested topics to the list. Below are two suggestions to sp= ark the discussion. >=20 > (1) AS_PATH >=20 > There was one agenda topic that we never directly addressed at the 30 Apr m= eeting. That topic was the absence of the AS_PATH attribute from the bgpsec= protocol. (The info normally contained in the AS_PATH is contained in the b= gpsec attributes.) >=20 > The absence of the AS_PATH did come up in discussing other topics (see the= minutes), but we did not discuss it directly. >=20 > (2) router private key provisioning. >=20 > In the interim in San Diego, there were requests (from operators) that gui= dance to operators of how to provision a router with the needed keys would b= e a good idea. We had some discussion in the Paris meeting of two drafts d= iscussing provisioning the routers with their needed private keys. There's a= lso been a recent flurry of discussion on the list. >=20 > --Sandy, speaking as wg co-chair > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr From warren@kumari.net Tue May 22 08:21:48 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DB8E21F85FD for ; Tue, 22 May 2012 08:21:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.299 X-Spam-Level: X-Spam-Status: No, score=-106.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MVRwvoT9czhS for ; Tue, 22 May 2012 08:21:47 -0700 (PDT) Received: from vimes.kumari.net (vimes.kumari.net [198.186.192.250]) by ietfa.amsl.com (Postfix) with ESMTP id 5B7EF21F85F9 for ; Tue, 22 May 2012 08:21:47 -0700 (PDT) Received: from dhcp-172-19-118-235.cbf.corp.google.com (unknown [64.13.52.115]) by vimes.kumari.net (Postfix) with ESMTPSA id 1E7C71B402F0; Tue, 22 May 2012 11:21:46 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Warren Kumari In-Reply-To: <2822D611-CAC9-4239-B4BB-CE3998C31D07@isode.com> Date: Tue, 22 May 2012 11:21:43 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <24B20D14B2CD29478C8D5D6E9CBB29F60F70A267@Hermes.columbia.ads.sparta.com> <24B20D14B2CD29478C8D5D6E9CBB29F625F0975D@Hermes.columbia.ads.sparta.com> <24B20D14B2CD29478C8D5D6E9CBB29F625F09827@Hermes.columbia.ads.sparta.com> <2822D611-CAC9-4239-B4BB-CE3998C31D07@isode.com> To: Alexey Melnikov X-Mailer: Apple Mail (2.1278) Cc: "Murphy, Sandra" , "sidr@ietf.org" Subject: Re: [sidr] request for agenda items for interim meeting 6 Jun X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 May 2012 15:21:48 -0000 On May 22, 2012, at 10:52 AM, Alexey Melnikov wrote: > Hi WG, >=20 > On 22 May 2012, at 07:08, "Murphy, Sandra" = wrote: >=20 >> An eagle eye reader points out that the agenda deadline before the = June meeting is in May, not June, and the day after tomorrow is still = May, not June. >>=20 >> Still. Get any requests for topics in asap. Agenda deadline is Wed = 23 May (tomorrow). >=20 > I would like to add to this: if there are no topics to discuss, chairs = reserve the right to cancel the interim. So in absence of new topics, = some confirmation that what Sandy suggested as the agenda earlier would = be good. Well, color me stoopid -- I have not been able to find "what Sandy = suggested as the agenda earlier". 'tis not (AFAICS) on the wiki, the Interim Announcement doesn't have = nothing agenda like, the list doesn't seem to have anything, etc. W >>=20 >> --Sandy, speaking as wg co-chair >> ________________________________________ >> From: sidr-bounces@ietf.org [sidr-bounces@ietf.org] on behalf of = Murphy, Sandra [Sandra.Murphy@sparta.com] >> Sent: Monday, May 21, 2012 6:27 PM >> To: sidr@ietf.org >> Subject: Re: [sidr] request for agenda items for interim meeting 6 = Jun >>=20 >> Agenda deadline is Wed 23 Jun (day after tomorrow). >>=20 >> Please send suggestions to the list. >>=20 >> --Sandy, speaking as wg co-chair >> ________________________________________ >> From: sidr-bounces@ietf.org [sidr-bounces@ietf.org] on behalf of = Murphy, Sandra [Sandra.Murphy@sparta.com] >> Sent: Wednesday, May 16, 2012 6:05 PM >> To: sidr@ietf.org >> Subject: [sidr] request for agenda items for interim meeting 6 Jun >>=20 >> Potential agenda items for the 6 Jun interim meeting. >>=20 >> The agenda needs to be announced two weeks ahead of time, which is = next Wednesday. >>=20 >> Please send suggested topics to the list. Below are two suggestions = to spark the discussion. >>=20 >> (1) AS_PATH >>=20 >> There was one agenda topic that we never directly addressed at the 30 = Apr meeting. That topic was the absence of the AS_PATH attribute from = the bgpsec protocol. (The info normally contained in the AS_PATH is = contained in the bgpsec attributes.) >>=20 >> The absence of the AS_PATH did come up in discussing other topics = (see the minutes), but we did not discuss it directly. >>=20 >> (2) router private key provisioning. >>=20 >> In the interim in San Diego, there were requests (from operators) = that guidance to operators of how to provision a router with the needed = keys would be a good idea. We had some discussion in the Paris meeting = of two drafts discussing provisioning the routers with their needed = private keys. There's also been a recent flurry of discussion on the = list. >>=20 >> --Sandy, speaking as wg co-chair >> _______________________________________________ >> sidr mailing list >> sidr@ietf.org >> https://www.ietf.org/mailman/listinfo/sidr >> _______________________________________________ >> sidr mailing list >> sidr@ietf.org >> https://www.ietf.org/mailman/listinfo/sidr >> _______________________________________________ >> sidr mailing list >> sidr@ietf.org >> https://www.ietf.org/mailman/listinfo/sidr > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr >=20 --=20 With Feudalism, it's your Count that votes. From alexey.melnikov@isode.com Tue May 22 08:38:41 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC65721F85D3 for ; Tue, 22 May 2012 08:38:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.203 X-Spam-Level: X-Spam-Status: No, score=-101.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2nyjNu1Em3e0 for ; Tue, 22 May 2012 08:38:41 -0700 (PDT) Received: from rufus.isode.com (cl-125.lon-03.gb.sixxs.net [IPv6:2a00:14f0:e000:7c::2]) by ietfa.amsl.com (Postfix) with ESMTP id A6A2F21F85FC for ; Tue, 22 May 2012 08:38:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1337701118; d=isode.com; s=selector; i=@isode.com; bh=4VWcNI11cpBqIZRNnI3XkW8K4YoItb9oyXRGO+tKH4o=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=iW6KdobAVkqNEue3tY1NTRCkFc4OEyfTSkHGPYV64wvpKumfHD0l6eTDurePWz8Y1UpsRR vGXgWsZ5Mg7GJ0IOryMMb8JnxAt+AnnYJCgL7o6tdTx3o8zhet3nCX6SFvSk3QAFQ9ShP3 EXkWeBbbSuzQn7ssfiM5WBuen47iPQo=; Received: from [10.0.0.102] (173-164-130-65-SFBA.hfc.comcastbusiness.net [173.164.130.65]) by rufus.isode.com (submission channel) via TCP with ESMTPSA id ; Tue, 22 May 2012 16:38:38 +0100 References: <24B20D14B2CD29478C8D5D6E9CBB29F60F70A267@Hermes.columbia.ads.sparta.com> <24B20D14B2CD29478C8D5D6E9CBB29F625F0975D@Hermes.columbia.ads.sparta.com> <24B20D14B2CD29478C8D5D6E9CBB29F625F09827@Hermes.columbia.ads.sparta.com> <2822D611-CAC9-4239-B4BB-CE3998C31D07@isode.com> In-Reply-To: Message-Id: X-Mailer: iPad Mail (9B206) From: Alexey Melnikov Date: Tue, 22 May 2012 08:38:36 -0700 To: Warren Kumari MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Cc: "Murphy, Sandra" , "sidr@ietf.org" Subject: Re: [sidr] request for agenda items for interim meeting 6 Jun X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 May 2012 15:38:41 -0000 Hi, On 22 May 2012, at 08:21, Warren Kumari wrote: >=20 > On May 22, 2012, at 10:52 AM, Alexey Melnikov wrote: >=20 >> Hi WG, >>=20 >> On 22 May 2012, at 07:08, "Murphy, Sandra" wro= te: >>=20 >>> An eagle eye reader points out that the agenda deadline before the June m= eeting is in May, not June, and the day after tomorrow is still May, not Jun= e. >>>=20 >>> Still. Get any requests for topics in asap. Agenda deadline is Wed 23 M= ay (tomorrow). >>=20 >> I would like to add to this: if there are no topics to discuss, chairs re= serve the right to cancel the interim. So in absence of new topics, some con= firmation that what Sandy suggested as the agenda earlier would be good. >=20 >=20 > Well, color me stoopid -- I have not been able to find "what Sandy suggest= ed as the agenda earlier". Below (quoted text) :-) >=20 > 'tis not (AFAICS) on the wiki, the Interim Announcement doesn't have nothi= ng agenda like, the list doesn't seem to have anything, etc. >=20 > W >=20 >=20 >>>=20 >>> --Sandy, speaking as wg co-chair >>> ________________________________________ >>> From: sidr-bounces@ietf.org [sidr-bounces@ietf.org] on behalf of Murphy,= Sandra [Sandra.Murphy@sparta.com] >>> Sent: Monday, May 21, 2012 6:27 PM >>> To: sidr@ietf.org >>> Subject: Re: [sidr] request for agenda items for interim meeting 6 Jun >>>=20 >>> Agenda deadline is Wed 23 Jun (day after tomorrow). >>>=20 >>> Please send suggestions to the list. >>>=20 >>> --Sandy, speaking as wg co-chair >>> ________________________________________ >>> From: sidr-bounces@ietf.org [sidr-bounces@ietf.org] on behalf of Murphy,= Sandra [Sandra.Murphy@sparta.com] >>> Sent: Wednesday, May 16, 2012 6:05 PM >>> To: sidr@ietf.org >>> Subject: [sidr] request for agenda items for interim meeting 6 Jun >>>=20 >>> Potential agenda items for the 6 Jun interim meeting. >>>=20 >>> The agenda needs to be announced two weeks ahead of time, which is next W= ednesday. >>>=20 >>> Please send suggested topics to the list. Below are two suggestions to s= park the discussion. >>>=20 >>> (1) AS_PATH >>>=20 >>> There was one agenda topic that we never directly addressed at the 30 Ap= r meeting. That topic was the absence of the AS_PATH attribute from the bgp= sec protocol. (The info normally contained in the AS_PATH is contained in t= he bgpsec attributes.) >>>=20 >>> The absence of the AS_PATH did come up in discussing other topics (see t= he minutes), but we did not discuss it directly. >>>=20 >>> (2) router private key provisioning. >>>=20 >>> In the interim in San Diego, there were requests (from operators) that g= uidance to operators of how to provision a router with the needed keys would= be a good idea. We had some discussion in the Paris meeting of two drafts= discussing provisioning the routers with their needed private keys. There'= s also been a recent flurry of discussion on the list. >>>=20 >>> --Sandy, speaking as wg co-chair >>> _______________________________________________ >>> sidr mailing list >>> sidr@ietf.org >>> https://www.ietf.org/mailman/listinfo/sidr >>> _______________________________________________ >>> sidr mailing list >>> sidr@ietf.org >>> https://www.ietf.org/mailman/listinfo/sidr >>> _______________________________________________ >>> sidr mailing list >>> sidr@ietf.org >>> https://www.ietf.org/mailman/listinfo/sidr >> _______________________________________________ >> sidr mailing list >> sidr@ietf.org >> https://www.ietf.org/mailman/listinfo/sidr >>=20 >=20 > --=20 > With Feudalism, it's your Count that votes. >=20 >=20 From Sandra.Murphy@sparta.com Tue May 22 08:38:44 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A42221F861A for ; Tue, 22 May 2012 08:38:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6hE3P6rl4W+k for ; Tue, 22 May 2012 08:38:43 -0700 (PDT) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by ietfa.amsl.com (Postfix) with ESMTP id 3C80421F8610 for ; Tue, 22 May 2012 08:38:43 -0700 (PDT) Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.14.4/8.14.4) with ESMTP id q4MFcfsB027413; Tue, 22 May 2012 10:38:42 -0500 Received: from Hermes.columbia.ads.sparta.com ([157.185.80.107]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id q4MFcZIr020095; Tue, 22 May 2012 10:38:38 -0500 Received: from HERMES.columbia.ads.sparta.com ([2002:9db9:506b::9db9:506b]) by Hermes.columbia.ads.sparta.com ([::1]) with mapi id 14.01.0355.002; Tue, 22 May 2012 11:38:35 -0400 From: "Murphy, Sandra" To: Warren Kumari , Alexey Melnikov Thread-Topic: [sidr] request for agenda items for interim meeting 6 Jun Thread-Index: AQHNM6/4vkOTGr4FY0qnZHxk5Z062pbU2chygAEHCc2AAE/kgIAACCiA///BKDs= Date: Tue, 22 May 2012 15:38:34 +0000 Message-ID: <24B20D14B2CD29478C8D5D6E9CBB29F625F09890@Hermes.columbia.ads.sparta.com> References: <24B20D14B2CD29478C8D5D6E9CBB29F60F70A267@Hermes.columbia.ads.sparta.com> <24B20D14B2CD29478C8D5D6E9CBB29F625F0975D@Hermes.columbia.ads.sparta.com> <24B20D14B2CD29478C8D5D6E9CBB29F625F09827@Hermes.columbia.ads.sparta.com> <2822D611-CAC9-4239-B4BB-CE3998C31D07@isode.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.185.63.118] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "sidr@ietf.org" Subject: Re: [sidr] request for agenda items for interim meeting 6 Jun X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 May 2012 15:38:44 -0000 See the message from last week:=0A= =0A= http://www.ietf.org/mail-archive/web/sidr/current/msg04632.html=0A= =0A= Registration and location details will be on the wiki soon.=0A= =0A= --Sandy=0A= =0A= ________________________________________=0A= From: Warren Kumari [warren@kumari.net]=0A= Sent: Tuesday, May 22, 2012 11:21 AM=0A= To: Alexey Melnikov=0A= Cc: sidr@ietf.org; Murphy, Sandra=0A= Subject: Re: [sidr] request for agenda items for interim meeting 6 Jun=0A= =0A= On May 22, 2012, at 10:52 AM, Alexey Melnikov wrote:=0A= =0A= > Hi WG,=0A= >=0A= > On 22 May 2012, at 07:08, "Murphy, Sandra" wro= te:=0A= >=0A= >> An eagle eye reader points out that the agenda deadline before the June = meeting is in May, not June, and the day after tomorrow is still May, not J= une.=0A= >>=0A= >> Still. Get any requests for topics in asap. Agenda deadline is Wed 23 = May (tomorrow).=0A= >=0A= > I would like to add to this: if there are no topics to discuss, chairs re= serve the right to cancel the interim. So in absence of new topics, some co= nfirmation that what Sandy suggested as the agenda earlier would be good.= =0A= =0A= =0A= Well, color me stoopid -- I have not been able to find "what Sandy suggeste= d as the agenda earlier".=0A= =0A= 'tis not (AFAICS) on the wiki, the Interim Announcement doesn't have nothin= g agenda like, the list doesn't seem to have anything, etc.=0A= =0A= W=0A= =0A= =0A= >>=0A= >> --Sandy, speaking as wg co-chair=0A= >> ________________________________________=0A= >> From: sidr-bounces@ietf.org [sidr-bounces@ietf.org] on behalf of Murphy,= Sandra [Sandra.Murphy@sparta.com]=0A= >> Sent: Monday, May 21, 2012 6:27 PM=0A= >> To: sidr@ietf.org=0A= >> Subject: Re: [sidr] request for agenda items for interim meeting 6 Jun= =0A= >>=0A= >> Agenda deadline is Wed 23 Jun (day after tomorrow).=0A= >>=0A= >> Please send suggestions to the list.=0A= >>=0A= >> --Sandy, speaking as wg co-chair=0A= >> ________________________________________=0A= >> From: sidr-bounces@ietf.org [sidr-bounces@ietf.org] on behalf of Murphy,= Sandra [Sandra.Murphy@sparta.com]=0A= >> Sent: Wednesday, May 16, 2012 6:05 PM=0A= >> To: sidr@ietf.org=0A= >> Subject: [sidr] request for agenda items for interim meeting 6 Jun=0A= >>=0A= >> Potential agenda items for the 6 Jun interim meeting.=0A= >>=0A= >> The agenda needs to be announced two weeks ahead of time, which is next = Wednesday.=0A= >>=0A= >> Please send suggested topics to the list. Below are two suggestions to = spark the discussion.=0A= >>=0A= >> (1) AS_PATH=0A= >>=0A= >> There was one agenda topic that we never directly addressed at the 30 Ap= r meeting. That topic was the absence of the AS_PATH attribute from the bg= psec protocol. (The info normally contained in the AS_PATH is contained in= the bgpsec attributes.)=0A= >>=0A= >> The absence of the AS_PATH did come up in discussing other topics (see t= he minutes), but we did not discuss it directly.=0A= >>=0A= >> (2) router private key provisioning.=0A= >>=0A= >> In the interim in San Diego, there were requests (from operators) that g= uidance to operators of how to provision a router with the needed keys woul= d be a good idea. We had some discussion in the Paris meeting of two draf= ts discussing provisioning the routers with their needed private keys. The= re's also been a recent flurry of discussion on the list.=0A= >>=0A= >> --Sandy, speaking as wg co-chair=0A= >> _______________________________________________=0A= >> sidr mailing list=0A= >> sidr@ietf.org=0A= >> https://www.ietf.org/mailman/listinfo/sidr=0A= >> _______________________________________________=0A= >> sidr mailing list=0A= >> sidr@ietf.org=0A= >> https://www.ietf.org/mailman/listinfo/sidr=0A= >> _______________________________________________=0A= >> sidr mailing list=0A= >> sidr@ietf.org=0A= >> https://www.ietf.org/mailman/listinfo/sidr=0A= > _______________________________________________=0A= > sidr mailing list=0A= > sidr@ietf.org=0A= > https://www.ietf.org/mailman/listinfo/sidr=0A= >=0A= =0A= --=0A= With Feudalism, it's your Count that votes.=0A= =0A= =0A= From mlepinski@bbn.com Tue May 22 08:54:57 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FD5121F8552 for ; Tue, 22 May 2012 08:54:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MaYVOXN0SS+B for ; Tue, 22 May 2012 08:54:56 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 44A1221F8470 for ; Tue, 22 May 2012 08:54:56 -0700 (PDT) Received: from mail.bbn.com ([128.33.0.48]:40603) by smtp.bbn.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1SWrPl-000Mk0-DF for sidr@ietf.org; Tue, 22 May 2012 11:54:25 -0400 Received: from dhcp89-089-205.bbn.com ([128.89.89.205]) by mail.bbn.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1SWrQE-0000yu-KY for sidr@ietf.org; Tue, 22 May 2012 11:54:55 -0400 Message-ID: <4FBBB6D1.9000008@bbn.com> Date: Tue, 22 May 2012 11:54:57 -0400 From: Matt Lepinski User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: sidr@ietf.org References: <24B20D14B2CD29478C8D5D6E9CBB29F60F70A267@Hermes.columbia.ads.sparta.com> <24B20D14B2CD29478C8D5D6E9CBB29F625F0975D@Hermes.columbia.ads.sparta.com> In-Reply-To: <24B20D14B2CD29478C8D5D6E9CBB29F625F0975D@Hermes.columbia.ads.sparta.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [sidr] request for agenda items for interim meeting 6 Jun X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 May 2012 15:54:57 -0000 Sandy, In my opinion the biggest open issue in the bgpsec protocol draft is the confederation issue that we discussed at the previous interim. (That is, if we don't include AS4_Path or AS_Path in a bgpsec signed update, then we need to somehow encode the information that would be in the AS_confed_sequence segments of the AS_Path.) At the April interim there were three possible solutions that people put forward to address this issue. However, we didn't decide on what was the best way forward. Now that people have had some more time to think about the issue, I would very much like to try and reach concensus at the Vancouver interim so that we can close this issue. If it would be helpful, I'm happy to throw together a few slides for the interim summarizing the problem and the possible solutions discussed at the April interim. Also, recently submitted a new version of draft-ietf-sidr-bgpsec-protocol (the -03 version). This document has significant changes from the (-02) version. Most, if not all of the changes were discussed at the Paris sidr meeting, so it probably isn't necessary to present them again. However, I would encourage anyone who is able to read Section 3 (the format for the BGPSEC_Path_Signatures attribute) of the -03 version before Vancouver. There may be places in the draft where the foolish document editor failed to produce text that reflects what the working group agreed to in Paris, and it would be good to get those issues (if they exist) resolved sooner rather than later. - Matt Lepinski On 5/21/2012 6:27 PM, Murphy, Sandra wrote: > Agenda deadline is Wed 23 Jun (day after tomorrow). > > Please send suggestions to the list. > > --Sandy, speaking as wg co-chair > ________________________________________ > From: sidr-bounces@ietf.org [sidr-bounces@ietf.org] on behalf of Murphy, Sandra [Sandra.Murphy@sparta.com] > Sent: Wednesday, May 16, 2012 6:05 PM > To: sidr@ietf.org > Subject: [sidr] request for agenda items for interim meeting 6 Jun > > Potential agenda items for the 6 Jun interim meeting. > > The agenda needs to be announced two weeks ahead of time, which is next Wednesday. > > Please send suggested topics to the list. Below are two suggestions to spark the discussion. > > (1) AS_PATH > > There was one agenda topic that we never directly addressed at the 30 Apr meeting. That topic was the absence of the AS_PATH attribute from the bgpsec protocol. (The info normally contained in the AS_PATH is contained in the bgpsec attributes.) > > The absence of the AS_PATH did come up in discussing other topics (see the minutes), but we did not discuss it directly. > > (2) router private key provisioning. > > In the interim in San Diego, there were requests (from operators) that guidance to operators of how to provision a router with the needed keys would be a good idea. We had some discussion in the Paris meeting of two drafts discussing provisioning the routers with their needed private keys. There's also been a recent flurry of discussion on the list. > > --Sandy, speaking as wg co-chair > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr > From warren@kumari.net Tue May 22 08:59:17 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C07521F8671 for ; Tue, 22 May 2012 08:59:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.449 X-Spam-Level: X-Spam-Status: No, score=-106.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fW0whlqRG-1U for ; Tue, 22 May 2012 08:59:17 -0700 (PDT) Received: from vimes.kumari.net (vimes.kumari.net [198.186.192.250]) by ietfa.amsl.com (Postfix) with ESMTP id D337F21F8587 for ; Tue, 22 May 2012 08:59:16 -0700 (PDT) Received: from dhcp-172-19-118-235.cbf.corp.google.com (unknown [64.13.52.115]) by vimes.kumari.net (Postfix) with ESMTPSA id 42F811B402F2; Tue, 22 May 2012 11:59:16 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=windows-1252 From: Warren Kumari In-Reply-To: Date: Tue, 22 May 2012 11:59:13 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <24B20D14B2CD29478C8D5D6E9CBB29F60F70A267@Hermes.columbia.ads.sparta.com> <24B20D14B2CD29478C8D5D6E9CBB29F625F0975D@Hermes.columbia.ads.sparta.com> <24B20D14B2CD29478C8D5D6E9CBB29F625F09827@Hermes.columbia.ads.sparta.com> <2822D611-CAC9-4239-B4BB-CE3998C31D07@isode.com> To: Alexey Melnikov X-Mailer: Apple Mail (2.1278) Cc: "Murphy, Sandra" , "sidr@ietf.org" Subject: Re: [sidr] request for agenda items for interim meeting 6 Jun X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 May 2012 15:59:17 -0000 On May 22, 2012, at 11:38 AM, Alexey Melnikov wrote: > Hi, >=20 > On 22 May 2012, at 08:21, Warren Kumari wrote: >=20 >>=20 >> On May 22, 2012, at 10:52 AM, Alexey Melnikov wrote: >>=20 >>> Hi WG, >>>=20 >>> On 22 May 2012, at 07:08, "Murphy, Sandra" = wrote: >>>=20 >>>> An eagle eye reader points out that the agenda deadline before the = June meeting is in May, not June, and the day after tomorrow is still = May, not June. >>>>=20 >>>> Still. Get any requests for topics in asap. Agenda deadline is = Wed 23 May (tomorrow). >>>=20 >>> I would like to add to this: if there are no topics to discuss, = chairs reserve the right to cancel the interim. So in absence of new = topics, some confirmation that what Sandy suggested as the agenda = earlier would be good. >>=20 >>=20 >> Well, color me stoopid -- I have not been able to find "what Sandy = suggested as the agenda earlier". >=20 > Below (quoted text) :-) >>=20 Ok, color me *very stooped* then -- my mail client helpfully collapsed = the earlier stuff and hid it under a "See more=85" label=85 Apologies for the grumpy tone, going to go hide under a rock now=85 Oh, and the agenda looks good to me=85 W >> 'tis not (AFAICS) on the wiki, the Interim Announcement doesn't have = nothing agenda like, the list doesn't seem to have anything, etc. >>=20 >> W >>=20 >>=20 >>>>=20 >>>> --Sandy, speaking as wg co-chair >>>> ________________________________________ >>>> From: sidr-bounces@ietf.org [sidr-bounces@ietf.org] on behalf of = Murphy, Sandra [Sandra.Murphy@sparta.com] >>>> Sent: Monday, May 21, 2012 6:27 PM >>>> To: sidr@ietf.org >>>> Subject: Re: [sidr] request for agenda items for interim meeting 6 = Jun >>>>=20 >>>> Agenda deadline is Wed 23 Jun (day after tomorrow). >>>>=20 >>>> Please send suggestions to the list. >>>>=20 >>>> --Sandy, speaking as wg co-chair >>>> ________________________________________ >>>> From: sidr-bounces@ietf.org [sidr-bounces@ietf.org] on behalf of = Murphy, Sandra [Sandra.Murphy@sparta.com] >>>> Sent: Wednesday, May 16, 2012 6:05 PM >>>> To: sidr@ietf.org >>>> Subject: [sidr] request for agenda items for interim meeting 6 Jun >>>>=20 >>>> Potential agenda items for the 6 Jun interim meeting. >>>>=20 >>>> The agenda needs to be announced two weeks ahead of time, which is = next Wednesday. >>>>=20 >>>> Please send suggested topics to the list. Below are two = suggestions to spark the discussion. >>>>=20 >>>> (1) AS_PATH >>>>=20 >>>> There was one agenda topic that we never directly addressed at the = 30 Apr meeting. That topic was the absence of the AS_PATH attribute = from the bgpsec protocol. (The info normally contained in the AS_PATH = is contained in the bgpsec attributes.) >>>>=20 >>>> The absence of the AS_PATH did come up in discussing other topics = (see the minutes), but we did not discuss it directly. >>>>=20 >>>> (2) router private key provisioning. >>>>=20 >>>> In the interim in San Diego, there were requests (from operators) = that guidance to operators of how to provision a router with the needed = keys would be a good idea. We had some discussion in the Paris meeting = of two drafts discussing provisioning the routers with their needed = private keys. There's also been a recent flurry of discussion on the = list. >>>>=20 >>>> --Sandy, speaking as wg co-chair >>>> _______________________________________________ >>>> sidr mailing list >>>> sidr@ietf.org >>>> https://www.ietf.org/mailman/listinfo/sidr >>>> _______________________________________________ >>>> sidr mailing list >>>> sidr@ietf.org >>>> https://www.ietf.org/mailman/listinfo/sidr >>>> _______________________________________________ >>>> sidr mailing list >>>> sidr@ietf.org >>>> https://www.ietf.org/mailman/listinfo/sidr >>> _______________________________________________ >>> sidr mailing list >>> sidr@ietf.org >>> https://www.ietf.org/mailman/listinfo/sidr >>>=20 >>=20 >> --=20 >> With Feudalism, it's your Count that votes. >>=20 >>=20 >=20 --=20 With Feudalism, it's your Count that votes. From randy@psg.com Tue May 22 14:25:08 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7E4021F85E5 for ; Tue, 22 May 2012 14:25:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.294 X-Spam-Level: X-Spam-Status: No, score=-2.294 tagged_above=-999 required=5 tests=[AWL=0.305, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oVJgrU-e3BWa for ; Tue, 22 May 2012 14:25:08 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id 5CEB721F85C7 for ; Tue, 22 May 2012 14:25:08 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1SWwZm-000AXK-P2; Tue, 22 May 2012 21:25:06 +0000 Date: Wed, 23 May 2012 06:25:05 +0900 Message-ID: From: Randy Bush To: Matt Lepinski In-Reply-To: <4FBBB6D1.9000008@bbn.com> References: <24B20D14B2CD29478C8D5D6E9CBB29F60F70A267@Hermes.columbia.ads.sparta.com> <24B20D14B2CD29478C8D5D6E9CBB29F625F0975D@Hermes.columbia.ads.sparta.com> <4FBBB6D1.9000008@bbn.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: sidr@ietf.org Subject: Re: [sidr] request for agenda items for interim meeting 6 Jun X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 May 2012 21:25:08 -0000 > In my opinion the biggest open issue in the bgpsec protocol draft is the > confederation issue that we discussed at the previous interim. (That is, > if we don't include AS4_Path or AS_Path in a bgpsec signed update, then > we need to somehow encode the information that would be in the > AS_confed_sequence segments of the AS_Path.) i thought we were cheerily dumping as_confed_seq and thereby getting rid of the last sequence. essentially o you are at the border about to send to an external peer o stepping back down the sigs, possibly zero times o there will be a sig from an external peer to the confed as o strip off all sigs subsequent to that one, if any o sign from the confed as to the external peer randy From mlepinski@bbn.com Tue May 22 14:46:27 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49D1021F8694 for ; Tue, 22 May 2012 14:46:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wBFpvb4kK-Ur for ; Tue, 22 May 2012 14:46:26 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id C76A621F8674 for ; Tue, 22 May 2012 14:46:26 -0700 (PDT) Received: from mail.bbn.com ([128.33.0.48]:38443) by smtp.bbn.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1SWwtv-0007Nf-V1; Tue, 22 May 2012 17:45:55 -0400 Received: from dhcp89-089-205.bbn.com ([128.89.89.205]) by mail.bbn.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1SWwuP-0001MT-LG; Tue, 22 May 2012 17:46:25 -0400 Message-ID: <4FBC0936.7000905@bbn.com> Date: Tue, 22 May 2012 17:46:30 -0400 From: Matt Lepinski User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Randy Bush References: <24B20D14B2CD29478C8D5D6E9CBB29F60F70A267@Hermes.columbia.ads.sparta.com> <24B20D14B2CD29478C8D5D6E9CBB29F625F0975D@Hermes.columbia.ads.sparta.com> <4FBBB6D1.9000008@bbn.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: sidr@ietf.org Subject: Re: [sidr] request for agenda items for interim meeting 6 Jun X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 May 2012 21:46:27 -0000 Randy, Personally, I'm fine with the solution you outlined. However, I didn't think that everyone in the room for the last interim was on-board with this. That being said, I wasn't in the room, so I'm not a good one to gauge consensus (or lack there of) ... I guess it wasn't clear to me from the minutes whether or not this issue was resolved, so I didn't stick into the -03 version of the document. Note: If this issue is indeed resolved, then I'm happy to put the solution in the -04 version of the document. Other than confeds are there any other potentially open issues related to the removal of AS_Path? - Matt Lepinski On 5/22/2012 5:25 PM, Randy Bush wrote: >> In my opinion the biggest open issue in the bgpsec protocol draft is the >> confederation issue that we discussed at the previous interim. (That is, >> if we don't include AS4_Path or AS_Path in a bgpsec signed update, then >> we need to somehow encode the information that would be in the >> AS_confed_sequence segments of the AS_Path.) > i thought we were cheerily dumping as_confed_seq and thereby getting rid > of the last sequence. essentially > o you are at the border about to send to an external peer > o stepping back down the sigs, possibly zero times > o there will be a sig from an external peer to the confed as > o strip off all sigs subsequent to that one, if any > o sign from the confed as to the external peer > > randy > From randy@psg.com Tue May 22 14:55:57 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69E8821F85FD for ; Tue, 22 May 2012 14:55:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.324 X-Spam-Level: X-Spam-Status: No, score=-2.324 tagged_above=-999 required=5 tests=[AWL=0.275, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OMQSCuwJx6sW for ; Tue, 22 May 2012 14:55:57 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id 1D6B821F85F6 for ; Tue, 22 May 2012 14:55:57 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1SWx3b-000AbI-Ru; Tue, 22 May 2012 21:55:56 +0000 Date: Wed, 23 May 2012 06:55:54 +0900 Message-ID: From: Randy Bush To: Matt Lepinski In-Reply-To: <4FBC0936.7000905@bbn.com> References: <24B20D14B2CD29478C8D5D6E9CBB29F60F70A267@Hermes.columbia.ads.sparta.com> <24B20D14B2CD29478C8D5D6E9CBB29F625F0975D@Hermes.columbia.ads.sparta.com> <4FBBB6D1.9000008@bbn.com> <4FBC0936.7000905@bbn.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: sidr@ietf.org Subject: Re: [sidr] request for agenda items for interim meeting 6 Jun X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 May 2012 21:55:57 -0000 > However, I didn't think that everyone in the room for the last interim > was on-board with this. ^logical well, i definitely look forward to reading a bright(er) idea on list. randy From kotikalapudi.sriram@nist.gov Tue May 22 15:13:21 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7778021F86BA for ; Tue, 22 May 2012 15:13:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P4kJ8Sf01LCX for ; Tue, 22 May 2012 15:13:20 -0700 (PDT) Received: from wsget1.nist.gov (wsget1.nist.gov [129.6.13.150]) by ietfa.amsl.com (Postfix) with ESMTP id 761D221F86B9 for ; Tue, 22 May 2012 15:13:20 -0700 (PDT) Received: from WSXGHUB1.xchange.nist.gov (129.6.18.96) by wsget1.nist.gov (129.6.13.150) with Microsoft SMTP Server (TLS) id 14.1.355.2; Tue, 22 May 2012 18:13:15 -0400 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB1.xchange.nist.gov ([129.6.18.96]) with mapi; Tue, 22 May 2012 18:13:19 -0400 From: "Sriram, Kotikalapudi" To: "sidr@ietf.org" Date: Tue, 22 May 2012 18:13:17 -0400 Thread-Topic: [sidr] request for agenda items for interim meeting 6 Jun Thread-Index: Ac04Mx70Ri2o/4iWR9KMsHd3oHXVtQAKqZ7Q Message-ID: References: <24B20D14B2CD29478C8D5D6E9CBB29F60F70A267@Hermes.columbia.ads.sparta.com> <24B20D14B2CD29478C8D5D6E9CBB29F625F0975D@Hermes.columbia.ads.sparta.com> <4FBBB6D1.9000008@bbn.com> In-Reply-To: <4FBBB6D1.9000008@bbn.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Cc: "Sandra Murphy \(Sandra.Murphy@sparta.com\)" Subject: Re: [sidr] request for agenda items for interim meeting 6 Jun X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 May 2012 22:13:21 -0000 In addition to the items suggested so far, I think we should also spend some time on performance considerations and resource sizing requirements for a BGPSEC router. Some of the performance and resource sizing questions are: Q1: What is an acceptable convergence time after a BGPSEC peering session reset? (See Wes George's question (in Paris) and some thoughts shared by Geoff with me below.) Q2: What degree of peering is reasonable to assume for various router scenarios such as Provider Edge (PE), Route Reflector (RR), Route Server (RS), etc.? (The convergence time and the RIB size would naturally depend on the number of BGPSEC peering sessions that the PE, RR, or RS needs to handle.) Q3: Is there any difference in how the RIBs (RIB-in, RIB-out, etc.) are managed at a RR or RS as compared to how it is done at the PE router? Q4: Is a large percentage of the clients of an RS consists of stub routers, i.e., they do not require signed updates in receive direction? I did get some inputs on PE and RR peering degrees from a large Tier 1 ISP and used them in my RIB modeling work earlier. It would be good to revisit this and try to get a good handle on such measurements for PE, RR, and also RS. See slide 4 of this study (I did about a year ago) for the measurement numbers I got from the large Tier 1 ISP. http://www.nist.gov/itl/antd/upload/BGPSEC_RIB_Estimation.pdf They shared the numbers for their typical PE and RR. (They actually did not share # peerings exactly but simply the measurements of the # total paths and the # unique prefixes at their PE and their RR.) I have the following notes to tease a discussion based on some earlier questions/conversations at the Paris meeting: Wes George (question at the Paris SIDR meeting): Are the 30 sec and 70 sec type of numbers (for convergence after BGPSEC peering reset) small enough? May not be. (This question followed my presentation: http://www.ietf.org/proceedings/83/slides/slides-83-sidr-7.pdf ) As a counter point, Geoff shared the following with me during a coffee break (in Paris): [Note: I think I am stating the intent of his comments correctly; I request Geoff to jump in if this does not capture accurately enough what he shared with me.] The way to think about those delays is that the data packets would traverse a possibly suboptimal path for the period of T seconds or minutes -- whatever the BGPSEC re-convergence delay number is -- but they are not dropped on the floor. That is a property of BGP. The data packets may incur a small extra delay due to the suboptimal path for that (BGPSEC re-convergence) period, and most of the time users don't even notice that extra data packet delay (if any) at the application layer. Sriram From randy@psg.com Tue May 22 16:12:06 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E669121F86B6 for ; Tue, 22 May 2012 16:12:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.349 X-Spam-Level: X-Spam-Status: No, score=-2.349 tagged_above=-999 required=5 tests=[AWL=0.250, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VKrbMbnI9jZh for ; Tue, 22 May 2012 16:12:06 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id C4F5D21F869D for ; Tue, 22 May 2012 16:12:01 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1SWyFE-000AoH-NC for sidr@ietf.org; Tue, 22 May 2012 23:12:01 +0000 Date: Wed, 23 May 2012 08:11:59 +0900 Message-ID: From: Randy Bush To: sidr wg list User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Subject: [sidr] docco changes from minutes X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 May 2012 23:12:07 -0000 so i reviewed the minutes from last month, looking for what i had to hack in the docs i edit. i found very little. essentially A prudent operator will pre-provision each router's 'next' key in the RPKI so that, in case of compromise of the current key, there is no propagation delay for provisioning the new key. and The operator should be aware that BGPsec, as any other policy change, can cause traffic shifts in their network. And, as with normal policy shift practice, a prudent operator has tools and methods to predict, measure, modify, etc. surely there was more. help!!! randy From wesley.george@twcable.com Wed May 23 05:34:40 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4729621F8712 for ; Wed, 23 May 2012 05:34:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.463 X-Spam-Level: X-Spam-Status: No, score=-0.463 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kjwAP-J3E+uA for ; Wed, 23 May 2012 05:34:39 -0700 (PDT) Received: from cdpipgw02.twcable.com (cdpipgw02.twcable.com [165.237.59.23]) by ietfa.amsl.com (Postfix) with ESMTP id A629D21F8711 for ; Wed, 23 May 2012 05:34:39 -0700 (PDT) X-SENDER-IP: 10.136.163.12 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.75,645,1330923600"; d="scan'208";a="368125200" Received: from unknown (HELO PRVPEXHUB03.corp.twcable.com) ([10.136.163.12]) by cdpipgw02.twcable.com with ESMTP/TLS/RC4-MD5; 23 May 2012 08:34:01 -0400 Received: from PRVPEXVS03.corp.twcable.com ([10.136.163.26]) by PRVPEXHUB03.corp.twcable.com ([10.136.163.12]) with mapi; Wed, 23 May 2012 08:34:38 -0400 From: "George, Wes" To: Randy Bush , sidr wg list Date: Wed, 23 May 2012 08:34:37 -0400 Thread-Topic: [sidr] docco changes from minutes Thread-Index: Ac04cFDv4ybcE6SsRPG8meLoD8GUOAAbrc0w Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sidr] docco changes from minutes X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 May 2012 12:34:40 -0000 > -----Original Message----- > From: sidr-bounces@ietf.org [mailto:sidr-bounces@ietf.org] On Behalf Of > Randy Bush > > so i reviewed the minutes from last month, looking for what i had to hack= in > the docs i edit. > surely there was more. help!!! > [WEG] I have some notes implying I owe you text, but one of them is a bit c= ryptic through the filter of waiting too long after the meeting to look at = it, perhaps it'll make sense if we both stare at it? Send Randy text about *why* you should drop invalid Origin ops/ BGP Sec ops Text - Deploy (upgrade code), apply policy just to tag with a community, then do analysis to ensure it's doing what you expect, then deploy policy to actually do things like drop invalid, prefer = valid over unknown, etc." I think the former is reference to a comment I made saying that if we were = recommending (SHOULD? Or MUST?) that invalid be dropped, rather than simply= de-preffed, we needed to spend some time explaining why (what badness can = ensue if you don't drop). You wanted text, but I'm not totally sure that I = know the complete rationale well enough to supply said text. Is it just a m= atter of the risk of eventually using an invalid route if the better option= s go away, or is there more to it? The latter looks to me like a deployment guideline to address the concerns = that I think Brian brought up about OV/BGPSec potentially creating non-triv= ial changes to routing during deployment. I can flesh that text out a bit i= f people agree that it's useful to add. Thanks, Wes George This E-mail and any of its attachments may contain Time Warner Cable propri= etary information, which is privileged, confidential, or subject to copyrig= ht belonging to Time Warner Cable. This E-mail is intended solely for the u= se of the individual or entity to which it is addressed. If you are not the= intended recipient of this E-mail, you are hereby notified that any dissem= ination, distribution, copying, or action taken in relation to the contents= of and attachments to this E-mail is strictly prohibited and may be unlawf= ul. If you have received this E-mail in error, please notify the sender imm= ediately and permanently delete the original and any copy of this E-mail an= d any printout. From randy@psg.com Wed May 23 06:51:11 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D49FD21F84FB for ; Wed, 23 May 2012 06:51:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.37 X-Spam-Level: X-Spam-Status: No, score=-2.37 tagged_above=-999 required=5 tests=[AWL=0.229, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q5RWYi+fA2g6 for ; Wed, 23 May 2012 06:51:11 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id 79B1521F847F for ; Wed, 23 May 2012 06:51:11 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1SXBy2-000DgN-9L; Wed, 23 May 2012 13:51:10 +0000 Date: Wed, 23 May 2012 22:51:09 +0900 Message-ID: From: Randy Bush To: "George, Wes" In-Reply-To: References: User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: sidr wg list Subject: Re: [sidr] docco changes from minutes X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 May 2012 13:51:12 -0000 > Send Randy text about *why* you should drop invalid i actually understand this. it's the jgs paris aha. thanks! if you have a roa 10.0.0.0/16-24 42 and you get announcements 10.0.0.0/16 42 10.0.666.0/24 666 if you do not drop the invalid 10.0.666.0/24, then longest match will send packets to 666 > Origin ops/ BGP Sec ops > Text - Deploy (upgrade code), > apply policy just to tag with a community, > then do analysis to ensure it's doing what you expect, > then deploy policy to actually do things like drop invalid, > prefer valid over unknown, etc." this i do not follow. > The latter looks to me like a deployment guideline to address the > concerns that I think Brian brought up about OV/BGPSec potentially > creating non-trivial changes to routing during deployment. I can flesh > that text out a bit if people agree that it's useful to add. i think i covered that with the new traffic paragraph. thanks!!! randy From randy@psg.com Wed May 23 15:08:55 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D60F11E80B3 for ; Wed, 23 May 2012 15:08:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.388 X-Spam-Level: X-Spam-Status: No, score=-2.388 tagged_above=-999 required=5 tests=[AWL=0.211, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GMfaBBT3Zd3E for ; Wed, 23 May 2012 15:08:55 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id 1701D11E8098 for ; Wed, 23 May 2012 15:08:55 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1SXJjg-000F7F-Uo; Wed, 23 May 2012 22:08:53 +0000 Date: Thu, 24 May 2012 07:08:51 +0900 Message-ID: From: Randy Bush To: "Murphy, Sandra" In-Reply-To: <24B20D14B2CD29478C8D5D6E9CBB29F60F70A267@Hermes.columbia.ads.sparta.com> References: <24B20D14B2CD29478C8D5D6E9CBB29F60F70A267@Hermes.columbia.ads.sparta.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: "sidr@ietf.org" Subject: Re: [sidr] request for agenda items for interim meeting 6 Jun X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 May 2012 22:08:55 -0000 > (1) AS_PATH > > There was one agenda topic that we never directly addressed at the 30 > Apr meeting. That topic was the absence of the AS_PATH attribute from > the bgpsec protocol. (The info normally contained in the AS_PATH is > contained in the bgpsec attributes.) well, actually, the discussion in april was walking around many of the implications thereof. it is hard to discuss "do we keep/replace AS[4]_PATH" as it is abstract and draws deep philosophical discourse with no hard handles on technical decision points. otoh, i would be really interested in hearing/discussing if anyone sees any show-stoppers to the current draft doing so. i am amused that the current draft says, in the intro, 2. Every AS listed in the AS_Path attribute of the update explicitly authorized the advertisement of the route to the subsequent AS in the AS_Path. when there is no bgpsec as_path. :) > The absence of the AS_PATH did come up in discussing other topics (see > the minutes), but we did not discuss it directly. see above > (2) router private key provisioning. > > In the interim in San Diego, there were requests (from operators) that > guidance to operators of how to provision a router with the needed > keys would be a good idea. We had some discussion in the Paris > meeting of two drafts discussing provisioning the routers with their > needed private keys. There's also been a recent flurry of discussion > on the list. no comments on the new version of draft-ietf-sidr-rtr-keying-00.txt. would appreciate some now or we can ask for wglc. there have been no comments on list to confed and aliasing. may we call them done? randy From internet-drafts@ietf.org Wed May 23 15:19:48 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC10521F84D5; Wed, 23 May 2012 15:19:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.525 X-Spam-Level: X-Spam-Status: No, score=-102.525 tagged_above=-999 required=5 tests=[AWL=0.074, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XcSuRhx52cOU; Wed, 23 May 2012 15:19:48 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A64621F849A; Wed, 23 May 2012 15:19:48 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.02 Message-ID: <20120523221948.15070.48061.idtracker@ietfa.amsl.com> Date: Wed, 23 May 2012 15:19:48 -0700 Cc: sidr@ietf.org Subject: [sidr] I-D Action: draft-ietf-sidr-origin-ops-16.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 May 2012 22:19:49 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Secure Inter-Domain Routing Working G= roup of the IETF. Title : RPKI-Based Origin Validation Operation Author(s) : Randy Bush Filename : draft-ietf-sidr-origin-ops-16.txt Pages : 11 Date : 2012-05-23 Deployment of RPKI-based BGP origin validation has many operational considerations. This document attempts to collect and present them. It is expected to evolve as RPKI-based origin validation is deployed and the dynamics are better understood. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sidr-origin-ops-16.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-sidr-origin-ops-16.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-sidr-origin-ops/ From internet-drafts@ietf.org Wed May 23 15:44:25 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7719211E80DE; Wed, 23 May 2012 15:44:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.533 X-Spam-Level: X-Spam-Status: No, score=-102.533 tagged_above=-999 required=5 tests=[AWL=0.066, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ISUss5JOMh-b; Wed, 23 May 2012 15:44:25 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13EBC11E80D6; Wed, 23 May 2012 15:44:25 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.02 Message-ID: <20120523224425.20538.30643.idtracker@ietfa.amsl.com> Date: Wed, 23 May 2012 15:44:25 -0700 Cc: sidr@ietf.org Subject: [sidr] I-D Action: draft-ietf-sidr-bgpsec-ops-05.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 May 2012 22:44:25 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Secure Inter-Domain Routing Working G= roup of the IETF. Title : BGPsec Operational Considerations Author(s) : Randy Bush Filename : draft-ietf-sidr-bgpsec-ops-05.txt Pages : 9 Date : 2012-05-23 Deployment of the BGPsec architecture and protocols has many operational considerations. This document attempts to collect and present them. It is expected to evolve as BGPsec is formalized and initially deployed. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sidr-bgpsec-ops-05.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-sidr-bgpsec-ops-05.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-sidr-bgpsec-ops/ From wjhns1@hardakers.net Wed May 23 16:04:57 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77EE021F8577 for ; Wed, 23 May 2012 16:04:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uidWnd5Cjmoc for ; Wed, 23 May 2012 16:04:56 -0700 (PDT) Received: from mail.hardakers.net (unknown [IPv6:2001:470:1f00:187::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9860421F8573 for ; Wed, 23 May 2012 16:04:56 -0700 (PDT) Received: from localhost (unknown [IPv6:2001:470:1f00:187:62d8:19ff:fed4:c8b6]) by mail.hardakers.net (Postfix) with ESMTPSA id 71C75BB0; Wed, 23 May 2012 16:04:55 -0700 (PDT) From: Wes Hardaker To: Brian Dickson References: Date: Wed, 23 May 2012 16:04:54 -0700 In-Reply-To: (Brian Dickson's message of "Mon, 7 May 2012 14:58:31 -0400") Message-ID: <0l4nr6pkh5.fsf@wjh.hardakers.net> User-Agent: Gnus/5.130004 (Ma Gnus v0.4) Emacs/23.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Cc: sidr wg list Subject: Re: [sidr] sidrKeys and algorithms for Updates - feasibility analysis? (was Re: RPKI and private keys) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 May 2012 23:04:57 -0000 Brian Dickson writes: Hi Brian, I believe I understand your system as functionally creating an BGPSEC_Path_Signatures attribute with a algorithm/signature set that is based off of adding random numbers to the signature field(s) instead of adding cryptographically generated hashes. IE, we end up with something like this being received by a RP: |----------------------| | AS Number 1 | | Random Bytes from #1 | |----------------------| | AS Number 2 | | Random Bytes from #2 | |----------------------| | ... | This obviously greatly simplifies the diagram from the -protocol document section 3, but is sufficient for the discussion. The point being is that the BGPSEC_Path_Signatures is a list of ASes that the update has gone through. Roughly. Now, I'm all for updating the signature field to the fastest cryptography that meets the goals. We just need to agree on what the goals are, and how the resulting system is subject to attacks against those goals. So, lets consider a few things first: 1) A random number generation using a PRF is an interesting concept. And you're right, that if you assume a OOB cache that can verify the results is available, it'll offload much of the computation from the RP router. It's a worthy goal. [However, I'd argue that you could do that without changing the crypto as well; though it may still be a goal to lower the crypto cost of the OOB cache machine anyway] 2) A random number generator can only be compared against an existing system in turns of speed if it provides a similar amount of security, or the reduced security is an acceptable trade off for the speed gain. So, let me start with the concept of generating a nonce from a 32 bit generating PRF (or, as you stated, N instances of a 32 bit PRF). The problem with a 32 bit PRF and repeating it N times is that you don't get 32*N bits of entropy. You only get 32 bits. Specifically, if I'm given M random number Rs that were concatenated into a nonce, what do I have to do in order to predict the next 32*N bit field? Functionally, I need to figure out the original seed so that I can calculate the next 32*N bit field. But to calculate all the N fields, I really only need to sweep through the entire 32 bits looking for each of the N values, and work backward to the seed. Using a single 2.4GHz i7 core, I calculate it would take me 1.4 hours to search the entire 32bit space of random numbers looking backward for a seed. And much of that time is devoted just to initializing the random number generator, as producing 4 random numbers from a single seed (say you want to drop the first bunch of random numbers so it's harder for me to work backward) doesn't really help much, as the time needed only jumps to 1.5 hours to calculate 4 times the number of random numbers per seed. Then, you have to think about dictionary attacks. Storing an entire 32 bit set of random numbers generated from any 32-bit PRF requires only 16GB of storage, which is probably about the same as your ram limit without even going into disk-storage. The other problem with a simple PRF implementation (such as random() on most systems) is that it's not designed to be unreversable. IE, it's not designed to be cryptographically random and a random generator should be picked with care if you're using it for "proof" points of view. The end result of this, is that if you want to compare the speed of using random numbers against the speed of a real crypto function, you probably want to use a random number generator that won't let me predict the next one so easily. You need a random number generator that can output a much larger set of bits (IE, returns an number much bigger than a 32-bit int and requires a random seed (if any) much bigger than a 32-bit int). But lets say you come up with a random number generator that is strong enough to do what you want, and we agree the OOB problem can be solved in a way that everyone can be happy with (which I know is one of your statements: worry about it later; I'm not sure we can meet that goal either, but I'm even willing to worry about it later for the time being). IE, let us say that an architecture is found that allows an OOB or the router itself to authoritatively say "AS A really did use random number R a while ago". What does the resulting algorithm really let you say? 3) It lets you say that "AS A really did use random number R a while ago". IE, if you see this: |------| | AS A | | R | |------| | AS B | | Q | |------| | ... | Then you can say "yep, R was generated by A". 4) But.... does it really tell you that R was generated by A for that particular update path? It doesn't, right? All you know is that at some point in the past that AS A really did issue R. And possibly, assuming you keep a running memory cache to avoid replay, that it hasn't been seen yet so you should trust it. But, it may have been monitored/stolen from a different path instead, etc. EG, consider two trust caches that neither of which has seen AS R yet. They could both vouch for completely different paths advertised. 5) And in fact, there is no assurance that the random number generated matches anything. Thus any of the following paths would be treated the same: |------| |------| |------| |------| |------| | AS A | | AS A | | AS C | | AS A | | AS B | | R | | R | | N | | R | | Q | |------| |------| |------| |------| |------| | AS B | | AS C | | AS A | | Q | | Q | | R | |------| |------| |------| | ... | | ... | | ... | IE, any update with AS A/num=R in it will verify, but it won't matter if the order is added-to, reversed, deleted, dropped, etc. In the end, it doesn't really provide any of the protection services that the original cryptographically-chained algorithm provides: proof that the path wasn't modified. So, as I said, I'm all for a system that is equally secure, or provides the minimal security properties that we need at a much faster speed. But I fail to see how your system provides any security. At least as you've defined it to date. And even a 50,000x potential improvement you claimed doesn't seem to make me happier if we're getting nothing out of it. Even if we had a more secure random number generator in use (which would be likely slower than the existing one you were testing but still faster than a ECDSA signing system), I fail to see how the designed system with any random number generator will help out because we're loosing all the path binding properties that BGPSEC is trying to secure in the first place. -- Wes Hardaker SPARTA, Inc. From shane@castlepoint.net Wed May 23 17:54:47 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D2CA21F845F for ; Wed, 23 May 2012 17:54:47 -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=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v6Z67zVtMnwp for ; Wed, 23 May 2012 17:54:46 -0700 (PDT) Received: from dog.tcb.net (dog.tcb.net [64.78.150.133]) by ietfa.amsl.com (Postfix) with ESMTP id 9067111E8072 for ; Wed, 23 May 2012 17:54:46 -0700 (PDT) Received: by dog.tcb.net (Postfix, from userid 0) id F1DE8268063; Wed, 23 May 2012 18:54:45 -0600 (MDT) Received: from mbpw.castlepoint.net (174-29-213-45.hlrn.qwest.net [174.29.213.45]) (authenticated-user smtp) (TLSv1/SSLv3 AES128-SHA 128/128) by dog.tcb.net with SMTP; Wed, 23 May 2012 18:54:45 -0600 (MDT) (envelope-from shane@castlepoint.net) X-Avenger: version=0.7.8; receiver=dog.tcb.net; client-ip=174.29.213.45; client-port=57718; syn-fingerprint=65535:54:1:64:M1452,N,W1,N,N,T,S; data-bytes=0 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Shane Amante In-Reply-To: Date: Wed, 23 May 2012 18:54:29 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <43DD8E9F-2482-4E0E-B187-CCF7DE534D2E@castlepoint.net> References: <24B20D14B2CD29478C8D5D6E9CBB29F60F70A267@Hermes.columbia.ads.sparta.com> To: Randy Bush X-Mailer: Apple Mail (2.1278) Cc: "Murphy, Sandra" , "sidr@ietf.org" Subject: Re: [sidr] request for agenda items for interim meeting 6 Jun X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 May 2012 00:54:47 -0000 Randy, On May 23, 2012, at 4:08 PM, Randy Bush wrote: >> (1) AS_PATH >>=20 >> There was one agenda topic that we never directly addressed at the 30 >> Apr meeting. That topic was the absence of the AS_PATH attribute = from >> the bgpsec protocol. (The info normally contained in the AS_PATH is >> contained in the bgpsec attributes.) >=20 > well, actually, the discussion in april was walking around many of the > implications thereof. it is hard to discuss "do we keep/replace > AS[4]_PATH" as it is abstract and draws deep philosophical discourse > with no hard handles on technical decision points. >=20 > otoh, i would be really interested in hearing/discussing if anyone = sees > any show-stoppers to the current draft doing so. >=20 > i am amused that the current draft says, in the intro, >=20 > 2. Every AS listed in the AS_Path attribute of the update = explicitly > authorized the advertisement of the route to the subsequent AS = in > the AS_Path. >=20 > when there is no bgpsec as_path. :) >=20 >> The absence of the AS_PATH did come up in discussing other topics = (see >> the minutes), but we did not discuss it directly. >=20 > see above >=20 >> (2) router private key provisioning. >>=20 >> In the interim in San Diego, there were requests (from operators) = that >> guidance to operators of how to provision a router with the needed >> keys would be a good idea. We had some discussion in the Paris >> meeting of two drafts discussing provisioning the routers with their >> needed private keys. There's also been a recent flurry of discussion >> on the list. >=20 > no comments on the new version of draft-ietf-sidr-rtr-keying-00.txt. > would appreciate some now or we can ask for wglc. >=20 > there have been no comments on list to confed and aliasing. may we = call > them done? Can you expound more what you mean by "aliasing" above? Do you mean = local-as, etc. 'hacks' to the AS_PATH attribute? -shane= From randy@psg.com Wed May 23 17:56:03 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5596A11E8088 for ; Wed, 23 May 2012 17:56:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.403 X-Spam-Level: X-Spam-Status: No, score=-2.403 tagged_above=-999 required=5 tests=[AWL=0.196, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mBIiLZjpUO5j for ; Wed, 23 May 2012 17:56:03 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id EFC1B11E8072 for ; Wed, 23 May 2012 17:56:02 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1SXMLO-000G4D-Vq; Thu, 24 May 2012 00:55:59 +0000 Date: Thu, 24 May 2012 09:55:57 +0900 Message-ID: From: Randy Bush To: Shane Amante In-Reply-To: <43DD8E9F-2482-4E0E-B187-CCF7DE534D2E@castlepoint.net> References: <24B20D14B2CD29478C8D5D6E9CBB29F60F70A267@Hermes.columbia.ads.sparta.com> <43DD8E9F-2482-4E0E-B187-CCF7DE534D2E@castlepoint.net> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: "Murphy, Sandra" , "sidr@ietf.org" Subject: Re: [sidr] request for agenda items for interim meeting 6 Jun X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 May 2012 00:56:03 -0000 >> there have been no comments on list to confed and aliasing. may we >> call them done? > > Can you expound more what you mean by "aliasing" above? Do you mean > local-as, etc. yep randy From shane@castlepoint.net Wed May 23 18:04:51 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B039A21F8493 for ; Wed, 23 May 2012 18:04:51 -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=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hr8n8t6YckMz for ; Wed, 23 May 2012 18:04:51 -0700 (PDT) Received: from dog.tcb.net (dog.tcb.net [64.78.150.133]) by ietfa.amsl.com (Postfix) with ESMTP id 276B321F848A for ; Wed, 23 May 2012 18:04:51 -0700 (PDT) Received: by dog.tcb.net (Postfix, from userid 0) id EE19B268063; Wed, 23 May 2012 19:04:50 -0600 (MDT) Received: from mbpw.castlepoint.net (174-29-213-45.hlrn.qwest.net [174.29.213.45]) (authenticated-user smtp) (TLSv1/SSLv3 AES128-SHA 128/128) by dog.tcb.net with SMTP; Wed, 23 May 2012 19:04:50 -0600 (MDT) (envelope-from shane@castlepoint.net) X-Avenger: version=0.7.8; receiver=dog.tcb.net; client-ip=174.29.213.45; client-port=57922; syn-fingerprint=65535:54:1:64:M1452,N,W1,N,N,T,S; data-bytes=0 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Shane Amante In-Reply-To: Date: Wed, 23 May 2012 19:04:34 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <24B20D14B2CD29478C8D5D6E9CBB29F60F70A267@Hermes.columbia.ads.sparta.com> <43DD8E9F-2482-4E0E-B187-CCF7DE534D2E@castlepoint.net> To: Randy Bush X-Mailer: Apple Mail (2.1278) Cc: "Murphy, Sandra" , "sidr@ietf.org" Subject: Re: [sidr] request for agenda items for interim meeting 6 Jun X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 May 2012 01:04:51 -0000 On May 23, 2012, at 6:55 PM, Randy Bush wrote: >>> there have been no comments on list to confed and aliasing. may we >>> call them done? >>=20 >> Can you expound more what you mean by "aliasing" above? Do you mean >> local-as, etc. >=20 > yep That's strange. Why doesn't the following comment to the list back in = March of this year count as "no comments on list to ... aliasing"? http://www.ietf.org/mail-archive/web/sidr/current/msg04093.html -shane= From randy@psg.com Wed May 23 18:08:57 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9280F21F8567 for ; Wed, 23 May 2012 18:08:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.416 X-Spam-Level: X-Spam-Status: No, score=-2.416 tagged_above=-999 required=5 tests=[AWL=0.183, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TtI3f4zFJBCn for ; Wed, 23 May 2012 18:08:57 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id 1733A21F8550 for ; Wed, 23 May 2012 18:08:57 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1SXMXu-000G6x-Um; Thu, 24 May 2012 01:08:55 +0000 Date: Thu, 24 May 2012 10:08:53 +0900 Message-ID: From: Randy Bush To: Shane Amante In-Reply-To: References: <24B20D14B2CD29478C8D5D6E9CBB29F60F70A267@Hermes.columbia.ads.sparta.com> <43DD8E9F-2482-4E0E-B187-CCF7DE534D2E@castlepoint.net> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: "Murphy, Sandra" , "sidr@ietf.org" Subject: Re: [sidr] request for agenda items for interim meeting 6 Jun X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 May 2012 01:08:57 -0000 >>> Can you expound more what you mean by "aliasing" above? Do you mean >>> local-as, etc. >> yep > That's strange. Why doesn't the following comment to the list back in > March of this year count as "no comments on list to ... aliasing"? > http://www.ietf.org/mail-archive/web/sidr/current/msg04093.html it counted so much we spent a good bit of time on it in the april meeting. we, possibly foolishly, thought we had local convergence. randy From shane@castlepoint.net Wed May 23 18:14:48 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA90321F84D6 for ; Wed, 23 May 2012 18:14:48 -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=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ikZpsKPWs-74 for ; Wed, 23 May 2012 18:14:48 -0700 (PDT) Received: from dog.tcb.net (dog.tcb.net [64.78.150.133]) by ietfa.amsl.com (Postfix) with ESMTP id 43C9D21F842C for ; Wed, 23 May 2012 18:14:48 -0700 (PDT) Received: by dog.tcb.net (Postfix, from userid 0) id D89AC268063; Wed, 23 May 2012 19:14:47 -0600 (MDT) Received: from mbpw.castlepoint.net (174-29-213-45.hlrn.qwest.net [174.29.213.45]) (authenticated-user smtp) (TLSv1/SSLv3 AES128-SHA 128/128) by dog.tcb.net with SMTP; Wed, 23 May 2012 19:14:47 -0600 (MDT) (envelope-from shane@castlepoint.net) X-Avenger: version=0.7.8; receiver=dog.tcb.net; client-ip=174.29.213.45; client-port=57974; syn-fingerprint=65535:54:1:64:M1452,N,W1,N,N,T,S; data-bytes=0 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Shane Amante In-Reply-To: Date: Wed, 23 May 2012 19:14:28 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <5DDBFDFB-0A6B-4830-AAFF-361F8B7AA500@castlepoint.net> References: <24B20D14B2CD29478C8D5D6E9CBB29F60F70A267@Hermes.columbia.ads.sparta.com> <43DD8E9F-2482-4E0E-B187-CCF7DE534D2E@castlepoint.net> To: Randy Bush X-Mailer: Apple Mail (2.1278) Cc: "Murphy, Sandra" , "sidr@ietf.org" Subject: Re: [sidr] request for agenda items for interim meeting 6 Jun X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 May 2012 01:14:48 -0000 On May 23, 2012, at 7:08 PM, Randy Bush wrote: >>>> Can you expound more what you mean by "aliasing" above? Do you = mean >>>> local-as, etc. >>> yep >=20 >> That's strange. Why doesn't the following comment to the list back = in >> March of this year count as "no comments on list to ... aliasing"? >> http://www.ietf.org/mail-archive/web/sidr/current/msg04093.html >=20 > it counted so much we spent a good bit of time on it in the april > meeting. we, possibly foolishly, thought we had local convergence. For those of us who did not attend the April interim meeting, can you = point to where the list was asked if they agreed with the "local = convergence"? -shane= From randy@psg.com Wed May 23 18:18:46 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC26211E80A1 for ; Wed, 23 May 2012 18:18:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.427 X-Spam-Level: X-Spam-Status: No, score=-2.427 tagged_above=-999 required=5 tests=[AWL=0.172, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XkXKDHebwn0Q for ; Wed, 23 May 2012 18:18:46 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id 2A9AE11E80AB for ; Wed, 23 May 2012 18:18:46 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1SXMhQ-000G9d-7F; Thu, 24 May 2012 01:18:44 +0000 Date: Thu, 24 May 2012 10:18:43 +0900 Message-ID: From: Randy Bush To: Shane Amante In-Reply-To: <5DDBFDFB-0A6B-4830-AAFF-361F8B7AA500@castlepoint.net> References: <24B20D14B2CD29478C8D5D6E9CBB29F60F70A267@Hermes.columbia.ads.sparta.com> <43DD8E9F-2482-4E0E-B187-CCF7DE534D2E@castlepoint.net> <5DDBFDFB-0A6B-4830-AAFF-361F8B7AA500@castlepoint.net> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: "Murphy, Sandra" , "sidr@ietf.org" Subject: Re: [sidr] request for agenda items for interim meeting 6 Jun X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 May 2012 01:18:46 -0000 >>>>> Can you expound more what you mean by "aliasing" above? Do you >>>>> mean local-as, etc. >>>> yep >>> That's strange. Why doesn't the following comment to the list back >>> in March of this year count as "no comments on list to ... >>> aliasing"? >>> http://www.ietf.org/mail-archive/web/sidr/current/msg04093.html >> it counted so much we spent a good bit of time on it in the april >> meeting. we, possibly foolishly, thought we had local convergence. > For those of us who did not attend the April interim meeting, can you > point to where the list was asked if they agreed with the "local > convergence"? i thought i just did that :) but, to be fair, i find the minutes lacking, to be kind. and this is really the chairs' job. and i am nose deep in tex with a journal paper drealine tomorrow. randy From wjhns1@hardakers.net Wed May 23 18:22:34 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E55C111E80AE for ; Wed, 23 May 2012 18:22:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZXVNU6PXB3pp for ; Wed, 23 May 2012 18:22:34 -0700 (PDT) Received: from mail.hardakers.net (unknown [IPv6:2001:470:1f00:187::1]) by ietfa.amsl.com (Postfix) with ESMTP id 60CB711E8072 for ; Wed, 23 May 2012 18:22:34 -0700 (PDT) Received: from localhost (unknown [IPv6:2001:470:1f00:187:62d8:19ff:fed4:c8b6]) by mail.hardakers.net (Postfix) with ESMTPSA id 0E19FBAD; Wed, 23 May 2012 18:22:33 -0700 (PDT) From: Wes Hardaker To: Rob Austein References: <20120326173305.D1CB96E71B3@minas-ithil.hactrn.net> Date: Wed, 23 May 2012 18:22:33 -0700 In-Reply-To: <20120326173305.D1CB96E71B3@minas-ithil.hactrn.net> (Rob Austein's message of "Mon, 26 Mar 2012 19:33:05 +0200") Message-ID: <0lehqanzja.fsf@wjh.hardakers.net> User-Agent: Gnus/5.130004 (Ma Gnus v0.4) Emacs/23.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Cc: sidr@ietf.org Subject: Re: [sidr] sidrSlides for "RPKI Over BitTorrent" presentation X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 May 2012 01:22:35 -0000 Rob Austein writes: > For those who didn't get to see the end of the "RPKI Over BitTorrent" > presentation in today's SIDR meeting, the full slide deck is available > at > > http://www.ietf.org/proceedings/83/slides/slides-83-sidr-9.pdf > > and should be relatively self-explanatory. I've been thinking about this a lot lately, as it'll certainly be a challenge to ensure everyone is up to date. It doesn't matter whether you "should have pulled" or whether "you pull right when you get a request". Either way, there is an underlying data distribution problem. Most importantly, every bit of the repository needs to pretty much get everywhere. Rdist works well for trying not to duplicate data. Bittorrent works well for sharing the load, but either requires a lot of bittorrent start files (whatever they're called), which then becomes hard to syncronize; or a small number of bittorrent files (one per aggregation point) that indicate you need to refetch and entire .zip file even if you already have most of it anyway. But the real underlying problem is what I said above: every bit needs to get efficiently to every place, ideally at time of initial publication. This sure smells to me like a solution in need of multicast (or, more accurately, "deployed multicast") with a fall back to something like bittorrent for bootstrapping or when you've missed session data and can't recover. Multicast as a data stream would be much more efficient is collecting updates, although there are still issues that would need to be worked through like "how do you know you heard everything". Oh, and it only works if you multicast deployed to your site of course. -- Wes Hardaker SPARTA, Inc. From shane@castlepoint.net Wed May 23 20:50:42 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27C9B11E8079 for ; Wed, 23 May 2012 20:50:42 -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=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aLODsn7GQzpX for ; Wed, 23 May 2012 20:50:41 -0700 (PDT) Received: from dog.tcb.net (dog.tcb.net [64.78.150.133]) by ietfa.amsl.com (Postfix) with ESMTP id 51E0411E8073 for ; Wed, 23 May 2012 20:50:41 -0700 (PDT) Received: by dog.tcb.net (Postfix, from userid 0) id 00E78268063; Wed, 23 May 2012 21:50:40 -0600 (MDT) Received: from mbpw.castlepoint.net (174-29-213-45.hlrn.qwest.net [174.29.213.45]) (authenticated-user smtp) (TLSv1/SSLv3 AES128-SHA 128/128) by dog.tcb.net with SMTP; Wed, 23 May 2012 21:50:40 -0600 (MDT) (envelope-from shane@castlepoint.net) X-Avenger: version=0.7.8; receiver=dog.tcb.net; client-ip=174.29.213.45; client-port=59156; syn-fingerprint=65535:54:1:64:M1452,N,W1,N,N,T,S; data-bytes=0 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Shane Amante In-Reply-To: Date: Wed, 23 May 2012 21:50:18 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <98FF69F2-D786-4044-BE5E-30275B8DFF8F@castlepoint.net> References: <24B20D14B2CD29478C8D5D6E9CBB29F60F70A267@Hermes.columbia.ads.sparta.com> <43DD8E9F-2482-4E0E-B187-CCF7DE534D2E@castlepoint.net> <5DDBFDFB-0A6B-4830-AAFF-361F8B7AA500@castlepoint.net> To: Randy Bush X-Mailer: Apple Mail (2.1278) Cc: "Murphy, Sandra" , "sidr@ietf.org" Subject: Re: [sidr] request for agenda items for interim meeting 6 Jun X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 May 2012 03:50:42 -0000 On May 23, 2012, at 7:18 PM, Randy Bush wrote: >>>>>> Can you expound more what you mean by "aliasing" above? Do you >>>>>> mean local-as, etc. >>>>> yep >>>> That's strange. Why doesn't the following comment to the list back >>>> in March of this year count as "no comments on list to ... >>>> aliasing"? >>>> http://www.ietf.org/mail-archive/web/sidr/current/msg04093.html >>> it counted so much we spent a good bit of time on it in the april >>> meeting. we, possibly foolishly, thought we had local convergence. >> For those of us who did not attend the April interim meeting, can you >> point to where the list was asked if they agreed with the "local >> convergence"? >=20 > i thought i just did that :) >=20 > but, to be fair, i find the minutes lacking, to be kind. and this is > really the chairs' job. and i am nose deep in tex with a journal = paper > drealine tomorrow. I did look through the minutes and would agree that they are "lacking". = Although I see some discussion of the issue under the "AS aliasing = Replace AS Local AS" and "Replace as - AS migration" sections, on p. 7, = all I (mainly) see are: "One way is use pcount=3D0" and "Going to have = to be knob". It's unclear, to me, if there were (are?) other suggested = solutions made and/or how the pCount=3D0 suggestion is thought to work, = in practice. Are these written down in detail somewhere in a draft, = ideally, or in the mean time can the WG chairs, or folks who suggested = the idea(s), share them with the list? In particular, I'm curious about = the potential security implications of now allowing anyone to turn on = this "feature" and allowing them to dump anything they want into the = BGPSEC_Path_Signature attribute, (assuming that any ASN they put in with = pCount=3D0 in the BGPSEC_Path_Signature has valid signatures of course). Thanks, -shane= From rogaglia@cisco.com Thu May 24 02:07:11 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 093EF21F8620 for ; Thu, 24 May 2012 02:07:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id clKAoRySGyxt for ; Thu, 24 May 2012 02:07:10 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 3966321F861F for ; Thu, 24 May 2012 02:07:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rogaglia@cisco.com; l=8225; q=dns/txt; s=iport; t=1337850430; x=1339060030; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=TiXeeW+/bWpG8/g3aN9JyHdtd2I7K2syqqV785liBfI=; b=M7kKdJ4NAgWsXjGwZ/Wzs7Oe52WLt0NfjiNwO2yZj53hiJUau3UlJg05 Tti1AxqFx0x3JmdCx4FVmNNonx4gf7pUr0mlt/Ji+PZqU7j61h1hNiW2R 2++XmBKxl0HFzDe3Y1040VmVGnbz4sqTXLahp1MWcPMKjJiBCpBww6OKJ M=; X-Files: smime.p7s : 4389 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAMz4vU+tJV2c/2dsb2JhbABDtEWBB4IVAQEBAwEBAQEPAVsLBQsCAQhGAiULJQIEDgUOFIdmBQubMp90BIsJhDZgA441gR2FRo4MgWSCag X-IronPort-AV: E=Sophos;i="4.75,649,1330905600"; d="p7s'?scan'208";a="86260861" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-4.cisco.com with ESMTP; 24 May 2012 09:07:09 +0000 Received: from xhc-rcd-x08.cisco.com (xhc-rcd-x08.cisco.com [173.37.183.82]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id q4O9799b029422 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 24 May 2012 09:07:09 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.176]) by xhc-rcd-x08.cisco.com ([173.37.183.82]) with mapi id 14.02.0298.004; Thu, 24 May 2012 04:07:09 -0500 From: "Roque Gagliano (rogaglia)" To: Randy Bush Thread-Topic: [sidr] request for agenda items for interim meeting 6 Jun Thread-Index: AQHNOYyYvjibX2JpQE6E+bXyEGQkgg== Date: Thu, 24 May 2012 09:07:08 +0000 Message-ID: References: <24B20D14B2CD29478C8D5D6E9CBB29F60F70A267@Hermes.columbia.ads.sparta.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.147.19.50] x-tm-as-product-ver: SMEX-10.2.0.1135-6.800.1017-18924.004 x-tm-as-result: No--42.730800-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/signed; boundary="Apple-Mail-485-913458735"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Cc: "Murphy, Sandra" , "sidr@ietf.org" Subject: Re: [sidr] request for agenda items for interim meeting 6 Jun X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 May 2012 09:07:11 -0000 --Apple-Mail-485-913458735 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Randy, > well, actually, the discussion in april was walking around many of the > implications thereof. it is hard to discuss "do we keep/replace > AS[4]_PATH" as it is abstract and draws deep philosophical discourse > with no hard handles on technical decision points. I think you should remove the [4] from the discussion. 4 bytes ASN is = mandatory for BGPSEC speakers. So, there should be no AS4_PATH = attributes between BGPSEC routers to keep/replace. Roque > otoh, i would be really interested in hearing/discussing if anyone = sees > any show-stoppers to the current draft doing so. >=20 > i am amused that the current draft says, in the intro, >=20 > 2. Every AS listed in the AS_Path attribute of the update = explicitly > authorized the advertisement of the route to the subsequent AS = in > the AS_Path. >=20 > when there is no bgpsec as_path. :) >=20 >> The absence of the AS_PATH did come up in discussing other topics = (see >> the minutes), but we did not discuss it directly. >=20 > see above >=20 >> (2) router private key provisioning. >>=20 >> In the interim in San Diego, there were requests (from operators) = that >> guidance to operators of how to provision a router with the needed >> keys would be a good idea. We had some discussion in the Paris >> meeting of two drafts discussing provisioning the routers with their >> needed private keys. There's also been a recent flurry of discussion >> on the list. >=20 > no comments on the new version of draft-ietf-sidr-rtr-keying-00.txt. > would appreciate some now or we can ask for wglc. >=20 > there have been no comments on list to confed and aliasing. may we = call > them done? >=20 > randy > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr --Apple-Mail-485-913458735 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMXDCCBWYw ggROoAMCAQICEDG+eY7Bhz6hDsSIPCMJYUYwDQYJKoZIhvcNAQEFBQAwgd0xCzAJBgNVBAYTAlVT MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEg KGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24g Q2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMzAeFw0xMjA1MDgwMDAwMDBaFw0x MzA1MTEyMzU5NTlaMIIBEzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9S UEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMpOTgxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZh bGlkYXRlZDEzMDEGA1UECxMqRGlnaXRhbCBJRCBDbGFzcyAxIC0gTmV0c2NhcGUgRnVsbCBTZXJ2 aWNlMRcwFQYDVQQDFA5Sb3F1ZSBHYWdsaWFubzEhMB8GCSqGSIb3DQEJARYScm9nYWdsaWFAY2lz Y28uY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAs+CGyKUNmmBJ4PgQDVA8hF5E ByrcJ8BQ2C8mSv3vSZqCZNXAyte/JRsl11BJmqwdLiH6baDaJbBKRzNFfaf8Wwe8aS3QvqpHfKtU pYvn+EKseVnXsIKssRV2AwNODN6VMwSA72Jiolo3z4xeoeLw9X/CnFYTJa4AcGM1LKk+rMGTQlly XXl+qc7LeAd+wk7bKsUFmg4uCfvCDhVSQj25S5tnmFl5WPGD2u7QEa2WLkkL5nH+BEedZmRejRgP smmAxDfBX1FVTnCOgz75hNFlrnkYJfPCXLRyfPHvaIGP/NBz6TJbwB3YZSweYHxWAEMglqgRvqIW 3Tr5k5x9yyNYVQIDAQABo4HoMIHlMAkGA1UdEwQCMAAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcX ATAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1UdDwQEAwIF oDAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwFAYKYIZIAYb4RQEGBwQGFgROb25lMFAG A1UdHwRJMEcwRaBDoEGGP2h0dHA6Ly9pbmRjMWRpZ2l0YWxpZC1nMy1jcmwudmVyaXNpZ24uY29t L0luZEMxRGlnaXRhbElELUczLmNybDANBgkqhkiG9w0BAQUFAAOCAQEAuFfFZrObA9gprpHyG6cq O4UZjtN5/moV6mUYbt+ffGrXMbVt06vgnba7r6ldS5eWPQZZQtAAKKqweAmZY37ZcvVQwDsMXOMG 4+MN60sPVKwrrSQz9xXcImVCzBxFsq22S4el6pGx38xytsPgKw4cs8ZVxPLEjZtcOGnl8R8fak2g WyAMt8zkIxu/84zcobhcY5EEPJxYg9WKHi617fD6/jjQqvwvW4zi2XkIjw+HpZSwdPxk2+Cg6id4 SS6WlTwe90rdJmRrCP4gTXyJOdARR7hJU714lamn9QdQuPX7WLJXuMmoyrhvZZUeHpvodO/eNiO2 KvxMUu0uXWiDcDgTvzCCBu4wggXWoAMCAQICEHEVZgVK5JEhTem8RPms09wwDQYJKoZIhvcNAQEF BQAwgcoxCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVy aVNpZ24gVHJ1c3QgTmV0d29yazE6MDgGA1UECxMxKGMpIDE5OTkgVmVyaVNpZ24sIEluYy4gLSBG b3IgYXV0aG9yaXplZCB1c2Ugb25seTFFMEMGA1UEAxM8VmVyaVNpZ24gQ2xhc3MgMSBQdWJsaWMg UHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSAtIEczMB4XDTA5MDUwMTAwMDAwMFoXDTE5 MDQzMDIzNTk1OVowgd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0G A1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0 dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZh bGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIg Q0EgLSBHMzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAO3ER98qKB18Bmu71yEyyWwT j+mxjUFONPfaC+Nq+mWIIAsRE+mb4ElOi2/VAdBfDUeRilpMdD4/xpEJu0w0no1uoYJRYvdpdliW B6+eFBgHT1q9n9IxslQZc0ZqGUIR7BJzIY313DDN5dlWCjHFNm0pFJe9LdqJRxmI2EsEPeu2PGce dAATDdCG2pNn+DMDrho8a2l49sAsjuGDP3f5mf/+n1JawrSHCthsqUfBVCllQz5KwJYfwa33d69s sQRevsG2lC2XkC0n0rse6YNqhPbEsq4jBmUmpSdYKwcitG+mYkgad/LVUCeaKdOW+yj1uiR2YuOM Wev7btVCxL5Bx/UCAwEAAaOCArkwggK1MDQGCCsGAQUFBwEBBCgwJjAkBggrBgEFBQcwAYYYaHR0 cDovL29jc3AudmVyaXNpZ24uY29tMBIGA1UdEwEB/wQIMAYBAf8CAQAwcAYDVR0gBGkwZzBlBgtg hkgBhvhFAQcXATBWMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vY3BzMCoG CCsGAQUFBwICMB4aHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEwNAYDVR0fBC0wKzApoCeg JYYjaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS1nMy5jcmwwDgYDVR0PAQH/BAQDAgEGMG4G CCsGAQUFBwEMBGIwYKFeoFwwWjBYMFYWCWltYWdlL2dpZjAhMB8wBwYFKw4DAhoEFEtruSiWBgy7 0FI4mymsSweLIQUYMCYWJGh0dHA6Ly9sb2dvLnZlcmlzaWduLmNvbS92c2xvZ28xLmdpZjAuBgNV HREEJzAlpCMwITEfMB0GA1UEAxMWUHJpdmF0ZUxhYmVsNC0yMDQ4LTExODAdBgNVHQ4EFgQUeUdh CEH9OASiS+e1zPVD9kkrEfgwgfEGA1UdIwSB6TCB5qGB0KSBzTCByjELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTow OAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5 MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24g QXV0aG9yaXR5IC0gRzOCEQCLW3VWhFSFCwDPrzhIzrGkMA0GCSqGSIb3DQEBBQUAA4IBAQA5Tc9B mYG1qQW1UjjpOYSJbOQ0qFrn2GwJTCQaulmkhztzIfGTgc+/aGNaZ/41hSuhw12jSsI6Gd0w1sxN 7/HSgZfKVFpDvzeLeo4ZjQ9DqIzyr2CzFYqzlZw84J6zJ5ikNXIX5fwqXYfTig3C0UUq+MD0rCqT OtWuEnAI6/s74nfs6CtkNXbNutrg0csU1nFYm77VPn222egkxSRmTF2RH3azFz5/DcYhiS+zN7ih /1yybUneZVJC+w6I0u1KHb9L4/jMcvpIDmWOScjW+JmYO7eUPjFxBof6bFlTLtffK+1fYwCsFe0D uFUWjMZoA+ciqHMLsbyg2lJY3QoOf8GCMYIEizCCBIcCAQEwgfIwgd0xCzAJBgNVBAYTAlVTMRcw FQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7 MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMp MDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xh c3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMwIQMb55jsGHPqEOxIg8IwlhRjAJBgUr DgMCGgUAoIICbTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMjA1 MjQwOTA3MDhaMCMGCSqGSIb3DQEJBDEWBBTleTccy8q9M1G77PZY6ZRoRzcGxzCCAQMGCSsGAQQB gjcQBDGB9TCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0 cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFs aWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBD QSAtIEczAhAxvnmOwYc+oQ7EiDwjCWFGMIIBBQYLKoZIhvcNAQkQAgsxgfWggfIwgd0xCzAJBgNV BAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3Qg TmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNv bS9ycGEgKGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVy aVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMwIQMb55jsGHPqEOxIg8 IwlhRjANBgkqhkiG9w0BAQEFAASCAQCg9lovhqtt01uN/MoO1YQP1BGN6SbgdBxnA7UK7ix69LF7 BDVm0TRyeRMhKQ1e09sHF6APEpaOFm8A98FHngMm4YhKCU4l1IAbHrN5FRMrxeQstXdVFegS8nTi 0eK5xnoKLkqpoeMvc6ZZPIqb/OSKZ+pLCvtCTXeGqsGMjrJ6JWWRq7j6xs1m9tY+lo6htPMlqxtJ nLPtolqZ3wd2bc3gNY6AV/PmUrkXEvEIqCeAMGUKfajNYRHCc9RdUHrVBtKdfp0nxuouyuFxwQrD JFdWVKyGhOfvI64d+c+d8LKVa/r58ZN2NvQCOnbOlMbjkT6JpEVNaxuRB+gzI4I5eq9sAAAAAAAA --Apple-Mail-485-913458735-- From randy@psg.com Thu May 24 02:18:19 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C3DD21F85AA for ; Thu, 24 May 2012 02:18:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.437 X-Spam-Level: X-Spam-Status: No, score=-2.437 tagged_above=-999 required=5 tests=[AWL=0.162, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IqnepMv2cvK0 for ; Thu, 24 May 2012 02:18:19 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id 19F1B21F8584 for ; Thu, 24 May 2012 02:18:19 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1SXUBV-000HJJ-14; Thu, 24 May 2012 09:18:17 +0000 Date: Thu, 24 May 2012 18:18:15 +0900 Message-ID: From: Randy Bush To: "Roque Gagliano (rogaglia)" In-Reply-To: References: <24B20D14B2CD29478C8D5D6E9CBB29F60F70A267@Hermes.columbia.ads.sparta.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: sidr wg list Subject: Re: [sidr] request for agenda items for interim meeting 6 Jun X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 May 2012 09:18:19 -0000 >> well, actually, the discussion in april was walking around many of >> the implications thereof. it is hard to discuss "do we keep/replace >> AS[4]_PATH" as it is abstract and draws deep philosophical discourse >> with no hard handles on technical decision points. > > I think you should remove the [4] from the discussion. 4 bytes ASN is > mandatory for BGPSEC speakers. So, there should be no AS4_PATH > attributes between BGPSEC routers to keep/replace. i agree. but every time i say AS_PATH someone whacks me with AS4_PATH. maybe this is why i like the NO_EXPLICIT_PATH :) randy From rogaglia@cisco.com Thu May 24 05:16:27 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5145C21F85EA for ; Thu, 24 May 2012 05:16:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sd8y8UnC38vg for ; Thu, 24 May 2012 05:16:26 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id A10AA21F85DB for ; Thu, 24 May 2012 05:16:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rogaglia@cisco.com; l=6557; q=dns/txt; s=iport; t=1337861786; x=1339071386; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=UCu6pTZIbO3O+8nUUl0ASJShFZ6DKKeHT4mfJtnylrw=; b=bqgP9KzJxmEQFunJYizZyktXx5MvIM4oMusRMy+pJuYAmb7eaOY+DXRx cMI9FMASGPvA9llL2j0eW4haT8m7X9+ObBA74nwt5X/gRDiv29+C8o0Hz 4HLwle1coECDFQzGHtLYd2IxvCZUnfaCTYliqwitqijyMxseFb77+j5Pg o=; X-Files: smime.p7s : 4389 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAE0lvk+tJV2d/2dsb2JhbABDtEaBB4IVAQEBAwESAWYFCwIBCEYCMCUCBA4TFIdmBZsloAOPP2ADjjWBHYVGjgyBZIJq X-IronPort-AV: E=Sophos;i="4.75,649,1330905600"; d="p7s'?scan'208";a="86287888" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-5.cisco.com with ESMTP; 24 May 2012 12:16:26 +0000 Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id q4OCGQk3009492 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 24 May 2012 12:16:26 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.176]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.02.0298.004; Thu, 24 May 2012 07:16:25 -0500 From: "Roque Gagliano (rogaglia)" To: Randy Bush Thread-Topic: [sidr] request for agenda items for interim meeting 6 Jun Thread-Index: AQHNOYyYvjibX2JpQE6E+bXyEGQkgg== Date: Thu, 24 May 2012 12:16:25 +0000 Message-ID: <129CAA72-2AF5-4B61-A444-B8A67D1145D6@cisco.com> References: <24B20D14B2CD29478C8D5D6E9CBB29F60F70A267@Hermes.columbia.ads.sparta.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.147.19.50] x-tm-as-product-ver: SMEX-10.2.0.1135-6.800.1017-18924.006 x-tm-as-result: No--24.756600-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/signed; boundary="Apple-Mail-555-924815228"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Cc: sidr wg list Subject: Re: [sidr] request for agenda items for interim meeting 6 Jun X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 May 2012 12:16:27 -0000 --Apple-Mail-555-924815228 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii > i agree. but every time i say AS_PATH someone whacks me with AS4_PATH. > maybe this is why i like the NO_EXPLICIT_PATH :) well, you are normally consistent at asking people to read the documents :-). r. > randy --Apple-Mail-555-924815228 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMXDCCBWYw ggROoAMCAQICEDG+eY7Bhz6hDsSIPCMJYUYwDQYJKoZIhvcNAQEFBQAwgd0xCzAJBgNVBAYTAlVT MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEg KGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24g Q2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMzAeFw0xMjA1MDgwMDAwMDBaFw0x MzA1MTEyMzU5NTlaMIIBEzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9S UEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMpOTgxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZh bGlkYXRlZDEzMDEGA1UECxMqRGlnaXRhbCBJRCBDbGFzcyAxIC0gTmV0c2NhcGUgRnVsbCBTZXJ2 aWNlMRcwFQYDVQQDFA5Sb3F1ZSBHYWdsaWFubzEhMB8GCSqGSIb3DQEJARYScm9nYWdsaWFAY2lz Y28uY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAs+CGyKUNmmBJ4PgQDVA8hF5E ByrcJ8BQ2C8mSv3vSZqCZNXAyte/JRsl11BJmqwdLiH6baDaJbBKRzNFfaf8Wwe8aS3QvqpHfKtU pYvn+EKseVnXsIKssRV2AwNODN6VMwSA72Jiolo3z4xeoeLw9X/CnFYTJa4AcGM1LKk+rMGTQlly XXl+qc7LeAd+wk7bKsUFmg4uCfvCDhVSQj25S5tnmFl5WPGD2u7QEa2WLkkL5nH+BEedZmRejRgP smmAxDfBX1FVTnCOgz75hNFlrnkYJfPCXLRyfPHvaIGP/NBz6TJbwB3YZSweYHxWAEMglqgRvqIW 3Tr5k5x9yyNYVQIDAQABo4HoMIHlMAkGA1UdEwQCMAAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcX ATAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1UdDwQEAwIF oDAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwFAYKYIZIAYb4RQEGBwQGFgROb25lMFAG A1UdHwRJMEcwRaBDoEGGP2h0dHA6Ly9pbmRjMWRpZ2l0YWxpZC1nMy1jcmwudmVyaXNpZ24uY29t L0luZEMxRGlnaXRhbElELUczLmNybDANBgkqhkiG9w0BAQUFAAOCAQEAuFfFZrObA9gprpHyG6cq O4UZjtN5/moV6mUYbt+ffGrXMbVt06vgnba7r6ldS5eWPQZZQtAAKKqweAmZY37ZcvVQwDsMXOMG 4+MN60sPVKwrrSQz9xXcImVCzBxFsq22S4el6pGx38xytsPgKw4cs8ZVxPLEjZtcOGnl8R8fak2g WyAMt8zkIxu/84zcobhcY5EEPJxYg9WKHi617fD6/jjQqvwvW4zi2XkIjw+HpZSwdPxk2+Cg6id4 SS6WlTwe90rdJmRrCP4gTXyJOdARR7hJU714lamn9QdQuPX7WLJXuMmoyrhvZZUeHpvodO/eNiO2 KvxMUu0uXWiDcDgTvzCCBu4wggXWoAMCAQICEHEVZgVK5JEhTem8RPms09wwDQYJKoZIhvcNAQEF BQAwgcoxCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVy aVNpZ24gVHJ1c3QgTmV0d29yazE6MDgGA1UECxMxKGMpIDE5OTkgVmVyaVNpZ24sIEluYy4gLSBG b3IgYXV0aG9yaXplZCB1c2Ugb25seTFFMEMGA1UEAxM8VmVyaVNpZ24gQ2xhc3MgMSBQdWJsaWMg UHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSAtIEczMB4XDTA5MDUwMTAwMDAwMFoXDTE5 MDQzMDIzNTk1OVowgd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0G A1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0 dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZh bGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIg Q0EgLSBHMzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAO3ER98qKB18Bmu71yEyyWwT j+mxjUFONPfaC+Nq+mWIIAsRE+mb4ElOi2/VAdBfDUeRilpMdD4/xpEJu0w0no1uoYJRYvdpdliW B6+eFBgHT1q9n9IxslQZc0ZqGUIR7BJzIY313DDN5dlWCjHFNm0pFJe9LdqJRxmI2EsEPeu2PGce dAATDdCG2pNn+DMDrho8a2l49sAsjuGDP3f5mf/+n1JawrSHCthsqUfBVCllQz5KwJYfwa33d69s sQRevsG2lC2XkC0n0rse6YNqhPbEsq4jBmUmpSdYKwcitG+mYkgad/LVUCeaKdOW+yj1uiR2YuOM Wev7btVCxL5Bx/UCAwEAAaOCArkwggK1MDQGCCsGAQUFBwEBBCgwJjAkBggrBgEFBQcwAYYYaHR0 cDovL29jc3AudmVyaXNpZ24uY29tMBIGA1UdEwEB/wQIMAYBAf8CAQAwcAYDVR0gBGkwZzBlBgtg hkgBhvhFAQcXATBWMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vY3BzMCoG CCsGAQUFBwICMB4aHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEwNAYDVR0fBC0wKzApoCeg JYYjaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS1nMy5jcmwwDgYDVR0PAQH/BAQDAgEGMG4G CCsGAQUFBwEMBGIwYKFeoFwwWjBYMFYWCWltYWdlL2dpZjAhMB8wBwYFKw4DAhoEFEtruSiWBgy7 0FI4mymsSweLIQUYMCYWJGh0dHA6Ly9sb2dvLnZlcmlzaWduLmNvbS92c2xvZ28xLmdpZjAuBgNV HREEJzAlpCMwITEfMB0GA1UEAxMWUHJpdmF0ZUxhYmVsNC0yMDQ4LTExODAdBgNVHQ4EFgQUeUdh CEH9OASiS+e1zPVD9kkrEfgwgfEGA1UdIwSB6TCB5qGB0KSBzTCByjELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTow OAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5 MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24g QXV0aG9yaXR5IC0gRzOCEQCLW3VWhFSFCwDPrzhIzrGkMA0GCSqGSIb3DQEBBQUAA4IBAQA5Tc9B mYG1qQW1UjjpOYSJbOQ0qFrn2GwJTCQaulmkhztzIfGTgc+/aGNaZ/41hSuhw12jSsI6Gd0w1sxN 7/HSgZfKVFpDvzeLeo4ZjQ9DqIzyr2CzFYqzlZw84J6zJ5ikNXIX5fwqXYfTig3C0UUq+MD0rCqT OtWuEnAI6/s74nfs6CtkNXbNutrg0csU1nFYm77VPn222egkxSRmTF2RH3azFz5/DcYhiS+zN7ih /1yybUneZVJC+w6I0u1KHb9L4/jMcvpIDmWOScjW+JmYO7eUPjFxBof6bFlTLtffK+1fYwCsFe0D uFUWjMZoA+ciqHMLsbyg2lJY3QoOf8GCMYIEizCCBIcCAQEwgfIwgd0xCzAJBgNVBAYTAlVTMRcw FQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7 MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMp MDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xh c3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMwIQMb55jsGHPqEOxIg8IwlhRjAJBgUr DgMCGgUAoIICbTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMjA1 MjQxMjE2MjRaMCMGCSqGSIb3DQEJBDEWBBT5l0BF33XKfi7lbCnOymORmtCqfzCCAQMGCSsGAQQB gjcQBDGB9TCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0 cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFs aWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBD QSAtIEczAhAxvnmOwYc+oQ7EiDwjCWFGMIIBBQYLKoZIhvcNAQkQAgsxgfWggfIwgd0xCzAJBgNV BAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3Qg TmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNv bS9ycGEgKGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVy aVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMwIQMb55jsGHPqEOxIg8 IwlhRjANBgkqhkiG9w0BAQEFAASCAQBktmqnOOWlsNIwZcT4MB2aVHnN4NOZASKUcHZ23pmdc2Hh opVjlJi6vxYkv8wqcBv0twn7sTKKS/MGmT30H2QRtr3FnA692h44iNpZuU/rQqGAyX0g8cfCMWcn t64f2S5gnn3kDXJi+t7k6hNpZOg9Cruz0msvqmixXWdE1+SU30lVW7HVehXyBqRbtGopCW+n1tWD PMRrzHoVFSWPm9qdCIKHHvIh9gwBq25UEan/JYTpYiOG9RQwZQt3z0F5tptiUmGS1hEuwmK7L/gr MwLmto+xBQ4+7M/OGKJ3Wec0C2Fzsl1PleQZKcMnWPwX2Kyh17dJpLlGmMNN43MyK+hnAAAAAAAA --Apple-Mail-555-924815228-- From heas@shrubbery.net Thu May 24 06:18:32 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AFEA21F85DD for ; Thu, 24 May 2012 06:18:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id msMl93Yd1AEO for ; Thu, 24 May 2012 06:18:31 -0700 (PDT) Received: from guelah.shrubbery.net (guelah.shrubbery.net [198.58.5.1]) by ietfa.amsl.com (Postfix) with ESMTP id D46EA21F8570 for ; Thu, 24 May 2012 06:18:31 -0700 (PDT) Received: by guelah.shrubbery.net (Postfix, from userid 7053) id 5968B88EEF; Thu, 24 May 2012 13:18:31 +0000 (UTC) Date: Thu, 24 May 2012 13:18:31 +0000 From: heasley To: Wes Hardaker Message-ID: <20120524131831.GG35070@shrubbery.net> References: <20120326173305.D1CB96E71B3@minas-ithil.hactrn.net> <0lehqanzja.fsf@wjh.hardakers.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0lehqanzja.fsf@wjh.hardakers.net> X-PGPkey: http://www.shrubbery.net/~heas/public-key.asc X-note: live free, or die! X-homer: i just want to have a beer while i am caring. X-Claimation: an engineer needs a manager like a fish needs a bicycle X-reality: only YOU can put an end to the embarrassment that is Tom Cruise User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Rob Austein , sidr@ietf.org Subject: Re: [sidr] sidrSlides for "RPKI Over BitTorrent" presentation X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 May 2012 13:18:32 -0000 Wed, May 23, 2012 at 06:22:33PM -0700, Wes Hardaker: > Rob Austein writes: > > > For those who didn't get to see the end of the "RPKI Over BitTorrent" > > presentation in today's SIDR meeting, the full slide deck is available > > at > > > > http://www.ietf.org/proceedings/83/slides/slides-83-sidr-9.pdf > > > > and should be relatively self-explanatory. > > I've been thinking about this a lot lately, as it'll certainly be a > challenge to ensure everyone is up to date. It doesn't matter whether > you "should have pulled" or whether "you pull right when you get a > request". Either way, there is an underlying data distribution problem. > > Most importantly, every bit of the repository needs to pretty much get > everywhere. Rdist works well for trying not to duplicate data. > Bittorrent works well for sharing the load, but either requires a lot of > bittorrent start files (whatever they're called), which then becomes > hard to syncronize; or a small number of bittorrent files (one per > aggregation point) that indicate you need to refetch and entire .zip > file even if you already have most of it anyway. > > But the real underlying problem is what I said above: every bit needs to > get efficiently to every place, ideally at time of initial publication. I have probably have missed it, but has an IRR distribution protocol-like mechanism been discussed? See Merit's IRRd documentation, but simply its DNS serial number-like with record "add" and "delete" functions. I would expect this to be relative low impact and, at least with Merit's IRRd, to be low maintenance. And, regarding the comment about NNTP in the slides, I believe that is false. If one had a server used solely for sidr, rather than sidr + alt.whatever.stream.of.garbage, I believe it would be found to be very low maintenance. I haven't run a server for about 15 years, but I never had trouble with the software and certainly the software has likely improved rather than degraded. The problems were always hardware (disk) failures and the volume. > This sure smells to me like a solution in need of multicast (or, more > accurately, "deployed multicast") with a fall back to something like > bittorrent for bootstrapping or when you've missed session data and > can't recover. Multicast as a data stream would be much more efficient > is collecting updates, although there are still issues that would need > to be worked through like "how do you know you heard everything". Oh, > and it only works if you multicast deployed to your site of course. please, we do not want multicast as the only solution. does your noc know how to debug multicast forwarding problems? From wesley.george@twcable.com Thu May 24 06:19:59 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3184821F84E6 for ; Thu, 24 May 2012 06:19:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.963 X-Spam-Level: X-Spam-Status: No, score=-0.963 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NiDlqaMdk-Zn for ; Thu, 24 May 2012 06:19:58 -0700 (PDT) Received: from cdpipgw01.twcable.com (cdpipgw01.twcable.com [165.237.59.22]) by ietfa.amsl.com (Postfix) with ESMTP id 4443C21F84D8 for ; Thu, 24 May 2012 06:19:58 -0700 (PDT) X-SENDER-IP: 10.136.163.13 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.75,651,1330923600"; d="scan'208";a="385472299" Received: from unknown (HELO PRVPEXHUB04.corp.twcable.com) ([10.136.163.13]) by cdpipgw01.twcable.com with ESMTP/TLS/RC4-MD5; 24 May 2012 09:19:33 -0400 Received: from PRVPEXVS03.corp.twcable.com ([10.136.163.26]) by PRVPEXHUB04.corp.twcable.com ([10.136.163.13]) with mapi; Thu, 24 May 2012 09:19:57 -0400 From: "George, Wes" To: Randy Bush , "Murphy, Sandra" Date: Thu, 24 May 2012 09:19:56 -0400 Thread-Topic: [sidr] request for agenda items for interim meeting 6 Jun Thread-Index: Ac05MKfpRkK4d7aARcCMmxA94ZEx2wAfbtIQ Message-ID: References: <24B20D14B2CD29478C8D5D6E9CBB29F60F70A267@Hermes.columbia.ads.sparta.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "sidr@ietf.org" Subject: Re: [sidr] request for agenda items for interim meeting 6 Jun X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 May 2012 13:19:59 -0000 > From: sidr-bounces@ietf.org [mailto:sidr-bounces@ietf.org] On Behalf Of > Randy Bush > Sent: Wednesday, May 23, 2012 6:09 PM > To: Murphy, Sandra > Cc: sidr@ietf.org > Subject: Re: [sidr] request for agenda items for interim meeting 6 Jun > > > In the interim in San Diego, there were requests (from operators) that > > guidance to operators of how to provision a router with the needed > > keys would be a good idea. We had some discussion in the Paris > > meeting of two drafts discussing provisioning the routers with their > > needed private keys. There's also been a recent flurry of discussion > > on the list. > > no comments on the new version of draft-ietf-sidr-rtr-keying-00.txt. > would appreciate some now or we can ask for wglc. > [WEG] We're again having an interim collocated with NANOG, ostensibly to ga= in additional operator participation (as well as batch travel). However, in order to gain any benefit from the location, we probably need t= o publicize the interim on the NANOG list, though the window for doing it b= efore travel plans are made is probably closing/closed. Wasn't it on the NANOG agenda in SD? It's not this time... It may even be useful to have a set of questions to fire off in a lightning= talk regarding the things we plan to discuss in more detail over the cours= e of the interim, so that people who have opinions on the matters can weigh= in. Wes George This E-mail and any of its attachments may contain Time Warner Cable propri= etary information, which is privileged, confidential, or subject to copyrig= ht belonging to Time Warner Cable. This E-mail is intended solely for the u= se of the individual or entity to which it is addressed. If you are not the= intended recipient of this E-mail, you are hereby notified that any dissem= ination, distribution, copying, or action taken in relation to the contents= of and attachments to this E-mail is strictly prohibited and may be unlawf= ul. If you have received this E-mail in error, please notify the sender imm= ediately and permanently delete the original and any copy of this E-mail an= d any printout. From wjhns1@hardakers.net Thu May 24 06:36:53 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10ADA21F8681 for ; Thu, 24 May 2012 06:36:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lkfA0-EQQi42 for ; Thu, 24 May 2012 06:36:52 -0700 (PDT) Received: from mail.hardakers.net (unknown [IPv6:2001:470:1f00:187::1]) by ietfa.amsl.com (Postfix) with ESMTP id A21ED21F8683 for ; Thu, 24 May 2012 06:36:52 -0700 (PDT) Received: from localhost (unknown [IPv6:2001:470:1f00:187:62d8:19ff:fed4:c8b6]) by mail.hardakers.net (Postfix) with ESMTPSA id 24CC4BC0; Thu, 24 May 2012 06:36:52 -0700 (PDT) From: Wes Hardaker To: heasley References: <20120326173305.D1CB96E71B3@minas-ithil.hactrn.net> <0lehqanzja.fsf@wjh.hardakers.net> <20120524131831.GG35070@shrubbery.net> Date: Thu, 24 May 2012 06:36:51 -0700 In-Reply-To: <20120524131831.GG35070@shrubbery.net> (heasley's message of "Thu, 24 May 2012 13:18:31 +0000") Message-ID: <0lwr41lmz0.fsf@wjh.hardakers.net> User-Agent: Gnus/5.130004 (Ma Gnus v0.4) Emacs/23.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Cc: sidr@ietf.org, Rob Austein Subject: Re: [sidr] sidrSlides for "RPKI Over BitTorrent" presentation X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 May 2012 13:36:53 -0000 heasley writes: >> This sure smells to me like a solution in need of multicast (or, more >> accurately, "deployed multicast") with a fall back to something like >> bittorrent for bootstrapping or when you've missed session data and >> can't recover. Multicast as a data stream would be much more efficient >> is collecting updates, although there are still issues that would need >> to be worked through like "how do you know you heard everything". Oh, >> and it only works if you multicast deployed to your site of course. > > please, we do not want multicast as the only solution. does your noc know > how to debug multicast forwarding problems? I didn't say only :-) . In fact, I pointed at bittorrent as a backup. I simply said it would be more efficient when sending out *new* changes. -- Wes Hardaker SPARTA, Inc. From heas@shrubbery.net Thu May 24 06:47:19 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBACD21F8698 for ; Thu, 24 May 2012 06:47:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 65xQup3L8iLD for ; Thu, 24 May 2012 06:47:19 -0700 (PDT) Received: from guelah.shrubbery.net (guelah.shrubbery.net [198.58.5.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BE6C21F8690 for ; Thu, 24 May 2012 06:47:19 -0700 (PDT) Received: by guelah.shrubbery.net (Postfix, from userid 7053) id 3372A88FD7; Thu, 24 May 2012 13:47:19 +0000 (UTC) Date: Thu, 24 May 2012 13:47:19 +0000 From: heasley To: Wes Hardaker Message-ID: <20120524134719.GI35070@shrubbery.net> References: <20120326173305.D1CB96E71B3@minas-ithil.hactrn.net> <0lehqanzja.fsf@wjh.hardakers.net> <20120524131831.GG35070@shrubbery.net> <0lwr41lmz0.fsf@wjh.hardakers.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0lwr41lmz0.fsf@wjh.hardakers.net> X-PGPkey: http://www.shrubbery.net/~heas/public-key.asc X-note: live free, or die! X-homer: i just want to have a beer while i am caring. X-Claimation: an engineer needs a manager like a fish needs a bicycle X-reality: only YOU can put an end to the embarrassment that is Tom Cruise User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Rob Austein , sidr@ietf.org Subject: Re: [sidr] sidrSlides for "RPKI Over BitTorrent" presentation X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 May 2012 13:47:19 -0000 Thu, May 24, 2012 at 06:36:51AM -0700, Wes Hardaker: > I didn't say only :-) . In fact, I pointed at bittorrent as a backup. I > simply said it would be more efficient when sending out *new* changes. understood; i'm registering/re-enforcing that if that is developed it must not be the only mathod. From morrowc@ops-netman.net Thu May 24 10:15:19 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C529F21F8601 for ; Thu, 24 May 2012 10:15:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.856 X-Spam-Level: X-Spam-Status: No, score=-1.856 tagged_above=-999 required=5 tests=[AWL=0.745, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id toLvahiWTw7r for ; Thu, 24 May 2012 10:15:19 -0700 (PDT) Received: from mailserver.ops-netman.net (mailserver.ops-netman.net [IPv6:2001:470:e495:fade:5054:ff:fe79:69db]) by ietfa.amsl.com (Postfix) with ESMTP id 5339321F85F9 for ; Thu, 24 May 2012 10:15:18 -0700 (PDT) Received: from donkey.her.corp.google.com (unknown [IPv6:2620:0:100a:0:613b:556f:273b:7630]) (Authenticated sender: morrowc@OPS-NETMAN.NET) by mailserver.ops-netman.net (Postfix) with ESMTPSA id D1EA2320226; Thu, 24 May 2012 17:15:17 +0000 (UTC) Message-ID: <4FBE6CA5.3070600@ops-netman.net> Date: Thu, 24 May 2012 13:15:17 -0400 From: Chris Morrow User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: "sidr-chairs@tools.ietf.org" , sidr@ietf.org, sidr-ads@tools.ietf.org X-Enigmail-Version: 1.5pre Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [sidr] [INTERIM MEETING 6/6] Agenda update X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 May 2012 17:15:19 -0000 The 6/6/2012 (6/6/2012 for the EU folks or Jun 6 2012) meeting agenda looks like: * aspath not present - implications? - scudder's notes at previous meeting perhaps not all the bugs worked out/considerations made (not just tools, re-figuring the aspath on entrance/exit, are there other places where aspath is used/required? confeds is one example?) - rbush's noted method to deal with this in confeds * rekeying processes/procedures/implications - two drafts (roque + randy) one focused on router side key management (onboarding/etc) one focused on overall key change process (including rpki/routers/etc) * performance measurement bounds - andree/tim's interest in this publication point sizing and operations/sla requirements - what parts of the system get metric'd and why are those important? - sriram - sizing requirements for routers in defined roles in the network. Note that we have only ~5hrs for the meeting so we may have to stack-rank the above into the items we really WANT to get through first. also, this is available (and will be updated at): -chris (co-chair 1 of 3) [0]: wiki -> http://trac.tools.ietf.org/wg/sidr/trac/wiki/WikiStart From christopher.morrow@gmail.com Thu May 24 12:38:55 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D12911E80D6 for ; Thu, 24 May 2012 12:38:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VzY+sPIczC1f for ; Thu, 24 May 2012 12:38:55 -0700 (PDT) Received: from mail-gh0-f172.google.com (mail-gh0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id E59D111E80D5 for ; Thu, 24 May 2012 12:38:54 -0700 (PDT) Received: by ghbg16 with SMTP id g16so105255ghb.31 for ; Thu, 24 May 2012 12:38:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=2EQj+VquvGz4C3dzN25umPpmePGycc0/ukt8isnKbHg=; b=POlBY+V7IzrLZocIB3xlWHg3erq4AGt3D0V+dgk1kqLADzAnkXvecTtpBU5i0WGdAO f1vtWJ7Lnh+crez9+/7Jj60pP6UcdEpLH4/OE1hFExHKoVscGsuwo1SC3USJO1Y44XPe K56iSvGZNbMCppZDqwl7HCb4e5Cq6ZTut7vAdTTskE0DThOVDelmo7AekjMJpqtZitbf QEmQasCvt/ZNZNnWQc7Na78Rf3A+onrI24CA7k7Z97e41b79+rlnL/e2Uc4w7F3tPr2m AmKEhkuPqWzjHbB1ks2v5GGWfqivyRpl+8b/j/+vRzFsaFaAuoj53Nn7TtVhV2UEmRdK fHwA== MIME-Version: 1.0 Received: by 10.60.7.200 with SMTP id l8mr576988oea.52.1337888334543; Thu, 24 May 2012 12:38:54 -0700 (PDT) Sender: christopher.morrow@gmail.com Received: by 10.182.166.71 with HTTP; Thu, 24 May 2012 12:38:54 -0700 (PDT) In-Reply-To: References: <24B20D14B2CD29478C8D5D6E9CBB29F60F70A267@Hermes.columbia.ads.sparta.com> Date: Thu, 24 May 2012 15:38:54 -0400 X-Google-Sender-Auth: MJ-ixFT4yvMGt-sN0OHq4D0Yj9I Message-ID: From: Christopher Morrow To: "George, Wes" Content-Type: text/plain; charset=ISO-8859-1 Cc: "Murphy, Sandra" , "sidr@ietf.org" Subject: Re: [sidr] request for agenda items for interim meeting 6 Jun X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 May 2012 19:38:55 -0000 On Thu, May 24, 2012 at 9:19 AM, George, Wes wrote: > However, in order to gain any benefit from the location, we probably need to publicize the interim on the NANOG list, though the window for doing it before travel plans are made is probably closing/closed. > Wasn't it on the NANOG agenda in SD? It's not this time... I sent a note to the nanog list... hopefully folk will be able to attend either physically or virtually. From wjhns1@hardakers.net Thu May 24 12:44:06 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FE2611E80AF for ; Thu, 24 May 2012 12:44:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xEOWXWbKpoo5 for ; Thu, 24 May 2012 12:44:05 -0700 (PDT) Received: from mail.hardakers.net (unknown [IPv6:2001:470:1f00:187::1]) by ietfa.amsl.com (Postfix) with ESMTP id B8DC011E8086 for ; Thu, 24 May 2012 12:44:04 -0700 (PDT) Received: from localhost (unknown [IPv6:2001:470:1f00:187:62d8:19ff:fed4:c8b6]) by mail.hardakers.net (Postfix) with ESMTPSA id BBABBBF3; Thu, 24 May 2012 12:44:02 -0700 (PDT) From: Wes Hardaker To: heasley References: <20120326173305.D1CB96E71B3@minas-ithil.hactrn.net> <0lehqanzja.fsf@wjh.hardakers.net> <20120524131831.GG35070@shrubbery.net> <0lwr41lmz0.fsf@wjh.hardakers.net> <20120524134719.GI35070@shrubbery.net> Date: Thu, 24 May 2012 12:44:02 -0700 In-Reply-To: <20120524134719.GI35070@shrubbery.net> (heasley's message of "Thu, 24 May 2012 13:47:19 +0000") Message-ID: <0l8vghcqkd.fsf@wjh.hardakers.net> User-Agent: Gnus/5.130004 (Ma Gnus v0.4) Emacs/23.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Cc: sidr@ietf.org, Rob Austein Subject: Re: [sidr] sidrSlides for "RPKI Over BitTorrent" presentation X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 May 2012 19:44:06 -0000 heasley writes: > Thu, May 24, 2012 at 06:36:51AM -0700, Wes Hardaker: >> I didn't say only :-) . In fact, I pointed at bittorrent as a backup. I >> simply said it would be more efficient when sending out *new* changes. > > understood; i'm registering/re-enforcing that if that is developed it must > not be the only mathod. Agreed. If we can't do it over carrier pigeon, we have no real backup. -- Wes Hardaker SPARTA, Inc. From christopher.morrow@gmail.com Thu May 24 13:09:17 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71BB321F848C for ; Thu, 24 May 2012 13:09:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TUbJ0txh0E2e for ; Thu, 24 May 2012 13:09:16 -0700 (PDT) Received: from mail-gg0-f172.google.com (mail-gg0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id B3D0221F847C for ; Thu, 24 May 2012 13:09:07 -0700 (PDT) Received: by ggnc4 with SMTP id c4so215148ggn.31 for ; Thu, 24 May 2012 13:09:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=DlKNm7Yw5NtFqLELI1zk8MbWLmdUfVWLjyYe5bXe9Bs=; b=fjYUznH8B6Ho9RPo0IdmTRq61+Rbs071gHr7hzHiqIBtRagiH7LZQJihfTsR2u2ZFu quWlTx3Zmk731QfCb5c+LnWxzNaPNHzQNTixFkNBF/DTBvvCHiktOpkUgxV058k/Kfw4 28CAr2yme5kF3MOT8tVWSR7QyTBeeNlHtGobznYQz3d0PWHoh6vBDa3wG1mbYlQclFs/ WspXKXCddG37gNBysPLQXMkbE/MXHK6oY+fnFsU7MjZCeakqSsLJpqtpJ2Vlbv3DW2T3 2BNizLR5gSzEuQYMzkFrVIsduhWNQdzf/Gr6xX+RU3ntD14Tg/OyBHiCtPD3ptpqP4kz 01kQ== MIME-Version: 1.0 Received: by 10.60.24.7 with SMTP id q7mr668346oef.50.1337890147222; Thu, 24 May 2012 13:09:07 -0700 (PDT) Sender: christopher.morrow@gmail.com Received: by 10.182.166.71 with HTTP; Thu, 24 May 2012 13:09:07 -0700 (PDT) In-Reply-To: <4FBE6CA5.3070600@ops-netman.net> References: <4FBE6CA5.3070600@ops-netman.net> Date: Thu, 24 May 2012 16:09:07 -0400 X-Google-Sender-Auth: mVV8PotVftWr8tmvGOwsyc5Vpy0 Message-ID: From: Christopher Morrow To: Chris Morrow Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: sidr-ads@tools.ietf.org, "sidr-chairs@tools.ietf.org" , sidr@ietf.org Subject: Re: [sidr] [INTERIM MEETING 6/6] Agenda update X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 May 2012 20:09:17 -0000 An astute reader notes that the original message: (additionally, until a moment ago the wiki doc for the meeting had this text copied/pasted into it...) Had the original timing data (full-day), the space and other constraints dictate that the meeting will actually be 1300-1800 PDT. -chris On Thu, May 24, 2012 at 1:15 PM, Chris Morrow wrot= e: > The 6/6/2012 (6/6/2012 for the EU folks or Jun 6 2012) meeting agenda > looks like: > > =A0* aspath not present - implications? > =A0 =A0- scudder's notes at previous meeting > =A0 =A0 =A0perhaps not all the bugs worked out/considerations made > =A0 =A0 =A0(not just tools, re-figuring the aspath on entrance/exit, > =A0 =A0 =A0 are there other places where aspath is used/required? > =A0 =A0 =A0 confeds is one example?) > =A0 =A0- rbush's noted method to deal with this in confeds > > =A0* rekeying processes/procedures/implications > =A0 =A0- two drafts (roque + randy) > =A0 =A0 =A0one focused on router side key management (onboarding/etc) > =A0 =A0 =A0one focused on overall key change process (including > =A0 =A0 =A0 =A0rpki/routers/etc) > > =A0* performance measurement bounds > =A0 =A0- andree/tim's interest in this > =A0 =A0 =A0publication point sizing and operations/sla requirements > =A0 =A0- what parts of the system get metric'd and why are those importan= t? > =A0 =A0- sriram - sizing requirements for routers in defined roles in the > =A0 =A0 =A0network. > > Note that we have only ~5hrs for the meeting so we may have to > stack-rank the above into the items we really WANT to get through first. > > also, this is available (and will be updated at): > =A0 > > -chris > (co-chair 1 of 3) > > [0]: wiki -> http://trac.tools.ietf.org/wg/sidr/trac/wiki/WikiStart > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr From jgs@juniper.net Thu May 24 13:14:21 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C4CA21F856C for ; Thu, 24 May 2012 13:14:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NgNUVrnI-vM9 for ; Thu, 24 May 2012 13:14:20 -0700 (PDT) Received: from exprod7og108.obsmtp.com (exprod7og108.obsmtp.com [64.18.2.169]) by ietfa.amsl.com (Postfix) with ESMTP id BB02A21F8568 for ; Thu, 24 May 2012 13:14:16 -0700 (PDT) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob108.postini.com ([64.18.6.12]) with SMTP ID DSNKT76WmKCakQuc+amTY200rHoWUtMVvirA@postini.com; Thu, 24 May 2012 13:14:19 PDT Received: from [172.16.13.202] (172.16.13.202) by P-EMHUB01-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server id 8.3.213.0; Thu, 24 May 2012 13:13:17 -0700 MIME-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset="us-ascii" From: "John G. Scudder" In-Reply-To: <0lehqanzja.fsf@wjh.hardakers.net> Date: Thu, 24 May 2012 16:13:16 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: <95C20E9C-A4F8-4CC9-9BBA-38AA28A33353@juniper.net> References: <20120326173305.D1CB96E71B3@minas-ithil.hactrn.net> <0lehqanzja.fsf@wjh.hardakers.net> To: Wes Hardaker X-Mailer: Apple Mail (2.1278) Cc: Rob Austein , sidr@ietf.org Subject: Re: [sidr] sidrSlides for "RPKI Over BitTorrent" presentation X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 May 2012 20:14:21 -0000 Wes, On May 23, 2012, at 9:22 PM, Wes Hardaker wrote: > Bittorrent works well for sharing the load, but either requires a lot = of > bittorrent start files (whatever they're called), which then becomes > hard to syncronize; or a small number of bittorrent files (one per > aggregation point) that indicate you need to refetch and entire .zip > file even if you already have most of it anyway. I'm far from an expert on Bittorrent but I believe this is not right. A = .torrent file (what you called a "bittorrent start file") can contain = contain a list of files to be transferred, there's no mandate to zip = them into a single file first. Presumably the BT protocol is smart about = not transferring files you already have locally -- that's kind of the = whole point. Rob's "operational overview" slide makes it clear he's = imagining operating in the collection-of-files mode.=20 Probably there are some issues with this mode of operation too -- if you = list every single RPKI object individually then the size of the .torrent = file scales linearly in the size of the unauthenticated/ tree. This = seems likely to suck since I am guessing BT's normal operating regime is = to transfer small numbers of large files rather than potentially vast = numbers of relatively tiny files. The zip files Rob's slides talk about just contain the .torrent file and = manifest (which is also O(N) in the size of the tree, sigh). Speaking purely as a Bittorrent amateur + not the author of the slides! --John= From christopher.morrow@gmail.com Thu May 24 14:12:00 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EBBC21F8568 for ; Thu, 24 May 2012 14:12:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y-BjSSTZkxyH for ; Thu, 24 May 2012 14:11:55 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id A603A21F8564 for ; Thu, 24 May 2012 14:11:55 -0700 (PDT) Received: by obbeh20 with SMTP id eh20so280039obb.31 for ; Thu, 24 May 2012 14:11:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=kl2AYz4P8fgz03mTHAmXnHJp8NRs9fuXYZU/WDH1I1o=; b=DbQIlcuuN/pSZ0yWiwBABlbFY6gIjhVUdGORV+bEjdF0B8lFTJjKFvo84den/X7GpW YFdJfyAG4LmDyES/HFED6MxMXe93M3X+rWf8xtCc10T6wtJ1EMEI3RWjGFTcRZT0Eakf /T4RjSZOji2x/fDqCmpwcnmtdKJXPaAxPYK5NoAtx4hsU3B7nDyxPwi/TAkovUS6eLC6 EKNX1uEcUaco2N3Bvtoar/mIZDnEDBpoGlDdSfkWqcpJNb+U1QuuDL67//RzNhsWsDkp SedUirSff35RysSydwNyFMTOBq+0Jm8D4DZszfd7XTJLO3yuuErGifJLSzSq1NJ5HNcG E01w== MIME-Version: 1.0 Received: by 10.182.31.11 with SMTP id w11mr770829obh.64.1337893915213; Thu, 24 May 2012 14:11:55 -0700 (PDT) Sender: christopher.morrow@gmail.com Received: by 10.182.166.71 with HTTP; Thu, 24 May 2012 14:11:55 -0700 (PDT) In-Reply-To: <95C20E9C-A4F8-4CC9-9BBA-38AA28A33353@juniper.net> References: <20120326173305.D1CB96E71B3@minas-ithil.hactrn.net> <0lehqanzja.fsf@wjh.hardakers.net> <95C20E9C-A4F8-4CC9-9BBA-38AA28A33353@juniper.net> Date: Thu, 24 May 2012 17:11:55 -0400 X-Google-Sender-Auth: jyXuCA9rwyNdLYwaGusVYbtmPyY Message-ID: From: Christopher Morrow To: "John G. Scudder" Content-Type: text/plain; charset=ISO-8859-1 Cc: sidr@ietf.org, Rob Austein Subject: Re: [sidr] sidrSlides for "RPKI Over BitTorrent" presentation X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 May 2012 21:12:00 -0000 On Thu, May 24, 2012 at 4:13 PM, John G. Scudder wrote: > Wes, > > On May 23, 2012, at 9:22 PM, Wes Hardaker wrote: > >> Bittorrent works well for sharing the load, but either requires a lot of >> bittorrent start files (whatever they're called), which then becomes >> hard to syncronize; or a small number of bittorrent files (one per >> aggregation point) that indicate you need to refetch and entire .zip >> file even if you already have most of it anyway. > > I'm far from an expert on Bittorrent but I believe this is not right. A > .torrent file (what you called a "bittorrent start file") can contain > contain a list of files to be transferred, there's no mandate to zip them > into a single file first. Presumably the BT protocol is smart about not > transferring files you already have locally -- that's kind of the whole > point. Rob's "operational overview" slide makes it clear he's imagining > operating in the collection-of-files mode. per publication-point I think? So you have to collect N-thousand of these torrent files, and keep N-thousand torrent jobs running and keep state on N-thousand remote torrent files changing over time... some of this could be alleviated in many ways, worst case though is that. > Probably there are some issues with this mode of operation too -- if you > list every single RPKI object individually then the size of the .torrent > file scales linearly in the size of the unauthenticated/ tree. This seems > likely to suck since I am guessing BT's normal operating regime is to > transfer small numbers of large files rather than potentially vast numbers > of relatively tiny files. well, folk like fedora/ubuntu/etc offer full distributions over bittorrent ... I've not done a find . | wc -l on a system like this in a long time, but 4-8 gb over bittorrent for a few thousands of files seems to work fairly well for them. > The zip files Rob's slides talk about just contain the .torrent file and > manifest (which is also O(N) in the size of the tree, sigh). maybe looking at a bittorrent-like solution for intra-as distribution is interesting though? though that also seems (to me) to fall into 'local implementation' land, from the vendor/arms-dealer that sold me the solution. > Speaking purely as a Bittorrent amateur + not the author of the slides! me too, as an amateur of bittorrentz I mean. -chris > --John > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr From sra@hactrn.net Thu May 24 15:14:14 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1906311E80A3 for ; Thu, 24 May 2012 15:14:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kXiYapnbWqiB for ; Thu, 24 May 2012 15:14:13 -0700 (PDT) Received: from cyteen.hactrn.net (cyteen.hactrn.net [66.92.66.68]) by ietfa.amsl.com (Postfix) with ESMTP id 50AF311E8081 for ; Thu, 24 May 2012 15:14:13 -0700 (PDT) Received: from thrintun.hactrn.net (thrintun.hactrn.net [10.0.1.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "thrintun.hactrn.net", Issuer "Grunchweather Associates" (verified OK)) by cyteen.hactrn.net (Postfix) with ESMTPS id 31B302847F for ; Thu, 24 May 2012 22:14:10 +0000 (UTC) Received: from thrintun.hactrn.net (localhost [IPv6:::1]) by thrintun.hactrn.net (Postfix) with ESMTP id 0020017244 for ; Thu, 24 May 2012 18:14:09 -0400 (EDT) Date: Thu, 24 May 2012 18:14:09 -0400 From: Rob Austein To: sidr@ietf.org In-Reply-To: References: <20120326173305.D1CB96E71B3@minas-ithil.hactrn.net> <0lehqanzja.fsf@wjh.hardakers.net> <95C20E9C-A4F8-4CC9-9BBA-38AA28A33353@juniper.net> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/23.4 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20120524221410.0020017244@thrintun.hactrn.net> Subject: Re: [sidr] sidrSlides for "RPKI Over BitTorrent" presentation X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 May 2012 22:14:14 -0000 At Thu, 24 May 2012 17:11:55 -0400, Christopher Morrow wrote: > > On Thu, May 24, 2012 at 4:13 PM, John G. Scudder wrote: > > Wes, > > > > On May 23, 2012, at 9:22 PM, Wes Hardaker wrote: > > > >> Bittorrent works well for sharing the load, but either requires a lot of > >> bittorrent start files (whatever they're called), which then becomes > >> hard to syncronize; or a small number of bittorrent files (one per > >> aggregation point) that indicate you need to refetch and entire .zip > >> file even if you already have most of it anyway. The .zip file is just a wrapper around a .torrent file and an associated text manifest (which is mostly present to provide a stronger checksum than BitTorrent provides). .zip files over HTTPS are the control channel. RPKI data files over BitTorrent are the data channel. Confusing the two will lead to brain trauma. > > I'm far from an expert on Bittorrent but I believe this is not right. A > > .torrent file (what you called a "bittorrent start file") can contain > > contain a list of files to be transferred, there's no mandate to zip them > > into a single file first. Presumably the BT protocol is smart about not > > transferring files you already have locally -- that's kind of the whole > > point. Rob's "operational overview" slide makes it clear he's imagining > > operating in the collection-of-files mode. > > per publication-point I think? No. It's one torrent per gatherer. More precisely, one torrent at time per gatherer, as each gatherer generates a new torrent when it thinks it has a new batch of data that's worth sharing. > So you have to collect N-thousand of these torrent files, and keep > N-thousand torrent jobs running and keep state on N-thousand remote > torrent files changing over time... some of this could be alleviated > in many ways, worst case though is that. One torrent per gatherer at a time. The mechanism outlined in the slides uses HTTPS polling to distribute the .zip files containing the .torrent files. The HTTPS service used for this can be replicated via the usual techniques. So the clients poll the HTTPS servers to get the .torrent files, then use the .torrent files to retrieve the ten zillion little object files from the BitTorrent cloud. Note that BitTorrent is clever enough not to retrieve files it already has, so in effect this produces a similar effect to rsync (client only pulls what it needs), without imposing the same kind of server load. From randy@psg.com Thu May 24 16:05:17 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE57811E8081 for ; Thu, 24 May 2012 16:05:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.454 X-Spam-Level: X-Spam-Status: No, score=-2.454 tagged_above=-999 required=5 tests=[AWL=0.145, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UPKsHdIG5LLq for ; Thu, 24 May 2012 16:05:17 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id E333921F851E for ; Thu, 24 May 2012 16:05:16 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1SXh5l-000JVI-JS; Thu, 24 May 2012 23:05:13 +0000 Date: Fri, 25 May 2012 08:05:12 +0900 Message-ID: From: Randy Bush To: Chris Morrow In-Reply-To: <4FBE6CA5.3070600@ops-netman.net> References: <4FBE6CA5.3070600@ops-netman.net> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: sidr-ads@tools.ietf.org, "sidr-chairs@tools.ietf.org" , sidr@ietf.org Subject: Re: [sidr] [INTERIM MEETING 6/6] Agenda update X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 May 2012 23:05:18 -0000 > * aspath not present - implications? > - scudder's notes at previous meeting > perhaps not all the bugs worked out/considerations made > (not just tools, re-figuring the aspath on entrance/exit, > are there other places where aspath is used/required? > confeds is one example?) > - rbush's noted method to deal with this in confeds i am not sure i would clump all of this under aspath, but what the heck. can we please add shane's aliasing issue and hopefully this time we can make it clear in the minutes? also, the pfx-validate authors are currently polling eachother to ask for wglc on that doc, and it may be worth putting on the agenda so folk at the meeting can whack us appropriately. also, new revs of origin-ops and bgpsec-ops are out. folk may wish to comment. on all those docs, i do not think a 'presentation' is warranted. if folk have not read them, that is their problem and does not warrant the comic book edition being presented to waste the time of those who have done their homework. of course, presentations to clarify important and complex issues would be useful, if there are such. randy From Sandra.Murphy@sparta.com Thu May 24 16:06:28 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E582D11E8081 for ; Thu, 24 May 2012 16:06:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.569 X-Spam-Level: X-Spam-Status: No, score=-102.569 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9jAkY4rb7ATf for ; Thu, 24 May 2012 16:06:26 -0700 (PDT) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by ietfa.amsl.com (Postfix) with ESMTP id BA64121F8533 for ; Thu, 24 May 2012 16:06:18 -0700 (PDT) Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.14.4/8.14.4) with ESMTP id q4ON6InY018759; Thu, 24 May 2012 18:06:18 -0500 Received: from Hermes.columbia.ads.sparta.com ([157.185.80.107]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id q4ON6IXW028087; Thu, 24 May 2012 18:06:18 -0500 Received: from HERMES.columbia.ads.sparta.com ([2002:9db9:506b::9db9:506b]) by Hermes.columbia.ads.sparta.com ([::1]) with mapi id 14.01.0355.002; Thu, 24 May 2012 19:06:17 -0400 From: "Murphy, Sandra" To: "sidr@ietf.org" Thread-Topic: WGLC for draft-ietf-sidr-rpsl-sig-05.txt Thread-Index: Ac06Aa7Kr7T1RdCRRuOxqeSeKadtDg== Date: Thu, 24 May 2012 23:06:17 +0000 Message-ID: <24B20D14B2CD29478C8D5D6E9CBB29F625F109D5@Hermes.columbia.ads.sparta.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.185.63.118] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "draft-ietf-sidr-rpsl-sig@tools.ietf.org" Subject: [sidr] WGLC for draft-ietf-sidr-rpsl-sig-05.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 May 2012 23:06:28 -0000 The authors have stated that they believe that draft-ietf-sidr-rpsl-sig-05 = "Securing RPSL Objects with RPKI Signatures" is ready for a working group l= ast call.=0A= =0A= The draft can be accessed at http://tools.ietf.org/html/draft-ietf-sidr-rps= l-sig-05 and https://datatracker.ietf.org/doc/draft-ietf-sidr-rpsl-sig/=0A= =0A= This announces the beginning of the wglc. The last call will end on Friday= , 08 Jun 2012.=0A= =0A= Please judge whether you believe that this work is ready for publication an= d send any comments to the list.=0A= =0A= --Sandy, speaking as wg co-chair= From christopher.morrow@gmail.com Thu May 24 17:15:13 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5F3A21F845C for ; Thu, 24 May 2012 17:15:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yzNR922AhtI1 for ; Thu, 24 May 2012 17:15:13 -0700 (PDT) Received: from mail-gh0-f172.google.com (mail-gh0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id F0F7E21F845B for ; Thu, 24 May 2012 17:15:12 -0700 (PDT) Received: by ghbg16 with SMTP id g16so287041ghb.31 for ; Thu, 24 May 2012 17:15:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=PUgagSIyS6/jDcpHcJRfRyg/7RhvJ5c2rEYekIMfciI=; b=PZ8t3Cce4gsoAeRL1sdxZZHfc9ERmgW+lBhXhLsFr7rUGYmZw+Ok0wu8hNgYWcVXfn 2TxnHagGZgXf9Gt/RADT8WEYNYULII2ARX3keQw6WvdGvlP6QsRMiZF356ZDqKwSyuHb T0YkSX5xc5vXGumfjLLCmyO4TnfkLI3KMDtSRTi28y9cElFrCH88/ohOqBURWnZxsIe0 eoxqJF4i4gEpeafoTAADEmW27l+X7voMHozg5L87FSsB1AWlMwNJ3OfxA0V8HOxgZMtm 3Yd8WFhzFnn6pS+LWS/nRiEC7kOc7PhKaopTNeD9nRWqvQWm9jSoaA/WeezeowUnr6IT mhLg== MIME-Version: 1.0 Received: by 10.60.21.234 with SMTP id y10mr1383289oee.0.1337904912458; Thu, 24 May 2012 17:15:12 -0700 (PDT) Sender: christopher.morrow@gmail.com Received: by 10.182.166.71 with HTTP; Thu, 24 May 2012 17:15:12 -0700 (PDT) In-Reply-To: References: <4FBE6CA5.3070600@ops-netman.net> Date: Thu, 24 May 2012 20:15:12 -0400 X-Google-Sender-Auth: A0icEJPNgaNo0rdhYtCo0Mq2_hs Message-ID: From: Christopher Morrow To: Randy Bush Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Chris Morrow , sidr@ietf.org, "sidr-chairs@tools.ietf.org" , sidr-ads@tools.ietf.org Subject: Re: [sidr] [INTERIM MEETING 6/6] Agenda update X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 May 2012 00:15:13 -0000 On Thu, May 24, 2012 at 7:05 PM, Randy Bush wrote: >> =A0 * aspath not present - implications? >> =A0 =A0 - scudder's notes at previous meeting >> =A0 =A0 =A0 perhaps not all the bugs worked out/considerations made >> =A0 =A0 =A0 (not just tools, re-figuring the aspath on entrance/exit, >> =A0 =A0 =A0 =A0are there other places where aspath is used/required? >> =A0 =A0 =A0 =A0confeds is one example?) >> =A0 =A0 - rbush's noted method to deal with this in confeds > > i am not sure i would clump all of this under aspath, but what the heck. > > can we please add shane's aliasing issue and hopefully this time we can > make it clear in the minutes? sure thing, your name is there purely for placeholder... with the example that you thought you'd already worked through properly on-list + in-room. > also, the pfx-validate authors are currently polling eachother to ask > for wglc on that doc, and it may be worth putting on the agenda so folk > at the meeting can whack us appropriately. sure, keep in mind we have only 5 hrs. > also, new revs of origin-ops and bgpsec-ops are out. =A0folk may wish to > comment. list comments seem great for that, at least for starters. > on all those docs, i do not think a 'presentation' is warranted. =A0if > folk have not read them, that is their problem and does not warrant the > comic book edition being presented to waste the time of those who have > done their homework. =A0of course, presentations to clarify important and > complex issues would be useful, if there are such. sure. > randy > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr From randy@psg.com Thu May 24 18:29:16 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBA6F11E8098 for ; Thu, 24 May 2012 18:29:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.462 X-Spam-Level: X-Spam-Status: No, score=-2.462 tagged_above=-999 required=5 tests=[AWL=0.137, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q7C5Gdzpwk1m for ; Thu, 24 May 2012 18:29:16 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id 59AD211E808E for ; Thu, 24 May 2012 18:29:16 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1SXjL9-000KRM-2y; Fri, 25 May 2012 01:29:15 +0000 Date: Fri, 25 May 2012 10:29:13 +0900 Message-ID: From: Randy Bush To: Sandy Murphy In-Reply-To: <24B20D14B2CD29478C8D5D6E9CBB29F625F109D5@Hermes.columbia.ads.sparta.com> References: <24B20D14B2CD29478C8D5D6E9CBB29F625F109D5@Hermes.columbia.ads.sparta.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: draft-ietf-sidr-rpsl-sig@tools.ietf.org, sidr wg list Subject: Re: [sidr] WGLC for draft-ietf-sidr-rpsl-sig-05.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 May 2012 01:29:17 -0000 a quick read only. and sorry to wait for wglc, but that's life. at least i did not wait for ietf lc :) -- what is "RPSL"? it is not defined, nor is there a cite. -- 2.1. General Attributes, Meta Information in general, the format/syntax of the attribute part of many fields might be specified more precisely. have mercy on the people who are gonna write code to parse this stuff. e.g. time "is expressed as the decimal representation of an unsigned integer," but what is a decimal representation? ascii? (note that 3.1.4 does this) i'd even settle for examples. the "list of attribute names" needs to cite the enumeration of allowed names, kinda hard if RPSL has no cite. blah blah blah. -- 2.1. General Attributes, Meta Information 2. Reference to the certificate corresponding to the private key used to sign this object (field "c"). This is a URL of type "rsync" or "http(s)" that points to a specific resource certificate in an RPKI repository. needs a cite -- 2.1. General Attributes, Meta Information 3. Signature method (field "m"): what hash and signature algorithms were used to create the signature. The allowed algorithms which can be used for the signature are specified in [RFC6485]. sec folk, is this sufficiently specified that i can get a sure parse? i am three levels deep in rfcs and am still not sure. -- 2.1. General Attributes, Meta Information 5. The signed attributes (field "a"). This is a list of attribute names, separated by an ASCII "+" character (if more than one attribute is enumerated). The list must include any attribute at most once. as rfc 2622 has many attributes which are "multi-valued," which of the set is being signed? -- Optional fields of the "signature" attribute: is it a field or an attribute? both are used. decide. -- One applications for such a mechanism include the case of a route[6] object, where both the prefix owner's and the AS owner's signature is expected (if they are different parties). first, this is an example of why a mild grammar pass is needed. second, the trust model of the rpki ROA is that the AS owner does not attest. i do not remember the trust model in RPSL and am too lazy to try to figure it out as it cites 2725 which says 3. Routes should only be announced with the consent of the holder of the origin AS number of the announcement and with the consent of the holder of the address space. but i just do not have the energy to find how this is stated, validated, ... in this way too looong doc. but the difference in trust models could be at least noted. and i have this nagging worry that there is trouble waiting in that list of urls of certs. the references and referents are not necessarily stable and the resulting instability of a collection of them could be interesting. -- 2.2. Signed Attributes One can look at an RPSL object as an (ordered) set of attributes uh, i guess one could. but my memory is that the are not strictly ordered. you may want to say if and why ordering is actually important to this draft. -- 2.2. Signed Attributes trust model issue. what attributes may [not] be signed by, for example, a prefix cert? may prefix certs [not] sign different fields/attributes than AS certs? -- The type of the object determines the minimum set of attributes that MUST be signed. The signer MAY choose to sign additional attributes, in order to provide integrity protection for those attributes too. forward ref to sec 4 would be helpful here. is integrity the only assertion being made if for signed attributes beyond the minimum set? with multiple signers, is, for example, the AS holder signing an route: object really attesting to the holes: and org:? -- why not mandate the canonic syntax of 3.1.4 in the objects themselves? -- 3.2. Signature Creation 3. Arrange the selected attributes according to the selection sequence specified in the "a" field as above, omiting all attributes that will not be signed. attributes which may be repeated are gonna be fun. -- back to tex randy From terry.manderson@icann.org Thu May 24 18:35:28 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EAECC11E8080 for ; Thu, 24 May 2012 18:35:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bvfQGODfL0ro for ; Thu, 24 May 2012 18:35:27 -0700 (PDT) Received: from EXPFE100-1.exc.icann.org (expfe100-1.exc.icann.org [64.78.22.236]) by ietfa.amsl.com (Postfix) with ESMTP id 5053221F845D for ; Thu, 24 May 2012 18:35:27 -0700 (PDT) Received: from EXVPMBX100-1.exc.icann.org ([64.78.22.232]) by EXPFE100-1.exc.icann.org ([64.78.22.236]) with mapi; Thu, 24 May 2012 18:35:10 -0700 From: Terry Manderson To: "Murphy, Sandra" , "sidr@ietf.org" Date: Thu, 24 May 2012 18:35:08 -0700 Thread-Topic: [sidr] WGLC for draft-ietf-sidr-rpsl-sig-05.txt Thread-Index: Ac06Aa7Kr7T1RdCRRuOxqeSeKadtDgAFO9TD Message-ID: In-Reply-To: <24B20D14B2CD29478C8D5D6E9CBB29F625F109D5@Hermes.columbia.ads.sparta.com> Accept-Language: en-US Content-Language: en X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3420790508_16603591" MIME-Version: 1.0 Cc: "draft-ietf-sidr-rpsl-sig@tools.ietf.org" Subject: Re: [sidr] WGLC for draft-ietf-sidr-rpsl-sig-05.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 May 2012 01:35:28 -0000 --B_3420790508_16603591 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit These are my comments on the draft draft-ietf-sidr-rpsl-sig-05 In the Introduction (Para 3) it says: " A maintainer of such signed database objects MUST possess a relevant resource certificate which shows him/her as the legitimate holder of an Internet number resource" I'm afraid I'm confused on how you make the jump to saying a maintainer of RPSL objects has a resource certificate which lists the resources 'shows him/her as the legitimate holder.' There is no identity information in the resource certificate. Further (and in the Abstract) says " are done by the legitimate holder(s) of the internet resources". I think this is misaligned. Many legitimate resource holders (that aren't in the ISP game) outsource their routing 'stuff' and would probably palm off the creation of resource certs to someone else who might then hold the private key - so I would argue that the more correct approach here, is to say that: "modifications of such database objects are authorized by the holder(s) of the private key for the resource certificate that encompasses the the Internet resources mentioned in those objects." The second last sentence clarifies somewhat, but my point is that I don't see that the maintainer::Resource Holder::Private Key Holder is a simple straight line. (and I note that the mntner object has no additional handling, so in a way the mntner and the private key and resource cert in the 'signature:' attribute can be quite unrelated except for some IRR process to assert some relationship, somehow. Is/was there any discussion on why the mntner asserts no awareness of a signature or relevant published rescerts that may come into play over the objects it is responsible for?) Section 2.1, The new attribute signature looks to update RPSL (RFC2622) shouldn't a 'updates' in the RFC header? section 2.2, nit. "Allowing the maintainer an object to select the attributes that are covered by the digital signature achieves the goals established in Section 1." missing "of", should be: "Allowing the maintainer of an object to select the attributes that are covered by the digital signature achieves the goals established in Section 1." In Signature Creation (3.2) I would like to see a pointer to section 4. You have gone to the effort to provide a sensible list of the attributes in RPSL objects to sign over (which I like!), might as well highlight this to the reader in section 3 and also in the intro and abstract. For me this is an important piece. I think the security considerations section needs work. Your rightly point out that confidentiality (as a public object) is not a concern. I would like the "integrity of the RPSL object" reworded so that you are actually talking about the attributes (section 4) of the RPSL object which are signed over. There are no words about availability. I think it needs to be highlighted that signing the objects still does not guarantee any level availability or end to end integrity. It's whois. :-) Any object can be modified in transit (MiTM) to drop the signature attribute and modify the RPSL contents should an attacker wish to. Can you provide a set of actual examples in an appendix? I am most interested in seeing an example with the optional references to other parties certificates field 'o'. and additional signatures. (section 2.1, second number '2' bullet) For the most part I have no strong objections to this document moving forward. Cheers Terry On 25/05/12 9:06 AM, "Murphy, Sandra" wrote: > The authors have stated that they believe that draft-ietf-sidr-rpsl-sig-05 > "Securing RPSL Objects with RPKI Signatures" is ready for a working group last > call. > > The draft can be accessed at > http://tools.ietf.org/html/draft-ietf-sidr-rpsl-sig-05 and > https://datatracker.ietf.org/doc/draft-ietf-sidr-rpsl-sig/ > > This announces the beginning of the wglc. The last call will end on Friday, > 08 Jun 2012. > > Please judge whether you believe that this work is ready for publication and > send any comments to the list. > > --Sandy, speaking as wg co-chair > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr --B_3420790508_16603591 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIQAQYJKoZIhvcNAQcCoIIP8jCCD+4CAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC Dc0wggcDMIIF66ADAgECAhAPz2lJUZsAlD35l4oJxf0FMA0GCSqGSIb3DQEBBQUAMGIxCzAJ BgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2Vy dC5jb20xITAfBgNVBAMTGERpZ2lDZXJ0IEFzc3VyZWQgSUQgQ0EtMTAeFw0xMjAzMjcwMDAw MDBaFw0xNTAzMjcxMjAwMDBaMIGsMQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZvcm5p YTEXMBUGA1UEBxMOTWFyaW5hIGRlbCBSZXkxPDA6BgNVBAoTM0ludGVybmV0IENvcnBvcmF0 aW9uIGZvciBBc3NpZ25lZCBOYW1lcyBhbmQgTnVtYmVyczEXMBUGA1UECxMORE5TIE9wZXJh dGlvbnMxGDAWBgNVBAMTD1RlcnJ5IE1hbmRlcnNvbjCCASIwDQYJKoZIhvcNAQEBBQADggEP ADCCAQoCggEBAKRhZ4W3U6MnfS2woYEFCIyN+g1MNILokbUKk+PTl5mmK3QtWQxTSOu2sdzN xHMy6p2RoT9BMGOamttFq2WswSru6/7JT1TflytGaPHfK5kMP/pI47hmcwUEm9Z169I5ar7z BTiEAQA06cGKtgJ8XiiLFUIHLVuRq3WGxjnFTHlAHXY6mdgDT/ntAnoEvvPVm4XqUnjJiZTS ojzyr1q2RqFvyXs2blOARumDqvLI33yLGcUuaEL+A+hgodzM/fL4kdoy964mXvmEerpm4d4f Y/JfbRUWxc0Eomu9nwGFNk6ijO41qk+OIboct2qeA+5PPclXJNNHYVfzT2dyWfGgxaMCAwEA AaOCA2gwggNkMB8GA1UdIwQYMBaAFBUAEisTmLKZB+0e36K+Vw0rZwLNMB0GA1UdDgQWBBSz wvR2YXpP9XjS9cknMX5g3LM2jTAkBgNVHREEHTAbgRl0ZXJyeS5tYW5kZXJzb25AaWNhbm4u b3JnMA4GA1UdDwEB/wQEAwIFoDAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwfQYD VR0fBHYwdDA4oDagNIYyaHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0QXNzdXJl ZElEQ0EtMS5jcmwwOKA2oDSGMmh0dHA6Ly9jcmw0LmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydEFz c3VyZWRJRENBLTEuY3JsMIIBxQYDVR0gBIIBvDCCAbgwggG0BgpghkgBhv1sBAECMIIBpDA6 BggrBgEFBQcCARYuaHR0cDovL3d3dy5kaWdpY2VydC5jb20vc3NsLWNwcy1yZXBvc2l0b3J5 Lmh0bTCCAWQGCCsGAQUFBwICMIIBVh6CAVIAQQBuAHkAIAB1AHMAZQAgAG8AZgAgAHQAaABp AHMAIABDAGUAcgB0AGkAZgBpAGMAYQB0AGUAIABjAG8AbgBzAHQAaQB0AHUAdABlAHMAIABh AGMAYwBlAHAAdABhAG4AYwBlACAAbwBmACAAdABoAGUAIABEAGkAZwBpAEMAZQByAHQAIABD AFAALwBDAFAAUwAgAGEAbgBkACAAdABoAGUAIABSAGUAbAB5AGkAbgBnACAAUABhAHIAdAB5 ACAAQQBnAHIAZQBlAG0AZQBuAHQAIAB3AGgAaQBjAGgAIABsAGkAbQBpAHQAIABsAGkAYQBi AGkAbABpAHQAeQAgAGEAbgBkACAAYQByAGUAIABpAG4AYwBvAHIAcABvAHIAYQB0AGUAZAAg AGgAZQByAGUAaQBuACAAYgB5ACAAcgBlAGYAZQByAGUAbgBjAGUALjB3BggrBgEFBQcBAQRr MGkwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmRpZ2ljZXJ0LmNvbTBBBggrBgEFBQcwAoY1 aHR0cDovL2NhY2VydHMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0QXNzdXJlZElEQ0EtMS5jcnQw DAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOCAQEAYpwxK/KvdhbyQqrKp2ylMQpNzqVH ofo4hPILTnp/o+UyYVn6daWSilaV+XNBzE5Rm/f7ms2iA1zBzOvGv55pLH0n6lgIRTeuAGzf KIsPCwPvYQkkMAPXHzh9A44m19hvigTgOPNyjzcOTiHqwwCJSDTEZx17CEkrzQPq1vfG1Lvk +AWjEtxCsGmsuCHHaZjwQ8SsGI7W5cA1Y4RTcQf6S9eIpSsOwXIYdDgWq9Uhi/amW7ryW06Y GH7BHaitqgmm32MZuid3UzJUU6+Ljx7uGA9Fe6k1uPEHhaXTAoobPSpPdOgGmnxUCRQu2OI7 +I8vHiSe7DC/LmxEDC5kB+lUTjCCBsIwggWqoAMCAQICEAoE3yF0XU0rjOozcgUAUOkwDQYJ KoZIhvcNAQEFBQAwZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcG A1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBS b290IENBMB4XDTA2MTExMDAwMDAwMFoXDTIxMTExMDAwMDAwMFowYjELMAkGA1UEBhMCVVMx FTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEhMB8G A1UEAxMYRGlnaUNlcnQgQXNzdXJlZCBJRCBDQS0xMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEA6IItmfnKwkKVpYBzQHDSnlZUXKnE0kEGj8kz/E1FkVyBn+0snPgWWd+etSQV wpi5tHdJ3InECtqvy15r7a2wcTHrzzpADEZNk+yLejYIA6sMNP4YSYL+x8cxSIB8HqIPkg5Q ycaH6zY/2DDD/6b3+6LNb3Mj/qxWBZDwMiEWicZwiPkFl32jx0PdAug7Pe2xQaPtP77blUjE 7h6z8rwMK5nQxl0SQoHhg26Ccz8mSxSQrllmCsSNvtLOBq6thG9IhJtPQLnxTPKvmPv2zkBd XPao8S+v7Iki8msYZbHBc63X8djPHgp0XEK4aH631XcKJ1Z8D2KkPzIUYJX9BwSiCQIDAQAB o4IDbzCCA2swDgYDVR0PAQH/BAQDAgGGMDsGA1UdJQQ0MDIGCCsGAQUFBwMBBggrBgEFBQcD AgYIKwYBBQUHAwMGCCsGAQUFBwMEBggrBgEFBQcDCDCCAcYGA1UdIASCAb0wggG5MIIBtQYL YIZIAYb9bAEDAAQwggGkMDoGCCsGAQUFBwIBFi5odHRwOi8vd3d3LmRpZ2ljZXJ0LmNvbS9z c2wtY3BzLXJlcG9zaXRvcnkuaHRtMIIBZAYIKwYBBQUHAgIwggFWHoIBUgBBAG4AeQAgAHUA cwBlACAAbwBmACAAdABoAGkAcwAgAEMAZQByAHQAaQBmAGkAYwBhAHQAZQAgAGMAbwBuAHMA dABpAHQAdQB0AGUAcwAgAGEAYwBjAGUAcAB0AGEAbgBjAGUAIABvAGYAIAB0AGgAZQAgAEQA aQBnAGkAQwBlAHIAdAAgAEMAUAAvAEMAUABTACAAYQBuAGQAIAB0AGgAZQAgAFIAZQBsAHkA aQBuAGcAIABQAGEAcgB0AHkAIABBAGcAcgBlAGUAbQBlAG4AdAAgAHcAaABpAGMAaAAgAGwA aQBtAGkAdAAgAGwAaQBhAGIAaQBsAGkAdAB5ACAAYQBuAGQAIABhAHIAZQAgAGkAbgBjAG8A cgBwAG8AcgBhAHQAZQBkACAAaABlAHIAZQBpAG4AIABiAHkAIAByAGUAZgBlAHIAZQBuAGMA ZQAuMA8GA1UdEwEB/wQFMAMBAf8wfQYIKwYBBQUHAQEEcTBvMCQGCCsGAQUFBzABhhhodHRw Oi8vb2NzcC5kaWdpY2VydC5jb20wRwYIKwYBBQUHMAKGO2h0dHA6Ly93d3cuZGlnaWNlcnQu Y29tL0NBQ2VydHMvRGlnaUNlcnRBc3N1cmVkSURSb290Q0EuY3J0MIGBBgNVHR8EejB4MDqg OKA2hjRodHRwOi8vY3JsMy5kaWdpY2VydC5jb20vRGlnaUNlcnRBc3N1cmVkSURSb290Q0Eu Y3JsMDqgOKA2hjRodHRwOi8vY3JsNC5kaWdpY2VydC5jb20vRGlnaUNlcnRBc3N1cmVkSURS b290Q0EuY3JsMB0GA1UdDgQWBBQVABIrE5iymQftHt+ivlcNK2cCzTAfBgNVHSMEGDAWgBRF 66Kv9JLLgjEtUYunpyGd823IDzANBgkqhkiG9w0BAQUFAAOCAQEAhGFOQR64dgQqtbbvj/JV hbldVv4KmObkvWWKfUAp0/yxXUX9OrgqWzNLJFzNubTkc61hXXatdDOKZtUjr0wfcm5F2XVA u6I7z41JL8BBsOIpo1E4Q1CZFKwzBjViiX13qVIH5WwgV7aBum+8s8KU7XYCgNl8zoWoHOzH Q0pLsVfPcs7f9SU8yyJP/Z9S0TfLCLs4PuDVPm95Ca1bfDGzdzXD5GP5aAqYB+dGOHeE0j6X vAqgqKwlT0RukeHSWq9r7zAcjaNEQrMQiyP61+Y1dDesz+urWB/JiCP/NtQH6jRqR+qdlWye KU9T7eMrlSBOKs+WYHr4LIDwlVLOKZaBYjGCAfwwggH4AgEBMHYwYjELMAkGA1UEBhMCVVMx FTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEhMB8G A1UEAxMYRGlnaUNlcnQgQXNzdXJlZCBJRCBDQS0xAhAPz2lJUZsAlD35l4oJxf0FMAkGBSsO AwIaBQCgXTAjBgkqhkiG9w0BCQQxFgQUtVcaeD7w+GFPlHYarvMzwPSeUnMwGAYJKoZIhvcN AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTIwNTI1MDEzNTA4WjANBgkqhkiG 9w0BAQEFAASCAQA/ONe1UhIztuF7lBfWTvbsqpBQPl3kRVaARCQM4qTK4QR+TNpIHoMoIMOy 1YtEREmGj30gMt7xuSMP7kpq54mjYk3VLhzvVEgPzzzzrr45sMZPpWJMPCow7FEMviSiAgEL VDqbwVuBeaIVRC2JS4C31Zh4ZU535pdsdUU8CLGvEXO9CxBp9RCB/iZTS2sZKbWQAGeRfp7M JnDaZCzWoDW/J0x7BdR1rH77cQnA5KQ9oj7oDbCDSu3urczE1ox85zwgsCL1oA/gtndIqHiD bxfEYbRlnBfjHW6h65SPJpoQYSB+laVia+hF0JL6U4+8oCHr0K6xX+ERRh4lvRdGn+AC --B_3420790508_16603591-- From alexey.melnikov@isode.com Fri May 25 08:47:11 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76CF421F8646 for ; Fri, 25 May 2012 08:47:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.484 X-Spam-Level: X-Spam-Status: No, score=-102.484 tagged_above=-999 required=5 tests=[AWL=0.115, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ejqf1w5vpwiP for ; Fri, 25 May 2012 08:47:10 -0700 (PDT) Received: from rufus.isode.com (cl-125.lon-03.gb.sixxs.net [IPv6:2a00:14f0:e000:7c::2]) by ietfa.amsl.com (Postfix) with ESMTP id D650821F85C9 for ; Fri, 25 May 2012 08:47:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1337960829; d=isode.com; s=selector; i=@isode.com; bh=eON+914MT/mOHLBcnh8EmK/fVeJGa9rRTwHmxMspHQM=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=Wzqc85ffR0shjBud8KUOuA7ZqpzonksOxP27Chkn2tZLYJES7/XSbsZ8vAHnmDAavgg6xS U3SMnssmVmTSlHgMLVWSQy2MgJFgRBKYg1iSUNmvYCL4wJ2i3JdqmcJlG94U5GNRwofedI 8H5zqfippGjAiuB3SdE+EA1ez+RRkYg=; Received: from [172.16.1.29] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPSA id ; Fri, 25 May 2012 16:47:09 +0100 X-SMTP-Protocol-Errors: PIPELINING Message-ID: <4FBFA992.8020107@isode.com> Date: Fri, 25 May 2012 16:47:30 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 To: sidr wg MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [sidr] Date and type of the next (end of June/early July) interim X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 May 2012 15:47:11 -0000 Dear WG members, The WG needs to decide about the date and type of the next interim (after June 6th). The earlier proposal stated June 29th. Are people happy with this date or do they want to propose an alternative? Note that we are more flexible this time, because this is not tied to any other industry event. We also need to decide on whether this should be a physical interim with remote participants or fully virtual interim (e.g. everybody is using WebEx or something similar). Please reply to this message, sending your comments to the mailing list or directly to chairs (sidr-chairs@tools.ietf.org). Best Regards, Alexey, on behalf of SIDR chairs. From randy@psg.com Sat May 26 00:47:18 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0C9021F8613 for ; Sat, 26 May 2012 00:47:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.468 X-Spam-Level: X-Spam-Status: No, score=-2.468 tagged_above=-999 required=5 tests=[AWL=0.131, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e6-uGtwJIxrz for ; Sat, 26 May 2012 00:47:18 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id 27D3521F85BE for ; Sat, 26 May 2012 00:47:18 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1SYBiV-0000AO-OL; Sat, 26 May 2012 07:47:16 +0000 Date: Sat, 26 May 2012 16:47:14 +0900 Message-ID: From: Randy Bush To: Alexey Melnikov In-Reply-To: <4FBFA992.8020107@isode.com> References: <4FBFA992.8020107@isode.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: sidr wg Subject: Re: [sidr] Date and type of the next (end of June/early July) interim X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 May 2012 07:47:18 -0000 alexey, > The WG needs to decide about the date and type of the next interim > (after June 6th). The earlier proposal stated June 29th. Are people > happy with this date or do they want to propose an alternative? i doubt i would have all homework from 6 june done by the 29th. of course, i might be lucky and have none :) and, of course i can not speak for matt, who does the heavy lifting. if 6 june turns out to leave a lot to discuss that warrants the bandwidth, i'll fly to wherever for the 29th. otherwise, i'll probably skype-out to the webex's pstn gateway. randy From alexey.melnikov@isode.com Sat May 26 02:48:02 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56F7221F85E3 for ; Sat, 26 May 2012 02:48:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fyiKs5mhaviF for ; Sat, 26 May 2012 02:48:01 -0700 (PDT) Received: from rufus.isode.com (cl-125.lon-03.gb.sixxs.net [IPv6:2a00:14f0:e000:7c::2]) by ietfa.amsl.com (Postfix) with ESMTP id 6F78521F85E1 for ; Sat, 26 May 2012 02:48:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1338025679; d=isode.com; s=selector; i=@isode.com; bh=e/WBeR2EwOy15uJzQkLW5LUa4KgPzGQiRnroDYUfixw=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=WgDbQ5Y3hn+oh8xeQm9NQPAyxpqB7vmlIxINEYE+0QM8bsB6CDgN/JKKJl75fZNFapindO RHVEJ8w0LFId7B2VhEqTZ7ZjQjI79X1UHfZPy/nFd+XYWAYIrW0YY9hF6lK9s5lPK/MqKJ t+wjc15A8Bay+s8OSSxYx3P2CDhMPNE=; Received: from [188.28.250.94] (188.28.250.94.threembb.co.uk [188.28.250.94]) by rufus.isode.com (submission channel) via TCP with ESMTPSA id ; Sat, 26 May 2012 10:47:59 +0100 References: <4FBFA992.8020107@isode.com> In-Reply-To: Message-Id: X-Mailer: iPad Mail (9B206) From: Alexey Melnikov Date: Sat, 26 May 2012 10:47:49 +0100 To: Randy Bush MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Cc: sidr wg Subject: Re: [sidr] Date and type of the next (end of June/early July) interim X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 May 2012 09:48:02 -0000 Hi Randy, On 26 May 2012, at 08:47, Randy Bush wrote: > alexey, > >> The WG needs to decide about the date and type of the next interim >> (after June 6th). The earlier proposal stated June 29th. Are people >> happy with this date or do they want to propose an alternative? > > i doubt i would have all homework from 6 june done by the 29th. of > course, i might be lucky and have none :) and, of course i can not > speak for matt, who does the heavy lifting. Would you prefer a later date then, e.g. shortly after July 4th? > > if 6 june turns out to leave a lot to discuss that warrants the > bandwidth, i'll fly to wherever for the 29th. otherwise, i'll probably > skype-out to the webex's pstn gateway. > > randy From randy@psg.com Sat May 26 03:22:10 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA28D21F85D5 for ; Sat, 26 May 2012 03:22:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.474 X-Spam-Level: X-Spam-Status: No, score=-2.474 tagged_above=-999 required=5 tests=[AWL=0.125, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T015X6D7OwKM for ; Sat, 26 May 2012 03:22:10 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id 204F621F85AA for ; Sat, 26 May 2012 03:22:10 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1SYE8P-0000Rj-53; Sat, 26 May 2012 10:22:09 +0000 Date: Sat, 26 May 2012 19:22:07 +0900 Message-ID: From: Randy Bush To: Alexey Melnikov In-Reply-To: References: <4FBFA992.8020107@isode.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: sidr wg Subject: Re: [sidr] Date and type of the next (end of June/early July) interim X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 May 2012 10:22:11 -0000 good evening alexey, > Would you prefer a later date then, e.g. shortly after July 4th? janog is 4-6 july, so we would be into the following week, the week of the 9th [0]. and then we've just moved the short stick to the time to the pre-ietf meeting, which i have marked as 27.7. so, if i had to call it now, i would say 29.6 virtual. i would asume it would be short, except we may not get as much done as we would like in the post-nanog van meeting in ten or so days. randy [0] - the calendar many of us use to avoid ops meetings conficts can be found at http://ws.edu.isoc.org/calendar/ From weiler@watson.org Sat May 26 08:38:38 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E91F421F8565 for ; Sat, 26 May 2012 08:38:38 -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=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sGojsXYTlgOS for ; Sat, 26 May 2012 08:38:38 -0700 (PDT) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by ietfa.amsl.com (Postfix) with ESMTP id 54DA121F8564 for ; Sat, 26 May 2012 08:38:37 -0700 (PDT) Received: from fledge.watson.org (localhost.watson.org [127.0.0.1]) by fledge.watson.org (8.14.4/8.14.4) with ESMTP id q4QFca5A054782; Sat, 26 May 2012 11:38:36 -0400 (EDT) (envelope-from weiler@watson.org) Received: from localhost (weiler@localhost) by fledge.watson.org (8.14.4/8.14.4/Submit) with ESMTP id q4QFcZdW054775; Sat, 26 May 2012 11:38:36 -0400 (EDT) (envelope-from weiler@watson.org) X-Authentication-Warning: fledge.watson.org: weiler owned process doing -bs Date: Sat, 26 May 2012 11:38:35 -0400 (EDT) From: Samuel Weiler To: Alexey Melnikov In-Reply-To: <4FBFA992.8020107@isode.com> Message-ID: References: <4FBFA992.8020107@isode.com> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.3 (fledge.watson.org [127.0.0.1]); Sat, 26 May 2012 11:38:36 -0400 (EDT) Cc: sidr wg Subject: Re: [sidr] Date and type of the next (end of June/early July) interim X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 May 2012 15:38:39 -0000 On Fri, 25 May 2012, Alexey Melnikov wrote: > The WG needs to decide about the date and type of the next interim > (after June 6th). The earlier proposal stated June 29th. Are people > happy with this date or do they want to propose an alternative? Note > that we are more flexible this time, because this is not tied to any > other industry event. I presently oppose having interims [1], but in case the WG decides to have one anyway... My preference is for earlier that week, particularly Tuesday or Wednesday, 26-27 June. Following up on Randy's suggestion, the week of 9 July is also fine, with a slight preference for Tuesday-Thursday. I had said back in March that I would not be available on 29 June [2] -- there's a chance that could change, but I'd still rather pick a day that I can commit to, like the Tuesday or Wednesday. > We also need to decide on whether this should be a physical interim > with remote participants or fully virtual interim (e.g. everybody is > using WebEx or something similar). I don't care. I've previously suggested that we have an all-virtual meeting as a forcing function on the technical issues[2], but many of those issues involve getting audio to/from the room with many people in it, so an all-virtual meeting may not all that useful as a forcing function. -- Sam [1] http://www.ietf.org/mail-archive/web/sidr/current/msg04559.html [2] http://www.ietf.org/mail-archive/web/sidr/current/msg04268.html From jgs@juniper.net Tue May 29 11:22:24 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E77211E8138 for ; Tue, 29 May 2012 11:22:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.524 X-Spam-Level: X-Spam-Status: No, score=-6.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1iB1xsX+SS9E for ; Tue, 29 May 2012 11:22:23 -0700 (PDT) Received: from exprod7og104.obsmtp.com (exprod7og104.obsmtp.com [64.18.2.161]) by ietfa.amsl.com (Postfix) with ESMTP id 7274C11E8114 for ; Tue, 29 May 2012 11:22:19 -0700 (PDT) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob104.postini.com ([64.18.6.12]) with SMTP ID DSNKT8UT2uprcleCY7WFZG8x/G998dI1Ea59@postini.com; Tue, 29 May 2012 11:22:23 PDT Received: from [172.16.13.202] (172.16.13.202) by P-EMHUB01-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server id 8.3.213.0; Tue, 29 May 2012 11:21:34 -0700 MIME-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset="us-ascii" From: "John G. Scudder" In-Reply-To: <4FBC0936.7000905@bbn.com> Date: Tue, 29 May 2012 14:21:33 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: <5BA9D6DE-BE0E-4922-9E09-7B85BD6F9342@juniper.net> References: <24B20D14B2CD29478C8D5D6E9CBB29F60F70A267@Hermes.columbia.ads.sparta.com> <24B20D14B2CD29478C8D5D6E9CBB29F625F0975D@Hermes.columbia.ads.sparta.com> <4FBBB6D1.9000008@bbn.com> <4FBC0936.7000905@bbn.com> To: Matt Lepinski X-Mailer: Apple Mail (2.1278) Cc: "sidr@ietf.org list" Subject: Re: [sidr] request for agenda items for interim meeting 6 Jun X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 May 2012 18:22:24 -0000 On May 22, 2012, at 5:46 PM, Matt Lepinski wrote: > Other than confeds are there any other potentially open issues related = to the removal of AS_Path? (I think this just recapitulates what I said at the interim, but maybe = it's worth saying again for the list.) Philosophically, the thing that makes me worry the most is that we're = cutting out one of BGP's fundamental elements and replacing it with one = which provides only a subset of its semantics. Specific things missing = include: - Confederations. But we are discussing ways to fix this. - Extensibility to include new segment types. In principle this is a = fairly serious omission, but one can argue that new segment types can't = be introduced in practice, since existing implementations will treat = them as fatal errors. And actually, that's it for my list of specifics. I think we can check = off the "done, in principle" box for confeds. So the remaining issue is = extensibility. One may or may not find the "extensibility doesn't work = anyway" argument compelling, I'm not entirely sure *I* do. In any case, = I think this deserves a good airing before we commit. The other issue is one Shane already brought up on this thread -- the = fact that some of the more egregious AS_PATH editing hacks that exist in = the wild may not be supportable in the AS_PATH-less new world order. = (Many of the less egregious ones seem to be OK with appropriate pcount = gyrations.) The pros and cons are a bit slippery here since even if we = continue to carry AS_PATH, if the BGPSEC_Path_Signatures attribute can't = represent the semantics of what's in that AS_PATH, then validation will = fail. But at least there's scope for a network operator on the receiving = end to tolerate the validation failure and use the route anyway, if = desired. In the case where there's no AS_PATH, the data are just gone = with no chance for appeal.=20 It's also worth noting that leaving AS_PATH in would not be without = cost. In the cases where the content of AS_PATH is isomorphic to that of = BGPSEC_Path_Signatures, there's no problem -- but in those cases AS_PATH = clearly could have been left out. In the remaining cases, what is the = implementation supposed to do? It would be necessary to carefully = specify. The easiest cop-out would be to say that in all such cases, the = route fails validation. But I have a feeling that it's not that easy. = Leaving AS_PATH out reduces that particular maze of twisty passages, = although it replaces it with another: making sure it was really OK to = axe AS_PATH to begin with (i.e., the discussion above). I'm going to forward this to IDR to ensure that those who aren't = following SIDR are aware there's a proposal to phase out AS_PATH in = favor of a simplified replacement in BGPSEC.=20 --John= From jgs@juniper.net Tue May 29 11:25:22 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92CDB21F8618; Tue, 29 May 2012 11:25:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.549 X-Spam-Level: X-Spam-Status: No, score=-6.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a0b2hbRqRJfR; Tue, 29 May 2012 11:25:21 -0700 (PDT) Received: from exprod7og117.obsmtp.com (exprod7og117.obsmtp.com [64.18.2.6]) by ietfa.amsl.com (Postfix) with ESMTP id 656D021F8619; Tue, 29 May 2012 11:25:21 -0700 (PDT) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob117.postini.com ([64.18.6.12]) with SMTP ID DSNKT8UUkSfWsO4C8RLLZXN7c00DBYakz3So@postini.com; Tue, 29 May 2012 11:25:21 PDT Received: from [172.16.13.202] (172.16.13.202) by P-EMHUB01-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server id 8.3.213.0; Tue, 29 May 2012 11:24:51 -0700 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Apple Message framework v1278) From: "John G. Scudder" Date: Tue, 29 May 2012 14:24:50 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: References: <5BA9D6DE-BE0E-4922-9E09-7B85BD6F9342@juniper.net> To: "idr@ietf.org List" X-Mailer: Apple Mail (2.1278) Cc: "sidr@ietf.org list" Subject: [sidr] BGPSEC proposal to drop AS_PATH [was: Fwd: request for agenda items for interim meeting 6 Jun] X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 May 2012 18:25:22 -0000 IDR folks, BGPSEC (in the SIDR WG) includes a path attribute, = BGPSEC_Path_Signatures, that substantially overlaps the semantics of = AS_PATH. For reasons discussed in the forwarded note below, it proposes = that updates carrying BGPSEC_Path_Signatures should NOT carry AS_PATH.=20= Since this would represent a fairly major change to the protocol, I = wanted to make sure those not following SIDR were aware of it. Please = cross-post any comments to sidr@ietf.org. (See http://tools.ietf.org/html/ietf-sidr-bgpsec-protocol-03 Section 3.) --John Begin forwarded message: > From: "John G. Scudder" > Subject: Re: [sidr] request for agenda items for interim meeting 6 Jun > Date: May 29, 2012 2:21:33 PM EDT > To: Matt Lepinski > Cc: "sidr@ietf.org list" >=20 > On May 22, 2012, at 5:46 PM, Matt Lepinski wrote: >=20 >> Other than confeds are there any other potentially open issues = related to the removal of AS_Path? >=20 > (I think this just recapitulates what I said at the interim, but maybe = it's worth saying again for the list.) >=20 > Philosophically, the thing that makes me worry the most is that we're = cutting out one of BGP's fundamental elements and replacing it with one = which provides only a subset of its semantics. Specific things missing = include: >=20 > - Confederations. But we are discussing ways to fix this. > - Extensibility to include new segment types. In principle this is a = fairly serious omission, but one can argue that new segment types can't = be introduced in practice, since existing implementations will treat = them as fatal errors. >=20 > And actually, that's it for my list of specifics. I think we can check = off the "done, in principle" box for confeds. So the remaining issue is = extensibility. One may or may not find the "extensibility doesn't work = anyway" argument compelling, I'm not entirely sure *I* do. In any case, = I think this deserves a good airing before we commit. >=20 > The other issue is one Shane already brought up on this thread -- the = fact that some of the more egregious AS_PATH editing hacks that exist in = the wild may not be supportable in the AS_PATH-less new world order. = (Many of the less egregious ones seem to be OK with appropriate pcount = gyrations.) The pros and cons are a bit slippery here since even if we = continue to carry AS_PATH, if the BGPSEC_Path_Signatures attribute can't = represent the semantics of what's in that AS_PATH, then validation will = fail. But at least there's scope for a network operator on the receiving = end to tolerate the validation failure and use the route anyway, if = desired. In the case where there's no AS_PATH, the data are just gone = with no chance for appeal.=20 >=20 > It's also worth noting that leaving AS_PATH in would not be without = cost. In the cases where the content of AS_PATH is isomorphic to that of = BGPSEC_Path_Signatures, there's no problem -- but in those cases AS_PATH = clearly could have been left out. In the remaining cases, what is the = implementation supposed to do? It would be necessary to carefully = specify. The easiest cop-out would be to say that in all such cases, the = route fails validation. But I have a feeling that it's not that easy. = Leaving AS_PATH out reduces that particular maze of twisty passages, = although it replaces it with another: making sure it was really OK to = axe AS_PATH to begin with (i.e., the discussion above). >=20 > I'm going to forward this to IDR to ensure that those who aren't = following SIDR are aware there's a proposal to phase out AS_PATH in = favor of a simplified replacement in BGPSEC.=20 >=20 > --John > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr From jgs@bgp.nu Tue May 29 14:22:18 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0A3211E80E3; Tue, 29 May 2012 14:22:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.043 X-Spam-Level: X-Spam-Status: No, score=-102.043 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_IS_SMALL6=0.556, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 106jrFLrJOkg; Tue, 29 May 2012 14:22:18 -0700 (PDT) Received: from bgp.nu (bgp.nu [147.28.0.53]) by ietfa.amsl.com (Postfix) with ESMTP id 5835211E80EC; Tue, 29 May 2012 14:22:07 -0700 (PDT) Received: from [172.16.13.202] (75-151-14-10-Michigan.hfc.comcastbusiness.net [75.151.14.10]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by bgp.nu (Postfix) with ESMTP id 335FE66D371; Tue, 29 May 2012 17:22:06 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: "John G. Scudder" In-Reply-To: Date: Tue, 29 May 2012 17:22:04 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5BA9D6DE-BE0E-4922-9E09-7B85BD6F9342@juniper.net> To: "sidr@ietf.org list" X-Mailer: Apple Mail (2.1278) Cc: "idr@ietf.org List" Subject: Re: [sidr] BGPSEC proposal to drop AS_PATH [was: Fwd: request for agenda items for interim meeting 6 Jun] X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 May 2012 21:22:18 -0000 On May 29, 2012, at 2:24 PM, John G. Scudder wrote: > It's also worth noting that leaving AS_PATH in would not be without = cost. In the cases where the content of AS_PATH is isomorphic to that of = BGPSEC_Path_Signatures, there's no problem -- but in those cases AS_PATH = clearly could have been left out. In the remaining cases, what is the = implementation supposed to do? It would be necessary to carefully = specify. The easiest cop-out would be to say that in all such cases, the = route fails validation. But I have a feeling that it's not that easy. = Leaving AS_PATH out reduces that particular maze of twisty passages, = although it replaces it with another: making sure it was really OK to = axe AS_PATH to begin with (i.e., the discussion above). In an offline follow-up with Robert Raszuk, he pointed out that when one = applies a knob that results in an AS_PATH that can't be represented as a = BGPSEC_Path_Signatures [*] there is a third option, that of downgrading = from BGPSEC to unsigned BGP. That is to say, you convert the = BGPSEC_Path_Signatures to an AS_PATH, apply the knob to the AS_PATH, and = propagate the route with the AS_PATH and not the BGPSEC_Path_Signatures. = This is functionally equivalent to "in all such cases, the route fails = validation" but is more straightforward and seems to make a lot of = sense: everything that can be represented signed, should be. If you = insist on doing something that can't be signed, you can fall back to = unsigned BGP and hope for the best. This leaves me feeling a little more sanguine about the drop-the-AS_PATH = idea, although I still think some more attention to enumerating what = knobs will fall by the wayside is advisable.=20 --John [*] The name of this attribute makes for awkward prose since it has no = natural singular. How about calling it BGPSEC_Path_Signature instead? Or = Signed_Path or Signed_AS_Path sans brand name?= From jgs@juniper.net Tue May 29 14:24:10 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F31E711E80F7; Tue, 29 May 2012 14:24:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.574 X-Spam-Level: X-Spam-Status: No, score=-6.574 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hT3dc1vaQM1J; Tue, 29 May 2012 14:24:09 -0700 (PDT) Received: from exprod7og120.obsmtp.com (exprod7og120.obsmtp.com [64.18.2.18]) by ietfa.amsl.com (Postfix) with ESMTP id 4069F11E80E3; Tue, 29 May 2012 14:24:09 -0700 (PDT) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob120.postini.com ([64.18.6.12]) with SMTP ID DSNKT8U+eGXnDVrs6tY7YqpZTRxayBXDDjwZ@postini.com; Tue, 29 May 2012 14:24:09 PDT Received: from [172.16.13.202] (172.16.13.202) by P-EMHUB01-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server id 8.3.213.0; Tue, 29 May 2012 14:23:01 -0700 MIME-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset="us-ascii" From: "John G. Scudder" In-Reply-To: Date: Tue, 29 May 2012 17:23:00 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: References: <5BA9D6DE-BE0E-4922-9E09-7B85BD6F9342@juniper.net> To: "sidr@ietf.org list" X-Mailer: Apple Mail (2.1278) Cc: "idr@ietf.org List" Subject: Re: [sidr] BGPSEC proposal to drop AS_PATH [was: Fwd: request for agenda items for interim meeting 6 Jun] X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 May 2012 21:24:10 -0000 [Once more from proper account, sigh.] On May 29, 2012, at 2:24 PM, John G. Scudder wrote: > It's also worth noting that leaving AS_PATH in would not be without = cost. In the cases where the content of AS_PATH is isomorphic to that of = BGPSEC_Path_Signatures, there's no problem -- but in those cases AS_PATH = clearly could have been left out. In the remaining cases, what is the = implementation supposed to do? It would be necessary to carefully = specify. The easiest cop-out would be to say that in all such cases, the = route fails validation. But I have a feeling that it's not that easy. = Leaving AS_PATH out reduces that particular maze of twisty passages, = although it replaces it with another: making sure it was really OK to = axe AS_PATH to begin with (i.e., the discussion above). In an offline follow-up with Robert Raszuk, he pointed out that when one = applies a knob that results in an AS_PATH that can't be represented as a = BGPSEC_Path_Signatures [*] there is a third option, that of downgrading = from BGPSEC to unsigned BGP. That is to say, you convert the = BGPSEC_Path_Signatures to an AS_PATH, apply the knob to the AS_PATH, and = propagate the route with the AS_PATH and not the BGPSEC_Path_Signatures. = This is functionally equivalent to "in all such cases, the route fails = validation" but is more straightforward and seems to make a lot of = sense: everything that can be represented signed, should be. If you = insist on doing something that can't be signed, you can fall back to = unsigned BGP and hope for the best. This leaves me feeling a little more sanguine about the drop-the-AS_PATH = idea, although I still think some more attention to enumerating what = knobs will fall by the wayside is advisable.=20 --John [*] The name of this attribute makes for awkward prose since it has no = natural singular. How about calling it BGPSEC_Path_Signature instead? Or = Signed_Path or Signed_AS_Path sans brand name?= From randy@psg.com Tue May 29 16:45:42 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3CBF11E8160; Tue, 29 May 2012 16:45:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.479 X-Spam-Level: X-Spam-Status: No, score=-2.479 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ngTKpxWjT8jH; Tue, 29 May 2012 16:45:42 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id 099E311E813B; Tue, 29 May 2012 16:45:42 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1SZW6e-000CPA-Tx; Tue, 29 May 2012 23:45:41 +0000 Date: Wed, 30 May 2012 08:45:39 +0900 Message-ID: From: Randy Bush To: "John G. Scudder" In-Reply-To: References: <5BA9D6DE-BE0E-4922-9E09-7B85BD6F9342@juniper.net> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: "idr@ietf.org List" , "sidr@ietf.org list" Subject: Re: [sidr] BGPSEC proposal to drop AS_PATH [was: Fwd: request for agenda items for interim meeting 6 Jun] X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 May 2012 23:45:42 -0000 > This leaves me feeling a little more sanguine about the > drop-the-AS_PATH idea, although I still think some more attention to > enumerating what knobs will fall by the wayside is advisable. as folk keep inventing new knobs, one question would seem to be whether the knob inventors will understand and accept the trust/threat model implications of knobs which force downgrade to non-sec. randy From jakob.heitz@ericsson.com Tue May 29 17:01:54 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BA6311E8177; Tue, 29 May 2012 17:01:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XM36mkDvyxOp; Tue, 29 May 2012 17:01:53 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id 6ACF111E8173; Tue, 29 May 2012 17:01:53 -0700 (PDT) Received: from eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id q4U01mKS027359; Tue, 29 May 2012 19:01:50 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.31]) by eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) with mapi; Tue, 29 May 2012 20:01:43 -0400 From: Jakob Heitz To: "John G. Scudder" , "sidr@ietf.org list" Date: Tue, 29 May 2012 20:01:42 -0400 Thread-Topic: [sidr] BGPSEC proposal to drop AS_PATH [was: Fwd: request for agenda items for interim meeting 6 Jun] Thread-Index: Ac094TbBfl3MnBoUTvCChOkF5V/nqwAFG3+A Message-ID: <7309FCBCAE981B43ABBE69B31C8D213921BFA65FD8@EUSAACMS0701.eamcs.ericsson.se> References: <5BA9D6DE-BE0E-4922-9E09-7B85BD6F9342@juniper.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "idr@ietf.org List" Subject: Re: [sidr] BGPSEC proposal to drop AS_PATH [was: Fwd: request for agenda items for interim meeting 6 Jun] X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 May 2012 00:01:54 -0000 AS_PATH is used to specify the path that the payload takes. Signed_AS_PATH is to verify the path that the update message takes. There is no reason they can not be different. Let the verifying function take both as input and let it decide based on policy. An AS could forward an update with a third party nexthop of a third party AS. The update message does not need to traverse the third party AS at all, but the payload will. The third party ASN might just be another ASN that the first party is using: it might be renumbering. The first party might like to include the third party ASN for loop detection. I don't have a specific feature in mind. Just "what if". On Tuesday, May 29, 2012 2:22 PM, John G. Scudder <> wrote: > On May 29, 2012, at 2:24 PM, John G. Scudder wrote: >=20 >> It's also worth noting that leaving AS_PATH in would not be without >> cost. In the cases where the content of AS_PATH is isomorphic to >> that of BGPSEC_Path_Signatures, there's no problem -- but in those >> cases AS_PATH clearly could have been left out. In the remaining >> cases, what is the implementation supposed to do? It would be >> necessary to carefully specify. The easiest cop-out would be to say >> that in all such cases, the route fails validation. But I have a >> feeling that it's not that easy. Leaving AS_PATH out reduces that >> particular maze of twisty passages, although it replaces it with >> another: making sure it was really OK to axe AS_PATH to begin with >> (i.e., the discussion above). =20 >=20 > In an offline follow-up with Robert Raszuk, he pointed out that when > one applies a knob that results in an AS_PATH that can't be > represented as a BGPSEC_Path_Signatures [*] there is a third option, > that of downgrading from BGPSEC to unsigned BGP. That is to say, you > convert the BGPSEC_Path_Signatures to an AS_PATH, apply the knob to > the AS_PATH, and propagate the route with the AS_PATH and not the > BGPSEC_Path_Signatures. This is functionally equivalent to "in all > such cases, the route fails validation" but is more straightforward > and seems to make a lot of sense: everything that can be represented > signed, should be. If you insist on doing something that can't be > signed, you can fall back to unsigned BGP and hope for the best. =20 >=20 > This leaves me feeling a little more sanguine about the > drop-the-AS_PATH idea, although I still think some more attention to > enumerating what knobs will fall by the wayside is advisable. =20 >=20 > --John >=20 > [*] The name of this attribute makes for awkward prose since it has > no natural singular. How about calling it BGPSEC_Path_Signature > instead? Or Signed_Path or Signed_AS_Path sans brand name --=20 Jakob Heitz.= From sra@hactrn.net Tue May 29 17:12:43 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6755A11E817B for ; Tue, 29 May 2012 17:12:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.855 X-Spam-Level: X-Spam-Status: No, score=-101.855 tagged_above=-999 required=5 tests=[AWL=-0.745, BAYES_05=-1.11, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PwohabgoMyE4 for ; Tue, 29 May 2012 17:12:42 -0700 (PDT) Received: from cyteen.hactrn.net (cyteen.hactrn.net [66.92.66.68]) by ietfa.amsl.com (Postfix) with ESMTP id 1F28F11E8121 for ; Tue, 29 May 2012 17:12:42 -0700 (PDT) Received: from thrintun.hactrn.net (thrintun.hactrn.net [IPv6:2002:425c:4242:0:219:d1ff:fe12:5d30]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "thrintun.hactrn.net", Issuer "Grunchweather Associates" (verified OK)) by cyteen.hactrn.net (Postfix) with ESMTPS id 56D712847F for ; Wed, 30 May 2012 00:12:39 +0000 (UTC) Received: from thrintun.hactrn.net (localhost [IPv6:::1]) by thrintun.hactrn.net (Postfix) with ESMTP id 2CF3D17244 for ; Tue, 29 May 2012 20:12:39 -0400 (EDT) Date: Tue, 29 May 2012 20:12:39 -0400 From: Rob Austein To: sidr@ietf.org User-Agent: Wanderlust/2.14.0 (Africa) Emacs/23.4 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20120530001239.2CF3D17244@thrintun.hactrn.net> Subject: [sidr] Collecting your own statistics on the RPKI repository infrastructure X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 May 2012 00:12:43 -0000 Those who are interested in performing their own measurements on the current RPKI infrastructure might be interested in the current version of the rcynic-html tool which ships with our (rpki.net) validation code. This is a follow-on to some of the earlier measurement work we've been doing. The intent is to make it practical for people to collect and graph their own statistics, since it's become clear that some of the measurement results are highly sensitive to where one sits on the global network. To use this, download and build our software (see documentation), configure rcynic and rcynic-html to run hourly under cron (ditto), and let it run for a while to collect some history. rcynic-html stores what we think are the most useful measurements in a collection of rrd databases (see rrdtool, mrtg) and includes graphs of the result in its output. Software is at http://rpki.net/ If you're allergic to private trust anchors, see http://download.rpki.net/ Sample of the output, from the same rcynic instance which generated the graphs I've presented at the last two IEPG meetings. Since I've been saving the XML files from this particular rcynic instance anyway, I was able to feed the last seven months of history into rcynic-html, so this gives some idea of what one might see after leaving it running for a while. http://www.hactrn.net/opaque/rcynic/ From randy@psg.com Tue May 29 17:29:27 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83A3F11E817D; Tue, 29 May 2012 17:29:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.484 X-Spam-Level: X-Spam-Status: No, score=-2.484 tagged_above=-999 required=5 tests=[AWL=0.115, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w0CEHGgf8-Zp; Tue, 29 May 2012 17:29:27 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id 24C3C11E817B; Tue, 29 May 2012 17:29:27 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1SZWmz-000CpK-3q; Wed, 30 May 2012 00:29:25 +0000 Date: Wed, 30 May 2012 09:29:23 +0900 Message-ID: From: Randy Bush To: Jakob Heitz In-Reply-To: <7309FCBCAE981B43ABBE69B31C8D213921BFA65FD8@EUSAACMS0701.eamcs.ericsson.se> References: <5BA9D6DE-BE0E-4922-9E09-7B85BD6F9342@juniper.net> <7309FCBCAE981B43ABBE69B31C8D213921BFA65FD8@EUSAACMS0701.eamcs.ericsson.se> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: idr wg , sidr wg list Subject: Re: [sidr] BGPSEC proposal to drop AS_PATH [was: Fwd: request for agenda items for interim meeting 6 Jun] X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 May 2012 00:29:27 -0000 > AS_PATH is used to specify the path that the payload takes. really? i thought it was a routing loop detection mechanism. it's been a while since folk wrote research papers describing schemes for routing by AS. i would phrase it as AS_PATH specifies the ASs through which the routing announcement has passed. > Signed_AS_PATH is to verify the path that the update message takes. and then this works really nicely. > There is no reason they can not be different. and here i thought that detecting that they differ, as an attack, is the core goal of as-path validation. randy From jakob.heitz@ericsson.com Tue May 29 17:47:44 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACA2821F8687; Tue, 29 May 2012 17:47:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BFslkLacnUxU; Tue, 29 May 2012 17:47:44 -0700 (PDT) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by ietfa.amsl.com (Postfix) with ESMTP id 1454921F867B; Tue, 29 May 2012 17:47:39 -0700 (PDT) Received: from eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id q4U0lcsn028834 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 29 May 2012 19:47:38 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.31]) by eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) with mapi; Tue, 29 May 2012 20:47:37 -0400 From: Jakob Heitz To: Randy Bush Date: Tue, 29 May 2012 20:47:36 -0400 Thread-Topic: [sidr] BGPSEC proposal to drop AS_PATH [was: Fwd: request for agenda items for interim meeting 6 Jun] Thread-Index: Ac09+0eISep1YF9nT8a9bfJn5+bX0AAAiVEw Message-ID: <7309FCBCAE981B43ABBE69B31C8D213921BFA66011@EUSAACMS0701.eamcs.ericsson.se> References: <5BA9D6DE-BE0E-4922-9E09-7B85BD6F9342@juniper.net> <7309FCBCAE981B43ABBE69B31C8D213921BFA65FD8@EUSAACMS0701.eamcs.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: idr wg , sidr wg list Subject: Re: [sidr] BGPSEC proposal to drop AS_PATH [was: Fwd: request for agenda items for interim meeting 6 Jun] X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 May 2012 00:47:44 -0000 On Tuesday, May 29, 2012 5:29 PM, Randy Bush wrote: >> AS_PATH is used to specify the path that the payload takes. >=20 > really? i thought it was a routing loop detection mechanism. > it's been a while since folk wrote research papers describing > schemes for routing by AS. >=20 > i would phrase it as >=20 > AS_PATH specifies the ASs through which the routing announcement has > passed. >=20 >> Signed_AS_PATH is to verify the path that the update message takes. >=20 > and then this works really nicely. >=20 >> There is no reason they can not be different. >=20 > and here i thought that detecting that they differ, as an attack, is > the core goal of as-path validation. I thought it was to prevent an AS from announcing an update that it was not authorised to. An entirely different thing. >=20 > randy --=20 Jakob Heitz.= From randy@psg.com Tue May 29 17:52:07 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 480B721F86B7; Tue, 29 May 2012 17:52:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.493 X-Spam-Level: X-Spam-Status: No, score=-2.493 tagged_above=-999 required=5 tests=[AWL=0.106, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 94F1mtelqgFE; Tue, 29 May 2012 17:52:06 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id BA17F21F86B6; Tue, 29 May 2012 17:52:06 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1SZX8w-000D4r-Fj; Wed, 30 May 2012 00:52:06 +0000 Date: Wed, 30 May 2012 09:52:05 +0900 Message-ID: From: Randy Bush To: Jakob Heitz In-Reply-To: <7309FCBCAE981B43ABBE69B31C8D213921BFA66011@EUSAACMS0701.eamcs.ericsson.se> References: <5BA9D6DE-BE0E-4922-9E09-7B85BD6F9342@juniper.net> <7309FCBCAE981B43ABBE69B31C8D213921BFA65FD8@EUSAACMS0701.eamcs.ericsson.se> <7309FCBCAE981B43ABBE69B31C8D213921BFA66011@EUSAACMS0701.eamcs.ericsson.se> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: idr wg , sidr wg list Subject: Re: [sidr] BGPSEC proposal to drop AS_PATH [was: Fwd: request for agenda items for interim meeting 6 Jun] X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 May 2012 00:52:07 -0000 >> and here i thought that detecting that they differ, as an attack, is >> the core goal of as-path validation. > I thought it was to prevent an AS from announcing an update that it > was not authorised to. nope. that is rpki-based origin validation. we are now talking about as-path validation. from a note to some gov folk: To be clear, as people keep calling BGP security 'RPKI' In the current taxonomy, there are three pieces, the RPKI, RPKI-based origin validation, and then path validation. RPKI is the X.509 based hierarchy with is congruent with the internet IP address allocation administration, the IANA, RIRS, ISPs, ... It is the substrate on which the next two are based. It is currently deployed in four of the five administrative regions, ARIN in North America being the sad and embarrassing exception. RPKI-based origin validation uses some of the RPKI data to allow a router to verify that the autonomous system announcing an IP address prefix is in fact authorized to do so. This is not crypto checked so can be violated. But it prevents the vast majority of accidental 'hijackings' on the internet today, e.g. the famous Pakastani accidental announcement of YouTube's address space. RPKI-based origin validation is in shipping code from Cisco, and will be shipping by Juniper soon. Path validation uses the full crypto information of the RPKI to make up for the embarrassing mistake that, like much of the internet BGP was designed with no thought to securing the BGP protocol itself from being gamed/violated. It allows a receiver of a BGP announcement to formally cryptographically validate that the originating autonomous system was truely authorized to announce the IP address prefix, and that the systems through which the announcement passed were indeed those which the sender/forwarder at each hop intended. Sorry to drone on, but these three really need to be differentiated. randy From jakob.heitz@ericsson.com Tue May 29 18:06:02 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E51BD11E8127; Tue, 29 May 2012 18:06:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r5qunIY-Upin; Tue, 29 May 2012 18:06:02 -0700 (PDT) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by ietfa.amsl.com (Postfix) with ESMTP id 549B121F8712; Tue, 29 May 2012 18:06:02 -0700 (PDT) Received: from eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id q4U161u5029472 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 29 May 2012 20:06:01 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.31]) by eusaamw0706.eamcs.ericsson.se ([147.117.20.31]) with mapi; Tue, 29 May 2012 21:06:01 -0400 From: Jakob Heitz To: Randy Bush Date: Tue, 29 May 2012 21:05:59 -0400 Thread-Topic: [sidr] BGPSEC proposal to drop AS_PATH [was: Fwd: request for agenda items for interim meeting 6 Jun] Thread-Index: Ac09/nKS5R3/ljnoQHOQ4+4cJ6S2HAAAG7Fg Message-ID: <7309FCBCAE981B43ABBE69B31C8D213921BFA66014@EUSAACMS0701.eamcs.ericsson.se> References: <5BA9D6DE-BE0E-4922-9E09-7B85BD6F9342@juniper.net> <7309FCBCAE981B43ABBE69B31C8D213921BFA65FD8@EUSAACMS0701.eamcs.ericsson.se> <7309FCBCAE981B43ABBE69B31C8D213921BFA66011@EUSAACMS0701.eamcs.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: idr wg , sidr wg list Subject: Re: [sidr] BGPSEC proposal to drop AS_PATH [was: Fwd: request for agenda items for interim meeting 6 Jun] X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 May 2012 01:06:03 -0000 On Tuesday, May 29, 2012 5:52 PM, Randy Bush wrote: >>> and here i thought that detecting that they differ, as an attack, is >>> the core goal of as-path validation. >> I thought it was to prevent an AS from announcing an update that it >> was not authorised to. >=20 > nope. that is rpki-based origin validation. we are now talking about > as-path validation. >=20 > from a note to some gov folk: >=20 > To be clear, as people keep calling BGP security 'RPKI' >=20 > In the current taxonomy, there are three pieces, the RPKI, RPKI-based > origin validation, and then path validation. >=20 > RPKI is the X.509 based hierarchy with is congruent with the internet > IP address allocation administration, the IANA, RIRS, ISPs, ... It > is the substrate on which the next two are based. It is currently > deployed in four of the five administrative regions, ARIN in North > America being the sad and embarrassing exception. >=20 > RPKI-based origin validation uses some of the RPKI data to allow a > router to verify that the autonomous system announcing an IP address > prefix is in fact authorized to do so. This is not crypto checked so > can be violated. But it prevents the vast majority of accidental > 'hijackings' on the internet today, e.g. the famous Pakastani > accidental announcement of YouTube's address space. RPKI-based > origin validation=20 > is in shipping code from Cisco, and will be shipping by Juniper soon. >=20 > Path validation uses the full crypto information of the RPKI to make > up for the embarrassing mistake that, like much of the internet BGP > was designed with no thought to securing the BGP protocol itself from > being gamed/violated. It allows a receiver of a BGP announcement to > formally cryptographically validate that the originating autonomous > system was truely authorized to announce the IP address prefix, and > that the=20 > systems through which the announcement passed were indeed those which > the sender/forwarder at each hop intended. >=20 > Sorry to drone on, but these three really need to be differentiated. >=20 > randy Apology accepted. Note, I said "announcing", not "originating". Here is my view of the difference: Origin validation does not stop anyone from announcing an update. It only requires the first AS in that update to be the owner of the prefix. Path validation prevents anyone from announcing an update unless it was sent to them by an authorised AS. And they are authorised, because it was sent to them by an authorised AS and so on, back to the authorised originator. --=20 Jakob Heitz.= From robert@raszuk.net Wed May 30 05:01:40 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63F1821F86FF for ; Wed, 30 May 2012 05:01:40 -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=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f24j+E5s5VTR for ; Wed, 30 May 2012 05:01:39 -0700 (PDT) Received: from mail1310.opentransfer.com (mail1310.opentransfer.com [76.162.254.103]) by ietfa.amsl.com (Postfix) with ESMTP id 8EA1A21F86F7 for ; Wed, 30 May 2012 05:01:39 -0700 (PDT) Received: (qmail 22326 invoked by uid 399); 30 May 2012 12:01:38 -0000 Received: from unknown (HELO ?192.168.1.91?) (pbs:m42@mojaklasa.info@83.31.219.206) by mail1310.opentransfer.com with ESMTPM; 30 May 2012 12:01:38 -0000 X-Originating-IP: 83.31.219.206 Message-ID: <4FC60C21.6010108@raszuk.net> Date: Wed, 30 May 2012 14:01:37 +0200 From: Robert Raszuk User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Randy Bush References: <5BA9D6DE-BE0E-4922-9E09-7B85BD6F9342@juniper.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "idr@ietf.org List" , "sidr@ietf.org list" Subject: Re: [sidr] [Idr] BGPSEC proposal to drop AS_PATH [was: Fwd: request for agenda items for interim meeting 6 Jun] X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: robert@raszuk.net List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 May 2012 12:01:40 -0000 Let's observe that mangling with AS_PATH is usually done for a reason .. to achieve reachability to some set of prefixes which otherwise would be dropped. So with this in mind a better question to think about from customer perspective is to choose either: - unsecure but reachable Internet destinations - secure Internet routing but unreachable destinations Rgs, R. PS. I believe I have a solution to address both sides. Let me write it up and share in a week or two. >> This leaves me feeling a little more sanguine about the >> drop-the-AS_PATH idea, although I still think some more attention to >> enumerating what knobs will fall by the wayside is advisable. > > as folk keep inventing new knobs, one question would seem to be whether > the knob inventors will understand and accept the trust/threat model > implications of knobs which force downgrade to non-sec. > > randy > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > > From kent@bbn.com Wed May 30 08:41:20 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BEB8221F85AD; Wed, 30 May 2012 08:41:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.299 X-Spam-Level: X-Spam-Status: No, score=-105.299 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HeHm2pgkkd3h; Wed, 30 May 2012 08:41:20 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id E775121F8438; Wed, 30 May 2012 08:41:19 -0700 (PDT) Received: from dhcp89-089-114.bbn.com ([128.89.89.114]:49193) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1SZl0s-000HOF-Ee; Wed, 30 May 2012 11:40:42 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <5BA9D6DE-BE0E-4922-9E09-7B85BD6F9342@juniper.net> <7309FCBCAE981B43ABBE69B31C8D213921BFA65FD8@EUSAACMS0701.eamcs.ericsson.se > <7309FCBCAE981B43ABBE69B31C8D213921BFA66011@EUSAACMS0701.eamcs.ericsson.se > Date: Wed, 30 May 2012 10:06:57 -0400 To: Randy Bush From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: idr wg , sidr wg list Subject: Re: [sidr] BGPSEC proposal to drop AS_PATH [was: Fwd: request for agenda items for interim meeting 6 Jun] X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 May 2012 15:41:20 -0000 Randy, Thanks for the nicely articulated description of these elements of routing security work in SIDR. Steve From Sandra.Murphy@sparta.com Wed May 30 09:11:17 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11F4811E8083 for ; Wed, 30 May 2012 09:11:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.535 X-Spam-Level: X-Spam-Status: No, score=-102.535 tagged_above=-999 required=5 tests=[AWL=0.064, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o98ua+g3TFeU for ; Wed, 30 May 2012 09:11:16 -0700 (PDT) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by ietfa.amsl.com (Postfix) with ESMTP id 324F411E808D for ; Wed, 30 May 2012 09:11:08 -0700 (PDT) Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.14.4/8.14.4) with ESMTP id q4UGAHmE023420; Wed, 30 May 2012 11:10:17 -0500 Received: from Hermes.columbia.ads.sparta.com ([157.185.80.107]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id q4UGAGLh023121; Wed, 30 May 2012 11:10:17 -0500 Received: from HERMES.columbia.ads.sparta.com ([2002:9db9:506b::9db9:506b]) by Hermes.columbia.ads.sparta.com ([::1]) with mapi id 14.01.0355.002; Wed, 30 May 2012 12:10:16 -0400 From: "Murphy, Sandra" To: "John G. Scudder" , Matt Lepinski Thread-Topic: [sidr] request for agenda items for interim meeting 6 Jun Thread-Index: AQHNM6/4vkOTGr4FY0qnZHxk5Z062pbU2chygAFoXoCAAFw9gIAABfwAgArHD4CAARR23g== Date: Wed, 30 May 2012 16:10:16 +0000 Message-ID: <24B20D14B2CD29478C8D5D6E9CBB29F625F12333@Hermes.columbia.ads.sparta.com> References: <24B20D14B2CD29478C8D5D6E9CBB29F60F70A267@Hermes.columbia.ads.sparta.com> <24B20D14B2CD29478C8D5D6E9CBB29F625F0975D@Hermes.columbia.ads.sparta.com> <4FBBB6D1.9000008@bbn.com> <4FBC0936.7000905@bbn.com>, <5BA9D6DE-BE0E-4922-9E09-7B85BD6F9342@juniper.net> In-Reply-To: <5BA9D6DE-BE0E-4922-9E09-7B85BD6F9342@juniper.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.185.63.118] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "sidr@ietf.org list" Subject: Re: [sidr] request for agenda items for interim meeting 6 Jun X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 May 2012 16:11:17 -0000 Speaking as regular ol' wg member:=0A= =0A= Thanks for all of this John. Excellent thoughts.=0A= =0A= >Philosophically, the thing that makes me worry the most is that we're =0A= >cutting out one of BGP's fundamental elements and replacing it with one = =0A= >which provides only a subset of its semantics. Specific things missing =0A= >include:=0A= =0A= I'm very interested in exploring semantics of the AS_PATH that the signatur= e attribute does not capture.=0A= =0A= As for the particular uses you note:=0A= =0A= >=0A= >- Confederations. But we are discussing ways to fix this.=0A= >- Extensibility to include new segment types. In principle this is a fairl= y =0A= >serious omission, but one can argue that new segment types can't be =0A= >introduced in practice, since existing implementations will treat them =0A= >as fatal errors.=0A= =0A= As you note, there was a good discussion at the Apr 30 interim about confed= erations. We probably need to document it, a minor question being where it= belongs (what document).=0A= =0A= About extensibility - as you say, any new segment type not built into imple= mentations would result in fatal errors. So any new segment type would nee= d to be built into implementations before use. The question then becomes -= can the signature attributes also be augmented at the same time to deal wi= th the new segment types?=0A= =0A= If a new segment type has a trust model, then there could be a simultaneous= ly developed new security attribute to protect it. If the new type's trust= model matches the existing AS_PATH trust model, then new protections could= be a new type or version of the existing signature attribute.=0A= =0A= So the AS_PATH extensibility could be maintained in the security protection= s - as long as the new extension is "protectable".=0A= =0A= =0A= >The other issue is one Shane already brought up on this thread -- =0A= >the fact that some of the more egregious AS_PATH editing hacks =0A= >that exist in the wild may not be supportable in the AS_PATH-less =0A= >new world order. =0A= =0A= I am quite sure I don't know the complete list of AS_PATH knobs!=0A= =0A= But some of those I do know are hacks that would allow attacks as well. Th= e fact that the security protections prohibit the attacks is a good thing. = If there's a way to identify good, not evil, uses, then we can design for = that. But in cases where there's no real way to distinguish the good from = the evil, we're in a hard place. Shoot a hole in the protection to allow t= he hack or prohibit the hack.=0A= =0A= --Sandy, speaking as regular ol' wg member=0A= =0A= ________________________________________=0A= From: sidr-bounces@ietf.org [sidr-bounces@ietf.org] on behalf of John G. Sc= udder [jgs@juniper.net]=0A= Sent: Tuesday, May 29, 2012 2:21 PM=0A= To: Matt Lepinski=0A= Cc: sidr@ietf.org list=0A= Subject: Re: [sidr] request for agenda items for interim meeting 6 Jun=0A= =0A= On May 22, 2012, at 5:46 PM, Matt Lepinski wrote:=0A= =0A= > Other than confeds are there any other potentially open issues related to= the removal of AS_Path?=0A= =0A= (I think this just recapitulates what I said at the interim, but maybe it's= worth saying again for the list.)=0A= =0A= Philosophically, the thing that makes me worry the most is that we're cutti= ng out one of BGP's fundamental elements and replacing it with one which pr= ovides only a subset of its semantics. Specific things missing include:=0A= =0A= - Confederations. But we are discussing ways to fix this.=0A= - Extensibility to include new segment types. In principle this is a fairly= serious omission, but one can argue that new segment types can't be introd= uced in practice, since existing implementations will treat them as fatal e= rrors.=0A= =0A= And actually, that's it for my list of specifics. I think we can check off = the "done, in principle" box for confeds. So the remaining issue is extensi= bility. One may or may not find the "extensibility doesn't work anyway" arg= ument compelling, I'm not entirely sure *I* do. In any case, I think this d= eserves a good airing before we commit.=0A= =0A= The other issue is one Shane already brought up on this thread -- the fact = that some of the more egregious AS_PATH editing hacks that exist in the wil= d may not be supportable in the AS_PATH-less new world order. (Many of the = less egregious ones seem to be OK with appropriate pcount gyrations.) The p= ros and cons are a bit slippery here since even if we continue to carry AS_= PATH, if the BGPSEC_Path_Signatures attribute can't represent the semantics= of what's in that AS_PATH, then validation will fail. But at least there's= scope for a network operator on the receiving end to tolerate the validati= on failure and use the route anyway, if desired. In the case where there's = no AS_PATH, the data are just gone with no chance for appeal.=0A= =0A= It's also worth noting that leaving AS_PATH in would not be without cost. I= n the cases where the content of AS_PATH is isomorphic to that of BGPSEC_Pa= th_Signatures, there's no problem -- but in those cases AS_PATH clearly cou= ld have been left out. In the remaining cases, what is the implementation s= upposed to do? It would be necessary to carefully specify. The easiest cop-= out would be to say that in all such cases, the route fails validation. But= I have a feeling that it's not that easy. Leaving AS_PATH out reduces that= particular maze of twisty passages, although it replaces it with another: = making sure it was really OK to axe AS_PATH to begin with (i.e., the discus= sion above).=0A= =0A= I'm going to forward this to IDR to ensure that those who aren't following = SIDR are aware there's a proposal to phase out AS_PATH in favor of a simpli= fied replacement in BGPSEC.=0A= =0A= --John=0A= _______________________________________________=0A= sidr mailing list=0A= sidr@ietf.org=0A= https://www.ietf.org/mailman/listinfo/sidr=0A= From mlepinski@bbn.com Wed May 30 10:18:25 2012 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 925FB11E80B4 for ; Wed, 30 May 2012 10:18:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gJ5c1kwd8QEn for ; Wed, 30 May 2012 10:18:24 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id AD66211E80B0 for ; Wed, 30 May 2012 10:18:24 -0700 (PDT) Received: from mail.bbn.com ([128.33.0.48]:56265) by smtp.bbn.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1SZmWu-000Khb-2U for sidr@ietf.org; Wed, 30 May 2012 13:17:52 -0400 Received: from [128.89.254.253] by mail.bbn.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1SZmXP-0003Ne-Va for sidr@ietf.org; Wed, 30 May 2012 13:18:24 -0400 Message-ID: <4FC65666.8080805@bbn.com> Date: Wed, 30 May 2012 13:18:30 -0400 From: Matt Lepinski User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: sidr@ietf.org References: <24B20D14B2CD29478C8D5D6E9CBB29F60F70A267@Hermes.columbia.ads.sparta.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------050000010109000703000704" Subject: Re: [sidr] request for agenda items for interim meeting 6 Jun X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 May 2012 17:18:25 -0000 This is a multi-part message in MIME format. --------------050000010109000703000704 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Roque, Yes, there has been some confusion about AS4_Path, I think my text in the protocol draft (both the current version, but especially in previous versions) is in part responsible for this. I agree that even if we included AS_Path in BGPSEC update messages BGPSEC speakers MUST support 4-byte AS numbers and so there would never be any reason to include AS4_Path. My apologies for lack of clarity in the spec, I'll attempt to remove any lingering ambiguity in the next update to the draft. - Matt Lepinski On 5/24/2012 5:07 AM, Roque Gagliano (rogaglia) wrote: > Randy, > >> well, actually, the discussion in april was walking around many of the >> implications thereof. it is hard to discuss "do we keep/replace >> AS[4]_PATH" as it is abstract and draws deep philosophical discourse >> with no hard handles on technical decision points. > I think you should remove the [4] from the discussion. 4 bytes ASN is mandatory for BGPSEC speakers. So, there should be no AS4_PATH attributes between BGPSEC routers to keep/replace. > > Roque > > > >> otoh, i would be really interested in hearing/discussing if anyone sees >> any show-stoppers to the current draft doing so. >> >> i am amused that the current draft says, in the intro, >> >> 2. Every AS listed in the AS_Path attribute of the update explicitly >> authorized the advertisement of the route to the subsequent AS in >> the AS_Path. >> >> when there is no bgpsec as_path. :) >> >>> The absence of the AS_PATH did come up in discussing other topics (see >>> the minutes), but we did not discuss it directly. >> see above >> >>> (2) router private key provisioning. >>> >>> In the interim in San Diego, there were requests (from operators) that >>> guidance to operators of how to provision a router with the needed >>> keys would be a good idea. We had some discussion in the Paris >>> meeting of two drafts discussing provisioning the routers with their >>> needed private keys. There's also been a recent flurry of discussion >>> on the list. >> no comments on the new version of draft-ietf-sidr-rtr-keying-00.txt. >> would appreciate some now or we can ask for wglc. >> >> there have been no comments on list to confed and aliasing. may we call >> them done? >> >> randy >> _______________________________________________ >> sidr mailing list >> sidr@ietf.org >> https://www.ietf.org/mailman/listinfo/sidr > > > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr --------------050000010109000703000704 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Roque,

Yes, there has been some confusion about AS4_Path, I think my text in the protocol draft (both the current version, but especially in previous versions) is in part responsible for this.

I agree that even if we included AS_Path in BGPSEC update messages BGPSEC speakers MUST support 4-byte AS numbers and so there would never be any reason to include AS4_Path. My apologies for lack of clarity in the spec, I'll attempt to remove any lingering ambiguity in the next update to the draft.

- Matt Lepinski

On 5/24/2012 5:07 AM, Roque Gagliano (rogaglia) wrote: 
Randy,


well, actually, the discussion in april was walking around many of the
implications thereof.  it is hard to discuss "do we keep/replace
AS[4]_PATH" as it is abstract and draws deep philosophical discourse
with no hard handles on technical decision points.

I think you should remove the [4] from the discussion. 4 bytes ASN is mandatory for BGPSEC speakers. So, there should be no AS4_PATH attributes between BGPSEC routers to keep/replace.

Roque




otoh, i would be really interested in hearing/discussing if anyone sees
any show-stoppers to the current draft doing so.

i am amused that the current draft says, in the intro,

  2.  Every AS listed in the AS_Path attribute of the update explicitly
      authorized the advertisement of the route to the subsequent AS in
      the AS_Path.

when there is no bgpsec as_path. :)


The absence of the AS_PATH did come up in discussing other topics (see
the minutes), but we did not discuss it directly.

see above


(2) router private key provisioning.

In the interim in San Diego, there were requests (from operators) that
guidance to operators of how to provision a router with the needed
keys would be a good idea.  We had some discussion in the Paris
meeting of two drafts discussing provisioning the routers with their
needed private keys.  There's also been a recent flurry of discussion
on the list.

no comments on the new version of draft-ietf-sidr-rtr-keying-00.txt.
would appreciate some now or we can ask for wglc.

there have been no comments on list to confed and aliasing.  may we call
them done?

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


      

      

      

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


    

    

  


--------------050000010109000703000704--

From morrowc@ops-netman.net  Wed May 30 12:17:01 2012
Return-Path: 
X-Original-To: sidr@ietfa.amsl.com
Delivered-To: sidr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 783BB21F8625 for ; Wed, 30 May 2012 12:17:01 -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=[AWL=-0.000, BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fP-hFl3DLEeE for ; Wed, 30 May 2012 12:16:58 -0700 (PDT)
Received: from mailserver.ops-netman.net (mailserver.ops-netman.net [IPv6:2001:470:e495:fade:5054:ff:fe79:69db]) by ietfa.amsl.com (Postfix) with ESMTP id 7D97221F8622 for ; Wed, 30 May 2012 12:16:58 -0700 (PDT)
Received: from [192.168.85.20] (216-239-44-65.google.com [216.239.44.65]) (Authenticated sender: morrowc@OPS-NETMAN.NET) by mailserver.ops-netman.net (Postfix) with ESMTPSA id C9416320372; Wed, 30 May 2012 19:16:55 +0000 (UTC)
Message-ID: <4FC67225.3040709@ops-netman.net>
Date: Wed, 30 May 2012 15:16:53 -0400
From: Chris Morrow 
User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1
MIME-Version: 1.0
To: "sidr-chairs@tools.ietf.org" 
References: <24B20D14B2CD29478C8D5D6E9CBB29F625F12C53@Hermes.columbia.ads.sparta.com>
In-Reply-To: <24B20D14B2CD29478C8D5D6E9CBB29F625F12C53@Hermes.columbia.ads.sparta.com>
X-Enigmail-Version: 1.4.1
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: sidr@ietf.org
Subject: Re: [sidr] register for 6 Jun interim meeting
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Secure Interdomain Routing 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 30 May 2012 19:17:01 -0000

The wiki page lists very few registrations for the interim meeting one
week from today.

Please do register if you intend to come.

You should also register if you attend to participate remotely.

Registration is by sending an email message to
sidr-chairs+reg06062012@ietf.org.  There is no registration fee.

--Sandy, speaking as wg co-chair

From jgs@juniper.net  Wed May 30 13:53:37 2012
Return-Path: 
X-Original-To: sidr@ietfa.amsl.com
Delivered-To: sidr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 216DE11E809C; Wed, 30 May 2012 13:53:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.58
X-Spam-Level: 
X-Spam-Status: No, score=-6.58 tagged_above=-999 required=5 tests=[AWL=0.019,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XGb4b4cdFtt3; Wed, 30 May 2012 13:53:36 -0700 (PDT)
Received: from exprod7og117.obsmtp.com (exprod7og117.obsmtp.com [64.18.2.6]) by ietfa.amsl.com (Postfix) with ESMTP id 657C821F874F; Wed, 30 May 2012 13:53:32 -0700 (PDT)
Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob117.postini.com ([64.18.6.12]) with SMTP ID DSNKT8aIzKxAs2onG6tCgi6IWl2WpnzfUqpn@postini.com; Wed, 30 May 2012 13:53:36 PDT
Received: from [172.16.13.202] (172.16.13.202) by P-EMHUB01-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server id 8.3.213.0; Wed, 30 May 2012 13:52:20 -0700
MIME-Version: 1.0 (Apple Message framework v1278)
Content-Type: text/plain; charset="us-ascii"
From: "John G. Scudder" 
In-Reply-To: <24B20D14B2CD29478C8D5D6E9CBB29F625F12333@Hermes.columbia.ads.sparta.com>
Date: Wed, 30 May 2012 16:52:19 -0400
Content-Transfer-Encoding: quoted-printable
Message-ID: 
References: <24B20D14B2CD29478C8D5D6E9CBB29F60F70A267@Hermes.columbia.ads.sparta.com> <24B20D14B2CD29478C8D5D6E9CBB29F625F0975D@Hermes.columbia.ads.sparta.com> <4FBBB6D1.9000008@bbn.com>  <4FBC0936.7000905@bbn.com>, <5BA9D6DE-BE0E-4922-9E09-7B85BD6F9342@juniper.net> <24B20D14B2CD29478C8D5D6E9CBB29F625F12333@Hermes.columbia.ads.sparta.com>
To: "Murphy, Sandra" 
X-Mailer: Apple Mail (2.1278)
Cc: "idr@ietf.org List" , "sidr@ietf.org list" 
Subject: Re: [sidr] request for agenda items for interim meeting 6 Jun
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Secure Interdomain Routing 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 30 May 2012 20:53:37 -0000

[added IDR to cc]

On May 30, 2012, at 12:10 PM, Murphy, Sandra wrote:

...
> About extensibility - as you say, any new segment type not built into =
implementations would result in fatal errors.  So any new segment type =
would need to be built into implementations before use.  The question =
then becomes - can the signature attributes also be augmented at the =
same time to deal with the new segment types?
...
> So the AS_PATH extensibility could be maintained in the security =
protections - as long as the new extension is "protectable".

OK, as long as it's practical to extend the BGPSEC_Path_Signatures =
attribute. I confess to not having given this much thought but it =
doesn't appear to be as easily extensible as AS_PATH, because the latter =
has a TLV structure and the former doesn't. I guess your answer is that =
since AS_PATH extensions are in practice a big deal, you'll just =
introduce a new, incompatible format of BGPSEC_Path_Signatures to match? =
If this is the plan, BGPSEC_Path_Signatures should include a version =
number, since it would be a little rude to consume another code point =
from the one-byte BGP path attribute code point space for this purpose. =
Also, for generality you'll need to think about whether you want to be =
able to support different subsets of extensions -- this is easy in a =
TLV-encoded attribute but hard if all you've got is a version number. =
(Another answer might be that Additional_info will serve as the =
extensibility placeholder, but if so its length field is too small.)

...
> I am quite sure I don't know the complete list of AS_PATH knobs!

Nor do I, from memory. But we probably should plan to enumerate a list =
of them so that we can categorize them as "we can do this", "this is =
formally an attack and therefore will never be supported", or "other", =
and then iterate on "other".

> But some of those I do know are hacks that would allow attacks as =
well.  The fact that the security protections prohibit the attacks is a =
good thing.  If there's a way to identify good, not evil, uses, then we =
can design for that.  But in cases where there's no real way to =
distinguish the good from the evil, we're in a hard place.  Shoot a hole =
in the protection to allow the hack or prohibit the hack.

Right, and agreed (see "formally an attack" above). But to repeat my =
further point, if the AS_PATH is present (even if not secured): "at =
least there's scope for a network operator on the receiving end to =
tolerate the validation failure and use the route anyway, if desired. In =
the case where there's no AS_PATH, the data are just gone with no chance =
for appeal."

--John=

From Sandra.Murphy@sparta.com  Wed May 30 14:07:13 2012
Return-Path: 
X-Original-To: sidr@ietfa.amsl.com
Delivered-To: sidr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C894D21F865D for ; Wed, 30 May 2012 14:07:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.549
X-Spam-Level: 
X-Spam-Status: No, score=-102.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7qoEF5md1qes for ; Wed, 30 May 2012 14:07:13 -0700 (PDT)
Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by ietfa.amsl.com (Postfix) with ESMTP id EC8C021F8663 for ; Wed, 30 May 2012 14:07:12 -0700 (PDT)
Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.14.4/8.14.4) with ESMTP id q4UL7Cg1026973; Wed, 30 May 2012 16:07:12 -0500
Received: from Hermes.columbia.ads.sparta.com ([157.185.80.107]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id q4UL7BKr000521; Wed, 30 May 2012 16:07:12 -0500
Received: from HERMES.columbia.ads.sparta.com ([2002:9db9:506b::9db9:506b]) by Hermes.columbia.ads.sparta.com ([::1]) with mapi id 14.01.0355.002; Wed, 30 May 2012 17:07:11 -0400
From: "Murphy, Sandra" 
To: Alexey Melnikov , sidr wg 
Thread-Topic: [sidr] Date and type of the next (end of June/early July) interim
Thread-Index: AQHNOo2tIS7pmKrx8Eie4UfrU9xHSZbi2oV0
Date: Wed, 30 May 2012 21:07:10 +0000
Message-ID: <24B20D14B2CD29478C8D5D6E9CBB29F625F12D2E@Hermes.columbia.ads.sparta.com>
References: <4FBFA992.8020107@isode.com>
In-Reply-To: <4FBFA992.8020107@isode.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [157.185.63.118]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [sidr] Date and type of the next (end of June/early July) interim
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Secure Interdomain Routing 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 30 May 2012 21:07:13 -0000

Not many people  have commented on Alexey's message.=0A=
=0A=
IETF process mandates that a face-face meeting be announced four week ahead=
, which is Friday 1 Jun, if we stay with face-face on 29 Jun.=0A=
=0A=
The subsequent meeting was proposed for 27 Jul, so keep that in mind as wel=
l.=0A=
=0A=
--Sandy=0A=
________________________________________=0A=
From: sidr-bounces@ietf.org [sidr-bounces@ietf.org] on behalf of Alexey Mel=
nikov [alexey.melnikov@isode.com]=0A=
Sent: Friday, May 25, 2012 11:47 AM=0A=
To: sidr wg=0A=
Subject: [sidr] Date and type of the next (end of June/early July) interim=
=0A=
=0A=
Dear WG members,=0A=
The WG needs to decide about the date and type of the next interim=0A=
(after June 6th). The earlier proposal stated June 29th. Are people=0A=
happy with this date or do they want to propose an alternative? Note=0A=
that we are more flexible this time, because this is not tied to any=0A=
other industry event.=0A=
=0A=
We also need to decide on whether this should be a physical interim with=0A=
remote participants or fully virtual interim (e.g. everybody is using=0A=
WebEx or something similar).=0A=
=0A=
Please reply to this message, sending your comments to the mailing list=0A=
or directly to chairs (sidr-chairs@tools.ietf.org).=0A=
=0A=
Best Regards,=0A=
Alexey, on behalf of SIDR chairs.=0A=
=0A=
_______________________________________________=0A=
sidr mailing list=0A=
sidr@ietf.org=0A=
https://www.ietf.org/mailman/listinfo/sidr=0A=

From p.krishnaswamy.ietf@gmail.com  Wed May 30 14:44:40 2012
Return-Path: 
X-Original-To: sidr@ietfa.amsl.com
Delivered-To: sidr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BEE6F11E80D5 for ; Wed, 30 May 2012 14:44:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.598
X-Spam-Level: 
X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NwW8gzCxTWwG for ; Wed, 30 May 2012 14:44:40 -0700 (PDT)
Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id 42C5311E80C5 for ; Wed, 30 May 2012 14:44:40 -0700 (PDT)
Received: by dacx6 with SMTP id x6so341891dac.31 for ; Wed, 30 May 2012 14:44:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=UpN+4ACuwG4ADQIQsh4ZzAZDefnnMAEzm1kt0gfh1ps=; b=E/YHdmZzac2QJPq4/TYMcgqs3pn53yEZNzVy1qHa6dkz6BYenes+ekiFdtiBZloPue k15HdCQEiFYsiLiCedEA1PojhpJVwxL9EwPxQ13uKhE0oN47XIDlifaQDMAgUZGKRFAJ cC555brnZ/M4OR0FBfVHIbxGo+KZeReUcdUET4aT9k9tJ0LpysSZhOGTXzWEpGIRPB4W CbchVbECt39eRI+gaI6d95SfyG2/03kuXSMSU97lUPsizPccPE7tFIr+XxH3y5H00zv4 8XmOS6hGqO4cuM+caxa6hOJayf85bdalJFU8hJ2noR5kowJUey65ejZG9hRmQceKeZM/ xllw==
MIME-Version: 1.0
Received: by 10.68.213.102 with SMTP id nr6mr47943810pbc.112.1338414280067; Wed, 30 May 2012 14:44:40 -0700 (PDT)
Received: by 10.66.87.233 with HTTP; Wed, 30 May 2012 14:44:40 -0700 (PDT)
Date: Wed, 30 May 2012 17:44:40 -0400
Message-ID: 
From: p krishnaswamy 
To: sidr@ietf.org
Content-Type: multipart/alternative; boundary=e89a8ff1ca32b9ca1b04c147db38
Subject: [sidr] are audio archive files for the ietf 83 sessions available?
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Secure Interdomain Routing 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 30 May 2012 21:44:40 -0000

--e89a8ff1ca32b9ca1b04c147db38
Content-Type: text/plain; charset=ISO-8859-1

Hi, I am looking for some detail on the IETF 83 Sidr discussions.

It looked as if   audio proceedings for IETF 83 were  still online as there
is html that says 'audio stream' next to the session times on


http://tools.ietf.org/wg/sidr/minutes




but  when the link for audio stream next to each session time  is clicked,
the  message from whichever player is being used says the file has moved or
does not exist.



Have the audio  files been scrapped (storage etc.)?or did they never exist
because skype didnt work ?





Thanks

Padma Krishnaswamy

--e89a8ff1ca32b9ca1b04c147db38
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hi, I am looking for some detail on the IETF 83 Sidr discussions.



It looked as if=A0=A0 audio proceedings for IETF 83 =
were=A0 still
online as there is html that says 'audio stream' next to the sessio=
n times on 

h=
ttp://tools.ietf.org/wg/sidr/minutes





=A0



but=A0 when the link for
audio stream next to each session time =A0is clicked, th=
e=A0 message from whichever player is being used says
the file has moved or does not exist.



=A0



Have the audio =A0files
been scrapped (storage etc.)?or did they never exist because skype didnt wo=
rk ?





=A0



Thanks



Padma Krishnaswamy





--e89a8ff1ca32b9ca1b04c147db38--

From russw@riw.us  Wed May 30 16:07:09 2012
Return-Path: 
X-Original-To: sidr@ietfa.amsl.com
Delivered-To: sidr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23A7C21F8616 for ; Wed, 30 May 2012 16:07:09 -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=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jSD3ITZFzuAT for ; Wed, 30 May 2012 16:07:08 -0700 (PDT)
Received: from da31.namelessnet.net (da31.namelessnet.net [74.124.205.66]) by ietfa.amsl.com (Postfix) with ESMTP id AB67E21F8615 for ; Wed, 30 May 2012 16:07:08 -0700 (PDT)
Received: from rrcs-24-199-145-66.midsouth.biz.rr.com ([24.199.145.66] helo=[192.168.3.115]) by da31.namelessnet.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77) (envelope-from ) id 1SZryt-0004GE-Tq for sidr@ietf.org; Wed, 30 May 2012 16:07:08 -0700
Message-ID: <4FC6A81C.1090306@riw.us>
Date: Wed, 30 May 2012 19:07:08 -0400
From: Russ White 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1
MIME-Version: 1.0
To: sidr@ietf.org
References: <5BA9D6DE-BE0E-4922-9E09-7B85BD6F9342@juniper.net>   <7309FCBCAE981B43ABBE69B31C8D213921BFA65FD8@EUSAACMS0701.eamcs.ericsson.se> 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Antivirus-Scanner: Seems clean.  You should still use an Antivirus Scanner
Subject: Re: [sidr] BGPSEC proposal to drop AS_PATH [was: Fwd: request	for agenda items for interim meeting 6 Jun]
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Secure Interdomain Routing 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 30 May 2012 23:07:09 -0000

> AS_PATH specifies the ASs through which the routing announcement has
> passed.
> 
>> Signed_AS_PATH is to verify the path that the update message takes.

....

> and here i thought that detecting that they differ, as an attack, is the
> core goal of as-path validation.

Okay, I seem to be confused. The AS Path isn't about where the update
has passed through, but the same attribute, when signed, is a mechanism
to provide security. And while the AS Path isn't about showing the path
of the update or the traffic, when it doesn't match the new attribute
that is supposed to show the path of the update this means there is an
attack of some sort.

Russ

-- 
<><
riwhite@verisign.com
russw@riw.us

From kotikalapudi.sriram@nist.gov  Wed May 30 17:02:46 2012
Return-Path: 
X-Original-To: sidr@ietfa.amsl.com
Delivered-To: sidr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89CDB11E80D5; Wed, 30 May 2012 17:02:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level: 
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0IUWDScthBRv; Wed, 30 May 2012 17:02:46 -0700 (PDT)
Received: from wsget2.nist.gov (wsget2.nist.gov [129.6.13.151]) by ietfa.amsl.com (Postfix) with ESMTP id D34C011E80AD; Wed, 30 May 2012 17:02:45 -0700 (PDT)
Received: from WSXGHUB1.xchange.nist.gov (129.6.18.96) by wsget2.nist.gov (129.6.13.151) with Microsoft SMTP Server (TLS) id 14.1.355.2; Wed, 30 May 2012 20:02:27 -0400
Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB1.xchange.nist.gov ([129.6.18.96]) with mapi; Wed, 30 May 2012 20:02:44 -0400
From: "Sriram, Kotikalapudi" 
To: "John G. Scudder" , "Murphy, Sandra" 
Date: Wed, 30 May 2012 20:02:44 -0400
Thread-Topic: [sidr] request for agenda items for interim meeting 6 Jun
Thread-Index: Ac0+phsg3Zu8y1qPTlqxOc9z76et7QACu8rw
Message-ID: 
References: <24B20D14B2CD29478C8D5D6E9CBB29F60F70A267@Hermes.columbia.ads.sparta.com> <24B20D14B2CD29478C8D5D6E9CBB29F625F0975D@Hermes.columbia.ads.sparta.com> <4FBBB6D1.9000008@bbn.com>  <4FBC0936.7000905@bbn.com>, <5BA9D6DE-BE0E-4922-9E09-7B85BD6F9342@juniper.net> <24B20D14B2CD29478C8D5D6E9CBB29F625F12333@Hermes.columbia.ads.sparta.com> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Cc: "idr@ietf.org List" , "sidr@ietf.org list" 
Subject: Re: [sidr] request for agenda items for interim meeting 6 Jun
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Secure Interdomain Routing 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 31 May 2012 00:02:46 -0000

>
>Right, and agreed (see "formally an attack" above). But to repeat my further
>point, if the AS_PATH is present (even if not secured): "at least there's scope for a
>network operator on the receiving end to tolerate the validation failure and use
>the route anyway, if desired. In the case where there's no AS_PATH, the data are
>just gone with no chance for appeal."
>

John,

I do not agree that in the event of "validation failure" the route becomes unusable
in BGPSEC as currently specified.
The operator has a choice to consider and select a route as best path (or as add-path)
even if the update failed validation or validation was deferred.
(Note: Validation may not be deferred sometimes due to 
processor overload, or known RPKI staleness, etc.)

You seem to be suggesting that when there is "validation failure",
then "BGPSEC_Path_Signatures" as whole is unusable. 
That is not the case.

"BGPSEC_Path_Signatures" is just a name given to the outer shell of
the BGPSEC update. (BGPSEC need not give the outer shell any name at all.) 
Within it, we have these segments: Secure_Path, Sig_Block, and Additional_Info.
Each of these segments has its own proper semantics.
Even if the Sig_Block were to have an invalid signature, 
the Secure_Path segment is still usable as it provides the AS path info.
If the operator chose an _Invalid_ update for lack of a better choice, 
then it is still the Secure_Path that provides the AS path info,
and also the update SHOULD be signed and propagated to other BGPSEC peers.
Also, if a specific eBGP neighbor is a non-bgpsec speaker, then the selected
BGPSEC update (valid or invalid) is converted to a regular BGP-4 update wherein 
the AS_PATH attribute is constructed from the Secure_Path. 
So validation failure in BGPSEC does not mean that "the data are just gone."

In fact, for clarity sake I would like to suggest that in the spec we consider
Secure_Path, Sig_Block, and Additional_Info as distinct BGPSEC attributes.
(That is to say we should not lump them together as one attribute.)

Sriram   

From rogaglia@cisco.com  Thu May 31 06:38:57 2012
Return-Path: 
X-Original-To: sidr@ietfa.amsl.com
Delivered-To: sidr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2079221F869A for ; Thu, 31 May 2012 06:38:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Level: 
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GFiR3fwk5Cqa for ; Thu, 31 May 2012 06:38:56 -0700 (PDT)
Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 4BEDF21F8675 for ; Thu, 31 May 2012 06:38:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rogaglia@cisco.com; l=8583; q=dns/txt; s=iport; t=1338471536; x=1339681136; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=Fiws1TuMtkxKS8/1Mb2KqRDXu92fMV7xOQMZ2kPdhFU=; b=h6PuoWkLv5pwMUiHv42I3Jer6dETOCW+TwWJjgGMnAWoI5wRWJRsFok1 2I/q4H2PuD6/Ec3xEYAWD5cMScUhqSGAHhLN6Jbl8cCNMofet2PjSlB8c PzzG9dVToUn9YGFjHL2gZRaHgSGv6kr6JPM6A5N3b8+zLFaAqqE5DH4bm g=;
X-Files: smime.p7s : 4389
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av8EAGhzx0+tJV2b/2dsb2JhbABEtAuBB4IYAQEBAwEBAQEPAVsLBQsCAQgRBAEBLwIlCx0IAgQOBQ4Uh2QFC5kNn2EEixGEZmADjjWBHYVGjg2BZoJg
X-IronPort-AV: E=Sophos;i="4.75,692,1330905600";  d="p7s'?scan'208";a="88299025"
Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-7.cisco.com with ESMTP; 31 May 2012 13:38:55 +0000
Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com [173.36.12.86]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id q4VDctGR017785 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 31 May 2012 13:38:55 GMT
Received: from xmb-rcd-x01.cisco.com ([169.254.1.61]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.02.0298.004; Thu, 31 May 2012 08:38:55 -0500
From: "Roque Gagliano (rogaglia)" 
To: Alexey Melnikov 
Thread-Topic: [sidr] Date and type of the next (end of June/early July) interim
Thread-Index: AQHNPzK499bpI6QRqUKxoHGwyWcDdg==
Date: Thu, 31 May 2012 13:38:54 +0000
Message-ID: <303ED97F-C935-45B7-A624-D74A746E4638@cisco.com>
References: <4FBFA992.8020107@isode.com> <24B20D14B2CD29478C8D5D6E9CBB29F625F12D2E@Hermes.columbia.ads.sparta.com>
In-Reply-To: <24B20D14B2CD29478C8D5D6E9CBB29F625F12D2E@Hermes.columbia.ads.sparta.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
x-originating-ip: [10.147.19.47]
x-tm-as-product-ver: SMEX-10.2.0.1135-6.800.1017-18938.006
x-tm-as-result: No--42.708400-8.000000-31
x-tm-as-user-approved-sender: No
x-tm-as-user-blocked-sender: No
Content-Type: multipart/signed; boundary="Apple-Mail-191--612919618"; protocol="application/pkcs7-signature"; micalg=sha1
MIME-Version: 1.0
Cc: "Murphy, Sandra" , sidr wg 
Subject: Re: [sidr] Date and type of the next (end of June/early July) interim
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Secure Interdomain Routing 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 31 May 2012 13:38:57 -0000

--Apple-Mail-191--612919618
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

Hi Alexey,

I would like to propose to have a test for a virtual-only meeting.=20

I understand that we want to keep interims very dynamic in a whiteboard =
style. But, having participated remotely for a couple of hours in the =
previous meeting, this is very hard for remote participants (internal =
conversations, been able to jump into the flow, presenting, etc.)

So, having a virtual-only meeting will be different as you normally =
requires more preparation work and moderators needs to be more active to =
make sure we get the work done.

Roque




On May 30, 2012, at 11:07 PM, Murphy, Sandra wrote:

> Not many people  have commented on Alexey's message.
>=20
> IETF process mandates that a face-face meeting be announced four week =
ahead, which is Friday 1 Jun, if we stay with face-face on 29 Jun.
>=20
> The subsequent meeting was proposed for 27 Jul, so keep that in mind =
as well.
>=20
> --Sandy
> ________________________________________
> From: sidr-bounces@ietf.org [sidr-bounces@ietf.org] on behalf of =
Alexey Melnikov [alexey.melnikov@isode.com]
> Sent: Friday, May 25, 2012 11:47 AM
> To: sidr wg
> Subject: [sidr] Date and type of the next (end of June/early July) =
interim
>=20
> Dear WG members,
> The WG needs to decide about the date and type of the next interim
> (after June 6th). The earlier proposal stated June 29th. Are people
> happy with this date or do they want to propose an alternative? Note
> that we are more flexible this time, because this is not tied to any
> other industry event.
>=20
> We also need to decide on whether this should be a physical interim =
with
> remote participants or fully virtual interim (e.g. everybody is using
> WebEx or something similar).
>=20
> Please reply to this message, sending your comments to the mailing =
list
> or directly to chairs (sidr-chairs@tools.ietf.org).
>=20
> Best Regards,
> Alexey, on behalf of SIDR chairs.
>=20
> _______________________________________________
> sidr mailing list
> sidr@ietf.org
> https://www.ietf.org/mailman/listinfo/sidr
> _______________________________________________
> sidr mailing list
> sidr@ietf.org
> https://www.ietf.org/mailman/listinfo/sidr


--Apple-Mail-191--612919618
Content-Disposition: attachment; filename="smime.p7s"
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMXDCCBWYw
ggROoAMCAQICEDG+eY7Bhz6hDsSIPCMJYUYwDQYJKoZIhvcNAQEFBQAwgd0xCzAJBgNVBAYTAlVT
MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y
azE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEg
KGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24g
Q2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMzAeFw0xMjA1MDgwMDAwMDBaFw0x
MzA1MTEyMzU5NTlaMIIBEzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT
aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9S
UEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMpOTgxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZh
bGlkYXRlZDEzMDEGA1UECxMqRGlnaXRhbCBJRCBDbGFzcyAxIC0gTmV0c2NhcGUgRnVsbCBTZXJ2
aWNlMRcwFQYDVQQDFA5Sb3F1ZSBHYWdsaWFubzEhMB8GCSqGSIb3DQEJARYScm9nYWdsaWFAY2lz
Y28uY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAs+CGyKUNmmBJ4PgQDVA8hF5E
ByrcJ8BQ2C8mSv3vSZqCZNXAyte/JRsl11BJmqwdLiH6baDaJbBKRzNFfaf8Wwe8aS3QvqpHfKtU
pYvn+EKseVnXsIKssRV2AwNODN6VMwSA72Jiolo3z4xeoeLw9X/CnFYTJa4AcGM1LKk+rMGTQlly
XXl+qc7LeAd+wk7bKsUFmg4uCfvCDhVSQj25S5tnmFl5WPGD2u7QEa2WLkkL5nH+BEedZmRejRgP
smmAxDfBX1FVTnCOgz75hNFlrnkYJfPCXLRyfPHvaIGP/NBz6TJbwB3YZSweYHxWAEMglqgRvqIW
3Tr5k5x9yyNYVQIDAQABo4HoMIHlMAkGA1UdEwQCMAAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcX
ATAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1UdDwQEAwIF
oDAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwFAYKYIZIAYb4RQEGBwQGFgROb25lMFAG
A1UdHwRJMEcwRaBDoEGGP2h0dHA6Ly9pbmRjMWRpZ2l0YWxpZC1nMy1jcmwudmVyaXNpZ24uY29t
L0luZEMxRGlnaXRhbElELUczLmNybDANBgkqhkiG9w0BAQUFAAOCAQEAuFfFZrObA9gprpHyG6cq
O4UZjtN5/moV6mUYbt+ffGrXMbVt06vgnba7r6ldS5eWPQZZQtAAKKqweAmZY37ZcvVQwDsMXOMG
4+MN60sPVKwrrSQz9xXcImVCzBxFsq22S4el6pGx38xytsPgKw4cs8ZVxPLEjZtcOGnl8R8fak2g
WyAMt8zkIxu/84zcobhcY5EEPJxYg9WKHi617fD6/jjQqvwvW4zi2XkIjw+HpZSwdPxk2+Cg6id4
SS6WlTwe90rdJmRrCP4gTXyJOdARR7hJU714lamn9QdQuPX7WLJXuMmoyrhvZZUeHpvodO/eNiO2
KvxMUu0uXWiDcDgTvzCCBu4wggXWoAMCAQICEHEVZgVK5JEhTem8RPms09wwDQYJKoZIhvcNAQEF
BQAwgcoxCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVy
aVNpZ24gVHJ1c3QgTmV0d29yazE6MDgGA1UECxMxKGMpIDE5OTkgVmVyaVNpZ24sIEluYy4gLSBG
b3IgYXV0aG9yaXplZCB1c2Ugb25seTFFMEMGA1UEAxM8VmVyaVNpZ24gQ2xhc3MgMSBQdWJsaWMg
UHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSAtIEczMB4XDTA5MDUwMTAwMDAwMFoXDTE5
MDQzMDIzNTk1OVowgd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0G
A1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0
dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZh
bGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIg
Q0EgLSBHMzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAO3ER98qKB18Bmu71yEyyWwT
j+mxjUFONPfaC+Nq+mWIIAsRE+mb4ElOi2/VAdBfDUeRilpMdD4/xpEJu0w0no1uoYJRYvdpdliW
B6+eFBgHT1q9n9IxslQZc0ZqGUIR7BJzIY313DDN5dlWCjHFNm0pFJe9LdqJRxmI2EsEPeu2PGce
dAATDdCG2pNn+DMDrho8a2l49sAsjuGDP3f5mf/+n1JawrSHCthsqUfBVCllQz5KwJYfwa33d69s
sQRevsG2lC2XkC0n0rse6YNqhPbEsq4jBmUmpSdYKwcitG+mYkgad/LVUCeaKdOW+yj1uiR2YuOM
Wev7btVCxL5Bx/UCAwEAAaOCArkwggK1MDQGCCsGAQUFBwEBBCgwJjAkBggrBgEFBQcwAYYYaHR0
cDovL29jc3AudmVyaXNpZ24uY29tMBIGA1UdEwEB/wQIMAYBAf8CAQAwcAYDVR0gBGkwZzBlBgtg
hkgBhvhFAQcXATBWMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vY3BzMCoG
CCsGAQUFBwICMB4aHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEwNAYDVR0fBC0wKzApoCeg
JYYjaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS1nMy5jcmwwDgYDVR0PAQH/BAQDAgEGMG4G
CCsGAQUFBwEMBGIwYKFeoFwwWjBYMFYWCWltYWdlL2dpZjAhMB8wBwYFKw4DAhoEFEtruSiWBgy7
0FI4mymsSweLIQUYMCYWJGh0dHA6Ly9sb2dvLnZlcmlzaWduLmNvbS92c2xvZ28xLmdpZjAuBgNV
HREEJzAlpCMwITEfMB0GA1UEAxMWUHJpdmF0ZUxhYmVsNC0yMDQ4LTExODAdBgNVHQ4EFgQUeUdh
CEH9OASiS+e1zPVD9kkrEfgwgfEGA1UdIwSB6TCB5qGB0KSBzTCByjELMAkGA1UEBhMCVVMxFzAV
BgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTow
OAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5
MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24g
QXV0aG9yaXR5IC0gRzOCEQCLW3VWhFSFCwDPrzhIzrGkMA0GCSqGSIb3DQEBBQUAA4IBAQA5Tc9B
mYG1qQW1UjjpOYSJbOQ0qFrn2GwJTCQaulmkhztzIfGTgc+/aGNaZ/41hSuhw12jSsI6Gd0w1sxN
7/HSgZfKVFpDvzeLeo4ZjQ9DqIzyr2CzFYqzlZw84J6zJ5ikNXIX5fwqXYfTig3C0UUq+MD0rCqT
OtWuEnAI6/s74nfs6CtkNXbNutrg0csU1nFYm77VPn222egkxSRmTF2RH3azFz5/DcYhiS+zN7ih
/1yybUneZVJC+w6I0u1KHb9L4/jMcvpIDmWOScjW+JmYO7eUPjFxBof6bFlTLtffK+1fYwCsFe0D
uFUWjMZoA+ciqHMLsbyg2lJY3QoOf8GCMYIEizCCBIcCAQEwgfIwgd0xCzAJBgNVBAYTAlVTMRcw
FQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7
MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMp
MDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xh
c3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMwIQMb55jsGHPqEOxIg8IwlhRjAJBgUr
DgMCGgUAoIICbTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMjA1
MzExMzM4NTNaMCMGCSqGSIb3DQEJBDEWBBR8SOo0TogBapEtCtNzBLau0o2IGDCCAQMGCSsGAQQB
gjcQBDGB9TCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD
VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0
cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFs
aWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBD
QSAtIEczAhAxvnmOwYc+oQ7EiDwjCWFGMIIBBQYLKoZIhvcNAQkQAgsxgfWggfIwgd0xCzAJBgNV
BAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3Qg
TmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNv
bS9ycGEgKGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVy
aVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMwIQMb55jsGHPqEOxIg8
IwlhRjANBgkqhkiG9w0BAQEFAASCAQA5WNFNX/NwMUT2S3AFPP0+ago4VkQGymiGe2fblJBiERms
UNgCsxEkmn9N7u+9n4zH8U527Xks5hfFp9yFMstVAimgc7GTvfKObqU05By0BRtkods/UELcyBKb
4+swqyCpRSeHNiiWvKagqC1aknknC0K/ln1qyVNi6VxfNNmHKnDXqZDuv1iIU9bZPicRMILwCZxr
rKjAAbMOlfbhD7Q2Rl3DHVhb3UEVFJzeFym7I9nGQmbBUChfWZKSx9mzF4LH57cjdeT28Q+ygjYo
eid+cQ8IzOSbG3L+EmTaBOlgXzq+42Pr3TEBuD+sNXLS3IrIGoEmB4JkaMVe5EW5OJLWAAAAAAAA

--Apple-Mail-191--612919618--

From wwwrun@rfc-editor.org  Thu May 31 07:56:27 2012
Return-Path: 
X-Original-To: sidr@ietfa.amsl.com
Delivered-To: sidr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D3E521F86CF for ; Thu, 31 May 2012 07:56:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.473
X-Spam-Level: 
X-Spam-Status: No, score=-102.473 tagged_above=-999 required=5 tests=[AWL=0.127, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0IYPMdc5VaNU for ; Thu, 31 May 2012 07:56:26 -0700 (PDT)
Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 5EB0721F86BD for ; Thu, 31 May 2012 07:56:26 -0700 (PDT)
Received: by rfc-editor.org (Postfix, from userid 30) id F363272E004; Thu, 31 May 2012 07:55:43 -0700 (PDT)
To: gih@apnic.net, ggm@apnic.net, robertl@apnic.net, stbryant@cisco.com, adrian@olddog.co.uk, alexey.melnikov@isode.com, Sandra.Murphy@sparta.com, morrowc@ops-netman.net
From: RFC Errata System 
Message-Id: <20120531145543.F363272E004@rfc-editor.org>
Date: Thu, 31 May 2012 07:55:43 -0700 (PDT)
Cc: rfc-editor@rfc-editor.org, sidr@ietf.org
Subject: [sidr] [Technical Errata Reported] RFC6487 (3238)
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Secure Interdomain Routing 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 31 May 2012 14:56:27 -0000

The following errata report has been submitted for RFC6487,
"A Profile for X.509 PKIX Resource Certificates".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=6487&eid=3238

--------------------------------------
Type: Technical
Reported by: Stephen Kent 

Section: 6.3

Original Text
-------------
 ExtendedKeyUsage
         The CA MAY honor ExtendedKeyUsage extensions of keyCertSign and
         cRLSign if present, as long as this is consistent with the
         BasicConstraints SubjectType sub-field, when specified.

Corrected Text
--------------
 ExtendedKeyUsage
         The CA MAY honor ExtendedKeyUsage extensions in requests for EE
         certificates that are issued to routers or other devices, consistent with values
         specified in Standards Track RFCs that adopt this profile and that identify
         application-specific requirements that motivate the use of such EKUs.

Notes
-----
The current text appears to be the result of a "cut and paste" error. It is essentially identical to the text 
for the Key Usage extension, and names two fields that appear in that extension, not in an EKU extension. The text I propose above parallels what appears in Section 4.8.5, which describes how an
 EKU MAY be used in RPKI certificates.

Instructions:
-------------
This errata is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party (IESG)
can log in to change the status and edit the report, if necessary. 

--------------------------------------
RFC6487 (draft-ietf-sidr-res-certs-22)
--------------------------------------
Title               : A Profile for X.509 PKIX Resource Certificates
Publication Date    : February 2012
Author(s)           : G. Huston, G. Michaelson, R. Loomans
Category            : PROPOSED STANDARD
Source              : Secure Inter-Domain Routing
Area                : Routing
Stream              : IETF
Verifying Party     : IESG

From Sandra.Murphy@sparta.com  Thu May 31 08:09:20 2012
Return-Path: 
X-Original-To: sidr@ietfa.amsl.com
Delivered-To: sidr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 486DD21F879E for ; Thu, 31 May 2012 08:09:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.553
X-Spam-Level: 
X-Spam-Status: No, score=-102.553 tagged_above=-999 required=5 tests=[AWL=0.044, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x6CwcHyTcML1 for ; Thu, 31 May 2012 08:09:19 -0700 (PDT)
Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by ietfa.amsl.com (Postfix) with ESMTP id 74D6321F879A for ; Thu, 31 May 2012 08:09:16 -0700 (PDT)
Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.14.4/8.14.4) with ESMTP id q4VF9E8c000356; Thu, 31 May 2012 10:09:14 -0500
Received: from Hermes.columbia.ads.sparta.com ([157.185.80.107]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id q4VF9BNl017572; Thu, 31 May 2012 10:09:14 -0500
Received: from HERMES.columbia.ads.sparta.com ([2002:9db9:506b::9db9:506b]) by Hermes.columbia.ads.sparta.com ([::1]) with mapi id 14.01.0355.002; Thu, 31 May 2012 11:09:10 -0400
From: "Murphy, Sandra" 
To: p krishnaswamy , "sidr@ietf.org" 
Thread-Topic: [sidr] are audio archive files for the ietf 83 sessions available?
Thread-Index: AQHNPq1uZTddfKg6vUmuarCfD41Z/5bj+t0H
Date: Thu, 31 May 2012 15:09:10 +0000
Message-ID: <24B20D14B2CD29478C8D5D6E9CBB29F625F12E8B@Hermes.columbia.ads.sparta.com>
References: 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [157.185.63.118]
Content-Type: multipart/alternative; boundary="_000_24B20D14B2CD29478C8D5D6E9CBB29F625F12E8BHermescolumbiaa_"
MIME-Version: 1.0
Subject: Re: [sidr] are audio archive files for the ietf 83 sessions available?
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Secure Interdomain Routing 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 31 May 2012 15:09:20 -0000

--_000_24B20D14B2CD29478C8D5D6E9CBB29F625F12E8BHermescolumbiaa_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Speaking as regular ol' member

I find audio files at
http://www.ietf.org/audio/ietf83/ietf83-241-20120326-1256-pm.mp3
and
http://www.ietf.org/audio/ietf83/ietf83-241-20120328-0855-am.mp3
that work for me.

Are those the files you were trying to access?  If not, do these work for y=
ou?

I got there from the ietf home page by:
Proceedings
IETF83
Routing Area
sidr
Audio Archives

That got me to a page that lists all the mp3s for all working groups.

Figuring out which are the sidr archives means knowing the room, date and t=
ime that sidr met.  You can get that from the agenda that is at the top of =
the ietf83 page.

The IETF audio archives are taken from the room audio, not any telecon that=
 is part of the wg meeting.  (I praise and thank the volunteers that manage=
 to get the venue audio patched into the web stream and the audio archive, =
btw.)  So anything spoken at or near a mike is archived for posterity (*) b=
ut audio from remote participants needs to be broadcast near a mike.

--Sandy, speaking as regular ol' wg member

(*) The mikes are on and being archived even during breaks, something to ke=
ep in mind.
________________________________
From: sidr-bounces@ietf.org [sidr-bounces@ietf.org] on behalf of p krishnas=
wamy [p.krishnaswamy.ietf@gmail.com]
Sent: Wednesday, May 30, 2012 5:44 PM
To: sidr@ietf.org
Subject: [sidr] are audio archive files for the ietf 83 sessions available?

Hi, I am looking for some detail on the IETF 83 Sidr discussions.
It looked as if   audio proceedings for IETF 83 were  still online as there=
 is html that says 'audio stream' next to the session times on

http://tools.ietf.org/wg/sidr/minutes


but  when the link for audio stream next to each session time  is clicked, =
the  message from whichever player is being used says the file has moved or=
 does not exist.

Have the audio  files been scrapped (storage etc.)?or did they never exist =
because skype didnt work ?



Thanks
Padma Krishnaswamy


--_000_24B20D14B2CD29478C8D5D6E9CBB29F625F12E8BHermescolumbiaa_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable








Speaking as regular ol' member



I find audio files at

http://www.ietf.org/audio/ietf83/ietf83-241-20120326-12=
56-pm.mp3

and

http://www.ietf.org/audio/ietf83/ietf83-241-20120328-08=
55-am.mp3

that work for me.



Are those the files you were trying to access?  If not, do these work =
for you?



I got there from the ietf home page by:

Proceedings

IETF83

Routing Area

sidr

Audio Archives



That got me to a page that lists all the mp3s for all working groups.



Figuring out which are the sidr archives means knowing the room, date and t=
ime that sidr met.  You can get that from the agenda that is at the to=
p of the ietf83 page.



The IETF audio archives are taken from the room audio, not any telecon that=
 is part of the wg meeting.  (I praise and thank the volunteers that m=
anage to get the venue audio patched into the web stream and the audio arch=
ive, btw.)  So anything spoken at or
 near a mike is archived for posterity (*) but audio from remote participan=
ts needs to be broadcast near a mike.



--Sandy, speaking as regular ol' wg member



(*) The mikes are on and being archived even during breaks, something to ke=
ep in mind.




From: sidr-bounces@ietf.org [sidr-bounces=
@ietf.org] on behalf of p krishnaswamy [p.krishnaswamy.ietf@gmail.com]

Sent: Wednesday, May 30, 2012 5:44 PM

To: sidr@ietf.org

Subject: [sidr] are audio archive files for the ietf 83 sessions ava=
ilable?








Hi, I am looking for some detail on the IETF 83 Sidr discussions.


It looked as if   audio proceedings for IE=
TF 83 were  still online as there is html that says 'audio stream' nex=
t to the session times on










http://tools.ietf.org/wg/sidr/min=
utes




 


but  when the link for =
audio stream next to each session time
 is clicked, the  message from whichever =
player is being used says the file has moved or does not exist.


 


Have the audio  files b=
een scrapped (storage etc.)?or did they never exist because skype didnt wor=
k ?









 


Thanks


Padma Krishnaswamy












--_000_24B20D14B2CD29478C8D5D6E9CBB29F625F12E8BHermescolumbiaa_--

From Sandra.Murphy@sparta.com  Thu May 31 08:25:53 2012
Return-Path: 
X-Original-To: sidr@ietfa.amsl.com
Delivered-To: sidr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F407321F8776 for ; Thu, 31 May 2012 08:25:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.558
X-Spam-Level: 
X-Spam-Status: No, score=-102.558 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RQ8U1coTawfT for ; Thu, 31 May 2012 08:25:51 -0700 (PDT)
Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by ietfa.amsl.com (Postfix) with ESMTP id 72F5911E80B7 for ; Thu, 31 May 2012 08:25:51 -0700 (PDT)
Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.14.4/8.14.4) with ESMTP id q4VFPnWx000618; Thu, 31 May 2012 10:25:49 -0500
Received: from Hermes.columbia.ads.sparta.com ([157.185.80.107]) by Beta5.sparta.com (8.13.8/8.13.8) with ESMTP id q4VFPmM0018317; Thu, 31 May 2012 10:25:49 -0500
Received: from HERMES.columbia.ads.sparta.com ([2002:9db9:506b::9db9:506b]) by Hermes.columbia.ads.sparta.com ([::1]) with mapi id 14.01.0355.002; Thu, 31 May 2012 11:25:48 -0400
From: "Murphy, Sandra" 
To: p krishnaswamy , "sidr@ietf.org" 
Thread-Topic: [sidr] are audio archive files for the ietf 83 sessions available?
Thread-Index: AQHNPq1uZTddfKg6vUmuarCfD41Z/5bj+t0HgAAHRKY=
Date: Thu, 31 May 2012 15:25:48 +0000
Message-ID: <24B20D14B2CD29478C8D5D6E9CBB29F625F12EBC@Hermes.columbia.ads.sparta.com>
References: , <24B20D14B2CD29478C8D5D6E9CBB29F625F12E8B@Hermes.columbia.ads.sparta.com>
In-Reply-To: <24B20D14B2CD29478C8D5D6E9CBB29F625F12E8B@Hermes.columbia.ads.sparta.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [157.185.63.118]
Content-Type: multipart/alternative; boundary="_000_24B20D14B2CD29478C8D5D6E9CBB29F625F12EBCHermescolumbiaa_"
MIME-Version: 1.0
Subject: Re: [sidr] are audio archive files for the ietf 83 sessions available?
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Secure Interdomain Routing 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 31 May 2012 15:25:53 -0000

--_000_24B20D14B2CD29478C8D5D6E9CBB29F625F12EBCHermescolumbiaa_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Speaking as regular ol' member:

The link to the audio stream archive on the tools page is generated by the =
tools site, and probably before audio files are assembled into the formal p=
roceedings page.

Why?  In times past, the archives were collected in one place during the me=
eting and physically moved after the meeting.  It looks like the tools site=
 has not been updated with the new location.

I'll let the secretariat/tools team know.

--Sandy, speaking as regular ol' member

________________________________
From: sidr-bounces@ietf.org [sidr-bounces@ietf.org] on behalf of Murphy, Sa=
ndra [Sandra.Murphy@sparta.com]
Sent: Thursday, May 31, 2012 11:09 AM
To: p krishnaswamy; sidr@ietf.org
Subject: Re: [sidr] are audio archive files for the ietf 83 sessions availa=
ble?

Speaking as regular ol' member

I find audio files at
http://www.ietf.org/audio/ietf83/ietf83-241-20120326-1256-pm.mp3
and
http://www.ietf.org/audio/ietf83/ietf83-241-20120328-0855-am.mp3
that work for me.

Are those the files you were trying to access?  If not, do these work for y=
ou?

I got there from the ietf home page by:
Proceedings
IETF83
Routing Area
sidr
Audio Archives

That got me to a page that lists all the mp3s for all working groups.

Figuring out which are the sidr archives means knowing the room, date and t=
ime that sidr met.  You can get that from the agenda that is at the top of =
the ietf83 page.

The IETF audio archives are taken from the room audio, not any telecon that=
 is part of the wg meeting.  (I praise and thank the volunteers that manage=
 to get the venue audio patched into the web stream and the audio archive, =
btw.)  So anything spoken at or near a mike is archived for posterity (*) b=
ut audio from remote participants needs to be broadcast near a mike.

--Sandy, speaking as regular ol' wg member

(*) The mikes are on and being archived even during breaks, something to ke=
ep in mind.
________________________________
From: sidr-bounces@ietf.org [sidr-bounces@ietf.org] on behalf of p krishnas=
wamy [p.krishnaswamy.ietf@gmail.com]
Sent: Wednesday, May 30, 2012 5:44 PM
To: sidr@ietf.org
Subject: [sidr] are audio archive files for the ietf 83 sessions available?

Hi, I am looking for some detail on the IETF 83 Sidr discussions.
It looked as if   audio proceedings for IETF 83 were  still online as there=
 is html that says 'audio stream' next to the session times on

http://tools.ietf.org/wg/sidr/minutes


but  when the link for audio stream next to each session time  is clicked, =
the  message from whichever player is being used says the file has moved or=
 does not exist.

Have the audio  files been scrapped (storage etc.)?or did they never exist =
because skype didnt work ?



Thanks
Padma Krishnaswamy


--_000_24B20D14B2CD29478C8D5D6E9CBB29F625F12EBCHermescolumbiaa_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable








Speaking as regular ol' member:



The link to the audio stream archive on the tools page is generated by the =
tools site, and probably before audio files are assembled into the formal p=
roceedings page. 




Why?  In times past, the archives were collected in one place during t=
he meeting and physically moved after the meeting.  It looks like the =
tools site has not been updated with the new location.



I'll let the secretariat/tools team know.



--Sandy, speaking as regular ol' member






From: sidr-bounces@ietf.org [sidr-bounces@=
ietf.org] on behalf of Murphy, Sandra [Sandra.Murphy@sparta.com]

Sent: Thursday, May 31, 2012 11:09 AM

To: p krishnaswamy; sidr@ietf.org

Subject: Re: [sidr] are audio archive files for the ietf 83 sessions=
 available?










Speaking as regular ol' member



I find audio files at

http://www.ietf.org/audio/ietf83/ietf83-241-20120326-12=
56-pm.mp3

and

http://www.ietf.org/audio/ietf83/ietf83-241-20120328-08=
55-am.mp3

that work for me.



Are those the files you were trying to access?  If not, do these work =
for you?



I got there from the ietf home page by:

Proceedings

IETF83

Routing Area

sidr

Audio Archives



That got me to a page that lists all the mp3s for all working groups.



Figuring out which are the sidr archives means knowing the room, date and t=
ime that sidr met.  You can get that from the agenda that is at the to=
p of the ietf83 page.



The IETF audio archives are taken from the room audio, not any telecon that=
 is part of the wg meeting.  (I praise and thank the volunteers that m=
anage to get the venue audio patched into the web stream and the audio arch=
ive, btw.)  So anything spoken at or
 near a mike is archived for posterity (*) but audio from remote participan=
ts needs to be broadcast near a mike.



--Sandy, speaking as regular ol' wg member



(*) The mikes are on and being archived even during breaks, something to ke=
ep in mind.






From: sidr-bounces@ietf.org [sidr-bounces@i=
etf.org] on behalf of p krishnaswamy [p.krishnaswamy.ietf@gmail.com]

Sent: Wednesday, May 30, 2012 5:44 PM

To: sidr@ietf.org

Subject: [sidr] are audio archive files for the ietf 83 sessions ava=
ilable?








Hi, I am looking for some detail on the IETF 83 Sidr discussions.


It looked as if   audio proceedings for IE=
TF 83 were  still online as there is html that says 'audio stream' nex=
t to the session times on










http://tools.ietf.org/wg/sidr/min=
utes




 


but  when the link for =
audio stream next to each session time
 is clicked, the  message from whichever =
player is being used says the file has moved or does not exist.


 


Have the audio  files b=
een scrapped (storage etc.)?or did they never exist because skype didnt wor=
k ?









 


Thanks


Padma Krishnaswamy


















--_000_24B20D14B2CD29478C8D5D6E9CBB29F625F12EBCHermescolumbiaa_--

From rogaglia@cisco.com  Thu May 31 08:29:20 2012
Return-Path: 
X-Original-To: sidr@ietfa.amsl.com
Delivered-To: sidr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1934D11E80CF for ; Thu, 31 May 2012 08:29:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Level: 
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3lNaFMX2vV8b for ; Thu, 31 May 2012 08:29:19 -0700 (PDT)
Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id CB8FA11E80C8 for ; Thu, 31 May 2012 08:29:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=rogaglia@cisco.com; l=9013; q=dns/txt; s=iport; t=1338478159; x=1339687759; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=C0MMvo7CNRQtwIp1UqI0YMQDSbZwMeg2hFNmupzDEEs=; b=fnydJX9hRji5pZLfm56D8z/Hfu3jfwYpqC11dLl3nVqxE8e/XOgUecmU DHCXmlk7xDZgmgL8lQVrM9ROnQ4iyOtjymV21XUErJNBMHSFOToqwEc3/ OuIqu/3tAlnf29ROOcdwsGobdOEUevaSY8zPDKp9TLN05ppKhXtASzb0u Q=;
X-Files: smime.p7s : 4389
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av8EAOWNx0+tJXG+/2dsb2JhbAAqEAq0DIEHghgBAQEDAQEBAQ8BWxALAgEIRgIlCyUCBBMOFIdkBQspmQafWosREIRWYAOONYEdhUaODYFmgmBv
X-IronPort-AV: E=Sophos;i="4.75,693,1330905600";  d="p7s'?scan'208";a="88328598"
Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-6.cisco.com with ESMTP; 31 May 2012 15:29:18 +0000
Received: from xhc-rcd-x07.cisco.com (xhc-rcd-x07.cisco.com [173.37.183.81]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id q4VFTIB3018993 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 31 May 2012 15:29:18 GMT
Received: from xmb-rcd-x01.cisco.com ([169.254.1.61]) by xhc-rcd-x07.cisco.com ([173.37.183.81]) with mapi id 14.02.0298.004; Thu, 31 May 2012 10:29:18 -0500
From: "Roque Gagliano (rogaglia)" 
To: "sidr@ietf.org" 
Thread-Topic: [sidr] [Technical Errata Reported] RFC6487 (3238)
Thread-Index: AQHNP0IkceACaXSj0EiHfTbYAW7KLA==
Date: Thu, 31 May 2012 15:29:17 +0000
Message-ID: <2BAE4694-60C2-4301-BFAF-05DF49054BF4@cisco.com>
References: <20120531145543.F363272E004@rfc-editor.org>
In-Reply-To: <20120531145543.F363272E004@rfc-editor.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
x-originating-ip: [10.147.19.47]
x-tm-as-product-ver: SMEX-10.2.0.1135-6.800.1017-18938.006
x-tm-as-result: No--35.653900-8.000000-31
x-tm-as-user-approved-sender: No
x-tm-as-user-blocked-sender: No
Content-Type: multipart/signed; boundary="Apple-Mail-293--606296011"; protocol="application/pkcs7-signature"; micalg=sha1
MIME-Version: 1.0
Subject: Re: [sidr] [Technical Errata Reported] RFC6487 (3238)
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Secure Interdomain Routing 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 31 May 2012 15:29:20 -0000

--Apple-Mail-293--606296011
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

Hi Steve,

>=20
> The following errata report has been submitted for RFC6487,
> "A Profile for X.509 PKIX Resource Certificates".
>=20
> --------------------------------------
> You may review the report below and at:
> http://www.rfc-editor.org/errata_search.php?rfc=3D6487&eid=3D3238
>=20
> --------------------------------------
> Type: Technical
> Reported by: Stephen Kent 
>=20
> Section: 6.3
>=20
> Original Text
> -------------
> ExtendedKeyUsage
>         The CA MAY honor ExtendedKeyUsage extensions of keyCertSign =
and
>         cRLSign if present, as long as this is consistent with the
>         BasicConstraints SubjectType sub-field, when specified.
>=20
> Corrected Text
> --------------
> ExtendedKeyUsage
>         The CA MAY honor ExtendedKeyUsage extensions in requests for =
EE
>         certificates that are issued to routers or other devices, =
consistent with values
>         specified in Standards Track RFCs that adopt this profile and =
that identify
>         application-specific requirements that motivate the use of =
such EKUs.
>=20

I agree that this correction make sense. I also agree on the restriction =
to uses that are compatible with this profile rather than the complete =
registry list. We already have RFC 6494 as example.

Roque




> Notes
> -----
> The current text appears to be the result of a "cut and paste" error. =
It is essentially identical to the text=20
> for the Key Usage extension, and names two fields that appear in that =
extension, not in an EKU extension. The text I propose above parallels =
what appears in Section 4.8.5, which describes how an
> EKU MAY be used in RPKI certificates.
>=20
> Instructions:
> -------------
> This errata is currently posted as "Reported". If necessary, please
> use "Reply All" to discuss whether it should be verified or
> rejected. When a decision is reached, the verifying party (IESG)
> can log in to change the status and edit the report, if necessary.=20
>=20
> --------------------------------------
> RFC6487 (draft-ietf-sidr-res-certs-22)
> --------------------------------------
> Title               : A Profile for X.509 PKIX Resource Certificates
> Publication Date    : February 2012
> Author(s)           : G. Huston, G. Michaelson, R. Loomans
> Category            : PROPOSED STANDARD
> Source              : Secure Inter-Domain Routing
> Area                : Routing
> Stream              : IETF
> Verifying Party     : IESG
> _______________________________________________
> sidr mailing list
> sidr@ietf.org
> https://www.ietf.org/mailman/listinfo/sidr


--Apple-Mail-293--606296011
Content-Disposition: attachment; filename="smime.p7s"
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMXDCCBWYw
ggROoAMCAQICEDG+eY7Bhz6hDsSIPCMJYUYwDQYJKoZIhvcNAQEFBQAwgd0xCzAJBgNVBAYTAlVT
MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y
azE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEg
KGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24g
Q2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMzAeFw0xMjA1MDgwMDAwMDBaFw0x
MzA1MTEyMzU5NTlaMIIBEzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT
aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9S
UEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMpOTgxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZh
bGlkYXRlZDEzMDEGA1UECxMqRGlnaXRhbCBJRCBDbGFzcyAxIC0gTmV0c2NhcGUgRnVsbCBTZXJ2
aWNlMRcwFQYDVQQDFA5Sb3F1ZSBHYWdsaWFubzEhMB8GCSqGSIb3DQEJARYScm9nYWdsaWFAY2lz
Y28uY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAs+CGyKUNmmBJ4PgQDVA8hF5E
ByrcJ8BQ2C8mSv3vSZqCZNXAyte/JRsl11BJmqwdLiH6baDaJbBKRzNFfaf8Wwe8aS3QvqpHfKtU
pYvn+EKseVnXsIKssRV2AwNODN6VMwSA72Jiolo3z4xeoeLw9X/CnFYTJa4AcGM1LKk+rMGTQlly
XXl+qc7LeAd+wk7bKsUFmg4uCfvCDhVSQj25S5tnmFl5WPGD2u7QEa2WLkkL5nH+BEedZmRejRgP
smmAxDfBX1FVTnCOgz75hNFlrnkYJfPCXLRyfPHvaIGP/NBz6TJbwB3YZSweYHxWAEMglqgRvqIW
3Tr5k5x9yyNYVQIDAQABo4HoMIHlMAkGA1UdEwQCMAAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcX
ATAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1UdDwQEAwIF
oDAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwFAYKYIZIAYb4RQEGBwQGFgROb25lMFAG
A1UdHwRJMEcwRaBDoEGGP2h0dHA6Ly9pbmRjMWRpZ2l0YWxpZC1nMy1jcmwudmVyaXNpZ24uY29t
L0luZEMxRGlnaXRhbElELUczLmNybDANBgkqhkiG9w0BAQUFAAOCAQEAuFfFZrObA9gprpHyG6cq
O4UZjtN5/moV6mUYbt+ffGrXMbVt06vgnba7r6ldS5eWPQZZQtAAKKqweAmZY37ZcvVQwDsMXOMG
4+MN60sPVKwrrSQz9xXcImVCzBxFsq22S4el6pGx38xytsPgKw4cs8ZVxPLEjZtcOGnl8R8fak2g
WyAMt8zkIxu/84zcobhcY5EEPJxYg9WKHi617fD6/jjQqvwvW4zi2XkIjw+HpZSwdPxk2+Cg6id4
SS6WlTwe90rdJmRrCP4gTXyJOdARR7hJU714lamn9QdQuPX7WLJXuMmoyrhvZZUeHpvodO/eNiO2
KvxMUu0uXWiDcDgTvzCCBu4wggXWoAMCAQICEHEVZgVK5JEhTem8RPms09wwDQYJKoZIhvcNAQEF
BQAwgcoxCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVy
aVNpZ24gVHJ1c3QgTmV0d29yazE6MDgGA1UECxMxKGMpIDE5OTkgVmVyaVNpZ24sIEluYy4gLSBG
b3IgYXV0aG9yaXplZCB1c2Ugb25seTFFMEMGA1UEAxM8VmVyaVNpZ24gQ2xhc3MgMSBQdWJsaWMg
UHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSAtIEczMB4XDTA5MDUwMTAwMDAwMFoXDTE5
MDQzMDIzNTk1OVowgd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0G
A1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0
dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZh
bGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIg
Q0EgLSBHMzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAO3ER98qKB18Bmu71yEyyWwT
j+mxjUFONPfaC+Nq+mWIIAsRE+mb4ElOi2/VAdBfDUeRilpMdD4/xpEJu0w0no1uoYJRYvdpdliW
B6+eFBgHT1q9n9IxslQZc0ZqGUIR7BJzIY313DDN5dlWCjHFNm0pFJe9LdqJRxmI2EsEPeu2PGce
dAATDdCG2pNn+DMDrho8a2l49sAsjuGDP3f5mf/+n1JawrSHCthsqUfBVCllQz5KwJYfwa33d69s
sQRevsG2lC2XkC0n0rse6YNqhPbEsq4jBmUmpSdYKwcitG+mYkgad/LVUCeaKdOW+yj1uiR2YuOM
Wev7btVCxL5Bx/UCAwEAAaOCArkwggK1MDQGCCsGAQUFBwEBBCgwJjAkBggrBgEFBQcwAYYYaHR0
cDovL29jc3AudmVyaXNpZ24uY29tMBIGA1UdEwEB/wQIMAYBAf8CAQAwcAYDVR0gBGkwZzBlBgtg
hkgBhvhFAQcXATBWMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vY3BzMCoG
CCsGAQUFBwICMB4aHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEwNAYDVR0fBC0wKzApoCeg
JYYjaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS1nMy5jcmwwDgYDVR0PAQH/BAQDAgEGMG4G
CCsGAQUFBwEMBGIwYKFeoFwwWjBYMFYWCWltYWdlL2dpZjAhMB8wBwYFKw4DAhoEFEtruSiWBgy7
0FI4mymsSweLIQUYMCYWJGh0dHA6Ly9sb2dvLnZlcmlzaWduLmNvbS92c2xvZ28xLmdpZjAuBgNV
HREEJzAlpCMwITEfMB0GA1UEAxMWUHJpdmF0ZUxhYmVsNC0yMDQ4LTExODAdBgNVHQ4EFgQUeUdh
CEH9OASiS+e1zPVD9kkrEfgwgfEGA1UdIwSB6TCB5qGB0KSBzTCByjELMAkGA1UEBhMCVVMxFzAV
BgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTow
OAYDVQQLEzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5
MUUwQwYDVQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24g
QXV0aG9yaXR5IC0gRzOCEQCLW3VWhFSFCwDPrzhIzrGkMA0GCSqGSIb3DQEBBQUAA4IBAQA5Tc9B
mYG1qQW1UjjpOYSJbOQ0qFrn2GwJTCQaulmkhztzIfGTgc+/aGNaZ/41hSuhw12jSsI6Gd0w1sxN
7/HSgZfKVFpDvzeLeo4ZjQ9DqIzyr2CzFYqzlZw84J6zJ5ikNXIX5fwqXYfTig3C0UUq+MD0rCqT
OtWuEnAI6/s74nfs6CtkNXbNutrg0csU1nFYm77VPn222egkxSRmTF2RH3azFz5/DcYhiS+zN7ih
/1yybUneZVJC+w6I0u1KHb9L4/jMcvpIDmWOScjW+JmYO7eUPjFxBof6bFlTLtffK+1fYwCsFe0D
uFUWjMZoA+ciqHMLsbyg2lJY3QoOf8GCMYIEizCCBIcCAQEwgfIwgd0xCzAJBgNVBAYTAlVTMRcw
FQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7
MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEgKGMp
MDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xh
c3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMwIQMb55jsGHPqEOxIg8IwlhRjAJBgUr
DgMCGgUAoIICbTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMjA1
MzExNTI5MTdaMCMGCSqGSIb3DQEJBDEWBBQIIDCC0dDxKzEkCT9bobcjOkjeXDCCAQMGCSsGAQQB
gjcQBDGB9TCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD
VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0
cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFs
aWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBD
QSAtIEczAhAxvnmOwYc+oQ7EiDwjCWFGMIIBBQYLKoZIhvcNAQkQAgsxgfWggfIwgd0xCzAJBgNV
BAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3Qg
TmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNv
bS9ycGEgKGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVy
aVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMwIQMb55jsGHPqEOxIg8
IwlhRjANBgkqhkiG9w0BAQEFAASCAQCEJbW4MapOeQv9e4v2/306IhlxYDH2j5GZzHXLu4O5lgR4
KkKBbpXtlELoNoc2uZ7Zu5YOtB2SVlIRRVacLqlsZtzWeulGWkdRLl4NkyV13Bu2689ayDCnD5Wb
CHE9qi/Hf5Ufe+WeHDtbO7oLK7LGXl7hKMWM6B/+V3hXqN9n0SZrn6DnH6Pp5r5TbkU9id3lHRql
9CxBxSUzUrV9dXxO55+IKprRBUWHJf8isugrxjVgRdPyk4YC8CWmwkRIC32lHkDb5tApNXEf0eja
g58njfrm8cpb+dzwwiM/oIEAs7VA9rJuad4TRAc9liyqx2qLCJMQ7n10uchI69P3AO45AAAAAAAA

--Apple-Mail-293--606296011--

From jgs@bgp.nu  Thu May 31 10:34:50 2012
Return-Path: 
X-Original-To: sidr@ietfa.amsl.com
Delivered-To: sidr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3267C11E80A4; Thu, 31 May 2012 10:34:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.043
X-Spam-Level: 
X-Spam-Status: No, score=-102.043 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_IS_SMALL6=0.556, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mMiNMITP4ttX; Thu, 31 May 2012 10:34:48 -0700 (PDT)
Received: from bgp.nu (bgp.nu [147.28.0.53]) by ietfa.amsl.com (Postfix) with ESMTP id BD26421F8661; Thu, 31 May 2012 10:34:48 -0700 (PDT)
Received: from [172.16.13.205] (75-151-14-10-Michigan.hfc.comcastbusiness.net [75.151.14.10]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by bgp.nu (Postfix) with ESMTP id B896166CE89; Thu, 31 May 2012 13:34:47 -0400 (EDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Apple Message framework v1278)
From: "John G. Scudder" 
In-Reply-To: 
Date: Thu, 31 May 2012 13:34:46 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <10EB7620-F079-40CA-8302-63FFEE969032@bgp.nu>
References: <5BA9D6DE-BE0E-4922-9E09-7B85BD6F9342@juniper.net> 
To: "idr@ietf.org List" , "sidr@ietf.org list" 
X-Mailer: Apple Mail (2.1278)
Subject: Re: [sidr] BGPSEC proposal to drop AS_PATH [was: Fwd: request for agenda items for interim meeting 6 Jun]
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Secure Interdomain Routing 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 31 May 2012 17:34:50 -0000

Missed one:

On May 29, 2012, at 2:24 PM, John G. Scudder wrote:

>> Philosophically, the thing that makes me worry the most is that we're =
cutting out one of BGP's fundamental elements and replacing it with one =
which provides only a subset of its semantics. Specific things missing =
include:
>>=20
>> - Confederations. But we are discussing ways to fix this.
>> - Extensibility to include new segment types. In principle this is a =
fairly serious omission, but one can argue that new segment types can't =
be introduced in practice, since existing implementations will treat =
them as fatal errors.

- AS_SETs. SIDR has decided not to support these, and IDR has published =
RFC 6472 / BCP 172 "Recommendation for Not Using AS_SET and =
AS_CONFED_SET in BGP". Nonetheless, they remain part of the protocol and =
have not (yet) been formally deprecated, so I mention them for =
completeness.

--John=

From jgs@juniper.net  Thu May 31 10:35:35 2012
Return-Path: 
X-Original-To: sidr@ietfa.amsl.com
Delivered-To: sidr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDA7D11E808C; Thu, 31 May 2012 10:35:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.584
X-Spam-Level: 
X-Spam-Status: No, score=-6.584 tagged_above=-999 required=5 tests=[AWL=0.015,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id blAzuu0y-Oni; Thu, 31 May 2012 10:35:35 -0700 (PDT)
Received: from exprod7og121.obsmtp.com (exprod7og121.obsmtp.com [64.18.2.20]) by ietfa.amsl.com (Postfix) with ESMTP id C3E4F11E8081; Thu, 31 May 2012 10:35:26 -0700 (PDT)
Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob121.postini.com ([64.18.6.12]) with SMTP ID DSNKT8er3sILfXaiRdUV/u1457AqwzHDzCt0@postini.com; Thu, 31 May 2012 10:35:34 PDT
Received: from [172.16.13.205] (172.16.13.205) by P-EMHUB02-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server id 8.3.213.0; Thu, 31 May 2012 10:31:30 -0700
MIME-Version: 1.0 (Apple Message framework v1278)
Content-Type: text/plain; charset="us-ascii"
From: "John G. Scudder" 
In-Reply-To: 
Date: Thu, 31 May 2012 13:31:29 -0400
Content-Transfer-Encoding: quoted-printable
Message-ID: <5F5F8CF8-061C-47C9-942C-7908963EF347@juniper.net>
References: <24B20D14B2CD29478C8D5D6E9CBB29F60F70A267@Hermes.columbia.ads.sparta.com> <24B20D14B2CD29478C8D5D6E9CBB29F625F0975D@Hermes.columbia.ads.sparta.com> <4FBBB6D1.9000008@bbn.com>  <4FBC0936.7000905@bbn.com>, <5BA9D6DE-BE0E-4922-9E09-7B85BD6F9342@juniper.net> <24B20D14B2CD29478C8D5D6E9CBB29F625F12333@Hermes.columbia.ads.sparta.com>  
To: "Sriram, Kotikalapudi" 
X-Mailer: Apple Mail (2.1278)
Cc: "idr@ietf.org List" , "Murphy, Sandra" , "sidr@ietf.org list" 
Subject: Re: [sidr] request for agenda items for interim meeting 6 Jun
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Secure Interdomain Routing 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 31 May 2012 17:35:35 -0000

On May 30, 2012, at 8:02 PM, Sriram, Kotikalapudi wrote:

>>=20
>> Right, and agreed (see "formally an attack" above). But to repeat my =
further
>> point, if the AS_PATH is present (even if not secured): "at least =
there's scope for a
>> network operator on the receiving end to tolerate the validation =
failure and use
>> the route anyway, if desired. In the case where there's no AS_PATH, =
the data are
>> just gone with no chance for appeal."
>>=20
>=20
> John,
>=20
> I do not agree that in the event of "validation failure" the route =
becomes unusable
> in BGPSEC as currently specified.

That's not what I meant. My point was that a feature may be applied that =
wants to change the AS_PATH in a way that can't be represented in the =
BGPSEC_Path_Signatures. In other words, your later statement:

> the Secure_Path segment is still usable as it provides the AS path =
info.

is not correct in all cases. Likewise, to this statement:

> So validation failure in BGPSEC does not mean that "the data are just =
gone."

My point is not that validation failure causes this. It's that absent =
AS_PATH, a semantically non-representable AS_PATH will be lost if forced =
through BGPSEC_Path_Signatures.

To reiterate, the options to address the case where a feature wants to =
produce output that can't be represented in BGPSEC_Path_Signatures are:

- Don't solve it. Effectively forbid any such feature.
- Carry both AS_PATH and BGPSEC_Path_Signatures in every update. Rules =
for reconciliation would be required.
- Downgrade BGPSEC update to BGP update.=20
- Extend BGPSEC_Path_Signatures format to be able to represent the =
needed feature. (As Sandy noted, this only makes sense insofar as the =
feature isn't formally an attack, so this option is incomplete.)

The validation failure I spoke of is a potential *consequence* of the =
middle two options above, and as you say, the operator can then decide =
what to do.

--John=

From jgs@juniper.net  Thu May 31 10:39:41 2012
Return-Path: 
X-Original-To: sidr@ietfa.amsl.com
Delivered-To: sidr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B2B011E80CA; Thu, 31 May 2012 10:39:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.585
X-Spam-Level: 
X-Spam-Status: No, score=-6.585 tagged_above=-999 required=5 tests=[AWL=0.014,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GnMp51PZHnvM; Thu, 31 May 2012 10:39:40 -0700 (PDT)
Received: from exprod7og115.obsmtp.com (exprod7og115.obsmtp.com [64.18.2.217]) by ietfa.amsl.com (Postfix) with ESMTP id B823311E8081; Thu, 31 May 2012 10:39:34 -0700 (PDT)
Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob115.postini.com ([64.18.6.12]) with SMTP ID DSNKT8es1qOzdQdy76ZqxQkWTgGZDaTnCIhw@postini.com; Thu, 31 May 2012 10:39:34 PDT
Received: from [172.16.13.205] (172.16.13.205) by P-EMHUB02-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server id 8.3.213.0; Thu, 31 May 2012 10:37:58 -0700
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0 (Apple Message framework v1278)
From: "John G. Scudder" 
In-Reply-To: 
Date: Thu, 31 May 2012 13:37:57 -0400
Content-Transfer-Encoding: quoted-printable
Message-ID: 
References: <5BA9D6DE-BE0E-4922-9E09-7B85BD6F9342@juniper.net> 
To: "idr@ietf.org List" , "sidr@ietf.org list" 
X-Mailer: Apple Mail (2.1278)
Subject: Re: [sidr] BGPSEC proposal to drop AS_PATH [was: Fwd: request for agenda items for interim meeting 6 Jun]
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Secure Interdomain Routing 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 31 May 2012 17:39:41 -0000

[Sigh. Again with the right source email address.]

Missed one:

On May 29, 2012, at 2:24 PM, John G. Scudder wrote:

>> Philosophically, the thing that makes me worry the most is that we're =
cutting out one of BGP's fundamental elements and replacing it with one =
which provides only a subset of its semantics. Specific things missing =
include:
>>=20
>> - Confederations. But we are discussing ways to fix this.
>> - Extensibility to include new segment types. In principle this is a =
fairly serious omission, but one can argue that new segment types can't =
be introduced in practice, since existing implementations will treat =
them as fatal errors.

- AS_SETs. SIDR has decided not to support these, and IDR has published =
RFC 6472 / BCP 172 "Recommendation for Not Using AS_SET and =
AS_CONFED_SET in BGP". Nonetheless, they remain part of the protocol and =
have not (yet) been formally deprecated, so I mention them for =
completeness.

--John=

From alexey.melnikov@isode.com  Thu May 31 12:16:59 2012
Return-Path: 
X-Original-To: sidr@ietfa.amsl.com
Delivered-To: sidr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF7F821F860D for ; Thu, 31 May 2012 12:16:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.937
X-Spam-Level: 
X-Spam-Status: No, score=-102.937 tagged_above=-999 required=5 tests=[AWL=-0.338, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RwCTW-QnzfLa for ; Thu, 31 May 2012 12:16:59 -0700 (PDT)
Received: from rufus.isode.com (cl-125.lon-03.gb.sixxs.net [IPv6:2a00:14f0:e000:7c::2]) by ietfa.amsl.com (Postfix) with ESMTP id DE2A621F860B for ; Thu, 31 May 2012 12:16:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1338491818; d=isode.com; s=selector; i=@isode.com; bh=wVqjEX3xLVukTxQqjvpHTvNKAoSCv+MVnwRRe16Wjf4=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=lBcIdMptKI87LC0099t6+p9By1Bq3NrIIfPfhoBVt8d3Q8IAQEKfxpjE+nXLycudVHuIfV g7Tk2N1AleTITo6pmrBd5vI5HvD8CU6ee3R2EjSHh66tpmxqYVeE17mKL5XP0uXYitls9h sbppjR0qOQikgF1KkqtyCWadZwz5TSM=;
Received: from [172.16.1.29] (shiny.isode.com [62.3.217.250])  by rufus.isode.com (submission channel) via TCP with ESMTPSA  id ; Thu, 31 May 2012 20:16:57 +0100
X-SMTP-Protocol-Errors: PIPELINING
Message-ID: <4FC7C3AC.7060606@isode.com>
Date: Thu, 31 May 2012 20:17:00 +0100
From: Alexey Melnikov 
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2
To: sidr wg 
References: <4FBFA992.8020107@isode.com>
In-Reply-To: <4FBFA992.8020107@isode.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: [sidr] Summary: another interim on June 29th
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Secure Interdomain Routing 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 31 May 2012 19:17:00 -0000

On 25/05/2012 16:47, Alexey Melnikov wrote:
> Dear WG members,
> The WG needs to decide about the date and type of the next interim 
> (after June 6th). The earlier proposal stated June 29th. Are people 
> happy with this date or do they want to propose an alternative? Note 
> that we are more flexible this time, because this is not tied to any 
> other industry event.
>
> We also need to decide on whether this should be a physical interim 
> with remote participants or fully virtual interim (e.g. everybody is 
> using WebEx or something similar).
>
> Please reply to this message, sending your comments to the mailing 
> list or directly to chairs (sidr-chairs@tools.ietf.org).
There weren't that many replies to this message. Most of the people who 
replied were either happy with the June 29th date or didn't want to have 
an interim around June 29th at all. Based on feedback from people who 
replied (some of them replied privately), SIDR chairs decided to 
tentatively book a fully virtual interim for a half of June 29th. Fully 
virtual interims (e.g. conference calls and/or jabber chats) require 2 
weeks prior notice to larger IETF community, so chairs will wait till 
after the interim on June 6th to decide whether there are enough issues 
to warrant having a virtual interim on June 29th.

Best Regards,
Alexey,
as a SIDR co-chair

P.S. There seems to be more interest in having a co-located interim just 
before the Vancouver IETF. We are still planning to have this one.


From randy@psg.com  Thu May 31 15:55:48 2012
Return-Path: 
X-Original-To: sidr@ietfa.amsl.com
Delivered-To: sidr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8884A21F861C for ; Thu, 31 May 2012 15:55:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.501
X-Spam-Level: 
X-Spam-Status: No, score=-2.501 tagged_above=-999 required=5 tests=[AWL=0.098,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qHdGZvqeObsv for ; Thu, 31 May 2012 15:55:48 -0700 (PDT)
Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by ietfa.amsl.com (Postfix) with ESMTP id 077AC21F85D7 for ; Thu, 31 May 2012 15:55:48 -0700 (PDT)
Received: from localhost ([127.0.0.1] helo=rair.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1SaEHT-000Ixu-GJ for sidr@ietf.org; Thu, 31 May 2012 22:55:47 +0000
Date: Fri, 01 Jun 2012 07:55:46 +0900
Message-ID: 
From: Randy Bush 
To: sidr wg list 
In-Reply-To: <2BAE4694-60C2-4301-BFAF-05DF49054BF4@cisco.com>
References: <20120531145543.F363272E004@rfc-editor.org> <2BAE4694-60C2-4301-BFAF-05DF49054BF4@cisco.com>
User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI)
MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka")
Content-Type: text/plain; charset=US-ASCII
Subject: Re: [sidr] [Technical Errata Reported] RFC6487 (3238)
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Secure Interdomain Routing 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 31 May 2012 22:55:48 -0000

>> The following errata report has been submitted for RFC6487,
>> "A Profile for X.509 PKIX Resource Certificates".
>> 
>> --------------------------------------
>> You may review the report below and at:
>> http://www.rfc-editor.org/errata_search.php?rfc=6487&eid=3238
>> 
>> --------------------------------------
>> Type: Technical
>> Reported by: Stephen Kent 
>> 
>> Section: 6.3
>> 
>> Original Text
>> -------------
>> ExtendedKeyUsage
>>         The CA MAY honor ExtendedKeyUsage extensions of keyCertSign and
>>         cRLSign if present, as long as this is consistent with the
>>         BasicConstraints SubjectType sub-field, when specified.
>> 
>> Corrected Text
>> --------------
>> ExtendedKeyUsage
>>         The CA MAY honor ExtendedKeyUsage extensions in requests for EE
>>         certificates that are issued to routers or other devices, consistent with values
>>         specified in Standards Track RFCs that adopt this profile and that identify
>>         application-specific requirements that motivate the use of such EKUs.
>> 
> 
> I agree that this correction make sense. I also agree on the restriction to uses that are compatible with this profile rather than the complete registry list. We already have RFC 6494 as example.
> 
> Roque
> 
> 
> 
> 
>> Notes
>> -----
>> The current text appears to be the result of a "cut and paste" error. It is essentially identical to the text 
>> for the Key Usage extension, and names two fields that appear in that extension, not in an EKU extension. The text I propose above parallels what appears in Section 4.8.5, which describes how an
>> EKU MAY be used in RPKI certificates.
>> 
>> Instructions:
>> -------------
>> This errata is currently posted as "Reported". If necessary, please
>> use "Reply All" to discuss whether it should be verified or
>> rejected. When a decision is reached, the verifying party (IESG)
>> can log in to change the status and edit the report, if necessary. 
>> 
>> --------------------------------------
>> RFC6487 (draft-ietf-sidr-res-certs-22)
>> --------------------------------------
>> Title               : A Profile for X.509 PKIX Resource Certificates
>> Publication Date    : February 2012
>> Author(s)           : G. Huston, G. Michaelson, R. Loomans
>> Category            : PROPOSED STANDARD
>> Source              : Secure Inter-Domain Routing
>> Area                : Routing
>> Stream              : IETF
>> Verifying Party     : IESG

while i agree that the change is correct, this is not an erratum, but an
actual change in semantics.

randy

From russw@riw.us  Thu May 31 16:17:06 2012
Return-Path: 
X-Original-To: sidr@ietfa.amsl.com
Delivered-To: sidr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69BD321F8636 for ; Thu, 31 May 2012 16:17:06 -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=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aVru7RmfQPMw for ; Thu, 31 May 2012 16:17:06 -0700 (PDT)
Received: from da31.namelessnet.net (da31.namelessnet.net [74.124.205.66]) by ietfa.amsl.com (Postfix) with ESMTP id E53A521F8630 for ; Thu, 31 May 2012 16:17:05 -0700 (PDT)
Received: from rrcs-24-199-145-66.midsouth.biz.rr.com ([24.199.145.66] helo=[192.168.3.115]) by da31.namelessnet.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77) (envelope-from ) id 1SaEc5-00083u-GO for sidr@ietf.org; Thu, 31 May 2012 16:17:05 -0700
Message-ID: <4FC7FBEE.4040100@riw.us>
Date: Thu, 31 May 2012 19:17:02 -0400
From: Russ White 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1
MIME-Version: 1.0
To: sidr@ietf.org
References: <5BA9D6DE-BE0E-4922-9E09-7B85BD6F9342@juniper.net>  
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Antivirus-Scanner: Seems clean.  You should still use an Antivirus Scanner
Subject: Re: [sidr] BGPSEC proposal to drop AS_PATH [was: Fwd: request for agenda items for interim meeting 6 Jun]
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Secure Interdomain Routing 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 31 May 2012 23:17:06 -0000

>>> - Extensibility to include new segment types. In principle this is a fairly serious omission, but one can argue that new segment types can't be introduced in practice, since existing implementations will treat them as fatal errors.

Doesn't this also impact 2 octet to 4 octet transition?

IMHO, this is a huge problem --much larger than we might imagine at this
particular moment in time.

Russ

-- 
<><
riwhite@verisign.com
russw@riw.us