From nobody Wed Apr 1 07:11:53 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 6FD161AC3AF for ; Wed, 1 Apr 2015 07:11:52 -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 4ebgjS0NGWpO for ; Wed, 1 Apr 2015 07:11:51 -0700 (PDT) Received: from nm25-vm9.access.bullet.mail.bf1.yahoo.com (nm25-vm9.access.bullet.mail.bf1.yahoo.com [216.109.115.200]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 78D2D1A92B8 for ; Wed, 1 Apr 2015 07:11:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1427897507; bh=DDsOeJDrnOEVS8+qb0ymXYxT33ektux7YTYpvHYINLc=; h=Date:From:To:Subject:References:In-Reply-To:From:Subject; b=l55CfA7e0B0j7H/+/b7X/0g7hcUEdwE5MX+XHjza1CPSN7jXEJJCKKlYY+6vdkCE33NXxei1xkeWXqUR8c6FeCvEpS7MluEwLB+dXK+XJ2ezmlhkTaHyoC6x7Igm4fsml/MuEmm2+i2fBL+tbE5FCvWOq0ShPzSXweTOpIfc3Yfe7z+DGK6j8lViq7SZGMz58IeDxKrd73Zq6nU3pfgQaiUR0OlH3Cc4RRWUMIRDGcyWgoVzcWk875elx6jY4lf7uez4YhvArB4D3S9drmPIGDSD4xsjPZnRx16pHORbqErrXLRK6z1NbbznxqFputsgEtkLHezzLc4RMHiST1b2mQ== Received: from [66.196.81.157] by nm25.access.bullet.mail.bf1.yahoo.com with NNFMP; 01 Apr 2015 14:11:47 -0000 Received: from [98.138.104.97] by tm3.access.bullet.mail.bf1.yahoo.com with NNFMP; 01 Apr 2015 14:11:47 -0000 Received: from [127.0.0.1] by smtp117.sbc.mail.ne1.yahoo.com with NNFMP; 01 Apr 2015 14:11:47 -0000 X-Yahoo-Newman-Id: 559769.2925.bm@smtp117.sbc.mail.ne1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: 6dlC1nMVM1lfS44_DCoShrhOSSZYWj_MzMW9QzHwdRH1NtY pmxJO9W0b3N9924FYFQn3.A1WDAJeD6KDRcVjVJ_Nn.BOCtpvFyaNMwMjWDk bmHM4gYWXXBtOFcWmaegFeT8kUPT5w.xaMh1EB2cmbOTlGOtB70cwZhz4kjg WsOB2uqzQoIcdIPUpfpk0iH1cQ2cSrN3jkKawV4vHt0uyYeyvXa8umCSG2Qt numQZDLzcGus1tGmNY0d6MX3eFVUdUNOqSo5eMUye_4yy0o4fPdUUCBV.L7d jnFujmINpbCpfvbauRgq8NB1Ob1cqrdPB82BTobToLoVypOE_eGVyOxNJxdM _ZR1BmZyhRqGH8shd_xtfmNCbuam9Txjhw4_TNmixmtTZDybsIJ8ZuXAQDgB OAlFZUquzG840fgahU.5AOrkpbtVbjjq7zQME16AdA8JtEMuXXNlUaRjbCVg xW341DPVbZQQ9oozXvvzqvOiYQzXlacScBXtXATHnOOTLym3IfcAn9CkgZrM l8GdMymD4o.h.do2xkbAOVYfefdXmuksyuBbo3vb2PW49bW5hjXZxi.As9.n Hw4baIO1ZuGO_Vmso36TyWfCbmzrnq90i8aFAKc7o_XZyba0uWg-- X-Yahoo-SMTP: 4kJJK.qswBDPuwyc5wW.BPAQqNXdy5j09UNyeAS0pyOQ708- Received: from [192.168.1.10] (c-76-24-31-176.hsd1.ma.comcast.net [76.24.31.176]) by uriel.mandelberg.org (Postfix) with ESMTPSA id 74BB71C604C for ; Wed, 1 Apr 2015 10:11:46 -0400 (EDT) Message-ID: <551BFCAF.8050309@mandelberg.org> Date: Wed, 01 Apr 2015 10:11:59 -0400 From: David Mandelberg 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: <048e9e0eb7a311408c1cb07d192c8894@mail.mandelberg.org> In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="wWVRL3vDMuw4k28rxdMWO8LqHiKSJ05HL" 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 14:11:52 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --wWVRL3vDMuw4k28rxdMWO8LqHiKSJ05HL Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 04/01/2015 01:38 AM, Randy Bush wrote: > why are you trying to rescue the case where a router (or cache) upgrade= s > 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 >=20 > session reset. I wasn't trying to rescue it, I was trying to ensure a session reset. > the bloody router (or cache) will have reloaded anyway > and does not have the old state. Either end can upgrade to support version 1 before the other is ready; version 1 is only negotiated after both ends support it. I know that our cache implementation does not lose state unless the database is manually cleared, but I can't speak for other cache or router implementations. I agree that the simplest way to fix this issue is to require a reset query when a new version is negotiated, but I don't think that can be done by relying on state being lost. For reference, here's the text that I originally proposed: 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. If one of those requirements is too burdensome, either of them would be sufficient by itself to ensure that a reset query happens when the negotiated protocol version changes. --=20 David Eric Mandelberg / dseomn http://david.mandelberg.org/ --wWVRL3vDMuw4k28rxdMWO8LqHiKSJ05HL 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 iEYEARECAAYFAlUb/K8ACgkQRKlmUHCg4sA4AACglZ5asMf5MEjVqkzVM7ZqOt1p NKAAn0XsO5kBYzZeUy8hC6VwM+KAtavr =PIX8 -----END PGP SIGNATURE----- --wWVRL3vDMuw4k28rxdMWO8LqHiKSJ05HL-- From nobody Wed Apr 1 10:39: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 BB5D81A1A9C for ; Wed, 1 Apr 2015 10:39:39 -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 jI2-TCAv81Eg for ; Wed, 1 Apr 2015 10:39:38 -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 BB48F1A1A8E for ; Wed, 1 Apr 2015 10:39:38 -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 1YdMc5-0002Sk-8a; Wed, 01 Apr 2015 17:39:37 +0000 Date: Wed, 01 Apr 2015 10:39:35 -0700 Message-ID: From: Randy Bush To: David Mandelberg In-Reply-To: <551BFCAF.8050309@mandelberg.org> References: <048e9e0eb7a311408c1cb07d192c8894@mail.mandelberg.org> <551BFCAF.8050309@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 17:39:39 -0000 > 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. why should there ever be two versions running at the same time between a cache and a router? randy From nobody Wed Apr 1 12:21: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 03E781A8849 for ; Wed, 1 Apr 2015 12:21:25 -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 uZepBIrIQB7B for ; Wed, 1 Apr 2015 12:21:17 -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 E5EE91A8A8B for ; Wed, 1 Apr 2015 12:21:16 -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 D7C3EA192 for ; Wed, 1 Apr 2015 19:21:14 +0000 (UTC) Received: from minas-ithil.hactrn.net (localhost [IPv6:::1]) by minas-ithil.hactrn.net (Postfix) with ESMTP id 6786D1712A31 for ; Wed, 1 Apr 2015 15:21:16 -0400 (EDT) Date: Wed, 01 Apr 2015 15:21:16 -0400 From: Rob Austein To: sidr@ietf.org In-Reply-To: <551BFCAF.8050309@mandelberg.org> References: <048e9e0eb7a311408c1cb07d192c8894@mail.mandelberg.org> <551BFCAF.8050309@mandelberg.org> 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: <20150401192116.6786D1712A31@minas-ithil.hactrn.net> 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 19:21:25 -0000 David, I think a simpler way to express the semantics you want is just to consider the protocol version number to be part of the session identifier. That way, a version 0 session can never match a version 1 session, by definition, full stop. From nobody Wed Apr 1 12:59: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 33B8E1A8702 for ; Wed, 1 Apr 2015 12:58:57 -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 ZYd5sODpzlTr for ; Wed, 1 Apr 2015 12:58:53 -0700 (PDT) Received: from nm24-vm2.access.bullet.mail.gq1.yahoo.com (nm24-vm2.access.bullet.mail.gq1.yahoo.com [216.39.63.52]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 895A71A8A9D for ; Wed, 1 Apr 2015 12:58:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1427918332; bh=tRsXgHfIsI+fbf8Xhm+OYj6z+1vauztmhdhlVccGqHg=; h=Date:From:To:Subject:In-Reply-To:References:From:Subject; b=pk5Gu+Tgv4Eu2EzFkGvaPBdQ3i3rrGdLAUGLGQL0NjpJxzNt9MRcSlXeFYLwswXh0OWxVTmtoe4uNipmoqm7YocDrNE0Y53mSfYPHllVt15o7o2JlSsR/3fop/L7d6V4ugph3ttAtE03VPAB/OKSWB0m3SFhWZPLLipzVVmJFsZuSW4lBbgH8/sdjs75R3W0rOPaTrPeBWI72b9day+BBgFWlfaR7dAFsRS2r3swOej35IvLjkSpvFoPo1yYpLWvV79RzPcYmW1Z3ntRFXrpRmY6v7MiIXVzk+Fw5A9TI4k3yMGHgQ1XmfG1f+kMzbmUQBnXoAVRxrBxyyjc17vyLQ== Received: from [216.39.60.168] by nm24.access.bullet.mail.gq1.yahoo.com with NNFMP; 01 Apr 2015 19:58:52 -0000 Received: from [98.138.104.97] by tm4.access.bullet.mail.gq1.yahoo.com with NNFMP; 01 Apr 2015 19:58:52 -0000 Received: from [127.0.0.1] by smtp117.sbc.mail.ne1.yahoo.com with NNFMP; 01 Apr 2015 19:58:52 -0000 X-Yahoo-Newman-Id: 130438.79043.bm@smtp117.sbc.mail.ne1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: uB8TkkMVM1lm4TD.8u9fNiL5NL.esB3pX9rfN_ITX.jM76Z apkN8dw2cgaz3gdhbjRtljnjydFOo1TIHaZ1yOKZPwdqpy86BYGsiDyi1t_b 43NQ7gqpcEQj15jn4AIXdP16xLNXrG11HwBEVXKeCsxLaZ3yexaQgszziA0y GMJyBm15Se8mgUTRzm_4zpCLKV3dBqYybTE7RuLbfCGdyqkKqsXmnC09VO20 1RWh19oDiWEvqlIo0Qn8mGUKcBb17Ue5bXPuaJJh5sQH4g1WR5zXz2W2BwpR rQMDbcKzKbEMKsLfd2xY4NOtnfFAnSNU2LeFdWi8vMEoGFFgXGmoaPgO39_o ADYh126.W9_uR0.AZLlqsWxa7_OsJD_X2hTICyDXkWnIbuNCAQeEXKQt1oXF 8x2yYxGjWG1DLwB3vxPxchfxjw0jCFwAJuSio.NHxPjzWS1CXkH2N6VIrpgI uni7mmWfq3PilteXx0pNo1qUYJvz6nL77y1MO7ua8psv0NDxnSf5RLDNFyBO nPJP5_pnR6yjNA9JtG4IFRpCTApi81NbLSGeswj_mdLj7E3FdqTHvgoV_G1r 0v85PFaYQdct683VTkGE3lNLt6XneCtn_fKMawFeDT_E6b31qjg-- 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 0F3E71C604C for ; Wed, 1 Apr 2015 15:58:51 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Date: Wed, 01 Apr 2015 14:58:50 -0500 From: David Mandelberg To: In-Reply-To: References: <048e9e0eb7a311408c1cb07d192c8894@mail.mandelberg.org> <551BFCAF.8050309@mandelberg.org> Message-ID: <2c541df5827d4d104fd2a4e5b52b0de0@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: Wed, 01 Apr 2015 19:58:57 -0000 On 2015-04-01 12:39, Randy Bush wrote: >> 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. > > why should there ever be two versions running at the same time > between a > cache and a router? For any pair of (cache, router), there would only be one version at a time. As I understand it though, a cache can use the same session information for all of its routers, which may not all use the same version. -- David Eric Mandelberg / dseomn http://david.mandelberg.org/ From nobody Wed Apr 1 13:02:08 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 BA56C1A8F50 for ; Wed, 1 Apr 2015 13:02:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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 GHKdekcoG0ZP for ; Wed, 1 Apr 2015 13:01:53 -0700 (PDT) Received: from nm11-vm9.access.bullet.mail.gq1.yahoo.com (nm11-vm9.access.bullet.mail.gq1.yahoo.com [216.39.63.249]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F0B041A89AA for ; Wed, 1 Apr 2015 13:01:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1427918512; bh=fGv8n4xnHiDdFEiNNlgqYkAoiOPRCEiUFZgISzTOHkE=; h=Date:From:To:Subject:In-Reply-To:References:From:Subject; b=L47205lp2KoaIQvllTaJJCbtRKtEc5KpxSbGnG3xsDPdp54zNj6oQ6npPSAYF7vIM0SscTWQYVbQZSWcUkdrQCwFdTJ5W06PVrkIRKhR0P0A7cr+8TklWYVDKuQnUwN/TJMJtA33IvutRIVZKo3i58g27hsklmwhilmjpz7rGf5HhLc40FIbPd23fI6nEAl55/X/p1l1k9m+g7JK2e9aeovFbxM6Az5d0KdMQE8aSenKEaIxk31X2PAmqXhXUe+P8Lm5MLeiSNtufJUe6Bu21eDGzwcrBHFvBUbEPa6iNv8rnzLSCGsk8N4jeFsSAAzsFyeNMzJNd3SqHkcbHM3jBw== Received: from [216.39.60.165] by nm11.access.bullet.mail.gq1.yahoo.com with NNFMP; 01 Apr 2015 20:01:52 -0000 Received: from [98.138.226.244] by tm1.access.bullet.mail.gq1.yahoo.com with NNFMP; 01 Apr 2015 20:01:52 -0000 Received: from [127.0.0.1] by smtp115.sbc.mail.ne1.yahoo.com with NNFMP; 01 Apr 2015 20:01:52 -0000 X-Yahoo-Newman-Id: 495094.60500.bm@smtp115.sbc.mail.ne1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: K5vnr0kVM1kDXBmT85fsrTb.E0Yq2sAMa01oG7qJek7rgEJ 7yZIKJ8zEnHCBqBjpQEm716gdd3aDaccvLCHKqS9TfrdQxe5Tdbak0LYS.0. Z7YDZqSqyb3CtwuBIIV8vT8SxysDxd_BVPTwf4asm6JV2oKpR_2jAWdrjhoQ sMiZCX4S0lJj6JckJg7_ZHRfQXE4XHgLtVDIThnaZgeC3RFl7YiGiKNWz2LI 9aHWMtU0ZgV8h36T3UW20LFoohO9C3s7co9cRpcP2RRiazYv9XWH6tEtocM. rNL7y4Kfps2PlHpBflWXN2mWQ5Or.82j7EbffIGFtwl_ZB.SjPuzforSkCft ffptfcVQQPjSEQ7.stC8hFp3sAaCXM1cr4W2LwqdISuBbgwYN..iexa2.svt 9pYT1FKqgIhGdVlrzpOc7dJFEpU73._twcWDuvxp_X1cwjWW_mcHNonRPqAI Kh2EUSQDWat9F1c4R0LOnHBaS6FB__x8CzRXxcJQliYqcaDFYtSF3F1rdF.X 37FUl6i9Lurp.sJ10d4G1el_K1AxjRbX8yTSjjsCGYXugQLQWOA6rZ6n0nhs J0sWDCaVud_oF3BpwG1HW6O_eQAarlUw2Y7DxFNdSrHkbo_lvOw-- 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 647771C604C for ; Wed, 1 Apr 2015 16:01:51 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Date: Wed, 01 Apr 2015 15:01:51 -0500 From: David Mandelberg To: In-Reply-To: <20150401192116.6786D1712A31@minas-ithil.hactrn.net> References: <048e9e0eb7a311408c1cb07d192c8894@mail.mandelberg.org> <551BFCAF.8050309@mandelberg.org> <20150401192116.6786D1712A31@minas-ithil.hactrn.net> Message-ID: <9e2b6b522fc97649117ad21139fb9285@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: Wed, 01 Apr 2015 20:02:06 -0000 On 2015-04-01 14:21, Rob Austein wrote: > David, I think a simpler way to express the semantics you want is > just > to consider the protocol version number to be part of the session > identifier. That way, a version 0 session can never match a version > 1 > session, by definition, full stop. Sure, that works. (BTW, I think Oliver also came up with something similar.) Alternatively, how about this? ;) Routers and caches SHOULD CONSIDER [RFC6919] the implications of serial queries across protocol versions. -- David Eric Mandelberg / dseomn http://david.mandelberg.org/ From nobody Wed Apr 1 15:15: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 E0C501A87BF for ; Wed, 1 Apr 2015 15:15:53 -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 sxiuEgknYb9I for ; Wed, 1 Apr 2015 15:15:53 -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 016DB1A87BB for ; Wed, 1 Apr 2015 15:15:52 -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 1YdQvO-0003Fs-T9; Wed, 01 Apr 2015 22:15:51 +0000 Date: Wed, 01 Apr 2015 15:15:48 -0700 Message-ID: From: Randy Bush To: David Mandelberg In-Reply-To: <2c541df5827d4d104fd2a4e5b52b0de0@mail.mandelberg.org> References: <048e9e0eb7a311408c1cb07d192c8894@mail.mandelberg.org> <551BFCAF.8050309@mandelberg.org> <2c541df5827d4d104fd2a4e5b52b0de0@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@ietf.org 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 22:15:54 -0000 > As I understand it though, a cache can use the same session > information for all of its routers that is not my understanding randy From nobody Wed Apr 1 15:16:59 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 14E341A87BF for ; Wed, 1 Apr 2015 15:16:58 -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 Ug2LfgE2SYhI for ; Wed, 1 Apr 2015 15:16:57 -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 22E001A87A5 for ; Wed, 1 Apr 2015 15:16:57 -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 1YdQwR-0003GI-H6; Wed, 01 Apr 2015 22:16:56 +0000 Date: Wed, 01 Apr 2015 15:16:54 -0700 Message-ID: From: Randy Bush To: David Mandelberg In-Reply-To: <9e2b6b522fc97649117ad21139fb9285@mail.mandelberg.org> References: <048e9e0eb7a311408c1cb07d192c8894@mail.mandelberg.org> <551BFCAF.8050309@mandelberg.org> <20150401192116.6786D1712A31@minas-ithil.hactrn.net> <9e2b6b522fc97649117ad21139fb9285@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@ietf.org 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 22:16:58 -0000 > Routers and caches SHOULD CONSIDER [RFC6919] the implications of > serial queries across protocol versions. s/consider/consider it an error/ randy From nobody Thu Apr 2 08:25: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 AAA131B2D1C for ; Thu, 2 Apr 2015 08:25:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.664 X-Spam-Level: * X-Spam-Status: No, score=1.664 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_RELAY_NODNS=1.451, HELO_EQ_MODEMCABLE=0.768, HELO_MISMATCH_COM=0.553, 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 niOH5MLY_hYj for ; Thu, 2 Apr 2015 08:25:39 -0700 (PDT) Received: from cdcipgw01.twcable.com (unknown [165.237.91.110]) by ietfa.amsl.com (Postfix) with ESMTP id AE4BC1B2D14 for ; Thu, 2 Apr 2015 08:25:38 -0700 (PDT) X-SENDER-IP: 10.136.163.15 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="5.11,511,1422939600"; d="scan'208";a="279240225" Received: from unknown (HELO PRVPEXHUB06.corp.twcable.com) ([10.136.163.15]) by cdcipgw01.twcable.com with ESMTP/TLS/RC4-MD5; 02 Apr 2015 11:18:03 -0400 Received: from PRVPEXVS10.corp.twcable.com ([10.136.163.40]) by PRVPEXHUB06.corp.twcable.com ([10.136.163.15]) with mapi; Thu, 2 Apr 2015 11:25:37 -0400 From: "George, Wes" To: "sidr@ietf.org" Date: Thu, 2 Apr 2015 11:25:37 -0400 Thread-Topic: [sidr] I-D Action: draft-ietf-sidr-bgpsec-rollover-03.txt Thread-Index: AdBtWUS4qtAF7ZN/Tmi3bsdb1GfM3Q== Message-ID: References: <20150307004344.316.10229.idtracker@ietfa.amsl.com> In-Reply-To: <20150307004344.316.10229.idtracker@ietfa.amsl.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] I-D Action: draft-ietf-sidr-bgpsec-rollover-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, 02 Apr 2015 15:25:40 -0000 T25lIHF1ZXN0aW9uIHRoYXQgY29tZXMgdXAgd2hlbiByZWFkaW5nIHRoaXMgZG9jdW1lbnQuIE5v dyB0aGF0IHdlJ3ZlDQpyZW1vdmVkIHRoZSBkZXBlbmRlbmN5IGJldHdlZW4gT3JpZ2luIFZhbGlk YXRpb24gYW5kIFBhdGggVmFsaWRhdGlvbiBidXQNCmFyZSBleHBlY3RpbmcgdGhlbSB0byBydW4g aW4gcGFyYWxsZWwgd2l0aCBzb21lIHNoYXJlZCBjb21wb25lbnRzLCBkbyB3ZQ0KbmVlZCB0byBk aXNjdXNzIGhvdyBCR1BTZWMgY2VydCByb2xsb3ZlciBpbnRlcmFjdHMgd2l0aCBPcmlnaW4gVmFs aWRhdGlvbg0KY2VydCByb2xsb3ZlciwgcG9zc2libHkgZ2l2aW5nIGhpbnRzIHRvIHdoYXQgYSBj b21iaW5lZCByb2xsb3ZlciBwcm9jZXNzDQpsb29rcyBsaWtlPyBBcmUgd2UgZXhwZWN0aW5nIHRo YXQgdGhleSBzaG91bGQgYmUgZG9uZSBhdCB0aGUgc2FtZSB0aW1lLCBvcg0KdGhhdCB0aGV5IHNo b3VsZCBOT1QgYmUgZG9uZSBhdCB0aGUgc2FtZSB0aW1lLCBvciBkb2VzIGl0IGp1c3Qgbm90IG1h dHRlcj8NCkZvciBleGFtcGxlLCBpZiBpdCdzIGJldHRlciB0byBoYXZlIHRoZSByb2xscyBkb25l IHNlcGFyYXRlbHksIHRoZW4NCnByb2JhYmx5IHNvbWUgZ3VpZGFuY2UgYWJvdXQgdGhlIGV4cGly eSB0aW1lcyBub3QgbGluaW5nIHVwIG1pZ2h0IGJlIGdvb2QuDQpJdCdzIGNvbmNlaXZhYmxlIHRo YXQgaWYgeW91J3JlIGRvaW5nIGFuIGVtZXJnZW5jeSByb2xsIG9uIGFjY291bnQgb2YNCmNvbXBy b21pc2VkIGtleXMsIHlvdSBtaWdodCBiZSBkb2luZyBib3RoIGF0IG9uY2UsIHJlZ2FyZGxlc3Mg b2Ygd2hldGhlcg0KaXQncyBhIGdvb2QgaWRlYSBub3JtYWxseSwgc28gSSB0aGluayB3ZSBuZWVk IHRvIGhpZ2hsaWdodCBhbnkgZ290Y2hhcw0KdGhhdCBtYXkgYmUgcHJlc2VudC4gTWF5YmUgdGhp cyBiZWxvbmdzIGluIHRoZSBvcHMgZG9jPw0KDQpUaGFua3MsDQoNCldlcw0KDQoNCg0KT24gMy82 LzE1LCA3OjQzIFBNLCAiaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIiA8aW50ZXJuZXQtZHJhZnRz QGlldGYub3JnPg0Kd3JvdGU6DQoNCj4NCj5BIE5ldyBJbnRlcm5ldC1EcmFmdCBpcyBhdmFpbGFi bGUgZnJvbSB0aGUgb24tbGluZSBJbnRlcm5ldC1EcmFmdHMNCj5kaXJlY3Rvcmllcy4NCj4gVGhp cyBkcmFmdCBpcyBhIHdvcmsgaXRlbSBvZiB0aGUgU2VjdXJlIEludGVyLURvbWFpbiBSb3V0aW5n IFdvcmtpbmcNCj5Hcm91cCBvZiB0aGUgSUVURi4NCj4NCj4gICAgICAgIFRpdGxlICAgICAgICAg ICA6IEJHUFNFQyBSb3V0ZXIgQ2VydGlmaWNhdGUgUm9sbG92ZXINCj4gICAgICAgIEF1dGhvcnMg ICAgICAgICA6IFJvcXVlIEdhZ2xpYW5vDQo+ICAgICAgICAgICAgICAgICAgICAgICAgICBLZXl1 ciBQYXRlbA0KPiAgICAgICAgICAgICAgICAgICAgICAgICAgQnJpYW4gV2Vpcw0KPiAgICAgICBG aWxlbmFtZSAgICAgICAgOiBkcmFmdC1pZXRmLXNpZHItYmdwc2VjLXJvbGxvdmVyLTAzLnR4dA0K PiAgICAgICBQYWdlcyAgICAgICAgICAgOiAxNQ0KPiAgICAgICBEYXRlICAgICAgICAgICAgOiAy MDE1LTAzLTA2DQo+DQo+QWJzdHJhY3Q6DQo+ICAgQkdQU0VDIHdpbGwgbmVlZCB0byBhZGRyZXNz IHRoZSBpbXBhY3QgZnJvbSByZWd1bGFyIGFuZCBlbWVyZ2VuY3kNCj4gICByb2xsb3ZlciBwcm9j ZXNzZXMgZm9yIHRoZSBCR1BTRUMgRW5kLUVudGl0eSAoRUUpIGNlcnRpZmljYXRlcyB0aGF0DQo+ ICAgd2lsbCBiZSBwZXJmb3JtZWQgYnkgQ2VydGlmaWNhdGUgQXV0aG9yaXRpZXMgKENBcykgcGFy dGljaXBhdGluZyBhdA0KPiAgIHRoZSBSZXNvdXJjZSBQdWJsaWMgS2V5IEluZnJhc3RydWN0dXJl IChSUEtJKS4gIFJvbGxvdmVycyBvZiBCR1BTRUMNCj4gICBFRSBjZXJ0aWZpY2F0ZXMgbXVzdCBi ZSBjYXJlZnVsbHkgbWFuYWdlZCBpbiBvcmRlciB0byBzeW5jaHJvbml6ZQ0KPiAgIGRpc3RyaWJ1 dGlvbiBvZiByb3V0ZXIgcHVibGljIGtleXMgYW5kIHRoZSB1c2FnZSBvZiB0aG9zZSBwdWJpYyBr ZXlzDQo+ICAgYnkgQkdQU0VDIHJvdXRlcnMuICBUaGlzIGRvY3VtZW50IHByb3ZpZGVzIGdlbmVy YWwgcmVjb21tZW5kYXRpb25zDQo+ICAgZm9yIHRoYXQgcHJvY2VzcywgYXMgd2VsbCBhcyBkZXNj cmliaW5nIHJlYXNvbnMgd2h5IHRoZSByb2xsb3ZlciBvZg0KPiAgIEJHUFNFQyBFRSBjZXJ0aWZp Y2F0ZXMgbWlnaHQgYmUgbmVjc3NhcnkuDQo+DQo+DQo+VGhlIElFVEYgZGF0YXRyYWNrZXIgc3Rh dHVzIHBhZ2UgZm9yIHRoaXMgZHJhZnQgaXM6DQo+aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9y Zy9kb2MvZHJhZnQtaWV0Zi1zaWRyLWJncHNlYy1yb2xsb3Zlci8NCj4NCj5UaGVyZSdzIGFsc28g YSBodG1saXplZCB2ZXJzaW9uIGF2YWlsYWJsZSBhdDoNCj5odHRwOi8vdG9vbHMuaWV0Zi5vcmcv aHRtbC9kcmFmdC1pZXRmLXNpZHItYmdwc2VjLXJvbGxvdmVyLTAzDQo+DQo+QSBkaWZmIGZyb20g dGhlIHByZXZpb3VzIHZlcnNpb24gaXMgYXZhaWxhYmxlIGF0Og0KPmh0dHA6Ly93d3cuaWV0Zi5v cmcvcmZjZGlmZj91cmwyPWRyYWZ0LWlldGYtc2lkci1iZ3BzZWMtcm9sbG92ZXItMDMNCj4NCj4N Cj5QbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0 aGUgdGltZSBvZg0KPnN1Ym1pc3Npb24NCj51bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQg ZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xzLmlldGYub3JnLg0KPg0KPkludGVybmV0LURyYWZ0 cyBhcmUgYWxzbyBhdmFpbGFibGUgYnkgYW5vbnltb3VzIEZUUCBhdDoNCj5mdHA6Ly9mdHAuaWV0 Zi5vcmcvaW50ZXJuZXQtZHJhZnRzLw0KPg0KPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQo+c2lkciBtYWlsaW5nIGxpc3QNCj5zaWRyQGlldGYub3JnDQo+ aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zaWRyDQoNCg0KVGhpcyBFLW1h aWwgYW5kIGFueSBvZiBpdHMgYXR0YWNobWVudHMgbWF5IGNvbnRhaW4gVGltZSBXYXJuZXIgQ2Fi bGUgcHJvcHJpZXRhcnkgaW5mb3JtYXRpb24sIHdoaWNoIGlzIHByaXZpbGVnZWQsIGNvbmZpZGVu dGlhbCwgb3Igc3ViamVjdCB0byBjb3B5cmlnaHQgYmVsb25naW5nIHRvIFRpbWUgV2FybmVyIENh YmxlLiBUaGlzIEUtbWFpbCBpcyBpbnRlbmRlZCBzb2xlbHkgZm9yIHRoZSB1c2Ugb2YgdGhlIGlu ZGl2aWR1YWwgb3IgZW50aXR5IHRvIHdoaWNoIGl0IGlzIGFkZHJlc3NlZC4gSWYgeW91IGFyZSBu b3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCBvZiB0aGlzIEUtbWFpbCwgeW91IGFyZSBoZXJlYnkg bm90aWZpZWQgdGhhdCBhbnkgZGlzc2VtaW5hdGlvbiwgZGlzdHJpYnV0aW9uLCBjb3B5aW5nLCBv ciBhY3Rpb24gdGFrZW4gaW4gcmVsYXRpb24gdG8gdGhlIGNvbnRlbnRzIG9mIGFuZCBhdHRhY2ht ZW50cyB0byB0aGlzIEUtbWFpbCBpcyBzdHJpY3RseSBwcm9oaWJpdGVkIGFuZCBtYXkgYmUgdW5s YXdmdWwuIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgRS1tYWlsIGluIGVycm9yLCBwbGVhc2Ug bm90aWZ5IHRoZSBzZW5kZXIgaW1tZWRpYXRlbHkgYW5kIHBlcm1hbmVudGx5IGRlbGV0ZSB0aGUg b3JpZ2luYWwgYW5kIGFueSBjb3B5IG9mIHRoaXMgRS1tYWlsIGFuZCBhbnkgcHJpbnRvdXQuDQo= From nobody Thu Apr 2 09:30: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 9A87E1ACE3E for ; Thu, 2 Apr 2015 09:30:33 -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 X7HotJtBahef for ; Thu, 2 Apr 2015 09:30:32 -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 9061E1ACE4F for ; Thu, 2 Apr 2015 09:30:32 -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 1Ydi0l-0002ac-DH; Thu, 02 Apr 2015 16:30:31 +0000 Date: Thu, 02 Apr 2015 09:30:30 -0700 Message-ID: From: Randy Bush To: "George, Wes" In-Reply-To: References: <20150307004344.316.10229.idtracker@ietfa.amsl.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Cc: "sidr@ietf.org" Subject: Re: [sidr] I-D Action: draft-ietf-sidr-bgpsec-rollover-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, 02 Apr 2015 16:30:33 -0000 > One question that comes up when reading this document. Now that we've > removed the dependency between Origin Validation and Path Validation but > are expecting them to run in parallel with some shared components, do we > need to discuss how BGPSec cert rollover interacts with Origin Validation > cert rollover, possibly giving hints to what a combined rollover process > looks like? Are we expecting that they should be done at the same time, or > that they should NOT be done at the same time, or does it just not matter? > For example, if it's better to have the rolls done separately, then > probably some guidance about the expiry times not lining up might be good. > It's conceivable that if you're doing an emergency roll on account of > compromised keys, you might be doing both at once, regardless of whether > it's a good idea normally, so I think we need to highlight any gotchas > that may be present. Maybe this belongs in the ops doc? the enumeration of all tuples which do not interact may be dauntingly large randy From nobody Fri Apr 3 11:18:59 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 5746F1ACED3 for ; Fri, 3 Apr 2015 11:18:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.91 X-Spam-Level: X-Spam-Status: No, score=-0.91 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 867xOCbQCXjJ for ; Fri, 3 Apr 2015 11:18:55 -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 310951ACE9F for ; Fri, 3 Apr 2015 11:18:55 -0700 (PDT) Received: from dhcp89-089-172.bbn.com ([128.89.89.172]:58037) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1Ye6BB-0009go-Oa for sidr@ietf.org; Fri, 03 Apr 2015 14:18:53 -0400 Message-ID: <551ED98D.5070104@bbn.com> Date: Fri, 03 Apr 2015 14:18:53 -0400 From: Karen Seo 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@ietf.org References: <54FE8373.6070902@bbn.com> In-Reply-To: <54FE8373.6070902@bbn.com> Content-Type: multipart/alternative; boundary="------------090607010507000007090405" Archived-At: Subject: [sidr] Correction re: 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: Fri, 03 Apr 2015 18:18:58 -0000 This is a multi-part message in MIME format. --------------090607010507000007090405 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Folks, Here's a better description of Case 3. (Thanks go to David Mandelberg for catching the problems with the previous version.) 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 to re-route traffic from these organizations that is destined for a set of systems outside of A's administrative control to a set of systems under its control, or to have that traffic dropped. A accomplishes this by controlling the UPDATES (for the routes to the addresses for those systems) that are sent to those organizations. If these organizations use the RPKI, A needs a way to ensure the information they obtain from the RPKI supports A’s traffic management goals. For example, Alice runs the network operations for a large consortium C that operates AS Y. Her management requests that traffic from C's members that is destined for a competitor's server at address Q in AS X, be re-directed to one of C's servers in AS Y. To do this,Alice assigns address Q to a server in AS Y and has AS Y originate routes for address Q. Alice has to ensure that the RPKI has the appropriate certificates, ROAs, etc. for these approved routes, as well as for the rest of the Internet. Karen On 3/10/15 1:38 AM, Karen Seo wrote: > 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 > > > > > > > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr --------------090607010507000007090405 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
Folks,

Here's a better description of Case 3. (Thanks go to David Mandelberg for catching the problems with the previous version.)
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 to re-route traffic from these organizations that is destined for a set of systems outside of A's administrative control to a set of systems under its control, or to have that traffic dropped. A accomplishes this by controlling the UPDATES (for the routes to the addresses for those systems) that are sent to those organizations. If these organizations use the RPKI, A needs a way to ensure the information they obtain from the RPKI supports A’s traffic management goals.
For example, Alice runs the network operations for a large consortium C that operates AS Y. Her management requests that traffic from C's members that is destined for a competitor's server at address Q in AS X, be re-directed to one of C's servers in AS Y.  To do this, Alice assigns address Q to a server in AS Y and has AS Y originate routes for address Q. Alice has to ensure that the RPKI has the appropriate certificates, ROAs, etc. for these approved routes, as well as for the rest of the Internet.
Karen

On 3/10/15 1:38 AM, Karen Seo wrote:
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

 
 
 

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

--------------090607010507000007090405-- From nobody Wed Apr 8 18:35:11 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 1378F1ACDB8 for ; Wed, 8 Apr 2015 18:35:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.51 X-Spam-Level: **** X-Spam-Status: No, score=4.51 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_SBL_CSS=3.335, RCVD_IN_XBL=0.375] 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 NXsM3dOBNHKI for ; Wed, 8 Apr 2015 18:35:07 -0700 (PDT) Received: from mail.zdns.cn (smtp.knet.cn [202.173.10.15]) by ietfa.amsl.com (Postfix) with SMTP id 2B3791ACDAE for ; Wed, 8 Apr 2015 18:35:06 -0700 (PDT) X-TM-DID: fa35e2629ca846414aa253e927ab9775 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Declan Ma In-Reply-To: <551ED98D.5070104@bbn.com> Date: Thu, 9 Apr 2015 09:34:59 +0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <54FE8373.6070902@bbn.com> <551ED98D.5070104@bbn.com> To: Karen Seo X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: sidr wg list Subject: Re: [sidr] Correction re: 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: Thu, 09 Apr 2015 01:35:10 -0000 Karen, =20 This is indeed a better description. And I believe it would be even better if Randy could describe how a = "local trust anchor=E2=80=9D takes effect on different cases. Declan Ma ZDNS Ltd. > =E5=9C=A8 2015=E5=B9=B44=E6=9C=884=E6=97=A5=EF=BC=8C=E4=B8=8A=E5=8D=882:= 18=EF=BC=8CKaren Seo =E5=86=99=E9=81=93=EF=BC=9A >=20 > Folks, >=20 > Here's a better description of Case 3. (Thanks go to David Mandelberg = for catching the problems with the previous version.)=20 > 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 to re-route traffic from these organizations that = is destined for a set of systems outside of A's administrative control = to a set of systems under its control, or to have that traffic dropped. = A accomplishes this by controlling the UPDATES (for the routes to the = addresses for those systems) that are sent to those organizations. If = these organizations use the RPKI, A needs a way to ensure the = information they obtain from the RPKI supports A=E2=80=99s traffic = management goals. >=20 > For example, Alice runs the network operations for a large consortium = C that operates AS Y. Her management requests that traffic from C's = members that is destined for a competitor's server at address Q in AS X, = be re-directed to one of C's servers in AS Y. To do this, Alice assigns = address Q to a server in AS Y and has AS Y originate routes for address = Q. Alice has to ensure that the RPKI has the appropriate certificates, = ROAs, etc. for these approved routes, as well as for the rest of the = Internet.=20 > Karen >=20 > On 3/10/15 1:38 AM, Karen Seo wrote: >> Randy et al.,=20 >>=20 >> 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?=20 >>=20 >> 4. Use Cases >>=20 >> 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: >> =E2=80=A2 unintentional, i.e., due to an error by RIR (or ISP) = staff >> =E2=80=A2 malicious, i.e., done with the intent to cause = problems, which could be aimed at C or some other entity. >> =E2=80=A2 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).=20 >>=20 >> 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. >>=20 >> 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=E2=80=99s traffic management goals. >>=20 >> 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 >>=20 >> =20 >>=20 >> =20 >>=20 >>=20 >> _______________________________________________ >> sidr mailing list >>=20 >> sidr@ietf.org >> https://www.ietf.org/mailman/listinfo/sidr >=20 > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr From nobody Wed Apr 8 19:41:59 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 86B211B3734 for ; Wed, 8 Apr 2015 19:41:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 ETYtyFltpCrE for ; Wed, 8 Apr 2015 19:41:56 -0700 (PDT) Received: from mail-qk0-x235.google.com (mail-qk0-x235.google.com [IPv6:2607:f8b0:400d:c09::235]) (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 05D511B3733 for ; Wed, 8 Apr 2015 19:41:56 -0700 (PDT) Received: by qkgx75 with SMTP id x75so106386955qkg.1 for ; Wed, 08 Apr 2015 19:41:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=5EcMGzVzOSPA+6EcDBO9SiKjnIJcUh8qhftxUr0AcK0=; b=jPnJMTmPUz3PUefkOS663FBwRwWhTyNUpJ0GhOIjikPdHwQg41l2ZK7dbeYlrKF+dY 3Oz1EMAN1m4mCaQUbl6dMc9XTu/IxEGXcNambu81SRLnIf/NMZ2NgonXndfFodLQEjXj 1TktwkhFpv8qs0mVhXuHBq5+9F6xIkLW5MAoQcO6XZ/fHzw3VORk2cDyzk0KAOb3C/1L iCpTCMFMOiXsezQgxv36ZCH7XwwMNyvtUG4UvdaH1lS3sfS8ZARcsL04Pnf13JFP5sXN eK6apwtgP9Ye9kN4OpfRgB2XGW6vuZGkcK8BcX80mx3LAdW8FoH7ApCt370V4lLGZAul L43A== MIME-Version: 1.0 X-Received: by 10.140.150.73 with SMTP id 70mr25618801qhw.10.1428547315264; Wed, 08 Apr 2015 19:41:55 -0700 (PDT) Sender: christopher.morrow@gmail.com Received: by 10.140.19.133 with HTTP; Wed, 8 Apr 2015 19:41:55 -0700 (PDT) In-Reply-To: References: <54FE8373.6070902@bbn.com> <551ED98D.5070104@bbn.com> Date: Wed, 8 Apr 2015 22:41:55 -0400 X-Google-Sender-Auth: EFZb6R0SfKxK3SYldRnu9eOAnf0 Message-ID: From: Christopher Morrow To: Declan Ma Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: sidr wg list Subject: Re: [sidr] Correction re: 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: Thu, 09 Apr 2015 02:41:58 -0000 could I suggest that: "A" ... is a bit rough on the reader in sentences like: "A wants to re-route traffic from these organizations..." A what? a giraffe? oh! Entity-A (or Network-A).. maybe change 'A' to 'Entity-A' or 'Network-A' ? Also there's a sad choice of time to use a pronoun in your example: "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 to re-route traffic from these organizations that is destined for a set of systems outside of A's administrative control to a set of systems under its control, or to have that traffic dropped." What is 'its' there? Org-A? his customers? the systems? generally it would be better to be clear and not use pronouns. On Wed, Apr 8, 2015 at 9:34 PM, Declan Ma wrote: > Karen, > > This is indeed a better description. > > And I believe it would be even better if Randy could describe how a "loca= l trust anchor=E2=80=9D takes effect on different cases. > > > Declan Ma > > ZDNS Ltd. > > > >> =E5=9C=A8 2015=E5=B9=B44=E6=9C=884=E6=97=A5=EF=BC=8C=E4=B8=8A=E5=8D=882:= 18=EF=BC=8CKaren Seo =E5=86=99=E9=81=93=EF=BC=9A >> >> Folks, >> >> Here's a better description of Case 3. (Thanks go to David Mandelberg fo= r catching the problems with the previous version.) >> Case 3: >> Organization A is authorized to control the routing of traffic from a se= t of organizations (within A's administrative control) to the rest of the I= nternet. A wants to re-route traffic from these organizations that is desti= ned for a set of systems outside of A's administrative control to a set of = systems under its control, or to have that traffic dropped. A accomplishes = this by controlling the UPDATES (for the routes to the addresses for those = systems) that are sent to those organizations. If these organizations use t= he RPKI, A needs a way to ensure the information they obtain from the RPKI = supports A=E2=80=99s traffic management goals. >> >> For example, Alice runs the network operations for a large consortium C = that operates AS Y. Her management requests that traffic from C's members t= hat is destined for a competitor's server at address Q in AS X, be re-direc= ted to one of C's servers in AS Y. To do this, Alice assigns address Q to = a server in AS Y and has AS Y originate routes for address Q. Alice has to = ensure that the RPKI has the appropriate certificates, ROAs, etc. for these= approved routes, as well as for the rest of the Internet. >> Karen >> >> On 3/10/15 1:38 AM, Karen Seo wrote: >>> Randy et al., >>> >>> In hopes of restarting work on this draft, here is proposed text for se= ction 4. This is an attempt to integrate the original text with the comment= s to the list submitted back in Feb 2014. My apologies if I've mis-underst= ood the original draft text or the comments. Does this correctly and clear= ly describe the use cases? >>> >>> 4. Use Cases >>> >>> Case 1: >>> Organization C finds that its CA certificate has been revoked (or modif= ied to remove resources) by the RIR (or ISP) that issued it. Or, if C has o= utsourced its CA operations, C finds that one of its children's certificate= s 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 discr= etion, the certificate revocation (or modification). The revocation or modi= fication could be: >>> =E2=80=A2 unintentional, i.e., due to an error by RIR (or ISP) sta= ff >>> =E2=80=A2 malicious, i.e., done with the intent to cause problems,= which could be aimed at C or some other entity. >>> =E2=80=A2 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 commu= nity 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 s= et of organizations (within A's administrative control) to the rest of the = Internet. A wants traffic from these organizations that is destined for a s= et 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 n= eeds a way to coordinate their use of the RPKI in support of A=E2=80=99s tr= affic 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 >>> >>> >>> >>> >>> >>> >>> _______________________________________________ >>> sidr mailing list >>> >>> sidr@ietf.org >>> https://www.ietf.org/mailman/listinfo/sidr >> >> _______________________________________________ >> sidr mailing list >> sidr@ietf.org >> https://www.ietf.org/mailman/listinfo/sidr > > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr From nobody Thu Apr 9 11:57:39 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 C68951A88F1 for ; Thu, 9 Apr 2015 11:57:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_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 ga8F76NqLVog for ; Thu, 9 Apr 2015 11:57:31 -0700 (PDT) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ECB2A1A88EF for ; Thu, 9 Apr 2015 11:57:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=16130; q=dns/txt; s=iport; t=1428605851; x=1429815451; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=YjsQlhO5oitHuitjn448tBj1TwvDM0mNkwZQMUbr16k=; b=m5FqD1WRdDcAaHGpnEnouFmW13y+WCqIhX2gxcZurILsDeDMJbVTIo1i DqPycIIZWaAFT4Wm5oQvuTdqfy8/Z8rJrUKyJsdU/VjfVsaUYg7RLA9vg DE6ydzVq6GYdiQIvhGLfT99KvRkIXU7a87pzLkTfNgNTm3O5llCMoaKrS Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0C8BABWyyZV/4YNJK1cgkVDgS4FxEUJh1QCgUY4FAEBAQEBAQF9hCABAQQnUhACAQg/BzIUEQIEAQ0FiCrOXAEBAQEBAQEBAgEBAQEBAQEBAQEBF4srhCRYB4QtBY5rghaGI4NogR2MQIM6g0siggMcgVBvgQMBHgYcfwEBAQ X-IronPort-AV: E=Sophos;i="5.11,551,1422921600"; d="scan'208,217";a="139803483" Received: from alln-core-12.cisco.com ([173.36.13.134]) by alln-iport-6.cisco.com with ESMTP; 09 Apr 2015 18:57:12 +0000 Received: from xhc-aln-x01.cisco.com (xhc-aln-x01.cisco.com [173.36.12.75]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id t39IvCAk024964 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 9 Apr 2015 18:57:12 GMT Received: from xmb-aln-x15.cisco.com ([169.254.9.109]) by xhc-aln-x01.cisco.com ([173.36.12.75]) with mapi id 14.03.0195.001; Thu, 9 Apr 2015 13:57:11 -0500 From: "Alvaro Retana (aretana)" To: "George, Wes" , "sidr@ietf.org" Thread-Topic: Review of draft-ietf-sidr-as-migration Thread-Index: AQHQZXyNDyFG42UFI02j3QHCiXZMQ503SiiAgA3pjwA= Date: Thu, 9 Apr 2015 18:57:11 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.117.15.13] Content-Type: multipart/alternative; boundary="_000_D14063379D3ABaretanaciscocom_" 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: Thu, 09 Apr 2015 18:57:34 -0000 --_000_D14063379D3ABaretanaciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable On 3/31/15, 2:29 PM, "George, Wes" > wrote: Wes: Some replies below. Thanks! Alvaro. Added SIDR, responses below inline, which of course messed up your original= numbering. I haven't pushed the rev yet, as I'm waiting to make sure that I don't need= to make additional changes based on the revision to the BGPSec protocol do= c. . . . 1. Section 3. s/SHOULD NOT/should not We can=92t use rfc2119 languag= e to mandate the behavior of an operator; in this case related to the amoun= t of time the transition phase lasts. I think you have made a good point a= bout the need to not stay there forever, but have also said that the transi= tion is not always under the control of the operator. WG] I disagree with the blanket assertion that we can't normatively mandate= the behavior of an operator in the context of a standard or BCP document, = and I think that the guidance is correct here =96 operators SHOULD NOT stay= in transition indefinitely. Should rather than must because we know that t= here are extenuating circumstances and acknowledging that we tried to keep = it simple. rfc2119 says, about the keywords: "MUST only be used where it is actually r= equired for interoperation or to limit behavior which has potential for cau= sing harm=94. While I completely agree that the transition shouldn=92t take forever, the = use that you=92re proposing doesn=92t have anything to do with interoperabi= lity, nor will taking longer than expected/usual actually causes harm from = the specification point of view. Yes, the operator will have to deal with = a cumbersome configuration/deployment, but the knobs in this case are speci= fied "to keep the additional complexity during the transition period to a m= inimum=94. To all this, how would you even determine if someone was not adhering to th= e recommendation? Do you measure the time in days, weeks, months, years? = I=92m sure that the transition timeframe is very dependent on the network/= deployment/operations and probably many other things I haven=92t even thoug= ht about. . . . 1. 3.2.1 s/MUST/must You=92re making reference to something that is = not specified in another document.. WG] right, I'm observing that the behavior is not normatively specified, he= nce the caps. I=92m not sure if you=92re agreeing with me or if you=92re further justifyi= ng the use. The section we=92re talking about reads: 3.2.1. Outbound announcements (PE-->CE) When PE1 is moved from AS64510 to AS64500, it will be provisioned with the appropriate keys for AS64500 to allow it to forward-sign routes using AS64500. However, there is currently no guidance in the BGPSec protocol specification on whether or not the forward-signed ASN value MUST match the configured "remote-as" to validate properly. That is, if CE1's BGP session is configured as "remote-as 64510", the presence of "local-as 64510" on PE1 will ensure that there is no ASN mismatch on the BGP session itself, but if CE1 receives updates from its remote neighbor (PE1) forward-signed from AS64500, there is no guidance as to whether the BGPSec validator on CE1 still consider those valid by default. RFC4271 [RFC4271] section 6.3 mentions this match between the ASN of the peer and the AS_PATH data, but it is listed as an optional validation, rather than a requirement. Assuming that this mismatch will be allowed by vendor implementations and using it as a means to solve this migration case is likely to be Problematic. Sounds to me that you want BGPSec to say that the values MUST match, is tha= t correct? If so, then I see two ways forward: 1. Work to include that =93MUST=94 in the BGPSec draft. And then refere= nce it here. 2. Given that the BGPSec draft deals with the base BGP spec and that her= e we=92re talking about the new mechanism from idr-as-migration, then chang= e the text above to explicitly say what you want to happen (=93MUST match= =94) and then this document would be eventually marked as updating the BGPS= ec base spec. [We might need to consider the order of processing of the do= cuments through the IESG so that the update makes sense.] . . . 1. 5.3 "While this is not prohibited by BGPSec [I-D.ietf-sidr-bgpsec-pr= otocol], routers that receive updates from iBGP neighbors MUST NOT reject u= pdates with new (valid) BGPSec attributes..=94 Does this represent an upda= te to BGPSec? Are you implying that the iBGP receiver should check the val= idity of the attributes? I know that at this point it is a little weird to= update a draft (not an RFC), but the process should take care of the appro= priate references. [Maybe the update is not needed based on the discussion = in the WG today.] WG] what this is saying is that BGPSec is currently silent on this, and mak= ing an update to clarify what the behavior needs to be. As to whether the u= pdates need to be validated in iBGP, I'm not explicitly requiring that, as = I think it's really more of an implementation detail. Ok, so it is an update to BGPSec. This is important because the header sho= uld say so and I would like to see a section that summarizes the updates. As far as the iBGP validation, I think the word =93valid=94 is what was thr= owing me off. You mean valid as in well formed, etc. --_000_D14063379D3ABaretanaciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
On 3/31/15, 2:29 PM, "George, Wes" <wesley.george@twcable.com> wrote:

