From sidr-bounces@ietf.org Wed Oct 1 13:07:30 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 88B8A3A68E6; Wed, 1 Oct 2008 13:07:30 -0700 (PDT) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F23A03A6801 for ; Wed, 1 Oct 2008 13:07:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q03ugM1RuGW3 for ; Wed, 1 Oct 2008 13:07:28 -0700 (PDT) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by core3.amsl.com (Postfix) with ESMTP id 238E33A67A6 for ; Wed, 1 Oct 2008 13:07:27 -0700 (PDT) Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.13.5/8.13.5) with ESMTP id m91K701p031884 for ; Wed, 1 Oct 2008 15:07:00 -0500 Received: from nemo.columbia.ads.sparta.com (nemo.columbia.sparta.com [157.185.80.75]) by Beta5.sparta.com (8.12.11/8.13.1) with ESMTP id m91K6uuL013756 for ; Wed, 1 Oct 2008 15:06:58 -0500 Received: from SANDYM-LT.columbia.ads.sparta.com ([157.185.81.158]) by nemo.columbia.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Wed, 1 Oct 2008 16:06:55 -0400 Date: Wed, 1 Oct 2008 16:07:02 -0400 (Eastern Daylight Time) From: Sandra Murphy To: sidr@ietf.org Message-ID: X-X-Sender: sandy@nemo.columbia.sparta.com MIME-Version: 1.0 X-OriginalArrivalTime: 01 Oct 2008 20:06:55.0951 (UTC) FILETIME=[40EB75F0:01C92401] Subject: [sidr] resuming last call on draft-ietf-sidr-res-certs-13.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org Geoff Huston submitted a new version of the res-certs draft which responds to comments received on the list and contains new text about trust anchors. I am issuing a working group last call on this draft. The last call will end Wed, Oct 15. Differences in terminology and language are scattered througout. The largest changes are the new trust anchor language in section 6, a new section 7 on Design Notes, and a new appendix on the CMS profile for trust anchor material. The previous last call was the -11 version. There was a short-lived -12 version in between. If you would like to see the differences between the -11 version and the -13 version, try the following URL: http://tools.ietf.org/rfcdiff?url1=http://tools.ietf.org/id/draft-ietf-sidr-res-certs-13.txt&url2=http://tools.ietf.org/id/draft-ietf-sidr-res-certs-11.txt This produces a side-by-side diff. If you prefer one of the other diff styles offered by the tools site, type the appropriate URLs into: http://tools.ietf.org/rfcdiff where the appropriate URLs are: http://tools.ietf.org/id/draft-ietf-sidr-res-certs-13.txt http://tools.ietf.org/id/draft-ietf-sidr-res-certs-11.txt --Sandy _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Thu Oct 2 09:08:44 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1750728C102; Thu, 2 Oct 2008 09:08:44 -0700 (PDT) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 465C83A6A8B; Thu, 2 Oct 2008 09:08:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.561 X-Spam-Level: X-Spam-Status: No, score=-2.561 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qhw3qyAhxffz; Thu, 2 Oct 2008 09:08:42 -0700 (PDT) Received: from mx11.bbn.com (mx11.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id 7AF2E3A6A27; Thu, 2 Oct 2008 09:08:42 -0700 (PDT) Received: from dhcp89-089-071.bbn.com ([128.89.89.71]) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1KlQj8-00079C-DE; Thu, 02 Oct 2008 12:08:30 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <48D96507.4000207@sri.com> <20080929200231.3E5DD3F443@pecan.tislabs.com> <77ead0ec0809291853t63940339xc826b13cf5515176@mail.gmail.com> Date: Thu, 2 Oct 2008 12:08:12 -0400 To: Acee Lindem From: Stephen Kent Cc: msec@ietf.org, tsvwg@ietf.org, OSPF List , Ronald Bonica , secdir@mit.edu, rpsec@ietf.org, sidr@ietf.org Subject: Re: [sidr] [secdir] [OSPF] [RPSEC] Authentication for OSPFv3 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org At 11:08 AM -0400 9/30/08, Acee Lindem wrote: >One thing to take into consideration is that the outcome of our KMART >BOF was that nobody deploying networks wanted routing infra-structure >based on a third-part verified certificates. >Thanks, >Acee Acee, The wording you used here "third-part[y] verified certificates" is ambiguous. A cert is validated (or verified) by a relying party, so third-party verification could imply having some entity verify a cert on behalf of a relying party, e.g, what SCVP permits. If, on the other hand, you were referring to cert issuance (not verification), then it is commonly the case that the cert issuer (certification authority) in a PKI is a "third party" in that it is not a participant in a communication between two relying parties. In either case, I don't recall hearing specific comments of the form you mention. Steve _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Thu Oct 2 18:48:54 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 333153A68E8; Thu, 2 Oct 2008 18:48:54 -0700 (PDT) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1EBC53A677D; Thu, 2 Oct 2008 18:48:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.019 X-Spam-Level: X-Spam-Status: No, score=-6.019 tagged_above=-999 required=5 tests=[AWL=0.580, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fRQ8E4spO+3Z; Thu, 2 Oct 2008 18:48:52 -0700 (PDT) Received: from machshav.com (machshav.com [198.180.150.44]) by core3.amsl.com (Postfix) with ESMTP id 2767B3A67A4; Thu, 2 Oct 2008 18:48:52 -0700 (PDT) Received: by machshav.com (Postfix, from userid 512) id 1904BAF69D; Fri, 3 Oct 2008 01:48:55 +0000 (GMT) Received: from yellowstone.machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 701C8AF687; Fri, 3 Oct 2008 01:48:54 +0000 (GMT) Received: from cs.columbia.edu (localhost [127.0.0.1]) by yellowstone.machshav.com (Postfix) with ESMTP id 6662C838722; Thu, 2 Oct 2008 21:48:53 -0400 (EDT) Date: Thu, 2 Oct 2008 21:48:53 -0400 From: "Steven M. Bellovin" To: Sam Hartman Message-ID: <20081002214853.208a78ff@cs.columbia.edu> In-Reply-To: References: <48D96507.4000207@sri.com> <20080929200231.3E5DD3F443@pecan.tislabs.com> <77ead0ec0809291853t63940339xc826b13cf5515176@mail.gmail.com> Organization: Columbia University X-Mailer: Claws Mail 3.5.0 (GTK+ 2.12.11; x86_64--netbsd) Mime-Version: 1.0 Cc: rpsec@ietf.org, Ronald Bonica , secdir@MIT.EDU, sidr@ietf.org, OSPF List , Acee Lindem Subject: Re: [sidr] [secdir] [OSPF] [RPSEC] Authentication for OSPFv3 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org On Tue, 30 Sep 2008 12:05:28 -0400 Sam Hartman wrote: > It's certainly true that some people in the room spoke out against > certificates. At least some of the reasons given did not actually > inherently apply to certificates as a whole although they did create > some significant constraints for what would not create operational > problems. > Right. There's a big misconception in the world that using certificates inherently requires a massive, complex infrastructure that's best handled by third parties. In reality, using certificates within an enterprise need be no more complex than handing out or accepting passwords. All you need is a simple wrapper around something like OpenSSL. You don't need formal root certificate ceremonies, you don't need court-certified videographers, you don't need high priests waving incense and anointing the certificate-signer machine with a mixture of cow innards and ground-up prime numbers. (That's what OCSP is about: Offal of Cow Sprinkled with Primes....) Whoever hands out address blocks within the company can sign the certificates -- it's that simple. I sometimes refer to this as the difference between "PKI" and "pki" -- for enterprises, you need the latter. --Steve Bellovin, http://www.cs.columbia.edu/~smb _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Fri Oct 3 21:45:34 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ACED13A6924; Fri, 3 Oct 2008 21:45:34 -0700 (PDT) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 825D83A68E4 for ; Fri, 3 Oct 2008 21:45:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.562 X-Spam-Level: X-Spam-Status: No, score=-6.562 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CfBNKVmQX8b0 for ; Fri, 3 Oct 2008 21:45:29 -0700 (PDT) Received: from mint.apnic.net (mint.apnic.net [202.12.29.58]) by core3.amsl.com (Postfix) with ESMTP id 775073A6924 for ; Fri, 3 Oct 2008 21:45:28 -0700 (PDT) Received: from dhcp19.potaroo.net (dhcp19.potaroo.net [203.10.60.19]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mint.apnic.net (Postfix) with ESMTP id 90F7CD5F2D for ; Sat, 4 Oct 2008 14:45:51 +1000 (EST) Message-Id: <513C369E-B21F-42CE-A721-61C258DC15D7@apnic.net> From: Geoff Huston To: sidr@ietf.org Mime-Version: 1.0 (Apple Message framework v929.2) Date: Sat, 4 Oct 2008 14:45:50 +1000 X-Mailer: Apple Mail (2.929.2) Subject: [sidr] Resolving the issues in the roa-format draft X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org WG-Chair hat hurled into the corner for this posting.... I note that there are two residual open issues in the ROA draft that should be resolved. From the minutes of IETF 72 it was reported that from this draft: o Open issues: * Should a canonical format for IP addresses in ROAs be specified? - What does equivalence of ROA mean if there is no canonical format? - Should we mandate canonical format to make comparison as easy as possible? - Is a useful canonical format feasible, and is the transform to any such format of benefit to the ROA creator or ROA relying party? - How do we apply the validation test of a precise match between the resources in the EE cert and the prefixes in the ROA, as described in step 3 of the draft - Further consideration of this topic is required by the WG * Should the ROA format permit multiple EE certs? - If an ISP has two CA certs from different CAs for adjacent addresses where the ISP wishes to advertise the aggregate, that this cannot be expressed in a ROA. - Is this something that the specification should address? - There was no clear outcome from the discussion, and further consideration of the matter is required by the WG. I'd like to propose a resolution to these issues by proposing that: a) NO canonical ROA format be specified. The reason for this is that origination validation is reliant on the presence of a valid ROA that matches the prefix. The presence of additional ROAs, valid or invalid, that also match the prefix does not alter the reliance that can be given to the route object once one valid ROA is detected. Therefore, as long as a relying party can use as a lookup key a given prefix and retrieve all ROAs that match the prefix then the validation operation can be undertaken. Comparison of 2 or more ROAs for equivalence is not necessary. in order to allow this document to proceed I propose that NO text be added regarding a description of a canonical ordering of prefixes in a ROA. b) a ROA BE ALLOWED to use multiple signatures This would use the CMS option of multiple EE certs to describe those aggregate prefixes that are not certified within a single validation path. This is a situation akin to proxy aggregation, where a route object is being constructed from multiple components and the associated ROA therefore contains a route object that cannot be described in a single EE certificate. The draft would need to specify that: - all EE certificates are to be included - all signatures MUST validate for the CMS object to be considered valid - the union of the address prefixes in the EE certificates MUST encompass the prefixes specified in the ROA. In favor of this approach I note that RFC 3852 and RFC4853 permit multiple signatures and EE certs in CMS, so the basic format of the ROA is not altered. The comment has been raised that this is an unlikely situation and there is no need to make the specification more complex for unlikely cases. In response I would argue that the specification should be complete and provide appropriate guidance to implementors for all situations where interoperability is required, and this case, although not common, has visible in the routing table already and will likely be visible in the routing table in future. Given that this does not define a new signature standard for CMS, nor a major change in the logic of ROA processing I do not see that this adds any undue complexity to implementations and has the benefit of covering the full range of anticipated use cases for ROAs in their application to signing route origination. Are there any comments from other folk on this proposed form of resolution? Geoff _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Sat Oct 4 17:30:02 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B4F763A684B; Sat, 4 Oct 2008 17:30:02 -0700 (PDT) X-Original-To: sidr@ietf.org Delivered-To: sidr@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id C9FBC3A684B; Sat, 4 Oct 2008 17:30:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20081005003001.C9FBC3A684B@core3.amsl.com> Date: Sat, 4 Oct 2008 17:30:01 -0700 (PDT) Cc: sidr@ietf.org Subject: [sidr] I-D Action:draft-ietf-sidr-repos-struct-01.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Secure Inter-Domain Routing Working Group of the IETF. Title : A Profile for Resource Certificate Repository Structure Author(s) : G. Huston, et al. Filename : draft-ietf-sidr-repos-struct-01.txt Pages : 12 Date : 2008-10-04 This document defines a profile for the structure of repository publication points that contain X.509 / PKIX Resource Certificates, Certificate Revocation Lists and signed objects. This profile contains the proposed object naming scheme, the contents of repository publication points, the contents of publication point manifests and a suggested internal structure of a local repository cache that is intended to facilitate synchronization across a distributed collection of repository publication points and facilitate certification path construction. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sidr-repos-struct-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-sidr-repos-struct-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-10-04172708.I-D@ietf.org> --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr --NextPart-- From sidr-bounces@ietf.org Sun Oct 5 01:15:03 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D3CB928C0DE; Sun, 5 Oct 2008 01:15:03 -0700 (PDT) X-Original-To: sidr@ietf.org Delivered-To: sidr@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id C35623A67B6; Sun, 5 Oct 2008 01:15:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20081005081501.C35623A67B6@core3.amsl.com> Date: Sun, 5 Oct 2008 01:15:01 -0700 (PDT) Cc: sidr@ietf.org Subject: [sidr] I-D Action:draft-ietf-sidr-bogons-01.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Secure Inter-Domain Routing Working Group of the IETF. Title : A Profile for Bogon Origin Attestations (BOAs) Author(s) : G. Huston, et al. Filename : draft-ietf-sidr-bogons-01.txt Pages : 15 Date : 2008-10-05 This document defines a standard profile for Bogon Origin Attestations (BOAs). A BOA is a digitally signed object that provides a means of verifying that an IP address block holder has not authorized any Autonomous System (AS) to originate routes that are equivalent to any of the addresses listed in the BOA. A BOA also provides a means of verifying that BGP speaker is not using an AS without appropriate authority to use that AS. The proposed application of BOAs is intended to fit within the requirements for adding security measures to inter-domain routing, including the ability to support incremental and piecemeal deployment of such measures, and does not require any changes to the specification of the Border Gateway Protocol. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sidr-bogons-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-sidr-bogons-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-10-05010308.I-D@ietf.org> --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr --NextPart-- From sidr-bounces@ietf.org Sun Oct 5 17:30:02 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3D5263A6913; Sun, 5 Oct 2008 17:30:02 -0700 (PDT) X-Original-To: sidr@ietf.org Delivered-To: sidr@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 4664C3A68FE; Sun, 5 Oct 2008 17:30:00 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20081006003001.4664C3A68FE@core3.amsl.com> Date: Sun, 5 Oct 2008 17:30:01 -0700 (PDT) Cc: sidr@ietf.org Subject: [sidr] I-D Action:draft-ietf-sidr-roa-validation-01.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Secure Inter-Domain Routing Working Group of the IETF. Title : Validation of Route Origination in BGP using the Resource Certificate PKI Author(s) : G. Huston, G. Michaelson Filename : draft-ietf-sidr-roa-validation-01.txt Pages : 13 Date : 2008-10-05 This document defines an application of the Resource Public Key Infrastructure to validate the origination of routes advertised in the Border Gateway Protocol. The proposed application is intended to fit within the requirements for adding security to inter-domain routing, including the ability to support incremental and piecemeal deployment, and does not require any changes to the specification of BGP. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sidr-roa-validation-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-sidr-roa-validation-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-10-05172552.I-D@ietf.org> --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr --NextPart-- From sidr-bounces@ietf.org Sun Oct 5 23:28:03 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AE8383A6943; Sun, 5 Oct 2008 23:28:03 -0700 (PDT) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D54503A6A33 for ; Sun, 5 Oct 2008 23:26:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MimrMD-sLivY for ; Sun, 5 Oct 2008 23:26:40 -0700 (PDT) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.238]) by core3.amsl.com (Postfix) with ESMTP id 0167E3A6967 for ; Sun, 5 Oct 2008 23:26:39 -0700 (PDT) Received: by rv-out-0506.google.com with SMTP id b25so2467269rvf.49 for ; Sun, 05 Oct 2008 23:27:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:from:to :content-type:content-transfer-encoding:mime-version:subject:date :x-mailer:sender; bh=u+bqRPrI+FHB3ajQmRsKzXjEK51m45P4+HZwU/9QqBk=; b=WVsRA9y2aldGb/6hsVbG7LrvHxicwvtLyxydW1X9YH/kqYzxsrRPszC83l83Nuvymd 58w5GGpoGMorkEMLILiFZNz37b3EOccMJ63TCm5Jc1gVmiZm0nAsPkzWjphAMH2obcbk MDb6L2LQ0PPLpYNWkKwR6LAs2K5/hvrCn1NfQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:from:to:content-type:content-transfer-encoding :mime-version:subject:date:x-mailer:sender; b=MiInTS8UERrw5gw1HU022O2iKcIYu397czkuA9hXubiaVg1CsOxx5O+c1fWHjB+5TO Nql5rHm43YUjdrgI1i6LPVtHIuawG9ek7eVUx1ULmLFG02Y6tF6ANAlVdBqMEanzZsqn RM8IjXw5sl2hx5UuKDmucSmwHuCCYayU6HYO0= Received: by 10.141.44.13 with SMTP id w13mr2617175rvj.181.1223274425333; Sun, 05 Oct 2008 23:27:05 -0700 (PDT) Received: from ?192.168.1.103? (c58-108-241-164.fitzg1.qld.optusnet.com.au [58.108.241.164]) by mx.google.com with ESMTPS id b39sm15683447rvf.0.2008.10.05.23.27.03 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 05 Oct 2008 23:27:04 -0700 (PDT) Message-Id: From: Terry Manderson To: sidr@ietf.org Mime-Version: 1.0 (Apple Message framework v929.2) Date: Mon, 6 Oct 2008 16:27:01 +1000 X-Mailer: Apple Mail (2.929.2) Subject: [sidr] draft-manderson-sidr-fetch-00.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org All, I have created a "new" version of the draft presented and discussed in Dublin. http://www.ietf.org/internet-drafts/draft-manderson-sidr-fetch-00.txt This version, while still noted as "00" (*), has: - https mandated for full end to end integrity of fetching objects - updated for RFC5280 - acknowledges the potential for failed retrieval of objects and identifies actions after that as being a local cache policy issue. - notes that a balance of number of HTTPS connections v parallelism needs to be considered by the client - Drops the "Alternative" from the name of the draft. It is superfluous. - Updated author details. (*) it is version 00 as I fixed my mistake of draft naming - meaning that my previous wrongly named version doesn't count as 00 by IDNITS. Terry _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Mon Oct 6 05:53:50 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 63BC728C115; Mon, 6 Oct 2008 05:53:50 -0700 (PDT) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B53733A68FA for ; Mon, 6 Oct 2008 05:53:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XrVxYWeA1xz2 for ; Mon, 6 Oct 2008 05:53:48 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by core3.amsl.com (Postfix) with ESMTP id B9A0D28C115 for ; Mon, 6 Oct 2008 05:53:47 -0700 (PDT) Received: from c-71-193-199-226.hsd1.or.comcast.net ([71.193.199.226] helo=rmac.psg.com) by ran.psg.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KmpbR-000KNo-N6 for sidr@ietf.org; Mon, 06 Oct 2008 12:54:21 +0000 Message-ID: <48EA0A7D.5070508@psg.com> Date: Mon, 06 Oct 2008 05:54:21 -0700 From: Randy Bush User-Agent: Thunderbird 2.0.0.17 (Macintosh/20080914) MIME-Version: 1.0 To: Silly Ideas for Doing X-Enigmail-Version: 0.95.7 Subject: [sidr] multiply signed roas are useless X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org [ since my last message on this subject was not approved for posting to this list, i am inflicting myself directly on you. apologies. ] i am told that multiply signed roas are reappearing like whack-a-mole. they are as operationally useful as gears on a fish, and serve only to make it harder for the poor thing to swim. the fantasy that receiving two aggregatable prefixes from two different parents is as O(likely) as brownian motion causing all the molecules of air in the room to rush into one corner and stay there, and all the complexity it would produce in relying implementations would save the announcement of one prefix in the global routing table. wow! just announce the two prefixes. sheesh! if it would save the over 50% pollution of the routing table by idiocy, then i would leap to advocating it. but one bleeping prefix, and with a 0.00001% probability at that? you must be kidding. is life not hard enough already? notice how rirs' promises of delivery have already slipped by years. this is not easy stuff. do everything you can to simplify it, not complicate it. and surely we can find better ways to amuse ourselves by complicating things. like how about we propose a second and less efficient protocol for fetching repositories? randy _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Mon Oct 6 07:28:29 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0EEA23A6A41; Mon, 6 Oct 2008 07:28:29 -0700 (PDT) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7B3193A6A41 for ; Mon, 6 Oct 2008 07:28:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.516 X-Spam-Level: X-Spam-Status: No, score=-2.516 tagged_above=-999 required=5 tests=[AWL=0.083, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xw487+MU9tcG for ; Mon, 6 Oct 2008 07:28:26 -0700 (PDT) Received: from mx3.bbn.com (mx3.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id 2763F3A67F4 for ; Mon, 6 Oct 2008 07:28:26 -0700 (PDT) Received: from dhcp89-089-234.bbn.com ([128.89.89.234] helo=[127.0.0.1]) by mx3.bbn.com with esmtp (Exim 4.63) (envelope-from ) id 1Kmr53-00083Z-A6; Mon, 06 Oct 2008 10:29:01 -0400 Message-ID: <48EA2044.6000204@bbn.com> Date: Mon, 06 Oct 2008 10:27:16 -0400 From: Matt Lepinski Organization: BBN User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Geoff Huston References: <513C369E-B21F-42CE-A721-61C258DC15D7@apnic.net> In-Reply-To: <513C369E-B21F-42CE-A721-61C258DC15D7@apnic.net> Cc: Resource Cert List , sidr@ietf.org Subject: Re: [sidr] Resolving the issues in the roa-format draft X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org Geoff, On the issue of canonicalization -- To the best of my knowledge no one has put forward a use-case, on this mailing list or at the Dublin meeting, in which efficient comparison of ROAs is necessary. Therefore, the only reason to define some sort of 'canonicalization' is to simplify comparison between the addresses in a ROA and an EE cert. It is possible that requiring prefixes to be lexiographically sorted makes it easier for relying parties to compare a ROA with its coresponding EE certificate [at the cost of slightly more work for the relying party]. Therefore, I have a weak preference for requiring ROA prefixes to be lexiographically sorted. However, I have a strong preference for finishing the document, so I'm willing to go along with Geoff's proposal (i.e. No canonical ordering). While we're on the topic of comparing ROA prefixes to those in EE certificates: Currently, the ROA format draft specifies an exact match between the prefixes in a ROA and the prefixes in the EE cert, and this text is a bit ambigous as written (for which I am to blame). As was pointed out at IETF 72 we have the following issue: One might reasonably create a ROA containing 10.0/16 and 10.1/16. However, RFC 3779 specifies that if one were to create an EE cert covering these addresses that the IP address extension would contain the single prefix 10.0/15. So if by "exact match" we mean a simple bit-wise comparison, then 10.0/16 and 10.1/16 cannot be present in the same ROA (they would need to be split into two separate ROAs, which is clearly inefficient) and if by "exact match" we mean 'logically the same set of addresses' then it's not clear what the "exact match" requirement is buying us. At IETF 72, George Michaelson suggested that the proper requirement is that each prefix in the ROA is a logical subset of a prefix in the EE certificate. This is at least as easy to implement as testing whether the ROA and EE cert contain the same 'logical set of addresses' and nicely resolves the issue of needing to break apart authorizations into a (potentially) large number of ROAs. - Matt Lepinski Geoff Huston wrote: > WG-Chair hat hurled into the corner for this posting.... > > I note that there are two residual open issues in the ROA draft that > should be resolved. From the minutes of IETF 72 it was reported that > from this draft: > > > o Open issues: > * Should a canonical format for IP addresses in ROAs be > specified? > - What does equivalence of ROA mean if there is no canonical > format? > - Should we mandate canonical format to make comparison as > easy as possible? > - Is a useful canonical format feasible, and is the transform > to any such format of benefit to the ROA creator or ROA > relying party? > - How do we apply the validation test of a precise match > between the resources in the EE cert and the prefixes in > the ROA, as described in step 3 of the draft > - Further consideration of this topic is required by the WG > > * Should the ROA format permit multiple EE certs? > - If an ISP has two CA certs from different CAs for adjacent > addresses where the ISP wishes to advertise the aggregate, > that this cannot be expressed in a ROA. > - Is this something that the specification should address? > - There was no clear outcome from the discussion, and further > consideration of the matter is required by the WG. > > > I'd like to propose a resolution to these issues by proposing that: > > a) NO canonical ROA format be specified. > > The reason for this is that origination validation is reliant on the > presence of a valid ROA that matches the prefix. The presence of > additional ROAs, valid or invalid, that also match the prefix does > not alter the reliance that can be given to the route object once > one valid ROA is detected. Therefore, as long as a relying party can > use as a lookup key a given prefix and retrieve all ROAs that match > the prefix then the validation operation can be undertaken. > Comparison of 2 or more ROAs for equivalence is not necessary. in > order to allow this document to proceed I propose that NO text be > added regarding a description of a canonical ordering of prefixes in > a ROA. > > b) a ROA BE ALLOWED to use multiple signatures > > This would use the CMS option of multiple EE certs to describe those > aggregate prefixes that are not certified within a single validation > path. This is a situation akin to proxy aggregation, where a route > object is being constructed from multiple components and the > associated ROA therefore contains a route object that cannot be > described in a single EE certificate. > > The draft would need to specify that: > - all EE certificates are to be included > - all signatures MUST validate for the CMS object to be considered valid > - the union of the address prefixes in the EE certificates MUST > encompass the prefixes specified in the ROA. > > In favor of this approach I note that RFC 3852 and RFC4853 permit > multiple signatures and EE certs in CMS, so the basic format of the > ROA is not altered. > > The comment has been raised that this is an unlikely situation and > there is no need to make the specification more complex for unlikely > cases. In response I would argue that the specification should be > complete and provide appropriate guidance to implementors for all > situations where interoperability is required, and this case, > although not common, has visible in the routing table already and > will likely be visible in the routing table in future. Given that > this does not define a new signature standard for CMS, nor a major > change in the logic of ROA processing I do not see that this adds any > undue complexity to implementations and has the benefit of covering > the full range of anticipated use cases for ROAs in their application > to signing route origination. > > Are there any comments from other folk on this proposed form of > resolution? > > Geoff > > > > > > > _______________________________________________ > 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 sidr-bounces@ietf.org Mon Oct 6 15:39:50 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2F64A28C1F2; Mon, 6 Oct 2008 15:39:50 -0700 (PDT) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0F3FB28C1F2 for ; Mon, 6 Oct 2008 15:39:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TgaX-lrjmepK for ; Mon, 6 Oct 2008 15:39:48 -0700 (PDT) Received: from mint.apnic.net (mint.apnic.net [202.12.29.58]) by core3.amsl.com (Postfix) with ESMTP id 4A6543A676A for ; Mon, 6 Oct 2008 15:39:48 -0700 (PDT) Received: from dhcp076.yarralumla.aarnet.edu.au (dhcp076.yarralumla.aarnet.edu.au [192.94.63.76]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mint.apnic.net (Postfix) with ESMTP id 83B5DD5F2D for ; Tue, 7 Oct 2008 08:40:18 +1000 (EST) Message-Id: From: Geoff Huston To: sidr@ietf.org In-Reply-To: <48EA0A7D.5070508@psg.com> Mime-Version: 1.0 (Apple Message framework v929.2) Date: Tue, 7 Oct 2008 09:40:17 +1100 References: <48EA0A7D.5070508@psg.com> X-Mailer: Apple Mail (2.929.2) Subject: Re: [sidr] Resolving the issues in the roa-format draft X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org My WG-Chair hat tossed into the corner for this posting.... On 06/10/2008, at 11:54 PM, Randy Bush wrote: > I am told that multiply signed roas are reappearing [...] As I understand the substance of this post, the comment has been raised (again) that this is an unlikely situation and there is no need to make the specification more complex for unlikely cases. In response I would argue (again) that the specification should be complete and provide appropriate guidance to implementors for all situations where interoperability is required, and this case, although not common, has been visible in the routing table already and will likely be visible in the routing table in future. Given that this does not define a new signature standard for CMS, nor a major change in the logic of ROA processing I do not see that this adds any undue complexity to implementations and has the benefit of covering the full range of anticipated use cases for ROAs in their application to signing route origination. Geoff _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Mon Oct 6 15:42:22 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 584803A6A7F; Mon, 6 Oct 2008 15:42:22 -0700 (PDT) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B8F7D3A6A7F for ; Mon, 6 Oct 2008 15:42:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KVkSR2SXo8jW for ; Mon, 6 Oct 2008 15:42:20 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by core3.amsl.com (Postfix) with ESMTP id D5F4A3A6804 for ; Mon, 6 Oct 2008 15:42:19 -0700 (PDT) Received: from c-71-193-199-226.hsd1.or.comcast.net ([71.193.199.226] helo=rmac.psg.com) by ran.psg.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Kmyn0-000MTj-9R; Mon, 06 Oct 2008 22:42:54 +0000 Message-ID: <48EA946D.6040303@psg.com> Date: Mon, 06 Oct 2008 15:42:53 -0700 From: Randy Bush User-Agent: Thunderbird 2.0.0.17 (Macintosh/20080914) MIME-Version: 1.0 To: Geoff Huston References: <48EA0A7D.5070508@psg.com> In-Reply-To: X-Enigmail-Version: 0.95.7 Cc: sidr@ietf.org Subject: Re: [sidr] Resolving the issues in the roa-format draft X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org > As I understand the substance of this post, the comment has been > raised (again) that this is an unlikely situation and there is no > need to make the specification more complex for unlikely cases. > > In response I would argue (again) that the specification should be > complete and provide appropriate guidance to implementors for all > situations where interoperability is required, and this case, > although not common, has been visible in the routing table already > and will likely be visible in the routing table in future. boiling the ocean is not necessary nor it is useful > I do not see that this adds any undue complexity to implementations do you just delete rob's mail unread? randy _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Mon Oct 6 16:06:54 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A3E8028C10D; Mon, 6 Oct 2008 16:06:54 -0700 (PDT) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 48ABB3A67EF for ; Mon, 6 Oct 2008 16:06:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r3gwVxKJuT48 for ; Mon, 6 Oct 2008 16:06:52 -0700 (PDT) Received: from mint.apnic.net (mint.apnic.net [202.12.29.58]) by core3.amsl.com (Postfix) with ESMTP id 2BEFA3A6867 for ; Mon, 6 Oct 2008 16:06:52 -0700 (PDT) Received: from dhcp076.yarralumla.aarnet.edu.au (dhcp076.yarralumla.aarnet.edu.au [192.94.63.76]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mint.apnic.net (Postfix) with ESMTP id 02A02D5F2D; Tue, 7 Oct 2008 09:07:12 +1000 (EST) Message-Id: <5E759AC5-DB4F-45C4-BD81-FFB63A3479F5@apnic.net> From: Geoff Huston To: Matt Lepinski In-Reply-To: <48EA2044.6000204@bbn.com> Mime-Version: 1.0 (Apple Message framework v929.2) Date: Tue, 7 Oct 2008 10:07:12 +1100 References: <513C369E-B21F-42CE-A721-61C258DC15D7@apnic.net> <48EA2044.6000204@bbn.com> X-Mailer: Apple Mail (2.929.2) Cc: sidr@ietf.org Subject: Re: [sidr] Resolving the issues in the roa-format draft X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org On 07/10/2008, at 1:27 AM, Matt Lepinski wrote: > Geoff, > > On the issue of canonicalization -- To the best of my knowledge no > one has put forward a use-case, on this mailing list or at the > Dublin meeting, in which efficient comparison of ROAs is necessary. > Therefore, the only reason to define some sort of 'canonicalization' > is to simplify comparison between the addresses in a ROA and an EE > cert. It is possible that requiring prefixes to be lexiographically > sorted makes it easier for relying parties to compare a ROA with its > coresponding EE certificate [at the cost of slightly more work for > the relying party]. Therefore, I have a weak preference for > requiring ROA prefixes to be lexiographically sorted. However, I > have a strong preference for finishing the document, so I'm willing > to go along with Geoff's proposal (i.e. No canonical ordering). > > While we're on the topic of comparing ROA prefixes to those in EE > certificates: Currently, the ROA format draft specifies an exact > match between the prefixes in a ROA and the prefixes in the EE cert, > and this text is a bit ambigous as written (for which I am to > blame). As was pointed out at IETF 72 we have the following issue: > > One might reasonably create a ROA containing 10.0/16 and 10.1/16. > However, RFC 3779 specifies that if one were to create an EE cert > covering these addresses that the IP address extension would contain > the single prefix 10.0/15. > So if by "exact match" we mean a simple bit-wise comparison, then > 10.0/16 and 10.1/16 cannot be present in the same ROA (they would > need to be split into two separate ROAs, which is clearly > inefficient) and if by "exact match" we mean 'logically the same set > of addresses' then it's not clear what the "exact match" requirement > is buying us. > > At IETF 72, George Michaelson suggested that the proper requirement > is that each prefix in the ROA is a logical subset of a prefix in > the EE certificate. This is at least as easy to implement as testing > whether the ROA and EE cert contain the same 'logical set of > addresses' and nicely resolves the issue of needing to break apart > authorizations into a (potentially) large number of ROAs. WG chair hat off once more: Yes, if the text in section 3, step 3 of the draft was altered to use the term "encompass" such that the IP addresses prefixes in that extension encompasses the IP prefix(es) in the ROA I would agree that would be a suitable resolution. regards, Geoff _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Mon Oct 6 16:08:00 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D5D803A6B2E; Mon, 6 Oct 2008 16:08:00 -0700 (PDT) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 72C973A6987 for ; Mon, 6 Oct 2008 16:07:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jUNwy5qGYwbV for ; Mon, 6 Oct 2008 16:07:58 -0700 (PDT) Received: from cyteen.hactrn.net (cyteen.hactrn.net [IPv6:2002:425c:4242:0:210:5aff:fe86:1f54]) by core3.amsl.com (Postfix) with ESMTP id 4F88A3A6B2E for ; Mon, 6 Oct 2008 16:07:58 -0700 (PDT) Received: from thrintun.hactrn.net (thrintun.hactrn.net [IPv6:2002:425c:4242:0:219:d1ff:fe12:5d30]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "thrintun.hactrn.net", Issuer "Grunchweather Associates" (verified OK)) by cyteen.hactrn.net (Postfix) with ESMTPS id 6130328429 for ; Mon, 6 Oct 2008 23:08:32 +0000 (UTC) Received: from thrintun.hactrn.net (localhost [IPv6:::1]) by thrintun.hactrn.net (Postfix) with ESMTP id 133E92282B for ; Mon, 6 Oct 2008 19:08:32 -0400 (EDT) Date: Mon, 06 Oct 2008 19:08:32 -0400 From: Rob Austein To: sidr@ietf.org In-Reply-To: References: <48EA0A7D.5070508@psg.com> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Message-Id: <20081006230832.133E92282B@thrintun.hactrn.net> Subject: Re: [sidr] Resolving the issues in the roa-format draft X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org At Tue, 7 Oct 2008 09:40:17 +1100, Geoff Huston wrote: > > ... I would argue (again) that the specification should be > complete and provide appropriate guidance to implementors for all > situations where interoperability is required, and this case, although > not common, has been visible in the routing table already and will > likely be visible in the routing table in future. Given that this does > not define a new signature standard for CMS, nor a major change in the > logic of ROA processing I do not see that this adds any undue > complexity to implementations and has the benefit of covering the full > range of anticipated use cases for ROAs in their application to > signing route origination. It adds a requirement that the validator, rather than doing a "simple" tree walk, must now attempt to trace multiple paths through the tree in order to check the signatures on the ROA. This adds quite a bit of complexity to the validation process, for no gain that I can see. Unnecessary complexity in a security-sensitive piece of software is a bad thing, so I have no intention of implementing this even if you do get it into the specification. _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Mon Oct 6 16:10:15 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0618A28C169; Mon, 6 Oct 2008 16:10:15 -0700 (PDT) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0D3E428C169 for ; Mon, 6 Oct 2008 16:10:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l3qwTELjEz-O for ; Mon, 6 Oct 2008 16:10:13 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by core3.amsl.com (Postfix) with ESMTP id 3E91528C10D for ; Mon, 6 Oct 2008 16:10:13 -0700 (PDT) Received: from c-71-193-199-226.hsd1.or.comcast.net ([71.193.199.226] helo=rmac.psg.com) by ran.psg.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KmzE0-000MX5-5z; Mon, 06 Oct 2008 23:10:48 +0000 Message-ID: <48EA9AF7.4020204@psg.com> Date: Mon, 06 Oct 2008 16:10:47 -0700 From: Randy Bush User-Agent: Thunderbird 2.0.0.17 (Macintosh/20080914) MIME-Version: 1.0 To: Rob Austein References: <48EA0A7D.5070508@psg.com> <20081006230832.133E92282B@thrintun.hactrn.net> In-Reply-To: <20081006230832.133E92282B@thrintun.hactrn.net> X-Enigmail-Version: 0.95.7 Cc: sidr@ietf.org Subject: Re: [sidr] Resolving the issues in the roa-format draft X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org > It adds a requirement that the validator, rather than doing a "simple" > tree walk, must now attempt to trace multiple paths through the tree > in order to check the signatures on the ROA. s/multiple/an unconstrained number of/ randy _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Mon Oct 6 16:12:03 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 310663A6B48; Mon, 6 Oct 2008 16:12:03 -0700 (PDT) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AF4F83A6B47 for ; Mon, 6 Oct 2008 16:12:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.542 X-Spam-Level: X-Spam-Status: No, score=-2.542 tagged_above=-999 required=5 tests=[AWL=0.057, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L9xmslh-sQWv for ; Mon, 6 Oct 2008 16:12:02 -0700 (PDT) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.172]) by core3.amsl.com (Postfix) with ESMTP id A05CB28C10D for ; Mon, 6 Oct 2008 16:12:01 -0700 (PDT) Received: by wf-out-1314.google.com with SMTP id 27so3187933wfd.31 for ; Mon, 06 Oct 2008 16:12:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:from:to :in-reply-to:content-type:content-transfer-encoding:mime-version :subject:date:references:x-mailer:sender; bh=BeHEmldRkHnFp9LIEILijX1dNf+23y3K9UJvpH2zLVw=; b=dW/aCT3vzlrwLfMCofXS7ICKUFnq0XXjrNQkT0LatB+Wg2X4+UwPr40xUxJ1LRFXEJ E4NcE9mxiMJgwL+bYJVqR/ak/+c7UWQpednSvfEI2OewRYdOSuKIeM0nOH4+7c1XaW5Q WiDrnV/+Om630TnUgHUQ3C5K40HaT+VcxU/WM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:from:to:in-reply-to:content-type :content-transfer-encoding:mime-version:subject:date:references :x-mailer:sender; b=DE+gWRcfdTi9WNmkZuBxXcdiDsGTJA/j4+ef4XpClAtJTcmvzm7ryV5H4Iy0YVw2nk 6TWkg5MpHEEhY6rpghypg9ClQeeKwfTEF1JzBHnuSu8uGR921r0BiRI6LBqQ3ZkNoEKt ETgfEVEWJNDiC8HZp8wnTvkCttEzOZzPWSWBM= Received: by 10.114.168.1 with SMTP id q1mr6453852wae.72.1223334757121; Mon, 06 Oct 2008 16:12:37 -0700 (PDT) Received: from ?192.168.1.103? (c58-108-241-164.fitzg1.qld.optusnet.com.au [58.108.241.164]) by mx.google.com with ESMTPS id m17sm32720371waf.35.2008.10.06.16.12.35 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 06 Oct 2008 16:12:36 -0700 (PDT) Message-Id: From: Terry Manderson To: sidr@ietf.org In-Reply-To: <48EA0A7D.5070508@psg.com> Mime-Version: 1.0 (Apple Message framework v929.2) Date: Tue, 7 Oct 2008 09:12:30 +1000 References: <48EA0A7D.5070508@psg.com> X-Mailer: Apple Mail (2.929.2) Subject: Re: [sidr] multiply signed roas are useless X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org Hi Randy, On 06/10/2008, at 10:54 PM, Randy Bush wrote: While sometimes I enjoy reading pointed rhetoric dismissing everyone else's view of the world, I'll skip it for today thanks. > and surely we can find better ways to amuse ourselves by complicating > things. like how about we propose a second and less efficient > protocol > for fetching repositories? Thanks for the deeply considered response to the sidr-fetch draft - gosh I'm assuming that is the draft you are targeting in your comment. I'd hate to misread your intention. Do you have any other comments you would like to share? Perhaps in line with what the draft is trying to achieve in terms of utility, security, scalability, integrity .. and any other "ity" words we might like to bring up, like compatibility.. .. and yes I do find many things amusing. Cheers Terry _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Mon Oct 6 16:33:58 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E8CF228C227; Mon, 6 Oct 2008 16:33:58 -0700 (PDT) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 715DE28C227 for ; Mon, 6 Oct 2008 16:33:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mRGyp-6NdWnU for ; Mon, 6 Oct 2008 16:33:56 -0700 (PDT) Received: from mint.apnic.net (mint.apnic.net [202.12.29.58]) by core3.amsl.com (Postfix) with ESMTP id 6929628C225 for ; Mon, 6 Oct 2008 16:33:56 -0700 (PDT) Received: from dhcp076.yarralumla.aarnet.edu.au (dhcp076.yarralumla.aarnet.edu.au [192.94.63.76]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mint.apnic.net (Postfix) with ESMTP id EBC03D5F2D; Tue, 7 Oct 2008 09:34:19 +1000 (EST) Message-Id: From: Geoff Huston To: Rob Austein In-Reply-To: <20081006230832.133E92282B@thrintun.hactrn.net> Mime-Version: 1.0 (Apple Message framework v929.2) Date: Tue, 7 Oct 2008 10:34:19 +1100 References: <48EA0A7D.5070508@psg.com> <20081006230832.133E92282B@thrintun.hactrn.net> X-Mailer: Apple Mail (2.929.2) Cc: sidr@ietf.org Subject: Re: [sidr] Resolving the issues in the roa-format draft X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org WG chair hgat off On 07/10/2008, at 10:08 AM, Rob Austein wrote: > At Tue, 7 Oct 2008 09:40:17 +1100, Geoff Huston wrote: >> >> ... I would argue (again) that the specification should be >> complete and provide appropriate guidance to implementors for all >> situations where interoperability is required, and this case, >> although >> not common, has been visible in the routing table already and will >> likely be visible in the routing table in future. Given that this >> does >> not define a new signature standard for CMS, nor a major change in >> the >> logic of ROA processing I do not see that this adds any undue >> complexity to implementations and has the benefit of covering the >> full >> range of anticipated use cases for ROAs in their application to >> signing route origination. > > It adds a requirement that the validator, rather than doing a "simple" > tree walk, must now attempt to trace multiple paths through the tree > in order to check the signatures on the ROA. Rather rather than a single check that the single certificate in the field of the Signed Data type is valid this becomes a iterative loop that invokes the validation procedure for each certificate in the field of the Signed Data type. Faiure at any stage is failure of the validation procedure. So far I'm not seeing complexity. Rather than a single pass through step 1 of the algorithm specified in section 3 of the draft there is a loop for each SignerInfo instance n the CMS. Again I'm not seeing complexity here. step 2 of that process is also repeated for each EE certificate rater than a single call. step 3 requires that the IP addresses in the collection of the EE certificates be merged into a single set before the "encompass" test is performed Without specifying the algorithm in detail here, I cannot see that this is a complex piece of code. Step 4 is repeated for each EE certificate, as noted above. Again I'm not seeing complexity here. > This adds quite a bit of > complexity to the validation process, If one assumes that iterative loops are complex then I could readily agree with this assertion. But I've never found them complex myself. Geoff _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Mon Oct 6 16:41:54 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 26FC028C10D; Mon, 6 Oct 2008 16:41:54 -0700 (PDT) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7F42128C10D for ; Mon, 6 Oct 2008 16:41:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JhfHBGCVKehp for ; Mon, 6 Oct 2008 16:41:51 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by core3.amsl.com (Postfix) with ESMTP id B15C73A676A for ; Mon, 6 Oct 2008 16:41:51 -0700 (PDT) Received: from c-71-193-199-226.hsd1.or.comcast.net ([71.193.199.226] helo=rmac.psg.com) by ran.psg.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KmziS-000Md9-5p; Mon, 06 Oct 2008 23:42:16 +0000 Message-ID: <48EAA257.7010301@psg.com> Date: Mon, 06 Oct 2008 16:42:15 -0700 From: Randy Bush User-Agent: Thunderbird 2.0.0.17 (Macintosh/20080914) MIME-Version: 1.0 To: Geoff Huston References: <48EA0A7D.5070508@psg.com> <20081006230832.133E92282B@thrintun.hactrn.net> In-Reply-To: X-Enigmail-Version: 0.95.7 Cc: Whack-a-Mole WG Subject: Re: [sidr] multiply signed roas are useless X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org it is not necessary. it is not operationally useful. it adds complexity to a security application. is there a netowrk operator here who really needs it? and we have already heard from the major open source full system implementor, who does not plan to add it. randy _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Mon Oct 6 16:42:16 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 48B5028C242; Mon, 6 Oct 2008 16:42:16 -0700 (PDT) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 57A1828C242 for ; Mon, 6 Oct 2008 16:42:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.265 X-Spam-Level: X-Spam-Status: No, score=-6.265 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j7uxJDVDegea for ; Mon, 6 Oct 2008 16:42:13 -0700 (PDT) Received: from outbound.afilias.info (outbound.afilias.info [69.46.124.26]) by core3.amsl.com (Postfix) with ESMTP id 4C9573A676A for ; Mon, 6 Oct 2008 16:42:13 -0700 (PDT) Received: from bmp-336-ms505.wa.yyz2.afilias-ops.info ([10.50.129.111] helo=smtp.afilias.info) by outbound.afilias.info with esmtp (Exim 4.69) (envelope-from ) id 1Kmzi0-0004vX-5g; Mon, 06 Oct 2008 23:41:48 +0000 Message-ID: <48EAA23F.6030609@ca.afilias.info> Date: Mon, 06 Oct 2008 19:41:51 -0400 From: Brian Dickson User-Agent: Thunderbird 2.0.0.17 (Macintosh/20080914) MIME-Version: 1.0 To: Geoff Huston References: <513C369E-B21F-42CE-A721-61C258DC15D7@apnic.net> In-Reply-To: <513C369E-B21F-42CE-A721-61C258DC15D7@apnic.net> X-Authenticated: True Cc: sidr@ietf.org Subject: Re: [sidr] Resolving the issues in the roa-format draft X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org Geoff Huston wrote: > WG-Chair hat hurled into the corner for this posting.... > > I note that there are two residual open issues in the ROA draft that > should be resolved. From the minutes of IETF 72 it was reported that > from this draft: > > > o Open issues: > * Should a canonical format for IP addresses in ROAs be > specified? > - What does equivalence of ROA mean if there is no canonical > format? > - Should we mandate canonical format to make comparison as > easy as possible? > - Is a useful canonical format feasible, and is the transform > to any such format of benefit to the ROA creator or ROA > relying party? > - How do we apply the validation test of a precise match > between the resources in the EE cert and the prefixes in > the ROA, as described in step 3 of the draft > - Further consideration of this topic is required by the WG > (see below, please) > > I'd like to propose a resolution to these issues by proposing that: > > a) NO canonical ROA format be specified. > > The reason for this is that origination validation is reliant on the > presence of a valid ROA that matches the prefix. The presence of > additional ROAs, valid or invalid, that also match the prefix does not > alter the reliance that can be given to the route object once one > valid ROA is detected. Therefore, as long as a relying party can use > as a lookup key a given prefix and retrieve all ROAs that match the > prefix then the validation operation can be undertaken. Comparison of > 2 or more ROAs for equivalence is not necessary. in order to allow > this document to proceed I propose that NO text be added regarding a > description of a canonical ordering of prefixes in a ROA. > (See below) > Are there any comments from other folk on this proposed form of > resolution? I hope it isn't too late to voice an opinion on ROA prefix and prefix-range semantics, and how those may better be represented with a slight change in the ROA fields needed to achieve that degree of subtlety. I believe that this may in fact inform a canonical format and sort order, for facilitating comparisons between ROAs and for matching prefixes against ROAs. Here's the gist of the issue - there are two things represented in the ROA which a prefix must match. One is, the "range" of the ROA, i.e. the CIDR block within which the matching prefix must fall. The second is the "size" of prefixes that the ROA is valid for, i.e. the range of valid prefix-lengths that a matching prefix's prefix-length must fall within. As it currently stands, an ROA has an implicit, rather than explicit, lower value for the range of prefix-lengths, which equals the prefix-length of the CIDR block that the ROA describes. I believe that there may be situations where the "semantics" of the ROA as it stands, would require multiple ROAs (where "multiple" could conceivably be any power of 2!!), to accurately represent a desired ROA assignment set. And, that a more "flexible" ROA with *explicit* lower value for range of prefix-lengths, would be all that is required to permit expressing such ROA sets. Rather than having: IP_address / length le maxLength (length <= maxLength <= address-family-max-length) this would be IP_address / length ge minLength le maxLength (length <= minLength <= maxLength <= address-family-max-length) One example I've seen discussed (not sure of the context, either in ROA format discussions, or in multiple-signature context), is 10.0/16 and 10.1/16. In this new syntax, this would be represented as "10.0/15 ge 16 le 16". A prefix/length would match an ROA, iff prefix is covered by ROA (ip_address/length) AND minLength <= length <= maxLength. Sort order would be: prefix (ascending) length (descending) minLength (descending) maxLength (descending) Search order semantics would be (and could be extended to tree-based searching): key_prefix >= prefix key_prefix < prefix + 2^(addr-family-max-length - length) key_length >= minLength key_length <= maxLength (NB - with this sort order and search order, the presence of "moot" ROAs who are entirely covered by another ROA (subnet of the prefix, range entirely within the other's range), won't break the matching process.) I don't think this change drastically affects the ROA, and in most cases I would expect length == minLength to be the case. However, in the few instances where it doesn't hold true, this would be a saving grace, and valuable enough (IMHO) to warrant discussion. Brian Dickson _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Mon Oct 6 16:46:27 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 86E4A28C10D; Mon, 6 Oct 2008 16:46:27 -0700 (PDT) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5B36628C10D for ; Mon, 6 Oct 2008 16:46:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jQB1xBvuVmHH for ; Mon, 6 Oct 2008 16:46:25 -0700 (PDT) Received: from mint.apnic.net (mint.apnic.net [202.12.29.58]) by core3.amsl.com (Postfix) with ESMTP id 7F6B13A6804 for ; Mon, 6 Oct 2008 16:46:25 -0700 (PDT) Received: from dhcp228.apnic.net (dhcp228.apnic.net [202.12.29.228]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mint.apnic.net (Postfix) with ESMTP id 5E7A1D5F2D; Tue, 7 Oct 2008 09:46:28 +1000 (EST) Message-Id: <617B6455-1509-4847-A58E-A59974450687@apnic.net> From: George Michaelson To: Randy Bush In-Reply-To: <48EAA257.7010301@psg.com> Mime-Version: 1.0 (Apple Message framework v929.2) Date: Tue, 7 Oct 2008 09:46:27 +1000 References: <48EA0A7D.5070508@psg.com> <20081006230832.133E92282B@thrintun.hactrn.net> <48EAA257.7010301@psg.com> X-Mailer: Apple Mail (2.929.2) Cc: sidr@ietf.org Subject: Re: [sidr] multiply signed roas are useless X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org Randy, all our objects are now defined in terms of CMS. CMS defines a multiple sign model. Its integral to the definition of CMS. If we defined a multiple sign model for our data objects now, then we effectively future proof the design against any emergent need to have multiple sign over objects to validate them for RFC3779. This is a remarkably low barrier right now, in a world of single sign. it is designing a data model to encompass a potential future need. I do not believe one implementors view on optimal processing defines the scalability of multiple signer checking: for instance, a DB centric model would have no particular problem locating the set of direct signers, and in a pre-validated certificate hierarchy, (ie the covering trees for each certificate already being known) the edge- validation of the object by the EE certificates which signed it, which can be validated against the DB seems to me to be scaleable. -George _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Mon Oct 6 17:18:48 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4B72D3A6B52; Mon, 6 Oct 2008 17:18:48 -0700 (PDT) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 823A63A6B52 for ; Mon, 6 Oct 2008 17:18:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IHgAyBUlLRQo for ; Mon, 6 Oct 2008 17:18:46 -0700 (PDT) Received: from mint.apnic.net (mint.apnic.net [202.12.29.58]) by core3.amsl.com (Postfix) with ESMTP id 5C5893A6B51 for ; Mon, 6 Oct 2008 17:18:46 -0700 (PDT) Received: from dhcp076.yarralumla.aarnet.edu.au (dhcp076.yarralumla.aarnet.edu.au [192.94.63.76]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mint.apnic.net (Postfix) with ESMTP id 27E13D5F2D for ; Tue, 7 Oct 2008 10:19:23 +1000 (EST) Message-Id: <62698B4A-8D14-4E38-856F-55EAB4435BCC@apnic.net> From: Geoff Huston To: sidr@ietf.org In-Reply-To: <48EAA257.7010301@psg.com> Mime-Version: 1.0 (Apple Message framework v929.2) Date: Tue, 7 Oct 2008 11:19:22 +1100 References: <48EA0A7D.5070508@psg.com> <20081006230832.133E92282B@thrintun.hactrn.net> <48EAA257.7010301@psg.com> X-Mailer: Apple Mail (2.929.2) Subject: Re: [sidr] Resolving the issues in the roa-format draft X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org WG Chair hat off: On 07/10/2008, at 10:42 AM, Randy Bush wrote: > it is not necessary. it is not operationally useful. it adds > complexity to a security application. > > is there a netowrk operator here who really needs it? > > and we have already heard from the major open source full system > implementor, who does not plan to add it. > As I understand the substance of this post, the comment has been raised (again) that this is an unlikely situation and there is no need to make the specification more complex for unlikely cases. In response I would argue (again) that the specification should be complete and provide appropriate guidance to implementors for all situations where interoperability is required, and this case, although not common, has been visible in the routing table already and will likely be visible in the routing table in future. Given that this does not define a new signature standard for CMS, nor a major change in the logic of ROA processing I do not see that this adds any undue complexity to implementations and has the benefit of covering the full range of anticipated use cases for ROAs in their application to signing route origination. But I've said all this already, so nothing new from me either yet. In a (possibly futile) effort to break out of this cycle of mindless repetition, here's a further contribution looking at what text would change in the ROA specification draft-ietf-sidr-roa-format to allow this proposed resolution to the issue: section 2.1.4 ...the end entity certificate(s) needed to validate this ROA. section 3 step 1 d. ... contains one or more EE certificates, where each EE certificate's Subject Key Identifier (SKi) matches the sid field of one instance of the SignerInfo object. section 3 step 2 ... in each EE certificate ... section 3 step 3 ... and that the union of the IP address prefix(es) in the EE certificate(s) extension(s) encompass the Ip address prefix(es) in the ROA. section 3 step 4 ... that each EE certificate is... section 3 Remove the sentences starting with "Note that ..." and "Indeed, since ..." section 4 ... are encompassed by those in thge address space extension(s) in the EE certificate(s) used to sign the ROA. Geoff _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Mon Oct 6 17:20:56 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 759C53A6B51; Mon, 6 Oct 2008 17:20:56 -0700 (PDT) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 16A313A6B35 for ; Mon, 6 Oct 2008 17:20:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GxBdswnnenco for ; Mon, 6 Oct 2008 17:20:54 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by core3.amsl.com (Postfix) with ESMTP id 373823A6B51 for ; Mon, 6 Oct 2008 17:20:54 -0700 (PDT) Received: from c-71-193-199-226.hsd1.or.comcast.net ([71.193.199.226] helo=rmac.psg.com) by ran.psg.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Kn0KQ-000Myy-58; Tue, 07 Oct 2008 00:21:30 +0000 Message-ID: <48EAAB89.9000001@psg.com> Date: Mon, 06 Oct 2008 17:21:29 -0700 From: Randy Bush User-Agent: Thunderbird 2.0.0.17 (Macintosh/20080914) MIME-Version: 1.0 To: Geoff Huston References: <48EA0A7D.5070508@psg.com> <20081006230832.133E92282B@thrintun.hactrn.net> <48EAA257.7010301@psg.com> <62698B4A-8D14-4E38-856F-55EAB4435BCC@apnic.net> In-Reply-To: <62698B4A-8D14-4E38-856F-55EAB4435BCC@apnic.net> X-Enigmail-Version: 0.95.7 Cc: sidr@ietf.org Subject: Re: [sidr] Resolving the issues in the roa-format draft X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org > In response I would argue (again) that the specification should be > complete and provide appropriate guidance to implementors for all > situations where interoperability is required, boiling the ocean. > and this case, although not common, has been visible in the routing > table already oh? and how do you detect it? how many are there? how much of a real problem is it? randy _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Mon Oct 6 19:22:43 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 826DD3A6831; Mon, 6 Oct 2008 19:22:43 -0700 (PDT) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8AB203A6831 for ; Mon, 6 Oct 2008 19:22:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CBFtm0SjZrAk for ; Mon, 6 Oct 2008 19:22:40 -0700 (PDT) Received: from cyteen.hactrn.net (cyteen.hactrn.net [IPv6:2002:425c:4242:0:210:5aff:fe86:1f54]) by core3.amsl.com (Postfix) with ESMTP id 8C0403A635F for ; Mon, 6 Oct 2008 19:22:40 -0700 (PDT) Received: from thrintun.hactrn.net (thrintun.hactrn.net [IPv6:2002:425c:4242:0:219:d1ff:fe12:5d30]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "thrintun.hactrn.net", Issuer "Grunchweather Associates" (verified OK)) by cyteen.hactrn.net (Postfix) with ESMTPS id BF1C128445 for ; Tue, 7 Oct 2008 02:23:14 +0000 (UTC) Received: from thrintun.hactrn.net (localhost [IPv6:::1]) by thrintun.hactrn.net (Postfix) with ESMTP id 7BE792282B for ; Mon, 6 Oct 2008 22:23:14 -0400 (EDT) Date: Mon, 06 Oct 2008 22:23:14 -0400 From: Rob Austein To: sidr@ietf.org In-Reply-To: References: <48EA0A7D.5070508@psg.com> <20081006230832.133E92282B@thrintun.hactrn.net> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Message-Id: <20081007022314.7BE792282B@thrintun.hactrn.net> Subject: Re: [sidr] Resolving the issues in the roa-format draft X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org I look forward to reading your code, Geoff. The process of retrieving and checking an RPKI tree is already a fairly complex recursive tree walk with many fiddly checks that have to be done in the right order to avoid various attack scenarios. The last thing this traversal algorithm needs is a gratuitous requirement that at each ROA it finds it must be prepared to go haring off after an arbitrarily large number of new certificate chains in different parts of the tree on a pointless quest to solve a non-problem. Do you have ANY evidence whatsoever for compelling real world cases? Don't talk theory. Show me a real case where this would matter. _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Mon Oct 6 19:32:56 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B86673A6B1B; Mon, 6 Oct 2008 19:32:56 -0700 (PDT) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A51673A6B1B for ; Mon, 6 Oct 2008 19:32:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xdi64wLGKqx0 for ; Mon, 6 Oct 2008 19:32:54 -0700 (PDT) Received: from mint.apnic.net (mint.apnic.net [202.12.29.58]) by core3.amsl.com (Postfix) with ESMTP id 7605B3A6AD9 for ; Mon, 6 Oct 2008 19:32:54 -0700 (PDT) Received: from dhcp228.apnic.net (dhcp228.apnic.net [202.12.29.228]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mint.apnic.net (Postfix) with ESMTP id CB438D5F2D; Tue, 7 Oct 2008 12:33:31 +1000 (EST) Message-Id: <2D30DC8B-1D75-4E9A-87C7-6F22615AAA25@apnic.net> From: George Michaelson To: Rob Austein In-Reply-To: <20081007022314.7BE792282B@thrintun.hactrn.net> Mime-Version: 1.0 (Apple Message framework v929.2) Date: Tue, 7 Oct 2008 12:33:31 +1000 References: <48EA0A7D.5070508@psg.com> <20081006230832.133E92282B@thrintun.hactrn.net> <20081007022314.7BE792282B@thrintun.hactrn.net> X-Mailer: Apple Mail (2.929.2) Cc: sidr@ietf.org Subject: Re: [sidr] Resolving the issues in the roa-format draft X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org clearly, I am not Geoff. But in any case, I don't understand why you only analyze the costs of this test in the context of complete chain-validation tests, validating signed objects. Why can you not test signed objects and the EE certificates against a *pre-validated* information structure for the hierarchy, and so only have to test the EE cert, and object validation at one level, instead of completely to the root? what am I mis-understanding about end-sign validation? I don't believe at this time that any multi-sign outcomes would exist except at the edge: end-entity objects. so I don't see why an entire tree-validation is needed, if you have a pre-validated repository of known good certificate chains. The end- entity certs, the signed objects, surely the validation is far simpler than you imply? On 07/10/2008, at 12:23 PM, Rob Austein wrote: > I look forward to reading your code, Geoff. > > The process of retrieving and checking an RPKI tree is already a > fairly complex recursive tree walk with many fiddly checks that have > to be done in the right order to avoid various attack scenarios. The > last thing this traversal algorithm needs is a gratuitous requirement > that at each ROA it finds it must be prepared to go haring off after > an arbitrarily large number of new certificate chains in different > parts of the tree on a pointless quest to solve a non-problem. > > Do you have ANY evidence whatsoever for compelling real world cases? post rundown, the likelihood that resources do not compress simply to single certificate chains seems to me a likely scenario. ie, people will be holding large sets of dis-aggregated resources, and need to assert route validation over them effectively. if they do this as a set of disjoint end objects you move validation costs to a simpler process per object, that then has to be (re)combined to make the real information you need. If we can find a way to make multi-sign work, there could be significantly less objects in play, in the system as a whole. Rob, I don't mean to be dis-respectful, but I find the vehemance "this can't work: its too expensive" over-stated. I don't buy it. I think you're at risk of entrenching a view that is as equally shakey as my belief multi-sign may turn out to be needed. > > Don't talk theory. Show me a real case where this would matter. Its hard for anyone to do that in a world where no routing security exists. But I am tempted to observe that in the WG discussions we seemed to be confident the *intended* security model in respect of IRR demanded more than one participant sign information to validate the relationship between AS in routing, and prefix being routed. (I do not mean ROA here, I am talking about things beyond the ROA. So I have moved the agenda sideways) I know that others believe this is irrelevant, but I still see it documented in the RFCs and in the actual code which implements checks on who authorizes updates in WHOIS.. cheers -George > > _______________________________________________ > 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 sidr-bounces@ietf.org Mon Oct 6 20:14:25 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 88E493A6AD7; Mon, 6 Oct 2008 20:14:25 -0700 (PDT) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E9BA93A68C4 for ; Mon, 6 Oct 2008 20:14:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.922 X-Spam-Level: X-Spam-Status: No, score=-2.922 tagged_above=-999 required=5 tests=[AWL=-0.323, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HqjMUAgYfN6i for ; Mon, 6 Oct 2008 20:14:24 -0700 (PDT) Received: from fk-out-0910.google.com (fk-out-0910.google.com [209.85.128.189]) by core3.amsl.com (Postfix) with ESMTP id 8F05F3A6AD7 for ; Mon, 6 Oct 2008 20:14:23 -0700 (PDT) Received: by fk-out-0910.google.com with SMTP id 18so2576580fkq.5 for ; Mon, 06 Oct 2008 20:15:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=JXvXIcmscK0buEYXO6BVdxO52b9PamFrlQxqN9N9Ii8=; b=mru6AVhJqexUqsSH4ZLvF5bV5EySIQRiHeDMtPfHq0ojynq5UZGHEBiqQDkvxv1C6V Ob2UXWbf1R1rg712h1xYR/vJUNCnAcvQUu5VF7ERR5NKAWb91e2BOMHPpSDxMSZsxuUt KwUQImKztGtUYcoDA86POhJX4xrIh2djSvzmU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=KWzfRbRzjdQTz1ZVSU/UiexAhxLQa2A2nSoL0/eRegc1PpvawFM59EofAL+FjBpD1y LyH+tjU+DPUS48drzw+4IxjyLsGo05vn+b//whzpUXbF2z4RdGCEAhU/rG5gTOHyaubU HNPgsYGQa5aPHztsQlMLEfH1deuJvFhlJFgqw= Received: by 10.180.255.1 with SMTP id c1mr4378901bki.23.1223349300803; Mon, 06 Oct 2008 20:15:00 -0700 (PDT) Received: by 10.180.226.2 with HTTP; Mon, 6 Oct 2008 20:15:00 -0700 (PDT) Message-ID: <77ead0ec0810062015y71d2ddb0lc2a4c6c59aa09a7e@mail.gmail.com> Date: Tue, 7 Oct 2008 14:15:00 +1100 From: "Vishwas Manral" To: "George Michaelson" In-Reply-To: <2D30DC8B-1D75-4E9A-87C7-6F22615AAA25@apnic.net> MIME-Version: 1.0 Content-Disposition: inline References: <48EA0A7D.5070508@psg.com> <20081006230832.133E92282B@thrintun.hactrn.net> <20081007022314.7BE792282B@thrintun.hactrn.net> <2D30DC8B-1D75-4E9A-87C7-6F22615AAA25@apnic.net> Cc: Rob Austein , sidr@ietf.org Subject: Re: [sidr] Resolving the issues in the roa-format draft X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org Hi Rob/ George, I had raised issues about SIDR and we had a long healthy discussion on it in February on the SIDR as well as the OPSEC lists. I had written a draft too but I guess it did not get promoted enough. Do have a look at : www.archivum.info/idr@ietf.org/2008-02/msg00035.html and let me know what you think about the ideas of the draft. Thanks, Vishwas On 10/7/08, George Michaelson wrote: > clearly, I am not Geoff. > > But in any case, I don't understand why you only analyze the costs of > this test in the context of complete chain-validation tests, > validating signed objects. > > Why can you not test signed objects and the EE certificates against a > *pre-validated* information structure for the hierarchy, and so only > have to test the EE cert, and object validation at one level, instead > of completely to the root? > > what am I mis-understanding about end-sign validation? > > I don't believe at this time that any multi-sign outcomes would exist > except at the edge: end-entity objects. > > so I don't see why an entire tree-validation is needed, if you have a > pre-validated repository of known good certificate chains. The end- > entity certs, the signed objects, surely the validation is far simpler > than you imply? > > On 07/10/2008, at 12:23 PM, Rob Austein wrote: > >> I look forward to reading your code, Geoff. >> >> The process of retrieving and checking an RPKI tree is already a >> fairly complex recursive tree walk with many fiddly checks that have >> to be done in the right order to avoid various attack scenarios. The >> last thing this traversal algorithm needs is a gratuitous requirement >> that at each ROA it finds it must be prepared to go haring off after >> an arbitrarily large number of new certificate chains in different >> parts of the tree on a pointless quest to solve a non-problem. >> >> Do you have ANY evidence whatsoever for compelling real world cases? > > post rundown, the likelihood that resources do not compress simply to > single certificate chains seems to me a likely scenario. ie, people > will be holding large sets of dis-aggregated resources, and need to > assert route validation over them effectively. > > if they do this as a set of disjoint end objects you move validation > costs to a simpler process per object, that then has to be > (re)combined to make the real information you need. > > If we can find a way to make multi-sign work, there could be > significantly less objects in play, in the system as a whole. > > Rob, I don't mean to be dis-respectful, but I find the vehemance "this > can't work: its too expensive" over-stated. I don't buy it. I think > you're at risk of entrenching a view that is as equally shakey as my > belief multi-sign may turn out to be needed. > >> >> Don't talk theory. Show me a real case where this would matter. > > Its hard for anyone to do that in a world where no routing security > exists. But I am tempted to observe that in the WG discussions we > seemed to be confident the *intended* security model in respect of IRR > demanded more than one participant sign information to validate the > relationship between AS in routing, and prefix being routed. (I do not > mean ROA here, I am talking about things beyond the ROA. So I have > moved the agenda sideways) > > I know that others believe this is irrelevant, but I still see it > documented in the RFCs and in the actual code which implements checks > on who authorizes updates in WHOIS.. > > cheers > > -George > >> >> _______________________________________________ >> 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 sidr-bounces@ietf.org Mon Oct 6 20:24:14 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C76B73A6B33; Mon, 6 Oct 2008 20:24:14 -0700 (PDT) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 129E03A6971 for ; Mon, 6 Oct 2008 20:24:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5JSD+R1urhR9 for ; Mon, 6 Oct 2008 20:24:13 -0700 (PDT) Received: from cyteen.hactrn.net (cyteen.hactrn.net [IPv6:2002:425c:4242:0:210:5aff:fe86:1f54]) by core3.amsl.com (Postfix) with ESMTP id 2BD283A6B3A for ; Mon, 6 Oct 2008 20:24:13 -0700 (PDT) Received: from thrintun.hactrn.net (thrintun.hactrn.net [IPv6:2002:425c:4242:0:219:d1ff:fe12:5d30]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "thrintun.hactrn.net", Issuer "Grunchweather Associates" (verified OK)) by cyteen.hactrn.net (Postfix) with ESMTPS id 4B20C2844C for ; Tue, 7 Oct 2008 03:24:47 +0000 (UTC) Received: from thrintun.hactrn.net (localhost [IPv6:::1]) by thrintun.hactrn.net (Postfix) with ESMTP id 076442282B for ; Mon, 6 Oct 2008 23:24:47 -0400 (EDT) Date: Mon, 06 Oct 2008 23:24:47 -0400 From: Rob Austein To: sidr@ietf.org In-Reply-To: <77ead0ec0810062015y71d2ddb0lc2a4c6c59aa09a7e@mail.gmail.com> References: <48EA0A7D.5070508@psg.com> <20081006230832.133E92282B@thrintun.hactrn.net> <20081007022314.7BE792282B@thrintun.hactrn.net> <2D30DC8B-1D75-4E9A-87C7-6F22615AAA25@apnic.net> <77ead0ec0810062015y71d2ddb0lc2a4c6c59aa09a7e@mail.gmail.com> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Message-Id: <20081007032447.076442282B@thrintun.hactrn.net> Subject: Re: [sidr] Resolving the issues in the roa-format draft X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org At Tue, 7 Oct 2008 14:15:00 +1100, Vishwas Manral wrote: > > www.archivum.info/idr@ietf.org/2008-02/msg00035.html and let me know > what you think about the ideas of the draft. No offense, but I see no relevance to the topic at hand. _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Mon Oct 6 20:32:39 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3C82F3A6A28; Mon, 6 Oct 2008 20:32:39 -0700 (PDT) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A3DDC3A6848 for ; Mon, 6 Oct 2008 20:32:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wBWQHubAluTX for ; Mon, 6 Oct 2008 20:32:35 -0700 (PDT) Received: from mint.apnic.net (mint.apnic.net [202.12.29.58]) by core3.amsl.com (Postfix) with ESMTP id D20893A6A28 for ; Mon, 6 Oct 2008 20:32:34 -0700 (PDT) Received: from dhcp076.yarralumla.aarnet.edu.au (dhcp076.yarralumla.aarnet.edu.au [192.94.63.76]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mint.apnic.net (Postfix) with ESMTP id 5BC99D5F2D for ; Tue, 7 Oct 2008 13:33:12 +1000 (EST) Message-Id: <1459E8F5-0B6E-483A-94F7-569C64532194@apnic.net> From: Geoff Huston To: sidr@ietf.org In-Reply-To: <20081007022314.7BE792282B@thrintun.hactrn.net> Mime-Version: 1.0 (Apple Message framework v929.2) Date: Tue, 7 Oct 2008 14:33:11 +1100 References: <48EA0A7D.5070508@psg.com> <20081006230832.133E92282B@thrintun.hactrn.net> <20081007022314.7BE792282B@thrintun.hactrn.net> X-Mailer: Apple Mail (2.929.2) Subject: Re: [sidr] Resolving the issues in the roa-format draft X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org WG char hat off On 07/10/2008, at 1:23 PM, Rob Austein wrote: > > The process of retrieving and checking an RPKI tree is already a > fairly complex recursive tree walk with many fiddly checks that have > to be done in the right order to avoid various attack scenarios. The > last thing this traversal algorithm needs is a gratuitous requirement > that at each ROA it finds it must be prepared to go haring off after > an arbitrarily large number of new certificate chains in different > parts of the tree on a pointless quest to solve a non-problem. What I understand from your posting is that this makes ROA validation horrendously complex. An algorithm that attempts to validate everything at a repository publication point before moving on to the next repository publication point will have problems with any form of multi-signed object. On the other hand an algorithm that validates certificates (and CRLs) in a first pass and signed objects in a second pass would not encounter the same problems, as the collection of ee certificates required to validate the multisigned object would be already validated in the first pass. So is what I'm hearing here from your posting: "I implemented it one way and if the draft is changed then my code will need to change, and I really don't want to do that, therefore I'm opposed to any change in the draft"? But in that case there is a problem here for this type of algorithm in validating any form of multi-signed object, not just ROAs. What about proxy aggregation in BGP? How can one validate any element that is constructed from a set of components other than by multo- signed objects? How are those multi-signed objects to be validated? What about if one wanted to implement the RPSS security framework where the analogous security mechanism to the Route Object is that the AS holder and the prefix holder sign the route object? How are those multi-signed objects to be validated? What about an AS adjacency attestation that is signed by both AS's? How are those multi-signed objects to be validated? What about a generic form of AS Path validation where the credentials are progressively signed by the sequence of AS's? How are those multi- signed objects to be validated? Is what you are really voicing here an opposition to any form of multiple RPKI signatures being placed on any signed object within this framework? If that's the case I _personally_ see that as a very short- sighted limitation, a I for one see multiple signatures in the RPKI as being a valuable attribute in the long run in terms of the flexibility of the PKI to suit a broad as possible number of potential areas of application including BGP itself. Geoff _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Mon Oct 6 21:07:22 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7BE173A684D; Mon, 6 Oct 2008 21:07:22 -0700 (PDT) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C9E773A682B for ; Mon, 6 Oct 2008 21:07:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eBBjcPEqqZCx for ; Mon, 6 Oct 2008 21:07:19 -0700 (PDT) Received: from mint.apnic.net (mint.apnic.net [202.12.29.58]) by core3.amsl.com (Postfix) with ESMTP id 49EB53A68C4 for ; Mon, 6 Oct 2008 21:07:19 -0700 (PDT) Received: from dhcp076.yarralumla.aarnet.edu.au (dhcp076.yarralumla.aarnet.edu.au [192.94.63.76]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mint.apnic.net (Postfix) with ESMTP id 5EE38D5F31; Tue, 7 Oct 2008 14:07:56 +1000 (EST) Message-Id: <859922F7-7136-4ECA-BB42-642603EFFC11@apnic.net> From: Geoff Huston To: Vishwas Manral In-Reply-To: <77ead0ec0810062015y71d2ddb0lc2a4c6c59aa09a7e@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v929.2) Date: Tue, 7 Oct 2008 15:07:55 +1100 References: <48EA0A7D.5070508@psg.com> <20081006230832.133E92282B@thrintun.hactrn.net> <20081007022314.7BE792282B@thrintun.hactrn.net> <2D30DC8B-1D75-4E9A-87C7-6F22615AAA25@apnic.net> <77ead0ec0810062015y71d2ddb0lc2a4c6c59aa09a7e@mail.gmail.com> X-Mailer: Apple Mail (2.929.2) Cc: sidr@ietf.org Subject: Re: [sidr] Resolving the issues in the roa-format draft X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org On 07/10/2008, at 2:15 PM, Vishwas Manral wrote: > I had raised issues about SIDR and we had a long healthy discussion on > it in February on the SIDR as well as the OPSEC lists. > > I had written a draft too but I guess it did not get promoted enough. > Do have a look at : > > www.archivum.info/idr@ietf.org/2008-02/msg00035.html and let me know > what you think about the ideas of the draft. > > Thanks, > Vishwas WG Chair HAT *ON* Vishwas, Thanks for your pointer and the reference you the draft you had written earlier this year. The charter of the SIDR working group (http://www.ietf.org/html.charters/sidr-charter.html ) includes the following: "Document specific routing functionality modules within this architecture that are designed to address specific secure routing requirements as they are determined by the RPSEC Working Group" To date, the RPSEC Working Group has concluded that securing the origination of routing advertisements IS a secure routing requirement, and on that basis the SIDR Working Group has been working on mechanisms that will allow the origination of route objects to be secured. The work on ROAs in precisely focused on this requirement. The comments you reference, and the draft you cite, appear to point to a requirement relating to AS path security, and the specification of mechanisms that would allow relying parties to detect efforts by third parties to place false information into the AS Path of a routing advertisement. This precise nature of this requirement has been the subject of an extended study in the RPSEC Working Group, and the precise security requirements arising from that study are still somewhat unclear at the moment. I refer you to the RPSEC Working Group and its drafts and mailing list archives for more details on this study. At this stage it is my understanding, as a co-chair of the SIDR Working Group, that the general subject of AS Path validation has not yet been passed over to SIDR as a well-defined security requirement from the RPSEC Working Group, or from the Area Director in the form of a revised charter for this Working Group. At some stage its likely that this will be part of the SIDR WG activities, and your contributions regarding effective and secure mechanism to safeguard the AS Path from various forms of unauthorized alteration would be welcome. However, before you brush up your previous draft and resubmit it, you may find some broad background reading on this topic to be helpful to your contribution, as the topic of securing the inter-domain routing system is one that has been the subject of a considerable number of research and operational papers as well as the subject of various efforts in the IETF and elsewhere over the past decade or so. kind regards, Geoff Huston This time speaking as the co-chair of this Working Group _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Mon Oct 6 22:32:45 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5B61A3A69D3; Mon, 6 Oct 2008 22:32:45 -0700 (PDT) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CF0743A6953 for ; Mon, 6 Oct 2008 22:32:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2r1PBPE6P0Im for ; Mon, 6 Oct 2008 22:32:43 -0700 (PDT) Received: from mint.apnic.net (mint.apnic.net [202.12.29.58]) by core3.amsl.com (Postfix) with ESMTP id 04B8A3A691C for ; Mon, 6 Oct 2008 22:32:41 -0700 (PDT) Received: from dhcp076.yarralumla.aarnet.edu.au (dhcp076.yarralumla.aarnet.edu.au [192.94.63.76]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mint.apnic.net (Postfix) with ESMTP id C7CBAD5F2D; Tue, 7 Oct 2008 15:33:18 +1000 (EST) Message-Id: <7D283111-5FAC-450F-8F15-18139A89F8C8@apnic.net> From: Geoff Huston To: Brian Dickson In-Reply-To: <48EAA23F.6030609@ca.afilias.info> Mime-Version: 1.0 (Apple Message framework v929.2) Date: Tue, 7 Oct 2008 16:33:17 +1100 References: <513C369E-B21F-42CE-A721-61C258DC15D7@apnic.net> <48EAA23F.6030609@ca.afilias.info> X-Mailer: Apple Mail (2.929.2) Cc: sidr@ietf.org Subject: Re: [sidr] Resolving the issues in the roa-format draft X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org WG Chair hat _OFF_ On 07/10/2008, at 10:41 AM, Brian Dickson wrote: > > Rather than having: > > IP_address / length le maxLength (length <= maxLength <= > address-family-max-length) > > this would be > > IP_address / length ge minLength le maxLength (length <= minLength > <= maxLength <= address-family-max-length) > Its isomorphic in one sense isn't it? The described representation lists the prefixes in the maximally permitted aggregate format and by the optional MaxLength parameter which specifies the finest level of more specifics that could be originated from this ROA. Your suggested representation allows a number of aggregatable prefixes to be aggregated as a described prefix, as long as they share a common minLength value. _personally_ I'm unsure that this alternate representation would offer any superior flexibility in the representation of ROAs. Geoff _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Mon Oct 6 23:24:00 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 20E673A67F7; Mon, 6 Oct 2008 23:24:00 -0700 (PDT) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3EC193A67F7 for ; Mon, 6 Oct 2008 23:23:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZJy10Dad8nkv for ; Mon, 6 Oct 2008 23:23:58 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by core3.amsl.com (Postfix) with ESMTP id 52F473A63D3 for ; Mon, 6 Oct 2008 23:23:58 -0700 (PDT) Received: from ip192.186.dsl-acs2.seawa0.iinet.com ([209.20.186.192] helo=rmac.psg.com) by ran.psg.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Kn5zj-000O3j-Vy; Tue, 07 Oct 2008 06:24:32 +0000 Message-ID: <48EB009F.9010701@psg.com> Date: Mon, 06 Oct 2008 23:24:31 -0700 From: Randy Bush User-Agent: Thunderbird 2.0.0.17 (Macintosh/20080914) MIME-Version: 1.0 To: Geoff Huston References: <48EA0A7D.5070508@psg.com> <20081006230832.133E92282B@thrintun.hactrn.net> <48EAA257.7010301@psg.com> <62698B4A-8D14-4E38-856F-55EAB4435BCC@apnic.net> <48EAAB89.9000001@psg.com> In-Reply-To: <48EAAB89.9000001@psg.com> X-Enigmail-Version: 0.95.7 Cc: sidr@ietf.org Subject: Re: [sidr] Resolving the issues in the roa-format draft X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org Geoff: >> and this case, although not common, has been visible in the routing >> table already Randy: > oh? and how do you detect it? how many are there? how much of a real > problem is it? so i had a three hour drive from seeing kids in portland to the exciting westin colo in seattle. i did not even make it through the neil young on my ipod. but i kept thinking of how one could test or demonstrate your assertion. perhaps neil scrambled my thinking, but it did not even get to winterlude. for each prefix in some routing table, rv, dump of one of my routers, whatever, see if that prefix can be decomposed into two or more prefixes which one can demonstrate are 'given' to the announcing asn by two or more different would-be certificate authoritiess, e.g. rirs or disparate delegatees of rirs. i could not really see how to do this for other than the case where the prefix can be shown to be in the delegation registries of two rirs. please give us one example which supports your assertion, or whack me with a clue by four about how one could better test/demonstrate your assertion. randy _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Mon Oct 6 23:32:42 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A04163A688E; Mon, 6 Oct 2008 23:32:42 -0700 (PDT) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8BEB13A688E for ; Mon, 6 Oct 2008 23:32:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.965 X-Spam-Level: X-Spam-Status: No, score=-5.965 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_91=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VG1F-W+MawQQ for ; Mon, 6 Oct 2008 23:32:40 -0700 (PDT) Received: from outbound.afilias.info (outbound.afilias.info [69.46.124.26]) by core3.amsl.com (Postfix) with ESMTP id 72CEB3A6883 for ; Mon, 6 Oct 2008 23:32:40 -0700 (PDT) Received: from bmp-336-ms506.wa.yyz2.afilias-ops.info ([10.50.129.112] helo=smtp.afilias.info) by outbound.afilias.info with esmtp (Exim 4.69) (envelope-from ) id 1Kn689-0005AF-4C; Tue, 07 Oct 2008 06:33:13 +0000 Message-ID: <48EB02AC.60503@ca.afilias.info> Date: Tue, 07 Oct 2008 02:33:16 -0400 From: Brian Dickson User-Agent: Thunderbird 2.0.0.17 (Macintosh/20080914) MIME-Version: 1.0 To: Geoff Huston References: <513C369E-B21F-42CE-A721-61C258DC15D7@apnic.net> <48EAA23F.6030609@ca.afilias.info> <7D283111-5FAC-450F-8F15-18139A89F8C8@apnic.net> In-Reply-To: <7D283111-5FAC-450F-8F15-18139A89F8C8@apnic.net> X-Authenticated: True Cc: sidr@ietf.org Subject: Re: [sidr] Resolving the issues in the roa-format draft X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org Geoff Huston wrote: > WG Chair hat _OFF_ > > On 07/10/2008, at 10:41 AM, Brian Dickson wrote: > >> >> Rather than having: >> >> IP_address / length le maxLength (length <= maxLength <= >> address-family-max-length) >> >> this would be >> >> IP_address / length ge minLength le maxLength (length <= minLength >> <= maxLength <= address-family-max-length) >> > > Its isomorphic in one sense isn't it? The described representation > lists the prefixes in the maximally permitted aggregate format and by > the optional MaxLength parameter which specifies the finest level of > more specifics that could be originated from this ROA. Your suggested > representation allows a number of aggregatable prefixes to be > aggregated as a described prefix, as long as they share a common > minLength value. > > _personally_ I'm unsure that this alternate representation would offer > any superior flexibility in the representation of ROAs. I'm not sure if any or all of these kinds of use cases are appropriate, but if any of them are, they may serve to demonstrate the compactness achievable with this representation. Examples: RIR->LIR, RIR has certain specific policies it wishes to enforce regarding LIR assignments to end-users -- anything bigger than /X requires justification (i.e. approval) and registration (i.e. ROA). Either RIR has to create a large swath of ROAs, each of size /X, or it can create one ROA with minLength=X. (In this example, maxLength is irrelevant and presumed identical.) Exceptions are needed, of course, for /Y (Y < X), but each of these can be done with separate ROAs. Even as a worst case scenario, no *more* ROAs are needed than in the original case. In a best case scenario, many orders of magnitude quantity of ROAs need never be created, and RIR's policies are enforced directly via ROAs. LIR->PA customers, LIR wants to aggregate but also wants to ensure no customers are able to punch holes in the PA space. LIR restricts the minLength to something not globally routable (e.g. /25 in IPv4, /49 in IPv6). This ties the customer to the LIR, by preventing PA blocks being announced via third parties (hole punching). One ROA can be assigned, whether the amount of space is small or large. Internal aggregation by the PA customer is limited, of course, but that is the intention of the LIR. There may be other cases that I'm missing, but which others may see, based on the above examples. Things related to IPv6 nibble boundaries (for ip6.arpa reasons) but where the current use is only a portion of the larger (reserved) block; ROAs with differing minLength can be created as the customer grows, providing a viable path with no "flag day" needed. It is certainly no worse than the previous representation, as it is strictly a superset. The main question, IMHO, is, does it add sufficient value to justify making the change? (I think it's the only question, actually.) Brian _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Mon Oct 6 23:47:43 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0CC803A6778; Mon, 6 Oct 2008 23:47:43 -0700 (PDT) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A8B523A6778 for ; Mon, 6 Oct 2008 23:47:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.222 X-Spam-Level: X-Spam-Status: No, score=-6.222 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A7wKXpPdCoex for ; Mon, 6 Oct 2008 23:47:40 -0700 (PDT) Received: from outbound.afilias.info (outbound.afilias.info [69.46.124.26]) by core3.amsl.com (Postfix) with ESMTP id B52C23A63D3 for ; Mon, 6 Oct 2008 23:47:40 -0700 (PDT) Received: from bmp-336-ms505.wa.yyz2.afilias-ops.info ([10.50.129.111] helo=smtp.afilias.info) by outbound.afilias.info with esmtp (Exim 4.69) (envelope-from ) id 1Kn6Md-0005SK-4W; Tue, 07 Oct 2008 06:48:11 +0000 Message-ID: <48EB062E.6090808@ca.afilias.info> Date: Tue, 07 Oct 2008 02:48:14 -0400 From: Brian Dickson User-Agent: Thunderbird 2.0.0.17 (Macintosh/20080914) MIME-Version: 1.0 To: Randy Bush References: <48EA0A7D.5070508@psg.com> <20081006230832.133E92282B@thrintun.hactrn.net> <48EAA257.7010301@psg.com> <62698B4A-8D14-4E38-856F-55EAB4435BCC@apnic.net> <48EAAB89.9000001@psg.com> <48EB009F.9010701@psg.com> In-Reply-To: <48EB009F.9010701@psg.com> X-Authenticated: True Cc: sidr@ietf.org Subject: Re: [sidr] Resolving the issues in the roa-format draft X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org Randy Bush wrote: > Geoff: > >>> and this case, although not common, has been visible in the routing >>> table already >>> > Randy: > >> oh? and how do you detect it? how many are there? how much of a real >> problem is it? >> > > so i had a three hour drive from seeing kids in portland to the exciting > westin colo in seattle. i did not even make it through the neil young > on my ipod. but i kept thinking of how one could test or demonstrate > your assertion. perhaps neil scrambled my thinking, but it did not even > get to winterlude. > > for each prefix in some routing table, rv, dump of one of my routers, > whatever, see if that prefix can be decomposed into two or more prefixes > which one can demonstrate are 'given' to the announcing asn by two or > more different would-be certificate authoritiess, e.g. rirs or disparate > delegatees of rirs. > > i could not really see how to do this for other than the case where the > prefix can be shown to be in the delegation registries of two rirs. > > please give us one example which supports your assertion, or whack me > with a clue by four about how one could better test/demonstrate your > assertion. > Let me ask Geoff about the specific kinds of scenarios, to simplify things a bit. (I'm curious, too.) Would the visible examples be adjacent prefixes (suitable for aggregation) originated by one specific ASN? Or, would the visible examples be adjacent prefixes from two ASNs, being *proxy* aggregated by a third ASN? Or some other variation involving one or two ASNs? Try as I might, I am unable to figure out any way to split a block more than one way. And for two blocks to be able to be aggregated (without covering other prefixes, i.e. not a proxy aggregate for any third parties), they have to be adjacent. Which means the two entities giving those blocks, would have to give the *whole* block (in both cases) to the recipient, with nothing left over for the giver or the giver's other customers. A=CIDR(x/n) -> B=CIDR(x/n+1) + C=CIDR(x+foo/n+1) RIR split A, gives B to Bob and C to Carol. Bob gives B to Dave, and Carol gives C to Dave. Dave can now join B+C to get A again. Nothing else works, unless B is passed down through Eric, Franz, and Greg, and C is passed down through Harriet, Ian, and James. In each case, without taking anything from B or C. Is this known to have happened, and is it visible in the routing table?? Brian _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Tue Oct 7 00:08:34 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7BB7F3A6873; Tue, 7 Oct 2008 00:08:34 -0700 (PDT) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 315F43A6873 for ; Tue, 7 Oct 2008 00:08:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t6rZAlSe8YsD for ; Tue, 7 Oct 2008 00:08:33 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by core3.amsl.com (Postfix) with ESMTP id 692D73A6850 for ; Tue, 7 Oct 2008 00:08:33 -0700 (PDT) Received: from ip192.186.dsl-acs2.seawa0.iinet.com ([209.20.186.192] helo=rmac.psg.com) by ran.psg.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Kn6gw-000OA8-4z; Tue, 07 Oct 2008 07:09:10 +0000 Message-ID: <48EB0B15.9030804@psg.com> Date: Tue, 07 Oct 2008 00:09:09 -0700 From: Randy Bush User-Agent: Thunderbird 2.0.0.17 (Macintosh/20080914) MIME-Version: 1.0 To: Geoff Huston References: <48EA0A7D.5070508@psg.com> <20081006230832.133E92282B@thrintun.hactrn.net> <48EAA257.7010301@psg.com> <62698B4A-8D14-4E38-856F-55EAB4435BCC@apnic.net> <48EAAB89.9000001@psg.com> <48EB009F.9010701@psg.com> In-Reply-To: <48EB009F.9010701@psg.com> X-Enigmail-Version: 0.95.7 Cc: sidr@ietf.org Subject: Re: [sidr] Resolving the issues in the roa-format draft X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org apologies. before someone over 40 catches me, i 'fess up that i was wrong. the cut i wanted was winterlong, not winterlude . and i did not get to cortez the killer either. and i still have not figured out how to demonstrate/test your assertion. randy, who clearly is not having a very good night _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Tue Oct 7 01:22:08 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 523A13A69E2; Tue, 7 Oct 2008 01:22:08 -0700 (PDT) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 569FB3A6870 for ; Tue, 7 Oct 2008 01:22:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.574 X-Spam-Level: X-Spam-Status: No, score=-6.574 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JRpuVM7ifIVS for ; Tue, 7 Oct 2008 01:22:06 -0700 (PDT) Received: from mint.apnic.net (mint.apnic.net [202.12.29.58]) by core3.amsl.com (Postfix) with ESMTP id 2A8193A6849 for ; Tue, 7 Oct 2008 01:22:06 -0700 (PDT) Received: from dhcp19.potaroo.net (dhcp19.potaroo.net [203.10.60.19]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mint.apnic.net (Postfix) with ESMTP id 56BF9D5F2D; Tue, 7 Oct 2008 18:22:43 +1000 (EST) Message-Id: <86FEFD2A-B5F6-456F-A215-BAA039D8377D@apnic.net> From: Geoff Huston To: Brian Dickson In-Reply-To: <48EB062E.6090808@ca.afilias.info> Mime-Version: 1.0 (Apple Message framework v929.2) Date: Tue, 7 Oct 2008 19:22:40 +1100 References: <48EA0A7D.5070508@psg.com> <20081006230832.133E92282B@thrintun.hactrn.net> <48EAA257.7010301@psg.com> <62698B4A-8D14-4E38-856F-55EAB4435BCC@apnic.net> <48EAAB89.9000001@psg.com> <48EB009F.9010701@psg.com> <48EB062E.6090808@ca.afilias.info> X-Mailer: Apple Mail (2.929.2) Cc: sidr@ietf.org Subject: Re: [sidr] Resolving the issues in the roa-format draft X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org WG Chair hat _OFF_ On 07/10/2008, at 5:48 PM, Brian Dickson wrote: > Randy Bush wrote: >> Geoff: >> >>>> and this case, although not common, has been visible in the routing >>>> table already >>>> >> Randy: >> >>> oh? and how do you detect it? how many are there? how much of a >>> real >>> problem is it? >>> >> >> so i had a three hour drive from seeing kids in portland to the >> exciting >> westin colo in seattle. i did not even make it through the neil >> young >> on my ipod. but i kept thinking of how one could test or demonstrate >> your assertion. perhaps neil scrambled my thinking, but it did not >> even >> get to winterlude. >> >> for each prefix in some routing table, rv, dump of one of my routers, >> whatever, see if that prefix can be decomposed into two or more >> prefixes >> which one can demonstrate are 'given' to the announcing asn by two or >> more different would-be certificate authoritiess, e.g. rirs or >> disparate >> delegatees of rirs. >> >> i could not really see how to do this for other than the case where >> the >> prefix can be shown to be in the delegation registries of two rirs. >> >> please give us one example which supports your assertion, or whack me >> with a clue by four about how one could better test/demonstrate your >> assertion. >> > > Let me ask Geoff about the specific kinds of scenarios, to simplify > things a bit. (I'm curious, too.) > > Would the visible examples be adjacent prefixes (suitable for > aggregation) originated by one specific ASN? yes > > > Or, would the visible examples be adjacent prefixes from two ASNs, > being > *proxy* aggregated by a third ASN? > yes - I had a quick scan through the routing table this afternoon and saw two potential instances of this. > Or some other variation involving one or two ASNs? I do not believe > > > Try as I might, I am unable to figure out any way to split a block > more > than one way. > > And for two blocks to be able to be aggregated (without covering other > prefixes, i.e. not a proxy aggregate for any third parties), they have > to be adjacent. > > Which means the two entities giving those blocks, would have to give > the > *whole* block (in both cases) to the recipient, with nothing left over > for the giver or the giver's other customers. > > A=CIDR(x/n) -> B=CIDR(x/n+1) + C=CIDR(x+foo/n+1) > RIR split A, gives B to Bob and C to Carol. Bob gives B to Dave, and > Carol gives C to Dave. Dave can now join B+C to get A again. > Nothing else works, unless B is passed down through Eric, Franz, and > Greg, and C is passed down through Harriet, Ian, and James. In each > case, without taking anything from B or C. > > Is this known to have happened, and is it visible in the routing > table?? If you have a detailed look at the RIR's stats files you find that the older address space is somewhat fragmented across RIRs. If you also try and take into account a certain amount if NIR fragmentation what you have is the basic set of prefixes and their associated certification path. Now construct this table of allocations for every day for the past, say year. Then pull the set of all BGP updates for the same period (route views is a decent source of all such updates over the past year) Now look up each updated prefix in the relevant daily table and see if the prefix fits within a single allocation space. Report anomalies. There may be more efficient approaches. Geoff _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Tue Oct 7 01:43:28 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 292FB28C156; Tue, 7 Oct 2008 01:43:28 -0700 (PDT) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7C0A328C133 for ; Tue, 7 Oct 2008 01:43:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.578 X-Spam-Level: X-Spam-Status: No, score=-6.578 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vxEDCaI-ngQX for ; Tue, 7 Oct 2008 01:43:26 -0700 (PDT) Received: from mint.apnic.net (mint.apnic.net [202.12.29.58]) by core3.amsl.com (Postfix) with ESMTP id 7B26528C10D for ; Tue, 7 Oct 2008 01:43:26 -0700 (PDT) Received: from dhcp19.potaroo.net (dhcp19.potaroo.net [203.10.60.19]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mint.apnic.net (Postfix) with ESMTP id C2067D5F2D; Tue, 7 Oct 2008 18:43:12 +1000 (EST) Message-Id: From: Geoff Huston To: Randy Bush In-Reply-To: <48EB0B15.9030804@psg.com> Mime-Version: 1.0 (Apple Message framework v929.2) Date: Tue, 7 Oct 2008 19:42:55 +1100 References: <48EA0A7D.5070508@psg.com> <20081006230832.133E92282B@thrintun.hactrn.net> <48EAA257.7010301@psg.com> <62698B4A-8D14-4E38-856F-55EAB4435BCC@apnic.net> <48EAAB89.9000001@psg.com> <48EB009F.9010701@psg.com> <48EB0B15.9030804@psg.com> X-Mailer: Apple Mail (2.929.2) Cc: sidr@ietf.org Subject: Re: [sidr] Resolving the issues in the roa-format draft X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org WG Chair hat _OFF_ On 07/10/2008, at 6:09 PM, Randy Bush wrote: > apologies. before someone over 40 catches me, i 'fess up that i was > wrong. the cut i wanted was winterlong, not winterlude . > and i > did not get to cortez the killer either. > > and i still have not figured out how to demonstrate/test your > assertion. > > randy, who clearly is not having a very good night A source of a relatively complete set of individual allocations can be retrieved from http://bgp.potaroo.net/stats/nro/delegated then take a large set of updates and examine each prefix - the Route views update archive is a good source and then perform a lookup into the individual allocation list for each updates / withdrawn prefix and report anomalies that straddle multiple allocations is one way to understand the level of historical occurrence. There could be other approaches of course. Geoff _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Tue Oct 7 05:25:11 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C046D3A6B74; Tue, 7 Oct 2008 05:25:11 -0700 (PDT) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 93BB83A6B74 for ; Tue, 7 Oct 2008 05:25:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0dbR3CVKeW-J for ; Tue, 7 Oct 2008 05:25:06 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by core3.amsl.com (Postfix) with ESMTP id 5491F3A689A for ; Tue, 7 Oct 2008 05:25:04 -0700 (PDT) Received: from ip192.186.dsl-acs2.seawa0.iinet.com ([209.20.186.192] helo=rmac.psg.com) by ran.psg.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KnBdD-000PWx-KV; Tue, 07 Oct 2008 12:25:39 +0000 Message-ID: <48EB5542.7000704@psg.com> Date: Tue, 07 Oct 2008 05:25:38 -0700 From: Randy Bush User-Agent: Thunderbird 2.0.0.17 (Macintosh/20080914) MIME-Version: 1.0 To: Geoff Huston References: <48EA0A7D.5070508@psg.com> <20081006230832.133E92282B@thrintun.hactrn.net> <48EAA257.7010301@psg.com> <62698B4A-8D14-4E38-856F-55EAB4435BCC@apnic.net> <48EAAB89.9000001@psg.com> <48EB009F.9010701@psg.com> <48EB0B15.9030804@psg.com> In-Reply-To: X-Enigmail-Version: 0.95.7 Cc: sidr@ietf.org Subject: Re: [sidr] Resolving the issues in the roa-format draft X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org > A source of a relatively complete set of individual allocations can be > retrieved from http://bgp.potaroo.net/stats/nro/delegated > > then take a large set of updates and examine each prefix - the Route > views update archive is a good source > > and then perform a lookup into the individual allocation list for each > updates / withdrawn prefix > > and report anomalies that straddle multiple allocations > > is one way to understand the level of historical occurrence. again, could you give us one or two examples of this actually occurring, an asn aggregating prefixes from multiple rirs, i.e. what not having multiply signed roas would preclude? you did say "and this case, although not common, has been visible in the routing table already." randy _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Tue Oct 7 07:11:31 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7D1A33A6B2F; Tue, 7 Oct 2008 07:11:31 -0700 (PDT) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5358828C12F for ; Tue, 7 Oct 2008 07:11:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.225 X-Spam-Level: X-Spam-Status: No, score=-2.225 tagged_above=-999 required=5 tests=[AWL=-0.226, BAYES_00=-2.599, J_CHICKENPOX_91=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BTX54b5EEzNx for ; Tue, 7 Oct 2008 07:11:29 -0700 (PDT) Received: from mx3.bbn.com (mx3.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id DF4923A6B28 for ; Tue, 7 Oct 2008 07:11:28 -0700 (PDT) Received: from dhcp89-089-106.bbn.com ([128.89.89.106] helo=[127.0.0.1]) by mx3.bbn.com with esmtp (Exim 4.63) (envelope-from ) id 1KnDHC-0005SQ-A4; Tue, 07 Oct 2008 10:11:02 -0400 Message-ID: <48EB6D8F.3070800@bbn.com> Date: Tue, 07 Oct 2008 10:09:19 -0400 From: Matt Lepinski Organization: BBN User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Brian Dickson References: <513C369E-B21F-42CE-A721-61C258DC15D7@apnic.net> <48EAA23F.6030609@ca.afilias.info> <7D283111-5FAC-450F-8F15-18139A89F8C8@apnic.net> <48EB02AC.60503@ca.afilias.info> In-Reply-To: <48EB02AC.60503@ca.afilias.info> Cc: sidr@ietf.org Subject: [sidr] ROA representation and examples (was Re: Resolving the issues in the roa-format draft) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org Brian, Two comments: 1) In your first example, the use of the term "registration" indicates that we might have some confusion on the semantics of a ROA. We envision that certificates will be issued in conjunction with the registration of IP resources (e.g. The RIR issues a certicate to the LIR when the LIR obtains resources from the RIR). ROAs are not intended to reflect registration but are merely a statement by the holder of IP resources (i.e. the party to whom the resources are registered) that a particular AS is permitted to originate routes to particular IP prefixes. If this was not your understanding, then I'd like your help in finding places in the ROA document where wording can changed to make these semantics clear. (If this was your understanding, then I apologize for mis-understanding your example.) In any case, I personally believe that the SIDR Resource PKI is an inefficient way for the RIRs to enforce policy upon the LIRs. So I'm personally not inclined to make changes in an attempt to make the R-PKI suitable for that purpose. With regards to your second example, if the LIR wants to prohibit a an end-user from announcing prefixes through another provider (hole punching), then I think the right answer is for the LIR NOT to issue a certificate to the end-user (this prevents the end-user from issuing ROAs that grant permissions to other providers) and instead to issue an appropriate ROA for the aggregate prefix (which persumably names the LIR's own AS number). 2) With regards to format, there was discussion in March in Philidelphia which led to the addition of the max-length field. At that time, the question was raised as to whether there should also be a min-length field and at the time there seemed to be no operator requirement for such a field. In particular, to justify a min-length field one would need a use-case where a registered holder of IP resources wishes to give an AS permission to advertise many long prefixes, but expressly forbid the AS from advertising the aggregate prefix. Such a use-case seems unlikely because in most cases advertising the aggregate prefix does no harm (and indeed will be ignored in the presence of advertisements for longer prefixes) although I could be missing something. - Matt Lepinski Brian Dickson wrote: >Geoff Huston wrote: > > >>WG Chair hat _OFF_ >> >>On 07/10/2008, at 10:41 AM, Brian Dickson wrote: >> >> >> >>>Rather than having: >>> >>> IP_address / length le maxLength (length <= maxLength <= >>>address-family-max-length) >>> >>>this would be >>> >>> IP_address / length ge minLength le maxLength (length <= minLength >>><= maxLength <= address-family-max-length) >>> >>> >>> >>Its isomorphic in one sense isn't it? The described representation >>lists the prefixes in the maximally permitted aggregate format and by >>the optional MaxLength parameter which specifies the finest level of >>more specifics that could be originated from this ROA. Your suggested >>representation allows a number of aggregatable prefixes to be >>aggregated as a described prefix, as long as they share a common >>minLength value. >> >>_personally_ I'm unsure that this alternate representation would offer >>any superior flexibility in the representation of ROAs. >> >> > >I'm not sure if any or all of these kinds of use cases are appropriate, >but if any of them are, they may serve to demonstrate the compactness >achievable with this representation. > >Examples: >RIR->LIR, RIR has certain specific policies it wishes to enforce >regarding LIR assignments to end-users -- anything bigger than /X >requires justification (i.e. approval) and registration (i.e. ROA). >Either RIR has to create a large swath of ROAs, each of size /X, or it >can create one ROA with minLength=X. (In this example, maxLength is >irrelevant and presumed identical.) >Exceptions are needed, of course, for /Y (Y < X), but each of these can >be done with separate ROAs. >Even as a worst case scenario, no *more* ROAs are needed than in the >original case. >In a best case scenario, many orders of magnitude quantity of ROAs need >never be created, and RIR's policies are enforced directly via ROAs. > >LIR->PA customers, LIR wants to aggregate but also wants to ensure no >customers are able to punch holes in the PA space. >LIR restricts the minLength to something not globally routable (e.g. /25 >in IPv4, /49 in IPv6). >This ties the customer to the LIR, by preventing PA blocks being >announced via third parties (hole punching). >One ROA can be assigned, whether the amount of space is small or large. >Internal aggregation by the PA customer is limited, of course, but that >is the intention of the LIR. > >There may be other cases that I'm missing, but which others may see, >based on the above examples. >Things related to IPv6 nibble boundaries (for ip6.arpa reasons) but >where the current use is only a portion of the larger (reserved) block; >ROAs with differing minLength can be created as the customer grows, >providing a viable path with no "flag day" needed. > >It is certainly no worse than the previous representation, as it is >strictly a superset. > >The main question, IMHO, is, does it add sufficient value to justify >making the change? >(I think it's the only question, actually.) > >Brian >_______________________________________________ >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 sidr-bounces@ietf.org Tue Oct 7 08:13:23 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 08A8B28C16F; Tue, 7 Oct 2008 08:13:23 -0700 (PDT) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 31D8228C16F for ; Tue, 7 Oct 2008 08:13:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.809 X-Spam-Level: X-Spam-Status: No, score=-2.809 tagged_above=-999 required=5 tests=[AWL=-0.210, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3accryFpQXZq for ; Tue, 7 Oct 2008 08:13:21 -0700 (PDT) Received: from mx11.bbn.com (mx11.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id 5A71C3A6B55 for ; Tue, 7 Oct 2008 08:13:21 -0700 (PDT) Received: from dhcp89-089-071.bbn.com ([128.89.89.71]) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1KnEF5-0001mZ-Do; Tue, 07 Oct 2008 11:12:55 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <77ead0ec0810062015y71d2ddb0lc2a4c6c59aa09a7e@mail.gmail.com> References: <48EA0A7D.5070508@psg.com> <20081006230832.133E92282B@thrintun.hactrn.net> <20081007022314.7BE792282B@thrintun.hactrn.net> <2D30DC8B-1D75-4E9A-87C7-6F22615AAA25@apnic.net> <77ead0ec0810062015y71d2ddb0lc2a4c6c59aa09a7e@mail.gmail.com> Date: Tue, 7 Oct 2008 11:13:34 -0400 To: "Vishwas Manral" From: Stephen Kent Cc: Rob Austein , sidr@ietf.org Subject: Re: [sidr] Resolving the issues in the roa-format draft X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org Vishwas, I replied to your message from Feb 27, back in that time frame. I noted that: - the RPKI is the first step toward providing better BGP security - the SIDR WG understands the limitations of using ROAs for origin AS validation (vs. full path validation) - both the soBGP and the SBGP proposals rely on a PKI of the sort that the SIDR work is standardizing - use of ROAs and the RPKI allows one to more readily distinguish between benign errors and malicious attacks, which is valuable I don't think that your 1-page I-D is a useful characterization of the motivation for the SIDR work, or the residual secruity issues to be addressed after the RPKI foundation is standardized. I do think we should make sure that the SIDR architecture document capture these issues, e.g., in the secruity considerations section. Steve _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Tue Oct 7 08:18:41 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9EF943A6B5E; Tue, 7 Oct 2008 08:18:41 -0700 (PDT) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A31533A6B5E for ; Tue, 7 Oct 2008 08:18:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.788 X-Spam-Level: X-Spam-Status: No, score=-2.788 tagged_above=-999 required=5 tests=[AWL=-0.189, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hHUfzzVPnppB for ; Tue, 7 Oct 2008 08:18:40 -0700 (PDT) Received: from mx11.bbn.com (mx11.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id E94A83A6B43 for ; Tue, 7 Oct 2008 08:18:39 -0700 (PDT) Received: from dhcp89-089-071.bbn.com ([128.89.89.71]) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1KnELG-0001r6-FY; Tue, 07 Oct 2008 11:19:18 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <48EB02AC.60503@ca.afilias.info> References: <513C369E-B21F-42CE-A721-61C258DC15D7@apnic.net> <48EAA23F.6030609@ca.afilias.info> <7D283111-5FAC-450F-8F15-18139A89F8C8@apnic.net> <48EB02AC.60503@ca.afilias.info> Date: Tue, 7 Oct 2008 11:19:41 -0400 To: Brian Dickson From: Stephen Kent Cc: sidr@ietf.org Subject: Re: [sidr] Resolving the issues in the roa-format draft X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org At 2:33 AM -0400 10/7/08, Brian Dickson wrote: >G... > >I'm not sure if any or all of these kinds of use cases are appropriate, >but if any of them are, they may serve to demonstrate the compactness >achievable with this representation. > >Examples: >RIR->LIR, RIR has certain specific policies it wishes to enforce >regarding LIR assignments to end-users -- anything bigger than /X >requires justification (i.e. approval) and registration (i.e. ROA). >Either RIR has to create a large swath of ROAs, each of size /X, or it When I got to this statement, I became very concerned. A ROA is generated by a prefix holder to specify an AS that the prefix holder authorizes to originate a route to the prefix in question. Thus, an RIR (or NIR) should never be signing a ROA. Only ISPs and subscribers who are multi-homed or who have PI address space should be generating ROAs. I didn't read the rest of your message to validate the other examples you offered, but this one seems seriously out of whack. Steve _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Tue Oct 7 08:30:10 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 84CB03A6B67; Tue, 7 Oct 2008 08:30:10 -0700 (PDT) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 262523A6B67 for ; Tue, 7 Oct 2008 08:30:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id inuOOEbMF5UA for ; Tue, 7 Oct 2008 08:30:08 -0700 (PDT) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by core3.amsl.com (Postfix) with ESMTP id 2A1613A69F4 for ; Tue, 7 Oct 2008 08:30:08 -0700 (PDT) Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.13.5/8.13.5) with ESMTP id m97FRwRb005833; Tue, 7 Oct 2008 10:27:58 -0500 Received: from nemo.columbia.ads.sparta.com (nemo.columbia.sparta.com [157.185.80.75]) by Beta5.sparta.com (8.12.11/8.13.1) with ESMTP id m97FRvJo014295; Tue, 7 Oct 2008 10:27:57 -0500 Received: from SANDYM-LT.columbia.ads.sparta.com ([157.185.81.151]) by nemo.columbia.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Tue, 7 Oct 2008 11:27:56 -0400 Date: Tue, 7 Oct 2008 11:27:54 -0400 (Eastern Daylight Time) From: Sandra Murphy To: Stephen Kent In-Reply-To: Message-ID: References: <513C369E-B21F-42CE-A721-61C258DC15D7@apnic.net> <48EAA23F.6030609@ca.afilias.info> <7D283111-5FAC-450F-8F15-18139A89F8C8@apnic.net> <48EB02AC.60503@ca.afilias.info> X-X-Sender: sandy@nemo.columbia.sparta.com MIME-Version: 1.0 X-OriginalArrivalTime: 07 Oct 2008 15:27:56.0693 (UTC) FILETIME=[4605E450:01C92891] Cc: sidr@ietf.org Subject: Re: [sidr] Resolving the issues in the roa-format draft X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org On Tue, 7 Oct 2008, Stephen Kent wrote: > At 2:33 AM -0400 10/7/08, Brian Dickson wrote: >> G... >> >> I'm not sure if any or all of these kinds of use cases are appropriate, >> but if any of them are, they may serve to demonstrate the compactness >> achievable with this representation. >> >> Examples: >> RIR->LIR, RIR has certain specific policies it wishes to enforce >> regarding LIR assignments to end-users -- anything bigger than /X >> requires justification (i.e. approval) and registration (i.e. ROA). >> Either RIR has to create a large swath of ROAs, each of size /X, or it > > > When I got to this statement, I became very concerned. A ROA is generated by > a prefix holder to specify an AS that the prefix holder authorizes to > originate a route to the prefix in question. Thus, an RIR (or NIR) should > never be signing a ROA. Only ISPs and subscribers who are multi-homed or who > have PI address space should be generating ROAs. Any chance Brian meant RSA, not ROA? Seems to fit the context better. --Sandy > > I didn't read the rest of your message to validate the other examples you > offered, but this one seems seriously out of whack. > > Steve > _______________________________________________ > 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 sidr-bounces@ietf.org Tue Oct 7 08:33:45 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1577D3A6873; Tue, 7 Oct 2008 08:33:45 -0700 (PDT) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0054E3A6873 for ; Tue, 7 Oct 2008 08:33:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iotUcBIhYdTa for ; Tue, 7 Oct 2008 08:33:40 -0700 (PDT) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by core3.amsl.com (Postfix) with ESMTP id 095F23A67B0 for ; Tue, 7 Oct 2008 08:33:39 -0700 (PDT) Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.13.5/8.13.5) with ESMTP id m97FUBQ3005878; Tue, 7 Oct 2008 10:30:11 -0500 Received: from nemo.columbia.ads.sparta.com (nemo.columbia.sparta.com [157.185.80.75]) by Beta5.sparta.com (8.12.11/8.13.1) with ESMTP id m97FUAp5014386; Tue, 7 Oct 2008 10:30:10 -0500 Received: from SANDYM-LT.columbia.ads.sparta.com ([157.185.81.151]) by nemo.columbia.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Tue, 7 Oct 2008 11:30:10 -0400 Date: Tue, 7 Oct 2008 11:30:09 -0400 (Eastern Daylight Time) From: Sandra Murphy To: Stephen Kent In-Reply-To: Message-ID: References: <513C369E-B21F-42CE-A721-61C258DC15D7@apnic.net> <48EAA23F.6030609@ca.afilias.info> <7D283111-5FAC-450F-8F15-18139A89F8C8@apnic.net> <48EB02AC.60503@ca.afilias.info> X-X-Sender: sandy@nemo.columbia.sparta.com MIME-Version: 1.0 X-OriginalArrivalTime: 07 Oct 2008 15:30:10.0131 (UTC) FILETIME=[958EEA30:01C92891] Cc: sidr@ietf.org Subject: Re: [sidr] Resolving the issues in the roa-format draft X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org On Tue, 7 Oct 2008, Sandra Murphy wrote: > > > On Tue, 7 Oct 2008, Stephen Kent wrote: > >> At 2:33 AM -0400 10/7/08, Brian Dickson wrote: >>> G... >>> >>> I'm not sure if any or all of these kinds of use cases are appropriate, >>> but if any of them are, they may serve to demonstrate the compactness >>> achievable with this representation. >>> >>> Examples: >>> RIR->LIR, RIR has certain specific policies it wishes to enforce >>> regarding LIR assignments to end-users -- anything bigger than /X >>> requires justification (i.e. approval) and registration (i.e. ROA). >>> Either RIR has to create a large swath of ROAs, each of size /X, or it >> >> >> When I got to this statement, I became very concerned. A ROA is generated >> by a prefix holder to specify an AS that the prefix holder authorizes to >> originate a route to the prefix in question. Thus, an RIR (or NIR) should >> never be signing a ROA. Only ISPs and subscribers who are multi-homed or >> who have PI address space should be generating ROAs. > > Any chance Brian meant RSA, not ROA? Seems to fit the context better. > On second thought, no it doesn't. sorry. --Sandy > --Sandy > > >> >> I didn't read the rest of your message to validate the other examples you >> offered, but this one seems seriously out of whack. >> >> Steve >> _______________________________________________ >> 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 sidr-bounces@ietf.org Tue Oct 7 13:05:39 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0213E3A6A89; Tue, 7 Oct 2008 13:05:39 -0700 (PDT) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2690B3A6A89 for ; Tue, 7 Oct 2008 13:05:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.927 X-Spam-Level: X-Spam-Status: No, score=-5.927 tagged_above=-999 required=5 tests=[AWL=-0.262, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_91=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sx48wDPrBuRB for ; Tue, 7 Oct 2008 13:05:35 -0700 (PDT) Received: from outbound.afilias.info (outbound.afilias.info [69.46.124.26]) by core3.amsl.com (Postfix) with ESMTP id 4A04B3A681F for ; Tue, 7 Oct 2008 13:05:35 -0700 (PDT) Received: from bmp-336-ms506.wa.yyz2.afilias-ops.info ([10.50.129.112] helo=smtp.afilias.info) by outbound.afilias.info with esmtp (Exim 4.69) (envelope-from ) id 1KnIoO-0004w2-4J; Tue, 07 Oct 2008 20:05:40 +0000 Message-ID: <48EBC117.5000402@ca.afilias.info> Date: Tue, 07 Oct 2008 16:05:43 -0400 From: Brian Dickson User-Agent: Thunderbird 2.0.0.17 (Macintosh/20080914) MIME-Version: 1.0 To: Matt Lepinski References: <513C369E-B21F-42CE-A721-61C258DC15D7@apnic.net> <48EAA23F.6030609@ca.afilias.info> <7D283111-5FAC-450F-8F15-18139A89F8C8@apnic.net> <48EB02AC.60503@ca.afilias.info> <48EB6D8F.3070800@bbn.com> In-Reply-To: <48EB6D8F.3070800@bbn.com> X-Authenticated: True Cc: sidr@ietf.org Subject: Re: [sidr] ROA representation and examples (was Re: Resolving the issues in the roa-format draft) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org (Sorry in advance - long post ahead. Please read, however, when you have time, everyone. There's some valuable operator input here.) Matt Lepinski wrote: > Brian, > > Two comments: > > 1) In your first example, the use of the term "registration" indicates > that we might have some confusion on the semantics of a ROA. We > envision that certificates will be issued in conjunction with the > registration of IP resources (e.g. The RIR issues a certicate to the > LIR when the LIR obtains resources from the RIR). ROAs are not > intended to reflect registration but are merely a statement by the > holder of IP resources (i.e. the party to whom the resources are > registered) that a particular AS is permitted to originate routes to > particular IP prefixes. If this was not your understanding, then I'd > like your help in finding places in the ROA document where wording can > changed to make these semantics clear. (If this was your > understanding, then I apologize for mis-understanding your example.) I think I understand what you're saying. However, I am trying to reconcile several things, and am having difficulty in figuring out what EE/ROA things need to be issued, by whom, and what the validation methodology is. I'm specifically considering the BGP default-free zone, and prefixes seen globally. Here's how filters can be built today: * IP allocations are done o either entire PA blocks to ISPs for reassignment to their customers, and aggregation to the whole block before global announcement (at least in theory) o or PI blocks to end sites who are multi-homed * IRR registration is made by the originating AS (the ISP or multi-homed entity, using its own ASN as Origin: attribute for Route: objects, plus its Aut-num: object) * IRR registration is made for as-sets (hierarchically, too, to arbitrary depth) reflecting customer/transit relationships * IRR registration of peering announcements (who announces what to whom, in RPSL) is done * Expansion of IRR contents on a per-peer or per-customer basis is done, expanding into permitted AS_PATH and PREFIX lists (not necessarily tied together, unfortunately, and not necessarily as complete as we would like) In the "-roa-" drafts, the term "originate" is used consistently, but I am unclear if that maps 1:1 with "Origin:" in the IRR. Does it mean, strictly, originate, or does it also mean "announce to a peer", where the announcer heard it from some third party, i.e. the announcer has the prefix with a non-empty as-path? I can see how the first recipient of such an announcement could validate the prefix based on ROA. How does someone more than one AS away validate using ROAs, if he/she is not able to know for certain that the sender is also authorized to send all prefixes for the remote AS (the alleged originator)? And/or, presumably, there is the ability to authorize an upstream AS to announce all of one's AS, and that that is a transitive property. Is the ROA used for this, or is there some other "thing" that is used for signing/validating? Now, for a use case: There are classes of allocations which are made in a very particular method, which I believe the RIRs would like to have means for restricting their use. These are "critical infrastructure" assignments, typically /24's to be used in a PI fashion, which may be assigned en mass, e.g. from larger ranges of contiguous space (perhaps by coincidence, but contiguous nonetheless). These could show up as a sequence of /23,/22,/23,/24 (for a set of 9 prefixes). Operators of DNS infrastructure, among others, are critically dependent on the availability and use of these, and having the ability to trust routing announcements of these prefixes is of first-order importance to SIDR, IMNSHO. In these cases, I believe the RIR would want to issue the ROA itself, and do so in such a way as to only permit /24's to be announced, and only by a specific ASN originator. I do not believe the RIR would want to cede control of the larger blocks, only (at best) the individual /24's. And, in particular, the RIR would not want the recipient ASN to be able to "glue together" the contiguous pieces, and certainly not to be able to assign the glued bits to some third party, especially for money. If it were technically feasible for a large chunk of "critical infrastructure" space to be (a) aggregated, and (b) sold on the black market, it would be bad all-around, for operators of critical infrastructure, for the RIR, and for the processes involved. That is one use case. However unlikely the scenarios described, they are of enough concern for me to document. That at a minimum, I would hope, is sufficient for the WG to give consideration to the security considerations involved, and to view the minLength issue from that perspective. > > In any case, I personally believe that the SIDR Resource PKI is an > inefficient way for the RIRs to enforce policy upon the LIRs. So I'm > personally not inclined to make changes in an attempt to make the > R-PKI suitable for that purpose. With regards to your second example, > if the LIR wants to prohibit a an end-user from announcing prefixes > through another provider (hole punching), then I think the right > answer is for the LIR NOT to issue a certificate to the end-user (this > prevents the end-user from issuing ROAs that grant permissions to > other providers) and instead to issue an appropriate ROA for the > aggregate prefix (which persumably names the LIR's own AS number). What about BGP MPLS VPNs? If an ISP gives a chunk of space to a customer to use on the customer's VPN, and wants to run BGP to the customer for PE-CE routing, and wants to ensure that the customer only announces prefixes it is supposed to, and to do the filtering per site, the ISP would ideally want to issue an ROA, with a longer minLength than the block itself, but not announce the more-specific to the world. The ISP would not want to have the customer announce any other prefixes. The ISP would also want to enforce BCP 38, and would want to filter *packets* based on RPKI (sidr). How else, other than ROA(s) is this possible? And what if the customer is so big, that they are the only recipient of an ROA from a large CIDR block? (Hint - think about large global organizations like IATA, or various DOD departments). > > 2) With regards to format, there was discussion in March in > Philidelphia which led to the addition of the max-length field. At > that time, the question was raised as to whether there should also be > a min-length field and at the time there seemed to be no operator > requirement for such a field. In particular, to justify a min-length > field one would need a use-case where a registered holder of IP > resources wishes to give an AS permission to advertise many long > prefixes, but expressly forbid the AS from advertising the aggregate > prefix. Such a use-case seems unlikely because in most cases > advertising the aggregate prefix does no harm (and indeed will be > ignored in the presence of advertisements for longer prefixes) > although I could be missing something. Not to be too pedantic, but: The IETF policy is that the mailing list is where things get decided. Meetings are for useful discussions, and for getting "the sense of the room". However, the absence of voices of concern, at a meeting, is not sufficient reason to discount discussion on technical issues and merits, on the mailing list. There are *definitely* cases where advertising the aggregate prefix can and will do harm. Consider Bill Manning's /16 for ep.net (exchange point allocations). Each of those is used as a /24 (or /23 or /22 for big exchanges). Announcing the aggregate, or any portion thereof, would likely cause harm, and at a minimum facilitate wide-scale abuse, like pointing default at peers on an exchange. It's one example, but far from the only example. I'd suggest that however unlikely, the presence of a single extra field, may save someone's bacon somewhere down the road. I wouldn't want to be counted among those opposing its inclusion, if not having it caused someone a real operational problem, just because we couldn't come up with a big enough example at the time. I'd rather have it included and never get used, than exclude it and cause a headache for someone. It's analogous to free speech. I may disagree vehemently with you, but I will always fight for your ability to express those insipid comments :-) Brian > > - Matt Lepinski > > Brian Dickson wrote: > >> Geoff Huston wrote: >> >> >>> WG Chair hat _OFF_ >>> >>> On 07/10/2008, at 10:41 AM, Brian Dickson wrote: >>> >>> >>>> Rather than having: >>>> >>>> IP_address / length le maxLength (length <= maxLength <= >>>> address-family-max-length) >>>> >>>> this would be >>>> >>>> IP_address / length ge minLength le maxLength (length <= minLength >>>> <= maxLength <= address-family-max-length) >>>> >>>> >>> Its isomorphic in one sense isn't it? The described representation >>> lists the prefixes in the maximally permitted aggregate format and by >>> the optional MaxLength parameter which specifies the finest level of >>> more specifics that could be originated from this ROA. Your suggested >>> representation allows a number of aggregatable prefixes to be >>> aggregated as a described prefix, as long as they share a common >>> minLength value. >>> >>> _personally_ I'm unsure that this alternate representation would offer >>> any superior flexibility in the representation of ROAs. >>> >> >> I'm not sure if any or all of these kinds of use cases are appropriate, >> but if any of them are, they may serve to demonstrate the compactness >> achievable with this representation. >> >> Examples: >> RIR->LIR, RIR has certain specific policies it wishes to enforce >> regarding LIR assignments to end-users -- anything bigger than /X >> requires justification (i.e. approval) and registration (i.e. ROA). >> Either RIR has to create a large swath of ROAs, each of size /X, or it >> can create one ROA with minLength=X. (In this example, maxLength is >> irrelevant and presumed identical.) >> Exceptions are needed, of course, for /Y (Y < X), but each of these can >> be done with separate ROAs. >> Even as a worst case scenario, no *more* ROAs are needed than in the >> original case. >> In a best case scenario, many orders of magnitude quantity of ROAs need >> never be created, and RIR's policies are enforced directly via ROAs. >> >> LIR->PA customers, LIR wants to aggregate but also wants to ensure no >> customers are able to punch holes in the PA space. >> LIR restricts the minLength to something not globally routable (e.g. /25 >> in IPv4, /49 in IPv6). >> This ties the customer to the LIR, by preventing PA blocks being >> announced via third parties (hole punching). >> One ROA can be assigned, whether the amount of space is small or large. >> Internal aggregation by the PA customer is limited, of course, but that >> is the intention of the LIR. >> >> There may be other cases that I'm missing, but which others may see, >> based on the above examples. >> Things related to IPv6 nibble boundaries (for ip6.arpa reasons) but >> where the current use is only a portion of the larger (reserved) block; >> ROAs with differing minLength can be created as the customer grows, >> providing a viable path with no "flag day" needed. >> >> It is certainly no worse than the previous representation, as it is >> strictly a superset. >> >> The main question, IMHO, is, does it add sufficient value to justify >> making the change? >> (I think it's the only question, actually.) >> >> Brian >> _______________________________________________ >> 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 sidr-bounces@ietf.org Tue Oct 7 13:40:46 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CE03F3A689F; Tue, 7 Oct 2008 13:40:46 -0700 (PDT) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 02C9E3A6834 for ; Tue, 7 Oct 2008 13:40:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.58 X-Spam-Level: X-Spam-Status: No, score=-6.58 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nbCHwXm-rHee for ; Tue, 7 Oct 2008 13:40:44 -0700 (PDT) Received: from mint.apnic.net (mint.apnic.net [202.12.29.58]) by core3.amsl.com (Postfix) with ESMTP id 29DAE3A680F for ; Tue, 7 Oct 2008 13:40:44 -0700 (PDT) Received: from dhcp19.potaroo.net (dhcp19.potaroo.net [203.10.60.19]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mint.apnic.net (Postfix) with ESMTP id 11825D5F2D; Wed, 8 Oct 2008 06:41:20 +1000 (EST) Message-Id: <74E7AAAC-9EFE-447D-A466-1934E18EB873@apnic.net> From: Geoff Huston To: Brian Dickson In-Reply-To: <48EBC117.5000402@ca.afilias.info> Mime-Version: 1.0 (Apple Message framework v929.2) Date: Wed, 8 Oct 2008 07:41:19 +1100 References: <513C369E-B21F-42CE-A721-61C258DC15D7@apnic.net> <48EAA23F.6030609@ca.afilias.info> <7D283111-5FAC-450F-8F15-18139A89F8C8@apnic.net> <48EB02AC.60503@ca.afilias.info> <48EB6D8F.3070800@bbn.com> <48EBC117.5000402@ca.afilias.info> X-Mailer: Apple Mail (2.929.2) Cc: sidr@ietf.org Subject: Re: [sidr] ROA representation and examples (was Re: Resolving the issues in the roa-format draft) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org WG Chair Hat Off On 08/10/2008, at 7:05 AM, Brian Dickson wrote: > (Sorry in advance - long post ahead. Please read, however, when you > have > time, everyone. There's some valuable operator input here.) Brian when I read your post I was reading it with the following example in mind ROA1 10.0.0.0/16, maxlength=18, 10.1.0.0/16, maxlength=18, EE Cert=10.0.0.0/15 and ROA2 10.0.0.0/15 minlength=16, maxlength=18, EE Cert=10.0.0.0/15 Now as far as I can tell these are equivalent ROAs, yes? Now what, in your examples could be expressed using ROA1 that chould not be expressed using ROA2, and vice versa? The reason why I ask the question was that in my readon of your post I saw nothing that helped me distinguish between these cases. regards, Geoff _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Tue Oct 7 13:47:05 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5C03A3A6B93; Tue, 7 Oct 2008 13:47:05 -0700 (PDT) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B396A3A6B79 for ; Tue, 7 Oct 2008 13:47:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.582 X-Spam-Level: X-Spam-Status: No, score=-6.582 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9+p9G63WQvUs for ; Tue, 7 Oct 2008 13:47:04 -0700 (PDT) Received: from mint.apnic.net (mint.apnic.net [202.12.29.58]) by core3.amsl.com (Postfix) with ESMTP id CA83C3A6B4C for ; Tue, 7 Oct 2008 13:47:03 -0700 (PDT) Received: from dhcp19.potaroo.net (dhcp19.potaroo.net [203.10.60.19]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mint.apnic.net (Postfix) with ESMTP id 4CF04D5F2D; Wed, 8 Oct 2008 06:47:26 +1000 (EST) Message-Id: <1EE78693-3CC1-43BE-95BA-7C65672755EE@apnic.net> From: Geoff Huston To: Randy Bush In-Reply-To: <48EB5542.7000704@psg.com> Mime-Version: 1.0 (Apple Message framework v929.2) Date: Wed, 8 Oct 2008 07:47:25 +1100 References: <48EA0A7D.5070508@psg.com> <20081006230832.133E92282B@thrintun.hactrn.net> <48EAA257.7010301@psg.com> <62698B4A-8D14-4E38-856F-55EAB4435BCC@apnic.net> <48EAAB89.9000001@psg.com> <48EB009F.9010701@psg.com> <48EB0B15.9030804@psg.com> <48EB5542.7000704@psg.com> X-Mailer: Apple Mail (2.929.2) Cc: sidr@ietf.org Subject: Re: [sidr] Resolving the issues in the roa-format draft X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org WG Chair hat off On 07/10/2008, at 11:25 PM, Randy Bush wrote: >> A source of a relatively complete set of individual allocations can >> be >> retrieved from http://bgp.potaroo.net/stats/nro/delegated >> >> then take a large set of updates and examine each prefix - the Route >> views update archive is a good source >> >> and then perform a lookup into the individual allocation list for >> each >> updates / withdrawn prefix >> >> and report anomalies that straddle multiple allocations >> >> is one way to understand the level of historical occurrence. > > again, could you give us one or two examples of this actually > occurring, > an asn aggregating prefixes from multiple rirs, i.e. what not having > multiply signed roas would preclude? > > you did say "and this case, although not common, has been visible in > the > routing table already." > I did say that and I based that comment on my earlier work in constructing the BGP report and looking at aggregation possibilities in the routing table and figuring out why the code was failing for certain advertised prefixes (its always the bugs that are more interesting than the working code). That was over 4 years ago, and after correcting (!) the code not to look for such cases where the prefix straddled across allocation boundaries I've not had to go back there again until this conversation. So if you are after current examples, then its a case of reconstructing the code and running through the routing updates again. It may be some weeks before I can get around to this task personally. Others may be better situated to perform such an investigation in a faster timeframe. Geoff _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Tue Oct 7 13:53:52 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1E0D93A6B70; Tue, 7 Oct 2008 13:53:52 -0700 (PDT) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 076463A6B4C for ; Tue, 7 Oct 2008 13:53:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.198 X-Spam-Level: X-Spam-Status: No, score=-6.198 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7srHKBFObhHq for ; Tue, 7 Oct 2008 13:53:50 -0700 (PDT) Received: from outbound.afilias.info (outbound.afilias.info [69.46.124.26]) by core3.amsl.com (Postfix) with ESMTP id 160B73A680F for ; Tue, 7 Oct 2008 13:53:49 -0700 (PDT) Received: from bmp-336-ms506.wa.yyz2.afilias-ops.info ([10.50.129.112] helo=smtp.afilias.info) by outbound.afilias.info with esmtp (Exim 4.69) (envelope-from ) id 1KnJZT-0005y4-6H; Tue, 07 Oct 2008 20:54:19 +0000 Message-ID: <48EBCC7F.5080504@ca.afilias.info> Date: Tue, 07 Oct 2008 16:54:23 -0400 From: Brian Dickson User-Agent: Thunderbird 2.0.0.17 (Macintosh/20080914) MIME-Version: 1.0 To: Geoff Huston References: <48EA0A7D.5070508@psg.com> <20081006230832.133E92282B@thrintun.hactrn.net> <48EAA257.7010301@psg.com> <62698B4A-8D14-4E38-856F-55EAB4435BCC@apnic.net> <48EAAB89.9000001@psg.com> <48EB009F.9010701@psg.com> <48EB0B15.9030804@psg.com> <48EB5542.7000704@psg.com> <1EE78693-3CC1-43BE-95BA-7C65672755EE@apnic.net> In-Reply-To: <1EE78693-3CC1-43BE-95BA-7C65672755EE@apnic.net> X-Authenticated: True Cc: sidr@ietf.org Subject: Re: [sidr] Resolving the issues in the roa-format draft X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org Geoff Huston wrote: > WG Chair hat off > > > On 07/10/2008, at 11:25 PM, Randy Bush wrote: > >>> A source of a relatively complete set of individual allocations can be >>> retrieved from http://bgp.potaroo.net/stats/nro/delegated >>> >>> then take a large set of updates and examine each prefix - the Route >>> views update archive is a good source >>> >>> and then perform a lookup into the individual allocation list for each >>> updates / withdrawn prefix >>> >>> and report anomalies that straddle multiple allocations >>> >>> is one way to understand the level of historical occurrence. >> >> again, could you give us one or two examples of this actually occurring, >> an asn aggregating prefixes from multiple rirs, i.e. what not having >> multiply signed roas would preclude? >> >> you did say "and this case, although not common, has been visible in the >> routing table already." >> > > I did say that and I based that comment on my earlier work in > constructing the BGP report and looking at aggregation possibilities > in the routing table and figuring out why the code was failing for > certain advertised prefixes (its always the bugs that are more > interesting than the working code). That was over 4 years ago, and > after correcting (!) the code not to look for such cases where the > prefix straddled across allocation boundaries I've not had to go back > there again until this conversation. Even historical examples from 4 years ago, if you can find the prefixes in question and other attributes, would be very interesting to most folks, I believe. (Most of us have access to the old data too, so we can look at the then-relevant state of the world as relates to those prefixes.) If you have them handy, that is. Brian > > So if you are after current examples, then its a case of > reconstructing the code and running through the routing updates again. > It may be some weeks before I can get around to this task personally. > Others may be better situated to perform such an investigation in a > faster timeframe. > > Geoff > > > > > _______________________________________________ > 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 sidr-bounces@ietf.org Tue Oct 7 14:01:53 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9F8693A6834; Tue, 7 Oct 2008 14:01:53 -0700 (PDT) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E6BE63A6834 for ; Tue, 7 Oct 2008 14:01:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.074 X-Spam-Level: X-Spam-Status: No, score=-6.074 tagged_above=-999 required=5 tests=[AWL=0.191, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uHVVkdGqh35J for ; Tue, 7 Oct 2008 14:01:51 -0700 (PDT) Received: from outbound.afilias.info (outbound.afilias.info [69.46.124.26]) by core3.amsl.com (Postfix) with ESMTP id 15E603A6768 for ; Tue, 7 Oct 2008 14:01:50 -0700 (PDT) Received: from bmp-336-ms505.wa.yyz2.afilias-ops.info ([10.50.129.111] helo=smtp.afilias.info) by outbound.afilias.info with esmtp (Exim 4.69) (envelope-from ) id 1KnJhA-00066c-5I; Tue, 07 Oct 2008 21:02:16 +0000 Message-ID: <48EBCE5B.2090006@ca.afilias.info> Date: Tue, 07 Oct 2008 17:02:19 -0400 From: Brian Dickson User-Agent: Thunderbird 2.0.0.17 (Macintosh/20080914) MIME-Version: 1.0 To: Geoff Huston References: <513C369E-B21F-42CE-A721-61C258DC15D7@apnic.net> <48EAA23F.6030609@ca.afilias.info> <7D283111-5FAC-450F-8F15-18139A89F8C8@apnic.net> <48EB02AC.60503@ca.afilias.info> <48EB6D8F.3070800@bbn.com> <48EBC117.5000402@ca.afilias.info> <74E7AAAC-9EFE-447D-A466-1934E18EB873@apnic.net> In-Reply-To: <74E7AAAC-9EFE-447D-A466-1934E18EB873@apnic.net> X-Authenticated: True Cc: sidr@ietf.org Subject: Re: [sidr] ROA representation and examples (was Re: Resolving the issues in the roa-format draft) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org Geoff Huston wrote: > WG Chair Hat Off > > On 08/10/2008, at 7:05 AM, Brian Dickson wrote: > >> (Sorry in advance - long post ahead. Please read, however, when you have >> time, everyone. There's some valuable operator input here.) > > Brian when I read your post I was reading it with the following > example in mind > > ROA1 > 10.0.0.0/16, maxlength=18, 10.1.0.0/16, maxlength=18, EE Cert=10.0.0.0/15 > > and > > ROA2 > 10.0.0.0/15 minlength=16, maxlength=18, EE Cert=10.0.0.0/15 > > Now as far as I can tell these are equivalent ROAs, yes? > Yeeeeeees. However, my reading of the drafts suggest that the EE Cert needs to exactly match the ROA. Is that the case for ROA1? > Now what, in your examples could be expressed using ROA1 that chould > not be expressed using ROA2, and vice versa? The reason why I ask the > question was that in my readon of your post I saw nothing that helped > me distinguish between these cases. For the small example above, there is no difference. But that example is, in some respects, a "straw man"... The problem is when you get into things like: 10.0.0.0/16, minlength=24, maxlength=24 or 10.0.0.0/12, minlength=21, maxlength=29 or 2001:foo::/48 minlength=56, maxlength=126 (Enumeration in binary systems doesn't scale well.) I can think of environments where this kind of thing might be desired, if not outright required. MPLS BGP VPNs, or virtual machine environments (EC2), among others. Even if we're not necessarily designing this for use in anything other than the DFZ Internet, I don't see strong disincentive to designing flexibility into the system, to support other uses. Brian _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Tue Oct 7 14:15:18 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DBB8428C12F; Tue, 7 Oct 2008 14:15:18 -0700 (PDT) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 38D9E28C12F for ; Tue, 7 Oct 2008 14:15:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.09 X-Spam-Level: X-Spam-Status: No, score=-6.09 tagged_above=-999 required=5 tests=[AWL=0.175, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eYVmfXbWEkXm for ; Tue, 7 Oct 2008 14:15:17 -0700 (PDT) Received: from outbound.afilias.info (outbound.afilias.info [69.46.124.26]) by core3.amsl.com (Postfix) with ESMTP id 3BBFC28C11B for ; Tue, 7 Oct 2008 14:15:17 -0700 (PDT) Received: from bmp-336-ms505.wa.yyz2.afilias-ops.info ([10.50.129.111] helo=smtp.afilias.info) by outbound.afilias.info with esmtp (Exim 4.69) (envelope-from ) id 1KnJtH-0006OE-60; Tue, 07 Oct 2008 21:14:47 +0000 Message-ID: <48EBD14B.6080503@ca.afilias.info> Date: Tue, 07 Oct 2008 17:14:51 -0400 From: Brian Dickson User-Agent: Thunderbird 2.0.0.17 (Macintosh/20080914) MIME-Version: 1.0 To: Stephen Kent References: <513C369E-B21F-42CE-A721-61C258DC15D7@apnic.net> <48EAA23F.6030609@ca.afilias.info> <7D283111-5FAC-450F-8F15-18139A89F8C8@apnic.net> <48EB02AC.60503@ca.afilias.info> In-Reply-To: X-Authenticated: True Cc: sidr@ietf.org Subject: Re: [sidr] Resolving the issues in the roa-format draft X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org Stephen Kent wrote: > At 2:33 AM -0400 10/7/08, Brian Dickson wrote: >> G... >> >> I'm not sure if any or all of these kinds of use cases are appropriate, >> but if any of them are, they may serve to demonstrate the compactness >> achievable with this representation. >> >> Examples: >> RIR->LIR, RIR has certain specific policies it wishes to enforce >> regarding LIR assignments to end-users -- anything bigger than /X >> requires justification (i.e. approval) and registration (i.e. ROA). >> Either RIR has to create a large swath of ROAs, each of size /X, or it > > > When I got to this statement, I became very concerned. A ROA is > generated by a prefix holder to specify an AS that the prefix holder > authorizes to originate a route to the prefix in question. Thus, an > RIR (or NIR) should never be signing a ROA. Only ISPs and subscribers > who are multi-homed or who have PI address space should be generating > ROAs. > > I didn't read the rest of your message to validate the other examples > you offered, but this one seems seriously out of whack. I think there are definitely boundary issues on "who owns IP space" that are very relevant, and very timely. Yes, I understand that "who owns" the space is "who generates the ROA". My question is, if the RIR's policy is that the RIR owns the space, not the ISP, what then? Nothing in the framework can or should mandate what an RIR does. (RIRs may take guidance, but are ultimately responsive to their membership, not the IETF.) Case in point - the "IP Transfer Policy for IPv4" issue, in the ARIN region (and likely mirrored in the other RIR regions)... (You may want to take a look at the ARIN public policy mailing list archives, if you aren't already on that list.) The main issue is, if IP space is *fully* under the control of the ISP, then that ISP can assign the whole block to some third party, e.g. for money (aka, "sell" or "rent" the block). Compare that to the model where the RIR *never* gives full control of the block, but instead signs an ROA with the ISP's ASN listed as being allowed to originate it, possibly with more-specifics. It differs from the current model, but then, everything about ROAs differs from the current model. So, I don't believe my example is "out of whack" at all, and is something that might not have been considered, but is definitely an unresolved and important issue. Brian _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Tue Oct 7 14:16:02 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0A9603A67B3; Tue, 7 Oct 2008 14:16:02 -0700 (PDT) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6E75E3A67B3 for ; Tue, 7 Oct 2008 14:16:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4hh3U592eEZc for ; Tue, 7 Oct 2008 14:15:59 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by core3.amsl.com (Postfix) with ESMTP id 7DD143A6768 for ; Tue, 7 Oct 2008 14:15:59 -0700 (PDT) Received: from ip192.186.dsl-acs2.seawa0.iinet.com ([209.20.186.192] helo=rmac.psg.com) by ran.psg.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KnJuz-0001ZY-6R; Tue, 07 Oct 2008 21:16:33 +0000 Message-ID: <48EBD1AF.10402@psg.com> Date: Tue, 07 Oct 2008 14:16:31 -0700 From: Randy Bush User-Agent: Thunderbird 2.0.0.17 (Macintosh/20080914) MIME-Version: 1.0 To: Geoff Huston References: <48EA0A7D.5070508@psg.com> <20081006230832.133E92282B@thrintun.hactrn.net> <48EAA257.7010301@psg.com> <62698B4A-8D14-4E38-856F-55EAB4435BCC@apnic.net> <48EAAB89.9000001@psg.com> <48EB009F.9010701@psg.com> <48EB0B15.9030804@psg.com> <48EB5542.7000704@psg.com> <1EE78693-3CC1-43BE-95BA-7C65672755EE@apnic.net> In-Reply-To: <1EE78693-3CC1-43BE-95BA-7C65672755EE@apnic.net> X-Enigmail-Version: 0.95.7 Cc: sidr@ietf.org Subject: Re: [sidr] Resolving the issues in the roa-format draft X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org the data are broken in the first place. there are duplicate entries! % grep ipv4 delegated | awk 'BEGIN {FS="|";} {print $4}' | sort | uniq -c | grep -v ' 1 ' 2 132.11.0.0 2 132.17.0.0 2 156.112.0.0 2 156.113.0.0 2 192.52.232.0 2 192.94.234.0 2 193.194.128.0 2 193.227.128.0 2 194.9.64.0 2 194.9.82.0 2 195.234.185.0 2 195.234.252.0 randy _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Tue Oct 7 14:35:01 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 963763A680F; Tue, 7 Oct 2008 14:35:01 -0700 (PDT) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C78633A680F for ; Tue, 7 Oct 2008 14:35:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.504 X-Spam-Level: X-Spam-Status: No, score=-2.504 tagged_above=-999 required=5 tests=[AWL=0.094, BAYES_00=-2.599, WHOIS_NETSOLPR=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o3Q+Uej32u8M for ; Tue, 7 Oct 2008 14:34:58 -0700 (PDT) Received: from mx11.bbn.com (mx11.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id 99D4F3A6768 for ; Tue, 7 Oct 2008 14:34:58 -0700 (PDT) Received: from dhcp89-089-106.bbn.com ([128.89.89.106] helo=[127.0.0.1]) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1KnKD4-0005wT-F1; Tue, 07 Oct 2008 17:35:14 -0400 Message-ID: <48EBD5AA.90609@bbn.com> Date: Tue, 07 Oct 2008 17:33:30 -0400 From: Matt Lepinski Organization: BBN User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Brian Dickson References: <513C369E-B21F-42CE-A721-61C258DC15D7@apnic.net> <48EAA23F.6030609@ca.afilias.info> <7D283111-5FAC-450F-8F15-18139A89F8C8@apnic.net> <48EB02AC.60503@ca.afilias.info> <48EB6D8F.3070800@bbn.com> <48EBC117.5000402@ca.afilias.info> In-Reply-To: <48EBC117.5000402@ca.afilias.info> Cc: sidr@ietf.org Subject: Re: [sidr] ROA representation and examples (was Re: Resolving the issues in the roa-format draft) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org Brian, Thank you for the feedback, comments are in-line below Brian Dickson wrote: >(Sorry in advance - long post ahead. Please read, however, when you have >time, everyone. There's some valuable operator input here.) > > >I think I understand what you're saying. > >However, I am trying to reconcile several things, and am having >difficulty in figuring out what EE/ROA things need to be issued, by >whom, and what the validation methodology is. > >I'm specifically considering the BGP default-free zone, and prefixes >seen globally. > >Here's how filters can be built today: > > * IP allocations are done > o either entire PA blocks to ISPs for reassignment to their > customers, and aggregation to the whole block before global > announcement (at least in theory) > o or PI blocks to end sites who are multi-homed > * IRR registration is made by the originating AS (the ISP or > multi-homed entity, using its own ASN as Origin: attribute for > Route: objects, plus its Aut-num: object) > * IRR registration is made for as-sets (hierarchically, too, to > arbitrary depth) reflecting customer/transit relationships > * IRR registration of peering announcements (who announces what to > whom, in RPSL) is done > * Expansion of IRR contents on a per-peer or per-customer basis is > done, expanding into permitted AS_PATH and PREFIX lists (not > necessarily tied together, unfortunately, and not necessarily as > complete as we would like) > > >In the "-roa-" drafts, the term "originate" is used consistently, but I >am unclear if that maps 1:1 with "Origin:" in the IRR. Does it mean, >strictly, originate, or does it also mean "announce to a peer", where >the announcer heard it from some third party, i.e. the announcer has the >prefix with a non-empty as-path? > >I can see how the first recipient of such an announcement could validate >the prefix based on ROA. >How does someone more than one AS away validate using ROAs, if he/she is >not able to know for certain that the sender is also authorized to send >all prefixes for the remote AS (the alleged originator)? >And/or, presumably, there is the ability to authorize an upstream AS to >announce all of one's AS, and that that is a transitive property. >Is the ROA used for this, or is there some other "thing" that is used >for signing/validating? > > [MBL]: It seems that our documents need to define "originate" more clearly. The intended meaning is that the "originating" AS is the one who initially injects an advertisement into the routing system (i.e. as the term is used in Section 5.1.2 of RFC 4271), and does not refer to an AS that receives an advertisement from a peer and forwards the advertisement to other peers. I believe this corresponds to the use of the "Origin:" attribute in the IRR. [MBL]: Also let me attempt to be clear as to the problem that ROAs are attempting to solve. The use of validated ROAs as an (additional) input to the filter generation process allows the prevention of the following limited class of attacks: Consider an AS who (perhaps accidently due to mis-configuration) emits a BGP UPDATE message originating a route to a prefix to which he is not authorized to originate routes (e.g. an ISP operator in Pakistan mistakenly announces a route to a prefix owned by youtube.com). Any ISP that receives such an invalid advertisement (either directly or by way of a peer who propagates the invalid announcement) can use data from validated ROAs to determine that the advertisement is invalid. [MBL]: Note that no one is claiming that the current SIDR work is sufficient to prevent all attacks on the routing system. Indeed, as you indicate, ROAs alone are insufficient to detect cases where an intermediate ISP receives a valid announcement that the ISP is not permitted to propagate, but (either maliciously or accidently) prorates the announcement anyway. However, the infrastructure being developed by SIDR is a necessary first step in creating more comprehensive routing security solutions (such as S-BGP or SO-BGP) which could be used to prevent such attacks by intermediaries. >Now, for a use case: > >There are classes of allocations which are made in a very particular >method, which I believe the RIRs would like to have means for >restricting their use. > >These are "critical infrastructure" assignments, typically /24's to be >used in a PI fashion, which may be assigned en mass, e.g. from larger >ranges of contiguous space (perhaps by coincidence, but contiguous >nonetheless). >These could show up as a sequence of /23,/22,/23,/24 (for a set of 9 >prefixes). >Operators of DNS infrastructure, among others, are critically dependent >on the availability and use of these, and having the ability to trust >routing announcements of these prefixes is of first-order importance to >SIDR, IMNSHO. > >In these cases, I believe the RIR would want to issue the ROA itself, >and do so in such a way as to only permit /24's to be announced, and >only by a specific ASN originator. I do not believe the RIR would want >to cede control of the larger blocks, only (at best) the individual /24's. > >And, in particular, the RIR would not want the recipient ASN to be able >to "glue together" the contiguous pieces, and certainly not to be able >to assign the glued bits to some third party, especially for money. > >If it were technically feasible for a large chunk of "critical >infrastructure" space to be (a) aggregated, and (b) sold on the black >market, it would be bad all-around, for operators of critical >infrastructure, for the RIR, and for the processes involved. > >That is one use case. However unlikely the scenarios described, they are >of enough concern for me to document. That at a minimum, I would hope, >is sufficient for the WG to give consideration to the security >considerations involved, and to view the minLength issue from that >perspective. > > [MBL]: Thank you for the use case. The problem you raise above is not one that I had envisioned that SIDR would solve, however, is there is a simple way for the SIDR architecture to be modified to meet additional RIR requirements then we should certainly consider such modification. What confuses me in this example, however, is how the aggregation of "critical infrastructure" space is the problem. If an RIR wishes to prevent a party receiving IP resources from transferring those resources to another party (e.g. on the black market) then the RIR could in theory issue the ROA itself (and not issue a certificate to the party receiving the addresses) which allows the RIR to maintain control over which AS's can originate routes to the given address space. (Personally, I don't know if any RIRs are planning to do this, but it is certainly technically possible). On the other hand, if an RIR chooses to issue a certificate to a party receiving IP resources then the mechanisms specified in SIDR are completely in-capable of preventing the receiving party from transferring the resources without the RIR's consent (e.g. on the black market) --- And this seems true regardless of whether there is a minLength field in a ROA. > > >>In any case, I personally believe that the SIDR Resource PKI is an >>inefficient way for the RIRs to enforce policy upon the LIRs. So I'm >>personally not inclined to make changes in an attempt to make the >>R-PKI suitable for that purpose. With regards to your second example, >>if the LIR wants to prohibit a an end-user from announcing prefixes >>through another provider (hole punching), then I think the right >>answer is for the LIR NOT to issue a certificate to the end-user (this >>prevents the end-user from issuing ROAs that grant permissions to >>other providers) and instead to issue an appropriate ROA for the >>aggregate prefix (which persumably names the LIR's own AS number). >> >> > >What about BGP MPLS VPNs? If an ISP gives a chunk of space to a customer >to use on the customer's VPN, and wants to run BGP to the customer for >PE-CE routing, and wants to ensure that the customer only announces >prefixes it is supposed to, and to do the filtering per site, the ISP >would ideally want to issue an ROA, with a longer minLength than the >block itself, but not announce the more-specific to the world. The ISP >would not want to have the customer announce any other prefixes. The ISP >would also want to enforce BCP 38, and would want to filter *packets* >based on RPKI (sidr). How else, other than ROA(s) is this possible? > >And what if the customer is so big, that they are the only recipient of >an ROA from a large CIDR block? (Hint - think about large global >organizations like IATA, or various DOD departments). > > [MBL]: This seems like a good example (which hasn't come up in past discussions) for us to keep in mind. I don't know whether we can make the R-PKI work for MPLS VPNs, but I'd certainly like to do so if it can be done with only minor changes to the architecture (e.g. the addition of an extra ROA field). I apologize for my ignorance, but f you could be a little more specific here, it would help me. In particular, I'm confused here as to what is "the block itself" as compared to the prefixes that the customer should be advertising. > >Not to be too pedantic, but: >The IETF policy is that the mailing list is where things get decided. >Meetings are for useful discussions, and for getting "the sense of the >room". >However, the absence of voices of concern, at a meeting, is not >sufficient reason to discount discussion on technical issues and merits, >on the mailing list. > > > [MBL]: My apologies, I did not mean to say that we should discount further discussion of the issue based on what had been said at IETF 72, I am only saying that the discussion at IETF 72 led me to personally believe that the existence of use-cases necessitating a minLength field was unlikely. But I'm happy to continue discussing this issue on the list, and it may very well turn out that I was mistaken. >There are *definitely* cases where advertising the aggregate prefix can >and will do harm. > >Consider Bill Manning's /16 for ep.net (exchange point allocations). >Each of those is used as a /24 (or /23 or /22 for big exchanges). >Announcing the aggregate, or any portion thereof, would likely cause >harm, and at a minimum facilitate wide-scale abuse, like pointing >default at peers on an exchange. >It's one example, but far from the only example. > > [MBL]: It seems to me that in order for minLength to be needed, we'd require a case in which an AS was authorized to originate routes to two adjacent /24's but it would be harmful if the AS instead initiated a route to the aggregate /23. Is this such a case? >I'd suggest that however unlikely, the presence of a single extra field, >may save someone's bacon somewhere down the road. > >I wouldn't want to be counted among those opposing its inclusion, if not >having it caused someone a real operational problem, just because we >couldn't come up with a big enough example at the time. > >I'd rather have it included and never get used, than exclude it and >cause a headache for someone. > >It's analogous to free speech. I may disagree vehemently with you, but I >will always fight for your ability to express those insipid comments :-) > >Brian > > [MBL]: Weighing the potential for future operational problems versus the added implementation complexity of adding rarely-used features to a specification is always challenging (see for example, the other current SIDR thread regarding multiple signatures on a ROA). I'm personally hesitant to include a feature without understanding the use-cases that necessitate such a feature, but others in the working group may disagree. Finally, I very much appreciate your feedback, and please do not take my response as arguing vehemently against inclusion of a minLength field (I'm really just trying to better understand the underlying use-cases). _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Tue Oct 7 14:44:49 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0AC733A6A67; Tue, 7 Oct 2008 14:44:49 -0700 (PDT) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A41D128C137 for ; Tue, 7 Oct 2008 14:44:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7uICPh+FjVU3 for ; Tue, 7 Oct 2008 14:44:47 -0700 (PDT) Received: from mint.apnic.net (mint.apnic.net [202.12.29.58]) by core3.amsl.com (Postfix) with ESMTP id BF37F28C16A for ; Tue, 7 Oct 2008 14:44:46 -0700 (PDT) Received: from [58.163.5.20] (unknown [58.163.5.20]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mint.apnic.net (Postfix) with ESMTP id D9EDCD5F2D; Wed, 8 Oct 2008 07:45:01 +1000 (EST) Message-Id: <3BCBBE81-B48F-4EC5-95A0-691322AA8772@apnic.net> From: Geoff Huston To: Brian Dickson In-Reply-To: <48EBCC7F.5080504@ca.afilias.info> Mime-Version: 1.0 (Apple Message framework v929.2) Date: Wed, 8 Oct 2008 08:45:00 +1100 References: <48EA0A7D.5070508@psg.com> <20081006230832.133E92282B@thrintun.hactrn.net> <48EAA257.7010301@psg.com> <62698B4A-8D14-4E38-856F-55EAB4435BCC@apnic.net> <48EAAB89.9000001@psg.com> <48EB009F.9010701@psg.com> <48EB0B15.9030804@psg.com> <48EB5542.7000704@psg.com> <1EE78693-3CC1-43BE-95BA-7C65672755EE@apnic.net> <48EBCC7F.5080504@ca.afilias.info> X-Mailer: Apple Mail (2.929.2) Cc: sidr@ietf.org Subject: Re: [sidr] Resolving the issues in the roa-format draft X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org WG Chair hat off On 08/10/2008, at 7:54 AM, Brian Dickson wrote: > Even historical examples from 4 years ago, if you can find the > prefixes > in question and other attributes, would be very interesting to most > folks, I believe. > (Most of us have access to the old data too, so we can look at the > then-relevant state of the world as relates to those prefixes.) > > If you have them handy, that is. I did not think that they were interesting at the time, and never kept any records (yeah, I'm too slack! :-( ) - so its a case of getting out the BGP update microscope and doing it all over again. Geoff _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Tue Oct 7 14:54:27 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9ED373A6B96; Tue, 7 Oct 2008 14:54:27 -0700 (PDT) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C96953A6B96 for ; Tue, 7 Oct 2008 14:54:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i1ggWavoCplU for ; Tue, 7 Oct 2008 14:54:25 -0700 (PDT) Received: from mint.apnic.net (mint.apnic.net [202.12.29.58]) by core3.amsl.com (Postfix) with ESMTP id 9B3243A6B81 for ; Tue, 7 Oct 2008 14:54:25 -0700 (PDT) Received: from [58.163.5.20] (unknown [58.163.5.20]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mint.apnic.net (Postfix) with ESMTP id 3FD0FD5F2D; Wed, 8 Oct 2008 07:55:00 +1000 (EST) Message-Id: From: Geoff Huston To: Brian Dickson In-Reply-To: <48EBCE5B.2090006@ca.afilias.info> Mime-Version: 1.0 (Apple Message framework v929.2) Date: Wed, 8 Oct 2008 08:54:58 +1100 References: <513C369E-B21F-42CE-A721-61C258DC15D7@apnic.net> <48EAA23F.6030609@ca.afilias.info> <7D283111-5FAC-450F-8F15-18139A89F8C8@apnic.net> <48EB02AC.60503@ca.afilias.info> <48EB6D8F.3070800@bbn.com> <48EBC117.5000402@ca.afilias.info> <74E7AAAC-9EFE-447D-A466-1934E18EB873@apnic.net> <48EBCE5B.2090006@ca.afilias.info> X-Mailer: Apple Mail (2.929.2) Cc: sidr@ietf.org Subject: Re: [sidr] ROA representation and examples (was Re: Resolving the issues in the roa-format draft) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org WG Chair hat off On 08/10/2008, at 8:02 AM, Brian Dickson wrote: > Geoff Huston wrote: >> WG Chair Hat Off >> >> On 08/10/2008, at 7:05 AM, Brian Dickson wrote: >> >>> (Sorry in advance - long post ahead. Please read, however, when >>> you have >>> time, everyone. There's some valuable operator input here.) >> >> Brian when I read your post I was reading it with the following >> example in mind >> >> ROA1 >> 10.0.0.0/16, maxlength=18, 10.1.0.0/16, maxlength=18, EE >> Cert=10.0.0.0/15 >> >> and >> >> ROA2 >> 10.0.0.0/15 minlength=16, maxlength=18, EE Cert=10.0.0.0/15 >> >> Now as far as I can tell these are equivalent ROAs, yes? >> > > Yeeeeeees. However, my reading of the drafts suggest that the EE Cert > needs to exactly match the ROA. > Is that the case for ROA1? > My apologies for the misunderstanging here - in the flurry of mail traffic on this list there was the proposal to change the "exactly match" text to "encompass" "Yes, if the text in section 3, step 3 of the draft was altered to use the term "encompass" such that the IP addresses prefixes in that extension encompasses the IP prefix(es) in the ROA I would agree that would be a suitable resolution." In my head in working through your example I had assumed that this was already the case. (The reasoning here is that EE certs DO have a canonical representation, and 10.0.0.0/16, 10.1.0.0/16 must be expressed in a canonical form in the cert as 10.0.0.0/15 - for this reason "encompass" is a reasonable resolution > >> Now what, in your examples could be expressed using ROA1 that chould >> not be expressed using ROA2, and vice versa? The reason why I ask the >> question was that in my readon of your post I saw nothing that helped >> me distinguish between these cases. > > For the small example above, there is no difference. But that example > is, in some respects, a "straw man"... > > The problem is when you get into things like: > > 10.0.0.0/16, minlength=24, maxlength=24 > > or > > 10.0.0.0/12, minlength=21, maxlength=29 > > or > > 2001:foo::/48 minlength=56, maxlength=126 > > (Enumeration in binary systems doesn't scale well.) Again, however this is an enumeration issue rather than a difference in semantics. > > > I can think of environments where this kind of thing might be desired, > if not outright required. > MPLS BGP VPNs, or virtual machine environments (EC2), among others. > > Even if we're not necessarily designing this for use in anything other > than the DFZ Internet, I don't see strong disincentive to designing > flexibility into the system, to support other uses. > I'm not arguing for or against this - I'm attempting to understand the precise nature of the difference. Its my understanding so far that the two representations are isomorphic - nothing expressible in one notation is inexpressible in the other. The only difference _as far as I can see_ lies in the size of the ROA in expressing sets of prefixes, and as far as I can see a set of conjoined prefixes with the same maximal length constraint would have a more compact representation with a min length parameter. Or am I missing something still in my understanding of this? regards, Geoff _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Tue Oct 7 15:00:22 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0F7EB3A6B82; Tue, 7 Oct 2008 15:00:22 -0700 (PDT) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 543303A6B82 for ; Tue, 7 Oct 2008 15:00:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GLTPxuINp2Gp for ; Tue, 7 Oct 2008 15:00:19 -0700 (PDT) Received: from mint.apnic.net (mint.apnic.net [202.12.29.58]) by core3.amsl.com (Postfix) with ESMTP id 69F7F3A6A97 for ; Tue, 7 Oct 2008 15:00:19 -0700 (PDT) Received: from [58.163.5.20] (unknown [58.163.5.20]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mint.apnic.net (Postfix) with ESMTP id 4B1A4D5F2D; Wed, 8 Oct 2008 08:00:35 +1000 (EST) Message-Id: <88E411E7-091D-4958-9814-FD5248CC1406@apnic.net> From: Geoff Huston To: Randy Bush In-Reply-To: <48EBD1AF.10402@psg.com> Mime-Version: 1.0 (Apple Message framework v929.2) Date: Wed, 8 Oct 2008 09:00:33 +1100 References: <48EA0A7D.5070508@psg.com> <20081006230832.133E92282B@thrintun.hactrn.net> <48EAA257.7010301@psg.com> <62698B4A-8D14-4E38-856F-55EAB4435BCC@apnic.net> <48EAAB89.9000001@psg.com> <48EB009F.9010701@psg.com> <48EB0B15.9030804@psg.com> <48EB5542.7000704@psg.com> <1EE78693-3CC1-43BE-95BA-7C65672755EE@apnic.net> <48EBD1AF.10402@psg.com> X-Mailer: Apple Mail (2.929.2) Cc: sidr@ietf.org Subject: Re: [sidr] Resolving the issues in the roa-format draft X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org WG Chair hat OFF On 08/10/2008, at 8:16 AM, Randy Bush wrote: > the data are broken in the first place. there are duplicate entries! > > % grep ipv4 delegated | awk 'BEGIN {FS="|";} {print $4}' | sort | uniq > -c | grep -v ' 1 ' > 2 132.11.0.0 > 2 132.17.0.0 > 2 156.112.0.0 > 2 156.113.0.0 > 2 192.52.232.0 > 2 192.94.234.0 > 2 193.194.128.0 > 2 193.227.128.0 > 2 194.9.64.0 > 2 194.9.82.0 > 2 195.234.185.0 > 2 195.234.252.0 Yes, I agree that the RIR allocation data is imperfect as well, so the summary file of the union of the RIR's data is also imperfect in terms of uniqueness. :-( Obviously, his does not make the task easier. Geoff _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Tue Oct 7 15:59:57 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4F83E28C181; Tue, 7 Oct 2008 15:59:57 -0700 (PDT) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7821C28C181 for ; Tue, 7 Oct 2008 15:59:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.756 X-Spam-Level: X-Spam-Status: No, score=-2.756 tagged_above=-999 required=5 tests=[AWL=-0.157, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cMyhLsJJhlD0 for ; Tue, 7 Oct 2008 15:59:54 -0700 (PDT) Received: from mx3.bbn.com (mx3.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id 90A6828C0CE for ; Tue, 7 Oct 2008 15:59:54 -0700 (PDT) Received: from dhcp89-089-071.bbn.com ([128.89.89.71]) by mx3.bbn.com with esmtp (Exim 4.63) (envelope-from ) id 1KnLXA-00058c-AJ; Tue, 07 Oct 2008 19:00:04 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <48EBD14B.6080503@ca.afilias.info> References: <513C369E-B21F-42CE-A721-61C258DC15D7@apnic.net> <48EAA23F.6030609@ca.afilias.info> <7D283111-5FAC-450F-8F15-18139A89F8C8@apnic.net> <48EB02AC.60503@ca.afilias.info> <48EBD14B.6080503@ca.afilias.info> Date: Tue, 7 Oct 2008 19:00:31 -0400 To: Brian Dickson From: Stephen Kent Cc: sidr@ietf.org Subject: Re: [sidr] Resolving the issues in the roa-format draft X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org Brian, I believe the collection of SIDR documents do a reasonable job explaining the underlying assumptions and motivations for the SIDR work. Still, we'll revisit them to try to minimize the ambiguities you perceive. Nonethelsss, let me summarize: The RPKI is intended to parallel the address space (and AS #) allocation hierarchy, from IANA, to RIRs, to NIRs (where applicable) to ISPs (aka LIRs) and PI subscribers, ... We never talk about "owning" address space, because IANA and the RIRs do not use that term. We use the term "resource holder" to refer to an entity who holds address space or AS numbers. The term refers to the entity that is recorded in the applicable RIR (or IANA) database as the holder of the resource in question. Thus the resource certificates issued by registries are alternative representations of the registry database records, pared down to the essential data for the routing security goals of interest. They are only part of the overall set of data needed to help improve routing security, but they are a critical first step. Given this model, a ROA is generated by the entity listed as the resource holder, because that entity is the one who chooses the ISP(s) that originate the route (i.e., is the origin AS in BGP terms) for the prefix (ignoring for the moment the issue of route aggregation). A resource holder might ask the RIR (or NIR or ISP) from which a resource was allocated to manage the RPKI data on its behalf, but that should be done in a fashion that does not make such "outsourcing" visible to the relying parties processing RPKI data. (Such outsourcing is common for commercial, TTP PKIs as well.) I believe that the folks at APNIC and RIPE have indicated that they are prepared to provide such services for their members. There is not an intent that ROAs represent a substantial departure from the current model, as you suggest. The intent is for a resource holder be able to use a ROA to identify, in a secure, independently verifiable fashion, the identity (in the form of an AS #) of entities authorized to originate routes for the prefix. The IRR databases try to do this, and more, via RPSL entries, but the security there is not as good as what can be achieved via deployment of the RPKI. Hope this helps. Steve _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Tue Oct 7 17:04:42 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9B6A13A6B88; Tue, 7 Oct 2008 17:04:42 -0700 (PDT) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4F37D3A6B88 for ; Tue, 7 Oct 2008 17:04:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.115 X-Spam-Level: X-Spam-Status: No, score=-6.115 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bCUyQExtqXPY for ; Tue, 7 Oct 2008 17:04:40 -0700 (PDT) Received: from outbound.afilias.info (outbound.afilias.info [69.46.124.26]) by core3.amsl.com (Postfix) with ESMTP id 864643A6B85 for ; Tue, 7 Oct 2008 17:04:40 -0700 (PDT) Received: from bmp-336-ms505.wa.yyz2.afilias-ops.info ([10.50.129.111] helo=smtp.afilias.info) by outbound.afilias.info with esmtp (Exim 4.69) (envelope-from ) id 1KnMYE-0001aD-67; Wed, 08 Oct 2008 00:05:14 +0000 Message-ID: <48EBF93E.6070700@ca.afilias.info> Date: Tue, 07 Oct 2008 20:05:18 -0400 From: Brian Dickson User-Agent: Thunderbird 2.0.0.17 (Macintosh/20080914) MIME-Version: 1.0 To: Geoff Huston References: <513C369E-B21F-42CE-A721-61C258DC15D7@apnic.net> <48EAA23F.6030609@ca.afilias.info> <7D283111-5FAC-450F-8F15-18139A89F8C8@apnic.net> <48EB02AC.60503@ca.afilias.info> <48EB6D8F.3070800@bbn.com> <48EBC117.5000402@ca.afilias.info> <74E7AAAC-9EFE-447D-A466-1934E18EB873@apnic.net> <48EBCE5B.2090006@ca.afilias.info> In-Reply-To: X-Authenticated: True Cc: sidr@ietf.org Subject: Re: [sidr] ROA representation and examples (was Re: Resolving the issues in the roa-format draft) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org Geoff Huston wrote: > > I'm not arguing for or against this - I'm attempting to understand the > precise nature of the difference. > > Its my understanding so far that the two representations are > isomorphic - nothing expressible in one notation is inexpressible in > the other. The only difference _as far as I can see_ lies in the size > of the ROA in expressing sets of prefixes, and as far as I can see a > set of conjoined prefixes with the same maximal length constraint > would have a more compact representation with a min length parameter. > Or am I missing something still in my understanding of this? No, that is it. (Other than the intrinsic self-documenting nature of the compact representation, vs the expansion thereof.) There are subtleties lost when enumeration is the only solution. My favorite example of succinct and subtle was in Terminator 2: "How many cops are there?" "All of them, I think." Brian _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Fri Oct 10 07:58:24 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E55D23A6A7D; Fri, 10 Oct 2008 07:58:24 -0700 (PDT) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1170A3A6A7D for ; Fri, 10 Oct 2008 07:58:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.524 X-Spam-Level: X-Spam-Status: No, score=-2.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h0beQ6F+LDIc for ; Fri, 10 Oct 2008 07:58:23 -0700 (PDT) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by core3.amsl.com (Postfix) with ESMTP id 307BE3A69FF for ; Fri, 10 Oct 2008 07:58:23 -0700 (PDT) Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.13.5/8.13.5) with ESMTP id m9AEwvqG019648 for ; Fri, 10 Oct 2008 09:58:57 -0500 Received: from nemo.columbia.ads.sparta.com (nemo.columbia.sparta.com [157.185.80.75]) by Beta5.sparta.com (8.12.11/8.13.1) with ESMTP id m9AEwwS3024930 for ; Fri, 10 Oct 2008 09:58:58 -0500 Received: from SANDYM-LT.columbia.ads.sparta.com ([157.185.81.151]) by nemo.columbia.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Fri, 10 Oct 2008 10:58:57 -0400 Date: Fri, 10 Oct 2008 10:58:56 -0400 (Eastern Daylight Time) From: Sandra Murphy To: sidr@ietf.org Message-ID: X-X-Sender: sandy@nemo.columbia.sparta.com MIME-Version: 1.0 X-OriginalArrivalTime: 10 Oct 2008 14:58:57.0283 (UTC) FILETIME=[B87E3D30:01C92AE8] Subject: [sidr] request for wg adoption X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org Terry Manderson submitted a new draft "RPKI Repository Retrieval Mechanism" in repsonse to comments received. The draft is available at http://www.ietf.org/internet-drafts/draft-manderson-sidr-fetch-00.txt. He asks for adoption of the draft as a sidr work item. I'm opening the question of whether this should be adopted as a wg work item. Please respond, indicating whether you are for or against adoption and whether you would participate in that work. The question is open for two weeks. Respond by Friday, Oct 22. --Sandy _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Sun Oct 12 17:58:49 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 982373A6A0D; Sun, 12 Oct 2008 17:58:49 -0700 (PDT) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1AD9E3A6AE8 for ; Sun, 12 Oct 2008 17:58:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KQurCo7JUZQ2 for ; Sun, 12 Oct 2008 17:58:47 -0700 (PDT) Received: from mint.apnic.net (mint.apnic.net [202.12.29.58]) by core3.amsl.com (Postfix) with ESMTP id E6DBF3A6A0D for ; Sun, 12 Oct 2008 17:58:46 -0700 (PDT) Received: from [202.12.29.166] (dhcp166.apnic.net [202.12.29.166]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mint.apnic.net (Postfix) with ESMTP id B64D3D5F33; Mon, 13 Oct 2008 10:59:31 +1000 (EST) Message-ID: <48F29D73.9030408@apnic.net> Date: Mon, 13 Oct 2008 10:59:31 +1000 From: Robert Loomans Organization: APNIC - http://www.apnic.net/ User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.0.9) Gecko/20061207 Thunderbird/1.5.0.9 Mnenhy/0.7.4.666 MIME-Version: 1.0 To: Sandra Murphy References: In-Reply-To: X-Enigmail-Version: 0.95.7 OpenPGP: id=C6B3AE7E; url=http://robert.loomans.org/0xC6B3AE7E.asc Cc: sidr@ietf.org Subject: Re: [sidr] request for wg adoption X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1771970137==" Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org This is a cryptographically signed message in MIME format. --===============1771970137== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms030306090506020106000402" This is a cryptographically signed message in MIME format. --------------ms030306090506020106000402 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Sandra Murphy wrote: > Terry Manderson submitted a new draft "RPKI Repository Retrieval > Mechanism" in repsonse to comments received. The draft is available at > http://www.ietf.org/internet-drafts/draft-manderson-sidr-fetch-00.txt. > > He asks for adoption of the draft as a sidr work item. > > I'm opening the question of whether this should be adopted as a wg work > item. Please respond, indicating whether you are for or against > adoption and whether you would participate in that work. > > The question is open for two weeks. Respond by Friday, Oct 22. I'm for adoption: I would like to see the idea explored. I will participate in any discussion. Rob -- Robert Loomans Email: robertl@apnic.net Senior Software Engineer, APNIC Phone: +61 7 3858 3100 http://www.apnic.net Fax: +61 7 3858 3199 --------------ms030306090506020106000402 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIK5jCC BW8wggRXoAMCAQICAiMDMA0GCSqGSIb3DQEBBQUAMIGOMQswCQYDVQQGEwJBVTEOMAwGA1UE ChMFQVBOSUMxGzAZBgNVBAsTElRlY2huaWNhbCBTZXJ2aWNlczEuMCwGA1UEAxMlQVBOSUMg Q2VydGlmaWNhdGlvbiBBdXRob3JpdHkgTWFuYWdlcjEiMCAGCSqGSIb3DQEJARYTY2FtYW5h Z2VyQGFwbmljLm5ldDAeFw0wNzEwMjUwNjMxMDBaFw0wODEwMjQwNjMxMDBaMEgxCzAJBgNV BAYTAkFQMREwDwYDVQQKEwhBUE5JQy1BUDEXMBUGA1UEAxMOUm9iZXJ0IExvb21hbnMxDTAL BgNVBAUTBDg5NjMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDcSon3OuumUDjF QP4OmyB73NE86ZN+/IMs8CmJ2f4k9RCns8CJ3CL/PO+OIcCq/+H9QJwfYUeKFqenx4/l/DWs 02JKEd4Kwap6eYMUxfbLffW+prRdBJjFYo6N03bGOu6CSU5AOT8AlFXu5D2kWFLzD3YjYgkH 0PvpZNWiV3uBqhItdPpgBqeBXtFMRpgfkK8YwyHol5Ger6N9fB1OqzIk6t963uI3zAD2U2wR 7r2SJDQ8SXiUJy5Mx853CqS5/IROi0kELuxE7/rPEIGEAasiFX167dRQ6WLMZqvkljICkIU+ uyZcsqAE7VVX0rRKeOa+K3UoFkPqOeda4yp7dXt/AgMBAAGjggIaMIICFjAJBgNVHRMEAjAA MBEGCWCGSAGG+EIBAQQEAwIFoDALBgNVHQ8EBAMCBeAwJwYJYIZIAYb4QgENBBoWGEFQTklD IENsaWVudCBDZXJ0aWZpY2F0ZTAdBgNVHQ4EFgQUKEo+2/IFBV8W2/KazvPHSH7jSJIwgbsG A1UdIwSBszCBsIAUFIYCsK64S7Hv0+vi+5IohXeMBOmhgZSkgZEwgY4xCzAJBgNVBAYTAkFV MQ4wDAYDVQQKEwVBUE5JQzEbMBkGA1UECxMSVGVjaG5pY2FsIFNlcnZpY2VzMS4wLAYDVQQD EyVBUE5JQyBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSBNYW5hZ2VyMSIwIAYJKoZIhvcNAQkB FhNjYW1hbmFnZXJAYXBuaWMubmV0ggEAMBwGA1UdEQQVMBOBEXJvYmVydGxAYXBuaWMubmV0 MB4GA1UdEgQXMBWBE2NhbWFuYWdlckBhcG5pYy5uZXQwNwYDVR0fBDAwLjAsoCqgKIYmaHR0 cHM6Ly93d3cuYXBuaWMubmV0L2NhL2NybC9jYWNybC5jcmwwNQYJYIZIAYb4QgEEBCgWJmh0 dHBzOi8vd3d3LmFwbmljLm5ldC9jYS9jcmwvY2FjcmwuY3JsMDUGCWCGSAGG+EIBAwQoFiZo dHRwczovL3d3dy5hcG5pYy5uZXQvY2EvY3JsL2NhY3JsLmNybDANBgkqhkiG9w0BAQUFAAOC AQEAhtnqJUiql+tfUKqvezpfcla+4EX3DSkz8E5Kfru7UiyEdZCwm3F6ou2rRz6LNDQUqQYq 32x4R8YHDgfUwq8nkQh9kfpOq5FDBJ7eKrKMSgcZrl4Q8AbkpFIBj9L4B0ymjyy2wWYA0tiC gPx/wQ72Eyj6DNdhCU/6Fsr6saTPKFn2OC7d9OwCey57/z08ih1/7A58mhk1AnrlWd4NUQgk f2Qk5n8RiNEpzzvm1cQbNOydfDfe1DRUYvcBkHkDNtB1bs1twDFTYH4z3wdU8evWqV6FUcKT H3fAz9RQC3zprZZK4AWxXqfsb1C3T4aStx+biDOhUO3OCbE1kbd0mi0hQjCCBW8wggRXoAMC AQICAiMDMA0GCSqGSIb3DQEBBQUAMIGOMQswCQYDVQQGEwJBVTEOMAwGA1UEChMFQVBOSUMx GzAZBgNVBAsTElRlY2huaWNhbCBTZXJ2aWNlczEuMCwGA1UEAxMlQVBOSUMgQ2VydGlmaWNh dGlvbiBBdXRob3JpdHkgTWFuYWdlcjEiMCAGCSqGSIb3DQEJARYTY2FtYW5hZ2VyQGFwbmlj Lm5ldDAeFw0wNzEwMjUwNjMxMDBaFw0wODEwMjQwNjMxMDBaMEgxCzAJBgNVBAYTAkFQMREw DwYDVQQKEwhBUE5JQy1BUDEXMBUGA1UEAxMOUm9iZXJ0IExvb21hbnMxDTALBgNVBAUTBDg5 NjMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDcSon3OuumUDjFQP4OmyB73NE8 6ZN+/IMs8CmJ2f4k9RCns8CJ3CL/PO+OIcCq/+H9QJwfYUeKFqenx4/l/DWs02JKEd4Kwap6 eYMUxfbLffW+prRdBJjFYo6N03bGOu6CSU5AOT8AlFXu5D2kWFLzD3YjYgkH0PvpZNWiV3uB qhItdPpgBqeBXtFMRpgfkK8YwyHol5Ger6N9fB1OqzIk6t963uI3zAD2U2wR7r2SJDQ8SXiU Jy5Mx853CqS5/IROi0kELuxE7/rPEIGEAasiFX167dRQ6WLMZqvkljICkIU+uyZcsqAE7VVX 0rRKeOa+K3UoFkPqOeda4yp7dXt/AgMBAAGjggIaMIICFjAJBgNVHRMEAjAAMBEGCWCGSAGG +EIBAQQEAwIFoDALBgNVHQ8EBAMCBeAwJwYJYIZIAYb4QgENBBoWGEFQTklDIENsaWVudCBD ZXJ0aWZpY2F0ZTAdBgNVHQ4EFgQUKEo+2/IFBV8W2/KazvPHSH7jSJIwgbsGA1UdIwSBszCB sIAUFIYCsK64S7Hv0+vi+5IohXeMBOmhgZSkgZEwgY4xCzAJBgNVBAYTAkFVMQ4wDAYDVQQK EwVBUE5JQzEbMBkGA1UECxMSVGVjaG5pY2FsIFNlcnZpY2VzMS4wLAYDVQQDEyVBUE5JQyBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSBNYW5hZ2VyMSIwIAYJKoZIhvcNAQkBFhNjYW1hbmFn ZXJAYXBuaWMubmV0ggEAMBwGA1UdEQQVMBOBEXJvYmVydGxAYXBuaWMubmV0MB4GA1UdEgQX MBWBE2NhbWFuYWdlckBhcG5pYy5uZXQwNwYDVR0fBDAwLjAsoCqgKIYmaHR0cHM6Ly93d3cu YXBuaWMubmV0L2NhL2NybC9jYWNybC5jcmwwNQYJYIZIAYb4QgEEBCgWJmh0dHBzOi8vd3d3 LmFwbmljLm5ldC9jYS9jcmwvY2FjcmwuY3JsMDUGCWCGSAGG+EIBAwQoFiZodHRwczovL3d3 dy5hcG5pYy5uZXQvY2EvY3JsL2NhY3JsLmNybDANBgkqhkiG9w0BAQUFAAOCAQEAhtnqJUiq l+tfUKqvezpfcla+4EX3DSkz8E5Kfru7UiyEdZCwm3F6ou2rRz6LNDQUqQYq32x4R8YHDgfU wq8nkQh9kfpOq5FDBJ7eKrKMSgcZrl4Q8AbkpFIBj9L4B0ymjyy2wWYA0tiCgPx/wQ72Eyj6 DNdhCU/6Fsr6saTPKFn2OC7d9OwCey57/z08ih1/7A58mhk1AnrlWd4NUQgkf2Qk5n8RiNEp zzvm1cQbNOydfDfe1DRUYvcBkHkDNtB1bs1twDFTYH4z3wdU8evWqV6FUcKTH3fAz9RQC3zp rZZK4AWxXqfsb1C3T4aStx+biDOhUO3OCbE1kbd0mi0hQjGCA8YwggPCAgEBMIGVMIGOMQsw CQYDVQQGEwJBVTEOMAwGA1UEChMFQVBOSUMxGzAZBgNVBAsTElRlY2huaWNhbCBTZXJ2aWNl czEuMCwGA1UEAxMlQVBOSUMgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgTWFuYWdlcjEiMCAG CSqGSIb3DQEJARYTY2FtYW5hZ2VyQGFwbmljLm5ldAICIwMwCQYFKw4DAhoFAKCCAgUwGAYJ KoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDgxMDEzMDA1OTMxWjAj BgkqhkiG9w0BCQQxFgQUbgh/D+a6pb80KSHGzLzqlhcUqqswUgYJKoZIhvcNAQkPMUUwQzAK BggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYI KoZIhvcNAwICASgwgaYGCSsGAQQBgjcQBDGBmDCBlTCBjjELMAkGA1UEBhMCQVUxDjAMBgNV BAoTBUFQTklDMRswGQYDVQQLExJUZWNobmljYWwgU2VydmljZXMxLjAsBgNVBAMTJUFQTklD IENlcnRpZmljYXRpb24gQXV0aG9yaXR5IE1hbmFnZXIxIjAgBgkqhkiG9w0BCQEWE2NhbWFu YWdlckBhcG5pYy5uZXQCAiMDMIGoBgsqhkiG9w0BCRACCzGBmKCBlTCBjjELMAkGA1UEBhMC QVUxDjAMBgNVBAoTBUFQTklDMRswGQYDVQQLExJUZWNobmljYWwgU2VydmljZXMxLjAsBgNV BAMTJUFQTklDIENlcnRpZmljYXRpb24gQXV0aG9yaXR5IE1hbmFnZXIxIjAgBgkqhkiG9w0B CQEWE2NhbWFuYWdlckBhcG5pYy5uZXQCAiMDMA0GCSqGSIb3DQEBAQUABIIBANAA+lO9D5DH /LCjsMD6CJuZKPJ0l9HFPd/b9uY8v2J64iDF7IP5JAzmQEzPi9bOMn6KETmdSjmNLzx2BbV3 RkmeTr0z3LGsf4apCXCR76Kb+abH+6L0PY+RFNcXv4yqYZnWUef++JWONJaK4qg6XHMbzQ9R iavN8Q9BWGR0ES08ZdxzwUgdBKlQa2vcPt2m9BN1HYoSss3EBvw64fHrLXR7nrPz2+RT6Hcw 4bc0Dr6d/R32d2lS9CdmueSIX3y00cu/CfkyifrCFUOpWchwzzS1cPQDTHlGXA37r6u5gDqx PCtqku62n+NZZwVpLNd3zmsXWctFXTLBtiV0+FpdOBsAAAAAAAA= --------------ms030306090506020106000402-- --===============1771970137== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr --===============1771970137==-- From sidr-bounces@ietf.org Mon Oct 13 13:32:03 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2E5623A6992; Mon, 13 Oct 2008 13:32:03 -0700 (PDT) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 90F263A699A for ; Mon, 13 Oct 2008 13:32:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.717 X-Spam-Level: X-Spam-Status: No, score=-2.717 tagged_above=-999 required=5 tests=[AWL=-0.118, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e4-HgE-FXdHQ for ; Mon, 13 Oct 2008 13:32:00 -0700 (PDT) Received: from mx3.bbn.com (mx3.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id 974D73A6951 for ; Mon, 13 Oct 2008 13:32:00 -0700 (PDT) Received: from dhcp89-089-071.bbn.com ([128.89.89.71]) by mx3.bbn.com with esmtp (Exim 4.63) (envelope-from ) id 1KpU5S-0003IS-Ab; Mon, 13 Oct 2008 16:32:18 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <20080813152039.AF3453F462@pecan.tislabs.com> <20080902215154.A80872282B@thrintun.hactrn.net> Date: Mon, 13 Oct 2008 16:33:08 -0400 To: Geoff Huston From: Stephen Kent Cc: Rob Austein , sidr@ietf.org Subject: Re: [sidr] WG LC on draft-ietf-sidr-rpki-manifests-02.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org Geoff & Rob, First, my recollection is that we decided that the cert for a manifest appears only in the manifest data structure, which still seems like a useful simplification. So, I suggest that this EE cert appear only in this location, and this not have its own publication point. That does require that the cert be used ONLY for manifest validation. In the terminology Geoff crafted for the manifest I-D, this makes the EE cert for a manifest a single-use cert, (optionally a sequential use cert) even if it is not a one-time-use cert. Geoff's message emphasized reuse of the private key, but Rob's message emphasized the desire to not have to put the manifest EE cert on a CRL if a manifest is reissued one or more times before its next scheduled issuance time. There was no mention of the validity interval is for this cert in either Geoff's or Rob's messages. For a one-time-use cert, the manifest I-D suggests that the EE cert lifetime match that of the manifest. That will cause each new EE to be on the CRL until the matching manifest expires, when a manifest is issued before the nextUpdate time. Presumably this is what triggered Rob's concern. The manifest I-D does not provide (useful) guidance for the validity period for a sequential-use EE cert associated with a manifest. Presumably the validity period will be longer than that anticipated for the manifest, else it makes no sense to view this as a sequential-use cert. So, it appears to me that a sequential-use, single-use cert satisfies Rob's concern about CRL growth. The primary security rationale for revoking the EE cert for a manifest when a new manifest is issued is to alert RPs of the manifest change. The argument is that the revoked EE cert for the manifest will appear on the CRL, and RPs will thus know not to accept the old manifest. This argument presumes that RPs will acquire the new CRL in orders to perform this check. However, if an attacker replaces the new manifest and new CRL with the older, not yet expired versions, RPs will not be able to tell the difference, so the cited rationale is not a good one. This suggests that a sequential-use EE cert for the manifest is just as secure as a one-time-use cert, relative to the unscheduled manifest change case. Given this observation, I suggest that we mandate that the manifest nextUpdate value and the nextUpdate value in the CRL that covers the EE cert used to verify the manifest be the same. Otherwise, if the CRL is scheduled to be reissued before the manifest, the manifest will have to be reissued at that time, so that it contains the current CRL hash value, and we'll create a preventable stale manifest problem. (I also suggest that this analysis be included in the manifest I-D.) If CRL and manifest issuance are synchronized, as suggested above, then a sequential-use EE cert for a manifest can safely have a lifetime that spans multiple manifests. The primary argument for one-time-use EE certs for manifests, is the same as for ROAs, i.e., the underlying private key can be forgotten after use, making the system somewhat safer as a result. As for terminology, a CA is an entity, a CA cert is not. We can talk about the current CRL issued by a CA and verified using the CA's cert, but a manifest is issued by a CA (through an EE representing the CA), nit by a CA cert. Finaly, the document has LOTS of instances where is refers to objects signed by a given cert. This has to be fixed, as certs are not used to sign objects; they are used to verify signed objects. I'l, send Geoff a marked up version of the manifest I-D with some of the edits based on my comments above. Steve _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Tue Oct 14 08:25:29 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B296A3A6C09; Tue, 14 Oct 2008 08:25:29 -0700 (PDT) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D21BB3A6C09 for ; Tue, 14 Oct 2008 08:25:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.539 X-Spam-Level: X-Spam-Status: No, score=-2.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mZmDnVAfRxqB for ; Tue, 14 Oct 2008 08:25:27 -0700 (PDT) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by core3.amsl.com (Postfix) with ESMTP id 4891E3A68B2 for ; Tue, 14 Oct 2008 08:25:27 -0700 (PDT) Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.13.5/8.13.5) with ESMTP id m9EFOkh2023184 for ; Tue, 14 Oct 2008 10:24:46 -0500 Received: from nemo.columbia.ads.sparta.com (nemo.columbia.sparta.com [157.185.80.75]) by Beta5.sparta.com (8.12.11/8.13.1) with ESMTP id m9EFOhpT013456 for ; Tue, 14 Oct 2008 10:24:43 -0500 Received: from SANDYM-LT.columbia.ads.sparta.com ([192.168.1.117]) by nemo.columbia.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Tue, 14 Oct 2008 11:24:42 -0400 Date: Tue, 14 Oct 2008 11:24:42 -0400 (Eastern Daylight Time) From: Sandra Murphy To: sidr@ietf.org Message-ID: X-X-Sender: sandy@nemo.columbia.sparta.com MIME-Version: 1.0 X-OriginalArrivalTime: 14 Oct 2008 15:24:43.0016 (UTC) FILETIME=[FB796080:01C92E10] Subject: [sidr] resuming last call on draft-ietf-sidr-res-certs-13.txt (fwd) X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org A reminder. Tomorrow is the last day for comments on the res-certs draft. Please take a moment to check this out for comments. --Sandy ---------- Forwarded message ---------- Date: Wed, 1 Oct 2008 16:07:02 -0400 (Eastern Daylight Time) From: Sandra Murphy To: sidr@ietf.org Subject: resuming last call on draft-ietf-sidr-res-certs-13.txt Geoff Huston submitted a new version of the res-certs draft which responds to comments received on the list and contains new text about trust anchors. I am issuing a working group last call on this draft. The last call will end Wed, Oct 15. Differences in terminology and language are scattered througout. The largest changes are the new trust anchor language in section 6, a new section 7 on Design Notes, and a new appendix on the CMS profile for trust anchor material. The previous last call was the -11 version. There was a short-lived -12 version in between. If you would like to see the differences between the -11 version and the -13 version, try the following URL: http://tools.ietf.org/rfcdiff?url1=http://tools.ietf.org/id/draft-ietf-sidr-res-certs-13.txt&url2=http://tools.ietf.org/id/draft-ietf-sidr-res-certs-11.txt This produces a side-by-side diff. If you prefer one of the other diff styles offered by the tools site, type the appropriate URLs into: http://tools.ietf.org/rfcdiff where the appropriate URLs are: http://tools.ietf.org/id/draft-ietf-sidr-res-certs-13.txt http://tools.ietf.org/id/draft-ietf-sidr-res-certs-11.txt --Sandy _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Tue Oct 14 11:58:12 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 22A9B3A693F; Tue, 14 Oct 2008 11:58:12 -0700 (PDT) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 314C03A63EC for ; Tue, 14 Oct 2008 11:58:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B7eByZ+nwNoQ for ; Tue, 14 Oct 2008 11:58:10 -0700 (PDT) Received: from davinci.fing.edu.uy (smtp.fing.edu.uy [164.73.32.2]) by core3.amsl.com (Postfix) with ESMTP id D9E733A693F for ; Tue, 14 Oct 2008 11:58:08 -0700 (PDT) Received: from Kate.dhcp.nanog.merit.net (Kate.dhcp.nanog.merit.net [192.35.166.35]) (authenticated bits=0) by davinci.fing.edu.uy with ESMTP id m9EIw4vp018770 for ; Tue, 14 Oct 2008 16:58:07 -0200 (UYST) Message-Id: <6AABDAB8-6CCB-41D6-8EF1-52548EBB7666@fing.edu.uy> From: Roque Gagliano To: sidr@ietf.org In-Reply-To: Mime-Version: 1.0 (Apple Message framework v929.2) Date: Tue, 14 Oct 2008 16:57:58 -0200 References: X-Pgp-Agent: GPGMail d51 (Leopard) X-Mailer: Apple Mail (2.929.2) X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-3.0 (davinci.fing.edu.uy [164.73.32.2]); Tue, 14 Oct 2008 16:58:08 -0200 (UYST) X-Scanned-By: MIMEDefang 2.58 on 164.73.32.2 Subject: Re: [sidr] request for wg adoption X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0934029889==" Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============0934029889== Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-65-890342876" Content-Transfer-Encoding: 7bit This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-65-890342876 Content-Type: multipart/alternative; boundary=Apple-Mail-64-890342859 --Apple-Mail-64-890342859 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit I do support this draft become WG item as a different fetching mechanism. I believe a reference to section 4.3 of the architecture draft (Access protocols) should be added in order to be sure that the proposed protocol complies with all the requirements stated there. Roque On Oct 10, 2008, at 12:58 PM, Sandra Murphy wrote: > Terry Manderson submitted a new draft "RPKI Repository Retrieval > Mechanism" in repsonse to comments received. The draft is available > at > http://www.ietf.org/internet-drafts/draft-manderson-sidr-fetch-00.txt. > > He asks for adoption of the draft as a sidr work item. > > I'm opening the question of whether this should be adopted as a wg > work item. Please respond, indicating whether you are for or > against adoption and whether you would participate in that work. > > The question is open for two weeks. Respond by Friday, Oct 22. > > --Sandy > > > _______________________________________________ > sidr mailing list > sidr@ietf.org > https://www.ietf.org/mailman/listinfo/sidr --Apple-Mail-64-890342859 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable I do support this draft become = WG item as a different fetching mechanism.

