From nobody Tue Mar 3 06:24:55 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F17071A8711 for ; Tue, 3 Mar 2015 06:24:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DWcthJsV82rj for ; Tue, 3 Mar 2015 06:24:52 -0800 (PST) Received: from walnut.tislabs.com (walnut.tislabs.com [192.94.214.200]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8C7CC1A8710 for ; Tue, 3 Mar 2015 06:24:38 -0800 (PST) Received: from nova.tislabs.com (unknown [10.66.1.77]) by walnut.tislabs.com (Postfix) with ESMTP id 0E75228B003D for ; Tue, 3 Mar 2015 09:24:37 -0500 (EST) Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1]) by nova.tislabs.com (Postfix) with ESMTP id E882D1F8035; Tue, 3 Mar 2015 09:24:36 -0500 (EST) From: Sandra Murphy Content-Type: multipart/signed; boundary="Apple-Mail=_6B20D6ED-54FD-4776-9E46-A40CC6C5063F"; protocol="application/pgp-signature"; micalg=pgp-sha512 Date: Tue, 3 Mar 2015 09:24:37 -0500 Message-Id: <9C2A1119-66EB-46BF-8E10-A8D36DF93A84@tislabs.com> To: "sidr@ietf.org list" Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) X-Mailer: Apple Mail (2.1510) Archived-At: Cc: Sandra Murphy Subject: [sidr] WGLC on draft-ietf-sidr-rfc6490-bis-01.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Mar 2015 14:24:54 -0000 --Apple-Mail=_6B20D6ED-54FD-4776-9E46-A40CC6C5063F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii The working group last call for draft-ietf-sidr-rfc6490-bis-01 ended = before the last IETF meeting. It got just three reviews, which is = meager consensus even for an overloaded working group like this one. However. The only comments in those reviews were minor editorial in nature. No = one objected. The changes are basically compatible with the known = relying party implementations. The changes to the RFC6490 spec are = minor and the new feature is important. The chairs in consultation with our Routing AD have decided to request = publication. =20 If you object, you can speak now. --Sandy, speaking for the wg co-chairs --Apple-Mail=_6B20D6ED-54FD-4776-9E46-A40CC6C5063F Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJU9cQlAAoJEHplpQeet0IZ6+cP/0L14xB1gQpFzJu8mRbjz+Bx EfGERgRJ1KwmeEx6EKzPrwEtNNYFj5kpIHVMEbsctiDrXgF05G7j7rMr40u+hvFJ eD/n+7g3s/uLlONs7+/vu0UYGAwB+CLNhkTaUU5PXxtKHETFWbm5ncPGVifuAPoN i35Wdu07d3hHkizOaSffO3tQGeFqj+1KSMXo8DeNI3/cCU30zswE6YdFreJBx8dG of8iJXzHIVjRXBjATvZzdE1GgCddh4l1nFRRzaeAK8WX2BqSyeLGKENubcLzl1cl tYwKvCOn6mRzbDeTBtCDo3hkwbB8yBolw+usL90yhVWnG9tyoO9KZDEgq8eo2dUM jJoHo8eHAEj7O4l+MxVuuBU/zDD3gGdI/HXLKU0y8xAeCIFB7+1kY6UHvxhn+H75 0kxTsA3x0m1P6PW/ZXOpnWj+SSpUho942ybuye9prn0mpJsAer1Lp48N/cRspMyX BhMZRy2/C4T4rsi4dQrqN4W85w0tivb4rCL4I6BzMGHWcexN5IvrM+Hh0zrdGFGe KQTwYBNpjr2dCrfWc1DuIiT4OBzTkNGgcNXFZWTSX7pKL38qNn6VhzdLquLS02U0 7WU+wOocO/wnbbxLyqAQNVrfknjegwNqDR47nh0vTFa848vNnt0gN0ld64ZRxFV+ uCiAJZxqfoasDUKrHyLX =emGQ -----END PGP SIGNATURE----- --Apple-Mail=_6B20D6ED-54FD-4776-9E46-A40CC6C5063F-- From nobody Tue Mar 3 08:29:38 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A301C1ABC75 for ; Tue, 3 Mar 2015 08:29:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z6OsoHkGowET for ; Tue, 3 Mar 2015 08:29:35 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 84B361ABC10 for ; Tue, 3 Mar 2015 08:29:35 -0800 (PST) Received: from ssh.bbn.com ([192.1.122.15]:51055 helo=COMSEC.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1YSphN-0005VE-Rc for sidr@ietf.org; Tue, 03 Mar 2015 11:29:34 -0500 Message-ID: <54F5E16D.9020002@bbn.com> Date: Tue, 03 Mar 2015 11:29:33 -0500 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: sidr@ietf.org References: <20141126164443.26069.29089.idtracker@ietfa.amsl.com> <54760513.2050709@innovationslab.net> In-Reply-To: <54760513.2050709@innovationslab.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [sidr] I-D Action: draft-ietf-sidr-rpsl-sig-06.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Mar 2015 16:29:37 -0000 Brian, I apologize for this very, very late comment. Your message from late November got lost in my inbox. I worry that accommodating multiple signatures will cause confusion for RPs. One would need to specify what to do if one sig fails, but other succeed, for example. Steve > All, > Robert and I have found the time/energy to push this work to > completion. This version does not contain any substantive updates from > the -05, I simply got this version out to allow for discussion on it to > resume. > > One question that I would like to discuss is the currently optional > "o" attribute. Robert feels it is not needed if the "c" attribute > references a RFC 3779-compliant certificate. I feel that the > flexibility of having multiple signatures allows for instances where > different parties own, for example, the prefix being advertised and the > ASN. I would appreciate feedback on this issue. > > A follow-on version will address comments raised previously on the > From nobody Tue Mar 3 15:43:22 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1AB271A3BA1 for ; Tue, 3 Mar 2015 15:43:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A4EF7_20ifAN for ; Tue, 3 Mar 2015 15:43:19 -0800 (PST) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0128.outbound.protection.outlook.com [65.55.169.128]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3E8BE1A212A for ; Tue, 3 Mar 2015 15:43:19 -0800 (PST) Received: from DM2PR09MB0302.namprd09.prod.outlook.com (25.160.96.147) by DM2PR09MB0302.namprd09.prod.outlook.com (25.160.96.147) with Microsoft SMTP Server (TLS) id 15.1.93.16; Tue, 3 Mar 2015 23:43:16 +0000 Received: from DM2PR09MB0302.namprd09.prod.outlook.com ([25.160.96.147]) by DM2PR09MB0302.namprd09.prod.outlook.com ([25.160.96.147]) with mapi id 15.01.0093.004; Tue, 3 Mar 2015 23:43:16 +0000 From: "Sriram, Kotikalapudi" To: Matthew Lepinski Thread-Topic: [sidr] wglc for draft-ietf-sidr-bgpsec-protocol-11 Thread-Index: AQHQObnP/eFvHk0J6E2CzGstO0tmlJzjGf4AgAcb4iqAAE0vAIAE7aoAgAD+GgCAAAaAAIAAMwz4gAT6WoCACpsfgIADKAoOgAgWoFA= Date: Tue, 3 Mar 2015 23:43:16 +0000 Message-ID: References: <54DA7C98.4040604@mandelberg.org> <1423943624118.34986@nist.gov> <54E3D163.1040600@mandelberg.org> <87ioeor29k.fsf@rebma.mikesoffice.com> In-Reply-To: <87ioeor29k.fsf@rebma.mikesoffice.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [129.6.140.100] authentication-results: gmail.com; dkim=none (message not signed) header.d=none; x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:DM2PR09MB0302; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:;SRVR:DM2PR09MB0302; x-forefront-prvs: 0504F29D72 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(50986999)(76176999)(86362001)(46102003)(76576001)(33656002)(54356999)(74316001)(40100003)(122556002)(110136001)(93886004)(92566002)(106116001)(62966003)(99286002)(230783001)(77156002)(66066001)(102836002)(2900100001)(2950100001)(87936001)(2656002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR09MB0302; H:DM2PR09MB0302.namprd09.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Mar 2015 23:43:16.3008 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR09MB0302 Archived-At: Cc: "sidr@ietf.org" Subject: Re: [sidr] wglc for draft-ietf-sidr-bgpsec-protocol-11 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Mar 2015 23:43:21 -0000 T24gcGFnZSA1LCBkcmFmdC1pZXRmLXNpZHItYmdwc2VjLXByb3RvY29sLTExIHNheXM6IA0KDQpB IEJHUCBzcGVha2VyIFNIT1VMRA0KICAgTk9UIGFkdmVydGlzZSB0aGUgY2FwYWJpbGl0eSBvZiBC R1BzZWMgc3VwcG9ydCBmb3IgYSBwYXJ0aWN1bGFyIEFGSQ0KICAgdW5sZXNzIGl0IGhhcyBhbHNv IGFkdmVydGlzZWQgdGhlIG11bHRpcHJvdG9jb2wgZXh0ZW5zaW9uIGNhcGFiaWxpdHkNCiAgIGZv ciB0aGUgc2FtZSBBRkkgY29tYmluYXRpb24gWzNdLg0KDQpJIGludGVycHJldCB0aGlzIHRvIG1l YW4gdGhhdCBpZiBhIEJHUHNlYyBzcGVha2VyIGludGVuZHMgdG8gc2VuZCBJUHY0IHVwZGF0ZXMg DQp0byBhIHBlZXIsIGl0IHNob3VsZCBhZHZlcnRpc2UgbXVsdGlwcm90b2NvbCBleHRlbnNpb24g Y2FwYWJpbGl0eSB3aXRoIEFGSSA9IDEuIA0KVGhhdCBpcyBzbyBldmVuIHdoZW4gaXQgaW50ZW5k cyB0byBzZW5kIG9ubHkgSVB2NCB1cGRhdGVzLiANClRoZSBmYWN0IHRoYXQgbXVsdGlwcm90b2Nv bCBleHRlbnNpb24gY2FwYWJpbGl0eSAod2l0aCBBRkkgPSAxKSBpcyBhZHZlcnRpc2VkLCBkb2Vz IGl0IG1lYW4gdGhhdCANCk1QX1JFQUNIX05MUkkgKHNlZSBwYWdlIDMsIFJGQyA0NzYwKSBzaG91 bGQgYmUgdXNlZCBmb3IgYW5ub3VuY2luZyBJUHY0IHByZWZpeGVzPw0KSnVzdCB0cnlpbmcgdG8g Y2xhcmlmeSBiZWNhdXNlIGl0IHdhc27igJl0IGNsZWFyIHRvIG1lIHJlYWRpbmcgUkZDIDQ3NjAu DQoNClNyaXJhbQ0K From nobody Tue Mar 3 16:32:29 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08E951A1BE8 for ; Tue, 3 Mar 2015 16:32:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RpP6E4H7Rkkj for ; Tue, 3 Mar 2015 16:32:26 -0800 (PST) Received: from mail-pa0-x232.google.com (mail-pa0-x232.google.com [IPv6:2607:f8b0:400e:c03::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8053F1A1BD7 for ; Tue, 3 Mar 2015 16:32:26 -0800 (PST) Received: by padfa1 with SMTP id fa1so22360406pad.3 for ; Tue, 03 Mar 2015 16:32:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type; bh=KTbP7mc3ewCqQnLsUmDn7jSPJsgj6DISroXkR3yHDXQ=; b=NggaFdHeRzoBfgYw6iFjzE1PKSwfJz6+8XnD23Gs/KhKwpjn91Xt78S1IrL9AOmUvG sLHypt/9VZEf3CvNKm18iNLKNKj9Zxp43ICCQXY/SbZkfxKQG4g3Wi6tJlXMcTkI4gZz z3GCOsXFDfdGbotc13f10ha8D4qgnI2eSyB54F9QcDo1TcRHtv80hb4TPZ2DziTNTmfF 8JNBJQ8dICkAyYjaBEq+1KuoGVM4x951HlmKco7TPwX+KJuLnUQcvHGf6WadBa3fGI1c 8Y9HOxubjB1rOz2ySV8lQG78fOExNKxJp8uZG/cE9VAAWEJRmjte0U6hQWzQ3Zx13Wz1 CYWQ== X-Received: by 10.66.146.6 with SMTP id sy6mr2208852pab.150.1425429145457; Tue, 03 Mar 2015 16:32:25 -0800 (PST) Received: from ISOC-A1FD58.local (fw.jfa07.roonets.jp. [61.206.20.162]) by mx.google.com with ESMTPSA id z9sm2164514par.6.2015.03.03.16.32.23 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 03 Mar 2015 16:32:24 -0800 (PST) Message-ID: <54F65293.3090405@gmail.com> Date: Wed, 04 Mar 2015 01:32:19 +0100 From: Andrei Robachevsky User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Stephen Kent , sidr@ietf.org References: <20141126164443.26069.29089.idtracker@ietfa.amsl.com> <54760513.2050709@innovationslab.net> <54F5E16D.9020002@bbn.com> In-Reply-To: <54F5E16D.9020002@bbn.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="2tLtBlM2cN6NeCr7qEc3p0nlI8LOhqXsP" Archived-At: Subject: Re: [sidr] I-D Action: draft-ietf-sidr-rpsl-sig-06.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Mar 2015 00:32:28 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --2tLtBlM2cN6NeCr7qEc3p0nlI8LOhqXsP Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Stephen Kent wrote on 03/03/15 17:29: > I worry that accommodating multiple signatures will cause confusion for= > RPs. One would need to specify what to do if one sig fails, but other > succeed, > for example. I think the draft is clear about that, requiring all signatures to be valid. And if we want to follow the RPSS/RFC2725 approach, then multiple signatures are needed. But, it is not entirely clear to me why we need an "o" field and not just multiple "signature:" attributes in cases when signing by several parties is required. Regards, Andrei --2tLtBlM2cN6NeCr7qEc3p0nlI8LOhqXsP Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - https://gpgtools.org iEYEARECAAYFAlT2UpMACgkQljz5tZmtij968QCfd1ZoYVYvpVfyyAAK6+/ATvtU u+YAoJHi1+nh0sfp3oaiF+0QVXyzHwrD =QEzg -----END PGP SIGNATURE----- --2tLtBlM2cN6NeCr7qEc3p0nlI8LOhqXsP-- From nobody Thu Mar 5 09:44:27 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 151B41A1DFA; Thu, 5 Mar 2015 09:44:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tnJfk7-QGjEU; Thu, 5 Mar 2015 09:44:25 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 84E2E1A1BE0; Thu, 5 Mar 2015 09:44:25 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 5.12.0.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150305174425.12521.58004.idtracker@ietfa.amsl.com> Date: Thu, 05 Mar 2015 09:44:25 -0800 Archived-At: Cc: sidr@ietf.org Subject: [sidr] I-D Action: draft-ietf-sidr-rpki-rtr-rfc6810-bis-03.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2015 17:44:27 -0000 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 : The Resource Public Key Infrastructure (RPKI) to Router Protocol Authors : Randy Bush Rob Austein Filename : draft-ietf-sidr-rpki-rtr-rfc6810-bis-03.txt Pages : 30 Date : 2015-03-05 Abstract: In order to verifiably validate the origin Autonomous Systems and Autonomous System Paths of BGP announcements, routers need a simple but reliable mechanism to receive Resource Public Key Infrastructure (RFC 6480) prefix origin data and router keys from a trusted cache. This document describes a protocol to deliver validated prefix origin data and router keys to routers. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sidr-rpki-rtr-rfc6810-bis/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-sidr-rpki-rtr-rfc6810-bis-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-sidr-rpki-rtr-rfc6810-bis-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Mar 5 09:54:54 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD5B31A1BE8 for ; Thu, 5 Mar 2015 09:54:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X0-pzKhJqx-p for ; Thu, 5 Mar 2015 09:54:52 -0800 (PST) Received: from cyteen.hactrn.net (cyteen.hactrn.net [66.92.66.68]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 40CC91A1EFE for ; Thu, 5 Mar 2015 09:54:47 -0800 (PST) Received: from minas-ithil.hactrn.net (c-24-34-34-101.hsd1.ma.comcast.net [24.34.34.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "nargothrond.hactrn.net", Issuer "Grunchweather Associates" (verified OK)) by cyteen.hactrn.net (Postfix) with ESMTPS id 2EBB5112A; Thu, 5 Mar 2015 17:54:45 +0000 (UTC) Received: from minas-ithil.hactrn.net (localhost [IPv6:::1]) by minas-ithil.hactrn.net (Postfix) with ESMTP id 91B801675EF3; Thu, 5 Mar 2015 12:54:57 -0500 (EST) Date: Thu, 05 Mar 2015 12:54:57 -0500 From: Rob Austein To: sidr-chairs@tools.ietf.org References: <20150305174425.12521.58004.idtracker@ietfa.amsl.com> User-Agent: Wanderlust/2.15.5 (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 Message-Id: <20150305175457.91B801675EF3@minas-ithil.hactrn.net> Archived-At: Cc: sidr@ietf.org Subject: [sidr] Requesting WGLC of draft-ietf-sidr-rpki-rtr-rfc6810-bis-03.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Mar 2015 17:54:53 -0000 Hereby request WGLC of draft-ietf-sidr-rpki-rtr-rfc6810-bis-03, the updated version of the RPKI-RTR protocol with support for BGPSEC keys. The -03 draft is just a refresh (no changes other than date) of -02, which we intended to WGLC last summer but apparently never did. There is at least one server implementation (mine) and there are at least two client implementations (mine and rtrlib). From nobody Fri Mar 6 01:22:33 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFA791ACD37 for ; Fri, 6 Mar 2015 01:22:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ei8w4AdqMbh1 for ; Fri, 6 Mar 2015 01:22:30 -0800 (PST) Received: from walnut.tislabs.com (walnut.tislabs.com [192.94.214.200]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DA08B1ACD3A for ; Fri, 6 Mar 2015 01:22:30 -0800 (PST) Received: from nova.tislabs.com (unknown [10.66.1.77]) by walnut.tislabs.com (Postfix) with ESMTP id 2CED528B0017 for ; Fri, 6 Mar 2015 04:22:30 -0500 (EST) Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1]) by nova.tislabs.com (Postfix) with ESMTP id BD9B51F8035; Fri, 6 Mar 2015 04:22:29 -0500 (EST) From: Sandra Murphy Content-Type: multipart/signed; boundary="Apple-Mail=_1F13AF90-0066-47FF-AA97-9424D53E8D10"; protocol="application/pgp-signature"; micalg=pgp-sha512 Date: Fri, 6 Mar 2015 04:22:30 -0500 Message-Id: To: "sidr@ietf.org list" Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) X-Mailer: Apple Mail (2.1510) Archived-At: Cc: Sandra Murphy Subject: [sidr] WGLC for draft-ietf-sidr-rpki-rtr-rfc6810-bis-03 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Mar 2015 09:22:32 -0000 --Apple-Mail=_1F13AF90-0066-47FF-AA97-9424D53E8D10 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii The authors of The Resource Public Key Infrastructure (RPKI) to Router = Protocol believe that the work is ready for a working grow last call. This starts a last call for that draft. You may find it at = https://tools.ietf.org/html/draft-ietf-sidr-rpki-rtr-rfc6810-bis-03. Please comment to the list whether you believe that this draft is ready = for publication. The wglc will be two weeks, ending on Friday, March = 20. --Sandy, speaking as one of the wg co-chairs --Apple-Mail=_1F13AF90-0066-47FF-AA97-9424D53E8D10 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJU+XHXAAoJEHplpQeet0IZD1oP/0g2n/Hb6buSCztQ4q29DmcF EMezB1ZB4JgeI2S4ExLSG+521AnKceT8kRnu9ddti1qjKukpKC8sXtDhfu7xzgHo DSK8oWTe913+7ei07OHR7+GH7cX+v+M5s192MsXHZiAStpeU4JViRnTZevgUCIrq zNBjAX2TQkDIl3n/xykPxxJFKpxbLjgbvenJfA3p6cWnFtT20/JOCMtyhIZ2uF/Q O4nySjYoVIC6sT/1Y0PIZlZPY2oYXf5Ahr7ZqKwx0gQC/7lrqC74VDSnfDnDxxTl QMhbXlYE0WYsoEOu3AZ2jDaCr82fEsRfGNarVFoDpW5VqnQdwpLzO3mOXBoy5u6+ gBGkbjXNa0OQwRFa6pwy57Gp06KslQeYLW/h458pKPdO/IQCXoYHRSSnI0h6prNg Em48SIHTToWNy2BdHr8xYbu9//ougbIS5413n5/b2EpM2pTN6fjLWRbfIR/efK8x i3Fde4O5GpFayXmK6wcwsswDe1rJExJpGV/VdEbeDxkGuytrw5X8261Oks2vjhRs UzKDpxBqBDswkDpk9T0E8QBtw/9w9DxuHUFzT9/vb9LrQ+QM0XIc1WEJuzrlCeyY K0M/dIbhPM+8YkMdLq5vfC7MUovKdYhXhcQ3tZ+3f8QzNWgdc1JlemHSmd7B2TLD uItT03IypUOt8ELE8dCE =O/pn -----END PGP SIGNATURE----- --Apple-Mail=_1F13AF90-0066-47FF-AA97-9424D53E8D10-- From nobody Fri Mar 6 02:04:37 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D132E1A00C7 for ; Fri, 6 Mar 2015 02:04:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wp9NNC6ZBslW for ; Fri, 6 Mar 2015 02:04:35 -0800 (PST) Received: from koko.ripe.net (koko.ripe.net [IPv6:2001:67c:2e8:11::c100:1348]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 278661A00C3 for ; Fri, 6 Mar 2015 02:04:35 -0800 (PST) Received: from nene.ripe.net ([193.0.23.10]) by koko.ripe.net with esmtps (UNKNOWN:AES256-GCM-SHA384:256) (Exim 4.72) (envelope-from ) id 1YTp7M-00031y-DL; Fri, 06 Mar 2015 11:04:30 +0100 Received: from sslvpn.ipv6.ripe.net ([2001:67c:2e8:9::c100:14e6] helo=[IPv6:2001:67c:2e8:5009::18f]) by nene.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1YTp7M-0001LD-7C; Fri, 06 Mar 2015 11:04:28 +0100 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) Content-Type: multipart/alternative; boundary="Apple-Mail=_23E3091E-0F4E-4B59-9CC3-D3437E9FF7A8" From: Tim Bruijnzeels In-Reply-To: Date: Fri, 6 Mar 2015 11:04:26 +0100 Message-Id: <4516D0B2-E1FB-4F6A-9411-03BA41B7CE67@ripe.net> References: To: Sandra Murphy X-Mailer: Apple Mail (2.2070.6) 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] 0.0 HTML_MESSAGE BODY: HTML included in message X-RIPE-Signature: 784d7acfe6559f2a0b602ec6519a0719e58617970d99f9b9dae8e41d3eebb79c Archived-At: Cc: "sidr@ietf.org list" Subject: Re: [sidr] WGLC for draft-ietf-sidr-rpki-rtr-rfc6810-bis-03 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Mar 2015 10:04:37 -0000 --Apple-Mail=_23E3091E-0F4E-4B59-9CC3-D3437E9FF7A8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, I read the document and it looks good to me, except for one = clarification in section 5.10: = https://tools.ietf.org/html/draft-ietf-sidr-rpki-rtr-rfc6810-bis-03#sectio= n-5.10 = The IPv4 Prefix description (section 5.6) has the following, and the = IPv6 text refers back to this: > The lowest order bit of the Flags field is 1 for an announcement and > 0 for a withdrawal. I expect that announcement and withdrawal is signalled in a similar way = for router keys? If so it would be good to make this explicit. Tim > On 06 Mar 2015, at 10:22, Sandra Murphy wrote: >=20 > The authors of The Resource Public Key Infrastructure (RPKI) to = Router Protocol believe that the work is ready for a working grow last = call. >=20 > This starts a last call for that draft. You may find it at = https://tools.ietf.org/html/draft-ietf-sidr-rpki-rtr-rfc6810-bis-03. >=20 > Please comment to the list whether you believe that this draft is = ready for publication. The wglc will be two weeks, ending on Friday, = March 20. >=20 > --Sandy, speaking as one of the wg co-chairs > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr --Apple-Mail=_23E3091E-0F4E-4B59-9CC3-D3437E9FF7A8 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hi,

I = read the document and it looks good to me, except for one clarification = in section 5.10:
https://tools.ietf.org/html/draft-ietf-sidr-rpki-rtr-rfc6810-bi= s-03#section-5.10

The IPv4 Prefix description (section 5.6) has the following, = and the IPv6 text refers back to this:
The lowest order bit of the Flags field is 1 for an =
announcement and
0 for a withdrawal.

I expect that announcement and = withdrawal is signalled in a similar way for router keys? If so it would = be good to make this explicit.

Tim





On = 06 Mar 2015, at 10:22, Sandra Murphy <sandy@tislabs.com> = wrote:

The = authors of  The Resource Public Key Infrastructure (RPKI) to Router = Protocol believe that the work is ready for a working grow last call.

This starts a last call for that draft. =  You may find it at https://tools.ietf.org/html/draft-ietf-sidr-rpki-rtr-rfc6810-bi= s-03.

Please comment to the list = whether you believe that this draft is ready for publication.  The = wglc will be two weeks, ending on Friday, March 20.

--Sandy, speaking as one of the wg co-chairs
_______________________________________________
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr

= --Apple-Mail=_23E3091E-0F4E-4B59-9CC3-D3437E9FF7A8-- From nobody Fri Mar 6 02:10:42 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3974C1A037A for ; Fri, 6 Mar 2015 02:10:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sLZeMk8UK3FE for ; Fri, 6 Mar 2015 02:10:39 -0800 (PST) Received: from ran.psg.com (ran.psg.com [198.180.150.18]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 86E301A00B6 for ; Fri, 6 Mar 2015 02:10:37 -0800 (PST) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.82) (envelope-from ) id 1YTpDG-0004mO-M1; Fri, 06 Mar 2015 10:10:35 +0000 Date: Fri, 06 Mar 2015 19:10:31 +0900 Message-ID: From: Randy Bush To: Tim Bruijnzeels In-Reply-To: <4516D0B2-E1FB-4F6A-9411-03BA41B7CE67@ripe.net> References: <4516D0B2-E1FB-4F6A-9411-03BA41B7CE67@ripe.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.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Cc: "sidr@ietf.org list" , Sandra Murphy Subject: Re: [sidr] WGLC for draft-ietf-sidr-rpki-rtr-rfc6810-bis-03 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Mar 2015 10:10:41 -0000 > I expect that announcement and withdrawal is signalled in a similar > way for router keys? If so it would be good to make this explicit. . thanks randy From nobody Fri Mar 6 16:43:47 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94F061A877A; Fri, 6 Mar 2015 16:43:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GKT5MyeB7OAB; Fri, 6 Mar 2015 16:43:44 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 475CA1A700F; Fri, 6 Mar 2015 16:43:44 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 5.12.0.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150307004344.316.10229.idtracker@ietfa.amsl.com> Date: Fri, 06 Mar 2015 16:43:44 -0800 Archived-At: Cc: sidr@ietf.org Subject: [sidr] I-D Action: draft-ietf-sidr-bgpsec-rollover-03.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Mar 2015 00:43:45 -0000 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 : BGPSEC Router Certificate Rollover Authors : Roque Gagliano Keyur Patel Brian Weis Filename : draft-ietf-sidr-bgpsec-rollover-03.txt Pages : 15 Date : 2015-03-06 Abstract: BGPSEC will need to address the impact from regular and emergency rollover processes for the BGPSEC End-Entity (EE) certificates that will be performed by Certificate Authorities (CAs) participating at the Resource Public Key Infrastructure (RPKI). Rollovers of BGPSEC EE certificates must be carefully managed in order to synchronize distribution of router public keys and the usage of those pubic keys by BGPSEC routers. This document provides general recommendations for that process, as well as describing reasons why the rollover of BGPSEC EE certificates might be necssary. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sidr-bgpsec-rollover/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-sidr-bgpsec-rollover-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-sidr-bgpsec-rollover-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Mar 9 12:12:33 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE4851A8F4E for ; Mon, 9 Mar 2015 12:12:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.789 X-Spam-Level: X-Spam-Status: No, score=0.789 tagged_above=-999 required=5 tests=[BAYES_50=0.8, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9aCrBhIV_JqL for ; Mon, 9 Mar 2015 12:12:28 -0700 (PDT) Received: from walnut.tislabs.com (walnut.tislabs.com [192.94.214.200]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0BDD21A8AED for ; Mon, 9 Mar 2015 12:12:17 -0700 (PDT) Received: from nova.tislabs.com (unknown [10.66.1.77]) by walnut.tislabs.com (Postfix) with ESMTP id 5125828B003D for ; Mon, 9 Mar 2015 15:12:16 -0400 (EDT) Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1]) by nova.tislabs.com (Postfix) with ESMTP id 36AE21F804E; Mon, 9 Mar 2015 15:12:16 -0400 (EDT) Content-Type: multipart/signed; boundary="Apple-Mail=_5E3B46B6-4E1F-44B9-8F94-DAD049B1F4A3"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Sandra Murphy In-Reply-To: <390084A4-88A5-4C5C-822B-1DFD6D3ADB05@ripe.net> Date: Mon, 9 Mar 2015 15:12:16 -0400 Message-Id: <9E977FB4-F176-4653-B3D2-079D2A44D13B@tislabs.com> References: <20150216191609.11058.6727.idtracker@ietfa.amsl.com> <390084A4-88A5-4C5C-822B-1DFD6D3ADB05@ripe.net> To: "sidr@ietf.org list" X-Mailer: Apple Mail (2.1510) Archived-At: Cc: Sandra Murphy Subject: Re: [sidr] draft-ietf-sidr-delta-protocol-00.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2015 19:12:31 -0000 --Apple-Mail=_5E3B46B6-4E1F-44B9-8F94-DAD049B1F4A3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 So after all the anguish about the rsync protocol, we now have a = suggested replacement. But there's been very little comment. Tim did a thorough job of describing the design goals. It would be useful if the wg paid attention to this. --Sandy, speaking as one of the wg co-chairs On Feb 17, 2015, at 12:54 PM, Tim Bruijnzeels wrote: > Hi all, >=20 > Following working group adoption I submitted the latest version of the = delta protocol document as a working group item: >=20 >> https://datatracker.ietf.org/doc/draft-ietf-sidr-delta-protocol/ >=20 > Sriram, allow me to get back on previous comments you made during the = call for adoption: >=20 >> When authors spin a WG draft version (assuming it would be accepted = as a WG draft), >> it would be good if the following suggestions can be given = consideration: >=20 > The current version is unchanged except for its name and number (00). = But of course we can give consideration to these and other suggestions = for a next version. >=20 >> 1. Include one short paragraph just to discuss key disadvantages of = rsync and >> how the delta protocol avoids or overcomes the same. >=20 > I would like to avoid general discussion that may include opinions = about how severe perceived disadvantages of rsync are. Instead I would = like to focus on a more positive, and factual message, of what we are = trying to achieve with this protocol, and why. >=20 > The last paragraph of the introduction has some text on this: >=20 > This protocol is designed to be consistent with the publication > protocol [I-D.ietf-sidr-publication] and treats publication events = of > one or more repository objects as immutable events that can be > communicated to relying parties. This approach helps to minimize = the > amount of data that traverses the network and thus helps minimize = the > amount of time until repository convergence occurs. This protocol > also provides a standards based way to obtain consistent, point in > time views of a single repository eliminating a number of = consistency > related issues. Finally, this approach allows for caching > infrastructure to be used to serve this immutable data, and thus > helps to reduce the load on a publication server when a large a > number of relying parties are querying it. >=20 > But admittedly this is incomplete and lacks explanation for why we = believe these are good things to have. >=20 > I am happy to elaborate more on this here, and if it's useful to = include in the document itself we can add more text.. >=20 > Design goals and benefits that I see (did not check everything with my = co-authors, so will not speak for them..): >=20 >=20 > =3D Based on publication protocol >=20 > Not the most important design goal, but useful because this way we do = not need to reinvent all of the data structure. We can re-use the = and elements that have already been defined. = Furthermore this may be easier for publication servers - they can re-use = update messages from Certification Authorities in update messages with = minimal effort. >=20 > =3D Minimise data transfer >=20 > We don't want to waste bits.. this is nothing against rsync, rsync is = actually very good at this. We just thought it would be good if we = didn't waste bits here either. >=20 > =3D Point in time views >=20 > This actually refers to a problem with rsync. Objects may be = republished mid-transfer and this can lead to things like getting a new = CRL, but an old manifest - and then the hash of the CRL doesn't match = and the MFT EE may be revoked. Clients can keep trying until they get = something that seems consistent, but.. if a Certification Server just = sends all its updates (CRL, MFT, ROAs etc) in one message to a = publication server, then all of this can be served as one delta and a = lot of this goes away. >=20 > =3D Caching infrastructure / CDNs (and immutable data) >=20 > There are many different http caching servers that can be used to deal = with the load of serving static data to a large number of clients. There = are also many commercial Global Content Delivery Networks (CDNs) that = can be used to improve this further - that can operate for some time = even if the back-end system is unavailable, can spread the load further, = and reduce latency to globally distributed clients. >=20 > Of course it is technically possible to build a CDN infrastructure = with rsync, using anycast or DNS tricks etc etc, but this is far from a = trivial effort. It's expensive to do, and easy to mess up, where the = http based CDNs and caching servers have had years of battle testing in = the internet industry. >=20 > =3D Shift load to clients to support scaling >=20 > Not mentioned yet in the introduction. >=20 > There is an asymmetry between the number of clients (relying parties) = and servers. With rsync the server needs to invest effort (CPU and = memory) in a dialogue with the client in order to work out what the = actually delta is that the client needs. The proportion of this effort = spent by the server in this dialogue is a limiting factor on how many = clients can be served. >=20 > Of course we can add more servers to counter this, but there is a lot = more gain to be had if we can minimise the effort that the server = actually has to invest. >=20 > For this reason the protocol shifts almost all the (CPU) work to the = relying party. The server creates a notification file that refers to = static snapshot and possible delta files. The RP can work out what they = need to get all on their own. >=20 > Serving this static data may still have bottlenecks with regards to = network usage and server memory, but this is where the http caching = servers and CDNs come in very helpful. >=20 >=20 > =3D Only support what's needed / protocol stability >=20 > Also not mentioned yet, but I remember hallway discussions where = people mentioned things like: versioning=85 why don't you just use = git/svn? >=20 > This seems overkill to me because these tools (like rsync) provide = many options that we don't need here. Also, which version of git/svn, or = rsync, are we talking about? >=20 > I think it would be best to have the protocol stripped down to only = the bare essentials, and version it clearly. >=20 >=20 > =3D Availability of open-source libraries for transport http >=20 > There are numerous open source http libraries available to use for RP = software in every major programming language. Helps with performance (no = need to fork a process), testing, and it reduces the risk of the system = as a whole of pretty much relying on a single implementation. >=20 >=20 > =3D Transport Protocol agnostic? >=20 > Although the protocol clearly relies on http caching, it was a design = decision to repeat relevant data such as session ids, and versions, in = all files (rather than making this implicit in their location). The = reason is that this will make it easier to share these files using other = transport or sharing protocols. >=20 >=20 >> 2. Possible to say something about the relevance of or comparison = with >> Aspera (since they make big performance improvement claims over rsync = etc.)?=20 >> http://asperasoft.com/resources/benchmarks/ >> http://asperasoft.com/performance-calculator/ >=20 > This seems to be an option as a transport protocol, but not as a = complete delta protocol - i.e. helping the client figure out what to = get. >=20 > This may be quicker than http, but I am not convinced mainly because = it's a proprietary service. We would depend on a single vendor to = support the transport protocol. >=20 >=20 >=20 >=20 > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr --Apple-Mail=_5E3B46B6-4E1F-44B9-8F94-DAD049B1F4A3 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJU/fCQAAoJEHplpQeet0IZejsQAKWUM3bJ/PiHgWeeziSpX9Cf HO9fEG6ooidZF9sWF2XVOo1NLPVNJOAZysrNcuRO//69XHRZ3yO34UkGwpc/oR+j +X/z5qnDV3HSf0SM4EB//DjbM2AzTEZ4YHvu9XKjOwGiW17nA46EztwXHGfjy36W 3Uotwd+jBygVSpqgI58kdxsMvJv6x9l8seqBwODr1+xhpoIjHhHGg0lJNay2VP5J CUKA8QAtLEQiCuRC61EIe64DxHVRoVYFkbZTWmnxGhzUK4kcpAcMYMEYqB7uwc7M 6pgqk4ECVTiZ47fceM5aI+7mdb0FtKroYWlCOfHqqemTVwgmgJeBTp7kNTlFCL2l JnSyuuvQsc7UT0D/Kdnf+LllCHgGschWOroGen662FqOtpscGAFCMU/zmRvTEw/t a2Er98hI5ELlD0Ybtifu/p6Zoj1AV4U0YBbt2hzQdF36lS3QJUW/gTt3IofCRV+V fYN4TJsgzSbLWyBT0G6/acJkMTIT+kisxXDlP/F+b+z4Vg6zowuA/T+hKMrODipW juGkZyVW7h7J21HqU5/HruxDMYv+zWT96TU/p3BzEv8RK6g9mTUUnMHuKXMJlm92 izRoihAqbUe6Fy9OInhlw7XSReDOmVx2kwhbFz3OgWV2NYFkOFljRInEEE7RpZhL fZ3edyngc5IS8V7H49H6 =cgwH -----END PGP SIGNATURE----- --Apple-Mail=_5E3B46B6-4E1F-44B9-8F94-DAD049B1F4A3-- From nobody Mon Mar 9 13:38:24 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B15701ACD16 for ; Mon, 9 Mar 2015 13:38:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q4Gn5d2Ge54Y for ; Mon, 9 Mar 2015 13:38:11 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C6BC71AC416 for ; Mon, 9 Mar 2015 13:37:58 -0700 (PDT) Received: from ssh.bbn.com ([192.1.122.15]:57511 helo=COMSEC.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1YV4R3-000Jzm-7y for sidr@ietf.org; Mon, 09 Mar 2015 16:37:57 -0400 Message-ID: <54FE04A4.8040302@bbn.com> Date: Mon, 09 Mar 2015 16:37:56 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: sidr@ietf.org References: <20150216191609.11058.6727.idtracker@ietfa.amsl.com> <390084A4-88A5-4C5C-822B-1DFD6D3ADB05@ripe.net> <9E977FB4-F176-4653-B3D2-079D2A44D13B@tislabs.com> In-Reply-To: <9E977FB4-F176-4653-B3D2-079D2A44D13B@tislabs.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [sidr] draft-ietf-sidr-delta-protocol-00.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2015 20:38:23 -0000 Sandy, I reviewed the doc with David M., since he is a co-author and because his office is down the hall :-). As a result of our discussion he has a number of comments to be addressed in the next version. Steve > So after all the anguish about the rsync protocol, we now have a suggested replacement. But there's been very little comment. > > Tim did a thorough job of describing the design goals. From nobody Mon Mar 9 14:43:57 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE67B1ACD80 for ; Mon, 9 Mar 2015 14:43:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cKTkXVnovYHe for ; Mon, 9 Mar 2015 14:43:51 -0700 (PDT) Received: from walnut.tislabs.com (walnut.tislabs.com [192.94.214.200]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D93CF1ACD0D for ; Mon, 9 Mar 2015 14:43:26 -0700 (PDT) Received: from nova.tislabs.com (unknown [10.66.1.77]) by walnut.tislabs.com (Postfix) with ESMTP id 38F1928B0017 for ; Mon, 9 Mar 2015 17:43:26 -0400 (EDT) Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1]) by nova.tislabs.com (Postfix) with ESMTP id 1E2D21F8035; Mon, 9 Mar 2015 17:43:26 -0400 (EDT) From: Sandra Murphy Content-Type: multipart/signed; boundary="Apple-Mail=_5C99A63B-E313-4887-BF98-8F9E88FD6EC0"; protocol="application/pgp-signature"; micalg=pgp-sha512 Date: Mon, 9 Mar 2015 17:43:27 -0400 Message-Id: <8251F4B5-C3D2-4D8C-89B8-0642E4A75B49@tislabs.com> To: "sidr@ietf.org list" Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) X-Mailer: Apple Mail (2.1510) Archived-At: Cc: Sandra Murphy Subject: [sidr] draft agenda posted X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2015 21:43:54 -0000 --Apple-Mail=_5C99A63B-E313-4887-BF98-8F9E88FD6EC0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii A draft agenda has been posted. Some of the requests for agenda time came to just one of the chairs. If = you made a request that is not on the agenda, you should send a query to = the sidr-chairs@ietf.org. =20 The deadline for drafts still has some time, so there may be other work = to be added to the agenda. There is plenty of room for further presentations. If you have a topic = for the wg, send a request to sidr-chairs@ietf.org/ Note: It is much safer to use the sidr-chairs@ietf.org alias than to = direct a message to an individual chair. --Sandy --Apple-Mail=_5C99A63B-E313-4887-BF98-8F9E88FD6EC0 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJU/hP/AAoJEHplpQeet0IZncAQAJi2cYqs6zVk2qphSeNg25Rg SCN72Fracib3SeN0pizIPvIFmPhvRqP6EQYBIuK4K/7gWerMMWlhXVMDf8V2rXO7 uXItQX0ftxl1Jyv0wMjmTE8u1W3tJepLDG7uZ0ZS/VGD4TGisINwqokL3WDv3Nrk DZwm6FUH5rz+Nq+qf0/L/s66eGvWEtt8SqpOi1joQ5hoV/SjbiUEaZJjiKdl3u2v n2xgOI+V56qTGwZnA7zGkIcsfik4QJXsu3PSR89A4fO/hDXN8TEXAPUEH+YSG3t5 RhKJzVq7AFqwOITN+CjfIwLeMFCOk2oNUUPqnm5pia3wZ69/m66yZ71m9DSFHocv tievw+OWaDV56xXgzzLDbpeWOM/D+EIXTvAzMMNzjfuZWiahbcruD972SPceW8O2 8IfB21PuYdHacEicT5DsKDT9EbKOiKxNSYQ9oGq+dqsUjqZ6PwbEtCL6H1+mvyuD hISbuxBEp/KmDrYJkmnp9SvtEhuABMelKU6wdgpMxv+yDYBYO6AQyGIVCGsZ04u7 ZLa9Eud+gHwA/WIR0g7XtcBZLuukBeoinCB/VmBYU4rQK0r/VtLbKsvu2JDgwX/B a8yTL4Um0ItFuRr08ffof2DF45eMwe/X4ICR21l7sx22NCtb1MSV4EKquKUbd78C Tpl+SbHHwLS333bszUo9 =EiiN -----END PGP SIGNATURE----- --Apple-Mail=_5C99A63B-E313-4887-BF98-8F9E88FD6EC0-- From nobody Mon Mar 9 15:17:28 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C32C41ACD7F; Mon, 9 Mar 2015 15:17:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YymuLBQHnKZL; Mon, 9 Mar 2015 15:17:16 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0727.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:727]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 84F691A8912; Mon, 9 Mar 2015 15:17:15 -0700 (PDT) Received: from DM2PR09MB0302.namprd09.prod.outlook.com (25.160.96.147) by DM2PR09MB0303.namprd09.prod.outlook.com (25.160.96.148) with Microsoft SMTP Server (TLS) id 15.1.106.15; Mon, 9 Mar 2015 22:16:55 +0000 Received: from DM2PR09MB0302.namprd09.prod.outlook.com ([25.160.96.147]) by DM2PR09MB0302.namprd09.prod.outlook.com ([25.160.96.147]) with mapi id 15.01.0106.007; Mon, 9 Mar 2015 22:16:54 +0000 From: "Sriram, Kotikalapudi" To: "idr@ietf.org" Thread-Topic: New Version Notification for draft-sriram-idr-route-leak-detection-mitigation-00.txt Thread-Index: AQHQWq/g4I7A2nv0JUGX1gNoY7bApJ0Usafw Date: Mon, 9 Mar 2015 22:16:54 +0000 Message-ID: References: <20150309212724.28218.56595.idtracker@ietfa.amsl.com> In-Reply-To: <20150309212724.28218.56595.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [129.6.140.100] authentication-results: ietf.org; dkim=none (message not signed) header.d=none; x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DM2PR09MB0303; x-forefront-antispam-report: BMV:1; SFV:NSPM; SFS:(10019020)(6009001)(377424004)(106116001)(450100001)(2900100001)(92566002)(77156002)(62966003)(1720100001)(33656002)(2656002)(46102003)(66066001)(54356999)(50986999)(74316001)(76176999)(86362001)(40100003)(102836002)(230783001)(122556002)(87936001)(2351001)(76576001)(2501003)(15975445007)(110136001)(19580395003)(2950100001); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR09MB0303; H:DM2PR09MB0302.namprd09.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5002009)(5005006); SRVR:DM2PR09MB0303; BCL:0; PCL:0; RULEID:; SRVR:DM2PR09MB0303; x-forefront-prvs: 05102978A2 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Mar 2015 22:16:54.6309 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR09MB0303 Archived-At: Cc: "sidr wg list \(sidr@ietf.org\)" Subject: [sidr] FW: New Version Notification for draft-sriram-idr-route-leak-detection-mitigation-00.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Mar 2015 22:17:18 -0000 Um91dGUgbGVha3MgcHJvYmxlbSBkZWZpbml0aW9uIGlzIGFscmVhZHkgd29yayBpbiBwcm9ncmVz cyBpbiB0aGUgR1JPVyBXRy4NCmh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYt Z3Jvdy1yb3V0ZS1sZWFrLXByb2JsZW0tZGVmaW5pdGlvbi0wMSANCg0KVGhpcyByZWxhdGVkIG5l dyBkcmFmdCBhZGRyZXNzZXMgdGVjaG5pcXVlcyBmb3IgZGV0ZWN0aW9uIGFuZCBtaXRpZ2F0aW9u IG9mIHJvdXRlIGxlYWtzLg0KVGhlIElEUiBjaGFpcnMgaGF2ZSBhZ3JlZWQgdG8gaW5jbHVkZSB0 aGlzIGRyYWZ0IGluIHRoZSBhZ2VuZGEgZm9yIERhbGxhcy4NClNvIHdlICh0aGUgYXV0aG9ycykg bG9vayBmb3J3YXJkIHRvIHByZXNlbnRpbmcgdGhpcyB3b3JrIGFuZCByZWNlaXZpbmcgeW91ciBj b21tZW50cy4NCkNvbW1lbnRzIGFyZSB3ZWxjb21lIG9uIHRoZSBtYWlsaW5nIGxpc3QgYXMgd2Vs bC4NCg0KU3JpcmFtDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoN CkEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1zcmlyYW0taWRyLXJvdXRlLWxlYWstZGV0ZWN0 aW9uLW1pdGlnYXRpb24tMDAudHh0DQpoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5 IEtvdGlrYWxhcHVkaSBTcmlyYW0gYW5kIHBvc3RlZCB0byB0aGUgSUVURiByZXBvc2l0b3J5Lg0K DQpOYW1lOgkJZHJhZnQtc3JpcmFtLWlkci1yb3V0ZS1sZWFrLWRldGVjdGlvbi1taXRpZ2F0aW9u DQpSZXZpc2lvbjoJMDANClRpdGxlOgkJTWV0aG9kcyBmb3IgRGV0ZWN0aW9uIGFuZCBNaXRpZ2F0 aW9uIG9mIEJHUCBSb3V0ZSBMZWFrcw0KRG9jdW1lbnQgZGF0ZToJMjAxNS0wMy0wOQ0KR3JvdXA6 CQlJbmRpdmlkdWFsIFN1Ym1pc3Npb24NClBhZ2VzOgkJMTQNClVSTDogICAgICAgICAgICBodHRw Oi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1zcmlyYW0taWRyLXJvdXRlLWxl YWstZGV0ZWN0aW9uLW1pdGlnYXRpb24tMDAudHh0DQpTdGF0dXM6ICAgICAgICAgaHR0cHM6Ly9k YXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtc3JpcmFtLWlkci1yb3V0ZS1sZWFrLWRldGVj dGlvbi1taXRpZ2F0aW9uLw0KSHRtbGl6ZWQ6ICAgICAgIGh0dHA6Ly90b29scy5pZXRmLm9yZy9o dG1sL2RyYWZ0LXNyaXJhbS1pZHItcm91dGUtbGVhay1kZXRlY3Rpb24tbWl0aWdhdGlvbi0wMA0K DQpBYnN0cmFjdDoNCiAgIEluIFtJLUQuaWV0Zi1ncm93LXJvdXRlLWxlYWstcHJvYmxlbS1kZWZp bml0aW9uXSwgdGhlIGF1dGhvcnMgaGF2ZQ0KICAgcHJvdmlkZWQgYSBkZWZpbml0aW9uIG9mIHRo ZSByb3V0ZSBsZWFrIHByb2JsZW0sIGFuZCBhbHNvIGVudW1lcmF0ZWQNCiAgIHNldmVyYWwgdHlw ZXMgb2Ygcm91dGUgbGVha3MuICBJbiB0aGlzIGRvY3VtZW50LCB3ZSBmaXJzdCBleGFtaW5lDQog ICB3aGljaCBvZiB0aG9zZSByb3V0ZS1sZWFrIHR5cGVzIGFyZSBkZXRlY3RlZCBhbmQgbWl0aWdh dGVkIGJ5IHRoZQ0KICAgZXhpc3Rpbmcgb3JpZ2luIHZhbGlkYXRpb24gW1JGQyA2ODExXSBhbmQg QkdQU0VDIHBhdGggdmFsaWRhdGlvbiBbSS0NCiAgIEQuaWV0Zi1zaWRyLWJncHNlYy1wcm90b2Nv bF0uICBXaGVyZSB0aGUgY3VycmVudCBCR1BTRUMgcHJvdG9jb2wNCiAgIGRvZXNuJ3Qgb2ZmZXIg YSBzb2x1dGlvbiwgdGhpcyBkb2N1bWVudCBzdWdnZXN0cyBhbiBlbmhhbmNlbWVudCB0aGF0DQog ICB3b3VsZCBleHRlbmQgdGhlIHJvdXRlLWxlYWsgZGV0ZWN0aW9uIGFuZCBtaXRpZ2F0aW9uIGNh cGFiaWxpdHkgb2YNCiAgIEJHUFNFQy4gIFRoZSBzb2x1dGlvbiBjYW4gYmUgaW1wbGVtZW50ZWQg aW4gQkdQIHdpdGhvdXQgbmVjZXNzYXJpbHkNCiAgIHR5aW5nIGl0IHRvIEJHUFNFQy4gIEluY29y cG9yYXRpbmcgdGhlIHNvbHV0aW9uIGluIEJHUFNFQyBpcyBvbmUgd2F5DQogICBvZiBpbXBsZW1l bnRpbmcgaXQgaW4gYSBzZWN1cmUgd2F5LiAgV2UgZG8gbm90IGNsYWltIHRvIGhhdmUgcHJvdmlk ZWQNCiAgIGEgc29sdXRpb24gZm9yIGFsbCBwb3NzaWJsZSB0eXBlcyBvZiByb3V0ZSBsZWFrcywg YnV0IHRoZSBzb2x1dGlvbg0KICAgY292ZXJzIHNldmVyYWwsIGVzcGVjaWFsbHkgY29uc2lkZXJp bmcgc29tZSBzaWduaWZpY2FudCByb3V0ZS1sZWFrDQogICBhdHRhY2tzIG9yIG9jY3VycmVuY2Vz IHRoYXQgaGF2ZSBiZWVuIG9ic2VydmVkIGluIHJlY2VudCB5ZWFycy4gIFRoZQ0KICAgZG9jdW1l bnQgYWxzbyBpbmNsdWRlcyBhIHN0b3BnYXAgbWV0aG9kIGZvciBkZXRlY3Rpb24gYW5kIG1pdGln YXRpb24NCiAgIG9mIHJvdXRlIGxlYWtzIGZvciB0aGUgcGhhc2Ugd2hlbiBCR1BTRUMgKHBhdGgg dmFsaWRhdGlvbikgaXMgbm90IHlldA0KICAgZGVwbG95ZWQgYnV0IG9ubHkgb3JpZ2luIHZhbGlk YXRpb24gaXMgZGVwbG95ZWQuDQoNCg== From nobody Mon Mar 9 18:07:55 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B73221A9092 for ; Mon, 9 Mar 2015 18:07:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qIwtaRlZ7f5b for ; Mon, 9 Mar 2015 18:07:51 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF7151A0231 for ; Mon, 9 Mar 2015 18:07:50 -0700 (PDT) Received: from socket.bbn.com ([192.1.120.102]:34790) by smtp.bbn.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1YV8eD-000NsA-Qm for sidr@ietf.org; Mon, 09 Mar 2015 21:07:49 -0400 X-Submitted: to socket.bbn.com (Postfix) with ESMTPSA id 8E1EC3FFEA Message-ID: <54FE43E5.8020705@bbn.com> Date: Mon, 09 Mar 2015 21:07:49 -0400 From: Richard Hansen User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: sidr@ietf.org References: <20150309225648.27496.13505.idtracker@ietfa.amsl.com> In-Reply-To: <20150309225648.27496.13505.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20150309225648.27496.13505.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: [sidr] Fwd: New Version Notification for draft-rhansen-sidr-rfc6487bis-00.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2015 01:07:52 -0000 Hi all, I have submitted a bis of RFC6487 as a -00 individual submission, and will be presenting it in Dallas. It's a minor change from RFC6487. Changes incorporated: * all 3 verified errata * RFC 7318 (update) * two changes that were submitted as errata but rejected for being technical changes: http://www.rfc-editor.org/errata_search.php?rfc=6487&rec_status=9 Comments welcome. Thanks, Richard -------- Forwarded Message -------- Subject: New Version Notification for draft-rhansen-sidr-rfc6487bis-00.txt Date: Mon, 09 Mar 2015 15:56:48 -0700 From: internet-drafts@ietf.org To: Richard Hansen , Andrew Newton , Robert Loomans , Geoff Huston , George Michaelson A new version of I-D, draft-rhansen-sidr-rfc6487bis-00.txt has been successfully submitted by Richard Hansen and posted to the IETF repository. Name: draft-rhansen-sidr-rfc6487bis Revision: 00 Title: A Profile for X.509 PKIX Resource Certificates Document date: 2015-03-09 Group: Individual Submission Pages: 32 URL: http://www.ietf.org/internet-drafts/draft-rhansen-sidr-rfc6487bis-00.txt Status: https://datatracker.ietf.org/doc/draft-rhansen-sidr-rfc6487bis/ Htmlized: http://tools.ietf.org/html/draft-rhansen-sidr-rfc6487bis-00 Abstract: This document defines a standard profile for X.509 certificates for the purpose of supporting validation of assertions of "right-of-use" of Internet Number Resources (INRs). The certificates issued under this profile are used to convey the issuer's authorization of the subject to be regarded as the current holder of a "right-of-use" of the INRs that are described in the certificate. This document contains the normative specification of Certificate and Certificate Revocation List (CRL) syntax in the Resource Public Key Infrastructure (RPKI). This document also specifies profiles for the format of certificate requests and specifies the Relying Party RPKI certificate path validation procedure. This document obsoletes RFC 6487. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat From nobody Mon Mar 9 22:39:04 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18B2D1A1B12 for ; Mon, 9 Mar 2015 22:39:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.711 X-Spam-Level: X-Spam-Status: No, score=-1.711 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_45=0.6, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n83jaukvCb7Y for ; Mon, 9 Mar 2015 22:39:01 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B58821A03E3 for ; Mon, 9 Mar 2015 22:39:00 -0700 (PDT) Received: from [128.89.253.161] (port=63843 helo=karen-seos-power-mac-g5.local) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1YVCsd-000OlU-94 for sidr@ietf.org; Tue, 10 Mar 2015 01:38:59 -0400 Message-ID: <54FE8373.6070902@bbn.com> Date: Tue, 10 Mar 2015 01:38:59 -0400 From: Karen Seo User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: sidr@ietf.org Content-Type: multipart/alternative; boundary="------------040404070506050707050700" Archived-At: Subject: [sidr] draft-ietf-sidr-lta-use-cases X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2015 05:39:03 -0000 This is a multi-part message in MIME format. --------------040404070506050707050700 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Randyet al., In hopes of restarting work on this draft, here is proposed text for section 4. This is an attempt to integrate the original text with the comments to the list submitted back in Feb 2014. My apologies if I've mis-understood the original draft text or the comments. Does this correctly and clearly describe the use cases? 4. Use Cases Case 1: Organization C finds that its CA certificate has been revoked (or modified to remove resources) by the RIR (or ISP) that issued it. Or, if C has outsourced its CA operations, C finds that one of its children's certificates has been revoked (or modified to remove resources).C disagrees with this action and would like relying parties to be able to ignore, at their discretion, the certificate revocation (or modification). The revocation or modification could be: * unintentional, i.e., due to an error by RIR (or ISP) staff * malicious, i.e., done with the intent to cause problems, which could be aimed at C or some other entity. * mandated by a law enforcement agency in the jurisdiction where the RIR (or ISP) operates For example, Carol, a RIPE resource holder (LIR, PI holder, ...), is a victim of the "Dutch Court Attack." Someone has convinced a Dutch court to forcethe RIPE/NCC to remove or modify some or all of Carol's certificates, ROAs, etc. or the resources they represent. However, the operational community wants to retain the ability to route to Carol's network(s). Case 2: Organization B makes use of private address space (RFC 1918) or address space allocated to another party but not globally announced by that party or by B. B wants its routers to be able to use RPKI data for both internal routing to these addresses and for global routing. Case 3: Organization A is authorized to control the routing of traffic from a set of organizations (within A's administrative control) to the rest of the Internet. A wants traffic from these organizations that is destined for a set of prefixes outside of A's administrative control to be routed to other addresses, or to be dropped. A accomplishes this by controlling the UPDATEs sent to those organizations. Because these organizations use the RPKI, A needs a way to coordinate their use of the RPKI in support of A’s traffic management goals. For example, Alice runs the network operations for a large consortium X. Her management requests that traffic (from X's members) that is destined for a competitor's site, be re-directed to a site approved by X. To do this,Alice has to ensure that the RPKI has the appropriate certificates, ROAs, etc. for those approved addresses as well as for the rest of the Internet. Thank you, Karen --------------040404070506050707050700 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Randy et al.,

In hopes of restarting work on this draft, here is proposed text for section 4. This is an attempt to integrate the original text with the comments to the list submitted back in Feb 2014.  My apologies if I've mis-understood the original draft text or the comments.  Does this correctly and clearly describe the use cases?

4.  Use Cases

Case 1:
Organization C finds that its CA certificate has been revoked (or modified to remove resources) by the RIR (or ISP) that issued it. Or, if C has outsourced its CA operations, C finds that one of its children's certificates has been revoked (or modified to remove resources). C disagrees with this action and would like relying parties to be able to ignore, at their discretion, the certificate revocation (or modification). The revocation or modification could be:
  • unintentional, i.e., due to an error by RIR (or ISP) staff
  • malicious, i.e., done with the intent to cause problems, which could be aimed at C or some other entity.
  • mandated by a law enforcement agency in the jurisdiction where the RIR (or ISP) operates
For example, Carol, a RIPE resource holder (LIR, PI holder, ...), is a victim of the "Dutch Court Attack." Someone has convinced a Dutch court to force the RIPE/NCC to remove or modify some or all of Carol's certificates, ROAs, etc. or the resources they represent. However, the operational community wants to retain the ability to route to Carol's network(s).

Case 2:
Organization B makes use of private address space (RFC 1918) or address space allocated to another party but not globally announced by that party or by B. B wants its routers to be able to use RPKI data for both internal routing to these addresses and for global routing.

Case 3:
Organization A is authorized to control the routing of traffic from a set of organizations (within A's administrative control) to the rest of the Internet. A wants traffic from these organizations that is destined for a set of prefixes outside of A's administrative control to be routed to other addresses, or to be dropped. A accomplishes this by controlling the UPDATEs sent to those organizations. Because these organizations use the RPKI, A needs a way to coordinate their use of the RPKI in support of A’s traffic management goals.

For example, Alice runs the network operations for a large consortium X. Her management requests that traffic (from X's members) that is destined for a competitor's site, be re-directed to a site approved by X. To do this, Alice has to ensure that the RPKI has the appropriate certificates, ROAs, etc. for those approved addresses as well as for the rest of the Internet.
Thank you,
Karen

 
 
 --------------040404070506050707050700-- From nobody Wed Mar 11 08:21:50 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C1D91A8857 for ; Wed, 11 Mar 2015 08:21:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W6BmWmKxoY6r for ; Wed, 11 Mar 2015 08:21:46 -0700 (PDT) Received: from koko.ripe.net (koko.ripe.net [IPv6:2001:67c:2e8:11::c100:1348]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BD6B31A010C for ; Wed, 11 Mar 2015 08:21:46 -0700 (PDT) Received: from titi.ripe.net ([193.0.23.11]) by koko.ripe.net with esmtps (UNKNOWN:AES256-GCM-SHA384:256) (Exim 4.72) (envelope-from ) id 1YViS5-00025t-Gz; Wed, 11 Mar 2015 16:21:42 +0100 Received: from gibbon.ripe.net ([193.0.1.206] helo=[0.0.0.0]) by titi.ripe.net with esmtp (Exim 4.72) (envelope-from ) id 1YViS5-0001Fx-Ci; Wed, 11 Mar 2015 16:21:41 +0100 Message-ID: <55005D85.40806@ripe.net> Date: Wed, 11 Mar 2015 16:21:41 +0100 From: Robert Kisteleki Organization: RIPE NCC User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Andrei Robachevsky , sidr@ietf.org References: <20141126164443.26069.29089.idtracker@ietfa.amsl.com> <54760513.2050709@innovationslab.net> <54F5E16D.9020002@bbn.com> <54F65293.3090405@gmail.com> In-Reply-To: <54F65293.3090405@gmail.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit 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: 72e00e6d7601fa19264e98abc238a27437883acea5fac18c95772ab11a8c6677 Archived-At: Subject: Re: [sidr] I-D Action: draft-ietf-sidr-rpsl-sig-06.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Mar 2015 15:21:48 -0000 On 2015-03-04 1:32, Andrei Robachevsky wrote: > Stephen Kent wrote on 03/03/15 17:29: >> I worry that accommodating multiple signatures will cause confusion for >> RPs. One would need to specify what to do if one sig fails, but other >> succeed, >> for example. > > I think the draft is clear about that, requiring all signatures to be > valid. And if we want to follow the RPSS/RFC2725 approach, then multiple > signatures are needed. > > But, it is not entirely clear to me why we need an "o" field and not > just multiple "signature:" attributes in cases when signing by several > parties is required. Indeed, that is why we're dropping it. The o= field was suggested a long time ago to make interdependent signatures. When thinking about the implementability of it, it became clear that it has a *lot* of added complexity, with not much benefit, if you compare to multiple, independent signatures (which only make real sense for route objects, I think). The draft already allows multiple signatures, therefore dropping the o= field is the simplest and most forward looking step. Cheers, Robert From nobody Thu Mar 12 09:38:24 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 924FF1A0174 for ; Thu, 12 Mar 2015 09:38:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.012 X-Spam-Level: X-Spam-Status: No, score=-0.012 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kVd3abzsKe8M for ; Thu, 12 Mar 2015 09:38:19 -0700 (PDT) Received: from walnut.tislabs.com (walnut.tislabs.com [192.94.214.200]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 610C01A016B for ; Thu, 12 Mar 2015 09:38:19 -0700 (PDT) Received: from nova.tislabs.com (unknown [10.66.1.77]) by walnut.tislabs.com (Postfix) with ESMTP id B6B9328B0017 for ; Thu, 12 Mar 2015 12:38:18 -0400 (EDT) Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1]) by nova.tislabs.com (Postfix) with ESMTP id 8E00A1F8035; Thu, 12 Mar 2015 12:38:18 -0400 (EDT) From: Sandra Murphy Content-Type: multipart/signed; boundary="Apple-Mail=_077FA46D-5335-4D26-BB71-8E47ABA59A55"; protocol="application/pgp-signature"; micalg=pgp-sha512 Date: Thu, 12 Mar 2015 12:38:24 -0400 Message-Id: To: "sidr@ietf.org list" Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) X-Mailer: Apple Mail (2.1510) Archived-At: Cc: Sandra Murphy Subject: [sidr] updated agenda posted X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Mar 2015 16:38:23 -0000 --Apple-Mail=_077FA46D-5335-4D26-BB71-8E47ABA59A55 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Two more discussions have been added to the agenda. The agenda is close to full now. In some cases, the estimate of = discussion time came from me. If the presenters could check and let = sidr-chairs know if they believe they need less or more time, that might = help if further requests come in. --Sandy, speaking as one of the wg co-chairs.=20 --Apple-Mail=_077FA46D-5335-4D26-BB71-8E47ABA59A55 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJVAcEAAAoJEHplpQeet0IZaNMP/1XID181P8/Qwc/UzB5V3PB6 JAyhNqYaYI2dru86WfizNVYqdEzV++Z7P2HL5iAcb03tEfTiYt5JumeBhdKgcsva d/Hfe0yK7LNNl0OUGsF2c7OieiJpAjHM3AMFpRWVH1ii3aI8xg7sIy+RpN7/lVIU RNp0mxhzgwL2LwCP1U8qTByhWbyI6yVnKdoeaEiUs7K1ngGx6ggTa+jObPu9vBCH UIzYAWDlrRDlS8szYtzllxASlaGKM3+d21Lk+LEAiuhtJjx7n6vLsvOTXWogQpMc VuYrF/2wgSlDetAn4eqGm3RXlk0BP6a/mmGOI9FhCt1kJDv6yNYc1ryflngObPFH yoluA1XjIDwUXMT88jf+Tc9BxSPZ3ASaELnlReM7gvW/INgpyxQn5Hvj2UkyIwol OTlYg4cW9RIBe5X/rzj8ao47WKFJSM4slN2ZeweCEiYl+H8UQOX+Hv6m4RaTKov+ esd2DQuSREDh0TCL/IpdfMswBd4A0ACWqUWCJtpzdCnA118tkaIHwVpWVm/Ab9V7 M7YtBM6G9PQRU0t8J6DEfsphZ8ERSWO7JNIibeQmOLxhfgSjDWpD+LMK2aOQWgYn qVxt4ty2B69uHyLwqCHjlfYWvYWsv+janjBIEn0itx/Vq8+R3bI5yVk1Ogyy4yMZ PjW0R69tS2dZWfRM3tRL =T0uz -----END PGP SIGNATURE----- --Apple-Mail=_077FA46D-5335-4D26-BB71-8E47ABA59A55-- From nobody Thu Mar 12 10:48:51 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5131A1A0062 for ; Thu, 12 Mar 2015 10:48:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JIBPidM-PUHZ for ; Thu, 12 Mar 2015 10:48:49 -0700 (PDT) Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5B9021A0040 for ; Thu, 12 Mar 2015 10:48:49 -0700 (PDT) Received: from clairseach.fuaim.com (clairseach-high.fuaim.com [206.197.161.158]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by uillean.fuaim.com (Postfix) with ESMTP id 42FBF8814B for ; Thu, 12 Mar 2015 10:48:49 -0700 (PDT) Received: from Brians-MacBook-Pro.local (unknown [76.21.129.88]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id 0EB0E13682DF for ; Thu, 12 Mar 2015 10:48:48 -0700 (PDT) Message-ID: <5501D17F.5040407@innovationslab.net> Date: Thu, 12 Mar 2015 13:48:47 -0400 From: Brian Haberman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: sidr@ietf.org References: <20141126164443.26069.29089.idtracker@ietfa.amsl.com> <54760513.2050709@innovationslab.net> <54F5E16D.9020002@bbn.com> <54F65293.3090405@gmail.com> <55005D85.40806@ripe.net> In-Reply-To: <55005D85.40806@ripe.net> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="s15TJMCJOb0k6JVQf9f4eHUTU65LSH9bW" Archived-At: Subject: Re: [sidr] I-D Action: draft-ietf-sidr-rpsl-sig-06.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Mar 2015 17:48:50 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --s15TJMCJOb0k6JVQf9f4eHUTU65LSH9bW Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable As an update... On 3/11/15 11:21 AM, Robert Kisteleki wrote: > On 2015-03-04 1:32, Andrei Robachevsky wrote: >> Stephen Kent wrote on 03/03/15 17:29: >>> I worry that accommodating multiple signatures will cause confusion f= or >>> RPs. One would need to specify what to do if one sig fails, but other= >>> succeed, >>> for example. >> >> I think the draft is clear about that, requiring all signatures to be >> valid. And if we want to follow the RPSS/RFC2725 approach, then multip= le >> signatures are needed. >> >> But, it is not entirely clear to me why we need an "o" field and not >> just multiple "signature:" attributes in cases when signing by several= >> parties is required. >=20 > Indeed, that is why we're dropping it. The o=3D field was suggested a l= ong > time ago to make interdependent signatures. When thinking about the > implementability of it, it became clear that it has a *lot* of added > complexity, with not much benefit, if you compare to multiple, independ= ent > signatures (which only make real sense for route objects, I think). >=20 > The draft already allows multiple signatures, therefore dropping the o=3D= > field is the simplest and most forward looking step. The above and a few other editorial changes will be made in an upcoming revision... Hopefully published when the draft submission blackout lifts.= Regards, Brian --s15TJMCJOb0k6JVQf9f4eHUTU65LSH9bW Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJVAdF/AAoJEBOZRqCi7goq7NgIAI2MbTf+SDrvry5+czRsGaiy 7c3d68DQyTPN0ui9jXmUTCI1peAhd5NFUm6Cx6bZJJQoL/2BOSjxMShFFweG09zs MJnbnZsQg92s54KKU5wcQZtg/8fiyxestZcLN3Q02GRZZZieqsalCuKv4Ox2xyF4 H2stSyY10f08OscHvL0E4v/qXUul73TyMLz+sW6lDxdnq69Cih2bI+2CLIM6L6X7 SoiY3YcHpFSA9TjS9kDoE7hyweH/fabOOSgYhKvGzG/lmtRT9TB+WONWiqmwm9nA HNwBv8dFtXIp7CR1yXWdNmXz/UUudec3uKa4LcN6UCJvhdUWaOAW1vHUAdxSDqo= =JikX -----END PGP SIGNATURE----- --s15TJMCJOb0k6JVQf9f4eHUTU65LSH9bW-- From nobody Mon Mar 16 08:35:47 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 819541A885F for ; Mon, 16 Mar 2015 08:35:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iKZWb2ex_cYz for ; Mon, 16 Mar 2015 08:35:45 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [198.180.150.18]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 398401A885D for ; Mon, 16 Mar 2015 08:35:45 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.82) (envelope-from ) id 1YXX3O-0008UW-I1 for sidr@ietf.org; Mon, 16 Mar 2015 15:35:42 +0000 Date: Mon, 16 Mar 2015 16:35:41 +0100 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.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Subject: [sidr] you gotta love as==0 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Mar 2015 15:35:46 -0000 go to http://rpki.me/quality.html#dl,RIPE,yellow,0,80.128.0.0/11,11 and click on the + to expand. make kinky corner features and you find yourself in twisty corners. it's correct in spec, but yuchhh. randy From nobody Mon Mar 16 08:41:13 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF2121A8757 for ; Mon, 16 Mar 2015 08:41:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01, WEIRD_PORT=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LOziF_L-Mfqn for ; Mon, 16 Mar 2015 08:41:11 -0700 (PDT) Received: from koko.ripe.net (koko.ripe.net [IPv6:2001:67c:2e8:11::c100:1348]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 40E0C1A1A91 for ; Mon, 16 Mar 2015 08:41:11 -0700 (PDT) Received: from titi.ripe.net ([193.0.23.11]) by koko.ripe.net with esmtps (UNKNOWN:AES256-GCM-SHA384:256) (Exim 4.72) (envelope-from ) id 1YXX8e-0003FC-T2; Mon, 16 Mar 2015 16:41:10 +0100 Received: from sslvpn.ipv6.ripe.net ([2001:67c:2e8:9::c100:14e6] helo=[IPv6:2001:67c:2e8:5009::f]) by titi.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1YXX8e-0004kp-Og; Mon, 16 Mar 2015 16:41:08 +0100 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Alex Band In-Reply-To: Date: Mon, 16 Mar 2015 16:41:08 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <0A704A81-E441-41A1-95B5-ECDAEE85B36B@ripe.net> References: To: Randy Bush X-Mailer: Apple Mail (2.2070.6) 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 0.0 WEIRD_PORT URI: Uses non-standard port number for HTTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-RIPE-Signature: ddd0bbf11d1e21354000f5f053f5ae69d71e48fcd4a672ac26f6abfd76ba06f9 Archived-At: Cc: sidr wg list Subject: Re: [sidr] you gotta love as==0 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Mar 2015 15:41:12 -0000 It's Deutsche Telekom who made it and by the looks of it, very = deliberately: http://localcert.ripe.net:8088/roas?q=3D80.128.0.0/11 http://localcert.ripe.net:8088/bgp-preview?q=3D80.128.0.0/11 = https://apps.db.ripe.net/search/lookup.html?source=3Dripe&key=3D80.128.0.0= %20-%2080.159.255.255&type=3Dinetnum Cheers, Alex > On 16 Mar 2015, at 16:35, Randy Bush wrote: >=20 > go to http://rpki.me/quality.html#dl,RIPE,yellow,0,80.128.0.0/11,11 = and > click on the + to expand. make kinky corner features and you find > yourself in twisty corners. it's correct in spec, but yuchhh. >=20 > randy >=20 > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr >=20 From nobody Mon Mar 16 10:07:27 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 390B71A88C7 for ; Mon, 16 Mar 2015 10:07:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.149 X-Spam-Level: X-Spam-Status: No, score=-1.149 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, J_CHICKENPOX_42=0.6, SPF_PASS=-0.001, WEIRD_PORT=0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 51sNMvnkdDWs for ; Mon, 16 Mar 2015 10:07:22 -0700 (PDT) Received: from mail-qg0-x232.google.com (mail-qg0-x232.google.com [IPv6:2607:f8b0:400d:c04::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB4721A878E for ; Mon, 16 Mar 2015 10:07:21 -0700 (PDT) Received: by qgg60 with SMTP id 60so45764278qgg.3 for ; Mon, 16 Mar 2015 10:07:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:reply-to:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=vz0sj6rh+4r90ys5cFTFKuvlA9STF3kniQ/Wvq08qFU=; b=BuPrz96Eg8JDkH8W3MhNslV2SfgmdY8vlSQpltMFLEW5yT6mK4gsHI61NmuSV8xkds n0lZ3Ldf1a6f2NenF9aM/G4T7QhIOA6IUhVl/Bll1J97zJIHaZ/mq1+wp2i91Z0OCW8X 7eV6XLFJcZRR4xiAZO7WeWuhV/MICUb9aDlHiIxJroKvxlWmGqdv62Xd/joX/8Ac0RO1 kcVa5pohnDzFM1DlT48yLLG+qbMnymoClKNR7mv5iWvh2uThlUNKtxKl+P5WvjBiwIHh VN+rktlFa4Dy0arhZDsFsnDGFFKq8+d8faKKhJ6isKx1DChfNNZfmegG0AB5/2Yg70iH i4Jg== X-Received: by 10.140.19.82 with SMTP id 76mr74741699qgg.19.1426525640720; Mon, 16 Mar 2015 10:07:20 -0700 (PDT) Received: from europa.local ([2001:13c7:7001:7000:ed76:3012:5307:9d21]) by mx.google.com with ESMTPSA id w130sm7788554qha.25.2015.03.16.10.07.18 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 16 Mar 2015 10:07:19 -0700 (PDT) Message-ID: <55070DC4.4030707@gmail.com> Date: Mon, 16 Mar 2015 14:07:16 -0300 From: "Carlos M. Martinez" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Alex Band , Randy Bush References: <0A704A81-E441-41A1-95B5-ECDAEE85B36B@ripe.net> In-Reply-To: <0A704A81-E441-41A1-95B5-ECDAEE85B36B@ripe.net> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Cc: sidr wg list Subject: Re: [sidr] you gotta love as==0 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: carlos@lacnic.net List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Mar 2015 17:07:27 -0000 Who operates rpki.me ? On 3/16/15 12:41 PM, Alex Band wrote: > It's Deutsche Telekom who made it and by the looks of it, very deliberately: > > http://localcert.ripe.net:8088/roas?q=80.128.0.0/11 > http://localcert.ripe.net:8088/bgp-preview?q=80.128.0.0/11 > > https://apps.db.ripe.net/search/lookup.html?source=ripe&key=80.128.0.0%20-%2080.159.255.255&type=inetnum > > Cheers, > > Alex > >> On 16 Mar 2015, at 16:35, Randy Bush wrote: >> >> go to http://rpki.me/quality.html#dl,RIPE,yellow,0,80.128.0.0/11,11 and >> click on the + to expand. make kinky corner features and you find >> yourself in twisty corners. it's correct in spec, but yuchhh. >> >> 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 > From nobody Mon Mar 16 10:11:07 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EAAB71A88C4 for ; Mon, 16 Mar 2015 10:11:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, J_CHICKENPOX_42=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q1UopBIALdkx for ; Mon, 16 Mar 2015 10:11:05 -0700 (PDT) Received: from mail-wi0-x22c.google.com (mail-wi0-x22c.google.com [IPv6:2a00:1450:400c:c05::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6AB371A878E for ; Mon, 16 Mar 2015 10:11:05 -0700 (PDT) Received: by wibg7 with SMTP id g7so43155681wib.1 for ; Mon, 16 Mar 2015 10:11:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=vr08xkSJfiHHMNVk4ianISMNBcbbrVAyslDkaBTUY2s=; b=RE1jxhFyi+Erb4Hc7OggDBlbZ9SODJWA8KKqR2k8TWawHQuJOn6WLSjQNqrZBFXpw3 PhIeDnIpq2DFBRE6nebwG/Yef3C5mNLPPERt08uFwTGiOhfAo2V4O0xZFWjRgDyRwBxr ir2O3HYo3hzUVTDMJrqzI0kmORa7ofS2L8Kz6DhwYP957YfCd4vpfbHYxIR8XBeEpEoy oiOOoFX8EQ62XLPsUWJ/Q1GmsMFceBbXvemW5+NieSjWCsqdAlnNBu5Sul7mm/8makXf EJKF1v2wqBa4bphSDL5Dp2vcKaNfrzZh8nJuRmRux4XvDC4PKpXX2UREkkTk29lcPC4d uZOw== X-Received: by 10.180.84.3 with SMTP id u3mr54400481wiy.38.1426525864170; Mon, 16 Mar 2015 10:11:04 -0700 (PDT) Received: from [192.168.1.148] (host86-175-71-123.range86-175.btcentralplus.com. [86.175.71.123]) by mx.google.com with ESMTPSA id vq9sm16243816wjc.6.2015.03.16.10.11.03 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 16 Mar 2015 10:11:03 -0700 (PDT) Message-ID: <55070EA7.9070101@gmail.com> Date: Mon, 16 Mar 2015 17:11:03 +0000 From: Daniele Iamartino User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: sidr@ietf.org References: <0A704A81-E441-41A1-95B5-ECDAEE85B36B@ripe.net> <55070DC4.4030707@gmail.com> In-Reply-To: <55070DC4.4030707@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [sidr] you gotta love as==0 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Mar 2015 17:11:07 -0000 On 16/03/2015 17:07, Carlos M. Martinez wrote: > Who operates rpki.me ? > me. part of my master thesis. BGP data is taken from LINX routeviews monitor and latest version of rpki repos validated with rcynic, in case you are wondering about that. -- Daniele Iamartino Student at Politecnico di Milano, Italy From nobody Mon Mar 16 10:11:15 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3E1D1A88F0 for ; Mon, 16 Mar 2015 10:11:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.31 X-Spam-Level: X-Spam-Status: No, score=-6.31 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_42=0.6, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MlnnXxDh8aoy for ; Mon, 16 Mar 2015 10:11:09 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [198.180.150.18]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 23D841A88EF for ; Mon, 16 Mar 2015 10:11:09 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.82) (envelope-from ) id 1YXYXh-0000dQ-Pk; Mon, 16 Mar 2015 17:11:06 +0000 Date: Mon, 16 Mar 2015 18:11:04 +0100 Message-ID: From: Randy Bush To: "Carlos M. Martinez" In-Reply-To: <55070DC4.4030707@gmail.com> References: <0A704A81-E441-41A1-95B5-ECDAEE85B36B@ripe.net> <55070DC4.4030707@gmail.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.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Cc: sidr wg list Subject: Re: [sidr] you gotta love as==0 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Mar 2015 17:11:13 -0000 > Who operates rpki.me ? Daniele Iamartino From nobody Mon Mar 16 10:44:13 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D053C1A8932 for ; Mon, 16 Mar 2015 10:44:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.311 X-Spam-Level: X-Spam-Status: No, score=-2.311 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aJXVFoLxYwkx for ; Mon, 16 Mar 2015 10:44:09 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 73C321A88FF for ; Mon, 16 Mar 2015 10:44:09 -0700 (PDT) Received: from ssh.bbn.com ([192.1.122.15]:35416 helo=COMSEC.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1YXZ3g-000EIg-0i for sidr@ietf.org; Mon, 16 Mar 2015 13:44:08 -0400 Message-ID: <55071667.7050000@bbn.com> Date: Mon, 16 Mar 2015 13:44:07 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: sidr Content-Type: multipart/alternative; boundary="------------010503070208090400090408" Archived-At: Subject: [sidr] comments on BGPsec rollover X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Mar 2015 17:44:12 -0000 This is a multi-part message in MIME format. --------------010503070208090400090408 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit The text needs a lot of work, i.e., odd English constructs are very common, and there are a number of typos, some of which I have noted below. I thought the current acronym is BGPsec. not BGPSEC. Also the document has too many instances of “could” and “would” where more normative statements ought to appear. I suggest the authors adopt (and clearly state) some of the assumptionsthey cite, then revise the document based on those assumptions. This I-D says it’s Standards Track, but it doesn’t read that way. Section 2: Comceptually -> conceptually Router certificate rollover is only superficially similar to key rollover a per RFC 6489; that process deals with CA certificates. Not EE certificates. “…routing information may be lost after the rollover process is finished.” How about “may be treated as unauthenticated …” the discussion of distribution of a stale BGPsec_Path attribute shoulddescribe this as part of an attack, explicitly. “The Security Requirements for BGP Path Validation [RFC7353] also describes the need for protection against a replay attack, …” What 7353 says is: 4.3Replay of BGP UPDATE messages need not be completely prevented, but a BGPsec design SHOULD provide a mechanism to control the window of exposure to replay attacks. I think the text in this document should be a bit closer to that in 7353. Section 3: propogated -> propagated correspondent -> corresponding certificate key may be compromised -> router private key … suchas EST-> such as EST BGP speaker that hold -> BGP speaker that holds This chose will -> This choice will The text refers to “New Certificate Pre-Publication” but it’s just publication of a certificate prior to beginning to make use of the corresponding private key. I suggest you remove the “pre” here. I think step 4 should describe the circumstances under which revocation is required or recommended. I’m a bit confused about step 5 here. Do we have a RTR withdrawal message? I would expect the normal process would be to issue an update with the new signatures an have it replace the current update that was signed under the old key. We have no way to ensure that this implicit withdrawal will propagate (in the context of a malicious router) but that’s why the revocation of the old certificate is needed. Section 4: mitigate mitigate -> mitigate If pre-provisioning done ahead of time … if it isn’t done “ahead of time”, it’s not pre-provisioning J! “ … if there have been no topology changes, then no security threat comes from a replay …” I think the vulnerability is even more narrowly constrained. Only if there are topology changes that make the route associated with the old BGPsec_Path attribute preferable to the route associated with the new one, right? “For a very small but critical fraction of the prefixes, the requirement may be in the order of hours.” This assertion needs to be explain with some examples or further explanatory text. I disagree with statement #2 in the Advantages text (page 10). I woud argue that many of the costs are borne by the RPs who have to fetch and validate the new router certificates and then provide the new keys and ASN information to their routers. I also disagree with item #4 under disadvantages. I think the increased burden on RPKI caches is analogous to the burden on repositories. --------------010503070208090400090408 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

The text needs a lot of work, i.e., odd English constructs are very common, and there are a number of typos, some of which I have noted below. I thought the current acronym is BGPsec. not BGPSEC. Also the document has too many instances of “could” and “would” where more normative statements ought to appear. I suggest the authors adopt (and clearly state) some of the assumptions they cite, then revise the document based on those assumptions. This I-D says it’s Standards Track, but it doesn’t read that way.

 

 

Section 2:

 

     Comceptually -> conceptually

 

Router certificate rollover is only superficially similar to key rollover a per RFC 6489; that process deals with CA certificates. Not EE certificates.

 

“…routing information may be lost after the rollover process is finished.” How about “may be treated as unauthenticated …”

 

the discussion of distribution of a stale BGPsec_Path attribute should  describe this as part of an attack, explicitly.

 

“The Security Requirements for BGP Path Validation [RFC7353] also

   describes the need for protection against a replay attack, …”

 

What 7353 says is:

 

4.3  Replay of BGP UPDATE messages need not be completely prevented, but a BGPsec design SHOULD provide a mechanism to control the window of exposure to replay attacks.

 

I think the text in this document should be a bit closer to that in 7353.

 

Section 3:

 

propogated -> propagated

 

correspondent -> corresponding

 

     certificate key may be compromised -> router private key …

 

     suchas EST-> such as EST

 

BGP speaker that hold -> BGP speaker that holds

 

This chose will -> This choice will

 

The text refers to “New Certificate Pre-Publication” but it’s just publication of a certificate prior to beginning to make use of the corresponding private key. I suggest you remove the “pre” here.

 

I think step 4 should describe the circumstances under which revocation is required or recommended.

 

I’m a bit confused about step 5 here. Do we have a RTR withdrawal message? I would expect the normal process would be to issue an update with the new signatures an have it replace the current update that was signed under the old key. We have no way to ensure that this implicit withdrawal will propagate (in the context of a malicious router) but that’s why the revocation of the old certificate is needed.

 

Section 4:

 

 

mitigate mitigate -> mitigate

 

If pre-provisioning done ahead of time …

if it isn’t done “ahead of time”, it’s not pre-provisioning J!

 

“ … if there have been no topology changes, then no security threat comes from a replay …” I think the vulnerability is even more narrowly constrained. Only if there are topology changes that make the route associated with the old BGPsec_Path attribute preferable to the route associated with the new one, right?

 

“For a very small but critical fraction of the prefixes, the requirement may be in the order of hours.” This assertion needs to be explain with some examples or further explanatory text.

 

I disagree with statement #2 in the Advantages text (page 10). I woud argue that many of the costs are borne by the RPs who have to fetch and validate the new router certificates and then provide the new keys and ASN information to their routers.

 

I also disagree with item #4 under disadvantages. I think the increased burden on RPKI caches is analogous to the burden on repositories.

--------------010503070208090400090408-- From nobody Mon Mar 16 12:05:02 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7CEB1A8ABD for ; Mon, 16 Mar 2015 12:04:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.15 X-Spam-Level: X-Spam-Status: No, score=-1.15 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, J_CHICKENPOX_42=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l2FXrrdI_uGa for ; Mon, 16 Mar 2015 12:04:54 -0700 (PDT) Received: from mail-qc0-x233.google.com (mail-qc0-x233.google.com [IPv6:2607:f8b0:400d:c01::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC4B91A8AB4 for ; Mon, 16 Mar 2015 12:04:54 -0700 (PDT) Received: by qcto4 with SMTP id o4so53020404qct.3 for ; Mon, 16 Mar 2015 12:04:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:reply-to:user-agent:mime-version:to:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=+qJqNX8142kmd+bnRYvB7kk8NP5ozcloFdn/wQcfzao=; b=gbsMPm7eoZz7ELS+PindGp7dIUXkDywhn32/RT92oYAKqw6hWi7xjP4GxRwoPqJI0N NIGcp0/M0QxzlKp6F1opUFONXVKy4Uvy2XVr2JvOKjOAEkSYoiOnjjOYWdd6zvE5qwqD MKWFNuSYVQ6Gy7evqDR7kfL0b3l9rBASjr7mxySyOkyJPd08pk3Fu3fWx3qNq5f5EuHz VFRUmy8+fZV+A6hQqZywWm0DU1Zqq3+sDJnYx90dClb231f2P9SmU57jsFYpPblbQfWa oDiEIU/14M40+iBSTBAt9cGQq33KBrIAeNYipA7f5yLd6KZ11Y83r2zP0QqulMdy9EY+ QUhQ== X-Received: by 10.55.48.21 with SMTP id w21mr47705973qkw.13.1426532693964; Mon, 16 Mar 2015 12:04:53 -0700 (PDT) Received: from europa.local ([2001:13c7:7001:7000:ed76:3012:5307:9d21]) by mx.google.com with ESMTPSA id 8sm8054332qgk.33.2015.03.16.12.04.51 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 16 Mar 2015 12:04:52 -0700 (PDT) Message-ID: <55072950.7040307@gmail.com> Date: Mon, 16 Mar 2015 16:04:48 -0300 From: "Carlos M. Martinez" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Daniele Iamartino , sidr@ietf.org References: <0A704A81-E441-41A1-95B5-ECDAEE85B36B@ripe.net> <55070DC4.4030707@gmail.com> <55070EA7.9070101@gmail.com> In-Reply-To: <55070EA7.9070101@gmail.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [sidr] you gotta love as==0 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: carlos@lacnic.net List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Mar 2015 19:04:55 -0000 Indeed I was, thanks! On 3/16/15 2:11 PM, Daniele Iamartino wrote: > On 16/03/2015 17:07, Carlos M. Martinez wrote: >> Who operates rpki.me ? >> > me. part of my master thesis. BGP data is taken from LINX routeviews > monitor and latest version of rpki repos validated with rcynic, in case > you are wondering about that. > > From nobody Mon Mar 16 13:01:37 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0A991A9071 for ; Mon, 16 Mar 2015 13:01:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r8SME4mSiMuB for ; Mon, 16 Mar 2015 13:01:34 -0700 (PDT) Received: from mail-we0-f174.google.com (mail-we0-f174.google.com [74.125.82.174]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7F0941A9064 for ; Mon, 16 Mar 2015 13:01:34 -0700 (PDT) Received: by weop45 with SMTP id p45so20878783weo.0 for ; Mon, 16 Mar 2015 13:01:33 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=ngBJsJwwlkZ8WgpJR0H7pOaWijO/M67oky7TprOJw4M=; b=mrH9twFiK/RHPmbsZzofCT38roeW22BaBIY6fXqRWCb4jIUarPqE5c36srASPttPl1 tTt2EKrlg94A0Up7PFWWajBRrslRNHSNN0pJneAytzN25li0w5CIDSB1lxWxEqkHsIXI szaQWwB9s67pRHyuGp0m9ZuyjxPCphMPhcdA6r6+0UrZxC30ONhEB5GwxLJeNVkjv42m ebg3eAu4fYwmIsp2jH1kbkmy4XSo4uvOyJfJlzd+I83tGArAhZE9iyRoTHuuBuIQ4nkC 9XBeYsadUJMVoJjQX4Oa4/ovnWybiOEPu2UnDoNJGbrypELyZ/qnrsHbPBFPWvdC06Wq ULqg== X-Gm-Message-State: ALoCoQlutiMFUuTyGOyIgXrvdvfnc9PvG9+PhzVy1kkjC5K/MaTtmVrHwt9mk3ITjqdvXANsTbNo MIME-Version: 1.0 X-Received: by 10.180.77.110 with SMTP id r14mr102741643wiw.89.1426536092986; Mon, 16 Mar 2015 13:01:32 -0700 (PDT) Received: by 10.194.110.97 with HTTP; Mon, 16 Mar 2015 13:01:32 -0700 (PDT) In-Reply-To: References: Date: Mon, 16 Mar 2015 21:01:32 +0100 Message-ID: From: Warren Kumari To: Randy Bush Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: sidr wg list Subject: Re: [sidr] you gotta love as==0 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Mar 2015 20:01:37 -0000 Huh. I don't really understand what DT is trying to say here -- 80.128.0.0/11 can be announced from 3320, but shouldn't be used? Rudiger? W On Mon, Mar 16, 2015 at 4:35 PM, Randy Bush wrote: > go to http://rpki.me/quality.html#dl,RIPE,yellow,0,80.128.0.0/11,11 and > click on the + to expand. make kinky corner features and you find > yourself in twisty corners. it's correct in spec, but yuchhh. > > randy > > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf From nobody Mon Mar 16 13:30:09 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 285CC1A90CC for ; Mon, 16 Mar 2015 13:30:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 918kWC4qDGKX for ; Mon, 16 Mar 2015 13:30:06 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0124.outbound.protection.outlook.com [65.55.169.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7BEB81A90CE for ; Mon, 16 Mar 2015 13:30:02 -0700 (PDT) Received: from BN1PR09MB011.namprd09.prod.outlook.com (10.255.201.147) by BN1PR09MB012.namprd09.prod.outlook.com (10.255.201.148) with Microsoft SMTP Server (TLS) id 15.1.118.15; Mon, 16 Mar 2015 20:30:00 +0000 Received: from BN1PR09MB011.namprd09.prod.outlook.com ([169.254.2.152]) by BN1PR09MB011.namprd09.prod.outlook.com ([169.254.2.152]) with mapi id 15.01.0118.009; Mon, 16 Mar 2015 20:30:00 +0000 From: "Montgomery, Douglas" To: Warren Kumari , Randy Bush Thread-Topic: [sidr] you gotta love as==0 Thread-Index: AQHQX/7kf7hGmJQYr0iSd7Gjb41L7Z0fiAEA///E3AA= Importance: low X-Priority: 5 Date: Mon, 16 Mar 2015 20:30:00 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.8.150116 x-originating-ip: [129.6.140.29] authentication-results: kumari.net; dkim=none (message not signed) header.d=none; x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN1PR09MB012; x-forefront-antispam-report: BMV:1; SFV:NSPM; SFS:(10019020)(6009001)(377454003)(479174004)(24454002)(51704005)(83506001)(102836002)(15975445007)(77156002)(19580395003)(86362001)(2656002)(19580405001)(54356999)(92566002)(76176999)(62966003)(40100003)(122556002)(87936001)(81686999)(46102003)(50986999)(66066001)(99286002)(106116001)(15395725005)(2950100001)(2900100001)(36756003)(15198665003); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1PR09MB012; H:BN1PR09MB011.namprd09.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5002010)(5005006); SRVR:BN1PR09MB012; BCL:0; PCL:0; RULEID:; SRVR:BN1PR09MB012; x-forefront-prvs: 05177D47DC Content-Type: text/plain; charset="utf-8" Content-ID: <1F94B20D95ED434F9369F86797C9A4CC@namprd09.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Mar 2015 20:30:00.0756 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN1PR09MB012 Archived-At: Cc: sidr wg list Subject: Re: [sidr] you gotta love as==0 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Mar 2015 20:30:08 -0000 SSBob3BlIHRoYXQgaXNu4oCZdCB3aGF0IERUIGlzIHRyeWluZyB0byBzYXksIGJlY2F1c2Ugb3Jp Z2luIHZhbGlkYXRpb24NCmRvZXNu4oCZdCB3b3JrIGxpa2UgdGhhdC4NCg0KU29tZXRoaW5nIG9m IGEg4oCcYmFja3N0b3DigJ0gUk9BPyAgSWYgdGhlIFJPQSBmb3IgdGhlIHJlYWwgb3JpZ2luIHNo b3VsZA0KZGlzYXBwZWFyLCBhY2NlcHQgbm8gYWx0ZXJuYXRpdmVzPz8/DQoNCkFsc28gaW50ZXJl c3RpbmcgYXJlIHRoZSAvMTMtMTMgYW5kIC8xMS0xMSBST0FzIGZvciB0aGUgc2FtZSBQL08gcGFp ci4NCg0KTWF5YmUgdGhpcyBpcyBhIG5ldyBwYXJ0eSBnYW1lIC0gZ3Vlc3MgdGhlIHJvdXRpbmcg cG9saWN5IGdpdmVuIGEgc2V0IG9mDQpST0FzLg0KDQpkb3VnbQ0K4oCUIA0KRG91ZyBNb250Z29t ZXJ5LCBNZ3IgSW50ZXJuZXQgJiBTY2FsYWJsZSBTeXN0ZW1zIFJlc2VhcmNoIGF0ICBOSVNUL0lU TC9BTlREDQoNCg0KDQoNCg0KT24gMy8xNi8xNSwgNDowMSBQTSwgIldhcnJlbiBLdW1hcmkiIDx3 YXJyZW5Aa3VtYXJpLm5ldD4gd3JvdGU6DQoNCj5IdWguIEkgZG9uJ3QgcmVhbGx5IHVuZGVyc3Rh bmQgd2hhdCBEVCBpcyB0cnlpbmcgdG8gc2F5IGhlcmUgLS0NCj44MC4xMjguMC4wLzExIGNhbiBi ZSBhbm5vdW5jZWQgZnJvbSAzMzIwLCBidXQgc2hvdWxkbid0IGJlIHVzZWQ/DQo+DQo+UnVkaWdl cj8NCj4NCj5XDQo+DQo+T24gTW9uLCBNYXIgMTYsIDIwMTUgYXQgNDozNSBQTSwgUmFuZHkgQnVz aCA8cmFuZHlAcHNnLmNvbT4gd3JvdGU6DQo+PiBnbyB0byBodHRwOi8vcnBraS5tZS9xdWFsaXR5 Lmh0bWwjZGwsUklQRSx5ZWxsb3csMCw4MC4xMjguMC4wLzExLDExIGFuZA0KPj4gY2xpY2sgb24g dGhlICsgdG8gZXhwYW5kLiAgbWFrZSBraW5reSBjb3JuZXIgZmVhdHVyZXMgYW5kIHlvdSBmaW5k DQo+PiB5b3Vyc2VsZiBpbiB0d2lzdHkgY29ybmVycy4gIGl0J3MgY29ycmVjdCBpbiBzcGVjLCBi dXQgeXVjaGhoLg0KPj4NCj4+IHJhbmR5DQo+Pg0KPj4gX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCj4+IHNpZHIgbWFpbGluZyBsaXN0DQo+PiBzaWRyQGll dGYub3JnDQo+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NpZHINCj4N Cj4NCj4NCj4tLSANCj5JIGRvbid0IHRoaW5rIHRoZSBleGVjdXRpb24gaXMgcmVsZXZhbnQgd2hl biBpdCB3YXMgb2J2aW91c2x5IGEgYmFkDQo+aWRlYSBpbiB0aGUgZmlyc3QgcGxhY2UuDQo+VGhp cyBpcyBsaWtlIHB1dHRpbmcgcmFiaWQgd2Vhc2VscyBpbiB5b3VyIHBhbnRzLCBhbmQgbGF0ZXIg ZXhwcmVzc2luZw0KPnJlZ3JldCBhdCBoYXZpbmcgY2hvc2VuIHRob3NlIHBhcnRpY3VsYXIgcmFi aWQgd2Vhc2VscyBhbmQgdGhhdCBwYWlyDQo+b2YgcGFudHMuDQo+ICAgLS0tbWFmDQo+DQo+X19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj5zaWRyIG1haWxp bmcgbGlzdA0KPnNpZHJAaWV0Zi5vcmcNCj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL3NpZHINCg0K From nobody Mon Mar 16 21:46:30 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73CD41A0064 for ; Mon, 16 Mar 2015 21:46:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S7Ov0_IROH-q for ; Mon, 16 Mar 2015 21:46:26 -0700 (PDT) Received: from nm22-vm6.access.bullet.mail.bf1.yahoo.com (nm22-vm6.access.bullet.mail.bf1.yahoo.com [216.109.115.149]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8C6571A0062 for ; Mon, 16 Mar 2015 21:46:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1426567585; bh=TThjZVcSzuj5ARZMIOUaCLYjzPo3EdPzj4O3REXZm2M=; h=Date:From:To:Subject:In-Reply-To:References:From:Subject; b=SSxWqdJI34dMXnzbv/AXr1uHh0nTfnRvNC4Mo9aAPedjZlMaRs/xjLIxKddFxbPSkoIL76fRMOrGGwI8XU6IlIrHOtx2O3ubqAJacx3y8xna2O+ZAnxb/EMFmFpJDZP5zTQOYqHUvI3kjfg5+bUoAMbfmsXHuSowlsY3VfXkhrBjRftv5wfrKP6ZF/g/KZUNjEnbSXBKaD6xO3jOPFybOXGh5gUsziHnC4VSFzgiEdJvdd6H3qGdjSNpJQX40C1RpoB2DCZPQMHufhXtb3973z3qhjoFUaTRDLcLaW+S93sEl2Sz/9VNUKxeidmWxQGpQyBlJ0rDUqajzPLdVM9tzg== Received: from [66.196.81.157] by nm22.access.bullet.mail.bf1.yahoo.com with NNFMP; 17 Mar 2015 04:46:25 -0000 Received: from [98.138.104.99] by tm3.access.bullet.mail.bf1.yahoo.com with NNFMP; 17 Mar 2015 04:46:25 -0000 Received: from [127.0.0.1] by smtp119.sbc.mail.ne1.yahoo.com with NNFMP; 17 Mar 2015 04:46:25 -0000 X-Yahoo-Newman-Id: 652186.68859.bm@smtp119.sbc.mail.ne1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: pzAHGz8VM1luCNN..zpxKmGnpMQD12dEiJNZaNvDcpZ0fGA QGEzqD9csy0O2ToE5MqjQHQ183thpnaAkmqVJbWt9ZNTImzDnMR45NyqjP5Q 4wmfuiOPJ.xtFvrawidnl_r9tgUonoRwOvwAKJo4CEre1QdHGu3vEk86ZaVD 3vcils59AAJ8gUtvF_77gvID0L3dZJiTYNSx5FwHH3V3o4LDuJfQ8w4ZctmH 3BCCl.t1qRV0ucpyTG_jUDmRyxSzTAguqwkQZt7l.x8mUTUFffyiH5CwF.r8 0j3mrVkIx4uogr2EMoWjHjQJNRb9xl0B5Pf5uELDoWUqM.bGhZ6fELx8vxj8 Nbv68wpjaedQAfTEJAFgs_SCUFzWF3lgqC9C9l5CU5R6vBcstyQc.TDuSlFf hX0Jn7IHSaziYIjUHCITlFORJ0xNNYjIs1Ut_v4F_nU.v5R98GkXgJcOUvp9 ABYc6RKPOH5ZYWOd8sJtBHYpVDN3x.O9UBsce7llJTcVOQOARiQ2iFMNNQ69 wb6VVISVC7IOyk372wWgMJ0BujKjEGlYQc35PRPRJ2nScREiSmNzZqYPLU4N 9X1M0fvnxC3JOsUAP5CR5P8bU7ipuvnBrrtayvA8017OdfMS40w-- X-Yahoo-SMTP: 4kJJK.qswBDPuwyc5wW.BPAQqNXdy5j09UNyeAS0pyOQ708- Received: from secure.mandelberg.org (c-76-24-31-176.hsd1.ma.comcast.net [76.24.31.176]) by uriel.mandelberg.org (Postfix) with ESMTPSA id 1CFE71C6058 for ; Tue, 17 Mar 2015 00:46:24 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Date: Tue, 17 Mar 2015 00:46:23 -0400 From: David Mandelberg To: In-Reply-To: References: Message-ID: <729d38908098b3cb55910eaf98fb346a@mail.mandelberg.org> X-Sender: david@mandelberg.org User-Agent: Roundcube Webmail/0.7.2 Archived-At: Subject: Re: [sidr] WGLC for draft-ietf-sidr-rpki-rtr-rfc6810-bis-03 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Mar 2015 04:46:28 -0000 On 2015-03-06 05:22, Sandra Murphy wrote: > Please comment to the list whether you believe that this draft is > ready for publication. I reviewed this draft. My substantive comments are below, and I'll send nits to the authors. Other than the below and the comment that Tim B sent to the list, I think the draft is ready for publication. (Note that while I have written a cache implementation of version 0 of this protocol, I have not yet written an implementation of version 1.) Section 5 says "Fields with unspecified content MUST be zero on transmission and MAY be ignored on receipt" and Section 5.1 says "Fields shown as zero or reserved MUST be zero. The value of such a field MUST be ignored on receipt." Are there three separate things (unspecified, zero, and reserved) to which these different rules apply? Or are these all the same thing, and the MAY in the first quote conflicts with the second MUST in the second quote? The Router Key PDU (section 5.10) uses a fixed-size field for the SKI. What's the plan for algorithm agility, if the size of the SKI changes? if the size of the SKI does not change, but the algorithm does? Section 7 adds the requirement that "A router MUST start each transport session by issuing either a Reset Query or a Serial Query." However, I don't see an additional requirement that the cache can't start sending PDUs (e.g., a Serial Notify) before it receives a Query from the router. Maybe there should be? Our current (version 0) implementation sends a Serial Notify whenever there is a new serial number, even if the router has not yet made any queries. If a version 1 router connects to our version 0 cache and we somehow manage to send a Serial Notify before the router is able to send a Query, what should the router do? Likewise, what should the router do if it receives any version 1 PDU before it has sent a Query? What happens if version 1 is successfully negotiated, but a later PDU is sent (in either direction) with its version set to 0? Should the receiving side send an Error Report and disconnect? Likewise, what happens if version 0 is successfully negotiated, but a later PDU has a version of 1? Should the receiving side send an Error Report and disconnect? Even if the version 1 PDU is a Query (router to cache) and the cache supports version 1? I have no issue with disallowing re-negotiation of the protocol version, but I think it should be clearly specified that negotiation happens only at the beginning of a transport session. -- David Eric Mandelberg / dseomn http://david.mandelberg.org/ From nobody Tue Mar 17 01:07:26 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 964951A00F6 for ; Tue, 17 Mar 2015 01:07:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7UAxOelFJRzk for ; Tue, 17 Mar 2015 01:07:15 -0700 (PDT) Received: from walnut.tislabs.com (walnut.tislabs.com [192.94.214.200]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6F3E81A00F5 for ; Tue, 17 Mar 2015 01:07:15 -0700 (PDT) Received: from nova.tislabs.com (unknown [10.66.1.77]) by walnut.tislabs.com (Postfix) with ESMTP id EA23A28B003D for ; Tue, 17 Mar 2015 04:07:13 -0400 (EDT) Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1]) by nova.tislabs.com (Postfix) with ESMTP id A043A1F8035; Tue, 17 Mar 2015 04:07:13 -0400 (EDT) Content-Type: multipart/signed; boundary="Apple-Mail=_6DB8E8D5-3983-4770-AAAC-B46A2A4EDC6A"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Sandra Murphy In-Reply-To: Date: Tue, 17 Mar 2015 04:07:15 -0400 Message-Id: <9D70CAEF-22F9-44FC-A429-9CBEBA9EAE6C@tislabs.com> References: To: "sidr@ietf.org list" X-Mailer: Apple Mail (2.1510) Archived-At: Cc: Sandra Murphy Subject: Re: [sidr] WGLC for draft-ietf-sidr-rpki-rtr-rfc6810-bis-03 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Mar 2015 08:07:19 -0000 --Apple-Mail=_6DB8E8D5-3983-4770-AAAC-B46A2A4EDC6A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii A reminder to everyone that this wglc ends Mar 20. There have been a couple of detailed responses. There should be more, = in order to judge consensus to publish. --Sandy, speaking as one of the wg co-chairs and chief nag On Mar 6, 2015, at 4:22 AM, Sandra Murphy wrote: > The authors of The Resource Public Key Infrastructure (RPKI) to = Router Protocol believe that the work is ready for a working grow last = call. >=20 > This starts a last call for that draft. You may find it at = https://tools.ietf.org/html/draft-ietf-sidr-rpki-rtr-rfc6810-bis-03. >=20 > Please comment to the list whether you believe that this draft is = ready for publication. The wglc will be two weeks, ending on Friday, = March 20. >=20 > --Sandy, speaking as one of the wg co-chairs --Apple-Mail=_6DB8E8D5-3983-4770-AAAC-B46A2A4EDC6A Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJVB+C0AAoJEHplpQeet0IZeYwP/Rsu2X9mbBay/ii5eTY1mpdx T/AANm6vYCZHlG+3o4X7ZrpMwqFhTS5t32y14qtP/4lyNGEJ99e7tJYyzPrucueR ZLDFawsgwnFZhMmVpitXHYR7UOaunQU3jkz2wUiydTXBxw4L/YnC9U38lv5YxztK Pyk610YfQDmq258gS/PW0+K1wkEoI0pMUGS4L1MqGNqwDh0T3Ueguw89CYlT0orJ SuN3kV9C0FXGtZoRcaO0VQoPkzSXVC8WGo4Ba37UCDLZimqejGwDDddjwJRvSwsn WbvvDBNhhTJwFiyb5pwZwLz5U+qF7ykEpdLYYHEg5VWNJsegKZp/ckFj+irTA+y7 mTrEOjGXfrvxoyRs523N8R5Itzk5H7+pCdB4YF4XngwpXKLpTl4u5D9X5heYbMCS eiF+cxljrmvOnXQDXRqt29FrCXVYVKg63Mz9ejDnhkJuwyqUjg7hS0vHbhMuOCn0 jiEOPtYk+c3afnQEm4N6jqkBd67GKce38xF0QS/c/u3xDUKiJocRT32e5F92yd10 oLyjkYmNC3Do6Gryz6gkU9LYbxQUQAhchGxIRclO8+VIYF3x6XkPbBIqE9l3364m HdNs6Mw17krqcbs+Woi3PJvhrGTSdQTIf4pC0pagGegjY82AbAGw7wMOIiOwSw7K TFSAmXoFU5wUi55goMY5 =JNkq -----END PGP SIGNATURE----- --Apple-Mail=_6DB8E8D5-3983-4770-AAAC-B46A2A4EDC6A-- From nobody Tue Mar 17 11:29:41 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C2221A871B for ; Tue, 17 Mar 2015 11:29:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.475 X-Spam-Level: X-Spam-Status: No, score=-0.475 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 56kMTYOxJ-Lr for ; Tue, 17 Mar 2015 11:29:36 -0700 (PDT) Received: from cdpipgw01.twcable.com (cdpipgw01.twcable.com [165.237.59.22]) by ietfa.amsl.com (Postfix) with ESMTP id 5E1C31A1B86 for ; Tue, 17 Mar 2015 11:29:35 -0700 (PDT) X-SENDER-IP: 10.136.163.13 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="5.11,417,1422939600"; d="scan'208";a="842296252" Received: from unknown (HELO PRVPEXHUB04.corp.twcable.com) ([10.136.163.13]) by cdpipgw01.twcable.com with ESMTP/TLS/RC4-MD5; 17 Mar 2015 14:17:08 -0400 Received: from PRVPEXVS10.corp.twcable.com ([10.136.163.41]) by PRVPEXHUB04.corp.twcable.com ([10.136.163.13]) with mapi; Tue, 17 Mar 2015 14:29:34 -0400 From: "George, Wes" To: Sandra Murphy , "sidr@ietf.org list" Date: Tue, 17 Mar 2015 14:29:34 -0400 Thread-Topic: [sidr] WGLC for draft-ietf-sidr-rpki-rtr-rfc6810-bis-03 Thread-Index: AdBg4FEiat4Q4CL8RTulGagAz3odAg== Message-ID: References: <9D70CAEF-22F9-44FC-A429-9CBEBA9EAE6C@tislabs.com> In-Reply-To: <9D70CAEF-22F9-44FC-A429-9CBEBA9EAE6C@tislabs.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.8.150116 acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [sidr] WGLC for draft-ietf-sidr-rpki-rtr-rfc6810-bis-03 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Mar 2015 18:29:38 -0000 bml0Og0KSWYgdGhpcyBpcyA2ODEwYmlzLCBzaG91bGRuJ3QgaXQgZm9ybWFsbHkgbGlzdCA2ODEw IGluIHRoZQ0KdXBkYXRlcy9vYnNvbGV0ZXMgbWV0YWRhdGE/DQoNCk90aGVyIGNvbW1lbnRzOg0K U2VjdGlvbiA2IEV4cGlyZSBpbnRlcnZhbCAtIHRoaXMgc2VlbXMgb3V0IG9mIHN0ZXAgd2l0aCB0 aGUgd2F5IHRoYXQgd2UndmUNCmRvbmUgbW9zdCB0aGluZ3MgaW4gUlBLSSwgaS5lLiB3aGF0IHRv IGRvIHdpdGggdGhlIGluZm9ybWF0aW9uIHByb3ZpZGVkIGlzDQp1c3VhbGx5IHRob3VnaHQgb2Yg YXMgYSBtYXR0ZXIgb2YgbG9jYWwgcG9saWN5LiBJIHJlYWxpemUgdGhhdCB0aGVyZSBpcw0KaW5j cmVhc2luZyByaXNrIHRvIGtlZXBpbmcgdGhlIGRhdGEgYmV5b25kIHRoZSBleHBpcnkgdGltZSBh cyBpdCBncm93cw0KbW9yZSBzdGFsZSwgYnV0IHRoZXJlIGlzbid0IG11Y2gganVzdGlmaWNhdGlv biBmb3Igd2h5IHRoaXMgTVVTVCBOT1QgaXMNCnByZXNlbnQuIEkgdGhpbmsgdGhhdCBwZXJoYXBz IHRoZSB0cmFkZW9mZiBiZXR3ZWVuIHN0YWxlbmVzcyBhbmQNCmV2ZXJ5dGhpbmcgZmFpbGluZyBi YWNrIHRvIHVua25vd24gc3RhdHVzIGlzIHNvbWV0aGluZyB0aGF0IHRoZSBvcGVyYXRvcg0KbmVl ZHMgdG8gd2VpZ2ggdGhlbXNlbHZlcy4gV2UgY291bGQgcHJvdmlkZSBndWlkYW5jZSB0aGF0IFtN VVNUL1NIT1VMRF0NCk5PVCBrZWVwIGRhdGEgZnJvbSBhIGNlcnRhaW4gY2FjaGUgYmV5b25kIGV4 cGlyeSB0aW1lICppZiogYW5vdGhlciBjYWNoZQ0KaXMgYXZhaWxhYmxlLCBidXQgYWNrbm93bGVk Z2UgdGhhdCBpbiBzb21lIGNhc2VzIHN0YWxlIGluZm8gbWF5IGJlIG1vcmUNCmRlc2lyYWJsZSB0 aGFuIG5vdGhpbmcgYXQgYWxsICh1bmxlc3MgdGhhdCdzIG5vdCBhY3R1YWxseSB0cnVlIGFuZCBJ J20NCm1pc3Npbmcgc29tZXRoaW5nLi4uKSBUaGlzIGlzIGRpc2N1c3NlZCBpbiB0aGUgZmFpbG92 ZXIgc2NlbmFyaW9zIGluIHRoZQ0KYm90dG9tIG9mIHNlY3Rpb24gMTAgKG9ubHkga2VlcCBkYXRh IGlmIHlvdSBkb24ndCBoYXZlIGEgZnVsbCBzZXQgZnJvbQ0KYW5vdGhlciBjYWNoZSkgYnV0IGZp Z3VyZWQgSSdkIG1lbnRpb24gaXQgaW4gY2FzZSB3ZSB0aGluayB0aGVyZSdzIHNvbWUNCnR3ZWFr cyBuZWNlc3NhcnkgaW4gdGhlIHNlY3Rpb24gNiB0ZXh0Lg0KDQpBbHNvIC0NClNpbmNlIHdlIHNh eSBpbiBzZWN0aW9uIDEwIHRoYXQgaXQgaXMgcGVybWlzc2libGUgdG8gaG9sZCBkYXRhIGZyb20N Cm11bHRpcGxlIGNhY2hlcywgdGhlIGRvYyBhcHBlYXJzIHRvIGJlIG1pc3NpbmcgZ3VpZGFuY2Ug b24gd2hhdCB0aGUgcm91dGVyDQpzaWRlIG9mIFJQS0ktcm91dGVyIHNob3VsZCBkbyBpbiB0aGUg Y2FzZSB3aGVyZSB0aGVyZSBhcmUgbXVsdGlwbGUgY2FjaGVzDQp0aGF0IGRpc2FncmVlIHdpdGgg b25lIGFub3RoZXIuIEl0IGRvZXMgc2F5IE1VU1QgTk9UIGRpc3Rpbmd1aXNoIGJldHdlZW4NCmRh dGEgc291cmNlcyB3aGVuIHZhbGlkYXRpbmcsIGJ1dCB0aGF0IG1heSBub3QgY292ZXIgdGhpcyBz Y2VuYXJpby4gVGhpcw0KbWF5IGJlIGFzIHNpbXBsZSBhcyByZWNvbW1lbmRpbmcgdGhhdCBpbiB0 aGUgY2FzZSB3aGVyZSBkYXRhIGZyb20gbXVsdGlwbGUNCmNhY2hlcyBpcyBoZWxkIGFuZCBzcGVj aWZpYyBlbnRyaWVzIGNvbmZsaWN0IHdpdGggb25lIGFub3RoZXIsIHRoZXJlDQpTSE9VTEQgYmUg YW4gb2RkIG51bWJlciBvZiBjYWNoZXMgc28gdGhhdCB0aGVyZSBpcyBiYXNpcyBmb3IgY29tcGFy aXNvbiB0bw0KZGV0ZXJtaW5lIHdoaWNoIGNhY2hlIGlzIG91dCBvZiBzeW5jIG9yIHByb3ZpZGlu ZyBpbmNvcnJlY3QgaW5mby4gKGkuZS4NCkhhdmUgMyBzbyB0aGF0IHlvdSBjYW4gZ28gd2l0aCB0 aGUgMi8zIHRoYXQgYWdyZWUpDQoNClRoYW5rcywNCg0KV2VzDQoNCg0KT24gMy8xNy8xNSwgNDow NyBBTSwgIlNhbmRyYSBNdXJwaHkiIDxzYW5keUB0aXNsYWJzLmNvbT4gd3JvdGU6DQoNCj5BIHJl bWluZGVyIHRvIGV2ZXJ5b25lIHRoYXQgdGhpcyB3Z2xjIGVuZHMgTWFyIDIwLg0KPg0KPlRoZXJl IGhhdmUgYmVlbiBhIGNvdXBsZSBvZiBkZXRhaWxlZCByZXNwb25zZXMuICBUaGVyZSBzaG91bGQg YmUgbW9yZSwgaW4NCj5vcmRlciB0byBqdWRnZSBjb25zZW5zdXMgdG8gcHVibGlzaC4NCj4NCj4t LVNhbmR5LCBzcGVha2luZyBhcyBvbmUgb2YgdGhlIHdnIGNvLWNoYWlycyBhbmQgY2hpZWYgbmFn DQo+DQo+T24gTWFyIDYsIDIwMTUsIGF0IDQ6MjIgQU0sIFNhbmRyYSBNdXJwaHkgPHNhbmR5QHRp c2xhYnMuY29tPiB3cm90ZToNCj4NCj4+IFRoZSBhdXRob3JzIG9mICBUaGUgUmVzb3VyY2UgUHVi bGljIEtleSBJbmZyYXN0cnVjdHVyZSAoUlBLSSkgdG8gUm91dGVyDQo+PlByb3RvY29sIGJlbGll dmUgdGhhdCB0aGUgd29yayBpcyByZWFkeSBmb3IgYSB3b3JraW5nIGdyb3cgbGFzdCBjYWxsLg0K Pj4NCj4+IFRoaXMgc3RhcnRzIGEgbGFzdCBjYWxsIGZvciB0aGF0IGRyYWZ0LiAgWW91IG1heSBm aW5kIGl0IGF0DQo+Pmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXNpZHIt cnBraS1ydHItcmZjNjgxMC1iaXMtMDMuDQo+Pg0KPj4gUGxlYXNlIGNvbW1lbnQgdG8gdGhlIGxp c3Qgd2hldGhlciB5b3UgYmVsaWV2ZSB0aGF0IHRoaXMgZHJhZnQgaXMgcmVhZHkNCj4+Zm9yIHB1 YmxpY2F0aW9uLiAgVGhlIHdnbGMgd2lsbCBiZSB0d28gd2Vla3MsIGVuZGluZyBvbiBGcmlkYXks IE1hcmNoIDIwLg0KPj4NCj4+IC0tU2FuZHksIHNwZWFraW5nIGFzIG9uZSBvZiB0aGUgd2cgY28t Y2hhaXJzDQo+DQoNCg0KVGhpcyBFLW1haWwgYW5kIGFueSBvZiBpdHMgYXR0YWNobWVudHMgbWF5 IGNvbnRhaW4gVGltZSBXYXJuZXIgQ2FibGUgcHJvcHJpZXRhcnkgaW5mb3JtYXRpb24sIHdoaWNo IGlzIHByaXZpbGVnZWQsIGNvbmZpZGVudGlhbCwgb3Igc3ViamVjdCB0byBjb3B5cmlnaHQgYmVs b25naW5nIHRvIFRpbWUgV2FybmVyIENhYmxlLiBUaGlzIEUtbWFpbCBpcyBpbnRlbmRlZCBzb2xl bHkgZm9yIHRoZSB1c2Ugb2YgdGhlIGluZGl2aWR1YWwgb3IgZW50aXR5IHRvIHdoaWNoIGl0IGlz IGFkZHJlc3NlZC4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCBvZiB0aGlz IEUtbWFpbCwgeW91IGFyZSBoZXJlYnkgbm90aWZpZWQgdGhhdCBhbnkgZGlzc2VtaW5hdGlvbiwg ZGlzdHJpYnV0aW9uLCBjb3B5aW5nLCBvciBhY3Rpb24gdGFrZW4gaW4gcmVsYXRpb24gdG8gdGhl IGNvbnRlbnRzIG9mIGFuZCBhdHRhY2htZW50cyB0byB0aGlzIEUtbWFpbCBpcyBzdHJpY3RseSBw cm9oaWJpdGVkIGFuZCBtYXkgYmUgdW5sYXdmdWwuIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMg RS1tYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgaW1tZWRpYXRlbHkgYW5k IHBlcm1hbmVudGx5IGRlbGV0ZSB0aGUgb3JpZ2luYWwgYW5kIGFueSBjb3B5IG9mIHRoaXMgRS1t YWlsIGFuZCBhbnkgcHJpbnRvdXQuDQo= From nobody Tue Mar 17 14:57:04 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 324061A8913 for ; Tue, 17 Mar 2015 14:57:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CSWryFZFyBBx for ; Tue, 17 Mar 2015 14:57:01 -0700 (PDT) Received: from walnut.tislabs.com (walnut.tislabs.com [192.94.214.200]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB3D41A8912 for ; Tue, 17 Mar 2015 14:57:01 -0700 (PDT) Received: from nova.tislabs.com (unknown [10.66.1.77]) by walnut.tislabs.com (Postfix) with ESMTP id 2E48C28B0017 for ; Tue, 17 Mar 2015 17:57:01 -0400 (EDT) Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1]) by nova.tislabs.com (Postfix) with ESMTP id 2761B1F8035; Tue, 17 Mar 2015 17:57:01 -0400 (EDT) From: Sandra Murphy Content-Type: multipart/signed; boundary="Apple-Mail=_963BF458-C080-413D-A8EB-76FC8B771794"; protocol="application/pgp-signature"; micalg=pgp-sha512 Date: Tue, 17 Mar 2015 17:57:01 -0400 Message-Id: To: "sidr@ietf.org list" Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) X-Mailer: Apple Mail (2.1510) Archived-At: Cc: Sandra Murphy Subject: [sidr] slides from presenters X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Mar 2015 21:57:03 -0000 --Apple-Mail=_963BF458-C080-413D-A8EB-76FC8B771794 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii To all the presenters: Please send your slides to the sidr-chairs@ietf.org alias, so it gets to = everyone who might be able to upload to the materials site. Please send = them by midnight Saturday 21 March. Remember to number your slides. --Sandy, speaking as one of the wg co-chairs --Apple-Mail=_963BF458-C080-413D-A8EB-76FC8B771794 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJVCKMtAAoJEHplpQeet0IZkncP/AzhPMgH4GFE3n9pOQpvLqc8 1oOIXMkAXfERZgKqFdzSsu+xTMvz9go5TFDwtBxdTya10NWHHeBvo9l22X/blT0a vHBSvOQCeqL3rJ69adOcZabJo1jvfVXxRrO3eFLvqw384nuvUwQg7xIG213KkIm2 VmB9wVoSJTTW1peiwjDjKRZZdAAvMxibIlf0HxNqPOlcThmUqdWhdS50H6hh4eSI Ws3G0JiZfyUQYrf5gCEfJCeroQY86Ig/avjLm6IyCtWQjJmB6lLp5qzv6nHVINEk glk499uYWg4UlqPQ2ChZwtjKsEuCWPX7GeBSDZr+fhDxF0UkkzHGdW0A6x4/1TmO gDFZ2oYS6s2n2aVWQL7Oy6v/wosMU2/RZdX6c+qEAiWECinxjrrIjWCHn+nwO4Kg YGYHeDnvgoelcwFKgJA1+4Ik1J7NMjxCXk747AShMYSHqK1oxVoYxHpXeeMEQGPw 4CXWpe4pmw0wZzVuqtzDUNuVPWLQPyyvjao6PFhcQeahKoaGSGkBxf3wo5kGAiQ+ QAAYlYaciMIJB/yacZNA1j3xlZejX3nMJSuuI2NyOWr9lS3C+dy8yn0/s7ysMfDU pEFqeqPdiugxX+rfuCWz/W9OheNfN3GipcwCyt5hceehr9d3emKpgc3X+cPoA8eJ qabHcP8QLJQqrW+hxf6B =o+gh -----END PGP SIGNATURE----- --Apple-Mail=_963BF458-C080-413D-A8EB-76FC8B771794-- From nobody Wed Mar 18 20:10:19 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42C481A870E for ; Wed, 18 Mar 2015 20:10:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.8 X-Spam-Level: X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jQuKgK8LD_wM for ; Wed, 18 Mar 2015 20:10:16 -0700 (PDT) Received: from nm8-vm9.access.bullet.mail.gq1.yahoo.com (nm8-vm9.access.bullet.mail.gq1.yahoo.com [216.39.63.246]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D5CDF1A8701 for ; Wed, 18 Mar 2015 20:10:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1426734616; bh=L69BBhZpKWBGuTCWHi0eVYiMQORAvC89booO2WVgjSQ=; h=Date:From:To:Subject:In-Reply-To:References:From:Subject; b=ks5XJ1rSSKFaodrLNz4/JQGrX17+6/anf+HbT8Fl+Q6yLji6cH0KsLU6KDAFJwodQaWuJhn/frUMZFQuLxlE1ba1yV10Up+gBofEVPqOMChNBIh5sIARKXM2I7rBLkvdy3xwO7ndMnAUym4JQKG6FZCSMMxwmyAk1igEk/I6+6uZWxX9qUhJoLF1TAXTYKbWXQNzNJv4RWRgL9m54yuMKU6+Q379t7/Wx5tH+eHeebtk1i6yo60qULcu1ZwJEt1/iBO1+zF0k/M8TGCtUz/aEeeSMIt1VvRAOQ6d0eNQY574D0MgjiqXXFzpWoDvHywwXmVw5Hq7FYiMFLSIE9RR6g== Received: from [216.39.60.171] by nm8.access.bullet.mail.gq1.yahoo.com with NNFMP; 19 Mar 2015 03:10:16 -0000 Received: from [98.138.104.97] by tm7.access.bullet.mail.gq1.yahoo.com with NNFMP; 19 Mar 2015 03:10:16 -0000 Received: from [127.0.0.1] by smtp117.sbc.mail.ne1.yahoo.com with NNFMP; 19 Mar 2015 03:10:16 -0000 X-Yahoo-Newman-Id: 346710.6887.bm@smtp117.sbc.mail.ne1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: kghC4gkVM1n5CWnlmbz3wfNApVF.R6VZ5GP_RK_ouaAOTbN XmBme9WwjQ06x.oYU1P0HYGIhCrJ.5ZnQ6xfnYv.KDKep9ibcEVz2_7Noicx yi2IKGzMIYIF5koVgGfqfqLbPbhUPMCrKK_KkJ4OHA0CmmDmR3DcvKtYWMsO Vrd.eNSt7z8N4sQVpmB3mLXXd94dnFIJAyqPtKnYThp8MHeeWsGb.QI2TlDF 8LAHphDUy.13l8hI3Fg35v9wkCKZp2EB8e9F9sYBt8TAIxiYwOXPkN_KKrIX FLEMKtdPf7NqwBrrFBl3ioB9FE0XtDMH7AMqCZZamhRYXyZNyYqFELpneZjO T.qGvKxUCKK7RUXdiG7Y8xQbl.OMUtAsGaXNYzf72_ZZCpCUG_iG1lDbXvqY E8E3a5IB0GpA41tViUWdbreXXnK6.zGRq_nwAjXI0gTmTdHEcWsT3HaTef9z d_8I._Zl5PV4VBUoF1bnbo6KkzDdamsF2PB.OC1O.7dk5qLl4qmWmAuS_AGE KL3VBUNbu31QBic2i8O6CBQHeg4L35xQMA.2sd1DEMwpfDKPHodjoBf__K3w fcdVhTWpOsxg0_wzW7ex0L9fUZNVCiIwdvoySsIa1wTPqrwUtOeSfrPXs7_t e X-Yahoo-SMTP: 4kJJK.qswBDPuwyc5wW.BPAQqNXdy5j09UNyeAS0pyOQ708- Received: from secure.mandelberg.org (c-76-24-31-176.hsd1.ma.comcast.net [76.24.31.176]) by uriel.mandelberg.org (Postfix) with ESMTPSA id C1BAA1C6052 for ; Wed, 18 Mar 2015 23:10:14 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Date: Wed, 18 Mar 2015 23:10:14 -0400 From: David Mandelberg To: In-Reply-To: References: <9D70CAEF-22F9-44FC-A429-9CBEBA9EAE6C@tislabs.com> Message-ID: X-Sender: david@mandelberg.org User-Agent: Roundcube Webmail/0.7.2 Archived-At: Subject: Re: [sidr] WGLC for draft-ietf-sidr-rpki-rtr-rfc6810-bis-03 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Mar 2015 03:10:18 -0000 On 2015-03-17 14:29, George, Wes wrote: > This > may be as simple as recommending that in the case where data from > multiple > caches is held and specific entries conflict with one another, there > SHOULD be an odd number of caches so that there is basis for > comparison to > determine which cache is out of sync or providing incorrect info. > (i.e. > Have 3 so that you can go with the 2/3 that agree) Are you suggesting comparison of all the data from each single cache as an atomic entity, or comparison of individual IPvX and Router Key PDUs? If the former, then I think that would work fine as long as a majority (or maybe even a plurality) of the caches has the exact same data. But what does the router do if this is not the case? If the caches all download from the RPKI at different times, then I would expect it to be common for no two caches to have the same data. If the latter, then the semantics depend heavily on exactly how the comparison is done. Lets say a CA simultaneously issues one ROA for {AS 65536, 10.0.0.0/8} and another for {AS 65537, 10.0.0.0/8}. Some of the caches see the publication point before both ROAs are issued; some see the pub point after both ROAs are issued and published. Can you guarantee that the voting mechanism will always result in either both ROA payloads, or neither, being used? (If a router ends up using one but not the other, then a previously unknown route becomes invalid.) -- David Eric Mandelberg / dseomn http://david.mandelberg.org/ From nobody Thu Mar 19 05:58:49 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4A231A89AE for ; Thu, 19 Mar 2015 05:58:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.225 X-Spam-Level: X-Spam-Status: No, score=0.225 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PLAq54ynEGKW for ; Thu, 19 Mar 2015 05:58:47 -0700 (PDT) Received: from cdcipgw02.twcable.com (cdcipgw02.twcable.com [165.237.91.111]) by ietfa.amsl.com (Postfix) with ESMTP id 5C2261A00B1 for ; Thu, 19 Mar 2015 05:58:46 -0700 (PDT) X-SENDER-IP: 10.136.163.12 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="5.11,429,1422939600"; d="scan'208";a="229069440" Received: from unknown (HELO PRVPEXHUB03.corp.twcable.com) ([10.136.163.12]) by cdcipgw02.twcable.com with ESMTP/TLS/RC4-MD5; 19 Mar 2015 08:46:55 -0400 Received: from PRVPEXVS10.corp.twcable.com ([10.136.163.41]) by PRVPEXHUB03.corp.twcable.com ([10.136.163.12]) with mapi; Thu, 19 Mar 2015 08:58:45 -0400 From: "George, Wes" To: David Mandelberg , "sidr@ietf.org" Date: Thu, 19 Mar 2015 08:58:43 -0400 Thread-Topic: [sidr] WGLC for draft-ietf-sidr-rpki-rtr-rfc6810-bis-03 Thread-Index: AdBiRG6sn2w8o6AHRJOaYGSk9gRqiA== Message-ID: References: <9D70CAEF-22F9-44FC-A429-9CBEBA9EAE6C@tislabs.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.8.150116 acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [sidr] WGLC for draft-ietf-sidr-rpki-rtr-rfc6810-bis-03 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Mar 2015 12:58:49 -0000 DQpPbiAzLzE4LzE1LCAxMToxMCBQTSwgIkRhdmlkIE1hbmRlbGJlcmciIDxkYXZpZEBtYW5kZWxi ZXJnLm9yZz4gd3JvdGU6DQoNCj5BcmUgeW91IHN1Z2dlc3RpbmcgY29tcGFyaXNvbiBvZiBhbGwg dGhlIGRhdGEgZnJvbSBlYWNoIHNpbmdsZSBjYWNoZSBhcw0KPmFuIGF0b21pYyBlbnRpdHksIG9y IGNvbXBhcmlzb24gb2YgaW5kaXZpZHVhbCBJUHZYIGFuZCBSb3V0ZXIgS2V5IFBEVXM/DQo+DQo+ SWYgdGhlIGZvcm1lciwgdGhlbiBJIHRoaW5rIHRoYXQgd291bGQgd29yayBmaW5lIGFzIGxvbmcg YXMgYSBtYWpvcml0eQ0KPihvciBtYXliZSBldmVuIGEgcGx1cmFsaXR5KSBvZiB0aGUgY2FjaGVz IGhhcyB0aGUgZXhhY3Qgc2FtZSBkYXRhLiBCdXQNCj53aGF0IGRvZXMgdGhlIHJvdXRlciBkbyBp ZiB0aGlzIGlzIG5vdCB0aGUgY2FzZT8gSWYgdGhlIGNhY2hlcyBhbGwNCj5kb3dubG9hZCBmcm9t IHRoZSBSUEtJIGF0IGRpZmZlcmVudCB0aW1lcywgdGhlbiBJIHdvdWxkIGV4cGVjdCBpdCB0byBi ZQ0KPmNvbW1vbiBmb3Igbm8gdHdvIGNhY2hlcyB0byBoYXZlIHRoZSBzYW1lIGRhdGEuDQo+DQo+ SWYgdGhlIGxhdHRlciwgdGhlbiB0aGUgc2VtYW50aWNzIGRlcGVuZCBoZWF2aWx5IG9uIGV4YWN0 bHkgaG93IHRoZQ0KPmNvbXBhcmlzb24gaXMgZG9uZS4gTGV0cyBzYXkgYSBDQSBzaW11bHRhbmVv dXNseSBpc3N1ZXMgb25lIFJPQSBmb3Ige0FTDQo+NjU1MzYsIDEwLjAuMC4wLzh9IGFuZCBhbm90 aGVyIGZvciB7QVMgNjU1MzcsIDEwLjAuMC4wLzh9LiBTb21lIG9mIHRoZQ0KPmNhY2hlcyBzZWUg dGhlIHB1YmxpY2F0aW9uIHBvaW50IGJlZm9yZSBib3RoIFJPQXMgYXJlIGlzc3VlZDsgc29tZSBz ZWUNCj50aGUgcHViIHBvaW50IGFmdGVyIGJvdGggUk9BcyBhcmUgaXNzdWVkIGFuZCBwdWJsaXNo ZWQuIENhbiB5b3UNCj5ndWFyYW50ZWUgdGhhdCB0aGUgdm90aW5nIG1lY2hhbmlzbSB3aWxsIGFs d2F5cyByZXN1bHQgaW4gZWl0aGVyIGJvdGgNCj5ST0EgcGF5bG9hZHMsIG9yIG5laXRoZXIsIGJl aW5nIHVzZWQ/IChJZiBhIHJvdXRlciBlbmRzIHVwIHVzaW5nIG9uZSBidXQNCj5ub3QgdGhlIG90 aGVyLCB0aGVuIGEgcHJldmlvdXNseSB1bmtub3duIHJvdXRlIGJlY29tZXMgaW52YWxpZC4pDQoN CldHXSB3ZWxsLCB0aGF0IGlzIG1haW5seSB3aHkgSSBicm91Z2h0IHVwIHRoZSBjb25jZXJuLiBW b3RpbmcgY29tcGFyaXNvbnMNCmxpa2UgdGhpcyBjYW4gYmUgaGFyZCB0byBkbyB3aXRoIHRoaXMg YW1vdW50IG9mIGRhdGEsIHNvIGlmIGl0IHdhcyBvdXINCmludGVudCB0byBhbGxvdyBtdWx0aXBs ZSBmdWxsIHZpZXdzLCB3ZSBuZWVkIGJldHRlciBndWlkYW5jZSBvbiBob3cgd2UNCnRoaW5rIGl0 J3MgbW9zdCBsaWtlbHkgdG8gYWN0dWFsbHkgd29yay4gSSdtIG5vdCBzdXJlIHdlJ2Qgc2VlIGVu b3VnaA0KY29uc2lzdGVuY3kgYmV0d2VlbiBjYWNoZXMgdG8gYmVuZWZpdCBmcm9tIGF0b21pYyBj b21wYXJpc29ucywgc28gaXQgbWF5DQpiZSBhIG1hdHRlciBvZiB0YWtpbmcgYWdlIGFuZCBvdGhl ciB0aGluZ3MgaW50byBhY2NvdW50LiBCdWlsZGluZyBvcg0KYWRhcHRpbmcgYSB2b3RpbmcgYWxn b3JpdGhtIHNlZW1zIGxpa2UgYSBsb3Qgb2YgZWZmb3J0IGZvciB3aGF0IG1heSB3ZWxsDQpiZSBh IGNvcm5lciBjYXNlLCBidXQgaWYgd2UncmUgZ29pbmcgdG8gYWxsb3cgcmV0ZW50aW9uIG9mIG11 bHRpcGxlDQpjYWNoZXMnIGRhdGEsIHdlIGhhdmUgdG8gYWRkcmVzcyB0aGUgaXNzdWUgb2YgaG93 IHRvIGhhbmRsZSBkaXNhZ3JlZW1lbnQNCmJldHdlZW4gY2FjaGVzLiBVbmxlc3MgcGVyaGFwcyB0 aGlzIHBhcnQgb2Ygc2VjdGlvbiAxMCBpcyBqdXN0DQpwb29ybHktd29yZGVkIGFuZCB0aGUgaW50 ZW50IHdhcyBvbmx5IGV2ZXIgdG8gYWxsb3cgcmV0ZW50aW9uIG9mIG90aGVyDQpjYWNoZSdzIGRh dGEgdG8ga2VlcCBhIHF1YXNpLWNvbXBsZXRlIHZpZXcgZHVyaW5nIGEgZmFpbG92ZXIvcmVzeW5j LCBpLmUuDQpBcyBvbmUgZW50cnkgaXMgcHVsbGVkIGZyb20gdGhlIG5ldyBjYWNoZSwgaXRzIGNv cnJlc3BvbmRpbmcgZW50cmllcw0KW1NIT1VMRC9NVVNUXSBiZSBwdXJnZWQgZnJvbSB0aGUgb3Ro ZXIgb25lKHMpLCBldGMuDQoNCg0KVGhpcyBFLW1haWwgYW5kIGFueSBvZiBpdHMgYXR0YWNobWVu dHMgbWF5IGNvbnRhaW4gVGltZSBXYXJuZXIgQ2FibGUgcHJvcHJpZXRhcnkgaW5mb3JtYXRpb24s IHdoaWNoIGlzIHByaXZpbGVnZWQsIGNvbmZpZGVudGlhbCwgb3Igc3ViamVjdCB0byBjb3B5cmln aHQgYmVsb25naW5nIHRvIFRpbWUgV2FybmVyIENhYmxlLiBUaGlzIEUtbWFpbCBpcyBpbnRlbmRl ZCBzb2xlbHkgZm9yIHRoZSB1c2Ugb2YgdGhlIGluZGl2aWR1YWwgb3IgZW50aXR5IHRvIHdoaWNo IGl0IGlzIGFkZHJlc3NlZC4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCBv ZiB0aGlzIEUtbWFpbCwgeW91IGFyZSBoZXJlYnkgbm90aWZpZWQgdGhhdCBhbnkgZGlzc2VtaW5h dGlvbiwgZGlzdHJpYnV0aW9uLCBjb3B5aW5nLCBvciBhY3Rpb24gdGFrZW4gaW4gcmVsYXRpb24g dG8gdGhlIGNvbnRlbnRzIG9mIGFuZCBhdHRhY2htZW50cyB0byB0aGlzIEUtbWFpbCBpcyBzdHJp Y3RseSBwcm9oaWJpdGVkIGFuZCBtYXkgYmUgdW5sYXdmdWwuIElmIHlvdSBoYXZlIHJlY2VpdmVk IHRoaXMgRS1tYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgaW1tZWRpYXRl bHkgYW5kIHBlcm1hbmVudGx5IGRlbGV0ZSB0aGUgb3JpZ2luYWwgYW5kIGFueSBjb3B5IG9mIHRo aXMgRS1tYWlsIGFuZCBhbnkgcHJpbnRvdXQuDQo= From nobody Thu Mar 19 08:00:56 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD5A61ACD76 for ; Thu, 19 Mar 2015 08:00:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.99 X-Spam-Level: * X-Spam-Status: No, score=1.99 tagged_above=-999 required=5 tests=[BAYES_50=0.8, GB_SUMOF=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_DBL_SPAM=2.5] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fLukOXMTASEy for ; Thu, 19 Mar 2015 08:00:47 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F9351ACD78 for ; Thu, 19 Mar 2015 08:00:46 -0700 (PDT) Received: from ssh.bbn.com ([192.1.122.15]:52978 helo=COMSEC.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1YYbwC-000BcP-0J for sidr@ietf.org; Thu, 19 Mar 2015 11:00:44 -0400 Message-ID: <550AE49C.9010207@bbn.com> Date: Thu, 19 Mar 2015 11:00:44 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: sidr Content-Type: multipart/alternative; boundary="------------060508090109060903040206" Archived-At: Subject: [sidr] comments on validation revisited -01 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Mar 2015 15:00:55 -0000 This is a multi-part message in MIME format. --------------060508090109060903040206 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit I reviewed draft-ietf-sidr-rpki-validation-reconsidered-01.txt. There are a number of minor changes to the text, but the big change is the addition of a specification for the proposed, revised validation procedure. Thus many of my comments repeat concerns cited with respect to the -00 version of this document and previously posted to this list. At the SIDR meeting in Honolulu John Curran delivered a briefing co-authored coauthored by Geoff Huston. That briefing described the potential for errors and the impact of such errors when a CA reissues a certificate with a smaller set of INRs. This presentation referred to the analysis in the -00 version of this document as “not detailed” and noted that the motivation for changing the validation algorithm was “not based on operational experience.” As a result I expected to see a more detailed analysis and discussion of operational experience with respect to over claiming (slide 4). For example, the importance of addressing this issue would be clearer if there were statistics detailing the number of INR transfers, by region, for the past few years. Such stats should indicate when the transfers were for “live” (in-use) vs. unused INRs. Finally, to understand the implications for the RPKI, the stats should indicate how transfers relate to the RPKI hierarchy, i.e., how many tiers were involved in a transfer. John’s briefing also suggested that a standard procedure for certificate management during INR transfers be documented (slide 5). The changes that resulted in the -01 version of this document do not addresses any of these issues. At the previous meeting, in Toronto, I offered to provide edits to improve the text when sentences run on, as they do in many places. I failed to do so, butsince most of the text is unchanged from the -00 version, I offer such revisions now, at the end of this message. Below are other comments on the -01 version of the document. The BEFORE/AFTER text is the bulk of this message. The second and third paragraphs of Section 3, argue that over-claiming may be the result of errors by a CA in the course of normal operation, independent of an INR transfer. This is inconsistent with the stated rationale from the earlier sections of the document. However, I agree with the concern cited here, i.e., we should examine ways to make the RPKI tolerant of errors made by CAs (especially higher tier CAs) and repository operators. Yet, the proposed mechanism addresses only one type of error. I suggest that an analysis is required to explore the range and types of errors that might occur, so that we can pursue a solution that addresses more than just the one type of error cited in this document. Later in Section 3 the document cites one possible way that a transfer might be effected, and notes that this would result in problems as illustrated in Section 2. However, the document does not examine other possible transfer procedures that might avoid this problem. It seems inappropriate to cite one example of how to effect a transfer and use that example to justify a major change in the RPKI validation procedure.(I’m tempted to cite the joke about a patient who complains to his doctor that when he tries to move his arm in a particular fashion it hurts. The doctor replies “Then don’t do that!”) I recall someone noting during a previous meeting that the CA’s on the receiving side of an INR transfer could issue new certificates, containing just the INRs being transferred, as a way to avoid the problem cited in this document. If these certificates are issued prior to the transfer being represented in the “common CA” certificate, they will be invalid, but they will not affect any other INRs in the path. When the transfer has been completed, the INRs can be represented in the (long term) certificates of the affected parties, and the certificates issued on a temporary basis for the transfer can be revoked (or allowed to expire). This suggestion does not seem to require changes to the existing path validation procedure, nor changes to RFCs. It does have the downside of adding more certificates to the RPKI repository system, for a (hopefully short) time. Absent stats on the frequency of transfers and the number of CAs that are (would be) involved, it’s impossible to determine if the impacts of this approach are significant. Later in Section 3 the document says: “Avoiding such situations requires that CA's adhere to a very specific ordering of certificate issuance.” It’s true that coordination of actions across CAs is needed when INRs are transferred. But coordination is required irrespective of the RPKI, e.g., to ensure that the INRs being transferred are not allocated by both the previous holder and the new holder (or their parent organizations). Thus the need for coordination is one of degree and extent, not a black-or-white distinction as suggested by the text. The text goes on to suggest that there is only one order of events that will effect a transfer without breaking the RPKI. This is not quite true. The (currently expired) Transfer Authorization Object (TAO) draft described how transfers could be effected under the current certificate path validation procedures. That document noted where coordination is required, and it painted a less rigid picture than that presented in the validation revisited I-D. Also, the discussion in this section fails to distinguish between a transfer of “live” address space vs. unused space. The distinction, which was addressed in the TAO I-D, is important and should be part of any discussion that purports to provide an analysis of inherent limitations on INR transfer procedures. Moreover, an approach based on issuing temporary certificates, as noted above, represents another means of staging a transfer that may reduce constraints on the ordering ofthe steps in the process. I note a very brief mention of the TAO idea in Section 4, along with a very quick dismissal. In part the text suggests that the TAO approach may be inadequate because its fails to “…mitigate to any meaningful extent the risks of failure to ensure strict INR consistency at all times.” This text sounds like its is again considering the larger topic of errors by CAs, independent of INR transfers. If so, then, as I noted above, an analysis of such errors needs to precede detailed discussion of proposed solutions. Section 5 is new, specifying the proposed, revised validation procedure. Much of this text is redundant. For example, steps 1 and 2 (page 7) are always part of path validation. Steps 3 and 4 are already stated in [RFC6487], and need not be two, separate steps.Steps 5 and 7 are always part of certificate path validation. Step 6 is the only RPKI-unique step and I don’t understand what it means. Presumably the text in the following paragraph (from page 8) is intended to establish the context for step 6, but that text says: Validation of signed resource data using a signing key that is certified in a resource certificate, coupled with a specific set of number resources, consists of verifying that the digital signature of the signed resource data is valid, using the public key that is certified by the resource certificate, and also validating the resource certificate in the context of the RPKI, using the path validation process. This 7-line sentence is unintelligible to me. For example, validation of signed anything is performed using a public key not a “signing” (private) key. Is signed resource data an oblique reference to 3779 extensions in a certificate? The comment “using the path validation process” seems to make the description of the process a circular definition. Suggested fixes for run-on sentences: Section 1. BEFORE This document reviews the certificate validation procedure specified in RFC6487 and highlights aspects of operational fragility in the management of certificates in the RPKI in response to the movement of resources across registries, and the associated actions of Certification Authorities to maintain continuity of validation of certification of resources during this movement. AFTER This document reviews the certificate validation procedure specified in RFC6487, with respect to operational fragility in the context of RPKI certificate management. It focuses on scenarios involving resource transfers across registries and the actions of Certification Authorities as needed to ensure continuity of validation of resource certificates during such transfers. Section 2. BEFORE As currently defined in section 7.2 of [RFC6487], validation of PKIX certificates that conform to the RPKI profile relies on the use of a path validation process where each certificate in the validation path is required to meet the certificate validation criteria.This is a recursively defined validation process where, in the context of an ordered sequence of certificates, as defined by each pair of certificates in this sequence having a common Issuer and Subject Name respectively, a certificate is defined as valid if it satisfies basic validation criteria relating to the syntactic correctness, currency of validity dates and similar properties of the certificate itself, as described in [RFC5280], and also that it satisfies certain additional criteria with respect to the previous certificate in the sequence (the Issuer part of the pair), and that this previous certificate is itself a valid certificate using the same criteria. This process is applied to all certificates in the sequence apart from the initial sequence element, which is required to be a Trust Anchor. For RPKI certificates, the additional criteria relating to the previous certificate in this sequence is that the certificate's number resource set, as defined in [RFC3779], is "encompassed" by the number resource set contained in the previous certificate. AFTER Path validation of resource certificates follows the basic procedure described in section 6.1of [RFC5280], with some additional restrictions appropriate for the RPKI context, as described in section 7.2 of [RFC6487]. In particular, the RFC 3779 extensions present in a certificate MUST be “encompassed” by the RFC 3779 extensions in the parent certificate. (As is always the case for path validation, trust anchors are exempt from this requirement.) BEFORE Because [RFC6487] validation demands that all resources in a certificate be valid under the parent (and recursively, to the root), a digitally signed attestation, such as a Route Origin Authorization (ROA) object [RFC6482], which refers only to a subset of RFC3779- specified resources from that certificate validation chain can be concluded to be invalid, but not by virtue of the relationship between the RFC3779 extensions of the certificates on the putative certificate validation path and the resources in the ROA, but by other resources described in these certificates where the "encompassing" relationship of the resources does not hold.Any such invalidity along the certificate validation chain can cause this outcome, not just at the immediate parent of the end entity certificate that attests to the key used to sign the ROA. AFTER Resource certificate validation demands that all INRs in each certificate (other than a trust anchor) be encompassed by the parent certificate. For a Route Origin Authorization (ROA) [RFC6482] this means that the INRs in its EE certificate MUST ne encompassed by the parent CA certificate, and by all superior certificates along the path to a trust anchor. BEFORE The underlying observation here is that this definition of certificate validation treats a collection of resources as inseparable, so that a single certificate containing a bundle of number resources is semantically distinct from an equivalent set of certificates where each certificate contains a single number resource.This semantic distinction between the whole and the sum of its parts is an artifice introduced by the particular choice of a certificate validation procedure used by the RPKI, as distinct from meeting any particular operational requirement, and the result is the introduction of operational fragility into the handling of RPKI certificates, particularly in the case where number resources are moved between the corresponding registries, as described here. AFTER The underlying observation here is that this definition of certificate validation treats a collection of resources as inseparable. Thus, a single certificate containing a bundle of INRs is semantically distinct from an equivalent set of certificates where each certificate contains a single number resource.Specifically, only the individual certificates in the set that fail to be encompassed by the parent would be invalid. This distinction is especially significant for CA certificates. If a CA certificate contains just one INR that is not encompassed by all of its superior CA certificates, the CA certificate is treated as invalid, and thus all of its subordinate certificates are invalid as well. There is no direct, operational requirement that mandates this aspect of resource certificate path validation. This aspect of path validation introduces operational fragility into management of resource certificates, particularly in the case where INRs are moved between the corresponding registries. Section 3. BEFORE This constraint creates a degree of operational fragility in the issuance of certificates, as all CA's are now required to exercise extreme care in the issuance and reissuance of certificates to ensure that at no time do they overclaim on the resources described in the parent CA, as the consequences of an operational lapse or oversight implies that all the subordinate certificates from the point of INR mismatch are invalid.It would be preferred if the consequences of such an operational lapse were limited in scope to the specific INRs that formed the mismatch, rather than including the entire set of INRs within the scope of damage from this point of mismatch downward across the entire sub-tree of descendant certificates in the RPKI certificate hierarchy. AFTER This constraint creates a degree of operational fragility in the issuance of certificates. CA's are required to exercise extreme care in the issuance and reissuance of certificates, to ensure that each the INRs in each certificate are encompassed by the CA’s own certificate. Failure to ensure this property in subordinate CA certificates would cause signed products of such subordinate certificates to be treated as invalid. It would be preferable if the consequences of such an operational lapse were limited in scope to the specific INRs that are not encompassed by superior CA certificates. BEFORE The second operational consideration described here relates to the situation where a registry withdraws a resource from the current holder, and the resource to transferred to another registry, to be registered to a new holder in that registry.The reason why this is a consideration in operational deployments of the RPKI lies in the movement of the "home" registry of number resources during cases of mergers, acquisitions, business re-alignments, and resource transfers and the desire to ensure that during this movement all other resources can continue to be validated. AFTER A second operational concern arises during transfers of INRs. During a transfer, a registry withdraws a resource from the current Holder and transfers it to another registry, to be allocated to a new holder in that registry.If the INRs being transferred are in use by the holder in the "home" registry, then it is critical that routing not be disrupted during the transfer. Mergers, acquisitions, and business re-alignments all may trigger such transfers. (In contrast, if INRs are allocated but not in use in the "home" registry context, transfer of the INRs does not require that they are continuously valid during the process.) BEFORE If the original registry's certification actions are simply to issue a new certificate for the current holder with a reduced resource set, and to revoke the original certificate, then there is a distinct possibility of encountering the situation illustrated by the example in the previous section.This is a result of an operational process for certificate issuance by the parent CA being de-coupled from the certificate operations of child CA. This de-coupled operation of CAs introduces a risk of unintended third party damage: since a CA certificate can refer to holdings which relate to two or more unrelated subordinate certificates, if this CA certificate becomes invalid due to the reduction in the resources allocated to this CA relating to one subordinate resource set, all other subordinate certificates are invalid until the CA certificate is reissued with a reduced resource set. AFTER The original registry's CA might issues a new certificate for the current holder with a reduced resource set, and revoke the original certificate. However, such action would cause the INRs being transferred become invalid, until the recipient of these INRs receives a new, valid certificate containing them. *(I’m unclear what the end of the first paragraph and most of the second paragraph is trying to say.)* BEFORE At the lower levels of the RPKI hierarchy the resource sets affected by such movements of resources may not encompass significantly large pools of resources.However, as one ascends through this certification hierarchy towards the apex, the larger the resource set that is going to be affected by a period of invalidity by virtue of such uncoordinated certificate management actions.In the case of a Regional Internet Registry (RIR) or National Internet Registry (NIR), the potential risk arising from uncoordinated certification actions relating to a transfer of resources is that the entire set of subordinate certificates that refer to resources administered by the RIR or the NIR cannot be validated during this period. AFTER At the lower levels of the RPKI hierarchy the resource sets affected by transfer of INRs may not encompass significantly large pools of resources.However, at higher tiers in the RPKI, the sets of INRs represented in CA certificates can be very large. In the case of a Regional Internet Registry (RIR) or National Internet Registry (NIR), the number INRs represented in their certificates is very large. *(This is true for an NIR only if it acts as a CA vs. an RA. Will all NIRs operates as CAs or will some act only as RAs?)* Thus there is a potential for a very large number of subordinate CAs to be adversely affected if the INRs represented in these CA certificates fail to adhere to the subset requirements imposed by [RFC3779]. *(The situation seems more complex than suggested here. First, if one focuses only on over-claiming, as this document seems to, the current RIR situation does not seem to have this problem. That’s because each RIR is a TA. Any INRs in a TA certificate are not subject to 3779 restrictions, so they cannot over-claim.Also, I believe that each RIR issues a subordinate CA certificate below its TA certificate, and uses the inherit bit to represent the INRs. In that case, the subordinate CA certificate also cannot over-claim. This sentence needs to turn into a paragraph to more accurately discuss the potential for very wide scale problems at the RIR tier.)* BEFORE Avoiding such situations requires that CA's adhere to a very specific ordering of certificate issuance.In this framework, the common registry CA that describes (directly or indirectly) the resources being shifted from one registry to the other, and also contains in subordinate certificates (direct or indirect) the certificates for both registries who are parties to the resource transfer has to coordinate a specific sequence of actions. This common registry CA has to first issue a new certificate towards the "receiving" registry that adds to the RFC3779 extension resource set the specific resource being transferred into this receiving registry.The common registry CA then has to wait until all registries in the subordinate certificate chain to the receiving registry have also performed a similar issuance of new certificates, and in each case a registry must await the issuance of the immediate superior certificate with the augmented resource set before it, in turn, can issue its own augmented certificate to its subordinate CA. This is a "top down" issuance sequence." AFTER Avoiding such situations requires that CA's adhere to a very specific ordering of certificate issuance. The common registry CA that is responsible (directly or indirectly) for the INRs being transferred, must coordinate the sequence of actions that effect the transfer. *(I didn’t rewrite the second paragraph above because the sequence of events that it describes is not the only way to orchestrate a transfer, as demonstrated in the TAO I-D.)* ** ** BEFORE It is possible for the common registry to issue a certificate to the "sending" registry with the reduced resource set at any time, but it should not revoke the previously issued certificate, nor overwrite this previously issued certificate in its repository publication point without specific coordination.Only when the common registry is assured that the top down certificate issuance process to the receiving registry CA chain has been completed can the common registry commence the revocation of the original certificate for the sending registry, However, it should not so until it is assured that the immediate subordinate registry CA in the path to the sending registry has issued a certificate with a reduced resource set, and so on.This implies that on the sending side the certificate issuance and revocation is a "bottom up" process. AFTER It is possible for the common registry to issue a certificate to the "sending" registry with the reduced resource set at any time. However, it should not revoke nor replace the previously issued certificate, without specific coordination. The common registry must verify that the certificate path to the recipient of the transferred INRs is in place before revoking and replacing the CA certificate of the source. This implies that on the sending side the certificate issuance and revocation is a "bottom up" process. *(The process also may be “bottom up” on the receiving side, with respect to requesting the INRs being transferred. However, the issuance of certificates with the new resources must be “top down.”)* BEFORE The underlying consideration here is that the operational coordination of these certificate issuance and revocation actions to effect a smooth resource transfer across registries is mandated by the nature of the particular choice of certificate validation process described in [RFC6487]. AFTER The certificate path validation procedure described in [RFC6487] requires that transfers of INRs be coordinated to prevent even transient over-claiming. Section 4. BEFORE Validation of signed resource data using a signing key that is certified in a resource certificate, coupled with a specific set of number resources, consists of verifying that the digital signature of the signed resource data is valid, using the public key that is certified by the resource certificate, and also validating the resource certificate in the context of the RPKI, using the path validation process. AFTER *(Nothing, since the text seems to add nothing to the description of the alternativepath validation procedure.)* --------------060508090109060903040206 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

I reviewed draft-ietf-sidr-rpki-validation-reconsidered-01.txt.

There are a number of minor changes to the text, but the big change is the addition of a specification for the proposed, revised validation procedure. Thus many of my comments repeat concerns cited with respect to the -00 version of this document and previously posted to this list.

 

At the SIDR meeting in Honolulu John Curran delivered a briefing co-authored coauthored by Geoff Huston. That briefing described the potential for errors and the impact of such errors when a CA reissues a certificate with a smaller set of INRs. This presentation referred to the analysis in the -00 version of this document as “not detailed” and noted that the motivation for changing the validation algorithm was “not based on operational experience.” As a result I expected to see a more detailed analysis and discussion of operational experience with respect to over claiming (slide 4).  For example, the importance of addressing this issue would be clearer if there were statistics detailing the number of INR transfers, by region, for the past few years. Such stats should indicate when the transfers were for “live” (in-use) vs. unused INRs. Finally, to understand the implications for the RPKI, the stats should indicate how transfers relate to the RPKI hierarchy, i.e., how many tiers were involved in a transfer.

 

John’s briefing also suggested that a standard procedure for certificate management during INR transfers be documented (slide 5). The changes that resulted in the -01 version of this document do not addresses any of these issues.

 

At the previous meeting, in Toronto, I offered to provide edits to improve the text when sentences run on, as they do in many places. I failed to do so, but since most of the text is unchanged from the -00 version, I offer such revisions now, at the end of this message. Below are other comments on the -01 version of the document. The BEFORE/AFTER text is the bulk of this message.

 

The second and third paragraphs of Section 3, argue that over-claiming may be the result of errors by a CA in the course of normal operation, independent of an INR transfer. This is inconsistent with the stated rationale from the earlier sections of the document. However, I agree with the concern cited here, i.e., we should examine ways to make the RPKI tolerant of errors made by CAs (especially higher tier CAs) and repository operators. Yet, the proposed mechanism addresses only one type of error. I suggest that an analysis is required to explore the range and types of errors that might occur, so that we can pursue a solution that addresses more than just the one type of error cited in this document.

 

Later in Section 3 the document cites one possible way that a transfer might be effected, and notes that this would result in problems as illustrated in Section 2. However, the document does not examine other possible transfer procedures that might avoid this problem. It seems inappropriate to cite one example of how to effect a transfer and use that example to justify a major change in the RPKI validation procedure.  (I’m tempted to cite the joke about a patient who complains to his doctor that when he tries to move his arm in a particular fashion it hurts. The doctor replies “Then don’t do that!”)

 

I recall someone noting during a previous meeting that the CA’s on the receiving side of an INR transfer could issue new certificates, containing just the INRs being transferred, as a way to avoid the problem cited in this document. If these certificates are issued prior to the transfer being represented in the “common CA” certificate, they will be invalid, but they will not affect any other INRs in the path. When the transfer has been completed, the INRs can be represented in the (long term) certificates of the affected parties, and the certificates issued on a temporary basis for the transfer can be revoked (or allowed to expire). This suggestion does not seem to require changes to the existing path validation procedure, nor changes to RFCs. It does have the downside of adding more certificates to the RPKI repository system, for a (hopefully short) time. Absent stats on the frequency of transfers and the number of CAs that are (would be) involved, it’s impossible to determine if the impacts of this approach are significant.

 

Later in Section 3 the document says: “Avoiding such situations requires that CA's adhere to a very specific ordering of certificate issuance.” It’s true that coordination of actions across CAs is needed when INRs are transferred. But coordination is required irrespective of the RPKI, e.g., to ensure that the INRs being transferred are not allocated by both the previous holder and the new holder (or their parent organizations). Thus the need for coordination is one of degree and extent, not a black-or-white distinction as suggested by the text.

 

The text goes on to suggest that there is only one order of events that will effect a transfer without breaking the RPKI. This is not quite true. The (currently expired) Transfer Authorization Object (TAO) draft described how transfers could be effected under the current certificate path validation procedures. That document noted where coordination is required, and it painted a less rigid picture than that presented in the validation revisited I-D. Also, the discussion in this section fails to distinguish between a transfer of “live” address space vs. unused space. The distinction, which was addressed in the TAO I-D, is important and should be part of any discussion that purports to provide an analysis of inherent limitations on INR transfer procedures. Moreover, an approach based on issuing temporary certificates, as noted above, represents another means of staging a transfer that may reduce constraints on the ordering of  the steps in the process.

 

I note a very brief mention of the TAO idea in Section 4, along with a very quick dismissal. In part the text suggests that the TAO approach may be inadequate because its fails to “…mitigate to any meaningful extent the risks of failure to ensure strict INR consistency at all times.” This text sounds like its is again considering the larger topic of errors by CAs, independent of INR transfers. If so, then, as I noted above, an analysis of such errors needs to precede detailed discussion of proposed solutions.

 

Section 5 is new, specifying the proposed, revised validation procedure. Much of this text is redundant. For example, steps 1 and 2 (page 7) are always part of path validation. Steps 3 and 4 are already stated in [RFC6487], and need not be two, separate steps.  Steps 5 and 7 are always part of certificate path validation. Step 6 is the only RPKI-unique step and I don’t understand what it means. Presumably the text in the following paragraph (from page 8) is intended to establish the context for step 6, but that text says:

 

Validation of signed resource data using a signing key that is

certified in a resource certificate, coupled with a specific set of number resources, consists of verifying that the digital signature of the signed resource data is valid, using the public key that is certified by the resource certificate, and also validating the resource certificate in the context of the RPKI, using the path validation process.

 

This 7-line sentence is unintelligible to me. For example, validation of signed anything is performed using a public key not a “signing” (private) key. Is signed resource data an oblique reference to 3779 extensions in a certificate? The comment “using the path validation process” seems to make the description of the process a circular definition.

 

 

Suggested fixes for run-on sentences:

 

Section 1.

 

BEFORE

This document reviews the certificate validation procedure specified

in RFC6487 and highlights aspects of operational fragility in the

management of certificates in the RPKI in response to the movement of

resources across registries, and the associated actions of

Certification Authorities to maintain continuity of validation of

certification of resources during this movement.

 

AFTER

This document reviews the certificate validation procedure specified

in RFC6487, with respect to operational fragility in the context of RPKI certificate management. It focuses on scenarios involving resource transfers across registries and the actions of

Certification Authorities as needed to ensure continuity of validation of resource certificates during such transfers.

 

Section 2.

 

BEFORE

As currently defined in section 7.2 of [RFC6487], validation of PKIX

certificates that conform to the RPKI profile relies on the use of a

path validation process where each certificate in the validation path

is required to meet the certificate validation criteria.  This is a

recursively defined validation process where, in the context of an

ordered sequence of certificates, as defined by each pair of

certificates in this sequence having a common Issuer and Subject Name

respectively, a certificate is defined as valid if it satisfies basic

validation criteria relating to the syntactic correctness, currency

of validity dates and similar properties of the certificate itself,

as described in [RFC5280], and also that it satisfies certain

additional criteria with respect to the previous certificate in the

sequence (the Issuer part of the pair), and that this previous

certificate is itself a valid certificate using the same criteria.

This process is applied to all certificates in the sequence apart

from the initial sequence element, which is required to be a Trust

Anchor.

 

For RPKI certificates, the additional criteria relating to the

previous certificate in this sequence is that the certificate's

number resource set, as defined in [RFC3779], is "encompassed" by the

number resource set contained in the previous certificate.

 

AFTER

 

Path validation of resource certificates follows the basic procedure described in section 6.1of [RFC5280], with some additional restrictions appropriate for the RPKI context, as described in section 7.2 of [RFC6487]. In particular, the RFC 3779 extensions present in a certificate MUST be “encompassed” by the RFC 3779 extensions in the parent certificate. (As is always the case for path validation, trust anchors are exempt from this requirement.)

 

BEFORE

Because [RFC6487] validation demands that all resources in a

certificate be valid under the parent (and recursively, to the root),

a digitally signed attestation, such as a Route Origin Authorization

(ROA) object [RFC6482], which refers only to a subset of RFC3779-

specified resources from that certificate validation chain can be

concluded to be invalid, but not by virtue of the relationship

between the RFC3779 extensions of the certificates on the putative

certificate validation path and the resources in the ROA, but by

other resources described in these certificates where the

"encompassing" relationship of the resources does not hold.  Any such

invalidity along the certificate validation chain can cause this

outcome, not just at the immediate parent of the end entity

certificate that attests to the key used to sign the ROA.

 

AFTER

 

Resource certificate validation demands that all INRs in each certificate (other than a trust anchor) be encompassed by the parent certificate. For a Route Origin Authorization (ROA) [RFC6482] this means that the INRs in its EE certificate MUST ne encompassed by the parent CA certificate, and by all superior certificates along the path to a trust anchor.

 

BEFORE

The underlying observation here is that this definition of

certificate validation treats a collection of resources as

inseparable, so that a single certificate containing a bundle of

number resources is semantically distinct from an equivalent set of

certificates where each certificate contains a single number

resource.  This semantic distinction between the whole and the sum of

its parts is an artifice introduced by the particular choice of a

certificate validation procedure used by the RPKI, as distinct from

meeting any particular operational requirement, and the result is the

introduction of operational fragility into the handling of RPKI

certificates, particularly in the case where number resources are

moved between the corresponding registries, as described here.

 

AFTER

The underlying observation here is that this definition of

certificate validation treats a collection of resources as

inseparable. Thus, a single certificate containing a bundle of

INRs is semantically distinct from an equivalent set of

certificates where each certificate contains a single number

resource.  Specifically, only the individual certificates in the set that fail to be encompassed by the parent would be invalid. This distinction is especially significant for CA certificates. If a CA certificate contains just one INR that is not encompassed by all of its superior CA certificates, the CA certificate is treated as invalid, and thus all of its subordinate certificates are invalid as well. There is no direct, operational requirement that mandates this aspect of resource certificate path validation. This aspect of path validation introduces operational fragility into management of resource certificates, particularly in the case where INRs are moved between the corresponding registries.

 

Section 3.

 

BEFORE

This constraint creates a degree of operational fragility in the

issuance of certificates, as all CA's are now required to exercise

extreme care in the issuance and reissuance of certificates to ensure

that at no time do they overclaim on the resources described in the

parent CA, as the consequences of an operational lapse or oversight

implies that all the subordinate certificates from the point of INR

mismatch are invalid.  It would be preferred if the consequences of

such an operational lapse were limited in scope to the specific INRs

that formed the mismatch, rather than including the entire set of

INRs within the scope of damage from this point of mismatch downward

across the entire sub-tree of descendant certificates in the RPKI

certificate hierarchy.

 

AFTER

This constraint creates a degree of operational fragility in the

issuance of certificates. CA's are required to exercise extreme care in the issuance and reissuance of certificates, to ensure that each the INRs in each certificate are encompassed by the CA’s own certificate. Failure to ensure this property in subordinate CA certificates would cause signed products of such subordinate certificates to be treated as invalid. It would be preferable if the consequences of such an operational lapse were limited in scope to the specific INRs that are not encompassed by superior CA certificates.

 

 

BEFORE

The second operational consideration described here relates to the

situation where a registry withdraws a resource from the current

holder, and the resource to transferred to another registry, to be

registered to a new holder in that registry.  The reason why this is

a consideration in operational deployments of the RPKI lies in the

movement of the "home" registry of number resources during cases of

mergers, acquisitions, business re-alignments, and resource transfers

and the desire to ensure that during this movement all other

resources can continue to be validated.

 

AFTER

A second operational concern arises during transfers of INRs. During a transfer, a registry withdraws a resource from the current

Holder and transfers it to another registry, to be allocated to a new holder in that registry.  If the INRs being transferred are in use by the holder in the "home" registry, then it is critical that routing not be disrupted during the transfer. Mergers, acquisitions, and business re-alignments all may trigger such transfers. (In contrast, if INRs are allocated but not in use in the "home" registry context, transfer of the INRs does not require that they are continuously valid during the process.)

 

 

BEFORE

If the original registry's certification actions are simply to issue

a new certificate for the current holder with a reduced resource set,

and to revoke the original certificate, then there is a distinct

possibility of encountering the situation illustrated by the example

in the previous section.  This is a result of an operational process

for certificate issuance by the parent CA being de-coupled from the

certificate operations of child CA.

 

This de-coupled operation of CAs introduces a risk of unintended

third party damage: since a CA certificate can refer to holdings

which relate to two or more unrelated subordinate certificates, if

this CA certificate becomes invalid due to the reduction in the

resources allocated to this CA relating to one subordinate resource

set, all other subordinate certificates are invalid until the CA

certificate is reissued with a reduced resource set.

 

AFTER

The original registry's CA might issues a new certificate for the current holder with a reduced resource set, and revoke the original certificate. However, such action would cause the INRs being transferred become invalid, until the recipient of these INRs receives a new, valid certificate containing them.

(I’m unclear what the end of the first paragraph and most of the second paragraph is trying to say.)

 

 

BEFORE

At the lower levels of the RPKI hierarchy the resource sets affected

by such movements of resources may not encompass significantly large

pools of resources.  However, as one ascends through this

certification hierarchy towards the apex, the larger the resource set

that is going to be affected by a period of invalidity by virtue of

such uncoordinated certificate management actions.  In the case of a

Regional Internet Registry (RIR) or National Internet Registry (NIR),

the potential risk arising from uncoordinated certification actions

relating to a transfer of resources is that the entire set of

subordinate certificates that refer to resources administered by the

RIR or the NIR cannot be validated during this period.

 

AFTER

At the lower levels of the RPKI hierarchy the resource sets affected

by transfer of INRs may not encompass significantly large

pools of resources.  However, at higher tiers in the RPKI, the sets of INRs represented in CA certificates can be very large. In the case of a Regional Internet Registry (RIR) or National Internet Registry (NIR), the number INRs represented in their certificates is very large. (This is true for an NIR only if it acts as a CA vs. an RA. Will all NIRs operates as CAs or will some act only as RAs?) Thus there is a potential for a very large number of subordinate CAs to be adversely affected if the INRs represented in these CA certificates fail to adhere to the subset requirements imposed by [RFC3779]. (The situation seems more complex than suggested here. First, if one focuses only on over-claiming, as this document seems to, the current RIR situation does not seem to have this problem. That’s because each RIR is a TA. Any INRs in a TA certificate are not subject to 3779 restrictions, so they cannot over-claim.  Also, I believe that each RIR issues a subordinate CA certificate below its TA certificate, and uses the inherit bit to represent the INRs. In that case, the subordinate CA certificate also cannot over-claim. This sentence needs to turn into a paragraph to more accurately discuss the potential for very wide scale problems at the RIR tier.)

 

BEFORE

Avoiding such situations requires that CA's adhere to a very specific

ordering of certificate issuance.  In this framework, the common

registry CA that describes (directly or indirectly) the resources

being shifted from one registry to the other, and also contains in

subordinate certificates (direct or indirect) the certificates for

both registries who are parties to the resource transfer has to

coordinate a specific sequence of actions.

 

This common registry CA has to first issue a new certificate towards

the "receiving" registry that adds to the RFC3779 extension resource

set the specific resource being transferred into this receiving

registry.  The common registry CA then has to wait until all

registries in the subordinate certificate chain to the receiving

registry have also performed a similar issuance of new certificates,

and in each case a registry must await the issuance of the immediate

superior certificate with the augmented resource set before it, in

turn, can issue its own augmented certificate to its subordinate CA.

This is a "top down" issuance sequence."

 

AFTER

Avoiding such situations requires that CA's adhere to a very specific

ordering of certificate issuance. The common registry CA that is responsible (directly or indirectly) for the INRs being transferred, must coordinate the sequence of actions that effect the transfer.

 

(I didn’t rewrite the second paragraph above because the sequence of events that it describes is not the only way to orchestrate a transfer, as demonstrated in the TAO I-D.)

 

 

BEFORE

It is possible for the common registry to issue a certificate to the

"sending" registry with the reduced resource set at any time, but it

should not revoke the previously issued certificate, nor overwrite

this previously issued certificate in its repository publication

point without specific coordination.  Only when the common registry

is assured that the top down certificate issuance process to the

receiving registry CA chain has been completed can the common

registry commence the revocation of the original certificate for the

sending registry, However, it should not so until it is assured that

the immediate subordinate registry CA in the path to the sending

registry has issued a certificate with a reduced resource set, and so

on.  This implies that on the sending side the certificate issuance

and revocation is a "bottom up" process.

 

AFTER

It is possible for the common registry to issue a certificate to the

"sending" registry with the reduced resource set at any time. However, it should not revoke nor replace the previously issued certificate,

without specific coordination. The common registry must verify that the certificate path to the recipient of the transferred INRs is in place before revoking and replacing the CA certificate of the source.

This implies that on the sending side the certificate issuance

and revocation is a "bottom up" process. (The process also may be “bottom up” on the receiving side, with respect to requesting the INRs being transferred. However, the issuance of certificates with the new resources must be “top down.”)

 

 

BEFORE

The underlying consideration here is that the operational

coordination of these certificate issuance and revocation actions to

effect a smooth resource transfer across registries is mandated by

the nature of the particular choice of certificate validation process

described in [RFC6487].

 

AFTER

The certificate path validation procedure described in [RFC6487] requires that transfers of INRs be coordinated to prevent even transient over-claiming.

 

 

Section 4.

 

 

BEFORE

Validation of signed resource data using a signing key that is

certified in a resource certificate, coupled with a specific set of

number resources, consists of verifying that the digital signature of

the signed resource data is valid, using the public key that is

certified by the resource certificate, and also validating the

resource certificate in the context of the RPKI, using the path

validation process.

 

AFTER

(Nothing, since the text seems to add nothing to the description of the alternative  path validation procedure.)

--------------060508090109060903040206-- From nobody Thu Mar 19 10:07:00 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 755C01A1B20 for ; Thu, 19 Mar 2015 10:06:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sImCXkSiODXN for ; Thu, 19 Mar 2015 10:06:57 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0750.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:750]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D6891A1AFC for ; Thu, 19 Mar 2015 10:06:57 -0700 (PDT) Received: from DM2PR09MB0286.namprd09.prod.outlook.com (25.160.96.143) by DM2PR09MB0287.namprd09.prod.outlook.com (25.160.96.144) with Microsoft SMTP Server (TLS) id 15.1.112.19; Thu, 19 Mar 2015 17:06:37 +0000 Received: from DM2PR09MB0286.namprd09.prod.outlook.com ([25.160.96.143]) by DM2PR09MB0286.namprd09.prod.outlook.com ([25.160.96.143]) with mapi id 15.01.0118.021; Thu, 19 Mar 2015 17:06:37 +0000 From: "Borchert, Oliver" To: sidr list Thread-Topic: [sidr] WGLC for draft-ietf-sidr-rpki-rtr-rfc6810-bis-03 Thread-Index: AQHQV+8ZoLfZHuZye0y1FFsltBIAFZ0gKsSAgAOwagA= Date: Thu, 19 Mar 2015 17:06:37 +0000 Message-ID: References: <729d38908098b3cb55910eaf98fb346a@mail.mandelberg.org> In-Reply-To: <729d38908098b3cb55910eaf98fb346a@mail.mandelberg.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.8.150116 x-originating-ip: [129.6.140.59] authentication-results: ietf.org; dkim=none (message not signed) header.d=none; x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DM2PR09MB0287; x-forefront-antispam-report: BMV:1; SFV:NSPM; SFS:(10019020)(6009001)(30584003)(99286002)(36756003)(106116001)(107886001)(87936001)(77156002)(230783001)(62966003)(102836002)(86362001)(2656002)(83506001)(450100001)(92566002)(46102003)(110136001)(66066001)(2900100001)(76176999)(54356999)(2950100001)(122556002)(50986999)(40100003); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR09MB0287; H:DM2PR09MB0286.namprd09.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5002010)(5005006); SRVR:DM2PR09MB0287; BCL:0; PCL:0; RULEID:; SRVR:DM2PR09MB0287; x-forefront-prvs: 052017CAF1 Content-Type: text/plain; charset="us-ascii" Content-ID: <48431529F76CED428D721A8634C69BA8@namprd09.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Mar 2015 17:06:37.3900 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR09MB0287 Archived-At: Subject: Re: [sidr] WGLC for draft-ietf-sidr-rpki-rtr-rfc6810-bis-03 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Mar 2015 17:06:59 -0000 I reviewed this draft and examining section 5.10 Router Key, I noticed that the format/encoding on the wire of the key is not specified.=20 The required format/encoding of the key e.g. DER is needed to assure a correct implementation and interoperability. Oliver ------------------------------------------------------------- Oliver Borchert, Computer Scientist National Institute of Standards and Technology (Phone) 301.975.4856 , (Fax) 301.975.6238 From nobody Thu Mar 19 14:44:31 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EF851AD0A8 for ; Thu, 19 Mar 2015 14:44:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7MQMg2Grd4um for ; Thu, 19 Mar 2015 14:44:29 -0700 (PDT) Received: from walnut.tislabs.com (walnut.tislabs.com [192.94.214.200]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 879321AD0A5 for ; Thu, 19 Mar 2015 14:44:29 -0700 (PDT) Received: from nova.tislabs.com (unknown [10.66.1.77]) by walnut.tislabs.com (Postfix) with ESMTP id DE8B628B0017 for ; Thu, 19 Mar 2015 17:44:28 -0400 (EDT) Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1]) by nova.tislabs.com (Postfix) with ESMTP id C7DC71F8035; Thu, 19 Mar 2015 17:44:28 -0400 (EDT) From: Sandra Murphy Content-Type: multipart/signed; boundary="Apple-Mail=_EA939AB2-8575-4A69-A4AD-62C308624013"; protocol="application/pgp-signature"; micalg=pgp-sha512 Date: Thu, 19 Mar 2015 17:44:29 -0400 Message-Id: To: "sidr@ietf.org list" Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) X-Mailer: Apple Mail (2.1510) Archived-At: Cc: Sandra Murphy Subject: [sidr] minutes taker and jabber scribe volunteers X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Mar 2015 21:44:30 -0000 --Apple-Mail=_EA939AB2-8575-4A69-A4AD-62C308624013 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Our meeting is Monday morning. The meeting can not begin unless we have = a minutes taker and a jabber scribe. Anyone who is willing to volunteer for either role, send a message to = sidr-chairs@ietf.org. --Sandy --Apple-Mail=_EA939AB2-8575-4A69-A4AD-62C308624013 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJVC0M+AAoJEHplpQeet0IZ64sP/jd/bWT2H2jfY2ai8SNGx1HT xAU8Mc7l1lOQK5PoMAo8irlB+ojY1PhCmB58S4br1DyETQlnHP3XWRVzw/9abwNI XY2NNVyn353L0ZtLPjG05q6swPV3BZUZn8Da+0/JhpCsewHgfj0eF/+C4xVNbvXL Emi2T7LPMNqyBdBchzViUEPqOUP7vLvNdg7I0gvOLJbsS1+DOhWaunclWXIQDsEc 9f+f8wcfDyIqiDiHuS7VpHuOA2SchjxIkUzMIUGY8CcAIZwoVTUqWcRGMs6wrmjI y7NBRWIgWxzSsjOYIJwkFSTR7Sqgr2XnyryKhsWp0xzoHiKHkeRYisDzqlRh0QRI x/hut66oDH8Q9UJcmxBSUtRzxjdFoZqRkIPh5wqI5tdF3hpUZG/1CGzfpabSrwHs xMmjP4QON8i6UAm94SDaZ1/5cpGhPR/Ky+Ne/2oDb98W5hPGib06nZIvylZM031p LsylsFDz5Qy1Uf9xyh27Kw07fxqtkUXVcfT5C6vUVRTgTQzgWTFubpi7BUMWVYv3 5zbfyWt2c/kMoGwFMvzL680E/ERLtlIQ9ydIi9ojw/9jTIghNW7dtktGoS7X4iDs /MrNRw7H1wzebcMf4D3tmUfpUwkADpx4sG6A22YSmV0tmWmSkg87Fw3ERBnEZREK 4QSzs8vHFYgoL0IPrPdL =RqhI -----END PGP SIGNATURE----- --Apple-Mail=_EA939AB2-8575-4A69-A4AD-62C308624013-- From nobody Thu Mar 19 15:22:46 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C389A1A90EA for ; Thu, 19 Mar 2015 15:22:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.098 X-Spam-Level: X-Spam-Status: No, score=0.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FSL_HELO_BARE_IP_2=1.999, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SyJiEnqN6vL7 for ; Thu, 19 Mar 2015 15:22:44 -0700 (PDT) Received: from gateway05.websitewelcome.com (gateway05.websitewelcome.com [64.5.38.5]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0AD421A88E4 for ; Thu, 19 Mar 2015 15:22:44 -0700 (PDT) Received: by gateway05.websitewelcome.com (Postfix, from userid 5007) id 6FEC3AE1BACAD; Thu, 19 Mar 2015 17:22:43 -0500 (CDT) Received: from gator3286.hostgator.com (gator3286.hostgator.com [198.57.247.250]) by gateway05.websitewelcome.com (Postfix) with ESMTP id 61C75AE1BAC6B for ; Thu, 19 Mar 2015 17:22:43 -0500 (CDT) Received: from [96.231.226.227] (port=62806 helo=192.168.1.8) by gator3286.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1YYipu-0001Pz-OH; Thu, 19 Mar 2015 17:22:42 -0500 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Sean Turner In-Reply-To: <54FE43E5.8020705@bbn.com> Date: Thu, 19 Mar 2015 18:22:40 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20150309225648.27496.13505.idtracker@ietfa.amsl.com> <54FE43E5.8020705@bbn.com> To: Richard Hansen X-Mailer: Apple Mail (2.1878.6) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator3286.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-IP: 96.231.226.227 X-Exim-ID: 1YYipu-0001Pz-OH X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: (192.168.1.8) [96.231.226.227]:62806 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 4 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IzMjg2Lmhvc3RnYXRvci5jb20= Archived-At: Cc: sidr@ietf.org Subject: Re: [sidr] New Version Notification for draft-rhansen-sidr-rfc6487bis-00.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Mar 2015 22:22:45 -0000 On Mar 09, 2015, at 21:07, Richard Hansen wrote: > Hi all, >=20 > I have submitted a bis of RFC6487 as a -00 individual submission, and > will be presenting it in Dallas. >=20 > It's a minor change from RFC6487. Changes incorporated: > * all 3 verified errata Faithfully includes the errata I submitted ;) > * RFC 7318 (update) > * two changes that were submitted as errata but rejected for being > technical changes: > http://www.rfc-editor.org/errata_search.php?rfc=3D6487&rec_status=3D9= >=20 > Comments welcome. I=92ll caveat this by saying I am definitely not hard over on this, but = I thought I=92d bring it up: Should we switch to a SHA-256-based key = identifier? s4.8.3 includes the following text: The Key Identifier used for resource certificates is the 160-bit SHA-1 hash of the value of the DER-encoded ASN.1 bit string of the issuer's public key, as described in Section 4.2.1.1 of [RFC5280]. Well now there=92s RFC 7093 (http://datatracker.ietf.org/doc/rfc7093/) = and we could point there and generate an identifier based on SHA-256. = Full disclosure: this would introduce a downref to the document; the RFC = was published through the ISE. spt > Thanks, > Richard >=20 >=20 > -------- Forwarded Message -------- > Subject: New Version Notification for = draft-rhansen-sidr-rfc6487bis-00.txt > Date: Mon, 09 Mar 2015 15:56:48 -0700 > From: internet-drafts@ietf.org > To: Richard Hansen , Andrew Newton , > Robert Loomans , Geoff Huston > , George Michaelson >=20 >=20 > A new version of I-D, draft-rhansen-sidr-rfc6487bis-00.txt > has been successfully submitted by Richard Hansen and posted to the > IETF repository. >=20 > Name: draft-rhansen-sidr-rfc6487bis > Revision: 00 > Title: A Profile for X.509 PKIX Resource Certificates > Document date: 2015-03-09 > Group: Individual Submission > Pages: 32 > URL: > = http://www.ietf.org/internet-drafts/draft-rhansen-sidr-rfc6487bis-00.txt > Status: > https://datatracker.ietf.org/doc/draft-rhansen-sidr-rfc6487bis/ > Htmlized: = http://tools.ietf.org/html/draft-rhansen-sidr-rfc6487bis-00 >=20 >=20 > Abstract: > This document defines a standard profile for X.509 certificates for > the purpose of supporting validation of assertions of "right-of-use" > of Internet Number Resources (INRs). The certificates issued under > this profile are used to convey the issuer's authorization of the > subject to be regarded as the current holder of a "right-of-use" of > the INRs that are described in the certificate. This document > contains the normative specification of Certificate and Certificate > Revocation List (CRL) syntax in the Resource Public Key > Infrastructure (RPKI). This document also specifies profiles for = the > format of certificate requests and specifies the Relying Party RPKI > certificate path validation procedure. >=20 > This document obsoletes RFC 6487. >=20 >=20 >=20 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > The IETF Secretariat >=20 >=20 >=20 > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr From nobody Fri Mar 20 04:01:22 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8F681B2CC7 for ; Fri, 20 Mar 2015 04:01:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gjt-lRiKq4gE for ; Fri, 20 Mar 2015 04:01:18 -0700 (PDT) Received: from walnut.tislabs.com (walnut.tislabs.com [192.94.214.200]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 907291B2C56 for ; Fri, 20 Mar 2015 04:01:18 -0700 (PDT) Received: from nova.tislabs.com (unknown [10.66.1.77]) by walnut.tislabs.com (Postfix) with ESMTP id E8A8B28B003D for ; Fri, 20 Mar 2015 07:01:17 -0400 (EDT) Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1]) by nova.tislabs.com (Postfix) with ESMTP id BFF1C1F8035; Fri, 20 Mar 2015 07:01:17 -0400 (EDT) From: Sandra Murphy Content-Type: multipart/signed; boundary="Apple-Mail=_79C255A6-EEC6-4189-892F-AA879D82D45C"; protocol="application/pgp-signature"; micalg=pgp-sha512 Date: Fri, 20 Mar 2015 07:01:19 -0400 Message-Id: <7FA2CD31-3540-45DC-BD53-546BBCB47523@tislabs.com> To: "sidr@ietf.org list" Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) X-Mailer: Apple Mail (2.1510) Archived-At: Cc: Sandra Murphy Subject: [sidr] agenda and slides updated X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Mar 2015 11:01:20 -0000 --Apple-Mail=_79C255A6-EEC6-4189-892F-AA879D82D45C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii An updated agenda and slides have been posted. Thanks to those who have submitted their slides. (Brian Haberman was = first getting his submitted - a gold star to Brian!) --Sandy --Apple-Mail=_79C255A6-EEC6-4189-892F-AA879D82D45C Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJVC/3/AAoJEHplpQeet0IZoUEP/3VtUAmAhYB7+5czjlXTylY4 k4jGsL6F9jSDlGmDqeqc8mr3vpu/Pj0+6Ut/0iZTZ6mXidhUZ8f31TBJSk93FiBr 3nby4h3/9leznw+l7QkOmGL1gk30SKzHvdnxaWpsPOKIXLz5s/ho+kAxKjS9dqxI ixDkAHafFUZ+RTt+2StiSwk6Tfdit6AninXKm2t/FeWr6VKxLCmsSsjLJh+Nhd2I JdIOFDNR1ivUJPu4/wRoOhLWtGr2OSKkdf0ulhoNMdqRKIC0Tnhq0pzxGJ1LHays jgWss1JQtpV3MeyWG8LvdJa/fzxe+r5zKSkG5cSVFTdFxRulGPVbaU+R0+ZEoFGV wnXRuM848Rd8Aco6au6KNWSG4CBA0Q1t4wK9LRyIjJhjfuqJlJtmLJsU0uLa98mw sv2xXriqaEJIRA3XZkFZf81NT9SjYIOyvtKWx2bb11P19lQ4fhVO6C9qtO1r/hZR Kr9vl/Lr2LSjvb5m4rWDzOd+z2ZUntBuuFljiua4qrwgdtwtrKHzSSlhIa0MMZDS pvVmRfZiMFOqUcT35uvKaUx/nCTYGiXrvrnCcK4lHQXlDkLDTAHSBkUSiWGXu2ma iDzU6B3h651Mm7TJE0YM7FP6xUGgOKZ0Decis92AjMZ5arGJsxf+Prx5Hmh6DTaS ovcIowKx9L2Zswa4sOsT =3xBV -----END PGP SIGNATURE----- --Apple-Mail=_79C255A6-EEC6-4189-892F-AA879D82D45C-- From nobody Fri Mar 20 08:03:13 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6885B1A01EA for ; Fri, 20 Mar 2015 08:03:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q0dkEn13hxad for ; Fri, 20 Mar 2015 08:03:10 -0700 (PDT) Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C6E61AC3E4 for ; Fri, 20 Mar 2015 08:03:10 -0700 (PDT) Received: from pool-74-96-106-79.washdc.fios.verizon.net ([74.96.106.79] helo=[192.168.1.13]) by mho-01-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1YYyS5-0005Fc-Bm; Fri, 20 Mar 2015 15:03:09 +0000 X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 74.96.106.79 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX196CoXM1JZwCbpiwsYEvZ7h Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: John Curran In-Reply-To: <550AE49C.9010207@bbn.com> Date: Fri, 20 Mar 2015 11:03:07 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <9DD8F125-0302-4D39-8110-38F6D1460F71@istaff.org> References: <550AE49C.9010207@bbn.com> To: Stephen Kent X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: sidr Subject: Re: [sidr] comments on validation revisited -01 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Mar 2015 15:03:12 -0000 On Mar 19, 2015, at 11:00 AM, Stephen Kent wrote: > ... > For example, the importance of addressing this issue would be clearer = if there were statistics detailing the number of INR transfers, by = region, for the past few years.=20 Steve -=20 That information might indeed be useful in understanding the potential=20= importance of the issue historically, but would not be an indication of=20= the need going forward unless one presumes that the demands in the past=20= for transfers reflects the future rate of transfers - this quite = unlikely=20 given that some RIRs (e.g. ARIN) are about to run out of their regional = IPv4=20 free pool, which will result in significantly more folks going to the = market=20 to meet their needs... (If you are curious about the historical = statistics on=20 IPv4 transfers, I believe that each of the RIRs have this on their web = site,=20 ARIN=E2=80=99s is here - = ) FYI, /John From nobody Fri Mar 20 10:35:54 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 059F91A7032 for ; Fri, 20 Mar 2015 10:35:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.011 X-Spam-Level: X-Spam-Status: No, score=-5.011 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xMGILTzGtIuG for ; Fri, 20 Mar 2015 10:35:45 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [198.180.150.18]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1344F1A7023 for ; Fri, 20 Mar 2015 10:35:45 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.82) (envelope-from ) id 1YZ0pi-0002wx-Fr; Fri, 20 Mar 2015 17:35:42 +0000 Date: Fri, 20 Mar 2015 12:35:42 -0500 Message-ID: From: Randy Bush To: Sean Turner In-Reply-To: References: <20150309225648.27496.13505.idtracker@ietfa.amsl.com> <54FE43E5.8020705@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.7 - "Harue") Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: sidr wg list Subject: Re: [sidr] New Version Notification for draft-rhansen-sidr-rfc6487bis-00.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Mar 2015 17:35:46 -0000 > I=E2=80=99ll caveat this by saying I am definitely not hard over on this,= but > I thought I=E2=80=99d bring it up: Should we switch to a SHA-256-based key > identifier? all the kool kids are doing that randy From nobody Fri Mar 20 11:10:42 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 186F61A1EEA for ; Fri, 20 Mar 2015 11:10:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.611 X-Spam-Level: X-Spam-Status: No, score=-3.611 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_26=0.6, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NEO4bPDHDjxr for ; Fri, 20 Mar 2015 11:10:39 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 711471A1A91 for ; Fri, 20 Mar 2015 11:10:39 -0700 (PDT) Received: from ssh.bbn.com ([192.1.122.15]:48032 helo=COMSEC.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1YZ1NV-000LWF-Th; Fri, 20 Mar 2015 14:10:38 -0400 Message-ID: <550C629D.8050907@bbn.com> Date: Fri, 20 Mar 2015 14:10:37 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: John Curran References: <550AE49C.9010207@bbn.com> <9DD8F125-0302-4D39-8110-38F6D1460F71@istaff.org> In-Reply-To: <9DD8F125-0302-4D39-8110-38F6D1460F71@istaff.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: sidr Subject: Re: [sidr] comments on validation revisited -01 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Mar 2015 18:10:41 -0000 John, > Steve - That information might indeed be useful in understanding the > potential importance of the issue historically, but would not be an > indication of the need going forward unless one presumes that the > demands in the past for transfers reflects the future rate of > transfers - this quite unlikely given that some RIRs (e.g. ARIN) are > about to run out of their regional IPv4 free pool, which will result > in significantly more folks going to the market to meet their needs... > (If you are curious about the historical statistics on IPv4 transfers, > I believe that each of the RIRs have this on their web site, ARIN’s is > here - ) > FYI, /John I agree that the frequency of v4 resources might change as a result of exhaustion of that space on a regional level. A cursory look at the transfers listed at the URL you provided would support that projection. But, I'm especially interested seeing which transfers are for live vs.unused space, since the implications for the ordering of events are very different. I don't see that info on this page. We also need a sense of how many CAs would have been involved in previous transfers, as an indication of how complex the transfer procedure will be in the RPKI. Steve From nobody Fri Mar 20 12:48:29 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 090661B301B for ; Fri, 20 Mar 2015 12:48:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tp3av3fuVk89 for ; Fri, 20 Mar 2015 12:48:27 -0700 (PDT) Received: from kaka.ripe.net (kaka.ripe.net [IPv6:2001:67c:2e8:11::c100:1347]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 82C941B301E for ; Fri, 20 Mar 2015 12:48:27 -0700 (PDT) Received: from titi.ripe.net ([193.0.23.11]) by kaka.ripe.net with esmtps (UNKNOWN:AES256-GCM-SHA384:256) (Exim 4.72) (envelope-from ) id 1YZ2u9-0006ZM-8J for sidr@ietf.org; Fri, 20 Mar 2015 20:48:26 +0100 Received: from gibbon.ripe.net ([193.0.1.206] helo=[0.0.0.0]) by titi.ripe.net with esmtp (Exim 4.72) (envelope-from ) id 1YZ2u9-0000ih-5L for sidr@ietf.org; Fri, 20 Mar 2015 20:48:25 +0100 Message-ID: <550C7989.8020104@ripe.net> Date: Fri, 20 Mar 2015 20:48:25 +0100 From: Robert Kisteleki Organization: RIPE NCC User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: sidr wg list References: <20150309225648.27496.13505.idtracker@ietfa.amsl.com> <54FE43E5.8020705@bbn.com> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit 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: 72e00e6d7601fa19264e98abc238a2742311995bfeeb0ffc4e2627d3d2a96073 Archived-At: Subject: Re: [sidr] New Version Notification for draft-rhansen-sidr-rfc6487bis-00.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Mar 2015 19:48:29 -0000 On 2015-03-20 18:35, Randy Bush wrote: >> I’ll caveat this by saying I am definitely not hard over on this, but >> I thought I’d bring it up: Should we switch to a SHA-256-based key >> identifier? > > all the kool kids are doing that > > randy That's nice, but can someone explain what the actual benefit would be? Robert From nobody Fri Mar 20 13:20:46 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1E291A8F3F for ; Fri, 20 Mar 2015 13:20:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.31 X-Spam-Level: X-Spam-Status: No, score=-1.31 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_12=0.6, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0hFejM07-UfS for ; Fri, 20 Mar 2015 13:20:42 -0700 (PDT) Received: from cyteen.hactrn.net (cyteen.hactrn.net [66.92.66.68]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A2EA91A8BC2 for ; Fri, 20 Mar 2015 13:20:42 -0700 (PDT) Received: from minas-ithil.hactrn.net (c-24-34-34-101.hsd1.ma.comcast.net [24.34.34.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "nargothrond.hactrn.net", Issuer "Grunchweather Associates" (verified OK)) by cyteen.hactrn.net (Postfix) with ESMTPS id 6CBAD4FB3 for ; Fri, 20 Mar 2015 20:20:40 +0000 (UTC) Received: from minas-ithil.hactrn.net (localhost [IPv6:::1]) by minas-ithil.hactrn.net (Postfix) with ESMTP id AD85316CF60F for ; Fri, 20 Mar 2015 16:20:41 -0400 (EDT) Date: Fri, 20 Mar 2015 16:20:41 -0400 From: Rob Austein To: sidr wg list In-Reply-To: References: <20150309225648.27496.13505.idtracker@ietfa.amsl.com> <54FE43E5.8020705@bbn.com> User-Agent: Wanderlust/2.15.5 (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=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Message-Id: <20150320202041.AD85316CF60F@minas-ithil.hactrn.net> Archived-At: Subject: Re: [sidr] New Version Notification for draft-rhansen-sidr-rfc6487bis-00.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Mar 2015 20:20:44 -0000 At Fri, 20 Mar 2015 12:35:42 -0500, Randy Bush wrote: >=20 > > I?ll caveat this by saying I am definitely not hard over on this, but > > I thought I?d bring it up: Should we switch to a SHA-256-based key > > identifier? >=20 > all the kool kids are doing that Not sure it's worth making an incompatible change. The key identifier isn't used for integrity checks, it's just the name of a sort of virtual hash bucket which we use as one of the criteria for pruning irrelevant candidate objects before we get all the way to doing expensive signature checks. An attacker can achieve the same effect just by inserting whatever attack string seems interesting in the key identifier field, regardless of digest algorithm, unless validation code also computes the key identifier digest itself and checks that digest against the key identifier of the object under inspection. My understanding is that all the current validation implementations do in fact check key identifier digests (mostly because BBN's creatively evil test suite whines at us if we don't detect such errors), which is both good and bad: it's good, because it makes the DoS attack described above harder (more precisely, it trades a small increase in the known fixed cost per object against the risk of the DoS attack), but it's bad because all this code knows which digest algorithm we're using to generate key identifiers and will care if we change that algorithm, rather than treating key identifiers as an opaque blobs. From nobody Fri Mar 20 16:28:31 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98B061A90B6 for ; Fri, 20 Mar 2015 16:28:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RD0oZMyPe0qI for ; Fri, 20 Mar 2015 16:28:25 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0135.outbound.protection.outlook.com [207.46.100.135]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 48B881A90B5 for ; Fri, 20 Mar 2015 16:28:25 -0700 (PDT) Received: from DM2PR09MB0288.namprd09.prod.outlook.com (25.160.96.145) by DM2PR09MB0716.namprd09.prod.outlook.com (25.161.145.13) with Microsoft SMTP Server (TLS) id 15.1.118.21; Fri, 20 Mar 2015 23:28:22 +0000 Received: from DM2PR09MB0286.namprd09.prod.outlook.com (25.160.96.143) by DM2PR09MB0288.namprd09.prod.outlook.com (25.160.96.145) with Microsoft SMTP Server (TLS) id 15.1.118.21; Fri, 20 Mar 2015 23:28:20 +0000 Received: from DM2PR09MB0286.namprd09.prod.outlook.com ([25.160.96.143]) by DM2PR09MB0286.namprd09.prod.outlook.com ([25.160.96.143]) with mapi id 15.01.0118.021; Fri, 20 Mar 2015 23:28:19 +0000 From: "Borchert, Oliver" To: sidr list Thread-Topic: NIST BGP-SRx / QuaggaSRX Release 0.4.1 Thread-Index: AQHQY2WMNCWTunUGBE+pt/MIzQ3pJg== Date: Fri, 20 Mar 2015 23:28:19 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.8.150116 x-originating-ip: [129.6.140.59] authentication-results: ietf.org; dkim=none (message not signed) header.d=none; x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:; SRVR:DM2PR09MB0288; UriScan:; BCL:0; PCL:0; RULEID:; SRVR:DM2PR09MB0716; x-microsoft-antispam-prvs: x-forefront-antispam-report: BMV:1; SFV:NSPM; SFS:(10019020)(53754006)(52044002)(124975003)(164054003)(30584003)(106116001)(16236675004)(99286002)(92566002)(107886001)(110136001)(229853001)(16601075003)(87936001)(66066001)(2656002)(83506001)(19580405001)(19580395003)(19617315012)(102836002)(50986999)(54356999)(62966003)(77156002)(86362001)(2900100001)(122556002)(36756003)(46102003)(15975445007)(7059030); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR09MB0288; H:DM2PR09MB0286.namprd09.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(5002010); SRVR:DM2PR09MB0288; BCL:0; PCL:0; RULEID:; SRVR:DM2PR09MB0288; x-forefront-prvs: 05214FD68E Content-Type: multipart/alternative; boundary="_000_D1322550220A0oliverborchertnistgov_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Mar 2015 23:28:19.6933 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR09MB0288 X-OriginatorOrg: nist.gov Archived-At: Subject: [sidr] NIST BGP-SRx / QuaggaSRX Release 0.4.1 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Mar 2015 23:28:30 -0000 --_000_D1322550220A0oliverborchertnistgov_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi all, I wanted to announce a new release V0.4.1 of QuaggaSRx/BGP-SRx which Adds BGPSEC path validation. QuaggaSRx is based on Quagga V0.99.22 and is available as tar ball or via 'yum'. http://bgpsrx.antd.nist.gov Please note that the software is still under development. If you have any questions feel free to email me or the dev team at bgpsrx-dev@nist.gov Thanks, Oliver ------------------------------------------------------------- Oliver Borchert, Computer Scientist National Institute of Standards and Technology (Phone) 301.975.4856 , (Fax) 301.975.6238 --_000_D1322550220A0oliverborchertnistgov_ Content-Type: text/html; charset="iso-8859-1" Content-ID: <050FB32083C4324F9C0C567916575F54@namprd09.prod.outlook.com> Content-Transfer-Encoding: quoted-printable
Hi all,

I wanted to announ= ce a new release V0.4.1 of QuaggaSRx/BGP-SRx which 
Adds BGPSEC path v= alidation. QuaggaSRx is based on Quagga V0.99.22 
and is available a= s tar ball or via ‘yum’.


Please note that t= he software is still under development. If you have any 
questions feel fre= e to email me or the dev team at bgpsrx-dev@nist.gov

Thanks,
Oliver

-------------------------------------------------------------
Oliver Borchert, Computer Scientist
National Institute of Standards and Technology
(Phone) 301.975.4856 , (Fax) 301.975.6238
--_000_D1322550220A0oliverborchertnistgov_-- From nobody Sat Mar 21 03:10:21 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB5291A9155 for ; Sat, 21 Mar 2015 03:10:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.911 X-Spam-Level: X-Spam-Status: No, score=-13.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_12=0.6, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XWcoGTjRHkOz for ; Sat, 21 Mar 2015 03:10:15 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 276601A9154 for ; Sat, 21 Mar 2015 03:10:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2400; q=dns/txt; s=iport; t=1426932615; x=1428142215; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=YH8dZaM2Nc8XQwQVuDJYKsWcf4TN1UASaQb/nyrC9JA=; b=MoARQENQuabpACzHFwUDm/rCuqt8OaMMydaPmrrrEU7vh/0A/syEph8Y H3oGpk8WCBbD+fsEnqBCa/UsgRPzZurnRWElDC43uWyyXqmU7MWTcJMMz fa2Ga3bg1LSxMrnoiJiInOzSUMo+4M4ffRsC4bdRjpUuTO2nH81nvP89u M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0CzBgCZQg1V/4YNJK1cgwZSWgTENYIwCoV1AoEoTAEBAQEBAX2EFQEBBAEBATc0CRICAQgOCh4QJwslAgQBEogvDcsnAQEBAQEBAQEBAQEBAQEBAQEBAQEBEwSLIYR8hC0BBJBPiW6BG49Ig0ciHoFjHYFQb4EEJBx/AQEB X-IronPort-AV: E=Sophos;i="5.11,442,1422921600"; d="scan'208";a="405500087" Received: from alln-core-12.cisco.com ([173.36.13.134]) by rcdn-iport-7.cisco.com with ESMTP; 21 Mar 2015 10:10:14 +0000 Received: from xhc-aln-x03.cisco.com (xhc-aln-x03.cisco.com [173.36.12.77]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id t2LAAE4n025847 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 21 Mar 2015 10:10:14 GMT Received: from xmb-rcd-x02.cisco.com ([169.254.4.91]) by xhc-aln-x03.cisco.com ([173.36.12.77]) with mapi id 14.03.0195.001; Sat, 21 Mar 2015 05:10:14 -0500 From: "Roque Gagliano (rogaglia)" To: Rob Austein , sidr wg list Thread-Topic: [sidr] New Version Notification for draft-rhansen-sidr-rfc6487bis-00.txt Thread-Index: AQHQY784sYNqTmmaxUeWVVayadqGIw== Date: Sat, 21 Mar 2015 10:10:13 +0000 Message-ID: References: <20150309225648.27496.13505.idtracker@ietfa.amsl.com> <54FE43E5.8020705@bbn.com> <20150320202041.AD85316CF60F@minas-ithil.hactrn.net> In-Reply-To: <20150320202041.AD85316CF60F@minas-ithil.hactrn.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.5.141003 x-originating-ip: [10.61.111.185] Content-Type: text/plain; charset="us-ascii" Content-ID: <137A8E11ABDE9C4A915ADAA463D1C59E@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [sidr] New Version Notification for draft-rhansen-sidr-rfc6487bis-00.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Mar 2015 10:10:20 -0000 On 20/03/15 21:20, "Rob Austein" wrote: >At Fri, 20 Mar 2015 12:35:42 -0500, Randy Bush wrote: >>=20 >> > I?ll caveat this by saying I am definitely not hard over on this, but >> > I thought I?d bring it up: Should we switch to a SHA-256-based key >> > identifier? >>=20 >> all the kool kids are doing that > >Not sure it's worth making an incompatible change. We may be facing problems when trying to certify RPKI software inside real customers. My experience with customers such as banks and some BGP networks (think about SWIFT) is that their security check-list is very-very hardcoded. If you have a non-compliance, it will delay your project for months/years and will add a lot of grey hairs to the project teams. So, if SHA-1 is officially deprecated (or de-facto as it is happening now) and makes it to these security-compliance check-lists, we will have no alternative from a practical view if we want people to use the technology (even if it does not introduce real enhancements.) Roque > >The key identifier isn't used for integrity checks, it's just the name >of a sort of virtual hash bucket which we use as one of the criteria >for pruning irrelevant candidate objects before we get all the way to >doing expensive signature checks. An attacker can achieve the same >effect just by inserting whatever attack string seems interesting in >the key identifier field, regardless of digest algorithm, unless >validation code also computes the key identifier digest itself and >checks that digest against the key identifier of the object under >inspection. > >My understanding is that all the current validation implementations do >in fact check key identifier digests (mostly because BBN's creatively >evil test suite whines at us if we don't detect such errors), which is >both good and bad: it's good, because it makes the DoS attack >described above harder (more precisely, it trades a small increase in >the known fixed cost per object against the risk of the DoS attack), >but it's bad because all this code knows which digest algorithm we're >using to generate key identifiers and will care if we change that >algorithm, rather than treating key identifiers as an opaque blobs. > >_______________________________________________ >sidr mailing list >sidr@ietf.org >https://www.ietf.org/mailman/listinfo/sidr From nobody Sun Mar 22 07:42:32 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31DA61AC529 for ; Sun, 22 Mar 2015 07:42:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.811 X-Spam-Level: X-Spam-Status: No, score=-2.811 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gatSlu6XCTLN for ; Sun, 22 Mar 2015 07:42:27 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D3CF11AC449 for ; Sun, 22 Mar 2015 07:42:27 -0700 (PDT) Received: from ssh.bbn.com ([192.1.122.15]:52697 helo=dhcp-b485.meeting.ietf.org) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1YZh58-0006SI-8c; Sun, 22 Mar 2015 10:42:26 -0400 Message-ID: <550ED4D1.3060506@bbn.com> Date: Sun, 22 Mar 2015 10:42:25 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: John Curran , sidr Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [sidr] another though re xfers X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Mar 2015 14:42:29 -0000 John, Looking at the ARIN xfer stats a few additional questions come to mind: - are most/all of the ARIN -> APNIC transfers sales of unused address space? - are many/most of the internal transfers the result of organizational changes and thus involve live address space? - would most of the transfers to APNIC involve only ARIN and APNIC as parent CAs? - would most of the intra-ARIN transfers have ARIN as the common parent Steve From nobody Sun Mar 22 11:03:18 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E11C1A000E for ; Sun, 22 Mar 2015 11:03:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.799 X-Spam-Level: X-Spam-Status: No, score=0.799 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8i-t8BmnL3_p for ; Sun, 22 Mar 2015 11:03:15 -0700 (PDT) Received: from relay.mailchannels.net (si-002-i69.relay.mailchannels.net [184.154.112.243]) by ietfa.amsl.com (Postfix) with ESMTP id 3ADCA1A0004 for ; Sun, 22 Mar 2015 11:03:14 -0700 (PDT) X-Sender-Id: duocircle|x-authuser|jcurran Received: from smtp1.ore.mailhop.org (ip-10-237-13-110.us-west-2.compute.internal [10.237.13.110]) by relay.mailchannels.net (Postfix) with ESMTPA id 614EF60A30; Sun, 22 Mar 2015 18:03:10 +0000 (UTC) X-Sender-Id: duocircle|x-authuser|jcurran Received: from smtp1.ore.mailhop.org (smtp1.ore.mailhop.org [10.83.15.107]) (using TLSv1 with cipher DHE-RSA-AES256-SHA) by 0.0.0.0:2500 (trex/5.4.8); Sun, 22 Mar 2015 18:03:11 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: duocircle|x-authuser|jcurran X-MailChannels-Auth-Id: duocircle X-MC-Loop-Signature: 1427047390492:3978850459 X-MC-Ingress-Time: 1427047390492 Received: from pool-74-96-106-79.washdc.fios.verizon.net ([74.96.106.79] helo=[192.168.1.13]) by smtp1.ore.mailhop.org with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.82) (envelope-from ) id 1YZkDO-00042u-3h; Sun, 22 Mar 2015 18:03:10 +0000 X-Mail-Handler: DuoCircle Outbound SMTP X-Originating-IP: 74.96.106.79 X-Report-Abuse-To: abuse@duocircle.com (see https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information for abuse reporting information) X-MHO-User: U2FsdGVkX18+Gci0UMylImHGMMqePsFE Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: John Curran In-Reply-To: <550ED4D1.3060506@bbn.com> Date: Sun, 22 Mar 2015 14:03:11 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <29BB6F59-938B-4909-A7E7-32AB55CC9991@istaff.org> References: <550ED4D1.3060506@bbn.com> To: Stephen Kent X-Mailer: Apple Mail (2.2070.6) X-AuthUser: jcurran Archived-At: Cc: sidr Subject: Re: [sidr] another though re xfers X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Mar 2015 18:03:17 -0000 On Mar 22, 2015, at 10:42 AM, Stephen Kent wrote: >=20 > John, >=20 > Looking at the ARIN xfer stats a few additional questions come to = mind: >=20 > - are most/all of the ARIN -> APNIC transfers sales of unused = address space? I'd expect it almost all to be unused at time of transfer (save transfers between organizational elements of single company),=20 but some of the blocks very clearly have been in use before any transfer (typically lightly utilized, e.g. /19 of a /16 block) > - are many/most of the internal transfers the result of = organizational changes > and thus involve live address space? These are fairly common occurrence, as organizations work to=20 move address space among business units that need such. > - would most of the transfers to APNIC involve only ARIN and APNIC = as > parent CAs? At this time, yes. We don't see a lot of organizations running their own CA, but clearly that could change in the future. > - would most of the intra-ARIN transfers have ARIN as the common = parent Yes, I would expect that to be the case, at least for the immediate = future. Thanks, /John John Curran President and CEO ARIN From nobody Sun Mar 22 11:18:14 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 763181A001A for ; Sun, 22 Mar 2015 11:18:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.301 X-Spam-Level: X-Spam-Status: No, score=-1.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_26=0.6, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TtdVw1LeqvYw for ; Sun, 22 Mar 2015 11:18:12 -0700 (PDT) Received: from relay.mailchannels.net (aso-006-i434.relay.mailchannels.net [23.91.64.115]) by ietfa.amsl.com (Postfix) with ESMTP id D1DF31A0018 for ; Sun, 22 Mar 2015 11:18:11 -0700 (PDT) X-Sender-Id: duocircle|x-authuser|jcurran Received: from smtp4.ore.mailhop.org (ip-10-237-13-110.us-west-2.compute.internal [10.237.13.110]) by relay.mailchannels.net (Postfix) with ESMTPA id 7D09312025D; Sun, 22 Mar 2015 18:18:09 +0000 (UTC) X-Sender-Id: duocircle|x-authuser|jcurran Received: from smtp4.ore.mailhop.org ([TEMPUNAVAIL]. [10.45.8.167]) (using TLSv1 with cipher DHE-RSA-AES256-SHA) by 0.0.0.0:2500 (trex/5.4.8); Sun, 22 Mar 2015 18:18:09 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: duocircle|x-authuser|jcurran X-MailChannels-Auth-Id: duocircle X-MC-Loop-Signature: 1427048289599:2261151106 X-MC-Ingress-Time: 1427048289599 Received: from pool-74-96-106-79.washdc.fios.verizon.net ([74.96.106.79] helo=[192.168.1.13]) by smtp4.ore.mailhop.org with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.82) (envelope-from ) id 1YZkRm-0006lA-3g; Sun, 22 Mar 2015 18:18:02 +0000 X-Mail-Handler: DuoCircle Outbound SMTP X-Originating-IP: 74.96.106.79 X-Report-Abuse-To: abuse@duocircle.com (see https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information for abuse reporting information) X-MHO-User: U2FsdGVkX19YR4h/L5eXXk8f5U+CQeWp Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: John Curran In-Reply-To: <550C629D.8050907@bbn.com> Date: Sun, 22 Mar 2015 14:18:03 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <5A5BA403-5D3E-4A0B-9CAB-DBAAEFCD085D@istaff.org> References: <550AE49C.9010207@bbn.com> <9DD8F125-0302-4D39-8110-38F6D1460F71@istaff.org> <550C629D.8050907@bbn.com> To: Stephen Kent X-Mailer: Apple Mail (2.2070.6) X-AuthUser: jcurran Archived-At: Cc: sidr Subject: Re: [sidr] comments on validation revisited -01 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Mar 2015 18:18:13 -0000 On Mar 20, 2015, at 2:10 PM, Stephen Kent wrote: >=20 > John, > I agree that the frequency of v4 resources might change as a result of = exhaustion > of that space on a regional level. A cursory look at the transfers = listed at the URL > you provided would support that projection. But, I'm especially = interested seeing > which transfers are for live vs.unused space, since the implications = for the > ordering of events are very different. I don't see that info on this = page. > ... Interesting question - this is not information that organizations need = to=20 supply to ARIN during the transfer request process (at least at ARIN), = so=20 it is not shown in the statistics. If someone wants to do little = analysis against routeviews/ripestat, it should be possible to derive such for = past =20 transfers. (I'd advise against optimizing future mechanisms based on = that=20 limited history, but it would still be interesting information to = have...) /John From nobody Sun Mar 22 12:49:00 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FD9C1A1A27 for ; Sun, 22 Mar 2015 12:48:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.311 X-Spam-Level: X-Spam-Status: No, score=-1.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_26=0.6, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4SnezUZilqc5 for ; Sun, 22 Mar 2015 12:48:56 -0700 (PDT) Received: from walnut.tislabs.com (walnut.tislabs.com [192.94.214.200]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 80B4F1A19F7 for ; Sun, 22 Mar 2015 12:48:56 -0700 (PDT) Received: from nova.tislabs.com (unknown [10.66.1.77]) by walnut.tislabs.com (Postfix) with ESMTP id B5BBD28B003D; Sun, 22 Mar 2015 15:48:55 -0400 (EDT) Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1]) by nova.tislabs.com (Postfix) with ESMTP id CE2AE1F8035; Sun, 22 Mar 2015 15:48:54 -0400 (EDT) Content-Type: multipart/signed; boundary="Apple-Mail=_2CEA091B-4DBC-4978-8083-69E0454220C7"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Sandra Murphy In-Reply-To: <5A5BA403-5D3E-4A0B-9CAB-DBAAEFCD085D@istaff.org> Date: Sun, 22 Mar 2015 15:48:56 -0400 Message-Id: <4566EEBB-0D73-497F-9B78-CE3C37C8A9E3@tislabs.com> References: <550AE49C.9010207@bbn.com> <9DD8F125-0302-4D39-8110-38F6D1460F71@istaff.org> <550C629D.8050907@bbn.com> <5A5BA403-5D3E-4A0B-9CAB-DBAAEFCD085D@istaff.org> To: John Curran X-Mailer: Apple Mail (2.1510) Archived-At: Cc: sidr , Sandra Murphy Subject: Re: [sidr] comments on validation revisited -01 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Mar 2015 19:48:59 -0000 --Apple-Mail=_2CEA091B-4DBC-4978-8083-69E0454220C7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Interesting answer. John, my understanding of what I've read on the = ARIN web site about transfer was that address space to be transferred = had to be unused. Did I read wrong? --Sandy On Mar 22, 2015, at 2:18 PM, John Curran wrote: > On Mar 20, 2015, at 2:10 PM, Stephen Kent wrote: >>=20 >> John, >> I agree that the frequency of v4 resources might change as a result = of exhaustion >> of that space on a regional level. A cursory look at the transfers = listed at the URL >> you provided would support that projection. But, I'm especially = interested seeing >> which transfers are for live vs.unused space, since the implications = for the >> ordering of events are very different. I don't see that info on this = page. >> ... >=20 > Interesting question - this is not information that organizations need = to=20 > supply to ARIN during the transfer request process (at least at ARIN), = so=20 > it is not shown in the statistics. If someone wants to do little = analysis > against routeviews/ripestat, it should be possible to derive such for = past =20 > transfers. (I'd advise against optimizing future mechanisms based on = that=20 > limited history, but it would still be interesting information to = have...) >=20 > /John >=20 > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr --Apple-Mail=_2CEA091B-4DBC-4978-8083-69E0454220C7 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJVDxyoAAoJEHplpQeet0IZHdEQALFdHkfRqIgstPsI6K7r5tLj jbVlZXX9rzenNjL0V1YhCMeKK8XmNbd/k26sZ6rAmdyLxGXy0fz4Y3an1KWGkS/u PDsPTnewkIk3s3312Syn+UMX38RxSRYGHhiw9A9NeO4EU5xDO3HsDswt0Fnl61pn 9vH7HlIBrvh9uuMpSTMH9Dhum6kZ24Nh9+Q7oEJHJ6topC46/uesFIV2Rj4koDSn W5gpHkq2sAuZuW/+3jEuT674UfWSfaRF4vq2dT6k6ICfd7ZlC7iQN0+hc65d+UXx nHbWCSyTD1l9HJH/rIhJeqN6dVFv0/VwF2lLM0LgvuwhDGx2NmwwnaehZVURj+hP RVzefLLp5CJmGjMBqeRZGBfDeTu4D41l/S5i83gcL4po99rBRZH/rvvA5Hnsx9PF QtsR/WuH7z7G+M3o7HI9WumhTV5GHZnwZq7h2ztPxzJp6d6VZ5GqrAJvvlPUSJAV 9LdsTnzokOrcKny+MkmhvNgoAzKdsmh+WO6n5zbelrVeWHCYC8wT/dF0CdVER8OH NKi5CDrkn5hXd/8sTqXgMndtpksUMwnTHc7/e8VCwAIaWAfhm9tkF3JQs670Vxjo uC3XIcz9GtXfab0Ooucwf69f3GizeUcgQ68bI2Ys+pzCu1LGfGVT8SnX51r59ORp DFOwMVg0rWJPA7jQDAIu =pYtH -----END PGP SIGNATURE----- --Apple-Mail=_2CEA091B-4DBC-4978-8083-69E0454220C7-- From nobody Sun Mar 22 13:45:43 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 923481A1B20 for ; Sun, 22 Mar 2015 13:45:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.19 X-Spam-Level: X-Spam-Status: No, score=-3.19 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MISSING_HEADERS=1.021, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JLHj7TgJcDWh for ; Sun, 22 Mar 2015 13:45:40 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 284131A1B1E for ; Sun, 22 Mar 2015 13:45:40 -0700 (PDT) Received: from ssh.bbn.com ([192.1.122.15]:54022 helo=COMSEC.local) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1YZmkc-0007ne-R0 for sidr@ietf.org; Sun, 22 Mar 2015 16:45:38 -0400 Message-ID: <550F29F2.4000903@bbn.com> Date: Sun, 22 Mar 2015 16:45:38 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 CC: sidr References: <550ED4D1.3060506@bbn.com> <29BB6F59-938B-4909-A7E7-32AB55CC9991@istaff.org> In-Reply-To: <29BB6F59-938B-4909-A7E7-32AB55CC9991@istaff.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [sidr] another though re xfers X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Mar 2015 20:45:41 -0000 John, Thanks for the timely reply and the informative responses. Steve From nobody Sun Mar 22 20:05:47 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 794E31A8791 for ; Sun, 22 Mar 2015 20:05:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e6AxPxbHXEJ4 for ; Sun, 22 Mar 2015 20:05:43 -0700 (PDT) Received: from relay.mailchannels.net (nov-007-i534.relay.mailchannels.net [46.232.183.88]) by ietfa.amsl.com (Postfix) with ESMTP id 3F2AB1A8788 for ; Sun, 22 Mar 2015 20:05:39 -0700 (PDT) X-Sender-Id: duocircle|x-authuser|jcurran Received: from smtp5.ore.mailhop.org (ip-10-33-12-218.us-west-2.compute.internal [10.33.12.218]) by relay.mailchannels.net (Postfix) with ESMTPA id 31649120309; Mon, 23 Mar 2015 03:05:30 +0000 (UTC) X-Sender-Id: duocircle|x-authuser|jcurran Received: from smtp5.ore.mailhop.org ([TEMPUNAVAIL]. [10.45.8.167]) (using TLSv1 with cipher DHE-RSA-AES256-SHA) by 0.0.0.0:2500 (trex/5.4.8); Mon, 23 Mar 2015 03:05:31 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: duocircle|x-authuser|jcurran X-MailChannels-Auth-Id: duocircle X-MC-Loop-Signature: 1427079930314:2859251541 X-MC-Ingress-Time: 1427079930314 Received: from [38.121.36.2] (helo=[10.10.2.182]) by smtp5.ore.mailhop.org with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.82) (envelope-from ) id 1YZsg3-0005Uc-K6; Mon, 23 Mar 2015 03:05:19 +0000 X-Mail-Handler: DuoCircle Outbound SMTP X-Originating-IP: 38.121.36.2 X-Report-Abuse-To: abuse@duocircle.com (see https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information for abuse reporting information) X-MHO-User: U2FsdGVkX1/jSYdVIHplY5sr1aW3wNmP Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) Content-Type: multipart/signed; boundary="Apple-Mail=_717286E9-CE35-467A-B912-6E63FC7FFAE1"; protocol="application/pgp-signature"; micalg=pgp-sha1 X-Pgp-Agent: GPGMail 2.5b6 From: John Curran In-Reply-To: <4566EEBB-0D73-497F-9B78-CE3C37C8A9E3@tislabs.com> Date: Sun, 22 Mar 2015 23:05:17 -0400 Message-Id: References: <550AE49C.9010207@bbn.com> <9DD8F125-0302-4D39-8110-38F6D1460F71@istaff.org> <550C629D.8050907@bbn.com> <5A5BA403-5D3E-4A0B-9CAB-DBAAEFCD085D@istaff.org> <4566EEBB-0D73-497F-9B78-CE3C37C8A9E3@tislabs.com> To: Sandra Murphy X-Mailer: Apple Mail (2.2070.6) X-AuthUser: jcurran Archived-At: Cc: sidr Subject: Re: [sidr] comments on validation revisited -01 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2015 03:05:45 -0000 --Apple-Mail=_717286E9-CE35-467A-B912-6E63FC7FFAE1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Mar 22, 2015, at 3:48 PM, Sandra Murphy wrote: >=20 > Interesting answer. John, my understanding of what I've read on the = ARIN web site about transfer was that address space to be transferred = had to be unused. >=20 > Did I read wrong? There is no requirement that the address block be "unused" (in either sense, i.e. not assigned to devices or not routed) /John --Apple-Mail=_717286E9-CE35-467A-B912-6E63FC7FFAE1 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iEYEARECAAYFAlUPgu0ACgkQh22TQU2hnI5fCgCg6b0HnHQn6zLIpuoOCUX3GHkv Ab4AoJ0Anj3ITkiv6ckFUtEJx0MOZ+hk =Vnx6 -----END PGP SIGNATURE----- --Apple-Mail=_717286E9-CE35-467A-B912-6E63FC7FFAE1-- From nobody Mon Mar 23 07:11:32 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42FAC1A8AD3; Mon, 23 Mar 2015 07:11:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OHm9gdvY5HOQ; Mon, 23 Mar 2015 07:11:28 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C1091A8AC3; Mon, 23 Mar 2015 07:11:28 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 5.12.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150323141128.327.41792.idtracker@ietfa.amsl.com> Date: Mon, 23 Mar 2015 07:11:28 -0700 Archived-At: Cc: sidr@ietf.org Subject: [sidr] I-D Action: draft-ietf-sidr-rfc6490-bis-02.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2015 14:11:29 -0000 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 : Resource Certificate PKI (RPKI) Trust Anchor Locator Authors : Geoff Huston Samuel Weiler George Michaelson Stephen Kent Filename : draft-ietf-sidr-rfc6490-bis-02.txt Pages : 9 Date : 2015-03-23 Abstract: This document defines a Trust Anchor Locator (TAL) for the Resource Certificate Public Key Infrastructure (RPKI). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sidr-rfc6490-bis/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-sidr-rfc6490-bis-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-sidr-rfc6490-bis-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Mar 23 07:19:33 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 950861A8ACB for ; Mon, 23 Mar 2015 07:19:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iEnmlS78P4VJ for ; Mon, 23 Mar 2015 07:19:29 -0700 (PDT) Received: from mail-wg0-x229.google.com (mail-wg0-x229.google.com [IPv6:2a00:1450:400c:c00::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C0521A8ABE for ; Mon, 23 Mar 2015 07:19:29 -0700 (PDT) Received: by wgbcc7 with SMTP id cc7so147094779wgb.0 for ; Mon, 23 Mar 2015 07:19:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to; bh=NJ6HDmpa6Bo4U0N5JLfmWw55jiuXSVl7lODx6cvhZ4s=; b=Qxn5+RxsS6go3RoCwxX/tI5pitlR/jnh9N7RDGypiKK/QmLtU0d5a87SJnlIMEdC8d FRBStkzgjfOMynDLS3dl8JOxlElcYUpnHsqFr2IwCG6r73f7oeK40sVG5FxTNucSspD4 xFkj1h8KUSQ/b0ziZBqc/Kbe+tJcGdB8EIr9FITTlY0graCoIpXt55luStxkmpN+1VZs FY25Lzr93BHVjpXq8T9k78RlTHY8sLaIBjQsrmCUe/yQdBSo/hTL/4BzZlmIiURnosNs Sd/zXcQuBhoWFxTG8D1p1G8E3fNPpvlbPjZKObcoHHBnTrfdbbZV/cLb4rq44WH74gom GeqQ== X-Received: by 10.194.57.206 with SMTP id k14mr188721944wjq.1.1427120367579; Mon, 23 Mar 2015 07:19:27 -0700 (PDT) Received: from ?IPv6:2001:67c:370:136:fcf0:16a2:5548:b9d6? ([2001:67c:370:136:fcf0:16a2:5548:b9d6]) by mx.google.com with ESMTPSA id p5sm11410572wiz.20.2015.03.23.07.19.26 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 23 Mar 2015 07:19:26 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Geoff Huston In-Reply-To: <20150323141128.327.41792.idtracker@ietfa.amsl.com> Date: Mon, 23 Mar 2015 09:19:23 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <91E804E2-7045-4CAC-AB92-6A55C6949C2A@gmail.com> References: <20150323141128.327.41792.idtracker@ietfa.amsl.com> To: sidr wg list X-Mailer: Apple Mail (2.2070.6) Archived-At: Subject: Re: [sidr] I-D Action: draft-ietf-sidr-rfc6490-bis-02.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2015 14:19:30 -0000 Just two changes: a) moved the ref to 6480 to be informative to avoid a downref b) updated Sam's current employer details Geoff > On 23 Mar 2015, at 9:11 am, internet-drafts@ietf.org wrote: >=20 >=20 > 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. >=20 > Title : Resource Certificate PKI (RPKI) Trust Anchor = Locator > Authors : Geoff Huston > Samuel Weiler > George Michaelson > Stephen Kent > Filename : draft-ietf-sidr-rfc6490-bis-02.txt > Pages : 9 > Date : 2015-03-23 >=20 > Abstract: > This document defines a Trust Anchor Locator (TAL) for the Resource > Certificate Public Key Infrastructure (RPKI). >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-sidr-rfc6490-bis/ >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-sidr-rfc6490-bis-02 >=20 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sidr-rfc6490-bis-02 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr From nobody Mon Mar 23 11:39:36 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FA381AD069 for ; Mon, 23 Mar 2015 11:39:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U4uRnIebwMhD for ; Mon, 23 Mar 2015 11:39:33 -0700 (PDT) Received: from walnut.tislabs.com (walnut.tislabs.com [192.94.214.200]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C9D111AD2C0 for ; Mon, 23 Mar 2015 11:39:26 -0700 (PDT) Received: from nova.tislabs.com (unknown [10.66.1.77]) by walnut.tislabs.com (Postfix) with ESMTP id 22B0728B0017; Mon, 23 Mar 2015 14:39:26 -0400 (EDT) Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1]) by nova.tislabs.com (Postfix) with ESMTP id C860F1F8051; Mon, 23 Mar 2015 14:39:25 -0400 (EDT) Content-Type: multipart/signed; boundary="Apple-Mail=_0E5C02AA-A8E9-42CC-B089-B87A499A2E90"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Sandra Murphy In-Reply-To: Date: Mon, 23 Mar 2015 14:39:23 -0400 Message-Id: <5CC4F283-DF63-4F3B-B47B-553B40F19AE8@tislabs.com> References: <550AE49C.9010207@bbn.com> <9DD8F125-0302-4D39-8110-38F6D1460F71@istaff.org> <550C629D.8050907@bbn.com> <5A5BA403-5D3E-4A0B-9CAB-DBAAEFCD085D@istaff.org> <4566EEBB-0D73-497F-9B78-CE3C37C8A9E3@tislabs.com> To: John Curran X-Mailer: Apple Mail (2.1510) Archived-At: Cc: sidr , Sandra Murphy Subject: Re: [sidr] comments on validation revisited -01 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2015 18:39:35 -0000 --Apple-Mail=_0E5C02AA-A8E9-42CC-B089-B87A499A2E90 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 I got that idea from the use of the word "unused" on = https://www.arin.net/resources/transfers/index.html IPv4 address space and Autonomous System Numbers (ASNs) issued by ARIN = or its predecessors may only be transferred to another organization = when: =95 An organization acquires the assets that are using IPv4 = addresses and/or ASNs in a currently operating network via a merger, = acquisition, or similar transaction =95 An organization with unused IPv4 address space or an ASN = releases it to a specified recipient who qualifies for it under current = ARIN policy (Note also the "may only" part.) On that same page, TRANSFERS TO SPECIFIED RECIPIENTS=20 (NRPM 8.3) If your organization is in need of, or currently holds unused = ARIN-issued IPv4 address space or an Autonomous System Number (ASN) you = may request an 8.3 Transfer (Transfer to Specified Recipients within the = ARIN Region) transfer. I guess what you are saying is that the "unused" part is unused in = operation. :-) Btw, There are also mentions of "unused" at the APNIC site. = https://cgi1.apnic.net/assets/apnic/js/apps/transfers/Transfer%20procedure= %20of%20unused%20IPv4%20and%20AS%20Numbers%20between%20APNIC%20accounts.pd= f = https://www.apnic.net/services/become-a-member/manage-your-membership/tran= sfer-resources#unused = https://www.apnic.net/services/become-a-member/manage-your-membership/tran= sfer-resources --Sandy On Mar 22, 2015, at 11:05 PM, John Curran wrote: > On Mar 22, 2015, at 3:48 PM, Sandra Murphy wrote: >>=20 >> Interesting answer. John, my understanding of what I've read on the = ARIN web site about transfer was that address space to be transferred = had to be unused. >>=20 >> Did I read wrong? >=20 > There is no requirement that the address block be "unused" > (in either sense, i.e. not assigned to devices or not routed) >=20 > /John >=20 >=20 >=20 > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr --Apple-Mail=_0E5C02AA-A8E9-42CC-B089-B87A499A2E90 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJVEF3bAAoJEHplpQeet0IZPdYP/2X6g5cLaHdcmFV54bCIGWTq 0IGMvRU83yV0+irxJWp8FjzXm51NN3YBCa/dwmIzhxMTOg5S1ZwE7JFwV2LrAU8F pvwoJCJmE2Llo5KeWpREZ5MFxCfOErFMUTy4e4EQ7Fy5V/A/Ywr0x3XMzjFsu5PD BDDnqp6Ov0P7Fug3H1eVuiVUu5+7FUIEjvHURPkC+QWmeJ1fHDOuVbrvye0PQBS5 UjeDXYkz53g+UxqPEMuoD8wOGPz6yQe8MTISv8PuGEGQQaDvx5q9DdYEAYrNEi8l usC4IqA18I3LBBUwtwDUcBzpGTZ0O4woJilNjdnpNduw8Qm4l2SsyNYS/ga8FGoQ P9F9RPGMAKOJGgNHYfmRb/xBXM79SVBCHkujJWAjXgwuD/TnUtmsuf7XqEqsSt9q WrE2fGNThe0Mri+uJdek0UXPusUO2gT2Vl4Qbyrmp6G9BJ9jbQJftbgf3fIMGGI8 7piflz0CUqyMItdG1dsBcQmfH0FyjJ9E9tYrCi2ITXb/piWKDQ5Y8jqpOUzQOqmR uAgNNRtkJt44Vgpl4B9vaPgEHHuNC648HHVV7LUEyjRb2sciSN1SL9ljAm7uaqzi U0InJUypqCYBc3XTocNSc8Uc3PoK2xjcdLQ8oBW0MOUIsBEvZDgysOjtK1RR7WKy Px/ZOSJtivTkKXBz6nug =f0F0 -----END PGP SIGNATURE----- --Apple-Mail=_0E5C02AA-A8E9-42CC-B089-B87A499A2E90-- From nobody Tue Mar 24 08:36:54 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB5D61A893E for ; Tue, 24 Mar 2015 08:36:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.8 X-Spam-Level: X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p9Bml6dyZ2P1 for ; Tue, 24 Mar 2015 08:36:47 -0700 (PDT) Received: from nm14-vm9.access.bullet.mail.gq1.yahoo.com (nm14-vm9.access.bullet.mail.gq1.yahoo.com [216.39.63.252]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DFA701A8932 for ; Tue, 24 Mar 2015 08:36:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1427211406; bh=UPAHU6TDioiW0p0T4c4C6ga+kKv+SFFhi/eVI4qlpmE=; h=Date:From:To:Subject:In-Reply-To:References:From:Subject; b=IC6fJ5xH9orLuhqF+5FDwl973y5bXEfbTogSaLKmMCmBJt9GWXp6+2HqdNxq+AJMpclu537KcW4oRtt4oY4Fkbi7a+Wo/g7IoU8U7O0el5tYotIJlQkrL9DQlbZThy8Yp7hZB8H+d4EWCU6qtWO/mo6++DFkREx2An3VTQwWjEohQ62G5jEcEzvfJ+HKKuHs6Pshfq2j3BqlPlqqwe0pt3OdciuuNwSPfddjyQda5WFOrZBeX6w/GMkmVAfPklSH87g/ClSRw7QLkG58ozNfFnTd8YtEjzW6jZLHZ8K3xJkCCs5iE0GfEZWtVxQXCEEnVfkbdH/OJxviOBZj7UMkWQ== Received: from [216.39.60.166] by nm14.access.bullet.mail.gq1.yahoo.com with NNFMP; 24 Mar 2015 15:36:46 -0000 Received: from [98.138.226.243] by tm2.access.bullet.mail.gq1.yahoo.com with NNFMP; 24 Mar 2015 15:36:46 -0000 Received: from [127.0.0.1] by smtp114.sbc.mail.ne1.yahoo.com with NNFMP; 24 Mar 2015 15:36:46 -0000 X-Yahoo-Newman-Id: 598923.52639.bm@smtp114.sbc.mail.ne1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: tWqeK.EVM1ktzE0zb5SdNoTWSqw8y8cMqMjPEw0Fx4j0_js JAfgtUaSqaxBJ0RNDe6yjfZPaTcFcLD1MEYIrN78aRLKrXs_r8KRSkymwvrd 6fmH0uA8soNglgONufPRcr5_ARU6j2MBo01BEMTm_eNqUV3X0FAXXgMV9DCx JW3_jNImEpZidEPmdr9xyL5Q4BXQZiIBfUX6CmEnsmXFFAXpX92FosYFTHTf BoyG3TSXuZYmJUl_a_qB9hzTzZLG1R25jkZZ03MMP6ecxIJSdNSUMo9n_2gO tzlS3OghQgPb7rOJrufoGC2viZwX7H05iPMcZ2GtVJ0C0SwT0s6LcdliYNE_ H9m09qdcNckKih.tdYeakqLJjNAOcF2p0yMIkx3ONpOvpYD0EfPN1ClXH5Xc FaTa0EJHmLbWTQlAJVehPdNkbR5HKplDOTuxw3R4P18qIisX6dcl8.MSJdAO YNk9lyZ3ZM6FlHz0fr.Czxnj3IHLOqP2wuBsvgBVH.wjXSCE5SE7jvO4UKVm 1jp1g_0Brua0LElE0XvIG20EONrB25FgsXvT9XaS2Bg.Stz9jv0y4pEuQiaV LgUCPmESBJ..N8xZiu0BYCCRUX6eT35pBF1iohMPnz3AxEEofUA-- X-Yahoo-SMTP: 4kJJK.qswBDPuwyc5wW.BPAQqNXdy5j09UNyeAS0pyOQ708- Received: from secure.mandelberg.org (c-76-24-31-176.hsd1.ma.comcast.net [76.24.31.176]) by uriel.mandelberg.org (Postfix) with ESMTPSA id 3E11C1C6052 for ; Tue, 24 Mar 2015 11:36:45 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Date: Tue, 24 Mar 2015 10:36:45 -0500 From: David Mandelberg To: In-Reply-To: <729d38908098b3cb55910eaf98fb346a@mail.mandelberg.org> References: <729d38908098b3cb55910eaf98fb346a@mail.mandelberg.org> Message-ID: <42c5425d1e1e7260c70dcdfbf8bbbdb7@mail.mandelberg.org> X-Sender: david@mandelberg.org User-Agent: Roundcube Webmail/0.7.2 Archived-At: Subject: Re: [sidr] WGLC for draft-ietf-sidr-rpki-rtr-rfc6810-bis-03 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2015 15:36:53 -0000 Rob and I were talking about rpki-rtr, and I came up with another potential issue with switching between protocol versions. I don't see any text about whether a single session (session id and serial numbers) can be used for both version 0 and 1. If a router has a valid version 0 session, upgrades to version 1, and issues a serial query with the same session id and serial number, it's unclear what the server should do. Could we add text to the document saying that the cache MUST maintain a separate session for each protocol version it supports, and a router MUST NOT attempt to reuse session information across multiple protocol versions? -- David Eric Mandelberg / dseomn http://david.mandelberg.org/ From nobody Tue Mar 24 08:58:51 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 686021A8FD4 for ; Tue, 24 Mar 2015 08:58:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bv6HZkUmR1JU for ; Tue, 24 Mar 2015 08:58:47 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0751.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:751]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D0D931A8F4E for ; Tue, 24 Mar 2015 08:58:46 -0700 (PDT) Received: from DM2PR09MB0286.namprd09.prod.outlook.com (25.160.96.143) by DM2PR09MB0286.namprd09.prod.outlook.com (25.160.96.143) with Microsoft SMTP Server (TLS) id 15.1.118.21; Tue, 24 Mar 2015 15:58:30 +0000 Received: from DM2PR09MB0286.namprd09.prod.outlook.com ([25.160.96.143]) by DM2PR09MB0286.namprd09.prod.outlook.com ([25.160.96.143]) with mapi id 15.01.0118.021; Tue, 24 Mar 2015 15:58:30 +0000 From: "Borchert, Oliver" To: David Mandelberg , "sidr@ietf.org" Thread-Topic: [sidr] WGLC for draft-ietf-sidr-rpki-rtr-rfc6810-bis-03 Thread-Index: AQHQV+8ZoLfZHuZye0y1FFsltBIAFZ0gKsSAgAu2CID//7HigA== Date: Tue, 24 Mar 2015 15:58:28 +0000 Message-ID: References: <729d38908098b3cb55910eaf98fb346a@mail.mandelberg.org> <42c5425d1e1e7260c70dcdfbf8bbbdb7@mail.mandelberg.org> In-Reply-To: <42c5425d1e1e7260c70dcdfbf8bbbdb7@mail.mandelberg.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.8.150116 x-originating-ip: [129.6.223.115] authentication-results: mandelberg.org; dkim=none (message not signed) header.d=none; x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DM2PR09MB0286; x-microsoft-antispam-prvs: x-forefront-antispam-report: BMV:1; SFV:NSPM; SFS:(10019020)(6009001)(40224003)(51704005)(479174004)(377454003)(30584003)(122556002)(2656002)(40100003)(230783001)(77156002)(54356999)(99286002)(66066001)(76176999)(46102003)(62966003)(87936001)(15975445007)(19580405001)(2950100001)(2900100001)(92566002)(2501003)(83506001)(102836002)(50986999)(107886001)(19580395003)(86362001)(106116001)(36756003); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR09MB0286; H:DM2PR09MB0286.namprd09.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(5002010); SRVR:DM2PR09MB0286; BCL:0; PCL:0; RULEID:; SRVR:DM2PR09MB0286; x-forefront-prvs: 0525BB0ADF Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Mar 2015 15:58:28.6491 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR09MB0286 Archived-At: Subject: Re: [sidr] WGLC for draft-ietf-sidr-rpki-rtr-rfc6810-bis-03 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2015 15:58:49 -0000 Isn=B9t this an implementation issue? The client either speaks 0 or 1. As long as the server=20 keeps track of the version for the session IMHO it does not matter if the session id is=20 shared? The client doesn=B9t know about it. Lets say one encounter a new ke= y and this=20 Only triggers a PDU 9, the server sends send out the notification. The client can but must not React to it anyhow. If the client reacts, the server sends an end of update to a version 0 session and all pdu 9 updates to a version 1 session. I don=B9t see a needed wording here. Not yet but I=8Cm open for enlightenme= nt. Oliver ------------------------------------------------------------- Oliver Borchert, Computer Scientist National Institute of Standards and Technology (Phone) 301.975.4856 , (Fax) 301.975.6238 On 3/24/15, 10:36 AM, "David Mandelberg" wrote: >Rob and I were talking about rpki-rtr, and I came up with another >potential issue with switching between protocol versions. I don't see >any text about whether a single session (session id and serial numbers) >can be used for both version 0 and 1. If a router has a valid version 0 >session, upgrades to version 1, and issues a serial query with the same >session id and serial number, it's unclear what the server should do. >Could we add text to the document saying that the cache MUST maintain a >separate session for each protocol version it supports, and a router >MUST NOT attempt to reuse session information across multiple protocol >versions? > >--=20 >David Eric Mandelberg / dseomn >http://david.mandelberg.org/ > >_______________________________________________ >sidr mailing list >sidr@ietf.org >https://www.ietf.org/mailman/listinfo/sidr From nobody Wed Mar 25 14:14:06 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4CD51A044F for ; Wed, 25 Mar 2015 14:14:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SYZ2VgzFVmfL for ; Wed, 25 Mar 2015 14:14:02 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0770.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:770]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 851991A007A for ; Wed, 25 Mar 2015 14:14:02 -0700 (PDT) Received: from DM2PR09MB0286.namprd09.prod.outlook.com (25.160.96.143) by DM2PR09MB0287.namprd09.prod.outlook.com (25.160.96.144) with Microsoft SMTP Server (TLS) id 15.1.118.21; Wed, 25 Mar 2015 21:13:44 +0000 Received: from DM2PR09MB0286.namprd09.prod.outlook.com ([25.160.96.143]) by DM2PR09MB0286.namprd09.prod.outlook.com ([25.160.96.143]) with mapi id 15.01.0118.022; Wed, 25 Mar 2015 21:13:44 +0000 From: "Borchert, Oliver" To: "Borchert, Oliver" , David Mandelberg , "sidr@ietf.org" Thread-Topic: [sidr] WGLC for drained ft-ietf-sidr-rpki-rtr-rfc6810-bis-03 Thread-Index: AQHQZ0CTdT6ASHFRyUaxHdTkYjFfEA== Date: Wed, 25 Mar 2015 21:13:44 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.8.150116 x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [129.6.218.31] authentication-results: nist.gov; dkim=none (message not signed) header.d=none; x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DM2PR09MB0287; x-forefront-antispam-report: BMV:1; SFV:NSPM; SFS:(10019020)(6009001)(40224003)(51704005)(377454003)(24454002)(30584003)(479174004)(122556002)(102836002)(40100003)(230783001)(15975445007)(99286002)(2900100001)(92566002)(106116001)(77156002)(107886001)(2501003)(54356999)(50986999)(86362001)(87936001)(2656002)(46102003)(83506001)(19580395003)(19580405001)(66066001)(36756003); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR09MB0287; H:DM2PR09MB0286.namprd09.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5002010)(5005006); SRVR:DM2PR09MB0287; BCL:0; PCL:0; RULEID:; SRVR:DM2PR09MB0287; x-forefront-prvs: 052670E5A4 Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Mar 2015 21:13:44.1560 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR09MB0287 Archived-At: Subject: Re: [sidr] WGLC for drained ft-ietf-sidr-rpki-rtr-rfc6810-bis-03 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Mar 2015 21:14:04 -0000 RGF2aWQsDQoNCkEgY29ycmVjdGlvbiBmb3IgbXkgcHJldmlvdXMgZW1haWwsIEkgbWl4ZWQgdXAg c2Vzc2lvbiBpZCBhbmQgc2VyaWFsDQpudW1iZXIuDQpJIHRoaW5rIHRvIGtlZXAgaXQgc2ltcGxl IGZvciB2ZXJzaW9uIDAgLSAxIHN3aXRjaGVzIGFuZCBmdXR1cmUgY2hhbmdlcywgYQ0KY2hhbmdl DQpXaXRoaW4gdGhlIHNlc3Npb24gaWQgYW5kIHZlcnNpb24gaWQgc2hvdWxkIHRyaWdnZXIgYSDi gJxDYWNoZSBSZXNldOKAnSBieSB0aGUNCmNhY2hlDQpBbmQgdGhlIGNsaWVudCBtdXN0IHJlc3lu Y2ggd2l0aCB0aGUgc2VydmVyLg0KQW5kIHllcywgd29yZGluZyBpbiB0aGlzIG1hdHRlciBtaWdo dCBuZWVkIHRvIGJlIGFkZGVkIC0gYnV0IHN0aWxsIGl0IGFsc28NCmNvdWxkDQpCZSBhbiBpbXBs ZW1lbnRhdGlvbiBpc3N1ZS4NCg0KT2xpdmVyDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCk9saXZlciBCb3JjaGVydCwgQ29t cHV0ZXIgU2NpZW50aXN0DQpOYXRpb25hbCBJbnN0aXR1dGUgb2YgU3RhbmRhcmRzIGFuZCBUZWNo bm9sb2d5DQooUGhvbmUpIDMwMS45NzUuNDg1NiAsIChGYXgpIDMwMS45NzUuNjIzOA0KDQoNCg0K DQoNCk9uIDMvMjQvMTUsIDEwOjU4IEFNLCAiQm9yY2hlcnQsIE9saXZlciIgPG9saXZlci5ib3Jj aGVydEBuaXN0Lmdvdj4gd3JvdGU6DQoNCj5Jc27CuXQgdGhpcyBhbiBpbXBsZW1lbnRhdGlvbiBp c3N1ZT8gVGhlIGNsaWVudCBlaXRoZXIgc3BlYWtzIDAgb3IgMS4gQXMNCj5sb25nIGFzIHRoZSBz ZXJ2ZXINCj5rZWVwcyB0cmFjayBvZiB0aGUgdmVyc2lvbiBmb3IgdGhlIHNlc3Npb24gSU1ITyBp dCBkb2VzIG5vdCBtYXR0ZXIgaWYgdGhlDQo+c2Vzc2lvbiBpZCBpcyANCj5zaGFyZWQ/IFRoZSBj bGllbnQgZG9lc27CuXQga25vdyBhYm91dCBpdC4gTGV0cyBzYXkgb25lIGVuY291bnRlciBhIG5l dyBrZXkNCj5hbmQgdGhpcyANCj5Pbmx5IHRyaWdnZXJzIGEgUERVIDksIHRoZSBzZXJ2ZXIgc2Vu ZHMgc2VuZCBvdXQgdGhlIG5vdGlmaWNhdGlvbi4gVGhlDQo+Y2xpZW50IGNhbiBidXQgbXVzdCBu b3QNCj5SZWFjdCB0byBpdCBhbnlob3cuIElmIHRoZSBjbGllbnQgcmVhY3RzLCB0aGUgc2VydmVy IHNlbmRzIGFuIGVuZCBvZg0KPnVwZGF0ZSB0byBhIHZlcnNpb24gMA0KPnNlc3Npb24gYW5kIGFs bCBwZHUgOSB1cGRhdGVzIHRvIGEgdmVyc2lvbiAxIHNlc3Npb24uDQo+SSBkb27CuXQgc2VlIGEg bmVlZGVkIHdvcmRpbmcgaGVyZS4gTm90IHlldCBidXQgScWSbSBvcGVuIGZvciBlbmxpZ2h0ZW5t ZW50Lg0KPg0KPk9saXZlcg0KPi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj5PbGl2ZXIgQm9yY2hlcnQsIENvbXB1dGVyIFNjaWVu dGlzdA0KPk5hdGlvbmFsIEluc3RpdHV0ZSBvZiBTdGFuZGFyZHMgYW5kIFRlY2hub2xvZ3kNCj4o UGhvbmUpIDMwMS45NzUuNDg1NiAsIChGYXgpIDMwMS45NzUuNjIzOA0KPg0KPg0KPg0KPg0KPg0K Pk9uIDMvMjQvMTUsIDEwOjM2IEFNLCAiRGF2aWQgTWFuZGVsYmVyZyIgPGRhdmlkQG1hbmRlbGJl cmcub3JnPiB3cm90ZToNCj4NCj4+Um9iIGFuZCBJIHdlcmUgdGFsa2luZyBhYm91dCBycGtpLXJ0 ciwgYW5kIEkgY2FtZSB1cCB3aXRoIGFub3RoZXINCj4+cG90ZW50aWFsIGlzc3VlIHdpdGggc3dp dGNoaW5nIGJldHdlZW4gcHJvdG9jb2wgdmVyc2lvbnMuIEkgZG9uJ3Qgc2VlDQo+PmFueSB0ZXh0 IGFib3V0IHdoZXRoZXIgYSBzaW5nbGUgc2Vzc2lvbiAoc2Vzc2lvbiBpZCBhbmQgc2VyaWFsIG51 bWJlcnMpDQo+PmNhbiBiZSB1c2VkIGZvciBib3RoIHZlcnNpb24gMCBhbmQgMS4gSWYgYSByb3V0 ZXIgaGFzIGEgdmFsaWQgdmVyc2lvbiAwDQo+PnNlc3Npb24sIHVwZ3JhZGVzIHRvIHZlcnNpb24g MSwgYW5kIGlzc3VlcyBhIHNlcmlhbCBxdWVyeSB3aXRoIHRoZSBzYW1lDQo+PnNlc3Npb24gaWQg YW5kIHNlcmlhbCBudW1iZXIsIGl0J3MgdW5jbGVhciB3aGF0IHRoZSBzZXJ2ZXIgc2hvdWxkIGRv Lg0KPj5Db3VsZCB3ZSBhZGQgdGV4dCB0byB0aGUgZG9jdW1lbnQgc2F5aW5nIHRoYXQgdGhlIGNh Y2hlIE1VU1QgbWFpbnRhaW4gYQ0KPj5zZXBhcmF0ZSBzZXNzaW9uIGZvciBlYWNoIHByb3RvY29s IHZlcnNpb24gaXQgc3VwcG9ydHMsIGFuZCBhIHJvdXRlcg0KPj5NVVNUIE5PVCBhdHRlbXB0IHRv IHJldXNlIHNlc3Npb24gaW5mb3JtYXRpb24gYWNyb3NzIG11bHRpcGxlIHByb3RvY29sDQo+PnZl cnNpb25zPw0KPj4NCj4+LS0gDQo+PkRhdmlkIEVyaWMgTWFuZGVsYmVyZyAvIGRzZW9tbg0KPj5o dHRwOi8vZGF2aWQubWFuZGVsYmVyZy5vcmcvDQo+Pg0KPj5fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KPj5zaWRyIG1haWxpbmcgbGlzdA0KPj5zaWRyQGll dGYub3JnDQo+Pmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2lkcg0KPg0K Pl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+c2lkciBt YWlsaW5nIGxpc3QNCj5zaWRyQGlldGYub3JnDQo+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9zaWRyDQoNCg== From nobody Sat Mar 28 16:20:17 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7E8D1A0196; Sat, 28 Mar 2015 16:20:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id md-_vy0VUOG0; Sat, 28 Mar 2015 16:20:12 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2553B1A01D6; Sat, 28 Mar 2015 16:20:12 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 5.13.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150328232012.8464.95328.idtracker@ietfa.amsl.com> Date: Sat, 28 Mar 2015 16:20:12 -0700 Archived-At: Cc: sidr@ietf.org Subject: [sidr] I-D Action: draft-ietf-sidr-rfc6490-bis-03.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Mar 2015 23:20:14 -0000 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 : Resource Certificate PKI (RPKI) Trust Anchor Locator Authors : Geoff Huston Samuel Weiler George Michaelson Stephen Kent Filename : draft-ietf-sidr-rfc6490-bis-03.txt Pages : 9 Date : 2015-03-28 Abstract: This document defines a Trust Anchor Locator (TAL) for the Resource Certificate Public Key Infrastructure (RPKI). This document obsoletes RFC 6490 by adding support for multiple URIs in a TAL. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sidr-rfc6490-bis/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-sidr-rfc6490-bis-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-sidr-rfc6490-bis-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sun Mar 29 12:48:05 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D35C1A87C2 for ; Sun, 29 Mar 2015 12:47:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.801 X-Spam-Level: X-Spam-Status: No, score=-101.801 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, SPF_PASS=-0.001, T_DKIM_INVALID=0.01, T_RP_MATCHES_RCVD=-0.01, USER_IN_WHITELIST=-100] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dgJHYh-n3T5D for ; Sun, 29 Mar 2015 12:47:55 -0700 (PDT) Received: from nx-mailgw.apnic.net (nx-mailgw.apnic.net [IPv6:2001:dd8:9:801::25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E29281A87BE for ; Sun, 29 Mar 2015 12:47:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apnic.net; s=c3po; h=received:received:content-type:mime-version:subject:from:in-reply-to:date: content-transfer-encoding:message-id:references:to:x-mailer:return-path: x-originating-ip; bh=HVsD/LtSP5SVzlDZbIFVvPS9MyxILWFVGS+A8GbAz/4=; b=JGuxVN6ImrIAUlMi90SZx57Uva0zphGNEGuiwyItKj1ExyAeAD9QWi8pzKP895lckfX8sJBObWPW6 sQX7lyNIf5FaddlQM7XiIbG9ewpeIY/9rvl98Xe2yYyWnJRKvzPzZ43/NIg0lN1SGF3RoNz0h2J2E9 rOYqTj5G9AmYXZd0= Received: from iamda3.org.apnic.net (unknown [IPv6:2001:dd8:9:2::101:249]) by nx-mailgw.apnic.net (Halon Mail Gateway) with ESMTPS for ; Mon, 30 Mar 2015 05:49:03 +1000 (AEST) Received: from dhcp179.potaroo.net (203.119.101.249) by iamda3.org.apnic.net (203.119.111.31) with Microsoft SMTP Server (TLS) id 14.1.218.12; Mon, 30 Mar 2015 05:47:43 +1000 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Geoff Huston In-Reply-To: <20150328232012.8464.95328.idtracker@ietfa.amsl.com> Date: Mon, 30 Mar 2015 06:47:41 +1100 Content-Transfer-Encoding: quoted-printable Message-ID: <4166EED5-E454-4137-AC42-62CA3153B613@apnic.net> References: <20150328232012.8464.95328.idtracker@ietfa.amsl.com> To: sidr wg list X-Mailer: Apple Mail (2.2070.6) X-Originating-IP: [203.119.101.249] Archived-At: Subject: Re: [sidr] I-D Action: draft-ietf-sidr-rfc6490-bis-03.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Mar 2015 19:47:57 -0000 Minor change to the Abstract and Introduction explaining the motivation = for the update to the RFC, as requested by the WG Chairs. Geoff > On 29 Mar 2015, at 10:20 am, internet-drafts@ietf.org wrote: >=20 >=20 > 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. >=20 > Title : Resource Certificate PKI (RPKI) Trust Anchor = Locator > Authors : Geoff Huston > Samuel Weiler > George Michaelson > Stephen Kent > Filename : draft-ietf-sidr-rfc6490-bis-03.txt > Pages : 9 > Date : 2015-03-28 >=20 > Abstract: > This document defines a Trust Anchor Locator (TAL) for the Resource > Certificate Public Key Infrastructure (RPKI). This document > obsoletes RFC 6490 by adding support for multiple URIs in a TAL. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-sidr-rfc6490-bis/ >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-sidr-rfc6490-bis-03 >=20 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sidr-rfc6490-bis-03 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr From nobody Tue Mar 31 11:30:15 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72BE81A90A3 for ; Tue, 31 Mar 2015 11:30:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.365 X-Spam-Level: **** X-Spam-Status: No, score=4.365 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FH_RELAY_NODNS=1.451, HELO_EQ_MODEMCABLE=0.768, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.793, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n2m7PkKjDOXs for ; Tue, 31 Mar 2015 11:30:08 -0700 (PDT) Received: from cdcipgw01.twcable.com (unknown [165.237.91.110]) by ietfa.amsl.com (Postfix) with ESMTP id 298BC1A90AC for ; Tue, 31 Mar 2015 11:29:46 -0700 (PDT) X-SENDER-IP: 10.136.163.10 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="5.11,502,1422939600"; d="scan'208,217";a="278371600" Received: from unknown (HELO PRVPEXHUB01.corp.twcable.com) ([10.136.163.10]) by cdcipgw01.twcable.com with ESMTP/TLS/RC4-MD5; 31 Mar 2015 14:22:16 -0400 Received: from PRVPEXVS10.corp.twcable.com ([10.136.163.40]) by PRVPEXHUB01.corp.twcable.com ([10.136.163.10]) with mapi; Tue, 31 Mar 2015 14:29:45 -0400 From: "George, Wes" To: "Alvaro Retana (aretana)" , "sidr@ietf.org" Date: Tue, 31 Mar 2015 14:29:43 -0400 Thread-Topic: Review of draft-ietf-sidr-as-migration Thread-Index: AdBr4Kkf5LcB5+V+S5m8ImnMkRldHg== Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.8.150116 acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_D14050384BA64wesleygeorgetwcablecom_" MIME-Version: 1.0 Archived-At: Cc: "draft-ietf-sidr-as-migration@tools.ietf.org" Subject: Re: [sidr] Review of draft-ietf-sidr-as-migration X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Mar 2015 18:30:11 -0000 --_000_D14050384BA64wesleygeorgetwcablecom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QWRkZWQgU0lEUiwgcmVzcG9uc2VzIGJlbG93IGlubGluZSwgd2hpY2ggb2YgY291cnNlIG1lc3Nl ZCB1cCB5b3VyIG9yaWdpbmFsIG51bWJlcmluZy4NCkkgaGF2ZW4ndCBwdXNoZWQgdGhlIHJldiB5 ZXQsIGFzIEknbSB3YWl0aW5nIHRvIG1ha2Ugc3VyZSB0aGF0IEkgZG9uJ3QgbmVlZCB0byBtYWtl IGFkZGl0aW9uYWwgY2hhbmdlcyBiYXNlZCBvbiB0aGUgcmV2aXNpb24gdG8gdGhlIEJHUFNlYyBw cm90b2NvbCBkb2MuDQoNClRoYW5rcywNCg0KV2VzDQoNCkZyb206ICJBbHZhcm8gUmV0YW5hIChh cmV0YW5hKSIgPGFyZXRhbmFAY2lzY28uY29tPG1haWx0bzphcmV0YW5hQGNpc2NvLmNvbT4+DQpE YXRlOiBNb25kYXksIE1hcmNoIDIzLCAyMDE1IGF0IDExOjE4IEFNDQpUbzogIkdlb3JnZSwgV2Vz IiA8d2VzbGV5Lmdlb3JnZUB0d2NhYmxlLmNvbTxtYWlsdG86d2VzbGV5Lmdlb3JnZUB0d2NhYmxl LmNvbT4+DQpDYzogImRyYWZ0LWlldGYtc2lkci1hcy1taWdyYXRpb25AdG9vbHMuaWV0Zi5vcmc8 bWFpbHRvOmRyYWZ0LWlldGYtc2lkci1hcy1taWdyYXRpb25AdG9vbHMuaWV0Zi5vcmc+IiA8ZHJh ZnQtaWV0Zi1zaWRyLWFzLW1pZ3JhdGlvbkB0b29scy5pZXRmLm9yZzxtYWlsdG86ZHJhZnQtaWV0 Zi1zaWRyLWFzLW1pZ3JhdGlvbkB0b29scy5pZXRmLm9yZz4+DQpTdWJqZWN0OiBSZXZpZXcgb2Yg ZHJhZnQtaWV0Zi1zaWRyLWFzLW1pZ3JhdGlvbg0KDQpNaW5vcjoNCg0KIDEuICBJdCB3b3VsZCBi ZSBuaWNlIHRvIGhhdmUgc29tZSBzb3J0IG9mIHJvYWQgbWFwIGluIHRoZSBJbnRyb2R1Y3Rpb24u ICBJbmRpY2F0aW5nIHRoYXQgU2VjdGlvbiAzIHByZXNlbnRzIHRoZSBwcm9ibGVtLCA0IHRoZSBy ZXF1aXJlbWVudHMgYW5kIDUgdGhlIHNvbHV0aW9uIGl0c2VsZi4gIEV2ZW4gdGhvdWdoIHNlY3Rp b24gNSBpbiBpbiBmYWN0IG5hbWVkIOKAmFNvbHV0aW9u4oCZIGl0IGlzIG5vdCBjbGVhciwgYXQg bGVhc3Qgbm90IHRvIG1lIHdoYXQgdGhlIG9yZGVyIG9mIHRoZSBkb2N1bWVudCBpczsgd2hlbiBy ZWFkaW5nIHNlY3Rpb24gMyBJIGtlcHQgd29uZGVyaW5nIHRvIG15c2VsZiDigJx3aGF0IGFib3V0 IHRoZSBzb2x1dGlvbj/igJ0uDQoNCldHXSBpc24ndCB0aGlzIHdoYXQgdGhlIHRhYmxlIG9mIGNv bnRlbnRzIGlzIGZvcj8gVGhpcyBpc24ndCBhIGxvbmcgZW5vdWdoIGRvY3VtZW50IHRoYXQgaXQg cmVhbGx5IG5lZWRzIGFuICJhZ2VuZGEgc2xpZGUiDQoNCiAxLiAgU2VjdGlvbiAzLiBzL1NIT1VM RCBOT1Qvc2hvdWxkIG5vdCAgICAgV2UgY2Fu4oCZdCB1c2UgcmZjMjExOSBsYW5ndWFnZSB0byBt YW5kYXRlIHRoZSBiZWhhdmlvciBvZiBhbiBvcGVyYXRvcjsgaW4gdGhpcyBjYXNlIHJlbGF0ZWQg dG8gdGhlIGFtb3VudCBvZiB0aW1lIHRoZSB0cmFuc2l0aW9uIHBoYXNlIGxhc3RzLiAgSSB0aGlu ayB5b3UgaGF2ZSBtYWRlIGEgZ29vZCBwb2ludCBhYm91dCB0aGUgbmVlZCB0byBub3Qgc3RheSB0 aGVyZSBmb3JldmVyLCBidXQgaGF2ZSBhbHNvIHNhaWQgdGhhdCB0aGUgdHJhbnNpdGlvbiBpcyBu b3QgYWx3YXlzIHVuZGVyIHRoZSBjb250cm9sIG9mIHRoZSBvcGVyYXRvci4NCg0KV0ddIEkgZGlz YWdyZWUgd2l0aCB0aGUgYmxhbmtldCBhc3NlcnRpb24gdGhhdCB3ZSBjYW4ndCBub3JtYXRpdmVs eSBtYW5kYXRlIHRoZSBiZWhhdmlvciBvZiBhbiBvcGVyYXRvciBpbiB0aGUgY29udGV4dCBvZiBh IHN0YW5kYXJkIG9yIEJDUCBkb2N1bWVudCwgYW5kIEkgdGhpbmsgdGhhdCB0aGUgZ3VpZGFuY2Ug aXMgY29ycmVjdCBoZXJlIOKAkyBvcGVyYXRvcnMgU0hPVUxEIE5PVCBzdGF5IGluIHRyYW5zaXRp b24gaW5kZWZpbml0ZWx5LiBTaG91bGQgcmF0aGVyIHRoYW4gbXVzdCBiZWNhdXNlIHdlIGtub3cg dGhhdCB0aGVyZSBhcmUgZXh0ZW51YXRpbmcgY2lyY3Vtc3RhbmNlcyBhbmQgYWNrbm93bGVkZ2lu ZyB0aGF0IHdlIHRyaWVkIHRvIGtlZXAgaXQgc2ltcGxlLg0KDQogMS4gIDMuMSAgIFRoZSB0ZXh0 IHNvcnQgb2YgY2lyY2xlcyBhcm91bmQgYSBjb3VwbGUgb2Ygc2NlbmFyaW9zIGFuZCBpdCBmaW5h bGx5IHNldHRsZXMgb24g4oCcYSBuZXcgUk9BIFNIT1VMRCBhbHNvIGJlIGNyZWF0ZWQgdGhhdCBh dXRob3JpemVzIEFTNjQ1MDDigJ0uICBTaG91bGRu4oCZdCBpdCBiZSBhIOKAmE1VU1TigJk/ICBJ biB0aGUgc2FtZSBwYXJhZ3JhcGggeW91IG1ha2UgdGhlIHBvaW50IHRoYXQgdGhlICJ2YWxpZGF0 aW9uIGNoZWNrIHdpbGwgZmFpbCB1bmxlc3MgYSBST0EgaXMgKmFsc28qIGF2YWlsYWJsZSBmb3Ig QVM2NDUwMOKAnS4uICBJ4oCZbSBndWVzc2luZyB0aGF0IHRoZSDigJhTSE9VTETigJkgaXMgdXNl ZCBpbiBjYXNlIHRoZXJlIGFyZSByb3V0ZXMgd2hpY2ggQVM2NDUwMCBpcyBub3Qgb3JpZ2luYXRp bmcgeWV0Li5idXQgaXQgaXMganVzdCBjb25mdXNpbmcgdG8gbWUgd2hhdCBleGFjdGx5IGlzIGlu dGVuZGVkLg0KDQpXR10gSSBjaGFuZ2VkIGl0IHRvIE1VU1QuIEhhdmluZyBhbiBhZGRpdGlvbmFs IFJPQSBpc24ndCBhIGJpZyBkZWFsLCBhbmQgc28gZXZlbiBpZiB0aG9zZSBhcmUgYWxsIGdlbmVy YXRlZCB1cCBmcm9udCBiZWZvcmUgbWlncmF0aW9uIHN0YXJ0cyBmb3IgYW55IHByZWZpeGVzLCB0 aGUgcmlnaHQgdGhpbmcgd2lsbCBoYXBwZW4uDQoNCiAxLiAgMy4yLjEgcy9NVVNUL211c3QgICAg IFlvdeKAmXJlIG1ha2luZyByZWZlcmVuY2UgdG8gc29tZXRoaW5nIHRoYXQgaXMgbm90IHNwZWNp ZmllZCBpbiBhbm90aGVyIGRvY3VtZW50Li4NCg0KV0ddIHJpZ2h0LCBJJ20gb2JzZXJ2aW5nIHRo YXQgdGhlIGJlaGF2aW9yIGlzIG5vdCBub3JtYXRpdmVseSBzcGVjaWZpZWQsIGhlbmNlIHRoZSBj YXBzLg0KDQogMS4gIFNlY3Rpb24gNS4gIFlvdSBsb3N0IG1lIGhlcmUgKGVuZCBvZiB0aGUgc2Vj b25kIHBhcmFncmFwaCk6IOKAnC4gLiAudGhlIG1vc3QgYXBwcm9wcmlhdGUgcGxhY2UgdG8gaW1w bGVtZW50IHRoaXMgaXMgb24gdGhlIGxvY2FsIFBFIHRoYXQgc3RpbGwgaGFzIGVCR1Agc2Vzc2lv bnMgYXNzb2NpYXRlZCB3aXRoIEFTNjQ1MTAgKHVzaW5nIHRoZSB0cmFuc2l0aW9uIGtub2JzIGRl dGFpbGVkIGluIHRoZSBjb21wYW5pb24gZHJhZnQpLiAgU2luY2UgdGhhdCBQRSBoYXMgYmVlbiBt b3ZlZCB0byBBUzY0NTAwLCBpdCBpcyBub3QgcG9zc2libGUgZm9yIGl0IHRvIGZvcndhcmQtc2ln biBBUzY0NTEwIHdpdGggcENvdW50PTAgLiAuIC7igJ0gIFlvdSBmaXJzdCBzYWlkIHRoYXQgdGhl IFBFIGhhcyBzZXNzaW9ucyBhc3NvY2lhdGVkIHdpdGggQVM2NDUxMCwgYnV0IHRoZW4gc2FpZCB0 aGF0IGl0IGhhZCBtb3ZlZCB0byBBUzY0NTAwLCB3aGF0IGFtIEkgbWlzc2luZz8gIE1heWJlIHlv deKAmXJlIHJlZmVycmluZyB0byBhIHNwZWNpZmljIHNlc3Npb24uLg0KDQpXR10gd2hhdCBJIG1l YW4gaXMgdGhhdCBpdCBzdGlsbCBoYXMgcGVlcnMgZXhwZWN0aW5nIGl0IHRvIGJlIDY0NTEwLiBS ZXBsYWNlZCAic2Vzc2lvbnMgYXNzb2NpYXRlZCB3aXRoIiB3aXRoICJzZXNzaW9ucyB3aXRoIHBl ZXJzIGV4cGVjdGluZyB0byBwZWVyIHdpdGgiDQoNCiAxLiAgNS4zICAiV2hpbGUgdGhpcyBpcyBu b3QgcHJvaGliaXRlZCBieSBCR1BTZWMgW0ktRC5pZXRmLXNpZHItYmdwc2VjLXByb3RvY29sXSwg cm91dGVycyB0aGF0IHJlY2VpdmUgdXBkYXRlcyBmcm9tIGlCR1AgbmVpZ2hib3JzIE1VU1QgTk9U IHJlamVjdCB1cGRhdGVzIHdpdGggbmV3ICh2YWxpZCkgQkdQU2VjIGF0dHJpYnV0ZXMuLuKAnSAg RG9lcyB0aGlzIHJlcHJlc2VudCBhbiB1cGRhdGUgdG8gQkdQU2VjPyAgQXJlIHlvdSBpbXBseWlu ZyB0aGF0IHRoZSBpQkdQIHJlY2VpdmVyIHNob3VsZCBjaGVjayB0aGUgdmFsaWRpdHkgb2YgdGhl IGF0dHJpYnV0ZXM/ICBJIGtub3cgdGhhdCBhdCB0aGlzIHBvaW50IGl0IGlzIGEgbGl0dGxlIHdl aXJkIHRvIHVwZGF0ZSBhIGRyYWZ0IChub3QgYW4gUkZDKSwgYnV0IHRoZSBwcm9jZXNzIHNob3Vs ZCB0YWtlIGNhcmUgb2YgdGhlIGFwcHJvcHJpYXRlIHJlZmVyZW5jZXMuIFtNYXliZSB0aGUgdXBk YXRlIGlzIG5vdCBuZWVkZWQgYmFzZWQgb24gdGhlIGRpc2N1c3Npb24gaW4gdGhlIFdHIHRvZGF5 Ll0NCg0KV0ddIHdoYXQgdGhpcyBpcyBzYXlpbmcgaXMgdGhhdCBCR1BTZWMgaXMgY3VycmVudGx5 IHNpbGVudCBvbiB0aGlzLCBhbmQgbWFraW5nIGFuIHVwZGF0ZSB0byBjbGFyaWZ5IHdoYXQgdGhl IGJlaGF2aW9yIG5lZWRzIHRvIGJlLiBBcyB0byB3aGV0aGVyIHRoZSB1cGRhdGVzIG5lZWQgdG8g YmUgdmFsaWRhdGVkIGluIGlCR1AsIEknbSBub3QgZXhwbGljaXRseSByZXF1aXJpbmcgdGhhdCwg YXMgSSB0aGluayBpdCdzIHJlYWxseSBtb3JlIG9mIGFuIGltcGxlbWVudGF0aW9uIGRldGFpbC4N Cg0KTml0czoNCg0KIDEuICBJbnRyb2R1Y3Rpb24uICBKdXN0IGEgc3R5bGUgcHJlZmVyZW5jZTog IGdldCB0byB0aGUgcG9pbnQgZmFzdGVyLiAgTWF5YmUgc29tZXRoaW5nIG1vcmUgZGlyZWN0IGxp a2U6IOKAnEEgbWV0aG9kIG9mIG1hbmFnaW5nIGFuIEFTTiBtaWdyYXRpb24gbm90IGZvcm1hbGx5 IHBhcnQgb2YgdGhlIEJHUDQgW1JGQzQyNzFdIHByb3RvY29sIHNwZWNpZmljYXRpb24gaXMgZGVz Y3JpYmVkIGluIFtJLUQuaWV0Zi1pZHItYXMtbWlncmF0aW9uXS4gIEFjY29yZGluZ2x5LCBpdCBp cyBuZWNlc3NhcnkgLiAuIC7igJ0NCg0KV0ddIGFjaywgc29tZSBvZiB0aGF0IHdhcyBhIGhvbGRv dmVyIGZyb20gcHJldmlvdXMgdmVyc2lvbnMgb2YgdGhlIGRvYywgY2xlYW5lZCBpdCB1cA0KDQog MS4gIHMvZHJhZnQvZG9jdW1lbnQNCg0KV0ddIGFjaw0KDQogMS4gIFNlY3Rpb24gMi4gIHMvRmln dXJlIDEvRmlndXJlcyAxIGFuZCAyLyAgICBCVFcsIGl0IHdvdWxkIGJlIG5pY2UgKGV2ZW4gaWYg dGhleeKAmXJlIHJlZmVyZW5jZWQpIHRvIHBhc3RlIGEgY29weSBvZiB0aGUgZmlndXJlcy4NCg0K V0ddIHdoYXQgc2F5IHlvdSwgU0lEUiBmb2xrcz8NCg0KIDEuICBTZWN0aW9uIDMuICBzLyJUaGUg bWV0aG9kcyBhbmQgaW1wbGVtZW50YXRpb24gZGlzY3Vzc2VkIGluIGRyYWZ0LWlldGYtaWRyLWFz LW1pZ3JhdGlvbi4gLiAuIHdpZGVseSB1c2Vk4oCdL1RoZSBmdW5jdGlvbmFsaXR5IGRlc2NyaWJl ZCBpbiBbSS1ELmlldGYtaWRyLWFzLW1pZ3JhdGlvbl0gaXMgd2lkZWx5IHVzZWQNCg0KV0ddIGFj aw0KDQogMS4gIDMuMSAg4oCcb3JpZ2luIHZhbGlkYXRpb27igJ0gYW5kIOKAnHJlcGxhY2UtYXPi gJ0gbmVlZCBhIHJlZmVyZW5jZS4NCg0KV0ddIEFDSw0KDQogMS4gIDMuMi4xIFJlZmVyZW5jZSBm b3Ig4oCcQkdQU2VjIHByb3RvY29sIHNwZWNpZmljYXRpb27igJ0sIGFuZCDigJxyZW1vdGUtYXPi gJ0uDQoNCldHXSBmaXhlZCBCR1BTZWMsIGRvbid0IGtub3cgd2hhdCB5b3UnZCBsaWtlIG1lIHRv IHJlZmVyZW5jZSBmb3IgcmVtb3RlLWFzLg0KDQogMS4gIHMvQVMgUGF0aC9BU19QQVRIDQoNCldH XSBHZW5lcmFsbHksIEkgdXNlZCB0aGUgYWxsIGNhcHMgd2hlbiByZWZlcnJpbmcgc3BlY2lmaWNh bGx5IHRvIHRoZSBhdHRyaWJ1dGUsIGFuZCBBUyBQYXRoIGZvciBtb3JlIGdlbmVyaWMgaW5zdGFu Y2VzIG1lYW5pbmcgImEgbGlzdCBvZiBBU05zIi4gSWYgeW91IHdhbnQgdG8gcG9pbnQgdG8gc3Bl Y2lmaWMgYXJlYXMgb2YgdGhlIHRleHQgd2hlcmUgdGhlIHdyb25nIG9uZSB3YXMgdXNlZCwgSSds bCBiZSBoYXBweSB0byBmaXgsIGJ1dCBJJ20gbm90IGNlcnRhaW4gdGhhdCBnbG9iYWxseSBzd2l0 Y2hpbmcgdG8gQVNfUEFUSCBpcyB0aGUgcmlnaHQgdGhpbmcgdG8gZG8uDQoNCl9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQpUaGlzIEUtbWFpbCBhbmQgYW55IG9mIGl0cyBhdHRhY2ht ZW50cyBtYXkgY29udGFpbiBUaW1lIFdhcm5lciBDYWJsZSBwcm9wcmlldGFyeSBpbmZvcm1hdGlv biwgd2hpY2ggaXMgcHJpdmlsZWdlZCwgY29uZmlkZW50aWFsLCBvciBzdWJqZWN0IHRvIGNvcHly aWdodCBiZWxvbmdpbmcgdG8gVGltZSBXYXJuZXIgQ2FibGUuIFRoaXMgRS1tYWlsIGlzIGludGVu ZGVkIHNvbGVseSBmb3IgdGhlIHVzZSBvZiB0aGUgaW5kaXZpZHVhbCBvciBlbnRpdHkgdG8gd2hp Y2ggaXQgaXMgYWRkcmVzc2VkLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50 IG9mIHRoaXMgRS1tYWlsLCB5b3UgYXJlIGhlcmVieSBub3RpZmllZCB0aGF0IGFueSBkaXNzZW1p bmF0aW9uLCBkaXN0cmlidXRpb24sIGNvcHlpbmcsIG9yIGFjdGlvbiB0YWtlbiBpbiByZWxhdGlv biB0byB0aGUgY29udGVudHMgb2YgYW5kIGF0dGFjaG1lbnRzIHRvIHRoaXMgRS1tYWlsIGlzIHN0 cmljdGx5IHByb2hpYml0ZWQgYW5kIG1heSBiZSB1bmxhd2Z1bC4gSWYgeW91IGhhdmUgcmVjZWl2 ZWQgdGhpcyBFLW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBpbW1lZGlh dGVseSBhbmQgcGVybWFuZW50bHkgZGVsZXRlIHRoZSBvcmlnaW5hbCBhbmQgYW55IGNvcHkgb2Yg dGhpcyBFLW1haWwgYW5kIGFueSBwcmludG91dC4NCg== --_000_D14050384BA64wesleygeorgetwcablecom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx NHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPGRpdj4NCjxkaXY+DQo8 ZGl2PkFkZGVkIFNJRFIsIHJlc3BvbnNlcyBiZWxvdyBpbmxpbmUsIHdoaWNoIG9mIGNvdXJzZSBt ZXNzZWQgdXAgeW91ciBvcmlnaW5hbCBudW1iZXJpbmcuPC9kaXY+DQo8ZGl2PkkgaGF2ZW4ndCBw dXNoZWQgdGhlIHJldiB5ZXQsIGFzIEknbSB3YWl0aW5nIHRvIG1ha2Ugc3VyZSB0aGF0IEkgZG9u J3QgbmVlZCB0byBtYWtlIGFkZGl0aW9uYWwgY2hhbmdlcyBiYXNlZCBvbiB0aGUgcmV2aXNpb24g dG8gdGhlIEJHUFNlYyBwcm90b2NvbCBkb2MuJm5ic3A7PC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4w MDAxcHQ7IGZvbnQtc2l6ZTogMTFwdDsiPlRoYW5rcyw8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTog MTFwdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMXB0OyI+V2VzPG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAw MXB0OyBmb250LXNpemU6IDExcHQ7Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjxzcGFuIGlkPSJPTEtfU1JDX0JPRFlfU0VDVElPTiI+DQo8ZGl2IHN0eWxl PSJmb250LWZhbWlseTpDYWxpYnJpOyBmb250LXNpemU6MTFwdDsgdGV4dC1hbGlnbjpsZWZ0OyBj b2xvcjpibGFjazsgQk9SREVSLUJPVFRPTTogbWVkaXVtIG5vbmU7IEJPUkRFUi1MRUZUOiBtZWRp dW0gbm9uZTsgUEFERElORy1CT1RUT006IDBpbjsgUEFERElORy1MRUZUOiAwaW47IFBBRERJTkct UklHSFQ6IDBpbjsgQk9SREVSLVRPUDogI2I1YzRkZiAxcHQgc29saWQ7IEJPUkRFUi1SSUdIVDog bWVkaXVtIG5vbmU7IFBBRERJTkctVE9QOiAzcHQiPg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0 OmJvbGQiPkZyb206IDwvc3Bhbj4mcXVvdDtBbHZhcm8gUmV0YW5hIChhcmV0YW5hKSZxdW90OyAm bHQ7PGEgaHJlZj0ibWFpbHRvOmFyZXRhbmFAY2lzY28uY29tIj5hcmV0YW5hQGNpc2NvLmNvbTwv YT4mZ3Q7PGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPkRhdGU6IDwvc3Bhbj5N b25kYXksIE1hcmNoIDIzLCAyMDE1IGF0IDExOjE4IEFNPGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQt d2VpZ2h0OmJvbGQiPlRvOiA8L3NwYW4+JnF1b3Q7R2VvcmdlLCBXZXMmcXVvdDsgJmx0OzxhIGhy ZWY9Im1haWx0bzp3ZXNsZXkuZ2VvcmdlQHR3Y2FibGUuY29tIj53ZXNsZXkuZ2VvcmdlQHR3Y2Fi bGUuY29tPC9hPiZndDs8YnI+DQo8c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+Q2M6IDwv c3Bhbj4mcXVvdDs8YSBocmVmPSJtYWlsdG86ZHJhZnQtaWV0Zi1zaWRyLWFzLW1pZ3JhdGlvbkB0 b29scy5pZXRmLm9yZyI+ZHJhZnQtaWV0Zi1zaWRyLWFzLW1pZ3JhdGlvbkB0b29scy5pZXRmLm9y ZzwvYT4mcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzpkcmFmdC1pZXRmLXNpZHItYXMtbWlncmF0 aW9uQHRvb2xzLmlldGYub3JnIj5kcmFmdC1pZXRmLXNpZHItYXMtbWlncmF0aW9uQHRvb2xzLmll dGYub3JnPC9hPiZndDs8YnI+DQo8c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+U3ViamVj dDogPC9zcGFuPlJldmlldyBvZiBkcmFmdC1pZXRmLXNpZHItYXMtbWlncmF0aW9uPGJyPg0KPC9k aXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9IndvcmQtd3JhcDogYnJl YWstd29yZDsgLXdlYmtpdC1uYnNwLW1vZGU6IHNwYWNlOyAtd2Via2l0LWxpbmUtYnJlYWs6IGFm dGVyLXdoaXRlLXNwYWNlOyBjb2xvcjogcmdiKDAsIDAsIDApOyBmb250LXNpemU6IDE0cHg7IGZv bnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyI+DQo8ZGl2IHN0eWxlPSJjb2xvcjogcmdi KDAsIDAsIDApOyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgZm9udC1zaXplOiAx NHB4OyI+DQpNaW5vcjo8L2Rpdj4NCjxvbD4NCjxsaSBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAw KTsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTRweDsiPg0K SXQgd291bGQgYmUgbmljZSB0byBoYXZlIHNvbWUgc29ydCBvZiByb2FkIG1hcCBpbiB0aGUgSW50 cm9kdWN0aW9uLiAmbmJzcDtJbmRpY2F0aW5nIHRoYXQgU2VjdGlvbiAzIHByZXNlbnRzIHRoZSBw cm9ibGVtLCA0IHRoZSByZXF1aXJlbWVudHMgYW5kIDUgdGhlIHNvbHV0aW9uIGl0c2VsZi4gJm5i c3A7RXZlbiB0aG91Z2ggc2VjdGlvbiA1IGluIGluIGZhY3QgbmFtZWQg4oCYU29sdXRpb27igJkg aXQgaXMgbm90IGNsZWFyLCBhdCBsZWFzdCBub3QgdG8gbWUgd2hhdCB0aGUNCiBvcmRlciBvZiB0 aGUgZG9jdW1lbnQgaXM7IHdoZW4gcmVhZGluZyBzZWN0aW9uIDMgSSBrZXB0IHdvbmRlcmluZyB0 byBteXNlbGYg4oCcd2hhdCBhYm91dCB0aGUgc29sdXRpb24/4oCdLjwvbGk+PC9vbD4NCjwvZGl2 Pg0KPC9kaXY+DQo8L3NwYW4+PHNwYW4gaWQ9Ik9MS19TUkNfQk9EWV9TRUNUSU9OIj4NCjxkaXY+ DQo8ZGl2IHN0eWxlPSJ3b3JkLXdyYXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBz cGFjZTsgLXdlYmtpdC1saW5lLWJyZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigw LCAwLCAwKTsgZm9udC1zaXplOiAxNHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJp ZjsiPg0KPGRpdj5XR10gaXNuJ3QgdGhpcyB3aGF0IHRoZSB0YWJsZSBvZiBjb250ZW50cyBpcyBm b3I/IFRoaXMgaXNuJ3QgYSBsb25nIGVub3VnaCBkb2N1bWVudCB0aGF0IGl0IHJlYWxseSBuZWVk cyBhbiAmcXVvdDthZ2VuZGEgc2xpZGUmcXVvdDs8L2Rpdj4NCjxvbD4NCjxsaSBzdHlsZT0iY29s b3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGZvbnQt c2l6ZTogMTRweDsiPg0KU2VjdGlvbiAzLiBzL1NIT1VMRCBOT1Qvc2hvdWxkIG5vdCAmbmJzcDsg Jm5ic3A7IFdlIGNhbuKAmXQgdXNlIHJmYzIxMTkgbGFuZ3VhZ2UgdG8gbWFuZGF0ZSB0aGUgYmVo YXZpb3Igb2YgYW4gb3BlcmF0b3I7IGluIHRoaXMgY2FzZSByZWxhdGVkIHRvIHRoZSBhbW91bnQg b2YgdGltZSB0aGUgdHJhbnNpdGlvbiBwaGFzZSBsYXN0cy4gJm5ic3A7SSB0aGluayB5b3UgaGF2 ZSBtYWRlIGEgZ29vZCBwb2ludCBhYm91dCB0aGUgbmVlZCB0byBub3Qgc3RheSB0aGVyZSBmb3Jl dmVyLA0KIGJ1dCBoYXZlIGFsc28gc2FpZCB0aGF0IHRoZSB0cmFuc2l0aW9uIGlzIG5vdCBhbHdh eXMgdW5kZXIgdGhlIGNvbnRyb2wgb2YgdGhlIG9wZXJhdG9yLjwvbGk+PC9vbD4NCjwvZGl2Pg0K PC9kaXY+DQo8L3NwYW4+PHNwYW4gaWQ9Ik9MS19TUkNfQk9EWV9TRUNUSU9OIj4NCjxkaXY+DQo8 ZGl2IHN0eWxlPSJ3b3JkLXdyYXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFj ZTsgLXdlYmtpdC1saW5lLWJyZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAw LCAwKTsgZm9udC1zaXplOiAxNHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsi Pg0KPGRpdj5XR10gSSBkaXNhZ3JlZSB3aXRoIHRoZSBibGFua2V0IGFzc2VydGlvbiB0aGF0IHdl IGNhbid0IG5vcm1hdGl2ZWx5IG1hbmRhdGUgdGhlIGJlaGF2aW9yIG9mIGFuIG9wZXJhdG9yIGlu IHRoZSBjb250ZXh0IG9mIGEgc3RhbmRhcmQgb3IgQkNQIGRvY3VtZW50LCBhbmQgSSB0aGluayB0 aGF0IHRoZSBndWlkYW5jZSBpcyBjb3JyZWN0IGhlcmUg4oCTIG9wZXJhdG9ycyBTSE9VTEQgTk9U IHN0YXkgaW4gdHJhbnNpdGlvbiBpbmRlZmluaXRlbHkuDQogU2hvdWxkIHJhdGhlciB0aGFuIG11 c3QgYmVjYXVzZSB3ZSBrbm93IHRoYXQgdGhlcmUgYXJlIGV4dGVudWF0aW5nIGNpcmN1bXN0YW5j ZXMgYW5kIGFja25vd2xlZGdpbmcgdGhhdCB3ZSB0cmllZCB0byBrZWVwIGl0IHNpbXBsZS48L2Rp dj4NCjxvbD4NCjxsaSBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IENh bGlicmksIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTRweDsiPg0KMy4xICZuYnNwOyBUaGUgdGV4 dCBzb3J0IG9mIGNpcmNsZXMgYXJvdW5kIGEgY291cGxlIG9mIHNjZW5hcmlvcyBhbmQgaXQgZmlu YWxseSBzZXR0bGVzIG9uIOKAnGEgbmV3IFJPQSBTSE9VTEQgYWxzbyBiZSBjcmVhdGVkIHRoYXQg YXV0aG9yaXplcyBBUzY0NTAw4oCdLiAmbmJzcDtTaG91bGRu4oCZdCBpdCBiZSBhIOKAmE1VU1Ti gJk/ICZuYnNwO0luIHRoZSBzYW1lIHBhcmFncmFwaCB5b3UgbWFrZSB0aGUgcG9pbnQgdGhhdCB0 aGUgJnF1b3Q7dmFsaWRhdGlvbiBjaGVjayB3aWxsIGZhaWwgdW5sZXNzDQogYSBST0EgaXMgKmFs c28qIGF2YWlsYWJsZSBmb3IgQVM2NDUwMOKAnS4uICZuYnNwO0nigJltIGd1ZXNzaW5nIHRoYXQg dGhlIOKAmFNIT1VMROKAmSBpcyB1c2VkIGluIGNhc2UgdGhlcmUgYXJlIHJvdXRlcyB3aGljaCBB UzY0NTAwIGlzIG5vdCBvcmlnaW5hdGluZyB5ZXQuLmJ1dCBpdCBpcyBqdXN0IGNvbmZ1c2luZyB0 byBtZSB3aGF0IGV4YWN0bHkgaXMgaW50ZW5kZWQuPC9saT48L29sPg0KPC9kaXY+DQo8L2Rpdj4N Cjwvc3Bhbj4NCjxkaXY+V0ddIEkgY2hhbmdlZCBpdCB0byBNVVNULiBIYXZpbmcgYW4gYWRkaXRp b25hbCBST0EgaXNuJ3QgYSBiaWcgZGVhbCwgYW5kIHNvIGV2ZW4gaWYgdGhvc2UgYXJlIGFsbCBn ZW5lcmF0ZWQgdXAgZnJvbnQgYmVmb3JlIG1pZ3JhdGlvbiBzdGFydHMgZm9yIGFueSBwcmVmaXhl cywgdGhlIHJpZ2h0IHRoaW5nIHdpbGwgaGFwcGVuLjwvZGl2Pg0KPHNwYW4gaWQ9Ik9MS19TUkNf Qk9EWV9TRUNUSU9OIj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJ3b3JkLXdyYXA6IGJyZWFrLXdvcmQ7 IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJyZWFrOiBhZnRlci13aGl0 ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAxNHB4OyBmb250LWZhbWls eTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPG9sPg0KPGxpIHN0eWxlPSJjb2xvcjogcmdiKDAs IDAsIDApOyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgZm9udC1zaXplOiAxNHB4 OyI+DQozLjIuMSBzL01VU1QvbXVzdCAmbmJzcDsgJm5ic3A7IFlvdeKAmXJlIG1ha2luZyByZWZl cmVuY2UgdG8gc29tZXRoaW5nIHRoYXQgaXMgbm90IHNwZWNpZmllZCBpbiBhbm90aGVyIGRvY3Vt ZW50Li4NCjwvbGk+PC9vbD4NCjwvZGl2Pg0KPC9kaXY+DQo8L3NwYW4+DQo8ZGl2PldHXSByaWdo dCwgSSdtIG9ic2VydmluZyB0aGF0IHRoZSBiZWhhdmlvciBpcyBub3Qgbm9ybWF0aXZlbHkgc3Bl Y2lmaWVkLCBoZW5jZSB0aGUgY2Fwcy48L2Rpdj4NCjxzcGFuIGlkPSJPTEtfU1JDX0JPRFlfU0VD VElPTiI+DQo8ZGl2IHN0eWxlPSJ3b3JkLXdyYXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1t b2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJyZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6 IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAxNHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fu cy1zZXJpZjsiPg0KPG9sPg0KPGxpIHN0eWxlPSJjb2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZh bWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgZm9udC1zaXplOiAxNHB4OyI+DQo8Zm9udCBmYWNl PSJDYWxpYnJpLHNhbnMtc2VyaWYiIHN0eWxlPSJjb2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZh bWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgZm9udC1zaXplOiAxNHB4OyI+U2VjdGlvbiA1LiAm bmJzcDtZb3UgbG9zdCBtZSBoZXJlIChlbmQgb2YgdGhlIHNlY29uZCBwYXJhZ3JhcGgpOiZuYnNw O+KAnC4gLiAuPC9mb250Pjxmb250IGZhY2U9IkNhbGlicmksc2Fucy1zZXJpZiIgc3R5bGU9ImNv bG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBmb250 LXNpemU6IDE0cHg7Ij50aGUNCiBtb3N0IGFwcHJvcHJpYXRlIHBsYWNlIHRvIGltcGxlbWVudCB0 aGlzIGlzJm5ic3A7PC9mb250PjxzcGFuIHN0eWxlPSJjb2xvcjogcmdiKDAsIDAsIDApOyBmb250 LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgZm9udC1zaXplOiAxNHB4OyI+b24gdGhlIGxv Y2FsIFBFIHRoYXQgc3RpbGwgaGFzIGVCR1Agc2Vzc2lvbnMgYXNzb2NpYXRlZCB3aXRoIEFTNjQ1 MTAmbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFt aWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDE0cHg7Ij4odXNpbmcNCiB0aGUg dHJhbnNpdGlvbiBrbm9icyBkZXRhaWxlZCBpbiB0aGUgY29tcGFuaW9uIGRyYWZ0KS4gJm5ic3A7 U2luY2UmbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQt ZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDE0cHg7Ij50aGF0IFBFIGhh cyBiZWVuIG1vdmVkIHRvIEFTNjQ1MDAsIGl0IGlzIG5vdCBwb3NzaWJsZSBmb3IgaXQgdG8mbmJz cDs8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBD YWxpYnJpLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDE0cHg7Ij5mb3J3YXJkLXNpZ24NCiBBUzY0 NTEwIHdpdGggcENvdW50PTAgLiAuIC48L3NwYW4+PGZvbnQgZmFjZT0iQ2FsaWJyaSxzYW5zLXNl cmlmIj7igJ0gJm5ic3A7WW91IGZpcnN0IHNhaWQgdGhhdCB0aGUgUEUgaGFzIHNlc3Npb25zIGFz c29jaWF0ZWQgd2l0aCBBUzY0NTEwLCBidXQgdGhlbiBzYWlkIHRoYXQgaXQgaGFkIG1vdmVkIHRv IEFTNjQ1MDAsIHdoYXQgYW0mbmJzcDtJIG1pc3Npbmc/ICZuYnNwO01heWJlIHlvdeKAmXJlJm5i c3A7cmVmZXJyaW5nIHRvIGEgc3BlY2lmaWMgc2Vzc2lvbi4uPC9mb250PjwvbGk+PC9vbD4NCjwv ZGl2Pg0KPC9zcGFuPg0KPGRpdj5XR10gd2hhdCBJIG1lYW4gaXMgdGhhdCBpdCBzdGlsbCBoYXMg cGVlcnMgZXhwZWN0aW5nIGl0IHRvIGJlIDY0NTEwLiBSZXBsYWNlZCAmcXVvdDtzZXNzaW9ucyBh c3NvY2lhdGVkIHdpdGgmcXVvdDsgd2l0aCAmcXVvdDtzZXNzaW9ucyB3aXRoIHBlZXJzIGV4cGVj dGluZyB0byBwZWVyIHdpdGgmcXVvdDs8L2Rpdj4NCjxzcGFuIGlkPSJPTEtfU1JDX0JPRFlfU0VD VElPTiI+DQo8ZGl2IHN0eWxlPSJ3b3JkLXdyYXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1t b2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJyZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6 IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAxNHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fu cy1zZXJpZjsiPg0KPG9sPg0KPGxpPjxmb250IGZhY2U9IkNhbGlicmksc2Fucy1zZXJpZiIgc3R5 bGU9ImNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlm OyBmb250LXNpemU6IDE0cHg7Ij41LjMgJm5ic3A7JnF1b3Q7PC9mb250PjxzcGFuIHN0eWxlPSJj b2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgZm9u dC1zaXplOiAxNHB4OyI+V2hpbGUgdGhpcyBpcyBub3QgcHJvaGliaXRlZCBieSBCR1BTZWMmbmJz cDs8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBD YWxpYnJpLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDE0cHg7Ij5bSS1ELmlldGYtc2lkci1iZ3Bz ZWMtcHJvdG9jb2xdLA0KIHJvdXRlcnMgdGhhdCByZWNlaXZlIHVwZGF0ZXMgZnJvbSZuYnNwOzwv c3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IENhbGli cmksIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTRweDsiPmlCR1AgbmVpZ2hib3JzIE1VU1QgTk9U IHJlamVjdCB1cGRhdGVzIHdpdGggbmV3ICh2YWxpZCkgQkdQU2VjJm5ic3A7PC9zcGFuPjxmb250 IGZhY2U9IkNhbGlicmksc2Fucy1zZXJpZiI+YXR0cmlidXRlcy4u4oCdICZuYnNwO0RvZXMgdGhp cyByZXByZXNlbnQNCiBhbiB1cGRhdGUgdG8gQkdQU2VjPyAmbmJzcDtBcmUgeW91IGltcGx5aW5n IHRoYXQgdGhlIGlCR1AgcmVjZWl2ZXImbmJzcDtzaG91bGQgY2hlY2sgdGhlIHZhbGlkaXR5IG9m IHRoZSBhdHRyaWJ1dGVzPyAmbmJzcDtJIGtub3cgdGhhdCBhdCB0aGlzIHBvaW50IGl0IGlzIGEg bGl0dGxlIHdlaXJkIHRvIHVwZGF0ZSBhIGRyYWZ0IChub3QgYW4gUkZDKSwgYnV0IHRoZSBwcm9j ZXNzJm5ic3A7c2hvdWxkIHRha2UgY2FyZSBvZiB0aGUgYXBwcm9wcmlhdGUgcmVmZXJlbmNlcy4g W01heWJlDQogdGhlIHVwZGF0ZSBpcyBub3QgbmVlZGVkIGJhc2VkIG9uIHRoZSBkaXNjdXNzaW9u IGluIHRoZSBXRyB0b2RheS5dPC9mb250PjwvbGk+PC9vbD4NCjwvZGl2Pg0KPC9zcGFuPg0KPGRp dj5XR10gd2hhdCB0aGlzIGlzIHNheWluZyBpcyB0aGF0IEJHUFNlYyBpcyBjdXJyZW50bHkgc2ls ZW50IG9uIHRoaXMsIGFuZCBtYWtpbmcgYW4gdXBkYXRlIHRvIGNsYXJpZnkgd2hhdCB0aGUgYmVo YXZpb3IgbmVlZHMgdG8gYmUuIEFzIHRvIHdoZXRoZXIgdGhlIHVwZGF0ZXMgbmVlZCB0byBiZSB2 YWxpZGF0ZWQgaW4gaUJHUCwgSSdtIG5vdCBleHBsaWNpdGx5IHJlcXVpcmluZyB0aGF0LCBhcyBJ IHRoaW5rIGl0J3MgcmVhbGx5IG1vcmUgb2YNCiBhbiBpbXBsZW1lbnRhdGlvbiBkZXRhaWwuPC9k aXY+DQo8c3BhbiBpZD0iT0xLX1NSQ19CT0RZX1NFQ1RJT04iPg0KPGRpdj4NCjxkaXYgc3R5bGU9 IndvcmQtd3JhcDogYnJlYWstd29yZDsgLXdlYmtpdC1uYnNwLW1vZGU6IHNwYWNlOyAtd2Via2l0 LWxpbmUtYnJlYWs6IGFmdGVyLXdoaXRlLXNwYWNlOyBjb2xvcjogcmdiKDAsIDAsIDApOyBmb250 LXNpemU6IDE0cHg7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyI+DQo8ZGl2IHN0 eWxlPSJjb2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJp ZjsgZm9udC1zaXplOiAxNHB4OyI+DQo8YnI+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9ImNvbG9yOiBy Z2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBmb250LXNpemU6 IDE0cHg7Ij4NCk5pdHM6PC9kaXY+DQo8b2wgc3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwgMCk7IGZv bnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDE0cHg7Ij4NCjxsaSBz dHlsZT0iY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2Vy aWY7IGZvbnQtc2l6ZTogMTRweDsiPg0KSW50cm9kdWN0aW9uLiAmbmJzcDtKdXN0IGEgc3R5bGUg cHJlZmVyZW5jZTogJm5ic3A7Z2V0IHRvIHRoZSBwb2ludCBmYXN0ZXIuICZuYnNwO01heWJlIHNv bWV0aGluZyBtb3JlIGRpcmVjdCBsaWtlOiDigJxBIG1ldGhvZCBvZiBtYW5hZ2luZyBhbiBBU04g bWlncmF0aW9uIG5vdCBmb3JtYWxseSBwYXJ0IG9mIHRoZSBCR1A0IFtSRkM0MjcxXSBwcm90b2Nv bCBzcGVjaWZpY2F0aW9uIGlzIGRlc2NyaWJlZCBpbiBbSS1ELmlldGYtaWRyLWFzLW1pZ3JhdGlv bl0uICZuYnNwO0FjY29yZGluZ2x5LA0KIGl0IGlzIG5lY2Vzc2FyeSAuIC4gLuKAnTwvbGk+PC9v bD4NCjwvZGl2Pg0KPC9kaXY+DQo8L3NwYW4+DQo8ZGl2PldHXSBhY2ssIHNvbWUgb2YgdGhhdCB3 YXMgYSBob2xkb3ZlciBmcm9tIHByZXZpb3VzIHZlcnNpb25zIG9mIHRoZSBkb2MsIGNsZWFuZWQg aXQgdXA8L2Rpdj4NCjxzcGFuIGlkPSJPTEtfU1JDX0JPRFlfU0VDVElPTiI+DQo8ZGl2Pg0KPGRp diBzdHlsZT0id29yZC13cmFwOiBicmVhay13b3JkOyAtd2Via2l0LW5ic3AtbW9kZTogc3BhY2U7 IC13ZWJraXQtbGluZS1icmVhazogYWZ0ZXItd2hpdGUtc3BhY2U7IGNvbG9yOiByZ2IoMCwgMCwg MCk7IGZvbnQtc2l6ZTogMTRweDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7Ij4N CjxvbCBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IENhbGlicmksIHNh bnMtc2VyaWY7IGZvbnQtc2l6ZTogMTRweDsiPg0KPGxpIHN0eWxlPSJjb2xvcjogcmdiKDAsIDAs IDApOyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgZm9udC1zaXplOiAxNHB4OyI+ DQpzL2RyYWZ0L2RvY3VtZW50IDwvbGk+PC9vbD4NCjwvZGl2Pg0KPC9kaXY+DQo8L3NwYW4+DQo8 ZGl2PldHXSBhY2s8L2Rpdj4NCjxzcGFuIGlkPSJPTEtfU1JDX0JPRFlfU0VDVElPTiI+DQo8ZGl2 IHN0eWxlPSJ3b3JkLXdyYXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsg LXdlYmtpdC1saW5lLWJyZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAw KTsgZm9udC1zaXplOiAxNHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0K PG9sIHN0eWxlPSJjb2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fu cy1zZXJpZjsgZm9udC1zaXplOiAxNHB4OyI+DQo8bGkgc3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwg MCk7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDE0cHg7Ij4N ClNlY3Rpb24gMi4gJm5ic3A7cy9GaWd1cmUgMS9GaWd1cmVzIDEgYW5kIDIvICZuYnNwOyAmbmJz cDtCVFcsIGl0IHdvdWxkIGJlIG5pY2UgKGV2ZW4gaWYgdGhleeKAmXJlIHJlZmVyZW5jZWQpIHRv IHBhc3RlIGEgY29weSBvZiB0aGUgZmlndXJlcy48L2xpPjwvb2w+DQo8L2Rpdj4NCjwvc3Bhbj4N CjxkaXY+V0ddIHdoYXQgc2F5IHlvdSwgU0lEUiBmb2xrcz88L2Rpdj4NCjxzcGFuIGlkPSJPTEtf U1JDX0JPRFlfU0VDVElPTiI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0id29yZC13cmFwOiBicmVhay13 b3JkOyAtd2Via2l0LW5ic3AtbW9kZTogc3BhY2U7IC13ZWJraXQtbGluZS1icmVhazogYWZ0ZXIt d2hpdGUtc3BhY2U7IGNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtc2l6ZTogMTRweDsgZm9udC1m YW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7Ij4NCjxvbCBzdHlsZT0iY29sb3I6IHJnYigwLCAw LCAwKTsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTRweDsi Pg0KPGxpPjxmb250IGZhY2U9IkNhbGlicmksc2Fucy1zZXJpZiI+U2VjdGlvbiAzLiAmbmJzcDtz LyZxdW90OzwvZm9udD48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2Vy aWY7Ij5UaGUgbWV0aG9kcyBhbmQgaW1wbGVtZW50YXRpb24gZGlzY3Vzc2VkIGluIGRyYWZ0LWll dGYtaWRyLWFzLTwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMt c2VyaWY7Ij5taWdyYXRpb24uIC4gLjwvc3Bhbj48Zm9udCBmYWNlPSJDYWxpYnJpLHNhbnMtc2Vy aWYiPiZuYnNwO3dpZGVseQ0KIHVzZWTigJ0vVGhlIGZ1bmN0aW9uYWxpdHkgZGVzY3JpYmVkIGlu IDwvZm9udD48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7Ij5b SS1ELmlldGYtaWRyLWFzLW1pZ3JhdGlvbl0mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQt ZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyI+aXMgd2lkZWx5IHVzZWQ8L3NwYW4+PC9saT48 L29sPg0KPC9kaXY+DQo8L2Rpdj4NCjwvc3Bhbj4NCjxkaXY+V0ddIGFjazwvZGl2Pg0KPHNwYW4g aWQ9Ik9MS19TUkNfQk9EWV9TRUNUSU9OIj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJ3b3JkLXdyYXA6 IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJyZWFr OiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAxNHB4 OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPG9sIHN0eWxlPSJjb2xvcjog cmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgZm9udC1zaXpl OiAxNHB4OyI+DQo8bGk+My4xICZuYnNwO+KAnG9yaWdpbiB2YWxpZGF0aW9u4oCdIGFuZCDigJxy ZXBsYWNlLWFz4oCdIG5lZWQgYSByZWZlcmVuY2UuIDwvbGk+PC9vbD4NCjwvZGl2Pg0KPC9kaXY+ DQo8L3NwYW4+DQo8ZGl2PldHXSBBQ0s8L2Rpdj4NCjxzcGFuIGlkPSJPTEtfU1JDX0JPRFlfU0VD VElPTiI+DQo8ZGl2IHN0eWxlPSJ3b3JkLXdyYXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1t b2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJyZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6 IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAxNHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fu cy1zZXJpZjsiPg0KPG9sIHN0eWxlPSJjb2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTog Q2FsaWJyaSwgc2Fucy1zZXJpZjsgZm9udC1zaXplOiAxNHB4OyI+DQo8bGk+My4yLjEgUmVmZXJl bmNlIGZvciDigJxCR1BTZWMgcHJvdG9jb2wgc3BlY2lmaWNhdGlvbuKAnSwgYW5kIOKAnHJlbW90 ZS1hc+KAnS4gPC9saT48L29sPg0KPC9kaXY+DQo8L3NwYW4+DQo8ZGl2PldHXSBmaXhlZCBCR1BT ZWMsIGRvbid0IGtub3cgd2hhdCB5b3UnZCBsaWtlIG1lIHRvIHJlZmVyZW5jZSBmb3IgcmVtb3Rl LWFzLjwvZGl2Pg0KPHNwYW4gaWQ9Ik9MS19TUkNfQk9EWV9TRUNUSU9OIj4NCjxkaXYgc3R5bGU9 IndvcmQtd3JhcDogYnJlYWstd29yZDsgLXdlYmtpdC1uYnNwLW1vZGU6IHNwYWNlOyAtd2Via2l0 LWxpbmUtYnJlYWs6IGFmdGVyLXdoaXRlLXNwYWNlOyBjb2xvcjogcmdiKDAsIDAsIDApOyBmb250 LXNpemU6IDE0cHg7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyI+DQo8b2wgc3R5 bGU9ImNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlm OyBmb250LXNpemU6IDE0cHg7Ij4NCjxsaT5zL0FTIFBhdGgvQVNfUEFUSDwvbGk+PC9vbD4NCjwv ZGl2Pg0KPC9zcGFuPjxzcGFuIGlkPSJPTEtfU1JDX0JPRFlfU0VDVElPTiI+DQo8ZGl2Pg0KPGRp diBzdHlsZT0id29yZC13cmFwOiBicmVhay13b3JkOyAtd2Via2l0LW5ic3AtbW9kZTogc3BhY2U7 IC13ZWJraXQtbGluZS1icmVhazogYWZ0ZXItd2hpdGUtc3BhY2U7IGNvbG9yOiByZ2IoMCwgMCwg MCk7IGZvbnQtc2l6ZTogMTRweDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7Ij4N CjxkaXY+V0ddIEdlbmVyYWxseSwgSSB1c2VkIHRoZSBhbGwgY2FwcyB3aGVuIHJlZmVycmluZyBz cGVjaWZpY2FsbHkgdG8gdGhlIGF0dHJpYnV0ZSwgYW5kIEFTIFBhdGggZm9yIG1vcmUgZ2VuZXJp YyBpbnN0YW5jZXMgbWVhbmluZyAmcXVvdDthIGxpc3Qgb2YgQVNOcyZxdW90Oy4gSWYgeW91IHdh bnQgdG8gcG9pbnQgdG8gc3BlY2lmaWMgYXJlYXMgb2YgdGhlIHRleHQgd2hlcmUgdGhlIHdyb25n IG9uZSB3YXMgdXNlZCwgSSdsbCBiZSBoYXBweSB0byBmaXgsIGJ1dA0KIEknbSBub3QgY2VydGFp biB0aGF0IGdsb2JhbGx5IHN3aXRjaGluZyB0byBBU19QQVRIIGlzIHRoZSByaWdodCB0aGluZyB0 byBkby48L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L3NwYW4+PGJyPg0KPGhyPg0KPGZvbnQgZmFj ZT0iQXJpYWwiIGNvbG9yPSJHcmF5IiBzaXplPSIxIj5UaGlzIEUtbWFpbCBhbmQgYW55IG9mIGl0 cyBhdHRhY2htZW50cyBtYXkgY29udGFpbiBUaW1lIFdhcm5lciBDYWJsZSBwcm9wcmlldGFyeSBp bmZvcm1hdGlvbiwgd2hpY2ggaXMgcHJpdmlsZWdlZCwgY29uZmlkZW50aWFsLCBvciBzdWJqZWN0 IHRvIGNvcHlyaWdodCBiZWxvbmdpbmcgdG8gVGltZSBXYXJuZXIgQ2FibGUuIFRoaXMgRS1tYWls IGlzIGludGVuZGVkIHNvbGVseQ0KIGZvciB0aGUgdXNlIG9mIHRoZSBpbmRpdmlkdWFsIG9yIGVu dGl0eSB0byB3aGljaCBpdCBpcyBhZGRyZXNzZWQuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRl ZCByZWNpcGllbnQgb2YgdGhpcyBFLW1haWwsIHlvdSBhcmUgaGVyZWJ5IG5vdGlmaWVkIHRoYXQg YW55IGRpc3NlbWluYXRpb24sIGRpc3RyaWJ1dGlvbiwgY29weWluZywgb3IgYWN0aW9uIHRha2Vu IGluIHJlbGF0aW9uIHRvIHRoZSBjb250ZW50cyBvZiBhbmQgYXR0YWNobWVudHMgdG8NCiB0aGlz IEUtbWFpbCBpcyBzdHJpY3RseSBwcm9oaWJpdGVkIGFuZCBtYXkgYmUgdW5sYXdmdWwuIElmIHlv dSBoYXZlIHJlY2VpdmVkIHRoaXMgRS1tYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBz ZW5kZXIgaW1tZWRpYXRlbHkgYW5kIHBlcm1hbmVudGx5IGRlbGV0ZSB0aGUgb3JpZ2luYWwgYW5k IGFueSBjb3B5IG9mIHRoaXMgRS1tYWlsIGFuZCBhbnkgcHJpbnRvdXQuPGJyPg0KPC9mb250Pg0K PC9ib2R5Pg0KPC9odG1sPg0K --_000_D14050384BA64wesleygeorgetwcablecom_-- From nobody Tue Mar 31 19:06:21 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23C241A0095 for ; Tue, 31 Mar 2015 19:06:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u-atDe0u_fzf for ; Tue, 31 Mar 2015 19:06:18 -0700 (PDT) Received: from nm16-vm4.access.bullet.mail.gq1.yahoo.com (nm16-vm4.access.bullet.mail.gq1.yahoo.com [216.39.63.104]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 689521A005D for ; Tue, 31 Mar 2015 19:06:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1427853978; bh=l90IYnNRkwvwpAjzQkSbe+Gh5dgpddxDj9tN9Mj69vM=; h=Date:From:To:Subject:In-Reply-To:References:From:Subject; b=fhlOGRbgzkZvxYxNMjT9cO+NijbSvOeIgRHN2UHDVs56BXKdNBus3ASeiZmXmbeOcKEaDEIjOwtgzkLB8vu6H4ALXwxqPCSLQ/cbmVhzsqP+fDBWJTmFz3v0HWWtpmYp57o1yG3j4MgX+LzpfUk+TTjZZu8og9wOxFoR5PUSQy4pujkJWMhLIZJ9cM+kftbHO8sznQBW1jJk+0PEknq3W8OK9R3m5D6kfNvpyKqdcmVd+8EIJOAAZC6ud70t1LACZTcQ3HtCnQnswnXh6ztMtfQVC+KQmxTjFIR01fjGWLBuC+4fK2Krei9UruRGDx2i9t3lDXlqFZgxB75GUv2Zgg== Received: from [216.39.60.171] by nm16.access.bullet.mail.gq1.yahoo.com with NNFMP; 01 Apr 2015 02:06:18 -0000 Received: from [98.138.104.98] by tm7.access.bullet.mail.gq1.yahoo.com with NNFMP; 01 Apr 2015 02:06:18 -0000 Received: from [127.0.0.1] by smtp118.sbc.mail.ne1.yahoo.com with NNFMP; 01 Apr 2015 02:06:17 -0000 X-Yahoo-Newman-Id: 878316.67253.bm@smtp118.sbc.mail.ne1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: 5RA2MWEVM1mhKDokCxNR9ZIACDgyqqIpXUKqVQAnredHsuW s8O3AmMPBS0npDEd.zo7cIp7K_VDifAUppLdtOP1EZ7A6KbkKJhzMAtJUa.2 Dsru1mazKnCaC5DiOkEET2T6wSB7DDrRf0fE5UPFOMwwIK5CvKMlu1HkZFeV Wi893OEi2C80kfW7b9yJiJb_YBl6K7cOwy6vWMMTPudsYs6qIoAGjNM8MShG dVn6wVVNIkzR4GmppxWDK6eKrYM.UOYNxEWgSQN5ARTohVhz8kG9MHoUAiI_ nTro6lDeg5FwcZNNLQaBxh02zxfNNhq4muyr5FVmsrBHh1quvURBmaRS5iK2 xRWBH8C2GxYI7U.qOlddKYn.mW9x.xL28ZDnbCtbv4oIZ_la.5mqt1hn6kAq .t3rFlXI7zFW6n8Dc42.TnbQUx5zbHTDZhhk5RHytxhJEdNqDxUGjFzT1BFp jf.vTnN2ryALllcihSiioTEs9_i7w6SNZxiC7xYaJH8wZSvFYA228B5V3Opj PrajyaqyoPzpcRGWuPyuwvwG1.78DSMwzhyo2QtXVHpXfpN49RV_VJUYpNy. 2TXO1ZiUIYZI1OlONErN1Xu9_rqmxoSdTdwm1QnB1v0N3n.cNmQ-- X-Yahoo-SMTP: 4kJJK.qswBDPuwyc5wW.BPAQqNXdy5j09UNyeAS0pyOQ708- Received: from secure.mandelberg.org (c-76-24-31-176.hsd1.ma.comcast.net [76.24.31.176]) by uriel.mandelberg.org (Postfix) with ESMTPSA id C7D9D1C6095 for ; Tue, 31 Mar 2015 22:06:16 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Date: Tue, 31 Mar 2015 21:06:16 -0500 From: David Mandelberg To: In-Reply-To: <20150328232012.8464.95328.idtracker@ietfa.amsl.com> References: <20150328232012.8464.95328.idtracker@ietfa.amsl.com> Message-ID: X-Sender: david@mandelberg.org User-Agent: Roundcube Webmail/0.7.2 Archived-At: Subject: Re: [sidr] I-D Action: draft-ietf-sidr-rfc6490-bis-03.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2015 02:06:21 -0000 Hi, While thinking about RRDP (draft-ietf-sidr-delta-protocol-00), I realized that there's a minor conflict between RRDP's push to transition from rsync to http(s), and the TAL format's requirement to use only rsync URIs. I propose the below changes to draft-ietf-sidr-rfc6490-bis-03 to make RRDP's work easier in the future without causing any harm now. Sorry to bring this up so late in the process for draft-ietf-sidr-rfc6490-bis. In the abstract, change: This document obsoletes RFC 6490 by adding support for multiple URIs in a TAL. to: This document obsoletes RFC 6490 by adding support for multiple URIs in a TAL, and allowing URI schemes other than rsync. In section 2.1, change: where the URI section is comprised of one of more of the ordered sequence of: 1.1) an rsync URI [RFC5781], 1.2) a or line break. to: where the URI section is comprised of one of more of the ordered sequence of: 1.1) a URI [RFC3986], 1.2) a or line break. The URI section MUST include one or more rsync URIs [RFC5781]. Non-rsync URIs MAY be present. I assume that an rfc3986 URI cannot include either or , but if I'm wrong then I'd like to add a MUST NOT somewhere in this text. In section 2.2, change: Each rsync URI in the TAL MUST reference a single object. to: Each URI in the TAL MUST reference a single object. and: Where the TAL contains two or more rsync URIs, then the same self- signed CA certificate MUST be found at each referenced location. In order to operational increase resilience, it is RECOMMENDED that the domain name parts of each of these URIs resolve to distinct IP addresses that are used by a diverse set of repository publication points, and these IP addresses be included in distinct Route Origination Authorizations (ROAs) objects signed by different CAs. to: Where the TAL contains two or more URIs, then the same self- signed CA certificate MUST be found at each referenced object. In order to increase operational resilience, it is RECOMMENDED that no two URLs which share a scheme have domain name parts that can resolve to the same IP address. Additionally, it is RECOMMENDED that these IP addresses be included in distinct Route Origination Authorizations (ROAs) objects signed by different CAs. In section 3, add this paragraph at the beginning: An RP MUST support the rsync URI scheme and MAY support additional URI schemes. An RP SHOULD ignore all URIs with unsupported schemes. -- David Eric Mandelberg / dseomn http://david.mandelberg.org/ From nobody Tue Mar 31 19:44:09 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1AA01A033B for ; Tue, 31 Mar 2015 19:44:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hnVR_OyjVoho for ; Tue, 31 Mar 2015 19:44:06 -0700 (PDT) Received: from nm2-vm10.access.bullet.mail.bf1.yahoo.com (nm2-vm10.access.bullet.mail.bf1.yahoo.com [216.109.114.83]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 31EAD1A1B95 for ; Tue, 31 Mar 2015 19:44:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1427856242; bh=nVvUCkqG0ufbYcfTy0AU2TtpFM5BTaw6IG/kI5MdgoI=; h=Date:From:To:Subject:In-Reply-To:References:From:Subject; b=umwwCylOVaoyCBusqFRNAD7JVOY5XN1UrrdAj5ixY1aXtHKMTu8gFg3v4zOhJj+/bU9f9MOQrcBjrhx0ljW8GSVGAWlfAGinMQpbuTE8MV5lauWrrDdorlPWZhis8DTIb0V846hRDtKh0g83QPnWJzrManvQMx8HtcDoud9Q6u07SyE5ULXZcMDyg0+HHXQ23PzRQqocDlb7zrGXEHq70E6dTWJYBYpvqQ7DuEGntopsS4AMd/me+tHFjLXI7mJXe08Y5MLbPOSPT15TbIsAFV9CAn+sy+6fEhoc7UZyXEQjFC24W1WdBPPDOHemZj85X4CngkbcQ9hkIMuu3mevZQ== Received: from [66.196.81.158] by nm2.access.bullet.mail.bf1.yahoo.com with NNFMP; 01 Apr 2015 02:44:02 -0000 Received: from [98.138.226.242] by tm4.access.bullet.mail.bf1.yahoo.com with NNFMP; 01 Apr 2015 02:44:02 -0000 Received: from [127.0.0.1] by smtp113.sbc.mail.ne1.yahoo.com with NNFMP; 01 Apr 2015 02:44:02 -0000 X-Yahoo-Newman-Id: 368782.89180.bm@smtp113.sbc.mail.ne1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: ZNHEJs8VM1nC6XOq.qCKbxEnrERpwSPZpdoXF_x.Ads4lJM RwcLsm7S3sAKSMUbGuz36La.GnS06Nj.e4m2vDKENEyE1GoIlB8d6Yj.rlX8 2TFrVPbG1hs1uZwOToeSMC4aokyoZthTxXPPfFYjD7Lo0VmO43DJL4IlGEDq vyxHXJ_VBkKdaCMT69sAizqfoNeDhiT4iqvnTzvWXIEO3jF6ZEIQoa4rKkWG OmUg.N56mJrMVMt8seQqFDb2XiKUEyoxp6kEZxBdChCec0kvyuKC3V4lUMkv 896GZPeTNvlmajvl.pqR6Xrmfo30cVRYzYXsRgwCb1_tVJZV86VIN7yOV1gW t8Uekc7IKopydBhCAFmgLaUFUZSByEucTbJfAt62wUBbJxdHggVMJjZowjpF VyK8dYrfg1gnC.0rSXS1k8FLGfE9MFHGXagSY5JGPHF0dOQnDF38SOePAJff goyBpYzPFppz6Vf0DEZj.RafHR22_bo4ntv1tGAH0F7wv.T9FlsltUTZXeDW uscIChb5go8F.94OfynhSunP.bV4aCkofcgRdluks3S8SA.a5IKoZxcPj2ly ahc97v3pVV5j.GHhd8rfoMD9qiSJlkxei7lNtCPLbC44Y58yQvg-- X-Yahoo-SMTP: 4kJJK.qswBDPuwyc5wW.BPAQqNXdy5j09UNyeAS0pyOQ708- Received: from secure.mandelberg.org (c-76-24-31-176.hsd1.ma.comcast.net [76.24.31.176]) by uriel.mandelberg.org (Postfix) with ESMTPSA id 439CA1C6095 for ; Tue, 31 Mar 2015 22:44:01 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Date: Tue, 31 Mar 2015 21:44:01 -0500 From: David Mandelberg To: In-Reply-To: References: Message-ID: <048e9e0eb7a311408c1cb07d192c8894@mail.mandelberg.org> X-Sender: david@mandelberg.org User-Agent: Roundcube Webmail/0.7.2 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [sidr] WGLC for draft-ietf-sidr-rpki-rtr-rfc6810-bis-03 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2015 02:44:08 -0000 On 2015-03-25 16:13, Borchert, Oliver wrote: > A correction for my previous email, I mixed up session id and serial > number. > I think to keep it simple for version 0 - 1 switches and future=20 > changes, a > change > Within the session id and version id should trigger a =E2=80=9CCache Re= set=E2=80=9D=20 > by the > cache > And the client must resynch with the server. If the router sends a serial query, yes I agree. > And yes, wording in this matter might need to be added - but still it=20 > also > could > Be an implementation issue. After talking with you in Dallas, I agree that we should try to give=20 implementors some leeway here. I still think there's an issue to address=20 though. Here's the case I want to prevent: 1. Router has all the data for version 0, session X, serial Y. 2. Router upgrades to version 1, disconnects, reconnects, and sends a=20 serial query with version =3D 1, session =3D X, and serial =3D Y. 3. Cache replies with all the changes from (1, X, Y) to (1, X, Y+1),=20 instead of from (0, X, Y) to (1, X, Y+1). As you pointed out in person, one way to avoid this is for the cache to=20 give each router a different session ID and track which version is used=20 by each router. Then the cache can respond in step 3 with the changes=20 from (0, X, Y) to (1, X, Y+1). Another way to avoid this is the first=20 part of what I originally suggested: effectively requiring the cache to=20 respond with a cache reset in step 3. Or the second part of what I=20 suggested: requiring the router to issue a reset query instead of a=20 serial query in step 2. I'm having trouble coming up with *simple* text=20 that prevents the issue while allowing any solution. If you can think of=20 something, that would be great. Otherwise, I'd prefer to at least pick=20 one of the solutions that does not require a cache to track its routers=20 individually. --=20 David Eric Mandelberg / dseomn http://david.mandelberg.org/ From nobody Tue Mar 31 22:38:28 2015 Return-Path: X-Original-To: sidr@ietfa.amsl.com Delivered-To: sidr@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB78B1A889F for ; Tue, 31 Mar 2015 22:38:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.51 X-Spam-Level: X-Spam-Status: No, score=-0.51 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CYYlQH2Coyye for ; Tue, 31 Mar 2015 22:38:25 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B67F01A8848 for ; Tue, 31 Mar 2015 22:38:25 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com.psg.com) by ran.psg.com with esmtp (Exim 4.82) (envelope-from ) id 1YdBM8-0000bK-2L; Wed, 01 Apr 2015 05:38:24 +0000 Date: Tue, 31 Mar 2015 22:38:23 -0700 Message-ID: From: Randy Bush To: David Mandelberg In-Reply-To: <048e9e0eb7a311408c1cb07d192c8894@mail.mandelberg.org> References: <048e9e0eb7a311408c1cb07d192c8894@mail.mandelberg.org> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Cc: sidr wg list Subject: Re: [sidr] WGLC for draft-ietf-sidr-rpki-rtr-rfc6810-bis-03 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2015 05:38:26 -0000 why are you trying to rescue the case where a router (or cache) upgrades versions in the middle of a session? o upgrade should be very rare o reload is relatively cheap o and you are generating kinky corner cases to patch it session reset. the bloody router (or cache) will have reloaded anyway and does not have the old state. randy