Wes:

Some replies below.

Thanks!

Alvaro.


Added SIDR, responses below inline, which of course messed up your ori= ginal numbering.
I haven't pushed the rev yet, as I'm waiting to make sure that I don't= need to make additional changes based on the revision to the BGPSec protoc= ol doc. 

. . .
  1. Section 3. s/SHOULD NOT/should not     We can=92t use rfc2119 lan= guage to mandate the behavior of an operator; in this case related to the a= mount of time the transition phase lasts.  I think you have made a goo= d point about the need to not stay there forever, but have also said that the transition is not always under the control of = the operator.
WG] I disagree with the blanket assertion that we can't normatively ma= ndate the behavior of an operator in the context of a standard or BCP docum= ent, and I think that the guidance is correct here =96 operators SHOULD NOT= stay in transition indefinitely. Should rather than must because we know that there are extenuating circums= tances and acknowledging that we tried to keep it simple.

rfc2119 says, about the keywords: "MUST only be used where it is = actually required for interoperation or to limit behavior which has potenti= al for causing harm=94.

While I completely agree that the transition shouldn=92t take forever,= the use that you=92re proposing doesn=92t have anything to do with interop= erability, nor will taking longer than expected/usual actually causes harm = from the specification point of view.  Yes, the operator will have to deal with a cumbersome configuration/= deployment, but the knobs in this case are specified "to keep the addi= tional complexity during the transition period to a minimum=94.

To all this, how would you even determine if someone was not adhering = to the recommendation?  Do you measure the time in days, weeks, months= , years?   I=92m sure that the transition timeframe is very dependent = on the network/deployment/operations and probably many other things I haven=92t even thought about.

. . .
  1. 3.2.1 s/MUST/must     You=92re making reference to something that= is not specified in another document..
WG] right, I'm observing that the behavior is not normatively specifie= d, hence the caps.

I=92m not sure if you=92re agreeing with me or if you=92re further jus= tifying the use.

The section we=92re talking about reads:

3.2.1.  Outbound announcements (PE-->CE)

   When PE1 is moved from AS64510 to AS64500, it will be pro= visioned
   with the appropriate keys for AS64500 to allow it to forw= ard-sign
   routes using AS64500.  However, there is currently n= o guidance in the
   BGPSec protocol specification on whether or not the forwa= rd-signed
   ASN value MUST match the configured "remote-as"= to validate properly.
   That is, if CE1's BGP session is configured as "remo= te-as 64510", the
   presence of "local-as 64510" on PE1 will ensure= that there is no ASN
   mismatch on the BGP session itself, but if CE1 receives u= pdates from
   its remote neighbor (PE1) forward-signed from AS64500, th= ere is no
   guidance as to whether the BGPSec validator on CE1 still = consider
   those valid by default.  RFC4271 [RFC4271] section 6= .3 mentions this
   match between the ASN of the peer and the AS_PATH data, b= ut it is
   listed as an optional validation, rather than a requireme= nt.
   Assuming that this mismatch will be allowed by vendor imp= lementations
   and using it as a means to solve this migration case is l= ikely to be
   Problematic.

Sounds to me that you want BGPSec to say that the values MUST match, i= s that correct?

If so, then I see two ways forward:
  1. Work to include that =93MUST=94 in the BGPSec draft.  And then ref= erence it here.
  2. Given that the BGPSec draft deals with the base BGP= spec and that here we=92re talking about the new mechanism from idr-as-mig= ration, then change the text above to explicitly say what you want to happe= n (=93MUST match=94) and then this document would be eventually marked as updating the BGPSec base spec.  [We might need to consider = the order of processing of the documents through the IESG so that the updat= e makes sense.]

. . .
  1. 5.3  "While this is not prohibited by BGPSec [I-D.= ietf-sidr-bgpsec-protocol], routers that receive updates from iBGP neighbors = MUST NOT reject updates with new (valid) BGPSec attributes..=94  Does this represent an update to BGPSec?  Are you implying that the iBGP receiver sh= ould check the validity of the attributes?  I know that at this point = it is a little weird to update a draft (not an RFC), but the process s= hould take care of the appropriate references. [Maybe the update is not needed based on the discussion in the WG today.]<= /li>
WG] what this is saying is that BGPSec is currently silent on this, an= d making an update to clarify what the behavior needs to be. As to whether = the updates need to be validated in iBGP, I'm not explicitly requiring that= , as I think it's really more of an implementation detail.

Ok, so it is an update to BGPSec.  This is important because the = header should say so and I would like to see a section that summarizes the = updates.