I believe = a reference to section 4.3 of the architecture draft (Access protocols) = should be added in order to be sure that the proposed protocol complies = with all the requirements stated = there.

Roque


<= div>
On Oct 10, 2008, at 12:58 PM, Sandra Murphy = wrote:

Terry Manderson submitted a new draft "RPKI = Repository Retrieval Mechanism" in repsonse to comments received. =  The draft is available at
http://www.ietf.org/internet-drafts/draft-manderson-sidr-fetch-00.txt= .

He asks for adoption of the draft as a sidr work = item.

I'm opening the question of whether this should be adopted = as a wg work item.  Please respond, indicating whether you are for = or against adoption and whether you would participate in that = work.

The question is open for two weeks.  Respond by = Friday, Oct = 22.

--Sandy


____________________________________________= ___
sidr mailing list
sidr@ietf.org
https://www.ietf.org/m= ailman/listinfo/sidr

= --Apple-Mail-64-890342859-- --Apple-Mail-65-890342876 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAkj067YACgkQnk+WSgHpbO5ouACgnF0QtTvrsllabZ0EsxmdiJFs XywAnjKC9Q6wYQgtVzTGXgQtBpUi+zpc =tajx -----END PGP SIGNATURE----- --Apple-Mail-65-890342876-- --===============0934029889== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr --===============0934029889==-- From sidr-bounces@ietf.org Wed Oct 15 12:07:56 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0B0A03A67B2; Wed, 15 Oct 2008 12:07:56 -0700 (PDT) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 39CE53A67A8 for ; Wed, 15 Oct 2008 12:07:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V7RGkz1Q5Neu for ; Wed, 15 Oct 2008 12:07:51 -0700 (PDT) Received: from smtp.nist.gov (rimp2.nist.gov [129.6.16.227]) by core3.amsl.com (Postfix) with ESMTP id D6D473A67EF for ; Wed, 15 Oct 2008 12:07:50 -0700 (PDT) Received: from postmark.nist.gov (emailha1.nist.gov [129.6.16.196]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id m9FJ8aI2002259; Wed, 15 Oct 2008 15:08:36 -0400 Received: from st26.ncsl.nist.gov (st26.ncsl.nist.gov [129.6.54.72]) by postmark.nist.gov (8.13.1/8.13.1) with ESMTP id m9FJ8SF3006475; Wed, 15 Oct 2008 15:08:28 -0400 Message-ID: <48F63F97.3070504@nist.gov> Date: Wed, 15 Oct 2008 15:08:07 -0400 From: "David A. Cooper" User-Agent: Thunderbird 2.0.0.17 (X11/20080926) MIME-Version: 1.0 To: Sandra Murphy References: In-Reply-To: X-NIST-MailScanner-Information: X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: david.cooper@nist.gov Cc: sidr@ietf.org Subject: Re: [sidr] request for wg adoption X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org I believe this document should become a WG work item. Dave Sandra Murphy wrote: > Terry Manderson submitted a new draft "RPKI Repository Retrieval > Mechanism" in repsonse to comments received. The draft is available at > http://www.ietf.org/internet-drafts/draft-manderson-sidr-fetch-00.txt. > > He asks for adoption of the draft as a sidr work item. > > I'm opening the question of whether this should be adopted as a wg > work item. Please respond, indicating whether you are for or against > adoption and whether you would participate in that work. > > The question is open for two weeks. Respond by Friday, Oct 22. > > --Sandy _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Fri Oct 17 07:29:11 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8116C3A6A65; Fri, 17 Oct 2008 07:29:11 -0700 (PDT) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CA1C83A6A65 for ; Fri, 17 Oct 2008 07:29:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HnxRxXKwHJ2Q for ; Fri, 17 Oct 2008 07:29:10 -0700 (PDT) Received: from smtp1.arin.net (smtp1.arin.net [IPv6:2001:500:4:13::33]) by core3.amsl.com (Postfix) with ESMTP id E2F833A6826 for ; Fri, 17 Oct 2008 07:29:09 -0700 (PDT) Received: by smtp1.arin.net (Postfix, from userid 323) id DD8A36FE99; Fri, 17 Oct 2008 10:24:53 -0400 (EDT) Received: from ex.arin.net (ex.arin.net [192.136.136.237]) by smtp1.arin.net (Postfix) with ESMTP id 3CEE46FE92; Fri, 17 Oct 2008 10:24:47 -0400 (EDT) Received: from EDAMAME.arin.net ([192.136.136.194]) by ex.arin.net ([192.136.136.237]) with mapi; Fri, 17 Oct 2008 10:30:06 -0400 From: Andy Newton To: Sandra Murphy , "sidr@ietf.org" Date: Fri, 17 Oct 2008 10:30:04 -0400 Thread-Topic: [sidr] request for wg adoption Thread-Index: Ackq6McuzwBMvGFpS1KpjbAO5tuB4wFfBEWF Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Subject: Re: [sidr] request for wg adoption X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org I'm not opposed to this idea, though I still don't know how this will shake out against rsync. Frankly, it would be simpler if there were just one mechanism, and perhaps that question ought to be asked of the working group. I do not think we are doing the broader community any favors by specifying two methods. I share the discomfort some people have with rsync and feel that an HTTP approach would be easier to troubleshoot and manipulate operationally. That being said, this draft does not appear to be revised with feedback from the last IETF. Without clarification and modification, the algorithm specified in this draft would have serious performance issues with HTTPS. So, when are we expecting a draft revision that addresses this issue and the others brought forward in Dublin? -andy On 10/10/08 10:58 AM, "Sandra Murphy" wrote: > Terry Manderson submitted a new draft "RPKI Repository Retrieval > Mechanism" in repsonse to comments received. The draft is available at > http://www.ietf.org/internet-drafts/draft-manderson-sidr-fetch-00.txt. > > He asks for adoption of the draft as a sidr work item. > > I'm opening the question of whether this should be adopted as a wg work > item. Please respond, indicating whether you are for or against > adoption and whether you would participate in that work. > > The question is open for two weeks. Respond by Friday, Oct 22. > > --Sandy > > > _______________________________________________ > 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 sidr-bounces@ietf.org Fri Oct 17 09:52:53 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B13A83A6781; Fri, 17 Oct 2008 09:52:53 -0700 (PDT) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 56B023A6780 for ; Fri, 17 Oct 2008 09:52:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mhoBeYvtgZlQ for ; Fri, 17 Oct 2008 09:52:51 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by core3.amsl.com (Postfix) with ESMTP id 87BBB3A6781 for ; Fri, 17 Oct 2008 09:52:51 -0700 (PDT) Received: from rmac.dhcp.nanog.merit.net ([192.35.165.20] helo=rmac.psg.com) by ran.psg.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KqsaG-000Jst-ET; Fri, 17 Oct 2008 16:53:52 +0000 Message-ID: <48F8C320.20904@psg.com> Date: Fri, 17 Oct 2008 09:53:52 -0700 From: Randy Bush User-Agent: Thunderbird 2.0.0.17 (Macintosh/20080914) MIME-Version: 1.0 To: Andy Newton References: In-Reply-To: X-Enigmail-Version: 0.95.7 Cc: "sidr@ietf.org" Subject: Re: [sidr] request for wg adoption X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org > That being said, this draft does not appear to be revised with feedback from > the last IETF. Without clarification and modification, the algorithm > specified in this draft would have serious performance issues with HTTPS. > So, when are we expecting a draft revision that addresses this issue and the > others brought forward in Dublin? when will there be running code we can actually compare? randy _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Fri Oct 17 10:43:55 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 15C2B3A69B3; Fri, 17 Oct 2008 10:43:55 -0700 (PDT) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 059983A69B3 for ; Fri, 17 Oct 2008 10:43:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q-GNcaRzvErc for ; Fri, 17 Oct 2008 10:43:52 -0700 (PDT) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by core3.amsl.com (Postfix) with ESMTP id 9E3173A6814 for ; Fri, 17 Oct 2008 10:43:52 -0700 (PDT) Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.13.5/8.13.5) with ESMTP id m9HHiuTP009557 for ; Fri, 17 Oct 2008 12:44:56 -0500 Received: from nemo.columbia.ads.sparta.com (nemo.columbia.sparta.com [157.185.80.75]) by Beta5.sparta.com (8.12.11/8.13.1) with ESMTP id m9HHiuHG004810 for ; Fri, 17 Oct 2008 12:44:56 -0500 Received: from SANDYM-LT.columbia.ads.sparta.com ([192.35.166.11]) by nemo.columbia.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Fri, 17 Oct 2008 13:44:55 -0400 Date: Fri, 17 Oct 2008 13:44:54 -0400 (Eastern Daylight Time) From: Sandra Murphy To: sidr@ietf.org Message-ID: X-X-Sender: sandy@nemo.columbia.sparta.com MIME-Version: 1.0 X-OriginalArrivalTime: 17 Oct 2008 17:44:55.0439 (UTC) FILETIME=[10E881F0:01C93080] Subject: [sidr] Manifests and the Repository Structure X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org The repository structure document reads: in section 2.2: Becuase a CA is associated with a single key pair an entity performss the equivalent of a key rollover operation by generating a new CA instance as well as a new key pair. In such cases the entity may chose to continue of use a single repository publication point for both CA instances. In such cases the repository publication pooint will contain the CRL, manifest and subordinate certificates of both CA instances. In section 2.3, which is talking about multi-use EE certificates It is consistent with this specification, but not recommended practice, that all subordinate EE certificates of a given CA share a common publication repository. In this case the repository publication point would contain multiple manifest objects, one for each EE certificate that has placed objects into this common publication point. Each manifest is limited in scope to listing the objects signed by the EE certificate. In section 3: o Each CA publication directory in the publication repository should contain the products of this CA, including those objects signed by single-use EE certificates that have been issued by this CA. The signed products of related CA's that are operated by the same entity may share the CA publication directory. Aside from subdirectories, no other objects should be placed in a publication repository directory. Rob Austein's message of 19 Sep 2008 says: >The problem is that the manifest is a not a listing of the active >entity's outputs, it's a listing of the outputs issued by a particular >CA certificate. Now that David has finished beating us up about the >term "rollover", the mapping from CA to CA certificate is 1:1, just to >further confuse matters, and we lack a good term for the entity that >controls a publication point and maps 1:1 with the publication point. > >There's a subtlety here that may not be obvious (thanks to Sandy for >asking about it): the publication point, in the sense of a filesystem >directory, is common to all current CA certificates in use by this >nameless entity that we used to call a CA. Normally that's exactly >one CA certificate, except during rollover, when both the old and new >CA certificates are valid; now that David has whacked us with proper >PKI terminology, the process that we call rollover is really a process >of generating a new CA and reissuing all of the old CA's products >under the new CA. > >The manifest, however, is specific to a particular CA certificate. >This means that during rollover the manifest will not cover the entire >content of the directory; instead, there will be two certificates, >each with its own manifest, and the two manifests between them will >cover the content of the directory. My question to which Rob refers was about how many manifests exist at a publication point. I think the repository structure and Rob's message indicate that there might be more than one manifest at a publication point, and no one manifest covers all items in the publication point. I don't think that the current text in the manifests draft quite carries that thought completely all the way through. My question to Rob last time was private, I'm taking the risky step of asking the question this time in public. For example, in the intro: A manifest is an object that lists of all of the other signed objects issued by the authority responsible for a publication point in the repository system. Depending on whether "the authority" means what Rob calls "the nameless entity" or "the CA certificate" (plus single use EE certificates signed by the CA cert?) , this would mean either that the manifest lists all the signed objects in the publication point period, or that the manifest lists only those signed objects in the publication point that were signed using just one private key. For the purpose of writing the manifest validation code, I think the difference matters. Section 5.1 on manifest generation says only: 4. Construct the manifest content. Who knew that might need explaining? My first guess at the algorithm is something like: take the EE cert that (refers to the public key that is associated with the private key that) will sign the manifest, take the CA cert that (refers to the public key associated with the private key that) signed the EE cert, and list all signed objects in the publication point that are signed by (the private key yada yada) that CA cert. Except that the repository structure draft in section 2.2 & 3 says that the publication point also includes objects signed by an EE certificate "where the EE certificate was issued by this CA". I believe that means that the manifest object also lists the signed objects associated with EE certs in the publication point that are associated with the CA cert. And in section 8.1, Tests for Determining Manifest State For a given publication point, the relying party should perform the following tests to determine the manifest state of the publication point: 1. Select the manifest having highest manifestNumber among all valid manifests (where manifest validity is defined in Section Section 7). I think this was intended to refer to choosing among manifests you have downloaded, not multiple manifests at the publication point. 3. Check that every file at the publication point appears on the manifest, and that every file on the manifest appears at the publication point. If a manifest lists only those signed objects signed by one particular private key (aka signed by one particular "CA", if I read Rob's message correctly above, or signed by a single use EE cert signed by this same one particular "CA", if I read the repository structure draft correctly), then this language needs to be made more precise, something like: take the EE cert that was used in signing the manifest, take the CA cert that was used in signing the EE cert, and list all signed objects in the publication point that are signed by that CA cert. The repository structure draft in section 2.2 & 3 says that the publication point also includes objects signed by an EE certificate "where the EE certificate was issued by this CA". I believe that means that the manifest object also lists the signed objects associated with EE certs in the publication point that are associated with the CA cert. Yes? That section reads further: * If there exists files at the publication point that do not appear on the manifest, or files on the manifest that do not appear at the publication point then see Section 8.5 but still continue with the following test. If there are several manifests at the publication point, then this branch gets taken every time, right? Section 8.5 Mismatch between Manifest and Publication Point says: If there exist otherwise valid signed objects that do not appear on any manifest, then provided the manifest is not stale (see Section Section 8.4) it is likely that their omission is an error by the publisher. The use of the word "any" here is important and indicates that you only have an error condition if you check all the manifests, which means you must aggregate the results of all the manifests before you decide you have an error. Yes? But objects listed in any one manifest but missing from the publication point constitute an error that you can check in each manifest independently. Right? --Sandy _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Fri Oct 17 23:21:05 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 343133A6A24; Fri, 17 Oct 2008 23:21:05 -0700 (PDT) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 453CA3A6A24 for ; Fri, 17 Oct 2008 23:21:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.561 X-Spam-Level: X-Spam-Status: No, score=-2.561 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5uDSxYXWl8Yn for ; Fri, 17 Oct 2008 23:21:03 -0700 (PDT) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.237]) by core3.amsl.com (Postfix) with ESMTP id 7FC953A6A12 for ; Fri, 17 Oct 2008 23:21:03 -0700 (PDT) Received: by rv-out-0506.google.com with SMTP id b25so793709rvf.49 for ; Fri, 17 Oct 2008 23:22:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:from:to :in-reply-to:content-type:content-transfer-encoding:mime-version :subject:date:references:x-mailer:sender; bh=qYsgrOUYSwKTTC70Prr7teykblwm8tvZDlf8m408djI=; b=tPFRf7Uh8vtww1+h7VRkeg+SLKR7B2S8viVD66Q0H3xTkoWL9v35TAEFbFB/zONGDz l5rNvMNJ+TChg9hkHgFSO2fzh2aKsWELRyLsklrTeZ8ERthCPKZbpmA0b6OgbTGE3Yxt LZLc0QKPOZhznKlYa/Fm36HcLlUHj34YPPSHQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:from:to:in-reply-to:content-type :content-transfer-encoding:mime-version:subject:date:references :x-mailer:sender; b=anyBIhFYVOYB+wLtDXgYLgN40Vum4EgKLWF/M5D0Xa2dhKiZjiSXI6ni/yinaTvBiF ucjwfGqyIwd4bFYkesp66DEarJbGQktJ9mfPB8QSXvuGjp8+rJR9+VE+Enc/WwBUmLGB 2ZO3KIc+dPemiWAXr2XbBFd+pHsTHLuPJ0Lbo= Received: by 10.140.125.1 with SMTP id x1mr3063402rvc.287.1224310929186; Fri, 17 Oct 2008 23:22:09 -0700 (PDT) Received: from ?192.168.1.103? (c58-108-241-164.fitzg1.qld.optusnet.com.au [58.108.241.164]) by mx.google.com with ESMTPS id b39sm5884891rvf.0.2008.10.17.23.22.07 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 17 Oct 2008 23:22:07 -0700 (PDT) Message-Id: From: Terry Manderson To: sidr@ietf.org In-Reply-To: Mime-Version: 1.0 (Apple Message framework v929.2) Date: Sat, 18 Oct 2008 16:22:04 +1000 References: X-Mailer: Apple Mail (2.929.2) Subject: Re: [sidr] request for wg adoption X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org Hi Andy, On 18/10/2008, at 12:30 AM, Andy Newton wrote: > I'm not opposed to this idea, though I still don't know how this > will shake > out against rsync. Frankly, it would be simpler if there were just > one > mechanism, and perhaps that question ought to be asked of the > working group. > I do not think we are doing the broader community any favors by > specifying I'm torn on this. I see the simplicity side and really appreciates that, but I also see the benefits of heterogeneity. > > two methods. I share the discomfort some people have with rsync and > feel > that an HTTP approach would be easier to troubleshoot and manipulate > operationally. > > That being said, this draft does not appear to be revised with > feedback from > the last IETF. Without clarification and modification, the algorithm > specified in this draft would have serious performance issues with > HTTPS. Yes, I didn't "go all the way" on the changes requested - I addressed most, but refrained from some as I felt under-qualified at the time to target some specifics. But I do accept that I need to go further, and willing to to do so under a WG item. > So, when are we expecting a draft revision that addresses this issue > and the > others brought forward in Dublin? > When do you want it? prior to adoption as a WG item? or as a WG item revision? Cheers Terry _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Fri Oct 17 23:28:04 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7C8A43A6A12; Fri, 17 Oct 2008 23:28:04 -0700 (PDT) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 01EB23A67EC for ; Fri, 17 Oct 2008 23:28:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.571 X-Spam-Level: X-Spam-Status: No, score=-2.571 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S0ff27p4a6pP for ; Fri, 17 Oct 2008 23:28:02 -0700 (PDT) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.169]) by core3.amsl.com (Postfix) with ESMTP id 5518D3A6928 for ; Fri, 17 Oct 2008 23:28:02 -0700 (PDT) Received: by wf-out-1314.google.com with SMTP id 27so1105573wfd.31 for ; Fri, 17 Oct 2008 23:28:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:from:to :in-reply-to:content-type:content-transfer-encoding:mime-version :subject:date:references:x-mailer:sender; bh=SD6eEnbNdcrmeCctnRSfS3mbRv0zEFUFA0e7pRPFdhM=; b=xQ7LK4rd6WW3UflT1KjlWhjZQ/9DtSr38pZmuazXdO9uGhutLEZWS5c7YJKbsh+KGL OGk5nbCrMWXDc3Xwt97OVbZLLUyJ9Te85TAm5BXZ2crdPtuSI4WctDzr7KvuKPMSS/aB Bo0UAz6s3sWbcfZnlatcsBzld2A51BOLDq1yQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:from:to:in-reply-to:content-type :content-transfer-encoding:mime-version:subject:date:references :x-mailer:sender; b=MlvI80oEdY3cowCGt4dEXWfOTgG+/O3EZWhngQ1HzBeXgImqR7bP7uwfxlhQXl25go ArZ67qqCIUaYmOuIp+b4soLBJr92H8sVTWiSLjRGA2nDlrh9ERKnYx44AxU9gdFyLWUx SEpHsGB5ZglgrcFDp/Z/HH1u7thiJ7m5UMu6U= Received: by 10.142.141.21 with SMTP id o21mr1840359wfd.213.1224311333435; Fri, 17 Oct 2008 23:28:53 -0700 (PDT) Received: from ?192.168.1.103? (c58-108-241-164.fitzg1.qld.optusnet.com.au [58.108.241.164]) by mx.google.com with ESMTPS id 29sm5513742wfg.0.2008.10.17.23.28.51 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 17 Oct 2008 23:28:52 -0700 (PDT) Message-Id: <843458F0-46FA-45FD-885F-9B034F297819@terrym.net> From: Terry Manderson To: sidr@ietf.org In-Reply-To: <48F8C320.20904@psg.com> Mime-Version: 1.0 (Apple Message framework v929.2) Date: Sat, 18 Oct 2008 16:28:48 +1000 References: <48F8C320.20904@psg.com> X-Mailer: Apple Mail (2.929.2) Subject: Re: [sidr] request for wg adoption X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org On 18/10/2008, at 2:53 AM, Randy Bush wrote: >> > > when will there be running code we can actually compare? Good question. I've been tinkering (note: I am an ops person - not a coder) with some code to do this and over the next few weeks in my spare time I shall tidy it up before it falls under the eyes of the programming 'guns' in the WG. Although, that timeline may not work in for the deadline for the WG Adoption request. Is that then a stopping block for you? Terry _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Sat Oct 18 08:58:55 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7EA153A6ABF; Sat, 18 Oct 2008 08:58:55 -0700 (PDT) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3735B3A6A57 for ; Sat, 18 Oct 2008 08:58:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.49 X-Spam-Level: X-Spam-Status: No, score=-1.49 tagged_above=-999 required=5 tests=[AWL=1.110, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FeTR29prQ9QF for ; Sat, 18 Oct 2008 08:58:53 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by core3.amsl.com (Postfix) with ESMTP id 644503A69A9 for ; Sat, 18 Oct 2008 08:58:53 -0700 (PDT) Received: from [66.28.50.6] (helo=rmac.psg.com) by ran.psg.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1KrEDb-000N6r-Vj; Sat, 18 Oct 2008 15:59:56 +0000 Message-ID: <48FA07FB.2090309@psg.com> Date: Sat, 18 Oct 2008 08:59:55 -0700 From: Randy Bush User-Agent: Thunderbird 2.0.0.17 (Macintosh/20080914) MIME-Version: 1.0 To: Terry Manderson References: <48F8C320.20904@psg.com> <843458F0-46FA-45FD-885F-9B034F297819@terrym.net> In-Reply-To: <843458F0-46FA-45FD-885F-9B034F297819@terrym.net> X-Enigmail-Version: 0.95.7 Cc: sidr@ietf.org Subject: Re: [sidr] request for wg adoption X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org as there are deep suspicions that the http approach will have serious implementation and performance issues, indeed lack of running code is a big blocker in my view. andy is a serious hacker and seems interested. perhaps he can help. randy _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Sat Oct 18 19:36:09 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0ABC93A69E7; Sat, 18 Oct 2008 19:36:09 -0700 (PDT) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C2AD53A69F5 for ; Sat, 18 Oct 2008 19:36:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.276 X-Spam-Level: X-Spam-Status: No, score=-1.276 tagged_above=-999 required=5 tests=[AWL=-1.324, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SQjfSJI17i-T for ; Sat, 18 Oct 2008 19:35:58 -0700 (PDT) Received: from adrilankha.hactrn.net (adrilankha.hactrn.net [IPv6:2001:418:1::19]) by core3.amsl.com (Postfix) with ESMTP id 8AEFC3A693C for ; Sat, 18 Oct 2008 19:35:58 -0700 (PDT) Received: from khazad-dum.hactrn.net (c-66-30-16-106.hsd1.ma.comcast.net [66.30.16.106]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "khazad-dum.hactrn.net", Issuer "Grunchweather Associates" (verified OK)) by adrilankha.hactrn.net (Postfix) with ESMTPS id 01EF0B82B; Sun, 19 Oct 2008 02:37:03 +0000 (UTC) Received: from khazad-dum.hactrn.net (localhost [IPv6:::1]) by khazad-dum.hactrn.net (Postfix) with ESMTP id 342EF734E1; Sat, 18 Oct 2008 19:22:45 +0000 (UTC) Date: Sat, 18 Oct 2008 15:22:44 -0400 From: Rob Austein To: Terry Manderson In-Reply-To: <843458F0-46FA-45FD-885F-9B034F297819@terrym.net> References: <48F8C320.20904@psg.com> <843458F0-46FA-45FD-885F-9B034F297819@terrym.net> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Message-Id: <20081018192245.342EF734E1@khazad-dum.hactrn.net> Cc: sidr@ietf.org Subject: Re: [sidr] request for wg adoption X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org I'd also question the purpose of TLS (ie, HTTPS vs HTTP) in this context. All the data are signed, there's no confidentiality or access control reuirement as far as I know, and the manifest design was specifically intended to remove the need for channel security. The draft doesn't contain any real analysis of what threats the protocol needs to defend against or why TLS is the right solution. _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Sun Oct 19 03:53:31 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EE7303A6A7C; Sun, 19 Oct 2008 03:53:30 -0700 (PDT) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 553F53A693B for ; Sun, 19 Oct 2008 03:53:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zA5KuYsFM9R6 for ; Sun, 19 Oct 2008 03:53:29 -0700 (PDT) Received: from postlady.ripe.net (postlady.ripe.net [193.0.19.65]) by core3.amsl.com (Postfix) with ESMTP id 74BF73A6A6A for ; Sun, 19 Oct 2008 03:53:29 -0700 (PDT) Received: from herring.ripe.net ([193.0.1.203]) by postlady.ripe.net with esmtp (Exim 4.63) (envelope-from ) id 1KrVvY-0001CQ-SA; Sun, 19 Oct 2008 12:54:36 +0200 Received: from Kistel-Mac.local (chimp.ripe.net [193.0.1.199]) by herring.ripe.net (Postfix) with ESMTP id C52BC2F583; Sun, 19 Oct 2008 12:54:28 +0200 (CEST) Message-ID: <48FB11E4.8020205@ripe.net> Date: Sun, 19 Oct 2008 03:54:28 -0700 From: Robert Kisteleki Organization: RIPE NCC User-Agent: Thunderbird 2.0.0.17 (Macintosh/20080914) MIME-Version: 1.0 To: sidr@ietf.org References: <48F8C320.20904@psg.com> <843458F0-46FA-45FD-885F-9B034F297819@terrym.net> <20081018192245.342EF734E1@khazad-dum.hactrn.net> In-Reply-To: <20081018192245.342EF734E1@khazad-dum.hactrn.net> X-RIPE-Spam-Level: ---- X-RIPE-Signature: 72e00e6d7601fa19264e98abc238a274267ac51f6f5b412c8fe6652a705ea347 Cc: Rob Austein Subject: Re: [sidr] request for wg adoption X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org Rob Austein wrote: > I'd also question the purpose of TLS (ie, HTTPS vs HTTP) in this > context. All the data are signed, there's no confidentiality or > access control reuirement as far as I know, and the manifest design > was specifically intended to remove the need for channel security. > The draft doesn't contain any real analysis of what threats the > protocol needs to defend against or why TLS is the right solution. I also have serious concerns about the use of HTTPS, especially about how a relying party should verify the server's certificate. I believe that the current RPKI certificate policy and/or profile prohibits certificate use for client/server authentication purposes. That'd mean that a different (yet another?) PKI should be used for this. What PKI would that be? Robert _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Sun Oct 19 22:50:44 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3237D3A6A71; Sun, 19 Oct 2008 22:50:44 -0700 (PDT) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 32B4F3A6A71 for ; Sun, 19 Oct 2008 22:50:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.576 X-Spam-Level: X-Spam-Status: No, score=-2.576 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rGPanEXet7zr for ; Sun, 19 Oct 2008 22:50:42 -0700 (PDT) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.238]) by core3.amsl.com (Postfix) with ESMTP id 571833A6A55 for ; Sun, 19 Oct 2008 22:50:42 -0700 (PDT) Received: by rv-out-0506.google.com with SMTP id b25so1469763rvf.49 for ; Sun, 19 Oct 2008 22:51:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:from:to :in-reply-to:content-type:content-transfer-encoding:mime-version :subject:date:references:x-mailer:sender; bh=LllviJz1yvQRm0o7EFTP+n8VWrCW1+LRzr6ezC0iKww=; b=XnNLP3EuBFAXUDEtKC2DeQyPbLzZjPknK3byuibcS/ykrFCeYABD6I9uMTDI0nLaVF 6HXow92P21UpFBxcKYI84YSbyXBvquOnPjsV8f3av9lRBoB/dRGa2AJT5DK4V+Co/lUW xi1V3Renz+f+Ytsj4FpZB9gGN/P1iKWGWICHo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:from:to:in-reply-to:content-type :content-transfer-encoding:mime-version:subject:date:references :x-mailer:sender; b=XGu7V2C/zrkx2p4b3XYkY40HTGWvePEGxmesDqfa5trNAFzf1V16fXBrsDjZA/jh6e fnSyRg8uRH7u9Xl286FMJftPdPh5h+3KnqNAmS1PInxkCKUspcBdZ/2ObKNi3bZnTZO7 JNgqp4zQFrYsK76etLUVznoero56w3ZqaCjI4= Received: by 10.141.33.21 with SMTP id l21mr4569839rvj.9.1224481912540; Sun, 19 Oct 2008 22:51:52 -0700 (PDT) Received: from ?192.168.1.103? (c58-108-241-164.fitzg1.qld.optusnet.com.au [58.108.241.164]) by mx.google.com with ESMTPS id b39sm10446388rvf.0.2008.10.19.22.51.50 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 19 Oct 2008 22:51:51 -0700 (PDT) Message-Id: <14FFA553-1CFB-4CDA-A1F4-BE9FCF0E7C40@terrym.net> From: Terry Manderson To: sidr@ietf.org In-Reply-To: <20081018192245.342EF734E1@khazad-dum.hactrn.net> Mime-Version: 1.0 (Apple Message framework v929.2) Date: Mon, 20 Oct 2008 15:51:47 +1000 References: <48F8C320.20904@psg.com> <843458F0-46FA-45FD-885F-9B034F297819@terrym.net> <20081018192245.342EF734E1@khazad-dum.hactrn.net> X-Mailer: Apple Mail (2.929.2) Subject: Re: [sidr] request for wg adoption X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org Hi Rob, On 19/10/2008, at 5:22 AM, Rob Austein wrote: > I'd also question the purpose of TLS (ie, HTTPS vs HTTP) in this > context. All the data are signed, there's no confidentiality or > access control reuirement as far as I know, and the manifest design > was specifically intended to remove the need for channel security. > The draft doesn't contain any real analysis of what threats the > protocol needs to defend against or why TLS is the right solution. Here is a hypothetical scenario that I think is technically viable. Consider two initial parties, Party A and B. Party A is the well mannered ISP who regularly fetches and validates the RPKI repository. Party B who is multi-homed is intent on doing an attack of some form on party A's customers. The entity that allocated the IP address space to party B for some reason retracts the allocation (expired membership, Law enforcement action etc) and issues a BOA. Party B somehow sees this happen and puts into play a mechanism close to the repository which identifies the collection of the updated manifest, 3779 certificate, and associated BOA - They then in transit modify one bit of data such that any of the following occurs for relying parties: manifest fails to validate the object's hash doesn't match those of the manifest and the objects fail to validate This means that depending on the policy of the relying parties, the bgp announcement from party B will remain in place for as long as the MiTM attack is happening on the repository elements related to party B, and party B's attack on customers of party A (or others) can remain in place. Using TLS would make this MiTM attack substantially more difficult to do with the intent of successfully downloading valid data from the repository for RPKI validation. .. Am I mistaken, is this not a valid attack on the RPKI infrastructure? Terry _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Sun Oct 19 22:57:19 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2C9C93A68E1; Sun, 19 Oct 2008 22:57:19 -0700 (PDT) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 044953A68E1 for ; Sun, 19 Oct 2008 22:57:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.58 X-Spam-Level: X-Spam-Status: No, score=-2.58 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ttp+g05HQ4DO for ; Sun, 19 Oct 2008 22:57:17 -0700 (PDT) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.229]) by core3.amsl.com (Postfix) with ESMTP id 38BCE3A68DA for ; Sun, 19 Oct 2008 22:57:17 -0700 (PDT) Received: by rv-out-0506.google.com with SMTP id b25so1471646rvf.49 for ; Sun, 19 Oct 2008 22:58:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:from:to :in-reply-to:content-type:content-transfer-encoding:mime-version :subject:date:references:x-mailer:sender; bh=QfjchWjyyDgIFmKaecl8hNrMjCbAbsR++LecqY+CKkw=; b=CcxP4W26uZSXt01NFWS1zSa7tLGFPnl66zDIQO+/Gtojt1bgjEuqEjW5ZY49OzbVpH KYGogQwxTMt4qppHvJNEe0uqYdeAVWe5nFHLYM7W3N54R8T5gpXJGJCXWURZ/6xP/gNV xMC6hZ8ZoakexnRZ94PmvgtlXVunzb8vP2jgI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:from:to:in-reply-to:content-type :content-transfer-encoding:mime-version:subject:date:references :x-mailer:sender; b=U8HW9GczSATx10H4Z7MerqPqX82omoqPIlJovWKrqbSGGRiUvSB1wFPNpSG/WfHqxh xt6PwshCiEsJz3LcBibtwLcA3FIBbqKU8LYvLCDJP9CnN2qNhagYIt1gnGlkx/As16R2 dWly7cllHgRyBR+3iH06+1/XubUxxs6+/+PG8= Received: by 10.141.168.16 with SMTP id v16mr4541182rvo.233.1224482307557; Sun, 19 Oct 2008 22:58:27 -0700 (PDT) Received: from ?192.168.1.103? (c58-108-241-164.fitzg1.qld.optusnet.com.au [58.108.241.164]) by mx.google.com with ESMTPS id l31sm18224939rvb.2.2008.10.19.22.58.25 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 19 Oct 2008 22:58:26 -0700 (PDT) Message-Id: From: Terry Manderson To: sidr@ietf.org In-Reply-To: <48FB11E4.8020205@ripe.net> Mime-Version: 1.0 (Apple Message framework v929.2) Date: Mon, 20 Oct 2008 15:58:23 +1000 References: <48F8C320.20904@psg.com> <843458F0-46FA-45FD-885F-9B034F297819@terrym.net> <20081018192245.342EF734E1@khazad-dum.hactrn.net> <48FB11E4.8020205@ripe.net> X-Mailer: Apple Mail (2.929.2) Subject: Re: [sidr] request for wg adoption X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org On 19/10/2008, at 8:54 PM, Robert Kisteleki wrote: >> > I also have serious concerns about the use of HTTPS, especially > about how a relying party should verify the server's certificate. I > believe that the current RPKI certificate policy and/or profile > prohibits certificate use for client/server authentication purposes. > That'd mean that a different (yet another?) PKI should be used for > this. What PKI would that be? > There is already a well accepted PKI for handling web based security - and as much as that may irritate some as equally open to abuse - it is far better than not having channel security. Although, I'm not closed to the idea of a TA being distributed for the purposes of RPKI Repository server security - just not sure if creating one is substantially better than using the existing known framework of third party certificate authorities already listed in most browsers/distributions. Please advise. Cheers Terry _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Mon Oct 20 03:16:27 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1FC833A676A; Mon, 20 Oct 2008 03:16:27 -0700 (PDT) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 137D73A676A for ; Mon, 20 Oct 2008 03:16:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uXAJmGGr4IT8 for ; Mon, 20 Oct 2008 03:16:25 -0700 (PDT) Received: from smtp2.arin.net (smtp2.arin.net [IPv6:2001:500:4:13::32]) by core3.amsl.com (Postfix) with ESMTP id 4B1EE3A63D2 for ; Mon, 20 Oct 2008 03:16:25 -0700 (PDT) Received: by smtp2.arin.net (Postfix, from userid 323) id 27A66A687C; Mon, 20 Oct 2008 06:17:36 -0400 (EDT) Received: from ex.arin.net (ex.arin.net [192.136.136.237]) by smtp2.arin.net (Postfix) with ESMTP id A57B8A6877; Mon, 20 Oct 2008 06:17:35 -0400 (EDT) Received: from EDAMAME.arin.net ([192.136.136.194]) by ex.arin.net ([192.136.136.237]) with mapi; Mon, 20 Oct 2008 06:17:35 -0400 From: Andy Newton To: Terry Manderson , "sidr@ietf.org" Date: Mon, 20 Oct 2008 06:17:31 -0400 Thread-Topic: [sidr] request for wg adoption Thread-Index: Ackw6gXR0Slcc/oqSnKL8J+ORY1EbwBswnPP Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Subject: Re: [sidr] request for wg adoption X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org On 10/18/08 2:22 AM, "Terry Manderson" wrote: > > I'm torn on this. I see the simplicity side and really appreciates > that, but I also see the benefits of heterogeneity. Well, unless one method clearly has a trade-off the other method does not, I see no reason for having two. Do you see any? >> So, when are we expecting a draft revision that addresses this issue >> and the >> others brought forward in Dublin? >> > > When do you want it? prior to adoption as a WG item? or as a WG item > revision? I'd prefer a revision prior to adoption. But failing that, an enumerated list of changes agreed upon by the wg is good enough. -andy _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Mon Oct 20 03:21:35 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C0B8C3A68F0; Mon, 20 Oct 2008 03:21:35 -0700 (PDT) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D08103A63D2 for ; Mon, 20 Oct 2008 03:21:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 05BtDMRQEYr7 for ; Mon, 20 Oct 2008 03:21:34 -0700 (PDT) Received: from smtp1.arin.net (smtp1.arin.net [IPv6:2001:500:4:13::33]) by core3.amsl.com (Postfix) with ESMTP id 1ED1F3A68F0 for ; Mon, 20 Oct 2008 03:21:34 -0700 (PDT) Received: by smtp1.arin.net (Postfix, from userid 323) id B66F76FE93; Mon, 20 Oct 2008 06:16:39 -0400 (EDT) Received: from ex.arin.net (ex.arin.net [192.136.136.237]) by smtp1.arin.net (Postfix) with ESMTP id 4ACC46FE8C; Mon, 20 Oct 2008 06:16:39 -0400 (EDT) Received: from EDAMAME.arin.net ([192.136.136.194]) by ex.arin.net ([192.136.136.237]) with mapi; Mon, 20 Oct 2008 06:22:44 -0400 From: Andy Newton To: Randy Bush , Terry Manderson Date: Mon, 20 Oct 2008 06:22:42 -0400 Thread-Topic: [sidr] request for wg adoption Thread-Index: AckxOpyf48Vk7zzwQEO47y5YezwCXQBYyxeV Message-ID: In-Reply-To: <48FA07FB.2090309@psg.com> Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Cc: "sidr@ietf.org" Subject: Re: [sidr] request for wg adoption X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org On 10/18/08 11:59 AM, "Randy Bush" wrote: > andy is a serious hacker and seems interested. perhaps he can help. Hmmm... This couldn't be too hard to test, now could it. Using curl or Apache libraries should be easy. If somebody could throw out what they consider to be a good size for the number of files in the repository and file size ranges, I'll cook something up. -andy _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Mon Oct 20 06:34:42 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7657C3A698B; Mon, 20 Oct 2008 06:34:42 -0700 (PDT) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D7A293A681C for ; Mon, 20 Oct 2008 06:34:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5K4gaefQ3yuW for ; Mon, 20 Oct 2008 06:34:35 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:1::36]) by core3.amsl.com (Postfix) with ESMTP id 680BE3A698B for ; Mon, 20 Oct 2008 06:34:35 -0700 (PDT) Received: from adsl-67-64-168-25.dsl.hstntx.swbell.net ([67.64.168.25] helo=rmac.psg.com) by ran.psg.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69 (FreeBSD)) (envelope-from ) id 1Kruv7-00034X-2h; Mon, 20 Oct 2008 13:35:41 +0000 Message-ID: <48FC892B.6080809@psg.com> Date: Mon, 20 Oct 2008 08:35:39 -0500 From: Randy Bush User-Agent: Thunderbird 2.0.0.17 (Macintosh/20080914) MIME-Version: 1.0 To: Andy Newton References: In-Reply-To: X-Enigmail-Version: 0.95.7 Cc: "sidr@ietf.org" Subject: Re: [sidr] request for wg adoption X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org Andy Newton wrote: >> I also see the benefits of heterogeneity. > Well, unless one method clearly has a trade-off the other method does > not, I see no reason for having two. Do you see any? i am still completely stunned and confused by this. i have been unable to understand "hetrogeneity" as other than two mandatory to implement protocols which have to offer then same end functionality. this not only has no benefits but is a major pain with no gain. i must be misunderstanding something. randy _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Mon Oct 20 15:08:43 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 34F033A6AF0; Mon, 20 Oct 2008 15:08:43 -0700 (PDT) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B39F13A6B06 for ; Mon, 20 Oct 2008 15:08:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8ITZAzjJ6HBW for ; Mon, 20 Oct 2008 15:08:41 -0700 (PDT) Received: from cyteen.hactrn.net (cyteen.hactrn.net [IPv6:2002:425c:4242:0:210:5aff:fe86:1f54]) by core3.amsl.com (Postfix) with ESMTP id 9EED03A6AF0 for ; Mon, 20 Oct 2008 15:08:40 -0700 (PDT) Received: from thrintun.hactrn.net (thrintun.hactrn.net [IPv6:2002:425c:4242:0:219:d1ff:fe12:5d30]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "thrintun.hactrn.net", Issuer "Grunchweather Associates" (verified OK)) by cyteen.hactrn.net (Postfix) with ESMTPS id 7B3E028470 for ; Mon, 20 Oct 2008 22:09:52 +0000 (UTC) Received: from thrintun.hactrn.net (localhost [IPv6:::1]) by thrintun.hactrn.net (Postfix) with ESMTP id 275952282B for ; Mon, 20 Oct 2008 18:09:52 -0400 (EDT) Date: Mon, 20 Oct 2008 18:09:52 -0400 From: Rob Austein To: sidr@ietf.org In-Reply-To: <14FFA553-1CFB-4CDA-A1F4-BE9FCF0E7C40@terrym.net> References: <48F8C320.20904@psg.com> <843458F0-46FA-45FD-885F-9B034F297819@terrym.net> <20081018192245.342EF734E1@khazad-dum.hactrn.net> <14FFA553-1CFB-4CDA-A1F4-BE9FCF0E7C40@terrym.net> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Message-Id: <20081020220952.275952282B@thrintun.hactrn.net> Subject: Re: [sidr] request for wg adoption X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org At Mon, 20 Oct 2008 15:51:47 +1000, Terry Manderson wrote: > > Here is a hypothetical scenario that I think is technically viable. > > Consider two initial parties, Party A and B. Party A is the well > mannered ISP who regularly fetches and validates the RPKI repository. > Party B who is multi-homed is intent on doing an attack of some form > on party A's customers. The entity that allocated the IP address space > to party B for some reason retracts the allocation (expired > membership, Law enforcement action etc) and issues a BOA. > > Party B somehow sees this happen and puts into play a mechanism close > to the repository which identifies the collection of the updated > manifest, 3779 certificate, and associated BOA - They then in transit > modify one bit of data such that any of the following occurs for > relying parties: > manifest fails to validate > the object's hash doesn't match those of the manifest and the objects > fail to validate > > This means that depending on the policy of the relying parties, the > bgp announcement from party B will remain in place for as long as the > MiTM attack is happening on the repository elements related to party > B, and party B's attack on customers of party A (or others) can remain > in place. > > Using TLS would make this MiTM attack substantially more difficult to > do with the intent of successfully downloading valid data from the > repository for RPKI validation. > > .. Am I mistaken, is this not a valid attack on the RPKI infrastructure? You appear to be describing a selective DoS attack by an on-path attacker. Unless I'm missing something, adding TLS to the mix here changes details but doesn't change the overall situation much, as: a) The attack was already detectable without TLS (those validation failures you mentioned), and b) An on-path attacker can DoS the relying party even when TLS is in use, albeit somewhat more crudely. So I don't see that TLS buys you much here, and you haven't said anything about the risks and costs of adding it: new trust relationships (adding channel trust relationships to what had previously been an end-to-end object security model) and new potential attackers (who did you say issues the TLS certificates?). _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Mon Oct 20 16:31:40 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7CF293A6924; Mon, 20 Oct 2008 16:31:40 -0700 (PDT) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A4DAD3A6924 for ; Mon, 20 Oct 2008 16:31:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.583 X-Spam-Level: X-Spam-Status: No, score=-2.583 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0gZDzoS0PND8 for ; Mon, 20 Oct 2008 16:31:38 -0700 (PDT) Received: from rv-out-0506.google.com (rv-out-0506.google.com [209.85.198.237]) by core3.amsl.com (Postfix) with ESMTP id B50573A63CB for ; Mon, 20 Oct 2008 16:31:38 -0700 (PDT) Received: by rv-out-0506.google.com with SMTP id b25so1836521rvf.49 for ; Mon, 20 Oct 2008 16:32:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:from:to :in-reply-to:content-type:content-transfer-encoding:mime-version :subject:date:references:x-mailer:sender; bh=sZdzRmK6gqXPNg3HJZgBK9P5T4iPG7wSQp4KJBu9Mw4=; b=TLW+dUbkd/Dh92dnsSJ3Zo4KuJVmTmnMZBZrhxHd32WSbsDTen5gIVwkvKPQxAaDoA c5n7yM2uMfSTYH6lDvTOhnEL72ZwJ6BJZ9nmDJ+JC4WjoLSB+nxqWOnw4y0oyJcBeLyf dUruRBQ62ssev+Q2kBwNOfakYCcjsH5eSdXh4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:from:to:in-reply-to:content-type :content-transfer-encoding:mime-version:subject:date:references :x-mailer:sender; b=DfmrbRCjkK9AN3WhJLq/QYdKSc5u1sQ0H5lSjgwikkUw0XVAGf6/hfo6BauN+Zzqtp mVHN+1XQI//034CeKrnfArVsV+lMFkcexFzs+kaApV5ebWCamAUrSap6m/jhF8KVD/c5 IG8yR+ukRSeeKMxo9SywlHc/ZvV3d08sgrNP0= Received: by 10.142.12.14 with SMTP id 14mr3373330wfl.147.1224545570870; Mon, 20 Oct 2008 16:32:50 -0700 (PDT) Received: from ?192.168.1.103? (c58-108-241-164.fitzg1.qld.optusnet.com.au [58.108.241.164]) by mx.google.com with ESMTPS id 27sm15346591wfa.2.2008.10.20.16.32.48 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 20 Oct 2008 16:32:49 -0700 (PDT) Message-Id: <84F38207-2CA7-4E80-BE56-225165FE39F0@terrym.net> From: Terry Manderson To: sidr@ietf.org In-Reply-To: <20081020220952.275952282B@thrintun.hactrn.net> Mime-Version: 1.0 (Apple Message framework v929.2) Date: Tue, 21 Oct 2008 09:32:45 +1000 References: <48F8C320.20904@psg.com> <843458F0-46FA-45FD-885F-9B034F297819@terrym.net> <20081018192245.342EF734E1@khazad-dum.hactrn.net> <14FFA553-1CFB-4CDA-A1F4-BE9FCF0E7C40@terrym.net> <20081020220952.275952282B@thrintun.hactrn.net> X-Mailer: Apple Mail (2.929.2) Subject: Re: [sidr] request for wg adoption X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org On 21/10/2008, at 8:09 AM, Rob Austein wrote: > You appear to be describing a selective DoS attack by an on-path > attacker. Unless I'm missing something, adding TLS to the mix here > changes details but doesn't change the overall situation much, as: > > a) The attack was already detectable without TLS (those validation > failures you mentioned), and > I think the difference is that the validation failures are much harder to nail down to a cause. ie was the rpki repository itself compromised? was the file modified in transit? was file put to disk erroneously? and many others .. I'm not sure that is a clean outcome. > b) An on-path attacker can DoS the relying party even when TLS is in > use, albeit somewhat more crudely. That sort of attack that really is disruptive to the entire channel and therefore to the fetch entirely. Not just the validation. But yes, still a risk. > > > So I don't see that TLS buys you much here, and you haven't said What TLS buys is the acceptance of the 'uber' security-oids who have secret decoder rings that look on this effort to secure the routing path, but don't secure the fetch mechanism from common well known attacks that can be specific in nature, and thus consider the attempt less than ideal. > > anything about the risks and costs of adding it: new trust > relationships (adding channel trust relationships to what had > previously been an end-to-end object security model) and new potential > attackers (who did you say issues the TLS certificates?). No, I didn't, the issue there is who is the trusted party? I'm happy to explore the options, although would it be appropriate for resource repository servers to be issued certificates following the allocation path? I don't see that using an un-secured channel to collect this information (validate-able or not) as going far enough to satisfy what the RPKI work is trying to achieve as a full end-to-end framework. While I'm not in love with rsync for this, adding TLS to rsync directly would go a long way. Having said that the last rsync patch I saw for this ('07) failed to work properly - I'm not aware of further work. Terry _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Tue Oct 21 07:19:28 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C749D3A6B73; Tue, 21 Oct 2008 07:19:28 -0700 (PDT) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A5CDD3A6B5B for ; Tue, 21 Oct 2008 07:19:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.549 X-Spam-Level: X-Spam-Status: No, score=-2.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SnnbyvSPHR0b for ; Tue, 21 Oct 2008 07:19:27 -0700 (PDT) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by core3.amsl.com (Postfix) with ESMTP id D23763A6B6A for ; Tue, 21 Oct 2008 07:19:26 -0700 (PDT) Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.13.5/8.13.5) with ESMTP id m9LEKHGA015529 for ; Tue, 21 Oct 2008 09:20:17 -0500 Received: from nemo.columbia.ads.sparta.com (nemo.columbia.sparta.com [157.185.80.75]) by Beta5.sparta.com (8.12.11/8.13.1) with ESMTP id m9LEKIaq030165 for ; Tue, 21 Oct 2008 09:20:18 -0500 Received: from SANDYM-LT.columbia.ads.sparta.com ([192.168.1.103]) by nemo.columbia.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Tue, 21 Oct 2008 10:20:17 -0400 Date: Tue, 21 Oct 2008 10:20:16 -0400 (Eastern Daylight Time) From: Sandra Murphy To: sidr@ietf.org Message-ID: X-X-Sender: sandy@nemo.columbia.sparta.com MIME-Version: 1.0 X-OriginalArrivalTime: 21 Oct 2008 14:20:17.0678 (UTC) FILETIME=[2471DAE0:01C93388] Subject: [sidr] IETF 73 draft deadlines X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org There are two upcoming deadlines for IETF 73 internet drafts that you should keep in mind: October 27, Monday - Internet Draft Cut-off for initial document (-00) submission by 17:00 PDT (24:00 UTC/GMT) November 3, Monday - Internet Draft final submission cut-off by 17:00 PT (01:00 Tuesday, November 4 UTC/GMT) If you do intend to produce a -00 wg draft (draft-ietf-sidr-yadayada-00.txt), please let me and Geoff know ASAP. --Sandy _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Tue Oct 21 07:25:02 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 154BF3A6958; Tue, 21 Oct 2008 07:25:02 -0700 (PDT) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A842E3A6953 for ; Tue, 21 Oct 2008 07:25:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.556 X-Spam-Level: X-Spam-Status: No, score=-2.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CDflAmnoBRC7 for ; Tue, 21 Oct 2008 07:25:00 -0700 (PDT) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by core3.amsl.com (Postfix) with ESMTP id D97CB3A6958 for ; Tue, 21 Oct 2008 07:24:59 -0700 (PDT) Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.13.5/8.13.5) with ESMTP id m9LEPs95015615 for ; Tue, 21 Oct 2008 09:25:54 -0500 Received: from nemo.columbia.ads.sparta.com (nemo.columbia.sparta.com [157.185.80.75]) by Beta5.sparta.com (8.12.11/8.13.1) with ESMTP id m9LEPsnF030438 for ; Tue, 21 Oct 2008 09:25:54 -0500 Received: from SANDYM-LT.columbia.ads.sparta.com ([192.168.1.103]) by nemo.columbia.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Tue, 21 Oct 2008 10:25:53 -0400 Date: Tue, 21 Oct 2008 10:25:54 -0400 (Eastern Daylight Time) From: Sandra Murphy To: sidr@ietf.org Message-ID: X-X-Sender: sandy@nemo.columbia.sparta.com MIME-Version: 1.0 X-OriginalArrivalTime: 21 Oct 2008 14:25:54.0116 (UTC) FILETIME=[ECFA3840:01C93388] Subject: [sidr] call for wg agenda items X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org Draft wg agendas are due by Wednesday, Nov 5. If you have any topics that you would like to present at the wg meeting, please send them to the wg chairs (me *and* Geoff) or the list by Tuesday, Nov 4. (US Election Day 2008! If you are in the US voting areas and you think you might be busy voting or dealing with social disruption or celebrations, send the mail early.) --Sandy _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Tue Oct 21 07:27:09 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3A2BA3A6A49; Tue, 21 Oct 2008 07:27:09 -0700 (PDT) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 20AC53A6869 for ; Tue, 21 Oct 2008 07:27:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.562 X-Spam-Level: X-Spam-Status: No, score=-2.562 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EsFZYLew8o6g for ; Tue, 21 Oct 2008 07:27:07 -0700 (PDT) Received: from M4.sparta.com (M4.sparta.com [157.185.61.2]) by core3.amsl.com (Postfix) with ESMTP id 3154A3A68DE for ; Tue, 21 Oct 2008 07:27:07 -0700 (PDT) Received: from Beta5.sparta.com (beta5.sparta.com [157.185.63.21]) by M4.sparta.com (8.13.5/8.13.5) with ESMTP id m9LERqNe015675 for ; Tue, 21 Oct 2008 09:27:52 -0500 Received: from nemo.columbia.ads.sparta.com (nemo.columbia.sparta.com [157.185.80.75]) by Beta5.sparta.com (8.12.11/8.13.1) with ESMTP id m9LERrIh030559 for ; Tue, 21 Oct 2008 09:27:53 -0500 Received: from SANDYM-LT.columbia.ads.sparta.com ([192.168.1.103]) by nemo.columbia.ads.sparta.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Tue, 21 Oct 2008 10:27:52 -0400 Date: Tue, 21 Oct 2008 10:27:53 -0400 (Eastern Daylight Time) From: Sandra Murphy To: sidr@ietf.org Message-ID: X-X-Sender: sandy@nemo.columbia.sparta.com MIME-Version: 1.0 X-OriginalArrivalTime: 21 Oct 2008 14:27:52.0663 (UTC) FILETIME=[33A30E70:01C93389] Subject: [sidr] other IETF 73 deadlines X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org I haven't been doing my usual wg nagging bit, so here's the rest of the important deadlines for IETF 73. November 7, Friday - Early-Bird registration and payment cut-off at 17:00 PT (01:00 Saturday, November 8 UTC/GMT). November 10, Monday - Revised Working Group agendas due by 17:00 PT (01:00 Tuesday, November 11 UTC/GMT) November 10, Monday - Registration cancellation cut-off at 17:00 PT (01:00 Tuesday, November 11 UTC/GMT). November 14, Friday - Final Pre-Registration and Pre-Payment cut-off at 17:00 PT (01:00 Saturday, November 15 UTC/GMT). --Sandy _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Tue Oct 21 16:37:01 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9166B3A67B1; Tue, 21 Oct 2008 16:37:01 -0700 (PDT) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E1B6C3A67B1 for ; Tue, 21 Oct 2008 16:37:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.585 X-Spam-Level: X-Spam-Status: No, score=-2.585 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kFxKNcqTEZ46 for ; Tue, 21 Oct 2008 16:37:00 -0700 (PDT) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.175]) by core3.amsl.com (Postfix) with ESMTP id 3D2F53A679C for ; Tue, 21 Oct 2008 16:37:00 -0700 (PDT) Received: by wf-out-1314.google.com with SMTP id 27so2894914wfd.31 for ; Tue, 21 Oct 2008 16:38:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:cc:message-id:from:to :in-reply-to:content-type:content-transfer-encoding:mime-version :subject:date:references:x-mailer:sender; bh=rNdlGPBEk8V3bYo1VabiN/6BXCiBT0JfA4Ttc+I21B0=; b=C6RbZUUIR04/AXoZtHgf3FjTScKD5gusfrhVx7wFZZLXj7w17iknoHLuoqm9ad0Szk 2172x50CzPfIE4H02mfJF0tBm4l213yURD3ryJXQuliYcPkWgtYFjib1sUF9MDQjzxaV PsoiyFr/tQroi+wPjATUVrbMjW05pQC7a+NqY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=cc:message-id:from:to:in-reply-to:content-type :content-transfer-encoding:mime-version:subject:date:references :x-mailer:sender; b=TiM6mqDJR/uC2VTqAw4fgg3ryxX+s6kjRTd0cpe2zO5HO2bCMimm3M5Eq9neB2eZQl 2mfbcSIqrxaWz/X/G/T6+gHmGeKAuLbwhbRIIc2vXD8BguOR1qhW/i08bElgzstr5K7z gmh2zSsT/82olcwuP2t0THYHE5c7UOA1+yGVw= Received: by 10.142.169.3 with SMTP id r3mr4013075wfe.203.1224632294177; Tue, 21 Oct 2008 16:38:14 -0700 (PDT) Received: from ?192.168.1.103? (c58-108-241-164.fitzg1.qld.optusnet.com.au [58.108.241.164]) by mx.google.com with ESMTPS id 29sm18674302wfg.0.2008.10.21.16.38.11 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 21 Oct 2008 16:38:12 -0700 (PDT) Message-Id: <3572460E-3183-4B1E-952C-946EA8964678@terrym.net> From: Terry Manderson To: Andy Newton In-Reply-To: Mime-Version: 1.0 (Apple Message framework v929.2) Date: Wed, 22 Oct 2008 09:38:07 +1000 References: X-Mailer: Apple Mail (2.929.2) Cc: sidr@ietf.org Subject: Re: [sidr] request for wg adoption X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org On 20/10/2008, at 8:22 PM, Andy Newton wrote: > > Hmmm... This couldn't be too hard to test, now could it. Using curl > or > Apache libraries should be easy. If somebody could throw out what > they > consider to be a good size for the number of files in the repository > and > file size ranges, I'll cook something up. APNIC _had_ a test repository in place. I don't know if it is still there. I'm not aware of any other organisation with a populated repository of test objects. T. _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Tue Oct 21 17:15:04 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2E7843A6853; Tue, 21 Oct 2008 17:15:04 -0700 (PDT) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5C79F3A6807 for ; Tue, 21 Oct 2008 17:15:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l9qtheUidBqo for ; Tue, 21 Oct 2008 17:15:01 -0700 (PDT) Received: from cyteen.hactrn.net (cyteen.hactrn.net [IPv6:2002:425c:4242:0:210:5aff:fe86:1f54]) by core3.amsl.com (Postfix) with ESMTP id 2F6753A63EC for ; Tue, 21 Oct 2008 17:15:01 -0700 (PDT) Received: from thrintun.hactrn.net (thrintun.hactrn.net [IPv6:2002:425c:4242:0:219:d1ff:fe12:5d30]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "thrintun.hactrn.net", Issuer "Grunchweather Associates" (verified OK)) by cyteen.hactrn.net (Postfix) with ESMTPS id AD9B72845A for ; Wed, 22 Oct 2008 00:16:14 +0000 (UTC) Received: from thrintun.hactrn.net (localhost [IPv6:::1]) by thrintun.hactrn.net (Postfix) with ESMTP id 47C972282C for ; Tue, 21 Oct 2008 20:16:14 -0400 (EDT) Date: Tue, 21 Oct 2008 20:16:14 -0400 From: Rob Austein To: sidr@ietf.org In-Reply-To: <3572460E-3183-4B1E-952C-946EA8964678@terrym.net> References: <3572460E-3183-4B1E-952C-946EA8964678@terrym.net> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Message-Id: <20081022001614.47C972282C@thrintun.hactrn.net> Subject: Re: [sidr] request for wg adoption X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org At Wed, 22 Oct 2008 09:38:07 +1000, Terry Manderson wrote: > > On 20/10/2008, at 8:22 PM, Andy Newton wrote: > > > Hmmm... This couldn't be too hard to test, now could it. Using > > curl or Apache libraries should be easy. If somebody could throw > > out what they consider to be a good size for the number of files > > in the repository and file size ranges, I'll cook something up. > > APNIC _had_ a test repository in place. I don't know if it is still > there. I'm not aware of any other organisation with a populated > repository of test objects. APNIC did indeed have a mock-up of a full-scale RPKI repository at one point, based on available data from IANA and all five RIRs (ie, this was an attempt to simulate what the full database in an RPKI world would look like). This test repository was a great help when I was first writing validation code and we were all trying to figure out what the certificate profile should be, but it was somewhat high maintenance, and APNIC decommissioned it a while ago. George Michaelson might be able to supply more details, but as I recall it was on the order of 30,000 - 40,000 objects. Didn't include ROAs or manifests, just certificates and CRLs. I no longer recall whether it included EE certificates or only CA certificates. Most of RPKI objects are quite small. Disk space per se was never a problem during testing with the full ~40k objects. Inodes, on the other hand, were a problem -- your average unix filesystem is configured assuming a higher data/inode ratio. The test objects that I generate as part of my regression testing framework come in at about 2000 octets for a manifest, about 1250 octets for a certificate, and about 435 octets for an empty CRL. These are probably on the small side, CRLs and manifests grow with the number of entries and certificates grow with the number of discrete resources encoded as extensions, but we're still talking about tiny files in most cases. Manifests issued by RIRs are likely to be significantly larger, simply because the tree is so flat there. CRLs sizes depend on your assumptions, but it's probably safe to assume that anybody who issues a lot of certificates will need to revoke some of them. Hope this helps. _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Fri Oct 24 03:29:46 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1B4A13A68E0; Fri, 24 Oct 2008 03:29:46 -0700 (PDT) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DBBFA3A6896 for ; Fri, 24 Oct 2008 03:29:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.586 X-Spam-Level: X-Spam-Status: No, score=-2.586 tagged_above=-999 required=5 tests=[AWL=0.013, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ilv+aQtlQJNY for ; Fri, 24 Oct 2008 03:29:44 -0700 (PDT) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.170]) by core3.amsl.com (Postfix) with ESMTP id 263BC3A67A3 for ; Fri, 24 Oct 2008 03:29:44 -0700 (PDT) Received: by wf-out-1314.google.com with SMTP id 27so874004wfd.31 for ; Fri, 24 Oct 2008 03:31:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:from:to :content-type:content-transfer-encoding:mime-version:subject:date :x-mailer:sender; bh=WTNo1kVOiB5txMy/+rDki8sCs6c10qdde9IdhRqxKP0=; b=Ayn4LSTNCPwyHqewf6Kd9NjgbUgAaFSAyLBignd4P82KKYnXnvur/ABewg8JdiR/zX /nBPj3d6VvBcaQa82y3AMDW/9xN0eNZdWcepKzuPn9XEfpXUhQh3I43HZhWzUeLbSgPh oQc7KQBq2mLpbLWlpHKpVpTFwXFU9lYkgq9Tk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:from:to:content-type:content-transfer-encoding :mime-version:subject:date:x-mailer:sender; b=WSxdz2hKMmDK7OScZmRZC4gjfUvc725YS2X6N5Ic/mZb1nkrAQNDcOwiVSHzyTREbO qldQVyEUHHoTbPsA0xf8ZmgO2QYcuYovk8UTUrP3rtbel3WHMvwPMEV4Dy+Hfrv+u/c/ GI//gZOmsj0v3zBYc9kYB91r2zJQY5/OtNUX8= Received: by 10.142.82.6 with SMTP id f6mr914541wfb.43.1224844265147; Fri, 24 Oct 2008 03:31:05 -0700 (PDT) Received: from ?192.168.1.103? (c58-108-241-164.fitzg1.qld.optusnet.com.au [58.108.241.164]) by mx.google.com with ESMTPS id 22sm2325090wfg.13.2008.10.24.03.31.03 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 24 Oct 2008 03:31:04 -0700 (PDT) Message-Id: From: Terry Manderson To: sidr@ietf.org Mime-Version: 1.0 (Apple Message framework v929.2) Date: Fri, 24 Oct 2008 20:30:59 +1000 X-Mailer: Apple Mail (2.929.2) Subject: [sidr] am I missing something? X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org I was re-reading draft-ietf-sidr-res-certs-13 to get something clear in my head about SIA values and I got wildly side-tracked. in section 1, it says: "In the context of the public Internet, and the use of public number resources within this context, it is intended that Resource Certificates are used in a manner that is explicitly aligned to the public number resource distribution function" My impression is that the allocation chain goes IANA->RIR->NIR/LIR- >ORG. And for legacy space there is a IANA->ORG structure. That is the way public numbers are distributed, yes? Wouldn't/Shouldn't there be a request for IANA to sign over "stuff" in the IANA considerations section? (or have I got the purpose of that section completely wrong?) Apologies for the newbie-ness of the question. Terry Speaking for Terry, I don't get to speak for anyone else.. and sometimes not even me! (just don't ask ;) _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Fri Oct 24 15:45:07 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3D8FC28C1B7; Fri, 24 Oct 2008 15:45:07 -0700 (PDT) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9E82E28C1B7 for ; Fri, 24 Oct 2008 15:45:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.67 X-Spam-Level: X-Spam-Status: No, score=-6.67 tagged_above=-999 required=5 tests=[AWL=-0.071, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hl9620gUqMIB for ; Fri, 24 Oct 2008 15:45:05 -0700 (PDT) Received: from mint.apnic.net (mint.apnic.net [202.12.29.58]) by core3.amsl.com (Postfix) with ESMTP id BFDE128C15E for ; Fri, 24 Oct 2008 15:45:04 -0700 (PDT) Received: from dhcp5.potaroo.net (dhcp5.potaroo.net [203.10.60.5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mint.apnic.net (Postfix) with ESMTP id 3D10FD5F31; Sat, 25 Oct 2008 08:46:26 +1000 (EST) Message-Id: <21DA0B5A-49F7-4347-86D0-346D15029296@apnic.net> From: Geoff Huston To: Sandra Murphy In-Reply-To: Mime-Version: 1.0 (Apple Message framework v929.2) Date: Sat, 25 Oct 2008 09:46:24 +1100 References: X-Mailer: Apple Mail (2.929.2) Cc: sidr@ietf.org Subject: Re: [sidr] Manifests and the Repository Structure X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org Thanks for these comments Sandy. I've tried to address these comments in the next release of the manifest draft (-04) which will be put into the internet drafts collection very shortly. Geoff On 18/10/2008, at 4:44 AM, Sandra Murphy wrote: > > The repository structure document reads: > > in section 2.2: > > Becuase a CA is associated with a single key pair an entity > performss > the equivalent of a key rollover operation by generating a new CA > instance as well as a new key pair. In such cases the entity may > chose to continue of use a single repository publication point for > both CA instances. In such cases the repository publication pooint > will contain the CRL, manifest and subordinate certificates of both > CA instances. > > In section 2.3, which is talking about multi-use EE certificates > > It is consistent with this specification, but not recommended > practice, that all subordinate EE certificates of a given CA share a > common publication repository. In this case the repository > publication point would contain multiple manifest objects, one for > each EE certificate that has placed objects into this common > publication point. Each manifest is limited in scope to listing the > objects signed by the EE certificate. > > In section 3: > > o Each CA publication directory in the publication repository > should > contain the products of this CA, including those objects signed > by > single-use EE certificates that have been issued by this CA. The > signed products of related CA's that are operated by the same > entity may share the CA publication directory. Aside from > subdirectories, no other objects should be placed in a > publication > repository directory. > > Rob Austein's message of 19 Sep 2008 says: > >> The problem is that the manifest is a not a listing of the active >> entity's outputs, it's a listing of the outputs issued by a >> particular >> CA certificate. Now that David has finished beating us up about the >> term "rollover", the mapping from CA to CA certificate is 1:1, just >> to >> further confuse matters, and we lack a good term for the entity that >> controls a publication point and maps 1:1 with the publication point. >> >> There's a subtlety here that may not be obvious (thanks to Sandy for >> asking about it): the publication point, in the sense of a filesystem >> directory, is common to all current CA certificates in use by this >> nameless entity that we used to call a CA. Normally that's exactly >> one CA certificate, except during rollover, when both the old and new >> CA certificates are valid; now that David has whacked us with proper >> PKI terminology, the process that we call rollover is really a >> process >> of generating a new CA and reissuing all of the old CA's products >> under the new CA. >> >> The manifest, however, is specific to a particular CA certificate. >> This means that during rollover the manifest will not cover the >> entire >> content of the directory; instead, there will be two certificates, >> each with its own manifest, and the two manifests between them will >> cover the content of the directory. > > My question to which Rob refers was about how many manifests exist at > a publication point. I think the repository structure and Rob's > message indicate that there might be more than one manifest at a > publication point, and no one manifest covers all items in the > publication point. > > I don't think that the current text in the manifests draft quite > carries that thought completely all the way through. My question to > Rob last time was private, I'm taking the risky step of asking the > question this time in public. > > For example, in the intro: > > A manifest is an object that lists of all of the other signed > objects > issued by the authority responsible for a publication point in the > repository system. > > Depending on whether "the authority" means what Rob calls "the > nameless > entity" or "the CA certificate" (plus single use EE certificates > signed > by the CA cert?) , this would mean either that the manifest lists all > the signed objects in the publication point period, or that the > manifest lists only those signed objects in the publication point that > were signed using just one private key. > > For the purpose of writing the manifest validation code, I think the > difference matters. > > Section 5.1 on manifest generation says only: > > 4. Construct the manifest content. > > Who knew that might need explaining? My first guess at the algorithm > is something like: take the EE cert that (refers to the public key > that is associated with the private key that) will sign the manifest, > take the CA cert that (refers to the public key associated with the > private key that) signed the EE cert, and list all signed objects in > the > publication point that are signed by (the private key yada yada) > that CA > cert. Except that the repository structure draft in section 2.2 & 3 > says that the publication point also includes objects signed by an EE > certificate "where the EE certificate was issued by this CA". I > believe that means that the manifest object also lists the signed > objects associated with EE certs in the publication point that > are associated with the CA cert. > > And in section 8.1, Tests for Determining Manifest State > > For a given publication point, the relying party should perform the > following tests to determine the manifest state of the publication > point: > > 1. Select the manifest having highest manifestNumber among all > valid > manifests (where manifest validity is defined in Section > Section 7). > > I think this was intended to refer to choosing among manifests you > have > downloaded, not multiple manifests at the publication point. > > 3. Check that every file at the publication point appears on the > manifest, and that every file on the manifest appears at the > publication point. > > If a manifest lists only those signed objects signed by one particular > private key (aka signed by one particular "CA", if I read Rob's > message > correctly above, or signed by a single use EE cert signed by this same > one particular "CA", if I read the repository structure draft > correctly), then this language needs to be made more precise, > something > like: take the EE cert that was used in signing the manifest, > take the CA cert that was used in signing the EE cert, and list all > signed objects in the publication point that are signed by that CA > cert. The repository structure draft in section 2.2 & 3 says that the > publication point also includes objects signed by an EE certificate > "where the EE certificate was issued by this CA". I believe that > means > that the manifest object also lists the signed objects associated with > EE certs in the publication point that are associated with the CA > cert. > > > Yes? > > That section reads further: > > > * If there exists files at the publication point that do not > appear on the manifest, or files on the manifest that do not > appear at the publication point then see Section 8.5 > but still continue with the following test. > > If there are several manifests at the publication point, then this > branch gets taken every time, right? > > Section 8.5 Mismatch between Manifest and Publication Point says: > > If there exist otherwise valid signed objects that do not appear on > any manifest, then provided the manifest is not stale (see Section > Section 8.4) it is likely that their omission is an error by the > publisher. > > The use of the word "any" here is important and indicates that you > only > have an error condition if you check all the manifests, which means > you must aggregate the results of all the manifests before you decide > you have an error. Yes? But objects listed in any one manifest but > missing from the publication point constitute an error that you can > check in each manifest independently. Right? > > --Sandy > _______________________________________________ > 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 sidr-bounces@ietf.org Fri Oct 24 16:15:03 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F16773A68B9; Fri, 24 Oct 2008 16:15:02 -0700 (PDT) X-Original-To: sidr@ietf.org Delivered-To: sidr@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 800673A69E3; Fri, 24 Oct 2008 16:15:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20081024231501.800673A69E3@core3.amsl.com> Date: Fri, 24 Oct 2008 16:15:01 -0700 (PDT) Cc: sidr@ietf.org Subject: [sidr] I-D Action:draft-ietf-sidr-rpki-manifests-04.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Secure Inter-Domain Routing Working Group of the IETF. Title : Manifests for the Resource Public Key Infrastructure Author(s) : R. Austein, et al. Filename : draft-ietf-sidr-rpki-manifests-04.txt Pages : 27 Date : 2008-10-24 This document defines a "manifest" for use in the Resource Public Key Infrastructure. A manifest is a signed object that contains a listing of all the signed objects in the repository publication point associated with an authority responsible for publishing in the repository. For each certificate, or other forms of signed objects issued by the authority that are published at this repository publication point, the manifest contains both the name of the file containing the object, and a hash of the file content. Manifests are intended to expose potential attacks against relying parties of the Resource Public Key Infrastructure, such as a man-in-the middle attack of withholding repository data from relying party access, or replaying stale repository data to a relying party's access request. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sidr-rpki-manifests-04.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-sidr-rpki-manifests-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-10-24161058.I-D@ietf.org> --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr --NextPart-- From sidr-bounces@ietf.org Sat Oct 25 12:45:03 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C40B63A692A; Sat, 25 Oct 2008 12:45:03 -0700 (PDT) X-Original-To: sidr@ietf.org Delivered-To: sidr@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 653103A6818; Sat, 25 Oct 2008 12:45:00 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20081025194501.653103A6818@core3.amsl.com> Date: Sat, 25 Oct 2008 12:45:01 -0700 (PDT) Cc: sidr@ietf.org Subject: [sidr] I-D Action:draft-ietf-sidr-res-certs-14.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Secure Inter-Domain Routing Working Group of the IETF. Title : A Profile for X.509 PKIX Resource Certificates Author(s) : G. Huston, et al. Filename : draft-ietf-sidr-res-certs-14.txt Pages : 44 Date : 2008-10-25 This document defines a standard profile for X.509 certificates for the purposes of supporting validation of assertions of "right-of-use" of an Internet Number Resource (IP Addresses and Autonomous System Numbers). This profile is used to convey the issuer's authorization of the subject to be regarded as the current holder of a "right-of- use" of the IP addresses and AS numbers that are described in the issued certificate. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sidr-res-certs-14.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-sidr-res-certs-14.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-10-25124003.I-D@ietf.org> --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr --NextPart-- From sidr-bounces@ietf.org Sat Oct 25 14:10:44 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 823ED3A686D; Sat, 25 Oct 2008 14:10:44 -0700 (PDT) X-Original-To: sidr@core3.amsl.com Delivered-To: sidr@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9A6B33A686D for ; Sat, 25 Oct 2008 14:10:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.664 X-Spam-Level: X-Spam-Status: No, score=-6.664 tagged_above=-999 required=5 tests=[AWL=-0.065, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eX54HjJuiosE for ; Sat, 25 Oct 2008 14:10:42 -0700 (PDT) Received: from mint.apnic.net (mint.apnic.net [202.12.29.58]) by core3.amsl.com (Postfix) with ESMTP id A09BE3A6818 for ; Sat, 25 Oct 2008 14:10:42 -0700 (PDT) Received: from dhcp5.potaroo.net (dhcp5.potaroo.net [203.10.60.5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mint.apnic.net (Postfix) with ESMTP id 1717BD5F31; Sun, 26 Oct 2008 07:12:07 +1000 (EST) Message-Id: <38ACC2BE-BC26-4CD5-B48C-B613D445CCA1@apnic.net> From: Geoff Huston To: sidr@ietf.org Mime-Version: 1.0 (Apple Message framework v929.2) Date: Sun, 26 Oct 2008 08:12:06 +1100 X-Mailer: Apple Mail (2.929.2) Subject: [sidr] New Version Notification for draft-ietf-sidr-res-certs-14 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org WG Chair hat OFF This version (14) incorporates review comments received during the last call on the document. The section on trust anchors was revised for clarity with suggestions from Steven kent, but no changes in the specification of the certificates have been made. thanks, Geoff _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Tue Oct 28 23:30:04 2008 Return-Path: X-Original-To: sidr-archive@megatron.ietf.org Delivered-To: ietfarch-sidr-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4A80C3A6A93; Tue, 28 Oct 2008 23:30:04 -0700 (PDT) X-Original-To: sidr@ietf.org Delivered-To: sidr@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 0B2483A6882; Tue, 28 Oct 2008 23:30:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20081029063002.0B2483A6882@core3.amsl.com> Date: Tue, 28 Oct 2008 23:30:02 -0700 (PDT) Cc: sidr@ietf.org Subject: [sidr] I-D Action:draft-ietf-sidr-bogons-02.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Secure Inter-Domain Routing Working Group of the IETF. Title : A Profile for Bogon Origin Attestations (BOAs) Author(s) : G. Huston, et al. Filename : draft-ietf-sidr-bogons-02.txt Pages : 15 Date : 2008-10-28 This document defines a standard profile for Bogon Origin Attestations (BOAs). A BOA is a digitally signed object that provides a means of verifying that an IP address block holder has not authorized any Autonomous System (AS) to originate routes that are equivalent to any of the addresses listed in the BOA. A BOA also provides a means of verifying that BGP speaker is not using an AS without appropriate authority to use that AS. The proposed application of BOAs is intended to fit within the requirements for adding security measures to inter-domain routing, including the ability to support incremental and piecemeal deployment of such measures, and does not require any changes to the specification of the Border Gateway Protocol. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sidr-bogons-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-sidr-bogons-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-10-28231639.I-D@ietf.org> --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr --NextPart--