As far as the iBGP validation, I think the word =93valid=94 is what wa= s throwing me off.  You mean valid as in well formed, etc.
--_000_D14063379D3ABaretanaciscocom_-- From nobody Thu Apr 9 13:13: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 409B21B31C9 for ; Thu, 9 Apr 2015 13:13:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.226 X-Spam-Level: X-Spam-Status: No, score=0.226 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001, 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 cz_q8HzjAMpg for ; Thu, 9 Apr 2015 13:13:30 -0700 (PDT) Received: from cdcipgw02.twcable.com (cdcipgw02.twcable.com [165.237.91.111]) by ietfa.amsl.com (Postfix) with ESMTP id 459501B31C7 for ; Thu, 9 Apr 2015 13:13:29 -0700 (PDT) X-SENDER-IP: 10.136.163.15 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="5.11,552,1422939600"; d="scan'208,217";a="236950904" Received: from unknown (HELO PRVPEXHUB06.corp.twcable.com) ([10.136.163.15]) by cdcipgw02.twcable.com with ESMTP/TLS/RC4-MD5; 09 Apr 2015 16:00:01 -0400 Received: from PRVPEXVS10.corp.twcable.com ([10.136.163.40]) by PRVPEXHUB06.corp.twcable.com ([10.136.163.15]) with mapi; Thu, 9 Apr 2015 16:13:28 -0400 From: "George, Wes" To: "Alvaro Retana (aretana)" , "sidr@ietf.org" Date: Thu, 9 Apr 2015 16:13:27 -0400 Thread-Topic: Review of draft-ietf-sidr-as-migration Thread-Index: AdBzAaQNbFzrImpBRRKKFS/xqQ3tfQ== 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_D14C49584CDB2wesleygeorgetwcablecom_" 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: Thu, 09 Apr 2015 20:13:34 -0000 --_000_D14C49584CDB2wesleygeorgetwcablecom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 TW9yZSBpbmxpbmUNCg0KVGhhbmtzLA0KDQpXZXMNCg0KRnJvbTogIkFsdmFybyBSZXRhbmEgKGFy ZXRhbmEpIiA8YXJldGFuYUBjaXNjby5jb208bWFpbHRvOmFyZXRhbmFAY2lzY28uY29tPj4NCkRh dGU6IFRodXJzZGF5LCBBcHJpbCA5LCAyMDE1IGF0IDI6NTcgUE0NClRvOiAiR2VvcmdlLCBXZXMi IDx3ZXNsZXkuZ2VvcmdlQHR3Y2FibGUuY29tPG1haWx0bzp3ZXNsZXkuZ2VvcmdlQHR3Y2FibGUu Y29tPj4sICJzaWRyQGlldGYub3JnPG1haWx0bzpzaWRyQGlldGYub3JnPiIgPHNpZHJAaWV0Zi5v cmc8bWFpbHRvOnNpZHJAaWV0Zi5vcmc+Pg0KQ2M6ICJkcmFmdC1pZXRmLXNpZHItYXMtbWlncmF0 aW9uQHRvb2xzLmlldGYub3JnPG1haWx0bzpkcmFmdC1pZXRmLXNpZHItYXMtbWlncmF0aW9uQHRv b2xzLmlldGYub3JnPiIgPGRyYWZ0LWlldGYtc2lkci1hcy1taWdyYXRpb25AdG9vbHMuaWV0Zi5v cmc8bWFpbHRvOmRyYWZ0LWlldGYtc2lkci1hcy1taWdyYXRpb25AdG9vbHMuaWV0Zi5vcmc+Pg0K U3ViamVjdDogUmU6IFJldmlldyBvZiBkcmFmdC1pZXRmLXNpZHItYXMtbWlncmF0aW9uDQoNCnJm YzIxMTkgc2F5cywgYWJvdXQgdGhlIGtleXdvcmRzOiAiTVVTVCBvbmx5IGJlIHVzZWQgd2hlcmUg aXQgaXMgYWN0dWFsbHkgcmVxdWlyZWQgZm9yIGludGVyb3BlcmF0aW9uIG9yIHRvIGxpbWl0IGJl aGF2aW9yIHdoaWNoIGhhcyBwb3RlbnRpYWwgZm9yIGNhdXNpbmcgaGFybeKAnS4NCg0KV2hpbGUg SSBjb21wbGV0ZWx5IGFncmVlIHRoYXQgdGhlIHRyYW5zaXRpb24gc2hvdWxkbuKAmXQgdGFrZSBm b3JldmVyLCB0aGUgdXNlIHRoYXQgeW914oCZcmUgcHJvcG9zaW5nIGRvZXNu4oCZdCBoYXZlIGFu eXRoaW5nIHRvIGRvIHdpdGggaW50ZXJvcGVyYWJpbGl0eSwgbm9yIHdpbGwgdGFraW5nIGxvbmdl ciB0aGFuIGV4cGVjdGVkL3VzdWFsIGFjdHVhbGx5IGNhdXNlcyBoYXJtIGZyb20gdGhlIHNwZWNp ZmljYXRpb24gcG9pbnQgb2Ygdmlldy4gIFllcywgdGhlIG9wZXJhdG9yIHdpbGwgaGF2ZSB0byBk ZWFsIHdpdGggYSBjdW1iZXJzb21lIGNvbmZpZ3VyYXRpb24vZGVwbG95bWVudCwgYnV0IHRoZSBr bm9icyBpbiB0aGlzIGNhc2UgYXJlIHNwZWNpZmllZCAidG8ga2VlcCB0aGUgYWRkaXRpb25hbCBj b21wbGV4aXR5IGR1cmluZyB0aGUgdHJhbnNpdGlvbiBwZXJpb2QgdG8gYSBtaW5pbXVt4oCdLg0K DQpUbyBhbGwgdGhpcywgaG93IHdvdWxkIHlvdSBldmVuIGRldGVybWluZSBpZiBzb21lb25lIHdh cyBub3QgYWRoZXJpbmcgdG8gdGhlIHJlY29tbWVuZGF0aW9uPyAgRG8geW91IG1lYXN1cmUgdGhl IHRpbWUgaW4gZGF5cywgd2Vla3MsIG1vbnRocywgeWVhcnM/ICAgSeKAmW0gc3VyZSB0aGF0IHRo ZSB0cmFuc2l0aW9uIHRpbWVmcmFtZSBpcyB2ZXJ5IGRlcGVuZGVudCBvbiB0aGUgbmV0d29yay9k ZXBsb3ltZW50L29wZXJhdGlvbnMgYW5kIHByb2JhYmx5IG1hbnkgb3RoZXIgdGhpbmdzIEkgaGF2 ZW7igJl0IGV2ZW4gdGhvdWdodCBhYm91dC4NCg0KV0ddIHdlbGwsIEknbGwgYmUgaG9uZXN0LCB0 aGUgcGhpbG9zb3BoeSBiZWhpbmQgMjExOSB3b3JkcyBpc24ndCBhIGhpbGwgSSdtIHdpbGxpbmcg dG8gZGllIG9uLiBJZiBpdCBpcyBmb3IgeW91LCB0aGF0J3MgZmluZSBhbmQgSSdsbCBjaGFuZ2Ug aXQsIGJ1dCBJJ3ZlIHJlYWQgcGxlbnR5IG9mIElFVEYgZG9jdW1lbnRzIHRoYXQgYXJlIHByZXR0 eSBsaWJlcmFsIGluIHRoZWlyIGludGVycHJldGF0aW9uIG9mIGhhcm1mdWwgYXMganVzdGlmaWNh dGlvbiBmb3IgdXNpbmcgbm9ybWF0aXZlIHdvcmRzIOKAkyBpdCBpc24ndCBsaW1pdGVkIHNpbXBs eSB0byB0aGUgcHJvdG9jb2wgYW5kIHVubGVzcyB3ZSBzdGFydCBleHBsaWNpdGx5IHByb2hpYml0 aW5nIDIxMTkgbGFuZ3VhZ2Ugb3V0c2lkZSBvZiBwcm90b2NvbCBzcGVjcywgeW91J3JlIGdvaW5n IHRvIGhhdmUgdGhpcyBhcmd1bWVudCB3aXRoIGEgbG90IG9mIHBlb3BsZSBJIHRoaW5rLiBBcyBm b3IgZW5mb3JjZW1lbnQsIHRoaXMgaXNuJ3QgdGllZCB0byBhbiBlbGFwc2VkIHRpbWUsIGFuZCBJ IGRvbid0IGV2ZW4gcmVhbGx5IHVuZGVyc3RhbmQgd2hhdCBlbmZvcmNlbWVudCBtZWFucyBpbiB0 aGlzIGNvbnRleHQg4oCTIGhvdyBkb2VzIElFVEYgZW5mb3JjZSBhbnl0aGluZywgZXNwZWNpYWxs eSBvdXRzaWRlIG9mIHByb3RvY29sIGludGVyb3A/DQoNCg0KSeKAmW0gbm90IHN1cmUgaWYgeW91 4oCZcmUgYWdyZWVpbmcgd2l0aCBtZSBvciBpZiB5b3XigJlyZSBmdXJ0aGVyIGp1c3RpZnlpbmcg dGhlIHVzZS4NCg0KV0ddIGp1c3RpZnlpbmcuDQoNClRoZSBzZWN0aW9uIHdl4oCZcmUgdGFsa2lu ZyBhYm91dCByZWFkczoNCg0KMy4yLjEuICBPdXRib3VuZCBhbm5vdW5jZW1lbnRzIChQRS0tPkNF KQ0KDQogICBXaGVuIFBFMSBpcyBtb3ZlZCBmcm9tIEFTNjQ1MTAgdG8gQVM2NDUwMCwgaXQgd2ls bCBiZSBwcm92aXNpb25lZA0KICAgd2l0aCB0aGUgYXBwcm9wcmlhdGUga2V5cyBmb3IgQVM2NDUw MCB0byBhbGxvdyBpdCB0byBmb3J3YXJkLXNpZ24NCiAgIHJvdXRlcyB1c2luZyBBUzY0NTAwLiAg SG93ZXZlciwgdGhlcmUgaXMgY3VycmVudGx5IG5vIGd1aWRhbmNlIGluIHRoZQ0KICAgQkdQU2Vj IHByb3RvY29sIHNwZWNpZmljYXRpb24gb24gd2hldGhlciBvciBub3QgdGhlIGZvcndhcmQtc2ln bmVkDQogICBBU04gdmFsdWUgTVVTVCBtYXRjaCB0aGUgY29uZmlndXJlZCAicmVtb3RlLWFzIiB0 byB2YWxpZGF0ZSBwcm9wZXJseS4NCiAgIFRoYXQgaXMsIGlmIENFMSdzIEJHUCBzZXNzaW9uIGlz IGNvbmZpZ3VyZWQgYXMgInJlbW90ZS1hcyA2NDUxMCIsIHRoZQ0KICAgcHJlc2VuY2Ugb2YgImxv Y2FsLWFzIDY0NTEwIiBvbiBQRTEgd2lsbCBlbnN1cmUgdGhhdCB0aGVyZSBpcyBubyBBU04NCiAg IG1pc21hdGNoIG9uIHRoZSBCR1Agc2Vzc2lvbiBpdHNlbGYsIGJ1dCBpZiBDRTEgcmVjZWl2ZXMg dXBkYXRlcyBmcm9tDQogICBpdHMgcmVtb3RlIG5laWdoYm9yIChQRTEpIGZvcndhcmQtc2lnbmVk IGZyb20gQVM2NDUwMCwgdGhlcmUgaXMgbm8NCiAgIGd1aWRhbmNlIGFzIHRvIHdoZXRoZXIgdGhl IEJHUFNlYyB2YWxpZGF0b3Igb24gQ0UxIHN0aWxsIGNvbnNpZGVyDQogICB0aG9zZSB2YWxpZCBi eSBkZWZhdWx0LiAgUkZDNDI3MSBbUkZDNDI3MV0gc2VjdGlvbiA2LjMgbWVudGlvbnMgdGhpcw0K ICAgbWF0Y2ggYmV0d2VlbiB0aGUgQVNOIG9mIHRoZSBwZWVyIGFuZCB0aGUgQVNfUEFUSCBkYXRh LCBidXQgaXQgaXMNCiAgIGxpc3RlZCBhcyBhbiBvcHRpb25hbCB2YWxpZGF0aW9uLCByYXRoZXIg dGhhbiBhIHJlcXVpcmVtZW50Lg0KICAgQXNzdW1pbmcgdGhhdCB0aGlzIG1pc21hdGNoIHdpbGwg YmUgYWxsb3dlZCBieSB2ZW5kb3IgaW1wbGVtZW50YXRpb25zDQogICBhbmQgdXNpbmcgaXQgYXMg YSBtZWFucyB0byBzb2x2ZSB0aGlzIG1pZ3JhdGlvbiBjYXNlIGlzIGxpa2VseSB0byBiZQ0KICAg UHJvYmxlbWF0aWMuDQoNClNvdW5kcyB0byBtZSB0aGF0IHlvdSB3YW50IEJHUFNlYyB0byBzYXkg dGhhdCB0aGUgdmFsdWVzIE1VU1QgbWF0Y2gsIGlzIHRoYXQgY29ycmVjdD8NCg0KV0ddIE5vLiBJ biB0aGF0IHNlY3Rpb24sIEknbSBzdGlsbCByZXZpZXdpbmcgdGhlIHByb2JsZW0gYW5kIG9wdGlv bnMgdG8gc29sdmUgdGhlIHByb2JsZW0uIFRoZSBrZXkgaXMgaW4gdGhlIGxhc3Qgc2VudGVuY2Ug b2Ygd2hhdCB5b3UgcXVvdGVkIGFib3ZlLg0KSW4gb3RoZXIgd29yZHMsIGluIHRoZW9yeSB5b3Ug bWlnaHQgYmUgYWJsZSB0byBnZXQgYXdheSB3aXRoIHRoZSBmaXJzdCBBUyBpbiB0aGUgQVNfUEFU SCBkZXZpYXRpbmcgZnJvbSB0aGUgY29uZmlndXJlZCByZW1vdGVfQVMgb24gc29tZSBsaWJlcmFs IGltcGxlbWVudGF0aW9ucywgYnV0IGl0J3MgcHJvYmFibHkgbm90IHZhbGlkIHRvIGFzc3VtZSB0 aGF0IGFsbCBpbXBsZW1lbnRhdGlvbnMgd2lsbCBtYWtlIHRoaXMgd29yaywgYmVjYXVzZSB0aGUg c3BlYyBkb2Vzbid0IHByb3ZpZGUgbm9ybWF0aXZlIGd1aWRhbmNlIHNheWluZyB0aGF0IGl0IE1V U1QuDQoNCg0KIDEuICA1LjMgICJXaGlsZSB0aGlzIGlzIG5vdCBwcm9oaWJpdGVkIGJ5IEJHUFNl YyBbSS1ELmlldGYtc2lkci1iZ3BzZWMtcHJvdG9jb2xdLCByb3V0ZXJzIHRoYXQgcmVjZWl2ZSB1 cGRhdGVzIGZyb20gaUJHUCBuZWlnaGJvcnMgTVVTVCBOT1QgcmVqZWN0IHVwZGF0ZXMgd2l0aCBu ZXcgKHZhbGlkKSBCR1BTZWMgYXR0cmlidXRlcy4u4oCdICBEb2VzIHRoaXMgcmVwcmVzZW50IGFu IHVwZGF0ZSB0byBCR1BTZWM/ICBBcmUgeW91IGltcGx5aW5nIHRoYXQgdGhlIGlCR1AgcmVjZWl2 ZXIgc2hvdWxkIGNoZWNrIHRoZSB2YWxpZGl0eSBvZiB0aGUgYXR0cmlidXRlcz8gIEkga25vdyB0 aGF0IGF0IHRoaXMgcG9pbnQgaXQgaXMgYSBsaXR0bGUgd2VpcmQgdG8gdXBkYXRlIGEgZHJhZnQg KG5vdCBhbiBSRkMpLCBidXQgdGhlIHByb2Nlc3Mgc2hvdWxkIHRha2UgY2FyZSBvZiB0aGUgYXBw cm9wcmlhdGUgcmVmZXJlbmNlcy4gW01heWJlIHRoZSB1cGRhdGUgaXMgbm90IG5lZWRlZCBiYXNl ZCBvbiB0aGUgZGlzY3Vzc2lvbiBpbiB0aGUgV0cgdG9kYXkuXQ0KDQpXR10gd2hhdCB0aGlzIGlz IHNheWluZyBpcyB0aGF0IEJHUFNlYyBpcyBjdXJyZW50bHkgc2lsZW50IG9uIHRoaXMsIGFuZCBt YWtpbmcgYW4gdXBkYXRlIHRvIGNsYXJpZnkgd2hhdCB0aGUgYmVoYXZpb3IgbmVlZHMgdG8gYmUu IEFzIHRvIHdoZXRoZXIgdGhlIHVwZGF0ZXMgbmVlZCB0byBiZSB2YWxpZGF0ZWQgaW4gaUJHUCwg SSdtIG5vdCBleHBsaWNpdGx5IHJlcXVpcmluZyB0aGF0LCBhcyBJIHRoaW5rIGl0J3MgcmVhbGx5 IG1vcmUgb2YgYW4gaW1wbGVtZW50YXRpb24gZGV0YWlsLg0KDQpPaywgc28gaXQgaXMgYW4gdXBk YXRlIHRvIEJHUFNlYy4gIFRoaXMgaXMgaW1wb3J0YW50IGJlY2F1c2UgdGhlIGhlYWRlciBzaG91 bGQgc2F5IHNvIGFuZCBJIHdvdWxkIGxpa2UgdG8gc2VlIGEgc2VjdGlvbiB0aGF0IHN1bW1hcml6 ZXMgdGhlIHVwZGF0ZXMuDQpXR10gd2UnbGwgaGF2ZSB0byBzZWUgaG93IHRoaXMgc2V0dGxlcyBv dXQgb25jZSB0aGUgbmV4dCByZXYgb2YgdGhlIEJHUFNlYyBwcm90b2NvbCBkcmFmdCBpcyBkb25l IHRvIGhhcm1vbml6ZSB0ZXh0IGJldHdlZW4gdGhlIHR3byBkb2N1bWVudHMuIEkgdGhpbmsgdGhl IG5vcm1hdGl2ZSB0ZXh0IGlzIHByZXR0eSBzZWxmLWV4cGxhbmF0b3J5IGFib3V0IHdoYXQgaXQn cyB1cGRhdGluZyBpbiB0aGUgYmFzZSBCR1BTZWMgc3BlYywgYmVjYXVzZSBpdCBvbmx5IGV4aXN0 cyBpbiBzZWN0aW9ucyA0IGFuZCA1LCBidXQgaWYgSSBmaW5kIHBsYWNlcyB3aGVyZSBJIHNob3Vs ZCBiZSBtb3JlIGV4cGxpY2l0LCBJIHdpbGwgdHJ5Lg0KDQpBcyBmYXIgYXMgdGhlIGlCR1AgdmFs aWRhdGlvbiwgSSB0aGluayB0aGUgd29yZCDigJx2YWxpZOKAnSBpcyB3aGF0IHdhcyB0aHJvd2lu ZyBtZSBvZmYuICBZb3UgbWVhbiB2YWxpZCBhcyBpbiB3ZWxsIGZvcm1lZCwgZXRjLg0KV0ddIHll cywgSSBjYW4gcHJvYmFibHkgY2xhcmlmeSB0aGF0Lg0KDQpfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0KVGhpcyBFLW1haWwgYW5kIGFueSBvZiBpdHMgYXR0YWNobWVudHMgbWF5IGNv bnRhaW4gVGltZSBXYXJuZXIgQ2FibGUgcHJvcHJpZXRhcnkgaW5mb3JtYXRpb24sIHdoaWNoIGlz IHByaXZpbGVnZWQsIGNvbmZpZGVudGlhbCwgb3Igc3ViamVjdCB0byBjb3B5cmlnaHQgYmVsb25n aW5nIHRvIFRpbWUgV2FybmVyIENhYmxlLiBUaGlzIEUtbWFpbCBpcyBpbnRlbmRlZCBzb2xlbHkg Zm9yIHRoZSB1c2Ugb2YgdGhlIGluZGl2aWR1YWwgb3IgZW50aXR5IHRvIHdoaWNoIGl0IGlzIGFk ZHJlc3NlZC4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCBvZiB0aGlzIEUt bWFpbCwgeW91IGFyZSBoZXJlYnkgbm90aWZpZWQgdGhhdCBhbnkgZGlzc2VtaW5hdGlvbiwgZGlz dHJpYnV0aW9uLCBjb3B5aW5nLCBvciBhY3Rpb24gdGFrZW4gaW4gcmVsYXRpb24gdG8gdGhlIGNv bnRlbnRzIG9mIGFuZCBhdHRhY2htZW50cyB0byB0aGlzIEUtbWFpbCBpcyBzdHJpY3RseSBwcm9o aWJpdGVkIGFuZCBtYXkgYmUgdW5sYXdmdWwuIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgRS1t YWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgaW1tZWRpYXRlbHkgYW5kIHBl cm1hbmVudGx5IGRlbGV0ZSB0aGUgb3JpZ2luYWwgYW5kIGFueSBjb3B5IG9mIHRoaXMgRS1tYWls IGFuZCBhbnkgcHJpbnRvdXQuDQo= --_000_D14C49584CDB2wesleygeorgetwcablecom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx NHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPGRpdj4NCjxkaXY+DQo8 ZGl2Pk1vcmUgaW5saW5lPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTog MTFwdDsiPlRoYW5rcyw8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTFwdDsiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAw LjAwMDFwdDsgZm9udC1zaXplOiAxMXB0OyI+V2VzPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDEx cHQ7Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxzcGFu IGlkPSJPTEtfU1JDX0JPRFlfU0VDVElPTiI+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTpDYWxp YnJpOyBmb250LXNpemU6MTFwdDsgdGV4dC1hbGlnbjpsZWZ0OyBjb2xvcjpibGFjazsgQk9SREVS LUJPVFRPTTogbWVkaXVtIG5vbmU7IEJPUkRFUi1MRUZUOiBtZWRpdW0gbm9uZTsgUEFERElORy1C T1RUT006IDBpbjsgUEFERElORy1MRUZUOiAwaW47IFBBRERJTkctUklHSFQ6IDBpbjsgQk9SREVS LVRPUDogI2I1YzRkZiAxcHQgc29saWQ7IEJPUkRFUi1SSUdIVDogbWVkaXVtIG5vbmU7IFBBRERJ TkctVE9QOiAzcHQiPg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPkZyb206IDwvc3Bh bj4mcXVvdDtBbHZhcm8gUmV0YW5hIChhcmV0YW5hKSZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRv OmFyZXRhbmFAY2lzY28uY29tIj5hcmV0YW5hQGNpc2NvLmNvbTwvYT4mZ3Q7PGJyPg0KPHNwYW4g c3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPkRhdGU6IDwvc3Bhbj5UaHVyc2RheSwgQXByaWwgOSwg MjAxNSBhdCAyOjU3IFBNPGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPlRvOiA8 L3NwYW4+JnF1b3Q7R2VvcmdlLCBXZXMmcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzp3ZXNsZXku Z2VvcmdlQHR3Y2FibGUuY29tIj53ZXNsZXkuZ2VvcmdlQHR3Y2FibGUuY29tPC9hPiZndDssICZx dW90OzxhIGhyZWY9Im1haWx0bzpzaWRyQGlldGYub3JnIj5zaWRyQGlldGYub3JnPC9hPiZxdW90 OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnNpZHJAaWV0Zi5vcmciPnNpZHJAaWV0Zi5vcmc8L2E+Jmd0 Ozxicj4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5DYzogPC9zcGFuPiZxdW90Ozxh IGhyZWY9Im1haWx0bzpkcmFmdC1pZXRmLXNpZHItYXMtbWlncmF0aW9uQHRvb2xzLmlldGYub3Jn Ij5kcmFmdC1pZXRmLXNpZHItYXMtbWlncmF0aW9uQHRvb2xzLmlldGYub3JnPC9hPiZxdW90OyAm bHQ7PGEgaHJlZj0ibWFpbHRvOmRyYWZ0LWlldGYtc2lkci1hcy1taWdyYXRpb25AdG9vbHMuaWV0 Zi5vcmciPmRyYWZ0LWlldGYtc2lkci1hcy1taWdyYXRpb25AdG9vbHMuaWV0Zi5vcmc8L2E+Jmd0 Ozxicj4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5TdWJqZWN0OiA8L3NwYW4+UmU6 IFJldmlldyBvZiBkcmFmdC1pZXRmLXNpZHItYXMtbWlncmF0aW9uPGJyPg0KPC9kaXY+DQo8ZGl2 Pjxicj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9IndvcmQtd3JhcDogYnJlYWstd29yZDsg LXdlYmtpdC1uYnNwLW1vZGU6IHNwYWNlOyAtd2Via2l0LWxpbmUtYnJlYWs6IGFmdGVyLXdoaXRl LXNwYWNlOyBjb2xvcjogcmdiKDAsIDAsIDApOyBmb250LXNpemU6IDE0cHg7IGZvbnQtZmFtaWx5 OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyI+DQo8ZGl2PnJmYzIxMTkgc2F5cywgYWJvdXQgdGhlIGtl eXdvcmRzOiAmcXVvdDtNVVNUIG9ubHkgYmUgdXNlZCB3aGVyZSBpdCBpcyBhY3R1YWxseSByZXF1 aXJlZCBmb3IgaW50ZXJvcGVyYXRpb24gb3IgdG8gbGltaXQgYmVoYXZpb3Igd2hpY2ggaGFzIHBv dGVudGlhbCBmb3IgY2F1c2luZyBoYXJt4oCdLjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxk aXY+V2hpbGUgSSBjb21wbGV0ZWx5IGFncmVlIHRoYXQgdGhlIHRyYW5zaXRpb24gc2hvdWxkbuKA mXQgdGFrZSBmb3JldmVyLCB0aGUgdXNlIHRoYXQgeW914oCZcmUgcHJvcG9zaW5nIGRvZXNu4oCZ dCBoYXZlIGFueXRoaW5nIHRvIGRvIHdpdGggaW50ZXJvcGVyYWJpbGl0eSwgbm9yIHdpbGwgdGFr aW5nIGxvbmdlciB0aGFuIGV4cGVjdGVkL3VzdWFsIGFjdHVhbGx5IGNhdXNlcyBoYXJtIGZyb20g dGhlIHNwZWNpZmljYXRpb24gcG9pbnQgb2Ygdmlldy4NCiAmbmJzcDtZZXMsIHRoZSBvcGVyYXRv ciB3aWxsIGhhdmUgdG8gZGVhbCB3aXRoIGEgY3VtYmVyc29tZSBjb25maWd1cmF0aW9uL2RlcGxv eW1lbnQsIGJ1dCB0aGUga25vYnMgaW4gdGhpcyBjYXNlIGFyZSBzcGVjaWZpZWQgJnF1b3Q7dG8g a2VlcCB0aGUgYWRkaXRpb25hbCBjb21wbGV4aXR5IGR1cmluZyB0aGUgdHJhbnNpdGlvbiBwZXJp b2QgdG8gYSBtaW5pbXVt4oCdLjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+VG8gYWxs IHRoaXMsIGhvdyB3b3VsZCB5b3UgZXZlbiBkZXRlcm1pbmUgaWYgc29tZW9uZSB3YXMgbm90IGFk aGVyaW5nIHRvIHRoZSByZWNvbW1lbmRhdGlvbj8gJm5ic3A7RG8geW91IG1lYXN1cmUgdGhlIHRp bWUgaW4gZGF5cywgd2Vla3MsIG1vbnRocywgeWVhcnM/ICZuYnNwOyBJ4oCZbSBzdXJlIHRoYXQg dGhlIHRyYW5zaXRpb24gdGltZWZyYW1lIGlzIHZlcnkgZGVwZW5kZW50IG9uIHRoZSBuZXR3b3Jr L2RlcGxveW1lbnQvb3BlcmF0aW9ucyBhbmQgcHJvYmFibHkNCiBtYW55IG90aGVyIHRoaW5ncyBJ IGhhdmVu4oCZdCBldmVuIHRob3VnaHQgYWJvdXQuPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9z cGFuPg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+V0ddIHdlbGwsIEknbGwgYmUgaG9uZXN0LCB0 aGUgcGhpbG9zb3BoeSBiZWhpbmQgMjExOSB3b3JkcyBpc24ndCBhIGhpbGwgSSdtIHdpbGxpbmcg dG8gZGllIG9uLiBJZiBpdCBpcyBmb3IgeW91LCB0aGF0J3MgZmluZSBhbmQgSSdsbCBjaGFuZ2Ug aXQsIGJ1dCBJJ3ZlIHJlYWQgcGxlbnR5IG9mIElFVEYgZG9jdW1lbnRzIHRoYXQgYXJlIHByZXR0 eSBsaWJlcmFsIGluIHRoZWlyIGludGVycHJldGF0aW9uIG9mIGhhcm1mdWwgYXMganVzdGlmaWNh dGlvbg0KIGZvciB1c2luZyBub3JtYXRpdmUgd29yZHMg4oCTIGl0IGlzbid0IGxpbWl0ZWQgc2lt cGx5IHRvIHRoZSBwcm90b2NvbCBhbmQgdW5sZXNzIHdlIHN0YXJ0IGV4cGxpY2l0bHkgcHJvaGli aXRpbmcgMjExOSBsYW5ndWFnZSBvdXRzaWRlIG9mIHByb3RvY29sIHNwZWNzLCB5b3UncmUgZ29p bmcgdG8gaGF2ZSB0aGlzIGFyZ3VtZW50IHdpdGggYSBsb3Qgb2YgcGVvcGxlIEkgdGhpbmsuIEFz IGZvciBlbmZvcmNlbWVudCwgdGhpcyBpc24ndCB0aWVkIHRvDQogYW4gZWxhcHNlZCB0aW1lLCBh bmQgSSBkb24ndCBldmVuIHJlYWxseSB1bmRlcnN0YW5kIHdoYXQgZW5mb3JjZW1lbnQgbWVhbnMg aW4gdGhpcyBjb250ZXh0IOKAkyBob3cgZG9lcyBJRVRGIGVuZm9yY2UgYW55dGhpbmcsIGVzcGVj aWFsbHkgb3V0c2lkZSBvZiBwcm90b2NvbCBpbnRlcm9wPyZuYnNwOzwvZGl2Pg0KPHNwYW4gaWQ9 Ik9MS19TUkNfQk9EWV9TRUNUSU9OIj4NCjxkaXYgc3R5bGU9IndvcmQtd3JhcDogYnJlYWstd29y ZDsgLXdlYmtpdC1uYnNwLW1vZGU6IHNwYWNlOyAtd2Via2l0LWxpbmUtYnJlYWs6IGFmdGVyLXdo aXRlLXNwYWNlOyBjb2xvcjogcmdiKDAsIDAsIDApOyBmb250LXNpemU6IDE0cHg7IGZvbnQtZmFt aWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyI+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPHNwYW4gaWQ9 Ik9MS19TUkNfQk9EWV9TRUNUSU9OIj4NCjxkaXYgc3R5bGU9IndvcmQtd3JhcDogYnJlYWstd29y ZDsgLXdlYmtpdC1uYnNwLW1vZGU6IHNwYWNlOyAtd2Via2l0LWxpbmUtYnJlYWs6IGFmdGVyLXdo aXRlLXNwYWNlOyBjb2xvcjogcmdiKDAsIDAsIDApOyBmb250LXNpemU6IDE0cHg7IGZvbnQtZmFt aWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyI+DQo8c3BhbiBpZD0iT0xLX1NSQ19CT0RZX1NFQ1RJ T04iPg0KPGRpdiBzdHlsZT0id29yZC13cmFwOiBicmVhay13b3JkOyAtd2Via2l0LW5ic3AtbW9k ZTogc3BhY2U7IC13ZWJraXQtbGluZS1icmVhazogYWZ0ZXItd2hpdGUtc3BhY2U7IGNvbG9yOiBy Z2IoMCwgMCwgMCk7IGZvbnQtc2l6ZTogMTRweDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMt c2VyaWY7Ij4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8L2Rpdj4NCjwvc3Bhbj48L2Rpdj4NCjwvc3Bh bj4NCjxkaXY+SeKAmW0gbm90IHN1cmUgaWYgeW914oCZcmUgYWdyZWVpbmcgd2l0aCBtZSBvciBp ZiB5b3XigJlyZSBmdXJ0aGVyIGp1c3RpZnlpbmcgdGhlIHVzZS48L2Rpdj4NCjwvZGl2Pg0KPC9z cGFuPg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+V0ddIGp1c3RpZnlpbmcuJm5ic3A7PC9kaXY+ DQo8c3BhbiBpZD0iT0xLX1NSQ19CT0RZX1NFQ1RJT04iPg0KPGRpdj4NCjxkaXYgc3R5bGU9Indv cmQtd3JhcDogYnJlYWstd29yZDsgLXdlYmtpdC1uYnNwLW1vZGU6IHNwYWNlOyAtd2Via2l0LWxp bmUtYnJlYWs6IGFmdGVyLXdoaXRlLXNwYWNlOyBjb2xvcjogcmdiKDAsIDAsIDApOyBmb250LXNp emU6IDE0cHg7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyI+DQo8ZGl2Pjxicj4N CjwvZGl2Pg0KPGRpdj5UaGUgc2VjdGlvbiB3ZeKAmXJlIHRhbGtpbmcgYWJvdXQgcmVhZHM6PC9k aXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+My4yLjEuICZuYnNwO091dGJvdW5k IGFubm91bmNlbWVudHMgKFBFLS0mZ3Q7Q0UpPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRp dj4mbmJzcDsgJm5ic3A7V2hlbiBQRTEgaXMgbW92ZWQgZnJvbSBBUzY0NTEwIHRvIEFTNjQ1MDAs IGl0IHdpbGwgYmUgcHJvdmlzaW9uZWQ8L2Rpdj4NCjxkaXY+Jm5ic3A7ICZuYnNwO3dpdGggdGhl IGFwcHJvcHJpYXRlIGtleXMgZm9yIEFTNjQ1MDAgdG8gYWxsb3cgaXQgdG8gZm9yd2FyZC1zaWdu PC9kaXY+DQo8ZGl2PiZuYnNwOyAmbmJzcDtyb3V0ZXMgdXNpbmcgQVM2NDUwMC4gJm5ic3A7SG93 ZXZlciwgdGhlcmUgaXMgY3VycmVudGx5IG5vIGd1aWRhbmNlIGluIHRoZTwvZGl2Pg0KPGRpdj4m bmJzcDsgJm5ic3A7QkdQU2VjIHByb3RvY29sIHNwZWNpZmljYXRpb24gb24gd2hldGhlciBvciBu b3QgdGhlIGZvcndhcmQtc2lnbmVkPC9kaXY+DQo8ZGl2PiZuYnNwOyAmbmJzcDtBU04gdmFsdWUg TVVTVCBtYXRjaCB0aGUgY29uZmlndXJlZCAmcXVvdDtyZW1vdGUtYXMmcXVvdDsgdG8gdmFsaWRh dGUgcHJvcGVybHkuPC9kaXY+DQo8ZGl2PiZuYnNwOyAmbmJzcDtUaGF0IGlzLCBpZiBDRTEncyBC R1Agc2Vzc2lvbiBpcyBjb25maWd1cmVkIGFzICZxdW90O3JlbW90ZS1hcyA2NDUxMCZxdW90Oywg dGhlPC9kaXY+DQo8ZGl2PiZuYnNwOyAmbmJzcDtwcmVzZW5jZSBvZiAmcXVvdDtsb2NhbC1hcyA2 NDUxMCZxdW90OyBvbiBQRTEgd2lsbCBlbnN1cmUgdGhhdCB0aGVyZSBpcyBubyBBU048L2Rpdj4N CjxkaXY+Jm5ic3A7ICZuYnNwO21pc21hdGNoIG9uIHRoZSBCR1Agc2Vzc2lvbiBpdHNlbGYsIGJ1 dCBpZiBDRTEgcmVjZWl2ZXMgdXBkYXRlcyBmcm9tPC9kaXY+DQo8ZGl2PiZuYnNwOyAmbmJzcDtp dHMgcmVtb3RlIG5laWdoYm9yIChQRTEpIGZvcndhcmQtc2lnbmVkIGZyb20gQVM2NDUwMCwgdGhl cmUgaXMgbm88L2Rpdj4NCjxkaXY+Jm5ic3A7ICZuYnNwO2d1aWRhbmNlIGFzIHRvIHdoZXRoZXIg dGhlIEJHUFNlYyB2YWxpZGF0b3Igb24gQ0UxIHN0aWxsIGNvbnNpZGVyPC9kaXY+DQo8ZGl2PiZu YnNwOyAmbmJzcDt0aG9zZSB2YWxpZCBieSBkZWZhdWx0LiAmbmJzcDtSRkM0MjcxIFtSRkM0Mjcx XSBzZWN0aW9uIDYuMyBtZW50aW9ucyB0aGlzPC9kaXY+DQo8ZGl2PiZuYnNwOyAmbmJzcDttYXRj aCBiZXR3ZWVuIHRoZSBBU04gb2YgdGhlIHBlZXIgYW5kIHRoZSBBU19QQVRIIGRhdGEsIGJ1dCBp dCBpczwvZGl2Pg0KPGRpdj4mbmJzcDsgJm5ic3A7bGlzdGVkIGFzIGFuIG9wdGlvbmFsIHZhbGlk YXRpb24sIHJhdGhlciB0aGFuIGEgcmVxdWlyZW1lbnQuPC9kaXY+DQo8ZGl2PiZuYnNwOyAmbmJz cDtBc3N1bWluZyB0aGF0IHRoaXMgbWlzbWF0Y2ggd2lsbCBiZSBhbGxvd2VkIGJ5IHZlbmRvciBp bXBsZW1lbnRhdGlvbnM8L2Rpdj4NCjxkaXY+Jm5ic3A7ICZuYnNwO2FuZCB1c2luZyBpdCBhcyBh IG1lYW5zIHRvIHNvbHZlIHRoaXMgbWlncmF0aW9uIGNhc2UgaXMgbGlrZWx5IHRvIGJlPC9kaXY+ DQo8ZGl2PiZuYnNwOyAmbmJzcDtQcm9ibGVtYXRpYy48L2Rpdj4NCjwvZGl2Pg0KPGRpdj48YnI+ DQo8L2Rpdj4NCjxkaXY+U291bmRzIHRvIG1lIHRoYXQgeW91IHdhbnQgQkdQU2VjIHRvIHNheSB0 aGF0IHRoZSB2YWx1ZXMgTVVTVCBtYXRjaCwgaXMgdGhhdCBjb3JyZWN0PzwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjwvc3Bhbj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PldHXSBOby4gSW4gdGhh dCBzZWN0aW9uLCBJJ20gc3RpbGwgcmV2aWV3aW5nIHRoZSBwcm9ibGVtIGFuZCBvcHRpb25zIHRv IHNvbHZlIHRoZSBwcm9ibGVtLiBUaGUga2V5IGlzIGluIHRoZSBsYXN0IHNlbnRlbmNlIG9mIHdo YXQgeW91IHF1b3RlZCBhYm92ZS4mbmJzcDs8L2Rpdj4NCjxkaXY+SW4gb3RoZXIgd29yZHMsIGlu IHRoZW9yeSB5b3UgbWlnaHQgYmUgYWJsZSB0byBnZXQgYXdheSB3aXRoIHRoZSBmaXJzdCBBUyBp biB0aGUgQVNfUEFUSCBkZXZpYXRpbmcgZnJvbSB0aGUgY29uZmlndXJlZCByZW1vdGVfQVMgb24g c29tZSBsaWJlcmFsIGltcGxlbWVudGF0aW9ucywgYnV0IGl0J3MgcHJvYmFibHkgbm90IHZhbGlk IHRvIGFzc3VtZSB0aGF0IGFsbCBpbXBsZW1lbnRhdGlvbnMgd2lsbCBtYWtlIHRoaXMgd29yaywg YmVjYXVzZQ0KIHRoZSBzcGVjIGRvZXNuJ3QgcHJvdmlkZSBub3JtYXRpdmUgZ3VpZGFuY2Ugc2F5 aW5nIHRoYXQgaXQgTVVTVC4mbmJzcDs8L2Rpdj4NCjxzcGFuIGlkPSJPTEtfU1JDX0JPRFlfU0VD VElPTiI+DQo8ZGl2IHN0eWxlPSJ3b3JkLXdyYXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1t b2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJyZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6 IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAxNHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fu cy1zZXJpZjsiPg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxzcGFuIGlkPSJPTEtfU1JDX0JPRFlfU0VD VElPTiI+DQo8YmxvY2txdW90ZSBpZD0iTUFDX09VVExPT0tfQVRUUklCVVRJT05fQkxPQ0tRVU9U RSIgc3R5bGU9IkJPUkRFUi1MRUZUOiAjYjVjNGRmIDUgc29saWQ7IFBBRERJTkc6MCAwIDAgNTsg TUFSR0lOOjAgMCAwIDU7Ij4NCjxkaXYgc3R5bGU9IndvcmQtd3JhcDogYnJlYWstd29yZDsgLXdl YmtpdC1uYnNwLW1vZGU6IHNwYWNlOyAtd2Via2l0LWxpbmUtYnJlYWs6IGFmdGVyLXdoaXRlLXNw YWNlOyBjb2xvcjogcmdiKDAsIDAsIDApOyBmb250LXNpemU6IDE0cHg7IGZvbnQtZmFtaWx5OiBD YWxpYnJpLCBzYW5zLXNlcmlmOyI+DQo8c3BhbiBpZD0iT0xLX1NSQ19CT0RZX1NFQ1RJT04iPg0K PGRpdiBzdHlsZT0id29yZC13cmFwOiBicmVhay13b3JkOyAtd2Via2l0LW5ic3AtbW9kZTogc3Bh Y2U7IC13ZWJraXQtbGluZS1icmVhazogYWZ0ZXItd2hpdGUtc3BhY2U7IGNvbG9yOiByZ2IoMCwg MCwgMCk7IGZvbnQtc2l6ZTogMTRweDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7 Ij4NCjxvbD4NCjxsaT48Zm9udCBmYWNlPSJDYWxpYnJpLHNhbnMtc2VyaWYiIHN0eWxlPSJjb2xv cjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgZm9udC1z aXplOiAxNHB4OyI+NS4zICZuYnNwOyZxdW90OzwvZm9udD48c3BhbiBzdHlsZT0iY29sb3I6IHJn YigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTog MTRweDsiPldoaWxlIHRoaXMgaXMgbm90IHByb2hpYml0ZWQgYnkgQkdQU2VjJm5ic3A7PC9zcGFu PjxzcGFuIHN0eWxlPSJjb2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogQ2FsaWJyaSwg c2Fucy1zZXJpZjsgZm9udC1zaXplOiAxNHB4OyI+W0ktRC5pZXRmLXNpZHItYmdwc2VjLXByb3Rv Y29sXSwNCiByb3V0ZXJzIHRoYXQgcmVjZWl2ZSB1cGRhdGVzIGZyb20mbmJzcDs8L3NwYW4+PHNw YW4gc3R5bGU9ImNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5z LXNlcmlmOyBmb250LXNpemU6IDE0cHg7Ij5pQkdQIG5laWdoYm9ycyBNVVNUIE5PVCByZWplY3Qg dXBkYXRlcyB3aXRoIG5ldyAodmFsaWQpIEJHUFNlYyZuYnNwOzwvc3Bhbj48Zm9udCBmYWNlPSJD YWxpYnJpLHNhbnMtc2VyaWYiPmF0dHJpYnV0ZXMuLuKAnSAmbmJzcDtEb2VzIHRoaXMgcmVwcmVz ZW50DQogYW4gdXBkYXRlIHRvIEJHUFNlYz8gJm5ic3A7QXJlIHlvdSBpbXBseWluZyB0aGF0IHRo ZSBpQkdQIHJlY2VpdmVyJm5ic3A7c2hvdWxkIGNoZWNrIHRoZSB2YWxpZGl0eSBvZiB0aGUgYXR0 cmlidXRlcz8gJm5ic3A7SSBrbm93IHRoYXQgYXQgdGhpcyBwb2ludCBpdCBpcyBhIGxpdHRsZSB3 ZWlyZCB0byB1cGRhdGUgYSBkcmFmdCAobm90IGFuIFJGQyksIGJ1dCB0aGUgcHJvY2VzcyZuYnNw O3Nob3VsZCB0YWtlIGNhcmUgb2YgdGhlIGFwcHJvcHJpYXRlIHJlZmVyZW5jZXMuIFtNYXliZQ0K IHRoZSB1cGRhdGUgaXMgbm90IG5lZWRlZCBiYXNlZCBvbiB0aGUgZGlzY3Vzc2lvbiBpbiB0aGUg V0cgdG9kYXkuXTwvZm9udD48L2xpPjwvb2w+DQo8L2Rpdj4NCjwvc3Bhbj4NCjxkaXY+V0ddIHdo YXQgdGhpcyBpcyBzYXlpbmcgaXMgdGhhdCBCR1BTZWMgaXMgY3VycmVudGx5IHNpbGVudCBvbiB0 aGlzLCBhbmQgbWFraW5nIGFuIHVwZGF0ZSB0byBjbGFyaWZ5IHdoYXQgdGhlIGJlaGF2aW9yIG5l ZWRzIHRvIGJlLiBBcyB0byB3aGV0aGVyIHRoZSB1cGRhdGVzIG5lZWQgdG8gYmUgdmFsaWRhdGVk IGluIGlCR1AsIEknbSBub3QgZXhwbGljaXRseSByZXF1aXJpbmcgdGhhdCwgYXMgSSB0aGluayBp dCdzIHJlYWxseSBtb3JlIG9mDQogYW4gaW1wbGVtZW50YXRpb24gZGV0YWlsLjwvZGl2Pg0KPC9k aXY+DQo8L2Jsb2NrcXVvdGU+DQo8L3NwYW4+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5Paywg c28gaXQgaXMgYW4gdXBkYXRlIHRvIEJHUFNlYy4gJm5ic3A7VGhpcyBpcyBpbXBvcnRhbnQgYmVj YXVzZSB0aGUgaGVhZGVyIHNob3VsZCBzYXkgc28gYW5kIEkgd291bGQgbGlrZSB0byBzZWUgYSBz ZWN0aW9uIHRoYXQgc3VtbWFyaXplcyB0aGUgdXBkYXRlcy48L2Rpdj4NCjwvZGl2Pg0KPC9zcGFu Pg0KPGRpdj5XR10gd2UnbGwgaGF2ZSB0byBzZWUgaG93IHRoaXMgc2V0dGxlcyBvdXQgb25jZSB0 aGUgbmV4dCByZXYgb2YgdGhlIEJHUFNlYyBwcm90b2NvbCBkcmFmdCBpcyBkb25lIHRvIGhhcm1v bml6ZSB0ZXh0IGJldHdlZW4gdGhlIHR3byBkb2N1bWVudHMuIEkgdGhpbmsgdGhlIG5vcm1hdGl2 ZSB0ZXh0IGlzIHByZXR0eSBzZWxmLWV4cGxhbmF0b3J5IGFib3V0IHdoYXQgaXQncyB1cGRhdGlu ZyBpbiB0aGUgYmFzZSBCR1BTZWMgc3BlYywgYmVjYXVzZQ0KIGl0IG9ubHkgZXhpc3RzIGluIHNl Y3Rpb25zIDQgYW5kIDUsIGJ1dCBpZiBJIGZpbmQgcGxhY2VzIHdoZXJlIEkgc2hvdWxkIGJlIG1v cmUgZXhwbGljaXQsIEkgd2lsbCB0cnkuPC9kaXY+DQo8c3BhbiBpZD0iT0xLX1NSQ19CT0RZX1NF Q1RJT04iPg0KPGRpdiBzdHlsZT0id29yZC13cmFwOiBicmVhay13b3JkOyAtd2Via2l0LW5ic3At bW9kZTogc3BhY2U7IC13ZWJraXQtbGluZS1icmVhazogYWZ0ZXItd2hpdGUtc3BhY2U7IGNvbG9y OiByZ2IoMCwgMCwgMCk7IGZvbnQtc2l6ZTogMTRweDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNh bnMtc2VyaWY7Ij4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PkFzIGZhciBhcyB0aGUgaUJHUCB2 YWxpZGF0aW9uLCBJIHRoaW5rIHRoZSB3b3JkIOKAnHZhbGlk4oCdIGlzIHdoYXQgd2FzIHRocm93 aW5nIG1lIG9mZi4gJm5ic3A7WW91IG1lYW4gdmFsaWQgYXMgaW4gd2VsbCBmb3JtZWQsIGV0Yy48 L2Rpdj4NCjwvZGl2Pg0KPC9zcGFuPg0KPGRpdj5XR10geWVzLCBJIGNhbiBwcm9iYWJseSBjbGFy aWZ5IHRoYXQuJm5ic3A7PC9kaXY+DQo8YnI+DQo8aHI+DQo8Zm9udCBmYWNlPSJBcmlhbCIgY29s b3I9IkdyYXkiIHNpemU9IjEiPlRoaXMgRS1tYWlsIGFuZCBhbnkgb2YgaXRzIGF0dGFjaG1lbnRz IG1heSBjb250YWluIFRpbWUgV2FybmVyIENhYmxlIHByb3ByaWV0YXJ5IGluZm9ybWF0aW9uLCB3 aGljaCBpcyBwcml2aWxlZ2VkLCBjb25maWRlbnRpYWwsIG9yIHN1YmplY3QgdG8gY29weXJpZ2h0 IGJlbG9uZ2luZyB0byBUaW1lIFdhcm5lciBDYWJsZS4gVGhpcyBFLW1haWwgaXMgaW50ZW5kZWQg c29sZWx5DQogZm9yIHRoZSB1c2Ugb2YgdGhlIGluZGl2aWR1YWwgb3IgZW50aXR5IHRvIHdoaWNo IGl0IGlzIGFkZHJlc3NlZC4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCBv ZiB0aGlzIEUtbWFpbCwgeW91IGFyZSBoZXJlYnkgbm90aWZpZWQgdGhhdCBhbnkgZGlzc2VtaW5h dGlvbiwgZGlzdHJpYnV0aW9uLCBjb3B5aW5nLCBvciBhY3Rpb24gdGFrZW4gaW4gcmVsYXRpb24g dG8gdGhlIGNvbnRlbnRzIG9mIGFuZCBhdHRhY2htZW50cyB0bw0KIHRoaXMgRS1tYWlsIGlzIHN0 cmljdGx5IHByb2hpYml0ZWQgYW5kIG1heSBiZSB1bmxhd2Z1bC4gSWYgeW91IGhhdmUgcmVjZWl2 ZWQgdGhpcyBFLW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBpbW1lZGlh dGVseSBhbmQgcGVybWFuZW50bHkgZGVsZXRlIHRoZSBvcmlnaW5hbCBhbmQgYW55IGNvcHkgb2Yg dGhpcyBFLW1haWwgYW5kIGFueSBwcmludG91dC48YnI+DQo8L2ZvbnQ+DQo8L2JvZHk+DQo8L2h0 bWw+DQo= --_000_D14C49584CDB2wesleygeorgetwcablecom_-- From nobody Tue Apr 14 07:49: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 851AF1ACDAB for ; Tue, 14 Apr 2015 07:49:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.511 X-Spam-Level: X-Spam-Status: No, score=-0.511 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, 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 OJq2jcMqO8Fw for ; Tue, 14 Apr 2015 07:49:24 -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 EB0F31ACD6B for ; Tue, 14 Apr 2015 07:49:08 -0700 (PDT) Received: from nova.tislabs.com (unknown [10.66.1.77]) by walnut.tislabs.com (Postfix) with ESMTP id 41D6828B0041; Tue, 14 Apr 2015 10:49:08 -0400 (EDT) Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1]) by nova.tislabs.com (Postfix) with ESMTP id 8318F1F8035; Tue, 14 Apr 2015 10:49:04 -0400 (EDT) Content-Type: multipart/signed; boundary="Apple-Mail=_4E7501C0-63D9-4E36-B3D6-A8D01E399674"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Sandra Murphy In-Reply-To: <20150401192116.6786D1712A31@minas-ithil.hactrn.net> Date: Tue, 14 Apr 2015 10:49:02 -0400 Message-Id: References: <048e9e0eb7a311408c1cb07d192c8894@mail.mandelberg.org> <551BFCAF.8050309@mandelberg.org> <20150401192116.6786D1712A31@minas-ithil.hactrn.net> To: Rob Austein X-Mailer: Apple Mail (2.1510) Archived-At: Cc: sidr@ietf.org, 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, 14 Apr 2015 14:49:26 -0000 --Apple-Mail=_4E7501C0-63D9-4E36-B3D6-A8D01E399674 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii The wglc for draft-ietf-sidr-rpki-rtr-rfc6810-bis-03 ended just before = IETF92. Then this energetic discussion followed the end of the wglc, = but seems to have substance. Do the authors have a clear picture of the changes needed to the draft = to proceed with a new version? --Sandy On Apr 1, 2015, at 3:21 PM, Rob Austein wrote: > David, I think a simpler way to express the semantics you want is just > to consider the protocol version number to be part of the session > identifier. That way, a version 0 session can never match a version 1 > session, by definition, full stop. >=20 > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr --Apple-Mail=_4E7501C0-63D9-4E36-B3D6-A8D01E399674 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 iQIcBAEBCgAGBQJVLSjfAAoJEHplpQeet0IZE3AP/3e5amHWWdXx/w7ozRpsrocm D0yGzGfqwgLesYfSjhv3/YKWKZTZzj7OrBDq0Vcya6aLTQVsXHcQkjDuL1VbOUNq wpxtCr55XjbZsnmAN/aJNluLZzZ4WSySqaesPeEPhAjDSzseSyBxAv5tyL8IiauK KTFtzvMtKL8zEZFJe317Mlo4CI5TyBg+n+Ve7Apc0xX9uulVv79g+elufghL526s 0KO+6Z4gPwXh5jwqOvwTckQLHB9wGVqqTFrm72fhLI3BDAP+cKWG+HOFPYLv72hT QIU0bp7iFb+9r0YpazNDa2qp7y18RQaqhH3jy0MZvPHYahQU+/+s09bhoIkP8gwd V2IZ/cGNTsZpmDDmZ8M4X9YswOGAsA5fC8v02LnxW5c8TdpdhFQl+rVTL0Cv7cL2 Yabxt65UMLUT2SFE97qARAt262UdwDhUOIO+YCbr0aPtoyFiDHDOGPGU2cvpUloM U3O/Ln9GSwlEeQ6/RVljklXRp90CKPH1m3y7NAug/z1ii2/A67wYZlm1PbK8CDLi 8Abp7JklicKddfeXD3ZSatcSyIgq2O7qfn8yRPv540v3fxtOrwmp6XbPI8Kmi5P3 /TJrWjmvPgEhQLADkGmi8v2q1Q+SX6X7DsWuVCWbeDn29ew8kaWPSdp4hKj3v4q1 okO+8z/wdN3NlYbPlIpI =V5mD -----END PGP SIGNATURE----- --Apple-Mail=_4E7501C0-63D9-4E36-B3D6-A8D01E399674-- From nobody Wed Apr 15 21:37:23 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 EA0271B2F69 for ; Wed, 15 Apr 2015 21:37:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.312 X-Spam-Level: X-Spam-Status: No, score=-2.312 tagged_above=-999 required=5 tests=[BAYES_20=-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 tgE2-C1aMUjF for ; Wed, 15 Apr 2015 21:37:19 -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 7E3661B2B65 for ; Wed, 15 Apr 2015 21:37:19 -0700 (PDT) Received: from socket.bbn.com ([192.1.120.102]:36467) by smtp.bbn.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1YibYE-000AfK-4v for sidr@ietf.org; Thu, 16 Apr 2015 00:37:18 -0400 X-Submitted: to socket.bbn.com (Postfix) with ESMTPSA id E09FE3FEE1 Message-ID: <552F3C79.8030809@bbn.com> Date: Thu, 16 Apr 2015 00:37:13 -0400 From: Richard Hansen User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: sidr@ietf.org References: In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="TMjAX1IL9OnURtG9ILV0bsgcu6NU38sfe" 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, 16 Apr 2015 04:37:22 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --TMjAX1IL9OnURtG9ILV0bsgcu6NU38sfe Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi all, Here are my comments, some of which overlap with what others have said: * The name of the draft says "rfc6810-bis", but the XML tag doesn't have an obsoletes=3D"6810" attribute. And I don't think it should -- Section 7 has a normative reference to RFC6810 when discussing downgrades to version 0, which isn't specified in this document. So perhaps the title and abstract should be worded to make it clear that this is not a replacement for RFC6810, but rather a new version of the protocol specified in RFC6810. (Or maybe this document should be worded as an update to RFC6810?) (Also mentioned in .) * The protocol is mostly query-response lockstep, but there are no timeouts. If the cache is taking unreasonably long to respond to a query, what should the router do? How long is unreasonably long? If timeouts are added, should the router reset its timeout timer for each response PDU (Cache Response, payload, and End of Data), or only after it receives the End of Data PDU? * Should the cache time out the router if the router doesn't send a Query soon after connecting? * Notify/Query race: What is supposed to happen if the router sees a Serial Notify right after it sends a Serial Query or Reset Query? This could happen if the two are sent at the same time -- the messages will cross paths and the router might think that the Serial Notify is an erroneous response to the query, and that the subsequent Cache Response came out of the blue. * The name "Session ID" is misleading. Section 2 clearly defines it, but unless you pay attention to the definition it's easy to assume that "session" refers to the transport session with the peer. I would prefer a different name such as "Cache Instance ID", though that name may be insufficient when you consider the protocol upgrade problem brought up by David in . Maybe something like "Data Series ID"? * In Section 5.1 (fields) under "Session ID", what is the definition of "completely drop the session"? Do you mean send a fatal error PDU, do a transport-layer disconnect, and let the router reconnect (possibly to a more preferred cache)? Or do you mean send a Cache Reset (cache->router) or Reset Query (router->cache) and continue the existing transport session? Or is either reaction acceptable? * What is the definition of "payload PDU", mentioned in Sections 5.3, 5.5, 8.1, 8.2, and 8.3? (I assume it means IPv4 Prefix, IPv6 Prefix, and Router Key, but it should be explicitly stated.) * Suppose an IPv4 Prefix was announced in serial 5 and withdrawn in serial 6, and a router does a Serial Query against serial 4. Is it OK if the cache elides the announce/withdraw pair? MUST it? If it doesn't, it seems like the cache MUST send the payload PDUs in serial number order, and the router MUST process the payload PDUs in serial number order (which implies that the transport MUST provide in-order delivery of the PDUs because the router has no idea which PDUs correspond to which serial number). * Section 5.1 (fields) says that the serial number is the serial number of the cache, but Section 5.3 (Serial Query) talks about serial numbers as if they are properties of a PDU. Perhaps 5.3 should be worded like: The router sends a Serial Query to ask the cache for the announcements and withdrawals that have occurred since the Serial Number in the Serial Query. Section 5.5 (Cache Response) has similarly problematic wording. * The two sentences in 5.3 (Serial Query) paragraph 2 seem to contradict each other in the case where there are no (net?) changes: The first sentence suggests that the cache sends a Cache Response (maybe followed by something?), while the second suggests that it only sends an End of Data (no Cache Response). I think the intention is for the cache to send a Cache Response immediately followed by an End of Data. Is that correct? * I don't think the set of valid responses to a Query (Reset or Serial) is clearly specified. I think the intention is for these to be the only valid responses: - Reset Query: * Cache Response followed by 0 or more payload PDUs followed by End of Data * Error Report - Serial Query: * Cache Response followed by 0 or more payload PDUs followed by End of Data * Error Report * Cache Reset Is this correct? * Is there a particular reason for omitting a payload PDU count field from the Cache Response PDU? If one was present, the router could pre-allocate an appropriate amount of memory to handle the payload PDUs (and perform additional sanity checks). I guess a PDU count field would prevent an implementation from opportunistically sending additional PDUs if there happened to be a serial number bump during the middle of a Cache Response. (Instead, the cache would have to follow the End of Data PDU with a Serial Notify, which is almost as good.) * Section 5.6 (IPv4 Prefix) mentions duplicates, but are redundant entries OK? Examples: - {65536,192.0.2.0/24-26} and {65536,192.0.2.0/26-26} (the latter is redundant) - {65536,192.0.2.0/24-26} and {65536,192.0.2.0/24-25} (the latter is redundant) * The fixed-length SKI field doesn't permit algorithm changes. Note that there has been some discussion about using SHA-256 for the SKI and AKI fields for the RFC6487(bis) profile (I'm guessing that's probably not going to happen, but still...). (Also mentioned in .) * Section 5.11 (Error Report) says that Error Reports are only sent as responses to other PDUs. Why the restriction? This prevents a side from raising a timeout error, and it prevents the cache from raising an internal error if a problem is detected when it's time to send a Serial Notify. * If error reports are only sent as responses to other PDUs, how is it possible for an Error Report to not be associated with the PDU to which it is responding? (Section 5.11 paragraph 4) * For version negotiation, what is supposed to happen if the router starts with a PDU with version > 1? There is an Unsupported Protocol Version error type, but nothing requires that to be sent. * Suppose a router connects and issues a v0 Query. If the cache doesn't support protocol v0, Section 7 says it MUST either downgrade or disconnect. Can it issue an Error Report before disconnecting? I would prefer it if the server MUST issue an Unsupported Protocol Version Error Report before disconnecting. * The second-to-last paragraph of Section 10 talks about deleting data from a cache when it has been unable to refresh from that cache for twice the polling period (by default). Why not have the time to delete equal the Expire Interval as specified in Section 6? Thanks, Richard --TMjAX1IL9OnURtG9ILV0bsgcu6NU38sfe Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlUvPH0ACgkQMs/lq+4xKKLqPQCfV7zBF2+Qfutt5gA0i1fVzq57 nOQAn2GYHoeXIzE4PT5AIK4VdXAejert =RN30 -----END PGP SIGNATURE----- --TMjAX1IL9OnURtG9ILV0bsgcu6NU38sfe-- From nobody Fri Apr 17 12:26: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 DF3091A006B for ; Fri, 17 Apr 2015 12:26:02 -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 tF7k40hxGS7G for ; Fri, 17 Apr 2015 12:26:02 -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 D926B1A0069 for ; Fri, 17 Apr 2015 12:26:01 -0700 (PDT) Received: from nova.tislabs.com (unknown [10.66.1.77]) by walnut.tislabs.com (Postfix) with ESMTP id 3853D28B0042 for ; Fri, 17 Apr 2015 15:26:01 -0400 (EDT) Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1]) by nova.tislabs.com (Postfix) with ESMTP id 23DE61F8035; Fri, 17 Apr 2015 15:26:01 -0400 (EDT) From: Sandra Murphy Content-Type: multipart/signed; boundary="Apple-Mail=_501FB67A-CB6D-495B-8483-016F685C2C27"; protocol="application/pgp-signature"; micalg=pgp-sha512 Date: Fri, 17 Apr 2015 15:26:00 -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 uploaded 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, 17 Apr 2015 19:26:03 -0000 --Apple-Mail=_501FB67A-CB6D-495B-8483-016F685C2C27 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii The minutes from IETF92 have been uploaded. Corrections should be posted to the list. The proceedings cutoff is 11 May. --Sandy --Apple-Mail=_501FB67A-CB6D-495B-8483-016F685C2C27 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 iQIcBAEBCgAGBQJVMV5IAAoJEHplpQeet0IZZQEP/0JJz2ZNeBfQn3PCRM320S8B PV4J0fQ+3hy8WcnZBrhvtJHkOa8Mo88ZZe5shOcwx4QVHeVyrLNYrwa/ASZOeRh8 BANm+E1BPgUBbDMCs3ylJ3rdmfu7ZvN+ADf1EIUYmdavf8DcYBk7rtdZkTuvP/j6 QiCYYg5+3uBAlGelodGt+VL/7oAaqy5bvfZHtl2v5mCFGLBuV9n7EiqMFUQvwF37 x1nSoTsDdyNdFDX8V/KI+QF4N7lg7CB5Uj1KdGnm7NffIdBMwOfBXAnrVYtSSHdA BG0qf54Iawq/S8pIxAPD37dIbgLXCOGrPTG2cRXQ2oYrPh3ixEZrb1iCeJj4sYPz iargd0Js9HpRT1j9SgFnoyOamwptOTQd2ZQfSm3+aejphgOK+sSdu5KVoxwUZV48 6cIn49CwE2DlL8Iiiw+vQTXbD+2yyLE2yohHM5/LPBkHEHpdJbXDcMfROvnVEPK/ TalwK90VKvZrRh7Cf+GjWuksU3L+3NZ9O2JwUcotVpD7d2QEMh3/94vuNOXq9/2e jf77JV5lIXgZosKW/2IFjHNAtQK6tsTtKht2e+1vX8Af/u+CQINaxbkRQEXS+8l3 sBgu1tX4SBUya7jdaZFuiA2y61kLH9kVdraUaRe+xGgQvcWG18rhw2wkuZIOOK+x ZiwAp5z4UloKIuzT1x77 =VN2J -----END PGP SIGNATURE----- --Apple-Mail=_501FB67A-CB6D-495B-8483-016F685C2C27-- From nobody Sun Apr 19 16:27: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 F1C221A0367 for ; Sun, 19 Apr 2015 16:27:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.312 X-Spam-Level: X-Spam-Status: No, score=-2.312 tagged_above=-999 required=5 tests=[BAYES_20=-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 txOs9J_urhq7 for ; Sun, 19 Apr 2015 16:27:19 -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 1564E1A7000 for ; Sun, 19 Apr 2015 16:27:18 -0700 (PDT) Received: from socket.bbn.com ([192.1.120.102]:37090) by smtp.bbn.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1YjycP-000LgC-Dj for sidr@ietf.org; Sun, 19 Apr 2015 19:27:17 -0400 X-Submitted: to socket.bbn.com (Postfix) with ESMTPSA id 23EA24037E Message-ID: <553439D4.7000901@bbn.com> Date: Sun, 19 Apr 2015 19:27:16 -0400 From: Richard Hansen User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: sidr@ietf.org Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: [sidr] feedback request for draft-rhansen-sidr-rfc6487bis-00 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, 19 Apr 2015 23:27:21 -0000 Hi all, At IETF92 I mentioned (see slides at [1]) the two changes that are new to draft-rhansen-sidr-rfc6487bis-00 [2]. I want to bring them up again here for two purposes: to see if there is WG consensus around the changes, and to get a feel for whether the WG is interested in adopting the draft. [1] https://www.ietf.org/proceedings/92/slides/slides-92-sidr-0.pdf [2] https://tools.ietf.org/html/draft-rhansen-sidr-rfc6487bis-00 Both of these changes were originally submitted as errata, but deemed substantive and thus requiring an update or bis RFC. I chose to do a bis. Note that the draft also includes the three approved errata and the update from RFC 7318, so those changes will show up in the diff. There are some unrelated nits that people have suggested to me off-list; I'll submit a new version of the draft with these later. I also think it is worth discussing SHA-256 key identifiers a bit more, but I'd like to postpone that discussion until a conclusion has been reached on these two changes. ====================================================================== Change #1: Make it clear that no other cert extensions are allowed Sections 1 and 8 say that no other certificate extensions are allowed. Section 4.8, however, implies that other extensions are allowed. Change the last sentence of the intro paragraph for Section 4.8 from: A certificate-using system MUST reject the certificate if it encounters a critical extension it does not recognize; however, a non-critical extension MAY be ignored if it is not recognized [RFC5280]. to: A certificate-using system MUST reject the certificate if it encounters an extension not explicitly mentioned in this document. This is in contrast to [RFC5280] which allows non- critical extensions to be ignored. See: http://www.rfc-editor.org/errata_search.php?eid=3168 http://thread.gmane.org/gmane.ietf.sidr/4168 http://thread.gmane.org/gmane.ietf.sidr/5837 ====================================================================== Change #2: Specify CRL AKI format RFC6487 says that the CRL must include the AKI, but it doesn't say which optional fields to include and how to format the keyIdentifier field (if included). Change the start of the 6th paragraph of section 5 from: An RPKI CA MUST include the two extensions, Authority Key Identifier and CRL Number, in every CRL that it issues. to: An RPKI CA MUST include the two extensions, Authority Key Identifier and CRL Number, in every CRL that it issues. The Authority Key Identifier extension MUST follow the same restrictions as in Section 4.8.3 above. See: http://www.rfc-editor.org/errata_search.php?eid=3174 http://thread.gmane.org/gmane.ietf.sidr/4314 Thanks, Richard From nobody Mon Apr 20 04:13:44 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 7813D1B2A80 for ; Mon, 20 Apr 2015 04:13:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.912 X-Spam-Level: X-Spam-Status: No, score=-101.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_WHITELIST=-100] 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 DkBXjA_BlHk0 for ; Mon, 20 Apr 2015 04:13:42 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1900:3001:11::31]) by ietfa.amsl.com (Postfix) with ESMTP id 24F111B2A7C for ; Mon, 20 Apr 2015 04:13:41 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 8FACC180092; Mon, 20 Apr 2015 04:12:48 -0700 (PDT) To: gih@apnic.net, akatlas@gmail.com, db3546@att.com, aretana@cisco.com, morrowc@ops-netman.net, sandy@tislabs.com X-PHP-Originating-Script: 6000:errata_mail_lib.php From: RFC Errata System Message-Id: <20150420111248.8FACC180092@rfc-editor.org> Date: Mon, 20 Apr 2015 04:12:48 -0700 (PDT) Archived-At: Cc: rfc-editor@rfc-editor.org, sidr@ietf.org, sandy@tislabs.com Subject: [sidr] [Technical Errata Reported] RFC6485 (4339) 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, 20 Apr 2015 11:13:43 -0000 The following errata report has been submitted for RFC6485, "The Profile for Algorithms and Key Sizes for Use in the Resource Public Key Infrastructure (RPKI)". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=6485&eid=4339 -------------------------------------- Type: Technical Reported by: Sandra Murphy Section: 2. Original Text ------------- In a certification request, the OID appears in the PKCS #10 signatureAlgorithm field [RFC2986] or in the Certificate Request Message Format (CRMF) POPOSigningKey signature field [RFC4211]. Corrected Text -------------- In a certification request, the OID appears in the PKCS #10 signatureAlgorithm field [RFC2986] or in the Certificate Request Message Format (CRMF) POPOSigningKey algorithmIdentifier field [RFC4211]. Notes ----- This is technically a technical change, as it would technically affect implementation, but I believe in fact it is just a typo. Only a very inexperienced implementor would put the RFC6485 algorithm OID in the signature field of the POPOSigningKey. This problem was noted in a message to the sidr list https://www.ietf.org/mail-archive/web/sidr/current/msg06587.html and supported by another message https://www.ietf.org/mail-archive/web/sidr/current/msg06649.html At noted in the message to the sidr list, RFC4211 says that the POPOSigningKey is: POPOSigningKey ::= SEQUENCE { poposkInput [0] POPOSigningKeyInput OPTIONAL, algorithmIdentifier AlgorithmIdentifier, signature BIT STRING } The OID mentioned in the RFC6485 text is for the algorithm identifier and so should appear in the algorithmIdentifier field, not the signature field. Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC6485 (draft-ietf-sidr-rpki-algs-05) -------------------------------------- Title : The Profile for Algorithms and Key Sizes for Use in the Resource Public Key Infrastructure (RPKI) Publication Date : February 2012 Author(s) : G. Huston Category : PROPOSED STANDARD Source : Secure Inter-Domain Routing Area : Routing Stream : IETF Verifying Party : IESG From nobody Mon Apr 20 10:37: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 5EE941A8A6E for ; Mon, 20 Apr 2015 10:37:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.912 X-Spam-Level: X-Spam-Status: No, score=-106.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_WHITELIST=-100] 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 7RZLp4PtMQwi for ; Mon, 20 Apr 2015 10:37:22 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) by ietfa.amsl.com (Postfix) with ESMTP id 3CC1F1A8A5E for ; Mon, 20 Apr 2015 10:37:22 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id D2FEA180092; Mon, 20 Apr 2015 10:36:28 -0700 (PDT) To: gih@apnic.net, akatlas@gmail.com, db3546@att.com, aretana@cisco.com, morrowc@ops-netman.net, sandy@tislabs.com X-PHP-Originating-Script: 6000:errata_mail_lib.php From: RFC Errata System Message-Id: <20150420173628.D2FEA180092@rfc-editor.org> Date: Mon, 20 Apr 2015 10:36:28 -0700 (PDT) Archived-At: Cc: rfc-editor@rfc-editor.org, sidr@ietf.org Subject: [sidr] [Editorial Errata Reported] RFC6485 (4340) 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, 20 Apr 2015 17:37:23 -0000 The following errata report has been submitted for RFC6485, "The Profile for Algorithms and Key Sizes for Use in the Resource Public Key Infrastructure (RPKI)". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=6485&eid=4340 -------------------------------------- Type: Editorial Reported by: Richard Hansen Section: 1 Original Text ------------- the SIDR Architecture [RFC6480], Corrected Text -------------- the RPKI Architecture [RFC6480], Notes ----- Neither "SIDR" nor "Secure Inter-Domain Routing" is mentioned in RFC6480. RFC6480 is about the design of the RPKI, so "RPKI Architecture" seems like a more appropriate fit. Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC6485 (draft-ietf-sidr-rpki-algs-05) -------------------------------------- Title : The Profile for Algorithms and Key Sizes for Use in the Resource Public Key Infrastructure (RPKI) Publication Date : February 2012 Author(s) : G. Huston Category : PROPOSED STANDARD Source : Secure Inter-Domain Routing Area : Routing Stream : IETF Verifying Party : IESG From nobody Mon Apr 20 23:24:53 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 801041B3628 for ; Mon, 20 Apr 2015 23:24:52 -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 JIJRq6R2Qn3q for ; Mon, 20 Apr 2015 23:24:50 -0700 (PDT) Received: from ia-mailgw.apnic.net (ia-mailgw.apnic.net [IPv6:2001:dd8:a:851::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 3C4A21B360A for ; Mon, 20 Apr 2015 23:24:49 -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:cc: content-transfer-encoding:message-id:references:to:x-mailer:return-path: x-originating-ip; bh=AoCldIYjRNUNQ7/rpZpyRyjKt7Et807ukH09zjdbRS8=; b=oSbNmQ2O6DWrI0hr3JwOhZ/7dgvkhifEWMbTY3aheJ+xdxB4CP9vs+NdDhbZL6YWsN4123U6tAeQd iyt4L92cD4JBLfKhlo27+x6tvuQBSTHrNaYjIZugttEd+S7S7BNbsodWge3ez9rX62h99zFjLEZDcb xZtRgAM5MAOqC6RU= Received: from iamda3.org.apnic.net (unknown [IPv6:2001:dd8:9:2::101:249]) by ia-mailgw.apnic.net (Halon Mail Gateway) with ESMTPS; Tue, 21 Apr 2015 16:24:36 +1000 (AEST) Received: from [192.168.1.67] (203.119.101.249) by iamda3.org.apnic.net (203.119.111.31) with Microsoft SMTP Server (TLS) id 14.1.218.12; Tue, 21 Apr 2015 16:24:46 +1000 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Geoff Huston In-Reply-To: <20150420173628.D2FEA180092@rfc-editor.org> Date: Tue, 21 Apr 2015 08:24:12 +0200 Content-Transfer-Encoding: quoted-printable Message-ID: References: <20150420173628.D2FEA180092@rfc-editor.org> To: RFC Errata System X-Mailer: Apple Mail (2.2098) X-Originating-IP: [203.119.101.249] Archived-At: Cc: db3546@att.com, sidr@ietf.org, morrowc@ops-netman.net, sandy@tislabs.com, rhansen@bbn.com Subject: Re: [sidr] [Editorial Errata Reported] RFC6485 (4340) 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, 21 Apr 2015 06:24:52 -0000 I am trying very hard to understand why or how such a change affects = interoperability of running code that is based on this specification. So far I=E2=80=99ve been = unable to think of an example that makes sense. Could Richard kindly enlighten me as to why this is an = important change?=20 thanks, Geoff > On 20 Apr 2015, at 7:36 pm, RFC Errata System = wrote: >=20 > The following errata report has been submitted for RFC6485, > "The Profile for Algorithms and Key Sizes for Use in the Resource = Public Key Infrastructure (RPKI)". >=20 > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=3D6485&eid=3D4340 >=20 > -------------------------------------- > Type: Editorial > Reported by: Richard Hansen >=20 > Section: 1 >=20 > Original Text > ------------- > the SIDR Architecture > [RFC6480], >=20 >=20 > Corrected Text > -------------- > the RPKI Architecture > [RFC6480], >=20 >=20 > Notes > ----- > Neither "SIDR" nor "Secure Inter-Domain Routing" is mentioned in = RFC6480. RFC6480 is about the design of the RPKI, so "RPKI = Architecture" seems like a more appropriate fit. >=20 > Instructions: > ------------- > This erratum is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party (IESG) > can log in to change the status and edit the report, if necessary.=20 >=20 > -------------------------------------- > RFC6485 (draft-ietf-sidr-rpki-algs-05) > -------------------------------------- > Title : The Profile for Algorithms and Key Sizes for Use = in the Resource Public Key Infrastructure (RPKI) > Publication Date : February 2012 > Author(s) : G. Huston > Category : PROPOSED STANDARD > Source : Secure Inter-Domain Routing > Area : Routing > Stream : IETF > Verifying Party : IESG >=20 From nobody Tue Apr 21 10:24:08 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 519E21B29C1 for ; Tue, 21 Apr 2015 10:24:06 -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 D4Jx4U21J8hC for ; Tue, 21 Apr 2015 10:24:03 -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 171E51A6EF4 for ; Tue, 21 Apr 2015 10:24:00 -0700 (PDT) Received: from socket.bbn.com ([192.1.120.102]:55586) by smtp.bbn.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1Ykbtn-0006MW-77; Tue, 21 Apr 2015 13:23:51 -0400 X-Submitted: to socket.bbn.com (Postfix) with ESMTPSA id A97B240066 Message-ID: <553687A5.50503@bbn.com> Date: Tue, 21 Apr 2015 13:23:49 -0400 From: Richard Hansen User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Geoff Huston References: <20150420173628.D2FEA180092@rfc-editor.org> In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: morrowc@ops-netman.net, sidr@ietf.org, sandy@tislabs.com, db3546@att.com, RFC Errata System Subject: Re: [sidr] [Editorial Errata Reported] RFC6485 (4340) 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, 21 Apr 2015 17:24:06 -0000 On 2015-04-21 02:24, Geoff Huston wrote: > I am trying very hard to understand why or how such a change affects in= teroperability of running > code that is based on this specification. So far I=92ve been unable to = think of an example > that makes sense. I also fail to see how this affects interoperability, which is why I submitted it as an editorial errata instead of a technical errata. This change is about as significant as , except maybe less so because people sometimes cite section numbers while nobody will ever cite this particular line. If the change was technical and substantial, I would have submitted a bis or update draft. > Could Richard kindly enlighten me as to why this is an important change= ? Someone unfamiliar with the SIDR working group might be confused by mention of SIDR. (Just like someone stumbling across a typo might be distracted a bit.) This is just a readability fix, nothing more. I think the more important question is: Is the suggested change correct? -Richard >=20 > thanks, >=20 > Geoff >=20 >=20 >=20 >=20 >> On 20 Apr 2015, at 7:36 pm, RFC Errata System wrote: >> >> The following errata report has been submitted for RFC6485, >> "The Profile for Algorithms and Key Sizes for Use in the Resource Publ= ic Key Infrastructure (RPKI)". >> >> -------------------------------------- >> You may review the report below and at: >> http://www.rfc-editor.org/errata_search.php?rfc=3D6485&eid=3D4340 >> >> -------------------------------------- >> Type: Editorial >> Reported by: Richard Hansen >> >> Section: 1 >> >> Original Text >> ------------- >> the SIDR Architecture >> [RFC6480], >> >> >> Corrected Text >> -------------- >> the RPKI Architecture >> [RFC6480], >> >> >> Notes >> ----- >> Neither "SIDR" nor "Secure Inter-Domain Routing" is mentioned in RFC64= 80. RFC6480 is about the design of the RPKI, so "RPKI Architecture" seem= s like a more appropriate fit. >> >> Instructions: >> ------------- >> This erratum is currently posted as "Reported". If necessary, please >> use "Reply All" to discuss whether it should be verified or >> rejected. When a decision is reached, the verifying party (IESG) >> can log in to change the status and edit the report, if necessary.=20 >> >> -------------------------------------- >> RFC6485 (draft-ietf-sidr-rpki-algs-05) >> -------------------------------------- >> Title : The Profile for Algorithms and Key Sizes for Use= in the Resource Public Key Infrastructure (RPKI) >> Publication Date : February 2012 >> Author(s) : G. Huston >> Category : PROPOSED STANDARD >> Source : Secure Inter-Domain Routing >> Area : Routing >> Stream : IETF >> Verifying Party : IESG >> >=20 > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr >=20 From nobody Tue Apr 21 15:49: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 B8F321B2D82 for ; Tue, 21 Apr 2015 15:49:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.226 X-Spam-Level: X-Spam-Status: No, score=-0.226 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FSL_HELO_BARE_IP_2=1.675, 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 wOhxaFBFbTj4 for ; Tue, 21 Apr 2015 15:49:34 -0700 (PDT) Received: from gateway23.websitewelcome.com (gateway23.websitewelcome.com [192.185.50.164]) (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 477171B2DE5 for ; Tue, 21 Apr 2015 15:49:24 -0700 (PDT) Received: by gateway23.websitewelcome.com (Postfix, from userid 500) id C6005CDE731C; Tue, 21 Apr 2015 17:49:23 -0500 (CDT) Received: from gator3286.hostgator.com (gator3286.hostgator.com [198.57.247.250]) by gateway23.websitewelcome.com (Postfix) with ESMTP id B2C99CDE7300 for ; Tue, 21 Apr 2015 17:49:23 -0500 (CDT) Received: from [173.73.121.66] (port=60500 helo=192.168.1.6) by gator3286.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1Ykgyo-0004FA-8e; Tue, 21 Apr 2015 17:49:22 -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: <553687A5.50503@bbn.com> Date: Tue, 21 Apr 2015 18:49:19 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <8F0E0F5C-5A48-4A43-83F0-5DCB63AF3BAD@ieca.com> References: <20150420173628.D2FEA180092@rfc-editor.org> <553687A5.50503@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: 173.73.121.66 X-Exim-ID: 1Ykgyo-0004FA-8e X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: (192.168.1.6) [173.73.121.66]:60500 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 7 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IzMjg2Lmhvc3RnYXRvci5jb20= Archived-At: Cc: db3546@att.com, sidr wg list , Chris Morrow , Sandra Murphy , RFC Errata System Subject: Re: [sidr] [Editorial Errata Reported] RFC6485 (4340) 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, 21 Apr 2015 22:49:35 -0000 On Apr 21, 2015, at 13:23, Richard Hansen wrote: > On 2015-04-21 02:24, Geoff Huston wrote: >> I am trying very hard to understand why or how such a change affects = interoperability of running >> code that is based on this specification. So far I=92ve been unable = to think of an example >> that makes sense. >=20 > I also fail to see how this affects interoperability, which is why I > submitted it as an editorial errata instead of a technical errata. = This > change is about as significant as > , except maybe > less so because people sometimes cite section numbers while nobody = will > ever cite this particular line. >=20 > If the change was technical and substantial, I would have submitted a > bis or update draft. >=20 >> Could Richard kindly enlighten me as to why this is an important = change? >=20 > Someone unfamiliar with the SIDR working group might be confused by > mention of SIDR. (Just like someone stumbling across a typo might be > distracted a bit.) >=20 > This is just a readability fix, nothing more. I think the more > important question is: Is the suggested change correct? The document to which the words refers to is called: "An Infrastructure to Support Secure Internet Routing" and the short title in the header of the draft is: "RPKI Architecture" but I don=92t think folks are going to be confused because they=92re = going to follow the [RFC6480] to the normative references and then do a = lookup or just do a straight lookup on RFC 6480 so I=92d probably just = leave it. spt > -Richard >=20 >>=20 >> thanks, >>=20 >> Geoff >>=20 >>=20 >>=20 >>=20 >>> On 20 Apr 2015, at 7:36 pm, RFC Errata System = wrote: >>>=20 >>> The following errata report has been submitted for RFC6485, >>> "The Profile for Algorithms and Key Sizes for Use in the Resource = Public Key Infrastructure (RPKI)". >>>=20 >>> -------------------------------------- >>> You may review the report below and at: >>> http://www.rfc-editor.org/errata_search.php?rfc=3D6485&eid=3D4340 >>>=20 >>> -------------------------------------- >>> Type: Editorial >>> Reported by: Richard Hansen >>>=20 >>> Section: 1 >>>=20 >>> Original Text >>> ------------- >>> the SIDR Architecture >>> [RFC6480], >>>=20 >>>=20 >>> Corrected Text >>> -------------- >>> the RPKI Architecture >>> [RFC6480], >>>=20 >>>=20 >>> Notes >>> ----- >>> Neither "SIDR" nor "Secure Inter-Domain Routing" is mentioned in = RFC6480. RFC6480 is about the design of the RPKI, so "RPKI = Architecture" seems like a more appropriate fit. >>>=20 >>> Instructions: >>> ------------- >>> This erratum is currently posted as "Reported". If necessary, please >>> use "Reply All" to discuss whether it should be verified or >>> rejected. When a decision is reached, the verifying party (IESG) >>> can log in to change the status and edit the report, if necessary.=20= >>>=20 >>> -------------------------------------- >>> RFC6485 (draft-ietf-sidr-rpki-algs-05) >>> -------------------------------------- >>> Title : The Profile for Algorithms and Key Sizes for = Use in the Resource Public Key Infrastructure (RPKI) >>> Publication Date : February 2012 >>> Author(s) : G. Huston >>> Category : PROPOSED STANDARD >>> Source : Secure Inter-Domain Routing >>> Area : Routing >>> Stream : IETF >>> Verifying Party : IESG >>>=20 >>=20 >> _______________________________________________ >> sidr mailing list >> sidr@ietf.org >> https://www.ietf.org/mailman/listinfo/sidr >>=20 >=20 > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr From nobody Wed Apr 22 13:05:48 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 C4B8B1B39D5 for ; Wed, 22 Apr 2015 13:05:46 -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 KQzJzGpfgiQo for ; Wed, 22 Apr 2015 13:05:45 -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 477BD1B39D9 for ; Wed, 22 Apr 2015 13:05:41 -0700 (PDT) Received: from socket.bbn.com ([192.1.120.102]:55841) by smtp.bbn.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1Yl0tm-0009cq-TC; Wed, 22 Apr 2015 16:05:30 -0400 X-Submitted: to socket.bbn.com (Postfix) with ESMTPSA id 9737C3FE39 Message-ID: <5537FF0A.9020109@bbn.com> Date: Wed, 22 Apr 2015 16:05:30 -0400 From: Richard Hansen User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: RFC Errata System , gih@apnic.net, akatlas@gmail.com, db3546@att.com, aretana@cisco.com, morrowc@ops-netman.net, sandy@tislabs.com References: <20150420111248.8FACC180092@rfc-editor.org> In-Reply-To: <20150420111248.8FACC180092@rfc-editor.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Cc: sidr@ietf.org Subject: Re: [sidr] [Technical Errata Reported] RFC6485 (4339) 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, 22 Apr 2015 20:05:46 -0000 On 2015-04-20 07:12, RFC Errata System wrote: > This is technically a technical change, as it would technically > affect implementation, but I believe in fact it is just a typo. Only > a very inexperienced implementor would put the RFC6485 algorithm OID > in the signature field of the POPOSigningKey. I agree with the proposed change, and I agree that there's no real risk of an implementation getting it wrong. -Richard From nobody Wed Apr 22 20:14:25 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 2FFBD1B2E3A; Wed, 22 Apr 2015 20:14:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.912 X-Spam-Level: X-Spam-Status: No, score=-101.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_WHITELIST=-100] 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 DYF3aQuDqZQE; Wed, 22 Apr 2015 20:14:22 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1900:3001:11::31]) by ietfa.amsl.com (Postfix) with ESMTP id B36FE1B2E5A; Wed, 22 Apr 2015 20:14:22 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id E9CA8180207; Wed, 22 Apr 2015 20:13:21 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org X-PHP-Originating-Script: 6000:ams_util_lib.php From: rfc-editor@rfc-editor.org Message-Id: <20150423031321.E9CA8180207@rfc-editor.org> Date: Wed, 22 Apr 2015 20:13:21 -0700 (PDT) Archived-At: Cc: drafts-update-ref@iana.org, sidr@ietf.org, rfc-editor@rfc-editor.org Subject: [sidr] BCP 173, RFC 7382 on Template for a Certification Practice Statement (CPS) for the Resource PKI (RPKI) 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, 23 Apr 2015 03:14:24 -0000 A new Request for Comments is now available in online RFC libraries. BCP 173 RFC 7382 Title: Template for a Certification Practice Statement (CPS) for the Resource PKI (RPKI) Author: S. Kent, D. Kong, K. Seo Status: Best Current Practice Stream: IETF Date: April 2015 Mailbox: skent@bbn.com, dkong@bbn.com, kseo@bbn.com Pages: 38 Characters: 82372 See Also: BCP 173 I-D Tag: draft-ietf-sidr-cps-04.txt URL: https://www.rfc-editor.org/info/rfc7382 This document contains a template to be used for creating a Certification Practice Statement (CPS) for an organization that is part of the Resource Public Key Infrastructure (RPKI), e.g., a resource allocation registry or an ISP. This document is a product of the Secure Inter-Domain Routing Working Group of the IETF. BCP: This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/rfc.html Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From nobody Thu Apr 23 12:51: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 5ABEB1B31C0 for ; Thu, 23 Apr 2015 12:51:17 -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 xY7IO4qY6diB for ; Thu, 23 Apr 2015 12:51:15 -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 A5F0E1B3206 for ; Thu, 23 Apr 2015 12:51:01 -0700 (PDT) Received: from socket.bbn.com ([192.1.120.102]:56064) by smtp.bbn.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1YlN9B-0008as-EZ; Thu, 23 Apr 2015 15:50:53 -0400 X-Submitted: to socket.bbn.com (Postfix) with ESMTPSA id 30B123FE6C Message-ID: <55394D15.4040104@bbn.com> Date: Thu, 23 Apr 2015 15:50:45 -0400 From: Richard Hansen User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Sean Turner References: <20150420173628.D2FEA180092@rfc-editor.org> <553687A5.50503@bbn.com> <8F0E0F5C-5A48-4A43-83F0-5DCB63AF3BAD@ieca.com> In-Reply-To: <8F0E0F5C-5A48-4A43-83F0-5DCB63AF3BAD@ieca.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="dG4SO5ebJn0uvfhk3vPIWNoQ941CDjfq7" Archived-At: Cc: db3546@att.com, sidr wg list , Chris Morrow , Sandra Murphy , RFC Errata System Subject: Re: [sidr] [Editorial Errata Reported] RFC6485 (4340) 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, 23 Apr 2015 19:51:17 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --dG4SO5ebJn0uvfhk3vPIWNoQ941CDjfq7 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 2015-04-21 18:49, Sean Turner wrote: > so I'd probably just leave it. Are you saying that the errata process is too heavyweight for a minor editorial typo like this? If so, is there a more appropriate way to report an editorial typo so that it will be fixed in a bis if/when one is ever produced? Thanks, Richard --dG4SO5ebJn0uvfhk3vPIWNoQ941CDjfq7 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlU5TR0ACgkQMs/lq+4xKKKiLQCfdaroF53JWFPPR4Mt4CziAHaw 2D8AoOQP2Twwt/a7ksG1pjI46XZzovR8 =J6U6 -----END PGP SIGNATURE----- --dG4SO5ebJn0uvfhk3vPIWNoQ941CDjfq7-- From nobody Tue Apr 28 11:02:03 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 D53431A897C; Tue, 28 Apr 2015 11:02:00 -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 4b9IRDO9QvkB; Tue, 28 Apr 2015 11:01:59 -0700 (PDT) Received: from sequoia.muada.com (sequoia.muada.com [IPv6:2001:1af8:3100:a006:1::]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 285441A8AB5; Tue, 28 Apr 2015 11:01:56 -0700 (PDT) Received: from global-hq.muada.nl (global-hq.muada.nl [IPv6:2001:470:1f15:8b5:a8f7:f4e5:3e8:856e] (may be forged)) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id t3SI1Xcs063315 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 28 Apr 2015 20:01:35 +0200 (CEST) (envelope-from iljitsch@muada.com) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Iljitsch van Beijnum In-Reply-To: <91148102-DADB-42E8-96A0-E89120642894@tislabs.com> Date: Tue, 28 Apr 2015 20:01:43 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4C184296-F426-40EF-9DB6-3AE87C42B516@tislabs.com> <91148102-DADB-42E8-96A0-E89120642894@tislabs.com> To: Sandra Murphy X-Mailer: Apple Mail (2.2098) Archived-At: Cc: "idr@ietf.org wg" , ggm@apnic.net, sidr@ietf.org Subject: [sidr] Levels of BGPsec/RPKI validation, was: Re: [Idr] 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, 28 Apr 2015 18:02:01 -0000 On 28 Jan 2015, at 23:38, Sandra Murphy wrote: > idr folk, your attention and comments would be appreciated as well. Since you ask... I'm sending this to both idr and sidr as I think this needs broader = input than just sidr. (And it seems I'm no longer on the sidr list.) I read draft-ietf-sidr-bgpsec-protocol-11 and = draft-lepinski-bgpsec-overview-00.txt as well as RFC 6483. I think what's lacking here is any discussion of what happens when = certificates etc expire. Please stay with me for a bit: RFC 6483 talks about RPKI route validation, which suggests that there = are three possible states: valid unknown invalid where valid is preferred over unknown and unknown over invalid, and: "It is a matter of local routing policy as to whether routes with an = "invalid" validity state are considered to be ineligible for further = consideration in a route selection process." Actually, I think the only reasonable approach is to filter out invalids = and prefer valids over unknowns. The important part here is that if = there's a ROA for 193.0.0.0/21 and then someone announces a more = specific like 193.0.7.0/24, that /24 will be "invalid", so even in = partial deployment RPKI users are protected against malicious or = accidental more specifics. But if invalids are accepted, even with a = very low preference, then they still get to divert traffic. So far, so good. But now what if a certificate expires? We know from the web that this is = extremely common. If an expired certificate means the prefixes involved = are marked invalid, this means that filtering invalids becomes very = problematic: not only will prefixes randomly drop off the net as people = forget to generate or install certificates or RPKI caches get stale, but = if things get really bad the resulting lack of connectivity makes it = impossible to correct the problem... So what we need is for expired certificates to make the affected = prefixes revert to unknown rather than invalid. Turns out, that's what = happens today: http://mailman.nanog.org/pipermail/nanog/2014-December/071907.html However, unless this is specified in one of the related documents other = than the three mentioned above, this seems to be an implementation = choice. I think the above issue needs to be discussed in an update of RFC 6483 = or in one of the BGPsec documents. And there's probably a bit more to think about: wouldn't it make sense = to be able to filter on the signature algorithm at some point during the = transition from one algorithm to the next? Or to be able to filter on = "expired" explicitly? A binary valid/invalid isn't enough. = Valid/unknown/invalid is workable, but maybe four or five levels is even = better. (And have a look at how this works in practice: = http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/iproute_bgp/command/irg-c= r-book/bgp-m1.html search for PEX.) From nobody Tue Apr 28 11:27:48 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 90D161A894A; Tue, 28 Apr 2015 11:27:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_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 DNmAOyluWUtr; Tue, 28 Apr 2015 11:27:43 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC75C1A020A; Tue, 28 Apr 2015 11:27:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9206; q=dns/txt; s=iport; t=1430245659; x=1431455259; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=tMyQI4zm+1eYV//wRpXJg1Zb7NSTI0yvjidpLUXWXC0=; b=PQwGS7qT6Zk1m5sKIzlWJd30Mly92kPXkbEDUZFqzdpPqcIpBvgkn9ZX PkPbo4vSH9toShTnPO0NHuMjovIj7ZJt4rYPPkn4T/6f4tiG6UrIA0YBK 997iTABMJ5yKFRXFD/AY5vldH6+6hPNlNTuyOgPUjBbZT0Qu9rRYxYQ6k 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0CiBgCS0D9V/5ldJa1cgkVHU1yFI8EOPIF8AQuGAgKBO0wBAQEBAQGBC4QgAQEBAwEBAQEqQQsFCwIBCBEDAQILGQsnCx0IAgQBDQUIiBsIDcdeAQEBAQEBAQEBAQEBAQEBAQEBAQEBF4s4hFQgDQQHBoMRgRYFhHSKToIjhASEM4IJgSI9gwyCcIZmg1qDUCNggSccFYE8bwGBAySBHQEBAQ X-IronPort-AV: E=Sophos;i="5.11,665,1422921600"; d="scan'208,217";a="412370647" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-9.cisco.com with ESMTP; 28 Apr 2015 18:27:38 +0000 Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id t3SIRaFi004612 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 28 Apr 2015 18:27:36 GMT Received: from xmb-rcd-x02.cisco.com ([169.254.4.111]) by xhc-rcd-x05.cisco.com ([173.37.183.79]) with mapi id 14.03.0195.001; Tue, 28 Apr 2015 13:27:36 -0500 From: "Roque Gagliano (rogaglia)" To: Iljitsch van Beijnum , Sandra Murphy Thread-Topic: [Idr] Levels of BGPsec/RPKI validation, was: Re: [sidr] wglc for draft-ietf-sidr-bgpsec-protocol-11 Thread-Index: AQHQgd2IxBf3Buc8wUqu36ahK1ga251ivkSa Date: Tue, 28 Apr 2015 18:27:35 +0000 Message-ID: References: <4C184296-F426-40EF-9DB6-3AE87C42B516@tislabs.com> <91148102-DADB-42E8-96A0-E89120642894@tislabs.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_EF4348D391D0334996EE9681630C83F02D173BEBxmbrcdx02ciscoc_" MIME-Version: 1.0 Archived-At: Cc: "idr@ietf.org wg" , "ggm@apnic.net" , "sidr@ietf.org" Subject: Re: [sidr] [Idr] Levels of BGPsec/RPKI validation, was: Re: 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, 28 Apr 2015 18:27:45 -0000 --_000_EF4348D391D0334996EE9681630C83F02D173BEBxmbrcdx02ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Iljitsu, It is not an implementation choice, it is by design. If a signed object doe= s not validate (based on whatever reason not just expiration), it is like i= f did not existed. I guess your point is covered. Roque Sent from my HTC ----- Reply message ----- From: "Iljitsch van Beijnum" To: "Sandra Murphy" Cc: "idr@ietf.org wg" , "ggm@apnic.net" , "sid= r@ietf.org" Subject: [Idr] Levels of BGPsec/RPKI validation, was: Re: [sidr] wglc for d= raft-ietf-sidr-bgpsec-protocol-11 Date: Tue, Apr 28, 2015 20:02 On 28 Jan 2015, at 23:38, Sandra Murphy wrote: > idr folk, your attention and comments would be appreciated as well. Since you ask... I'm sending this to both idr and sidr as I think this needs broader input t= han just sidr. (And it seems I'm no longer on the sidr list.) I read draft-ietf-sidr-bgpsec-protocol-11 and draft-lepinski-bgpsec-overvie= w-00.txt as well as RFC 6483. I think what's lacking here is any discussion of what happens when certific= ates etc expire. Please stay with me for a bit: RFC 6483 talks about RPKI route validation, which suggests that there are t= hree possible states: valid unknown invalid where valid is preferred over unknown and unknown over invalid, and: "It is a matter of local routing policy as to whether routes with an "inval= id" validity state are considered to be ineligible for further consideratio= n in a route selection process." Actually, I think the only reasonable approach is to filter out invalids an= d prefer valids over unknowns. The important part here is that if there's a= ROA for 193.0.0.0/21 and then someone announces a more specific like 193.0= .7.0/24, that /24 will be "invalid", so even in partial deployment RPKI use= rs are protected against malicious or accidental more specifics. But if inv= alids are accepted, even with a very low preference, then they still get to= divert traffic. So far, so good. But now what if a certificate expires? We know from the web that this is ex= tremely common. If an expired certificate means the prefixes involved are m= arked invalid, this means that filtering invalids becomes very problematic:= not only will prefixes randomly drop off the net as people forget to gener= ate or install certificates or RPKI caches get stale, but if things get rea= lly bad the resulting lack of connectivity makes it impossible to correct t= he problem... So what we need is for expired certificates to make the affected prefixes r= evert to unknown rather than invalid. Turns out, that's what happens today: http://mailman.nanog.org/pipermail/nanog/2014-December/071907.html However, unless this is specified in one of the related documents other tha= n the three mentioned above, this seems to be an implementation choice. I think the above issue needs to be discussed in an update of RFC 6483 or i= n one of the BGPsec documents. And there's probably a bit more to think about: wouldn't it make sense to b= e able to filter on the signature algorithm at some point during the transi= tion from one algorithm to the next? Or to be able to filter on "expired" e= xplicitly? A binary valid/invalid isn't enough. Valid/unknown/invalid is wo= rkable, but maybe four or five levels is even better. (And have a look at how this works in practice: http://www.cisco.com/c/en/u= s/td/docs/ios-xml/ios/iproute_bgp/command/irg-cr-book/bgp-m1.html search fo= r PEX.) _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr --_000_EF4348D391D0334996EE9681630C83F02D173BEBxmbrcdx02ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Iljitsu,

It is not an implementation choice, it is by design. If a signed objec= t does not validate (based on whatever reason not just expiration), it is l= ike if did not existed. 

I guess your point is covered.

Roque

Sent from my HTC

----- Reply message -----
From: "Iljitsch van Beijnum" <iljitsch@muada.com>
To: "Sandra Murphy" <sandy@tislabs.com>
Cc: "idr@ietf.org wg" <idr@ietf.org>, "ggm@apnic.net&q= uot; <ggm@apnic.net>, "sidr@ietf.org" <sidr@ietf.org>=
Subject: [Idr] Levels of BGPsec/RPKI validation, was: Re: [sidr] wglc for d= raft-ietf-sidr-bgpsec-protocol-11
Date: Tue, Apr 28, 2015 20:02

On 28 Jan 2015, at 23:38, Sandra Murphy <sandy@= tislabs.com> wrote:

> idr folk, your attention and comments would be appreciated as well.
Since you ask...

I'm sending this to both idr and sidr as I think this needs broader input t= han just sidr. (And it seems I'm no longer on the sidr list.)

I read draft-ietf-sidr-bgpsec-protocol-11 and draft-lepinski-bgpsec-overvie= w-00.txt as well as RFC 6483.

I think what's lacking here is any discussion of what happens when certific= ates etc expire. Please stay with me for a bit:

RFC 6483 talks about RPKI route validation, which suggests that there are t= hree possible states:

valid
unknown
invalid

where valid is preferred over unknown and unknown over invalid, and:

"It is a matter of local routing policy as to whether routes with an &= quot;invalid" validity state are considered to be ineligible for furth= er consideration in a route selection process."

Actually, I think the only reasonable approach is to filter out invalids an= d prefer valids over unknowns. The important part here is that if there's a= ROA for 193.0.0.0/21 and then someone announces a more specific like 193.0= .7.0/24, that /24 will be "invalid", so even in partial deployment RPKI users are protected against malicious o= r accidental more specifics. But if invalids are accepted, even with a very= low preference, then they still get to divert traffic.

So far, so good.

But now what if a certificate expires? We know from the web that this is ex= tremely common. If an expired certificate means the prefixes involved are m= arked invalid, this means that filtering invalids becomes very problematic:= not only will prefixes randomly drop off the net as people forget to generate or install certificates or R= PKI caches get stale, but if things get really bad the resulting lack of co= nnectivity makes it impossible to correct the problem...

So what we need is for expired certificates to make the affected prefixes r= evert to unknown rather than invalid. Turns out, that's what happens today:=

http://mailman.nanog.org/pipermail/nanog/2014-December/071907.html<= br>
However, unless this is specified in one of the related documents other tha= n the three mentioned above, this seems to be an implementation choice.

I think the above issue needs to be discussed in an update of RFC 6483 or i= n one of the BGPsec documents.

And there's probably a bit more to think about: wouldn't it make sense to b= e able to filter on the signature algorithm at some point during the transi= tion from one algorithm to the next? Or to be able to filter on "expir= ed" explicitly? A binary valid/invalid isn't enough. Valid/unknown/invalid is workable, but maybe four or five le= vels is even better.

(And have a look at how this works in practice: http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/iproute_bgp/command/irg-cr= -book/bgp-m1.html search for PEX.)

_______________________________________________
Idr mailing list
Idr@ietf.org
https://www.ietf.org/= mailman/listinfo/idr
 --_000_EF4348D391D0334996EE9681630C83F02D173BEBxmbrcdx02ciscoc_-- From nobody Tue Apr 28 12: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 D3EFB1A0250; Tue, 28 Apr 2015 12: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 Aiwj6SVOaPb7; Tue, 28 Apr 2015 12:21:47 -0700 (PDT) Received: from sequoia.muada.com (sequoia.muada.com [IPv6:2001:1af8:3100:a006:1::]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 03DCC1A01BA; Tue, 28 Apr 2015 12:21:46 -0700 (PDT) Received: from [192.168.178.25] (5356AD6E.cm-6-7c.dynamic.ziggo.nl [83.86.173.110]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id t3SJLKr0071532 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 28 Apr 2015 21:21:21 +0200 (CEST) (envelope-from iljitsch@muada.com) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Iljitsch van Beijnum In-Reply-To: Date: Tue, 28 Apr 2015 21:21:31 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4C184296-F426-40EF-9DB6-3AE87C42B516@tislabs.com> <91148102-DADB-42E8-96A0-E89120642894@tislabs.com> To: "Roque Gagliano (rogaglia)" X-Mailer: Apple Mail (2.2098) Archived-At: Cc: "idr@ietf.org wg" , "sidr@ietf.org" , "ggm@apnic.net" , Sandra Murphy Subject: Re: [sidr] [Idr] Levels of BGPsec/RPKI validation, was: Re: 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, 28 Apr 2015 19:21:49 -0000 On 28 Apr 2015, at 20:27, Roque Gagliano (rogaglia) = wrote: > It is not an implementation choice, it is by design. If a signed = object does not validate (based on whatever reason not just expiration), = it is like if did not existed.=20 No... Suppose: ROA: 193.0.0.0/21 up to /21 -> AS 3333 not valid after 20150430 BGP table 29 april: 193.0.0.0/21 3333 -> valid 193.0.0.0/21 4444 -> invalid 193.0.7.0/24 3333 -> invalid 192.0.0.0/16 5555 -> unknown But, two days later, after the ROA expires, do we have this: 193.0.0.0/21 3333 -> unknown 193.0.0.0/21 4444 -> unknown 193.0.7.0/24 3333 -> unknown 192.0.0.0/16 5555 -> unknown or this: 193.0.0.0/21 3333 -> invalid 193.0.0.0/21 4444 -> invalid 193.0.7.0/24 3333 -> invalid 192.0.0.0/16 5555 -> unknown ? You seem to be saying the second, but that wouldn't work, as a simple = mistake would make AS 3333 unreachable. And since you need to connect to = the internet in order to get a new certificate/ROA so you can connect to = the internet... The NANOG link I posted says it's the first case, which would be much = more workable in practice: in that case, if a certificate expires before = a new one is installed, you lose security but not connectivity. As we've = successfully run BGP for 25 years without security, that's bad, but = preferable to being unreachable. Note also that the approach suggested in RFC 6483 and Cisco and Juniper = documentation, where valid > unknown > invalid is not workable because = then can still have traffic flow towards more specific prefixes even = though they're invalid and have a very low local preference. The nice = thing about RPKI is that you can deploy it TODAY if you filter invalids = with the huge upside that you get rid of unauthorized more specifics, = incurring only the very small risk that someone creates ROAs that = conflict with their advertisements. But the real issue is that this isn't written down anywhere as far as I = can tell, so we're dependent on implementers all independently coming up = with the preferred way to handle this. That's never good business for a = standards organization.= From nobody Tue Apr 28 15:21: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 9653A1A8BB2 for ; Tue, 28 Apr 2015 15:21:16 -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=unavailable 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 uB8zyz6AeaiP for ; Tue, 28 Apr 2015 15:21:15 -0700 (PDT) Received: from nm6-vm6.access.bullet.mail.bf1.yahoo.com (nm6-vm6.access.bullet.mail.bf1.yahoo.com [216.109.114.149]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2EE911A8BC2 for ; Tue, 28 Apr 2015 15:21:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1430259673; bh=6I/k2NQ/CL91na9BrT5QS8KXRA3swNO1TMtoeAfqKlI=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From:Subject; b=SMIiaquxFh6hPXtoJgnke+Hcsv09I3bTb0SaiCpM5RtERtycePzIYlDzvPjFWK692DpNxz87kQxzPGI7vBORtH1UcmQKK1nIIQq4tHGuuKjTcnnQm8nqbJxUOAeS9qXK2V2I4rWGoHkajCwrqI0eGoI8/YfYqkYGJw4Yc5sWo6uiIlXvsqPNitoRlyyfx+XKojXmK5ePXMwrrKaKQ6GESepHJIY+Orqhxa9CQ1AFn1Dmq5s3tGHtcUW+BNB8hjiSuyioMy9bRTJG/HraO4tgsbogsR4mfxc06ts+KGbs9HCQnu1zgtg3gDMZiZLuXJd9xuoGgqnVQ7UodaDppvxmhw== Received: from [66.196.81.156] by nm6.access.bullet.mail.bf1.yahoo.com with NNFMP; 28 Apr 2015 22:21:13 -0000 Received: from [98.138.104.99] by tm2.access.bullet.mail.bf1.yahoo.com with NNFMP; 28 Apr 2015 22:21:13 -0000 Received: from [127.0.0.1] by smtp119.sbc.mail.ne1.yahoo.com with NNFMP; 28 Apr 2015 22:21:13 -0000 X-Yahoo-Newman-Id: 682213.69154.bm@smtp119.sbc.mail.ne1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: DWQpn2UVM1lAL_QXtCqVK74Mwm5wL1HTJ9mQAxAFTEt1KTg hTvA_0y5zul1R0ukqK9FnryjFv4klzWST6O2j6hbF31v_wiL8iCDZNbAIj34 67tVo3QrUlD73pelxZMv935fkqlEiiPoeI7iHnWOZX3ljNo5INi__mvtYfVQ j65JzQkPQ9oaLboypRPaEaVfifImQ_jCZ9kNB64m1b9Hf3N0fq6MJhVJpmMa wqcYrMW0lZitA.buzFA76vLY4IPD7bDqNf6LkQc6KduthUtgu.GD5Wx.hLYM u_sxru7VbptDLmXqRh2DpxU6tN1cqxsz383c7lUQHIXfnvn2SjUdRKKtCixv zFuans2FBSWnv7Ou8AJRJCQ0QRWZrVSUSgG4UTs8uZJgRUOxUmN7r2OmiTZu ko8QAKc7CA3LtuKdrC2i8tTYMqiMEc2rCXiht3R6h819QSds.uDqzipdNBB6 MQwcMWYXrfekS6ClaAH_oPmA6oZZEboEThwzmPSn3JyP5CnCkNluogHJCnLN w6gbogsaogizEC.P09yIVoTKlRQ-- 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 4EEE81C6048; Tue, 28 Apr 2015 18:21:12 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Date: Tue, 28 Apr 2015 18:21:12 -0400 From: David Mandelberg To: Iljitsch van Beijnum In-Reply-To: References: <4C184296-F426-40EF-9DB6-3AE87C42B516@tislabs.com> <91148102-DADB-42E8-96A0-E89120642894@tislabs.com> Message-ID: <986c7f50a5300c46ad05afb643be3a1d@mail.mandelberg.org> X-Sender: david@mandelberg.org User-Agent: Roundcube Webmail/0.7.2 Archived-At: Cc: idr@ietf.org, sidr@ietf.org Subject: Re: [sidr] [Idr] Levels of BGPsec/RPKI validation, was: Re: 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, 28 Apr 2015 22:21:16 -0000 On 2015-04-28 15:21, Iljitsch van Beijnum wrote: > On 28 Apr 2015, at 20:27, Roque Gagliano (rogaglia) > wrote: > >> It is not an implementation choice, it is by design. If a signed >> object does not validate (based on whatever reason not just >> expiration), it is like if did not existed. > > No... > > Suppose: > > ROA: 193.0.0.0/21 up to /21 -> AS 3333 not valid after 20150430 In your example, is this the only ROA with a prefix that covers 193.0.0.0/21 or is covered by 193.0.0.0/21? Based on the states below, I'm assuming it is. Please correct me if I'm wrong. > BGP table 29 april: > > 193.0.0.0/21 3333 -> valid > 193.0.0.0/21 4444 -> invalid > 193.0.7.0/24 3333 -> invalid > 192.0.0.0/16 5555 -> unknown This part looks right to me. > But, two days later, after the ROA expires, do we have this: > > 193.0.0.0/21 3333 -> unknown > 193.0.0.0/21 4444 -> unknown > 193.0.7.0/24 3333 -> unknown > 192.0.0.0/16 5555 -> unknown > > or this: > > 193.0.0.0/21 3333 -> invalid > 193.0.0.0/21 4444 -> invalid > 193.0.7.0/24 3333 -> invalid > 192.0.0.0/16 5555 -> unknown > > ? [snip] > But the real issue is that this isn't written down anywhere as far as > I can tell, so we're dependent on implementers all independently > coming up with the preferred way to handle this. That's never good > business for a standards organization. It's the first one (all unknowns). I don't think this is written down explicitly, but if implementations follow RFC6483, I don't think there's any way they can get the second result. From RFC6483, Section 2: It is assumed here that a relying party (RP) has access to a local cache of the complete set of valid ROAs when performing validation of a route. (Valid ROAs are defined as ROAs that are determined to be syntactically correct and are signed using a signature that can be verified using the RPKI, as described in [RFC6482].) The RP needs to match a route to one or more valid candidate ROAs in order to determine a validation outcome, which, in turn, can be used to determine the appropriate local actions to perform on the route. This means that only valid (non-expired) ROAs are used for origin validation. Like Roque said, "if a signed object does not validate (based on whatever reason not just expiration), it is like if did not existed." Then, in the next paragraph: However, routes for address prefixes that are not fully described by any single ROA (i.e., those routes whose address prefixes may be an aggregate of address prefixes described in a valid ROA, or have address prefixes where there is no intersection with any valid ROA), and are not matched by any valid ROA and do not have an address prefix that is a more specific address prefix described in any valid ROA, cannot be reliably classified as "invalid" in a partial deployment scenario. Such routes have a validation outcome of "unknown". Since the {AS 3333, 193.0.0.0/21-21} ROA expired, there's no *valid* ROA that intersects any of {193.0.0.0/21, 193.0.0.0/21, 193.0.7.0/24, 192.0.0.0/16}. (See my assumption above about no other ROAs for these prefixes.) Since none of these four prefixes intersect any prefix in any valid ROA, all four routes you gave are unknown. Based on the two snippets above, I do think it's clear enough for implementations to get it right. However, you asked a good question that other people will probably ask again. Do you think it would be helpful to make this case more explicit somewhere? -- David Eric Mandelberg / dseomn http://david.mandelberg.org/ From nobody Tue Apr 28 15:48: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 8BF7D1A8968; Tue, 28 Apr 2015 15:48:53 -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 Gx8xnP_FpyWv; Tue, 28 Apr 2015 15:48:52 -0700 (PDT) Received: from sequoia.muada.com (sequoia.muada.com [IPv6:2001:1af8:3100:a006:1::]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EFE7D1A882B; Tue, 28 Apr 2015 15:48:51 -0700 (PDT) Received: from [192.168.178.25] (5356AD6E.cm-6-7c.dynamic.ziggo.nl [83.86.173.110]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id t3SMmX0t092774 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 29 Apr 2015 00:48:34 +0200 (CEST) (envelope-from iljitsch@muada.com) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Iljitsch van Beijnum In-Reply-To: <986c7f50a5300c46ad05afb643be3a1d@mail.mandelberg.org> Date: Wed, 29 Apr 2015 00:48:43 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <4C80F9CE-06F9-4FB7-852B-BF1B205738FC@muada.com> References: <4C184296-F426-40EF-9DB6-3AE87C42B516@tislabs.com> <91148102-DADB-42E8-96A0-E89120642894@tislabs.com> <986c7f50a5300c46ad05afb643be3a1d@mail.mandelberg.org> To: David Mandelberg X-Mailer: Apple Mail (2.2098) Archived-At: Cc: idr@ietf.org, sidr@ietf.org Subject: Re: [sidr] [Idr] Levels of BGPsec/RPKI validation, was: Re: 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, 28 Apr 2015 22:48:53 -0000 On 29 Apr 2015, at 0:21, David Mandelberg wrote: > Based on the two snippets above, I do think it's clear enough for = implementations to get it right. Yes, looks like it's indeed in there if you read closely. > However, you asked a good question that other people will probably ask = again. > Do you think it would be helpful to make this case more explicit = somewhere? I think making this more explicit in an update of RFC 6483 would be = helpful. But unless I missed something, the BGPsec drafts don't even talk about = the unknown state: "The validation procedure results in one of two states: 'Valid' and 'Not = Valid'." I don't see any reasonable deployment scenario with only valid and = invalid. I think this needs to be addressed in a BGPsec document.= From nobody Tue Apr 28 15:53: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 1D9261A8949; Tue, 28 Apr 2015 15:53:16 -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 5vx8M6NTF75k; Tue, 28 Apr 2015 15:53:14 -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 F24931A8A48; Tue, 28 Apr 2015 15:53:13 -0700 (PDT) Received: from nova.tislabs.com (unknown [10.66.1.77]) by walnut.tislabs.com (Postfix) with ESMTP id 4AAA128B0042; Tue, 28 Apr 2015 18:53:13 -0400 (EDT) Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1]) by nova.tislabs.com (Postfix) with ESMTP id 2D2011F8035; Tue, 28 Apr 2015 18:53:13 -0400 (EDT) Content-Type: multipart/signed; boundary="Apple-Mail=_F81E6FD1-B1F5-4596-B2C5-00DF6E3AEACD"; 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, 28 Apr 2015 18:53:12 -0400 Message-Id: <30008066-54A7-4545-B947-947669B8EB3E@tislabs.com> References: <4C184296-F426-40EF-9DB6-3AE87C42B516@tislabs.com> <91148102-DADB-42E8-96A0-E89120642894@tislabs.com> To: Iljitsch van Beijnum X-Mailer: Apple Mail (2.1510) Archived-At: Cc: "idr@ietf.org wg" , "sidr@ietf.org" , "ggm@apnic.net" , Sandra Murphy Subject: Re: [sidr] [Idr] Levels of BGPsec/RPKI validation, was: Re: 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, 28 Apr 2015 22:53:16 -0000 --Apple-Mail=_F81E6FD1-B1F5-4596-B2C5-00DF6E3AEACD Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 speaking as regular ol' member: On Apr 28, 2015, at 3:21 PM, Iljitsch van Beijnum = wrote: > On 28 Apr 2015, at 20:27, Roque Gagliano (rogaglia) = wrote: >=20 >> It is not an implementation choice, it is by design. If a signed = object does not validate (based on whatever reason not just expiration), = it is like if did not existed.=20 >=20 > No... >=20 > Suppose: >=20 > ROA: 193.0.0.0/21 up to /21 -> AS 3333 not valid after 20150430 >=20 > BGP table 29 april: >=20 > 193.0.0.0/21 3333 -> valid > 193.0.0.0/21 4444 -> invalid > 193.0.7.0/24 3333 -> invalid > 192.0.0.0/16 5555 -> unknown >=20 > But, two days later, after the ROA expires, do we have this: >=20 > 193.0.0.0/21 3333 -> unknown > 193.0.0.0/21 4444 -> unknown > 193.0.7.0/24 3333 -> unknown > 192.0.0.0/16 5555 -> unknown >=20 > or this: >=20 > 193.0.0.0/21 3333 -> invalid > 193.0.0.0/21 4444 -> invalid > 193.0.7.0/24 3333 -> invalid > 192.0.0.0/16 5555 -> unknown >=20 > ? >=20 > You seem to be saying the second, but that wouldn't work, as a simple = mistake would make AS 3333 unreachable. And since you need to connect to = the internet in order to get a new certificate/ROA so you can connect to = the internet=85 I think Roque was saying that the first outcome would be the case, not = the second: >> If a signed object does not validate (based on whatever reason not = just expiration), it is like if did not existed. If the ROA's EE certificate expires, then the ROA does not validate, it = is like if the ROA did not exist. Which makes the first outcome, not the second. I'm not sure where you see text that implies that the second outcome = would happen. We have left the idea of how fast expiration takes effect up to = implementation. If the implementation immediately trashes an expired EE = cert, then you lose the ROA, and the 3333 route would be "unknown". If = the implementation keeps the EE cert around (until next clock chime? = next sync interval? until it sees a reissue or a CRL?), then you keep = the ROA, and the 3333 route would be "valid". In neither case does the = 3333 route become "invalid". To get a result of "invalid" for 3333 for the /21 requires that you = found a ROA that authorizes some other AS for the /21 and no ROA that = authorizes 3333 for the /21. >=20 > The NANOG link I posted says it's the first case, which would be much = more workable in practice: in that case, if a certificate expires before = a new one is installed, you lose security but not connectivity.=20 Since that's what I think happens and what you think should happen, = we're good! >=20 > Note also that the approach suggested in RFC 6483 and Cisco and = Juniper documentation, where valid > unknown > invalid is not workable = because then can still have traffic flow towards more specific prefixes = even though they're invalid and have a very low local preference. The = nice thing about RPKI is that you can deploy it TODAY if you filter = invalids with the huge upside that you get rid of unauthorized more = specifics, incurring only the very small risk that someone creates ROAs = that conflict with their advertisements. Some people think depref-ing invalids is a safer alternative than = outright dropping them. There's evidence that people are creating ROAs = for their own announcement but forgetting the more specific prefixes = they've sub allocated to customers, where the customer are announcing = from their own AS but not doing ROAs. The ROA for the aggregate makes = the customer's announcement look invalid. Or maybe that's what you mean = by "get rid of unauthorized more specifics" and you think that's a good = outcome. > As we've successfully run BGP for 25 years without security, that's = bad, but preferable to being unreachable. I'm not sure you'd be unreachable. In this day and age, if there's an = aggregate prefix that includes yours, then you got your prefix from the = holder of the aggregate. And in (most?) cases, you have connectivity to = the holder of the aggregate. So you are reachable through them. (Since = IAmNotAnOperator (IANAO), any remark I make about operations should be = checked with someone who is.) Not reachable through your backup = provider, but that's maybe not so bad. =20 If you took their/your more specific prefix and walked and no longer = have connectivity thru the aggregate holder, well, =85 just deserts? = Speculation on my part. >=20 > But the real issue is that this isn't written down anywhere as far as = I can tell, so we're dependent on implementers all independently coming = up with the preferred way to handle this. That's never good business for = a standards organization. I don't agree that it is not written down anywhere. I think the = certificate checking and the BGP route checking are both clear in the = cases you lay out. --Sandy, speaking as regular ol' member --Apple-Mail=_F81E6FD1-B1F5-4596-B2C5-00DF6E3AEACD 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 iQIcBAEBCgAGBQJVQA9YAAoJEHplpQeet0IZfPkP/RZJkH3oE2uoSTxR8MDbKXQX XV88ZesDTCbXtElci6md9+nNQZsfvwgtAE4kb6F/b96xbqj4nTqWafRhb9KPIK+m foRO1zlJfxSP0CjaZwDl6/TDS3ush1ABOyNlwboJbPZjeCaKzYYbDloegOggB0ee H+ezvkMrrnwo7YwT6G0d0R80GMjAwo9UzKpcLedux1Z7RfnTrKX53G5PMwer4/kF eNKh6DEGwuBDoOJ+eyiYvNVp239vwNSQ2Xe5QP5EQlSfwGxTglqnuiFy6nMjq2Ua dFUcIZUTBUw9tjjrByFANtWIe7FNrsRFFteFbazcBqeab2c44b5KwZfiLNHDA7sr 4adpjJqQY9s4VSI1F1tKA3hemr5HvxSKC5MGQpJSF07MoBM1PU1LwH+i22ssxwlC xK+EvzKAxXyOJ74YggPaWNo3d8Q3uM8BAal4R6bY9Qtc3oBbXIWpwbOR9Yyhi4uI YhIygfKQ3cm2wIUu4bW+jMuyR+1cHyxjA5Gu9onyBhjjTy/hdqjN5a1OqLXaORHt tZHXJTMDYssqxtM1FEwBWN+3/wxL7wzXvPGZfibpsFLG7XrG3HkPr4s1cBGwy7W8 MyYdPOFGLTpfLjZmLwx1yIR9bMvYh/JLh0dIWdsdgGRMtTa2W5TzHjA3roEGluOF SWGIHBVmpr8qYMRDroe5 =+rEj -----END PGP SIGNATURE----- --Apple-Mail=_F81E6FD1-B1F5-4596-B2C5-00DF6E3AEACD-- From nobody Tue Apr 28 16:03: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 B538B1A8AE6; Tue, 28 Apr 2015 16:03:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, 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 Ef5sC-QHuBPo; Tue, 28 Apr 2015 16:03:54 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 51E5B1A9030; Tue, 28 Apr 2015 16:03:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1153; q=dns/txt; s=iport; t=1430262234; x=1431471834; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=PZ0oduq9sF/ElHbNnBMn3RYqjBaEkqAb5RE4zGoglOQ=; b=mre+FT0J8sriD+gIUGpktWUZpSGVVsuwI1s9REufhxTSuJUtBd6GiQWm AXF647tavsNwqoFixxoUDETpa85YxbPwzz2YmgRW57AJdAfk9IuWLt1P2 hEwvtTXPKeg1LOdXxUhG6zodVhqBKE7dymkhh8cbmY0DjLVzvMzj0cpYH g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0A6BQDNEEBV/4gNJK1cgwyBNMY3b4dXAoE9OhIBAQEBAQEBgQqEIQEBBHkQAgEGAg4tCzIlAgQBDYgwlXmxGAEBAQEBAQEBAQEBAQEBAQEBAQEBAReLOIUFB4QtAQSGR4seij+VbCNggQVTgTyBcQIeAgQcgQEBAQE X-IronPort-AV: E=Sophos;i="5.11,666,1422921600"; d="scan'208";a="145374057" Received: from alln-core-3.cisco.com ([173.36.13.136]) by alln-iport-3.cisco.com with ESMTP; 28 Apr 2015 23:03:53 +0000 Received: from xhc-rcd-x07.cisco.com (xhc-rcd-x07.cisco.com [173.37.183.81]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id t3SN3rVg021821 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 28 Apr 2015 23:03:53 GMT Received: from xmb-rcd-x02.cisco.com ([169.254.4.111]) by xhc-rcd-x07.cisco.com ([173.37.183.81]) with mapi id 14.03.0195.001; Tue, 28 Apr 2015 18:03:53 -0500 From: "Roque Gagliano (rogaglia)" To: Sandra Murphy , Iljitsch van Beijnum Thread-Topic: [sidr] [Idr] Levels of BGPsec/RPKI validation, was: Re: wglc for draft-ietf-sidr-bgpsec-protocol-11 Thread-Index: AQHQggeYX77EfpWBnE20t13GxYDGaw== Date: Tue, 28 Apr 2015 23:03:52 +0000 Message-ID: References: <4C184296-F426-40EF-9DB6-3AE87C42B516@tislabs.com> <91148102-DADB-42E8-96A0-E89120642894@tislabs.com> <30008066-54A7-4545-B947-947669B8EB3E@tislabs.com> In-Reply-To: <30008066-54A7-4545-B947-947669B8EB3E@tislabs.com> 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.85.4] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "idr@ietf.org wg" , "ggm@apnic.net" , "sidr@ietf.org" Subject: Re: [sidr] [Idr] Levels of BGPsec/RPKI validation, was: Re: 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, 28 Apr 2015 23:03:55 -0000 >I think Roque was saying that the first outcome would be the case, not >the second: You are correct and IMHO we do not need more documents. The normative text is in RFC 6482 section 4: ----------------------- 4. ROA Validation Before a relying party can use a ROA to validate a routing announcement, the relying party MUST first validate the ROA. To validate a ROA, the relying party MUST perform all the validation checks specified in [RFC6488] as well as the following additional ROA-specific validation step. o The IP address delegation extension [RFC3779] is present in the end-entity (EE) certificate (contained within the ROA), and each IP address prefix(es) in the ROA is contained within the set of IP addresses specified by the EE certificate's IP address delegation extension. =8B=8B=8B=8B=8B=8B=8B=8B=8B=8B=8B Informational text is in RFC6907, section 7.2: 7.2. ROA Expiry or Receipt of a CRL Revoking a ROA Particularly, section 7.2.5 to 7.2.8 covers different expiration circumstances. =8B=8B=8B=8B=8B=8B=8B=8B=8B=8B=8B Regards, Roque From nobody Tue Apr 28 20:07: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 CF3591A8720; Tue, 28 Apr 2015 20:07:14 -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 wo3uCgWEa4pj; Tue, 28 Apr 2015 20:07:08 -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 669C71A86F7; Tue, 28 Apr 2015 20:07:06 -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 1YnIL2-0006Qi-Fd; Wed, 29 Apr 2015 03:07:04 +0000 Date: Wed, 29 Apr 2015 12:07:02 +0900 Message-ID: From: Randy Bush To: Roque Gagliano In-Reply-To: References: <4C184296-F426-40EF-9DB6-3AE87C42B516@tislabs.com> <91148102-DADB-42E8-96A0-E89120642894@tislabs.com> <30008066-54A7-4545-B947-947669B8EB3E@tislabs.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: idr wg , sidr wg Subject: Re: [sidr] [Idr] Levels of BGPsec/RPKI validation, was: Re: 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: Wed, 29 Apr 2015 03:07:15 -0000 ca software should warn the user of upcoming expiration of certs, ee certs, roas, crls, drivers' licenses, ... but what is the user gonna do? they're gonna renew. so maybe renew automagically and tell the user? randy From nobody Tue Apr 28 21:58: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 0C9DB1AC40B for ; Tue, 28 Apr 2015 21:58:17 -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 GjUCmibXaq1B for ; Tue, 28 Apr 2015 21:58:15 -0700 (PDT) Received: from ia-mailgw.apnic.net (ia-mailgw.apnic.net [IPv6:2001:dd8:a:851::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 C7AA41AC411 for ; Tue, 28 Apr 2015 21:58:14 -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:cc: content-transfer-encoding:message-id:references:to:x-mailer:return-path: x-originating-ip; bh=JgOOwQe+k5ce77NF9Ne6/zTL2HTqYmqzL4E9knEpjEY=; b=hPRaGbOzpwGUQBmpOy14/vCA/rEYJ5IUOLRq2dlOj43fXY4AbEr9WJrqojr6vrP8Eev+Nv09HlLIP O3zQU9ctQcu0JLJ2FwZuYYpdNcwf+ZJBY5BPaWUDrEymV0G4jxuv7IwMle0qtabDjpPo6mIgolR7Dy ed+k8iWzfcT9Frr0= Received: from NXMDA2.org.apnic.net (unknown [203.119.101.249]) by ia-mailgw.apnic.net (Halon Mail Gateway) with ESMTPS; Wed, 29 Apr 2015 14:58:10 +1000 (AEST) Received: from [192.168.1.47] (203.119.101.249) by NXMDA2.org.apnic.net (203.119.107.21) with Microsoft SMTP Server (TLS) id 14.1.218.12; Wed, 29 Apr 2015 14:59:27 +1000 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Geoff Huston In-Reply-To: Date: Wed, 29 Apr 2015 06:57:57 +0200 Content-Transfer-Encoding: quoted-printable Message-ID: References: <4C184296-F426-40EF-9DB6-3AE87C42B516@tislabs.com> <91148102-DADB-42E8-96A0-E89120642894@tislabs.com> To: Iljitsch van Beijnum X-Mailer: Apple Mail (2.2098) X-Originating-IP: [203.119.101.249] Archived-At: Cc: "idr@ietf.org wg" , sidr@ietf.org, George Michaelson , Sandra Murphy Subject: Re: [sidr] Levels of BGPsec/RPKI validation, was: Re: [Idr] 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: Wed, 29 Apr 2015 04:58:17 -0000 Hi Iljitsch, > But now what if a certificate expires? We know from the web that this = is extremely common. If an expired certificate means the prefixes = involved are marked invalid, this means that filtering invalids becomes = very problematic: not only will prefixes randomly drop off the net as = people forget to generate or install certificates or RPKI caches get = stale, but if things get really bad the resulting lack of connectivity = makes it impossible to correct the problem=E2=80=A6 >=20 > So what we need is for expired certificates to make the affected = prefixes revert to unknown rather than invalid. Turns out, that's what = happens today: >=20 > http://mailman.nanog.org/pipermail/nanog/2014-December/071907.html >=20 yup, becuase an expired certificate is not used for validation of ROAs, = so a route object that is only referred to by a ROA that cannot be = validated is =E2=80=9Cunknown=E2=80=9D in this taxonomy. It is not = =E2=80=9Cinvalid" by virtue of an expired certificate. > However, unless this is specified in one of the related documents = other than the three mentioned above, this seems to be an implementation = choice. to quote RFC6483:=20 "It is assumed here that a relying party (RP) has access to a local cache of the complete set of valid ROAs when performing validation of a route. (Valid ROAs are defined as ROAs that are determined to be syntactically correct and are signed using a signature that can be verified using the RPKI, as described in [RFC6482].) i.e. the route validation process that produces this set of valid, = invalid and unknown outcomes is based on the set of valid ROAs. ROAs = that cannot be validated (i.e. due to expired certificates and other = causes) are not considered in the route validation process described in = RFC6483. =20 >=20 > I think the above issue needs to be discussed in an update of RFC 6483 = or in one of the BGPsec documents. It=E2=80=99s not clear to me that any further text needs to be added to = RFC6483. The underlying process is one based on examination of the route = feed and comparing each received route object to a collection of = attestations and authorities that have been validated by the relying = party as trustable. >=20 > And there's probably a bit more to think about: wouldn't it make sense = to be able to filter on the signature algorithm at some point during the = transition from one algorithm to the next? Or to be able to filter on = "expired" explicitly? A binary valid/invalid isn't enough. = Valid/unknown/invalid is workable, but maybe four or five levels is even = better. >=20 > (And have a look at how this works in practice: = http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/iproute_bgp/command/irg-c= r-book/bgp-m1.html search for PEX.) >=20 regards, Geoff From nobody Wed Apr 29 11:46:40 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 D7BA91A8903; Wed, 29 Apr 2015 11:46:37 -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 6J3DbXKOMgJG; Wed, 29 Apr 2015 11:46:35 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0774.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:774]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B50C81A88BE; Wed, 29 Apr 2015 11:46:34 -0700 (PDT) Received: from CY1PR09MB0793.namprd09.prod.outlook.com (25.163.43.143) by CY1PR09MB0795.namprd09.prod.outlook.com (25.163.43.145) with Microsoft SMTP Server (TLS) id 15.1.148.16; Wed, 29 Apr 2015 18:46:18 +0000 Received: from CY1PR09MB0793.namprd09.prod.outlook.com ([25.163.43.143]) by CY1PR09MB0793.namprd09.prod.outlook.com ([25.163.43.143]) with mapi id 15.01.0148.008; Wed, 29 Apr 2015 18:46:18 +0000 From: "Sriram, Kotikalapudi" To: Iljitsch van Beijnum , David Mandelberg Thread-Topic: [sidr] [Idr] Levels of BGPsec/RPKI validation, was: Re: wglc for draft-ietf-sidr-bgpsec-protocol-11 Thread-Index: AQHQgeES7U91mgLFt0G5eeS9M69BR51izU6AgAAyNACAAAewgIABRAfg Date: Wed, 29 Apr 2015 18:46:18 +0000 Message-ID: References: <4C184296-F426-40EF-9DB6-3AE87C42B516@tislabs.com> <91148102-DADB-42E8-96A0-E89120642894@tislabs.com> <986c7f50a5300c46ad05afb643be3a1d@mail.mandelberg.org> <4C80F9CE-06F9-4FB7-852B-BF1B205738FC@muada.com> In-Reply-To: <4C80F9CE-06F9-4FB7-852B-BF1B205738FC@muada.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: muada.com; dkim=none (message not signed) header.d=none; x-originating-ip: [129.6.140.100] x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR09MB0795; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(3002001); SRVR:CY1PR09MB0795; BCL:0; PCL:0; RULEID:; SRVR:CY1PR09MB0795; x-forefront-prvs: 05610E64EE x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(2656002)(99286002)(62966003)(86362001)(77156002)(230783001)(5001770100001)(54356999)(76576001)(93886004)(5001960100002)(76176999)(50986999)(46102003)(92566002)(33656002)(66066001)(2950100001)(2900100001)(102836002)(40100003)(106116001)(87936001)(5001920100001)(122556002)(74316001); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR09MB0795; H:CY1PR09MB0793.namprd09.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Apr 2015 18:46:18.1300 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR09MB0795 Archived-At: Cc: "idr@ietf.org" , "sidr@ietf.org" Subject: Re: [sidr] [Idr] Levels of BGPsec/RPKI validation, was: Re: 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: Wed, 29 Apr 2015 18:46:38 -0000 Hi Iljitsch, >But unless I missed something, the BGPsec drafts don't even talk about the= unknown state:=20 >"The validation procedure results in one of two states: 'Valid' and 'Not V= alid'." >I don't see any reasonable deployment scenario with only valid and invalid= . I think this needs to be addressed in a BGPsec document. The validation in the BGPsec draft is only about the AS path signatures in = signed updates. It is talking about the validity of the Secure_Path. =20 If all the signatures in a Signature_Block are valid, then the Signature_Bl= ock (and hence Secure_Path) is 'Valid'; Else, the Signature_Block is 'Not Valid'. If there are two Signature_Blocks (e.g. when two different algorithms are i= n use) in an update,=20 then at least one of them must be 'Valid' in order for the Secure_Path to b= e valid. Separately, prefix-origin validation has three possible outcomes as you hav= e observed already. That is the topic of RFC 6483 (Informational) and RFC 6811 (Standards Track= ). Sriram=20 From nobody Wed Apr 29 12:13: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 F03201ACE45; Wed, 29 Apr 2015 12:13:44 -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 rae9V4LHveHa; Wed, 29 Apr 2015 12:13:44 -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 AA0921ACE58; Wed, 29 Apr 2015 12:13:40 -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 1YnXQQ-0000jm-PN; Wed, 29 Apr 2015 19:13:39 +0000 Date: Thu, 30 Apr 2015 04:13:37 +0900 Message-ID: From: Randy Bush To: Kotikalapudi Sriram In-Reply-To: References: <4C184296-F426-40EF-9DB6-3AE87C42B516@tislabs.com> <91148102-DADB-42E8-96A0-E89120642894@tislabs.com> <986c7f50a5300c46ad05afb643be3a1d@mail.mandelberg.org> <4C80F9CE-06F9-4FB7-852B-BF1B205738FC@muada.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: idr wg list , sidr wg list Subject: Re: [sidr] [Idr] Levels of BGPsec/RPKI validation, was: Re: 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: Wed, 29 Apr 2015 19:13:45 -0000 this is deja vu all over again path validation has three possible results o a signed path validated o a signed path could not be validated o the path was unsigned randy From nobody Wed Apr 29 12:46: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 8AFD01A00C8; Wed, 29 Apr 2015 12:46:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.912 X-Spam-Level: X-Spam-Status: No, score=-1.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-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 UNMJasPW9raP; Wed, 29 Apr 2015 12:46:49 -0700 (PDT) Received: from puck.nether.net (puck.nether.net [IPv6:2001:418:3f4::5]) by ietfa.amsl.com (Postfix) with ESMTP id 89C5A1A0033; Wed, 29 Apr 2015 12:46:49 -0700 (PDT) Received: from [165.254.18.222] (unknown [165.254.18.222]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by puck.nether.net (Postfix) with ESMTPSA id E706A540633; Wed, 29 Apr 2015 15:46:47 -0400 (EDT) Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) Content-Type: text/plain; charset=us-ascii From: Jared Mauch In-Reply-To: Date: Wed, 29 Apr 2015 15:46:46 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4C184296-F426-40EF-9DB6-3AE87C42B516@tislabs.com> <91148102-DADB-42E8-96A0-E89120642894@tislabs.com> <986c7f50a5300c46ad05afb643be3a1d@mail.mandelberg.org> <4C80F9CE-06F9-4FB7-852B-BF1B205738FC@muada.com> To: Randy Bush X-Mailer: Apple Mail (2.2098) Archived-At: Cc: idr wg list , Kotikalapudi Sriram , sidr wg list Subject: Re: [sidr] [Idr] Levels of BGPsec/RPKI validation, was: Re: 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: Wed, 29 Apr 2015 19:46:50 -0000 > On Apr 29, 2015, at 3:13 PM, Randy Bush wrote: >=20 > this is deja vu all over again >=20 > path validation has three possible results > o a signed path validated > o a signed path could not be validated > o the path was unsigned I will add one more thing, the path was was signed/validated when it was = checked. Some prefixes are stable for very long periods of time and = therefore the validation may not occur until after the expiration. I generally dislike systems that self-destruct. - Jared= From nobody Wed Apr 29 13: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 7A9DB1A6F5D; Wed, 29 Apr 2015 13:35:46 -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 s222OUedZOkV; Wed, 29 Apr 2015 13:35:43 -0700 (PDT) Received: from sequoia.muada.com (sequoia.muada.com [IPv6:2001:1af8:3100:a006:1::]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4CD5C1A6EF2; Wed, 29 Apr 2015 13:35:42 -0700 (PDT) Received: from global-hq.muada.nl (global-hq.muada.nl [IPv6:2001:470:1f15:8b5:995e:8e8e:2b66:a875] (may be forged)) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id t3TKZQ7w011005 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 29 Apr 2015 22:35:27 +0200 (CEST) (envelope-from iljitsch@muada.com) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Iljitsch van Beijnum In-Reply-To: Date: Wed, 29 Apr 2015 22:35:37 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4C184296-F426-40EF-9DB6-3AE87C42B516@tislabs.com> <91148102-DADB-42E8-96A0-E89120642894@tislabs.com> <986c7f50a5300c46ad05afb643be3a1d@mail.mandelberg.org> <4C80F9CE-06F9-4FB7-852B-BF1B205738FC@muada.com> To: "Sriram, Kotikalapudi" X-Mailer: Apple Mail (2.2098) Archived-At: Cc: "idr@ietf.org" , "sidr@ietf.org" , David Mandelberg Subject: Re: [sidr] [Idr] Levels of BGPsec/RPKI validation, was: Re: 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: Wed, 29 Apr 2015 20:35:46 -0000 On 29 Apr 2015, at 20:46, Sriram, Kotikalapudi = wrote: > The validation in the BGPsec draft is only about the AS path = signatures in signed updates. > It is talking about the validity of the Secure_Path. =20 > If all the signatures in a Signature_Block are valid, then the = Signature_Block (and hence Secure_Path) is 'Valid'; > Else, the Signature_Block is 'Not Valid'. So how does this work when a certificate expires without a new one in = place? Then the signature over a hop in the path and therefore the path and = therefore one or more prefixes are now "Not Valid". This presents us = with two choices: 1. we accept those prefixes in our forwarding tables 2. we don't accept those prefixes in our forwarding tables Obviously 1. can't be the answer, because then BGPsec is pretty much a = NOP. But 2. is not so great either, because now a mistake or delay in = generating and propagating certificates can cause unreachability. So what we need is a third option, that provides better security than 1. = and better reachability than 2. In other words, "couldn't validate because of certificate lifetime" and = "validation failed because of a bad signature or bad certificate chain" = are different enough that we need them to have different effects on the = forwarding tables.= From nobody Wed Apr 29 14:47:34 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 212121A0141; Wed, 29 Apr 2015 14:47:33 -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 kc2WuXSX6kTP; Wed, 29 Apr 2015 14:47:31 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0751.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::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 BF5361A00E6; Wed, 29 Apr 2015 14:47:30 -0700 (PDT) Received: from CY1PR09MB0793.namprd09.prod.outlook.com (25.163.43.143) by CY1PR09MB0795.namprd09.prod.outlook.com (25.163.43.145) with Microsoft SMTP Server (TLS) id 15.1.148.16; Wed, 29 Apr 2015 21:47:08 +0000 Received: from CY1PR09MB0793.namprd09.prod.outlook.com ([25.163.43.143]) by CY1PR09MB0793.namprd09.prod.outlook.com ([25.163.43.143]) with mapi id 15.01.0148.008; Wed, 29 Apr 2015 21:47:09 +0000 From: "Sriram, Kotikalapudi" To: Iljitsch van Beijnum Thread-Topic: [sidr] [Idr] Levels of BGPsec/RPKI validation, was: Re: wglc for draft-ietf-sidr-bgpsec-protocol-11 Thread-Index: AQHQgeES7U91mgLFt0G5eeS9M69BR51izU6AgAAyNACAAAewgIABRAfggAApHYCAABDxMA== Date: Wed, 29 Apr 2015 21:47:08 +0000 Message-ID: References: <4C184296-F426-40EF-9DB6-3AE87C42B516@tislabs.com> <91148102-DADB-42E8-96A0-E89120642894@tislabs.com> <986c7f50a5300c46ad05afb643be3a1d@mail.mandelberg.org> <4C80F9CE-06F9-4FB7-852B-BF1B205738FC@muada.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: muada.com; dkim=none (message not signed) header.d=none; x-originating-ip: [129.6.140.100] x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR09MB0795; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(3002001); SRVR:CY1PR09MB0795; BCL:0; PCL:0; RULEID:; SRVR:CY1PR09MB0795; x-forefront-prvs: 05610E64EE x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(19580395003)(2656002)(99286002)(62966003)(86362001)(230783001)(77156002)(54356999)(76176999)(76576001)(110136002)(93886004)(5001960100002)(46102003)(50986999)(92566002)(33656002)(66066001)(15975445007)(2950100001)(2900100001)(102836002)(106116001)(87936001)(40100003)(5001920100001)(122556002)(74316001); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR09MB0795; H:CY1PR09MB0793.namprd09.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Apr 2015 21:47:08.7400 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR09MB0795 Archived-At: Cc: "idr@ietf.org" , "sidr@ietf.org" , David Mandelberg Subject: Re: [sidr] [Idr] Levels of BGPsec/RPKI validation, was: Re: 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: Wed, 29 Apr 2015 21:47:33 -0000 >So what we need is a third option, that provides better security than 1. a= nd better reachability than 2. >In other words, "couldn't validate because of certificate lifetime"=20 >and "validation failed because of a bad signature or bad certificate chain= "=20 >are different enough that we need them to have different effects on the fo= rwarding tables. My thoughts on this: First: There should be operational BCP recommendation based on the principle of ma= ke-before-break ( in doc like https://tools.ietf.org/html/draft-ietf-sidr-bgpsec-ops-05 ): 1. Certificate should be renewed and pre-published in advance of expiry of = the current certificate;=20 There should be overlapping validity period bridging the two (current and n= ew certs). (See https://tools.ietf.org/html/draft-ietf-sidr-bgpsec-rollover-03 and https://www.ietf.org/proceedings/92/slides/slides-92-sidr-5.pdf )=20 2. The update for the prefix should be re-originated (by origin AS) or re-p= ropagated (by a transit AS). Basically, whoever got a new certificate should do this refresh within the = above overlap period.=20 The above two BCP steps, if followed, will help prevent "couldn't validate = because of certificate lifetime". Second: The operational BCP can also say: Allow a certain grace period before you act on the update that became 'Not = Valid' due to cert expiry. (Earlier Sandy also mentioned this.) =20 Your other scenario "validation failed because of a bad signature or bad ce= rtificate chain" is fine.=20 In this scenario, the update is labeled 'Not Valid' for good reason. Sriram =20 From nobody Wed Apr 29 15:24:59 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 7392C1A885C; Wed, 29 Apr 2015 15:24:57 -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 jPaLQ_GIita8; Wed, 29 Apr 2015 15:24:55 -0700 (PDT) Received: from sequoia.muada.com (sequoia.muada.com [IPv6:2001:1af8:3100:a006:1::]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 735D51A8855; Wed, 29 Apr 2015 15:24:55 -0700 (PDT) Received: from global-hq.muada.nl (global-hq.muada.nl [IPv6:2001:470:1f15:8b5:995e:8e8e:2b66:a875] (may be forged)) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id t3TMOdtq011768 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 30 Apr 2015 00:24:40 +0200 (CEST) (envelope-from iljitsch@muada.com) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Iljitsch van Beijnum In-Reply-To: Date: Thu, 30 Apr 2015 00:24:50 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4C184296-F426-40EF-9DB6-3AE87C42B516@tislabs.com> <91148102-DADB-42E8-96A0-E89120642894@tislabs.com> <986c7f50a5300c46ad05afb643be3a1d@mail.mandelberg.org> <4C80F9CE-06F9-4FB7-852B-BF1B205738FC@muada.com> To: "Sriram, Kotikalapudi" X-Mailer: Apple Mail (2.2098) Archived-At: Cc: "idr@ietf.org" , "sidr@ietf.org" , David Mandelberg Subject: Re: [sidr] [Idr] Levels of BGPsec/RPKI validation, was: Re: 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: Wed, 29 Apr 2015 22:24:57 -0000 On 29 Apr 2015, at 23:47, Sriram, Kotikalapudi = wrote: > The above two BCP steps, if followed, will help prevent "couldn't = validate because of certificate lifetime". Of course, most of the time this would happen correctly. People aren't = stupid. But experience with HTTPS has shown that expired certificates = can't be prevented 100%, and with routing the results are much more = severe than with the web, as the user can't decide to go ahead anyway. = The user wouldn't even know what happened. And fixing the problem may = not be possible because of the unreachability caused by the problem. > Second: > The operational BCP can also say: > Allow a certain grace period before you act on the update that became = 'Not Valid' due to cert expiry. > (Earlier Sandy also mentioned this.) =20 Ok. So what do you propose? That a path with signatures based on expired certificates remains = "valid" for some additional grace period? Then you simply postpone the = problem by that period. Or should operators have a way to differentiate between paths that are = actually invalid and paths that are merely affected by expired = certificates? In that case we are saying the same thing. It might even be useful to have valid / expired-but-otherwise-valid / = unknown / invalid rather than valid / unknown / invalid. Or maybe = valid-algo1 / valid-algo2 / expired-but-otherwise-valid / unknown / = invalid, so I can prefer paths protected with the strongest hashing = algorithm over paths protected with a weaker algorithm and those over = paths protected with expired certificates and those over paths not = protected by BGPsec. (IMO invalid paths should not be allowed at all.) Iljitsch= From nobody Wed Apr 29 16:18: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 94AF81A8772; Wed, 29 Apr 2015 16:18:46 -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 HmZoQBCFZ4KG; Wed, 29 Apr 2015 16:18:45 -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 D4C621A873C; Wed, 29 Apr 2015 16:18:44 -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 1YnbFY-0001PA-DO; Wed, 29 Apr 2015 23:18:40 +0000 Date: Thu, 30 Apr 2015 08:18:38 +0900 Message-ID: From: Randy Bush To: "Sriram, Kotikalapudi" In-Reply-To: References: <4C184296-F426-40EF-9DB6-3AE87C42B516@tislabs.com> <91148102-DADB-42E8-96A0-E89120642894@tislabs.com> <986c7f50a5300c46ad05afb643be3a1d@mail.mandelberg.org> <4C80F9CE-06F9-4FB7-852B-BF1B205738FC@muada.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: David Mandelberg , "idr@ietf.org" , Iljitsch van Beijnum , "sidr@ietf.org" Subject: Re: [sidr] [Idr] Levels of BGPsec/RPKI validation, was: Re: 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: Wed, 29 Apr 2015 23:18:46 -0000 > First: > There should be operational BCP recommendation based on the principle of make-before-break > ( in doc like https://tools.ietf.org/html/draft-ietf-sidr-bgpsec-ops-05 ): > 1. Certificate should be renewed and pre-published in advance of expiry of the current certificate; > There should be overlapping validity period bridging the two (current and new certs). > (See https://tools.ietf.org/html/draft-ietf-sidr-bgpsec-rollover-03 and > https://www.ietf.org/proceedings/92/slides/slides-92-sidr-5.pdf ) > 2. The update for the prefix should be re-originated (by origin AS) or re-propagated (by a transit AS). > Basically, whoever got a new certificate should do this refresh within the above overlap period. > > The above two BCP steps, if followed, will help prevent "couldn't validate because of certificate lifetime". > > Second: > The operational BCP can also say: > Allow a certain grace period before you act on the update that became 'Not Valid' due to cert expiry. > (Earlier Sandy also mentioned this.) > > Your other scenario "validation failed because of a bad signature or bad certificate chain" is fine. > In this scenario, the update is labeled 'Not Valid' for good reason. From: Randy Bush Subject: Re: [sidr] [Idr] Levels of BGPsec/RPKI validation, was: Re: wglc for draft-ietf-sidr-bgpsec-protocol-11 To: Roque Gagliano Cc: idr wg , sidr wg Date: Wed, 29 Apr 2015 12:07:02 +0900 ca software should warn the user of upcoming expiration of certs, ee certs, roas, crls, drivers' licenses, ... but what is the user gonna do? they're gonna renew. so maybe renew automagically and tell the user? randy From nobody Thu Apr 30 02:43:10 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 D43EF1ACD8B; Thu, 30 Apr 2015 02:43:08 -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 YIzt6cmYK2nw; Thu, 30 Apr 2015 02:43:05 -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 7DC5A1A90B0; Thu, 30 Apr 2015 02:43:05 -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 1Ynkzm-0004Cb-4X; Thu, 30 Apr 2015 11:43:03 +0200 Received: from sslvpn.ipv6.ripe.net ([2001:67c:2e8:9::c100:14e6] helo=[IPv6:2001:67c:2e8:5009::151]) by titi.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1Ynkzl-0005bH-Vp; Thu, 30 Apr 2015 11:43:02 +0200 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) Content-Type: text/plain; charset=us-ascii From: Tim Bruijnzeels In-Reply-To: Date: Thu, 30 Apr 2015 11:43:01 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <8271CC14-248D-4F65-852E-6436E8DBC935@ripe.net> References: <4C184296-F426-40EF-9DB6-3AE87C42B516@tislabs.com> <91148102-DADB-42E8-96A0-E89120642894@tislabs.com> <986c7f50a5300c46ad05afb643be3a1d@mail.mandelberg.org> <4C80F9CE-06F9-4FB7-852B-BF1B205738FC@muada.com> To: Randy Bush X-Mailer: Apple Mail (2.2098) 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: 784d7acfe6559f2a0b602ec6519a0719a20cc706ea76f97e44c3a294f72fb301 Archived-At: Cc: "sidr@ietf.org" , "idr@ietf.org" , Iljitsch van Beijnum , "Sriram, Kotikalapudi" , David Mandelberg Subject: Re: [sidr] [Idr] Levels of BGPsec/RPKI validation, was: Re: 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: Thu, 30 Apr 2015 09:43:09 -0000 Hi, > On 30 Apr 2015, at 01:18, Randy Bush wrote: >=20 >> First: >> There should be operational BCP recommendation based on the principle = of make-before-break >> ( in doc like = https://tools.ietf.org/html/draft-ietf-sidr-bgpsec-ops-05 ): >> 1. Certificate should be renewed and pre-published in advance of = expiry of the current certificate;=20 >> There should be overlapping validity period bridging the two (current = and new certs). >> (See https://tools.ietf.org/html/draft-ietf-sidr-bgpsec-rollover-03 = and >> https://www.ietf.org/proceedings/92/slides/slides-92-sidr-5.pdf )=20 >> 2. The update for the prefix should be re-originated (by origin AS) = or re-propagated (by a transit AS). >> Basically, whoever got a new certificate should do this refresh = within the above overlap period.=20 >>=20 >> The above two BCP steps, if followed, will help prevent "couldn't = validate because of certificate lifetime". >>=20 >> Second: >> The operational BCP can also say: >> Allow a certain grace period before you act on the update that became = 'Not Valid' due to cert expiry. >> (Earlier Sandy also mentioned this.) =20 >>=20 >> Your other scenario "validation failed because of a bad signature or = bad certificate chain" is fine.=20 >> In this scenario, the update is labeled 'Not Valid' for good reason. >=20 >=20 > From: Randy Bush > Subject: Re: [sidr] [Idr] Levels of BGPsec/RPKI validation, was: Re: = wglc for draft-ietf-sidr-bgpsec-protocol-11 > To: Roque Gagliano > Cc: idr wg , sidr wg > Date: Wed, 29 Apr 2015 12:07:02 +0900 >=20 > ca software should warn the user of upcoming expiration of certs, ee > certs, roas, crls, drivers' licenses, ... >=20 > but what is the user gonna do? they're gonna renew. so maybe renew > automagically and tell the user? For the record in the RIPE NCC software we automagically re-issue CA = certificates to members 6 months before they expire (and log errors in = case of problems, so we have time to respond). Our system currently only = supports non-hosted setups where a member runs their own remote CA in = our pilot environment, but there too we pro-actively re-issue.. we don't = tell the CA because in the provisioning protocol model the child CA can = contact us, but we can't contact them. We do tell them about the new = certificate when the CA queries, as they do regularly. We believe that = this is safe to do. The new certificate is equivalent in every way to = the last requested and issued certificate except that the validity time = is longer, so we don't see any scenario where the child would not agree = to this - i.e. we can be pro-active. For hosted member CAs we also re-issue ROAs 6 months before the expire, = and we re-issue MFTs 16 hours before their 'next update time' and 6 days = and 16 hours before their EE certificate expiration. >=20 > randy >=20 > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr From nobody Thu Apr 30 10:48: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 149531A889F; Thu, 30 Apr 2015 10:48:26 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, NORMAL_HTTP_TO_IP=0.001, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.886, RAZOR2_CHECK=0.922, 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 hZnGzwQPq7s8; Thu, 30 Apr 2015 10:48:23 -0700 (PDT) Received: from mail-ob0-x22e.google.com (mail-ob0-x22e.google.com [IPv6:2607:f8b0:4003:c01::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 990931A8A51; Thu, 30 Apr 2015 10:48:19 -0700 (PDT) Received: by obbeb7 with SMTP id eb7so49974811obb.3; Thu, 30 Apr 2015 10:48:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=zwKsdSEiK2Ppt9wyA5MrVm2uf/UOyQshvIffJxbgBeE=; b=0644APAOzt++GRUwow5YpDVDSPa2DvEvr3JVuCniYv2rK9PDxdds06hgTv0iHcui1y QxxxAUK6+kgimdSsHKjQ5oP0fZVTpYp2EbAAHoOv5aVgqxtJBSsSdb1Kn8hVEWEZN2lP Sxo4d6a30h/l6O/YjdtWmT2wA+u7nanL/EJO140jlzGlmgi9CR5gDsJRdDaYVyishRgX VIBICKG/xGDxzqn6xnWvh/GeX3p1m3IGq+i/EmPBM9ZLDmIDfEx5/O3fqDZXEjFKenUo 2LU8h56BVa4BYDN2Ki9jUSSGHPcbd4KaOmAXHkSAFddeRzYWano4tPsSkmuO4tqVziZb C5jg== MIME-Version: 1.0 X-Received: by 10.182.153.74 with SMTP id ve10mr4349928obb.54.1430416098990; Thu, 30 Apr 2015 10:48:18 -0700 (PDT) Received: by 10.202.226.13 with HTTP; Thu, 30 Apr 2015 10:48:18 -0700 (PDT) In-Reply-To: References: <4C184296-F426-40EF-9DB6-3AE87C42B516@tislabs.com> <91148102-DADB-42E8-96A0-E89120642894@tislabs.com> Date: Thu, 30 Apr 2015 13:48:18 -0400 Message-ID: From: Matthew Lepinski To: Iljitsch van Beijnum Content-Type: multipart/alternative; boundary=089e013a0ba87620580514f4b3ed Archived-At: Cc: "idr@ietf.org wg" , "sidr@ietf.org" , ggm@apnic.net, Sandra Murphy Subject: Re: [sidr] Levels of BGPsec/RPKI validation, was: Re: [Idr] 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: Thu, 30 Apr 2015 17:48:26 -0000 --089e013a0ba87620580514f4b3ed Content-Type: text/plain; charset=UTF-8 Iljitsch, Thank you for the feedback. With regards to bgpsec-protocol and/or bgpsec-overview, I am not sure what text would be helpful. For path validation (as opposed to origin validation), the path validation algorithm returns one of two states. That is, either an update has a valid signed path or it doesn't. (We discussed previously in SIDR whether there was a useful third case for path validation, and the working group wasn't able to come up with one.) This means that there are six possible states that come from SIDR validation (assuming you are using both origin validation and path validation). That is, three possible origin validation states and two possible path validation states yields six possible joint states. Of course, one's local policy is free to collapse that state-space if they wish to treat of some of those states as identical. (Perhaps if origin is invalid, then it doesn't matter whether path is valid or not ... maybe it is foolish to care about whether there are signatures on a path if the path is headed to a bad destination. I don't know ... but it is a matter of local policy, and it is perfectly fine for different operators to handle such cases differently.) In any case, with regards to path validation, I think that in general one wants to prefer routes with valid, signed paths over routes that lack valid, signed paths. However, personally, for path validation, I would not recommend throwing out all route advertisements where path validation returns invalid. That is, if the only route you know of to get to a particular block of address space has a signature that doesn't valid (or lack signatures because someone in the middle doesn't have BGPsec turned on), I think it is probably a good idea to use that route despite the lack of valid signature chain. (But again, this is a matter of local policy, and I don't want to mandate policy decisions for network operators in the base protocol specification.) - Matt Lepinski On Tue, Apr 28, 2015 at 2:01 PM, Iljitsch van Beijnum wrote: > On 28 Jan 2015, at 23:38, Sandra Murphy wrote: > > > idr folk, your attention and comments would be appreciated as well. > > Since you ask... > > I'm sending this to both idr and sidr as I think this needs broader input > than just sidr. (And it seems I'm no longer on the sidr list.) > > I read draft-ietf-sidr-bgpsec-protocol-11 and > draft-lepinski-bgpsec-overview-00.txt as well as RFC 6483. > > I think what's lacking here is any discussion of what happens when > certificates etc expire. Please stay with me for a bit: > > RFC 6483 talks about RPKI route validation, which suggests that there are > three possible states: > > valid > unknown > invalid > > where valid is preferred over unknown and unknown over invalid, and: > > "It is a matter of local routing policy as to whether routes with an > "invalid" validity state are considered to be ineligible for further > consideration in a route selection process." > > Actually, I think the only reasonable approach is to filter out invalids > and prefer valids over unknowns. The important part here is that if there's > a ROA for 193.0.0.0/21 and then someone announces a more specific like > 193.0.7.0/24, that /24 will be "invalid", so even in partial deployment > RPKI users are protected against malicious or accidental more specifics. > But if invalids are accepted, even with a very low preference, then they > still get to divert traffic. > > So far, so good. > > But now what if a certificate expires? We know from the web that this is > extremely common. If an expired certificate means the prefixes involved are > marked invalid, this means that filtering invalids becomes very > problematic: not only will prefixes randomly drop off the net as people > forget to generate or install certificates or RPKI caches get stale, but if > things get really bad the resulting lack of connectivity makes it > impossible to correct the problem... > > So what we need is for expired certificates to make the affected prefixes > revert to unknown rather than invalid. Turns out, that's what happens today: > > http://mailman.nanog.org/pipermail/nanog/2014-December/071907.html > > However, unless this is specified in one of the related documents other > than the three mentioned above, this seems to be an implementation choice. > > I think the above issue needs to be discussed in an update of RFC 6483 or > in one of the BGPsec documents. > > And there's probably a bit more to think about: wouldn't it make sense to > be able to filter on the signature algorithm at some point during the > transition from one algorithm to the next? Or to be able to filter on > "expired" explicitly? A binary valid/invalid isn't enough. > Valid/unknown/invalid is workable, but maybe four or five levels is even > better. > > (And have a look at how this works in practice: > http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/iproute_bgp/command/irg-cr-book/bgp-m1.html > search for PEX.) > > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr > --089e013a0ba87620580514f4b3ed Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Iljitsch,

Thank you for the feedback. W= ith regards to bgpsec-protocol and/or bgpsec-overview, I am not sure what t= ext would be helpful.

For path validation (as oppo= sed to origin validation), the path validation algorithm returns one of two= states. That is, either an update has a valid signed path or it doesn'= t. (We discussed previously in SIDR whether there was a useful third case f= or path validation, and the working group wasn't able to come up with o= ne.)

This means that there are six possible states= that come from SIDR validation (assuming you are using both origin validat= ion and path validation). That is, three possible origin validation states = and two possible path validation states yields six possible joint states. O= f course, one's local policy is free to collapse that state-space if th= ey wish to treat of some of those states as identical. (Perhaps if origin i= s invalid, then it doesn't matter whether path is valid or not ... mayb= e it is foolish to care about whether there are signatures on a path if the= path is headed to a bad destination. I don't know ... but it is a matt= er of local policy, and it is perfectly fine for different operators to han= dle such cases differently.)

In any case, with reg= ards to path validation, I think that in general =C2=A0one wants to prefer = routes with valid, signed paths over routes that lack valid, signed paths. = However, personally, for path validation, I would not recommend throwing ou= t all route advertisements where path validation returns invalid. That is, = if the only route you know of to get to a particular block of address space= has a signature that doesn't valid (or lack signatures because someone= in the middle doesn't have BGPsec turned on), I think it is probably a= good idea to use that route despite the lack of valid signature chain. (Bu= t again, this is a matter of local policy, and I don't want to mandate = policy decisions for network operators in the base protocol specification.)=

- Matt Lepinski


On Tue, Apr 28, 2015 at = 2:01 PM, Iljitsch van Beijnum <iljitsch@muada.com> wrote:
On 28 Jan 2015, at 23:38, Sandra Murphy &l= t;sandy@tislabs.com> wrote:

> idr folk, your attention and comments would be appreciated as well.
Since you ask...

I'm sending this to both idr and sidr as I think this needs broader inp= ut than just sidr. (And it seems I'm no longer on the sidr list.)

I read draft-ietf-sidr-bgpsec-protocol-11 and draft-lepinski-bgpsec-overvie= w-00.txt as well as RFC 6483.

I think what's lacking here is any discussion of what happens when cert= ificates etc expire. Please stay with me for a bit:

RFC 6483 talks about RPKI route validation, which suggests that there are t= hree possible states:

valid
unknown
invalid

where valid is preferred over unknown and unknown over invalid, and:

"It is a matter of local routing policy as to whether routes with an &= quot;invalid" validity state are considered to be ineligible for furth= er consideration in a route selection process."

Actually, I think the only reasonable approach is to filter out invalids an= d prefer valids over unknowns. The important part here is that if there'= ;s a ROA for 193.0.0.0/21= and then someone announces a more specific like 193.0.7.0/24, that /24 will be "invali= d", so even in partial deployment RPKI users are protected against mal= icious or accidental more specifics. But if invalids are accepted, even wit= h a very low preference, then they still get to divert traffic.

So far, so good.

But now what if a certificate expires? We know from the web that this is ex= tremely common. If an expired certificate means the prefixes involved are m= arked invalid, this means that filtering invalids becomes very problematic:= not only will prefixes randomly drop off the net as people forget to gener= ate or install certificates or RPKI caches get stale, but if things get rea= lly bad the resulting lack of connectivity makes it impossible to correct t= he problem...

So what we need is for expired certificates to make the affected prefixes r= evert to unknown rather than invalid. Turns out, that's what happens to= day:

http://mailman.nanog.org/pipermail/nanog/2014-Decembe= r/071907.html

However, unless this is specified in one of the related documents other tha= n the three mentioned above, this seems to be an implementation choice.

I think the above issue needs to be discussed in an update of RFC 6483 or i= n one of the BGPsec documents.

And there's probably a bit more to think about: wouldn't it make se= nse to be able to filter on the signature algorithm at some point during th= e transition from one algorithm to the next? Or to be able to filter on &qu= ot;expired" explicitly? A binary valid/invalid isn't enough. Valid= /unknown/invalid is workable, but maybe four or five levels is even better.=

(And have a look at how this works in practice: http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/iprou= te_bgp/command/irg-cr-book/bgp-m1.html search for PEX.)

_______________________________________________
sidr mailing list
sidr@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/sidr

--089e013a0ba87620580514f4b3ed-- From nobody Thu Apr 30 13:39:53 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 CAD331A009B; Thu, 30 Apr 2015 13:39:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.11 X-Spam-Level: X-Spam-Status: No, score=-0.11 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_45=0.6, J_CHICKENPOX_47=0.6, J_CHICKENPOX_65=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 1xxJfrLaOFdE; Thu, 30 Apr 2015 13:39:49 -0700 (PDT) Received: from sequoia.muada.com (sequoia.muada.com [IPv6:2001:1af8:3100:a006:1::]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B46B1A0077; Thu, 30 Apr 2015 13:39:48 -0700 (PDT) Received: from [192.168.178.25] (5356AD6E.cm-6-7c.dynamic.ziggo.nl [83.86.173.110]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id t3UKdJCH026323 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 30 Apr 2015 22:39:19 +0200 (CEST) (envelope-from iljitsch@muada.com) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) From: Iljitsch van Beijnum In-Reply-To: Date: Thu, 30 Apr 2015 22:39:31 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <3637DF28-CFC8-46FF-8929-DF88BB91D3AB@muada.com> References: <4C184296-F426-40EF-9DB6-3AE87C42B516@tislabs.com> <91148102-DADB-42E8-96A0-E89120642894@tislabs.com> To: Matthew Lepinski X-Mailer: Apple Mail (2.2098) Archived-At: Cc: "idr@ietf.org wg" , "sidr@ietf.org" Subject: Re: [sidr] Levels of BGPsec/RPKI validation, was: Re: [Idr] 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: Thu, 30 Apr 2015 20:39:51 -0000 On 30 Apr 2015, at 19:48, Matthew Lepinski = wrote: > For path validation (as opposed to origin validation), the path = validation algorithm returns one of two states. That is, either an = update has a valid signed path or it doesn't. (We discussed previously = in SIDR whether there was a useful third case for path validation, and = the working group wasn't able to come up with one.) I think expired certificates qualifies. And a case can be made for = strong crypto algo vs weak crypto algo is a fourth one. > This means that there are six possible states that come from SIDR = validation (assuming you are using both origin validation and path = validation). That is, three possible origin validation states and two = possible path validation states yields six possible joint states. Actually nine, assuming < 100% BGPsec deployment: 1. BGPsec=3Dvalid, RPKI=3Dvalid 2. BGPsec=3Dvalid, RPKI=3Dunknown 3. BGPsec=3Dvalid, RPKI=3Dinvalid 4. no BGPsec, RPKI=3Dvalid 5. no BGPsec, RPKI=3Dunknown 6. no BGPsecd, RPKI=3Dinvalid 7. BGPsec=3Dnotvalid, RPKI=3Dvalid 8. BGPsec=3Dnotvalid, RPKI=3Dunknown 9. BGPsec=3Dnotvalid, RPKI=3Dinvalid Only with type 1 can we be sure that the prefix is advertised = legitimately. Type 5 indicates no BGPsec or RPKI deployment and may or may not be = legitimate. These should have a lower local_pref than type 1. Type 2 is = strange, but can probably be treated the same as type 5, or perhaps a = loc_pref higher than 5 but lower than 1. Types 3, 6 and 9 are bad news, as they may be unauthorized more = specifics, so it's important to filter these. Type 4 can happen because BGPsec hasn't been fully deployed yet = (remember that the whole path must support it while RPKI can be deployed = by just the "end" AS) but once that's no longer common it will be the = attack vector of choice because it's easy to fake the origin AS if = there's no BGPsec, so at some point, these need to be filtered, too. That leaves 7 and 8, which SHOULD be filtered if they're legitimate = BGPsec validation failures and not incidental mistakes such as expired = certificates. > it is perfectly fine for different operators to handle such cases = differently.) Famous last words. Obviously we don't want to be overly prescriptive, = but I don't think there's as much room for creativity as you suggest. > However, personally, for path validation, I would not recommend = throwing out all route advertisements where path validation returns = invalid. That is, if the only route you know of to get to a particular = block of address space has a signature that doesn't valid (or lack = signatures because someone in the middle doesn't have BGPsec turned on), = I think it is probably a good idea to use that route despite the lack of = valid signature chain. Actually I don't think that case can happen. Consider the following = path: 6 5 4 3 2 1 If AS 4 doesn't support BGPsec but the others do, then AS 3 will convert = the BGPsec_Path to an AS_PATH, removing all the signatures. ASes 5 and 6 = are not in the position to repair this, so as far as they're concerned, = the path is completely unprotected. However, what you say here is problematic: > That is, if the only route you know of to get to a particular block of = address space has a signature that doesn't valid (or lack signatures = because someone in the middle doesn't have BGPsec turned on), I think it = is probably a good idea to use that route despite the lack of valid = signature chain. Considering whether a route is "the only route you know" is explicitly = forbidden by RFC 4271: "The function that calculates the degree of preference for a given route SHALL NOT use any of the following as its inputs: the existence of other routes, the non-existence of other routes, or the path attributes of other routes." However, you can get the same result by simply giving the invalid path a = low local preference. However 2, the real problem with allowing prefixes that don't = RPKI/BGPsec validate is that these invalid prefixes could be more = specifics of legitimate prefixes, and no matter how high the local_pref = of the valid prefixes and low the local_pref of the invalid more = specifics, the packets will be forwarded as per the invalid more = specifics. Therefore, the only workable approach is to completely filter out = prefixes that don't validate. However, the downside of such a strict policy is that if the = certificates used for BGPsec signatures expire, the path will become = notvalid and the associated prefixes disappear from the internet. That's = why we need the ability to treat paths that don't validate because of = expired certificates differently from paths that don't validate for = other reasons.