From sidr-bounces@ietf.org Mon Jul 02 14:50:36 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5Qyj-0007e2-EO; Mon, 02 Jul 2007 14:50:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5Qyi-0007av-Ik for sidr@ietf.org; Mon, 02 Jul 2007 14:50:28 -0400 Received: from ns1.tislabs.com ([192.94.214.100] helo=nutshell.tislabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I5Qyc-0007TI-UV for sidr@ietf.org; Mon, 02 Jul 2007 14:50:28 -0400 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id l62IhJCg028624 for ; Mon, 2 Jul 2007 14:43:33 -0400 (EDT) Received: from pecan.tislabs.com(10.66.1.30) by nutshell.tislabs.com via csmap (V6.0) id srcAAAxUaGX3; Mon, 2 Jul 07 14:42:06 -0400 Received: by pecan.tislabs.com (Postfix, from userid 2005) id 2AF913F48C; Mon, 2 Jul 2007 14:10:37 -0400 (EDT) To: sidr@ietf.org Message-Id: <20070702181037.2AF913F48C@pecan.tislabs.com> Date: Mon, 2 Jul 2007 14:10:37 -0400 (EDT) From: sandy@tislabs.com (Sandy Murphy) X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Cc: sandy@tislabs.com Subject: [Sidr] agenda items for IETF 69 Chicago X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: sidr-bounces@ietf.org >Any who have plans to submit at the sidr meeting at IETF 69 in Chicago, OK, so that did not come out quite the way I wanted. If you plan to submit a draft to be discussed at the meeting or wish to discuss any other idea at the meeting, please send them to the list. --Sandy _______________________________________________ Sidr mailing list Sidr@ietf.org https://www1.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Mon Jul 02 15:21:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5RTB-0001xf-4t; Mon, 02 Jul 2007 15:21:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5RTA-0001xa-97 for sidr@ietf.org; Mon, 02 Jul 2007 15:21:56 -0400 Received: from sentry.gw.tislabs.com ([192.94.214.100] helo=nutshell.tislabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I5RSC-0005Wn-Nf for sidr@ietf.org; Mon, 02 Jul 2007 15:21:56 -0400 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id l62JGQNh000486 for ; Mon, 2 Jul 2007 15:16:27 -0400 (EDT) Received: from pecan.tislabs.com(10.66.1.30) by nutshell.tislabs.com via csmap (V6.0) id srcAAA_fai3a; Mon, 2 Jul 07 15:15:17 -0400 Received: by pecan.tislabs.com (Postfix, from userid 2005) id 17A063F488; Mon, 2 Jul 2007 14:08:41 -0400 (EDT) To: sidr@ietf.org Message-Id: <20070702180841.17A063F488@pecan.tislabs.com> Date: Mon, 2 Jul 2007 14:08:41 -0400 (EDT) From: sandy@tislabs.com (Sandy Murphy) X-Spam-Score: 0.0 (/) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea Cc: sandy@tislabs.com Subject: [Sidr] agenda items for IETF 69 Chicago X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: sidr-bounces@ietf.org Any who have plans to submit at the sidr meeting at IETF 69 in Chicago, please send them to the list. Agendas are due to the secretariat on Wed July 11, so don't wait too long. --Sandy _______________________________________________ Sidr mailing list Sidr@ietf.org https://www1.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Mon Jul 02 15:26:40 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5RXk-0008En-Gf; Mon, 02 Jul 2007 15:26:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5RXi-0008A6-Eb for sidr@ietf.org; Mon, 02 Jul 2007 15:26:38 -0400 Received: from sentry.gw.tislabs.com ([192.94.214.100] helo=nutshell.tislabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I5RXe-0006G2-2x for sidr@ietf.org; Mon, 02 Jul 2007 15:26:38 -0400 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id l62JLtXC000804 for ; Mon, 2 Jul 2007 15:21:57 -0400 (EDT) Received: from pecan.tislabs.com(10.66.1.30) by nutshell.tislabs.com via csmap (V6.0) id srcAAABZaOzb; Mon, 2 Jul 07 15:20:27 -0400 Received: by pecan.tislabs.com (Postfix, from userid 2005) id 943B23F475; Mon, 2 Jul 2007 15:18:39 -0400 (EDT) To: sidr@ietf.org Message-Id: <20070702191839.943B23F475@pecan.tislabs.com> Date: Mon, 2 Jul 2007 15:18:39 -0400 (EDT) From: sandy@tislabs.com (Sandy Murphy) X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: sandy@tislabs.com Subject: [Sidr] FW: Request to forward the Nomcom 2007-8 Announcement to lists you manage X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: sidr-bounces@ietf.org Forwarded on behalf of the noncom chair. --Sandy >From wgchairs-bounces@ietf.org Sat Jun 16 12:51:49 2007 X-Original-To: sandy@pecan.tislabs.com Delivered-To: sandy@pecan.tislabs.com Date: Sat, 16 Jun 2007 09:55:05 -0700 From: Lakshminath Dondeti User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: wgchairs@ietf.org, irsg@isi.edu, bofchairs@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: Subject: Request to forward the Nomcom 2007-8 Announcement to lists you manage X-BeenThere: wgchairs@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Working Group Chairs List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: wgchairs-bounces@ietf.org Folks, We have around 50 volunteers so far for Nomcom 2007-8 voting member selection. We need a lot more! Not everyone subscribes to the IETF-Announce list. Could you please forward the announcement https://datatracker.ietf.org/public/show_nomcom_message.cgi?id=1234 to WG, RG, BoF, Area lists that you manage? Thanks in advance. best regards, Lakshminath _______________________________________________ Sidr mailing list Sidr@ietf.org https://www1.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Tue Jul 03 10:16:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5jAi-00033X-Dm; Tue, 03 Jul 2007 10:16:04 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5jAH-0001x5-Ck; Tue, 03 Jul 2007 10:15:37 -0400 Received: from ns4.neustar.com ([156.154.24.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I5jAH-0007hE-5J; Tue, 03 Jul 2007 10:15:37 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id 0B9E72AC79; Tue, 3 Jul 2007 14:15:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1I5j9h-0006IU-Nt; Tue, 03 Jul 2007 10:15:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Tue, 03 Jul 2007 10:15:01 -0400 X-Spam-Score: 0.3 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Cc: sidr@ietf.org Subject: [Sidr] I-D ACTION:draft-ietf-sidr-res-certs-07.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , 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-07.txt Pages : 30 Date : 2007-7-3 This document defines a standard profile for X.509 certificates for the purposes of supporting validation of assertions of "right-to-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 Resource Certificate. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sidr-res-certs-07.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sidr-res-certs-07.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sidr-res-certs-07.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. 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: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-7-3093412.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sidr-res-certs-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sidr-res-certs-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-7-3093412.I-D@ietf.org> --OtherAccess-- --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://www1.ietf.org/mailman/listinfo/sidr --NextPart-- From sidr-bounces@ietf.org Mon Jul 09 18:02:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I81JI-0004tt-NH; Mon, 09 Jul 2007 18:02:24 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I81JH-0004tn-RI for sidr@ietf.org; Mon, 09 Jul 2007 18:02:23 -0400 Received: from ns1.tislabs.com ([192.94.214.100] helo=nutshell.tislabs.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I81JH-0003QX-GP for sidr@ietf.org; Mon, 09 Jul 2007 18:02:23 -0400 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id l69LwGkm016332 for ; Mon, 9 Jul 2007 17:58:21 -0400 (EDT) Received: from pecan.tislabs.com(10.66.1.30) by nutshell.tislabs.com via csmap (V6.0) id srcAAAh0ayUF; Mon, 9 Jul 07 17:56:47 -0400 Received: by pecan.tislabs.com (Postfix, from userid 2005) id 7BDD53F48C; Mon, 9 Jul 2007 17:54:46 -0400 (EDT) To: sidr@ietf.org Message-Id: <20070709215446.7BDD53F48C@pecan.tislabs.com> Date: Mon, 9 Jul 2007 17:54:46 -0400 (EDT) From: sandy@tislabs.com (Sandy Murphy) X-Spam-Score: 0.0 (/) X-Scan-Signature: 2870a44b67ee17965ce5ad0177e150f4 Cc: sandy@tislabs.com Subject: [Sidr] reminder: agenda items due X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: sidr-bounces@ietf.org If anyone wants to speak at the Chicago meeting and has not already communicated with Geoff and me, please do so by Wednesday morning (ET). --Sandy _______________________________________________ Sidr mailing list Sidr@ietf.org https://www1.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Mon Jul 09 18:10:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I81Qz-0004dj-E0; Mon, 09 Jul 2007 18:10:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I81Qx-0004dc-8a for sidr@ietf.org; Mon, 09 Jul 2007 18:10:19 -0400 Received: from nutshell.tislabs.com ([192.94.214.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I81Qq-0008SC-O2 for sidr@ietf.org; Mon, 09 Jul 2007 18:10:19 -0400 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id l69M6ih9016784; Mon, 9 Jul 2007 18:07:27 -0400 (EDT) Received: from pecan.tislabs.com(10.66.1.30) by nutshell.tislabs.com via csmap (V6.0) id srcAAArOaqRG; Mon, 9 Jul 07 18:05:32 -0400 Received: by pecan.tislabs.com (Postfix, from userid 2005) id 230EE3F47F; Mon, 9 Jul 2007 16:58:11 -0400 (EDT) To: jabley@ca.afilias.info, sidr@ietf.org Subject: Re: [Sidr] other means of trusting announcements In-Reply-To: Message-Id: <20070709205811.230EE3F47F@pecan.tislabs.com> Date: Mon, 9 Jul 2007 16:58:11 -0400 (EDT) From: sandy@tislabs.com (Sandy Murphy) X-Spam-Score: 0.0 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Cc: sandy@tislabs.com X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: sidr-bounces@ietf.org A late reply to Joe's message: >The RPSL repository operated by the RIPE NCC (the "RIPE database") on >behalf of RIPE members (and others) incorporates a feature which I >believe is not available in corresponding services offered by other >RIRs. The assignment/allocation data from the RIR (in the form of >RPSL inetnum, aut-num, etc objects) is linked for the purposes of >authentication with routing data (e.g. route, route6, etc objects). > >This linkage is provided by RPSS (Routing Policy System Security). >RPSS is documented in RFC 2725, but I do not know how accurate that >document is with respect to the code which is actually running today >in Amsterdam. I recall asking at the mike in the Oct 06 ARIN meeting about support for RPSS. Andrei Robachevsky (RIPE rep there at the time) said that RIPE fully supports RPSS. (Ray Plzak said that ARIN did not.) I've also been told by people from the RIPE region that they must adhere to the RPSS rules when registering objects. So I believe that the actually running RIPE code is doing RPSS. >In broad terms (and apologies to those who know the details of this, >and who are now cringing) it is not possible to register a route >object in the RIPE database if you are not authorised to manipulate >the corresponding (covering) inetnum object. The actual RPSS rule is that you have to be authorized for the inetnum for the prefix AND the aut-num for the AS. This was the RIPE authorization model that I mentioned in last Nov's sidr meeting. I asked if the ROA we produced should do that dual authorization, or stick with authorization by the prefix holder only. The comments at the mike seemed to agree that the authorization by the prefix holder only was appropriate. >[The big hole in this trust dynamic is that for addresses assigned by >other RIRs, no such linkage exists; in practice anybody can install >route objects for addresses they have no business announcing in the >RIPE database so long as those route objects don't already exist, and >so long as the addresses concerned are not taken from one of the RIPE >NCC's pools.] So RIR-run IRRs have the opportuntity to authenticate registrations from that RIR's members. Those RIR's who have just one database that holds both resource information and routing policy information (e.g., RIPE) have an easier time of this than those RIR's who have separate the resource database from the routing policy database (e.g., ARIN). RIR run IRRs can not authenticate registrations from non-members. non-RIR run IRRs (RADB?) can not directly authenticate anything registered with them. Incidentally, from what I've heard and overheard from ARIN staff, ARIN's IRR will authenticate registrations against the authentication in their resource database. But: - the mtn-by in the IRR database side is not always in sync with the POC in the resource database side, which can make authentication difficult when they do not match - they allow but can't authentiate registrations for non-members (see above) - they authenticate inetnum and aut-num registrations, but do not authenticate route objects. >The key point is that it is possible to build a prefix filter based >on policy expressed in an aut-num or as-set RPSL object using the >RIPE database I thought the RPLS route object was the closest match to the ROA, not the aut-num/as-set. Wrong? There is one other basic difference between the IRR authorization model and the resource certificates and ROAs we are defining. The IRRs use a secure channel model; we use a secure object model. The IRR model is that the registry authenticates input to it, stores the authenticated input, and you get your data (hopefully through a protected channel) from the IRR. Getting a copy of the IRR data from anywhere else gives you no assurance in the data. In the resource certificates and ROAs, the objects themselves are protected, so you can get the objects by any channel (posted somewhere, peer-peer exchanges, rsynch...) from anywhere and the objects are still protected. --Sandy _______________________________________________ Sidr mailing list Sidr@ietf.org https://www1.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Mon Jul 09 19:20:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I82X4-0001DY-Vw; Mon, 09 Jul 2007 19:20:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I82X3-0001DP-Gi for sidr@ietf.org; Mon, 09 Jul 2007 19:20:41 -0400 Received: from monster.hopcount.ca ([199.212.90.4]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I82Wz-0001i2-4x for sidr@ietf.org; Mon, 09 Jul 2007 19:20:41 -0400 Received: from yxu1b30.hopcount.ca ([199.212.90.30]) by monster.hopcount.ca with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.67 (FreeBSD)) (envelope-from ) id 1I82ZU-0009Yv-Gk; Mon, 09 Jul 2007 23:23:12 +0000 In-Reply-To: <20070709205811.230EE3F47F@pecan.tislabs.com> References: <20070709205811.230EE3F47F@pecan.tislabs.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <36988402-EDEF-46AE-9178-C901D15D53BC@ca.afilias.info> Content-Transfer-Encoding: 7bit From: Joe Abley Subject: Re: [Sidr] other means of trusting announcements Date: Mon, 9 Jul 2007 19:20:15 -0400 To: sandy@tislabs.com (Sandy Murphy) X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: sidr@ietf.org X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: sidr-bounces@ietf.org On 9-Jul-2007, at 16:58, Sandy Murphy wrote: > I recall asking at the mike in the Oct 06 ARIN meeting about support > for RPSS. Andrei Robachevsky (RIPE rep there at the time) said that > RIPE fully supports RPSS. As a some-time use of the RIPE db, I agree. > (Ray Plzak said that ARIN did not.) Similarly, as a some-time user of the ARIN db, I agree with that too. >> The key point is that it is possible to build a prefix filter based >> on policy expressed in an aut-num or as-set RPSL object using the >> RIPE database > > I thought the RPLS route object was the closest match to the ROA, not > the aut-num/as-set. Wrong? What usually happens is that for each ISP there is a set of AS numbers, the members of which are used to originate routes. One (or more) of those ASes will roughly equate to "the ISP". The rest probably can be treated as "BGP-speaking customers". A peer (in the BGP sense, not the economic sense) of that ISP who wants to filter prefixes announced from that ISP's routers might ask "what's your AS-SET?" and receive the name of an object whose members are the ASes mentioned above. The peer can then query the whois server and enumerate "all routes with an origin AS that is a member of this set". I think in the context of SIDR, the IRR as a whole (the RPSS- supporting minority and the rest) represents a source of possibly- feasible routes that a peer AS might want to announce. There are other such sources (e.g. mail from customers saying "please announce X"). RPSS means the set is more likely to be accurate, but it's still no guarantee of anything in practice (and will never be so long as there are RPSL repositories run by people who are not RIRs). However you obtain your list of feasible routes, you still need a reliable, automated mechanism for deciding whether a given route is actually sensible to accept. It seems to me that most of that would be accomplished by the work being discussed here (with the possible exception of a convention or protocol to allow ROAs to be retrieved?). Joe _______________________________________________ Sidr mailing list Sidr@ietf.org https://www1.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Tue Jul 10 13:15:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8JIw-0003WY-My; Tue, 10 Jul 2007 13:15:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8JIk-00038A-Jz; Tue, 10 Jul 2007 13:15:02 -0400 Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I8JIk-000394-CW; Tue, 10 Jul 2007 13:15:02 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id 428A726EB9; Tue, 10 Jul 2007 17:15:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1I8JIk-0006Cj-4J; Tue, 10 Jul 2007 13:15:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Tue, 10 Jul 2007 13:15:02 -0400 X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Cc: sidr@ietf.org Subject: [Sidr] I-D ACTION:draft-ietf-sidr-cps-irs-02.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , 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 : Template for an Internet Registry's Certification Practice Statement (CPS) for the Internet IP Address and AS Number (PKI) Author(s) : S. Kent, et al. Filename : draft-ietf-sidr-cps-irs-02.txt Pages : 45 Date : 2007-7-10 This document contains a template to be used for creating a Certification Practice Statement (CPS) for an Internet Registry (e.g., NIR or RIR) that is part of the Internet IP Address and Autonomous System (AS) Number Public Key Infrastructure (PKI). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sidr-cps-irs-02.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sidr-cps-irs-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sidr-cps-irs-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. 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: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-7-10121830.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sidr-cps-irs-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sidr-cps-irs-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-7-10121830.I-D@ietf.org> --OtherAccess-- --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://www1.ietf.org/mailman/listinfo/sidr --NextPart-- From sidr-bounces@ietf.org Tue Jul 10 13:15:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8JJD-0003x8-72; Tue, 10 Jul 2007 13:15:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8JIk-00038V-S1; Tue, 10 Jul 2007 13:15:02 -0400 Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I8JIk-000396-HX; Tue, 10 Jul 2007 13:15:02 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id 6248F26EC3; Tue, 10 Jul 2007 17:15:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1I8JIk-0006Cp-5f; Tue, 10 Jul 2007 13:15:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Tue, 10 Jul 2007 13:15:02 -0400 X-Spam-Score: 0.0 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: sidr@ietf.org Subject: [Sidr] I-D ACTION:draft-ietf-sidr-roa-format-01.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , 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 Route Origin Authorizations (ROAs) Author(s) : S. Kent, et al. Filename : draft-ietf-sidr-roa-format-01.txt Pages : 12 Date : 2007-7-10 This document defines a standard profile for Route Origin Authorizations (ROAs). A ROA is a digitally signed object that provides a means of verifying that an IP address block holder has authorized an Autonomous System (AS) to originate routes to that one or more prefixes within the address block. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sidr-roa-format-01.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sidr-roa-format-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sidr-roa-format-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. 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: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-7-10122125.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sidr-roa-format-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sidr-roa-format-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-7-10122125.I-D@ietf.org> --OtherAccess-- --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://www1.ietf.org/mailman/listinfo/sidr --NextPart-- From sidr-bounces@ietf.org Tue Jul 10 13:15:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8JJQ-0004cN-AC; Tue, 10 Jul 2007 13:15:44 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8JIl-00038q-AM; Tue, 10 Jul 2007 13:15:03 -0400 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I8JIk-0002Gl-R9; Tue, 10 Jul 2007 13:15:03 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id 8477F17610; Tue, 10 Jul 2007 17:15:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1I8JIk-0006Cg-3Z; Tue, 10 Jul 2007 13:15:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Tue, 10 Jul 2007 13:15:02 -0400 X-Spam-Score: 0.0 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Cc: sidr@ietf.org Subject: [Sidr] I-D ACTION:draft-ietf-sidr-cp-02.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , 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 : Certificate Policy (CP) for the Internet IP Address and AS Number (PKI) Author(s) : K. Seo, et al. Filename : draft-ietf-sidr-cp-02.txt Pages : 45 Date : 2007-7-10 This document describes the certificate policy for a PKI used to support improved routing security. Each organization that allocates IP addresses or Autonomous System (AS) numbers to an organization will, in parallel, issue a certificate reflecting this allocation. These certificates will enable verification that the holder of the associated private key has been allocated the resources indicated in the certificate, and is the current, unique holder of these resources. The PKI in which the certificates issued under this policy are employed, in conjunction with ancillary digitally signed data structures, will provide critical inputs for routing security mechanisms, e.g., generation of route filters by ISPs. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sidr-cp-02.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sidr-cp-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sidr-cp-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. 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: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-7-10121640.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sidr-cp-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sidr-cp-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-7-10121640.I-D@ietf.org> --OtherAccess-- --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://www1.ietf.org/mailman/listinfo/sidr --NextPart-- From sidr-bounces@ietf.org Tue Jul 10 13:17:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8JJa-00057L-R9; Tue, 10 Jul 2007 13:15:54 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8JJE-000450-Qr; Tue, 10 Jul 2007 13:15:32 -0400 Received: from ns4.neustar.com ([156.154.24.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I8JJE-0002Hm-JK; Tue, 10 Jul 2007 13:15:32 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id 7AE012ACAF; Tue, 10 Jul 2007 17:15:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1I8JIk-0006Cm-4z; Tue, 10 Jul 2007 13:15:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Tue, 10 Jul 2007 13:15:02 -0400 X-Spam-Score: 0.0 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: sidr@ietf.org Subject: [Sidr] I-D ACTION:draft-ietf-sidr-cps-isp-01.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , 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 : Template for an Internet Service Provider's Certification Practice Statement (CPS) for the Internet IP address and AS Number PKI Author(s) : D. Kong, et al. Filename : draft-ietf-sidr-cps-isp-01.txt Pages : 48 Date : 2007-7-10 This document contains a template to be used for creating a Certification Practice Statement (CPS) for a Local Internet Registry (LIR) or Internet Service Provider (ISP) that is part of the Internet IP Address and Autonomous System (AS) Number Public Key Infrastructure (PKI). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sidr-cps-isp-01.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sidr-cps-isp-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sidr-cps-isp-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. 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: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-7-10122000.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sidr-cps-isp-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sidr-cps-isp-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-7-10122000.I-D@ietf.org> --OtherAccess-- --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://www1.ietf.org/mailman/listinfo/sidr --NextPart-- From sidr-bounces@ietf.org Tue Jul 10 13:33:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8JaX-0001ZA-NA; Tue, 10 Jul 2007 13:33:25 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8JaT-0001YN-Q0; Tue, 10 Jul 2007 13:33:21 -0400 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I8JaT-0003YH-IF; Tue, 10 Jul 2007 13:33:21 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id AF70D17617; Tue, 10 Jul 2007 17:15:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1I8JIk-0006Cv-7F; Tue, 10 Jul 2007 13:15:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Tue, 10 Jul 2007 13:15:02 -0400 X-Spam-Score: 0.0 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Cc: sidr@ietf.org Subject: [Sidr] I-D ACTION:draft-ietf-sidr-arch-01.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , 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 : An Infrastructure to Support Secure Internet Routing Author(s) : R. Barnes, et al. Filename : draft-ietf-sidr-arch-01.txt Pages : 26 Date : 2007-7-10 This document describes an architecture for an infrastructure to support secure Internet routing. The foundation of this architecture is a public key infrastructure (PKI) that represents the allocation hierarchy of IP address space and Autonomous System Numbers; certificates from this PKI are used to verify signed objects that authorize autonomous systems to originate routes for specified IP address prefixes. The data objects that comprise the PKI, as well as other signed objects necessary for secure routing, are stored and disseminated through a distributed repository system. This document also describes at a high level how this architecture can be used to add security features to common operations such as IP address space allocation and route filter construction. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sidr-arch-01.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sidr-arch-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sidr-arch-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. 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: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-7-10122416.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sidr-arch-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sidr-arch-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-7-10122416.I-D@ietf.org> --OtherAccess-- --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://www1.ietf.org/mailman/listinfo/sidr --NextPart-- From sidr-bounces@ietf.org Tue Jul 10 22:57:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8SO6-0007Zl-Ed; Tue, 10 Jul 2007 22:57:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8SO5-0007ZX-Am for sidr@ietf.org; Tue, 10 Jul 2007 22:57:09 -0400 Received: from mint.apnic.net ([202.12.29.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I8SO0-0002m2-Hb for sidr@ietf.org; Tue, 10 Jul 2007 22:57:09 -0400 Received: from [202.12.29.172] (dhcp172.apnic.net [202.12.29.172]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mint.apnic.net (Postfix) with ESMTP id 5A92ED5F2D for ; Wed, 11 Jul 2007 12:57:03 +1000 (EST) Message-ID: <469446FC.4080709@apnic.net> Date: Wed, 11 Jul 2007 12:57:00 +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: sidr@ietf.org Subject: Re: [Sidr] I-D ACTION:draft-ietf-sidr-roa-format-01.txt References: In-Reply-To: X-Enigmail-Version: 0.95.2 OpenPGP: id=C6B3AE7E; url=http://robert.loomans.org/0xC6B3AE7E.asc X-Spam-Score: 0.0 (/) X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1649251929==" Errors-To: sidr-bounces@ietf.org This is a cryptographically signed message in MIME format. --===============1649251929== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms010509040306000501070000" This is a cryptographically signed message in MIME format. --------------ms010509040306000501070000 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit In section 3 "ROA Validation": > 4. Verify that the EE certificate has an IP Address Delegation > extension [RFC3779] and that the IP address prefix(es) in that > extension exactly matches the IP address prefix(es) in the ROA. I assume this does not require that the encoding match. If it did, it would conflict with RFC3779 which requires the minimal encoding. eg, A ROA could have two prefixes, say 11.0.0.0/8 and 12.0.0.0/8, encoded as two IPAddress fields, whereas RFC3779 would dictate that they would be encoded as a range 11.0.0.0-12.255.255.255. Rob -- Robert Loomans Email: robertl@apnic.net Senior Programmer/Analyst, APNIC Phone: +61 7 3858 3100 http://www.apnic.net Fax: +61 7 3858 3199 --------------ms010509040306000501070000 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 BW8wggRXoAMCAQICAhmqMA0GCSqGSIb3DQEBBQUAMIGOMQswCQYDVQQGEwJBVTEOMAwGA1UE ChMFQVBOSUMxGzAZBgNVBAsTElRlY2huaWNhbCBTZXJ2aWNlczEuMCwGA1UEAxMlQVBOSUMg Q2VydGlmaWNhdGlvbiBBdXRob3JpdHkgTWFuYWdlcjEiMCAGCSqGSIb3DQEJARYTY2FtYW5h Z2VyQGFwbmljLm5ldDAeFw0wNjA4MTYyMzQ0MjJaFw0wNzA4MTYyMzQ0MjJaMEgxCzAJBgNV BAYTAkFQMREwDwYDVQQKEwhBUE5JQy1BUDEXMBUGA1UEAxMOUm9iZXJ0IExvb21hbnMxDTAL BgNVBAUTBDY1NzAwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDIGKArFelrgnyK QHEZnvLP8bvR3jwpKRmaBp8+PrCJRA8ELT3L4ZtY98cYyjAIfFYdt/n9gQjagRaltoEW4bkK Z9cS91onYYCt70xnMzwJrh3ms3rDUeXK5JQqUv3AYpQLfvC5ICV+FBNuIQ26b2hzUgiyOP89 Lc9YHJ2E02ACHKlfsYyWD/vWCd8UOQYyuijkPgHvCncHaEjuSekg8JnWqi9GQtWLt7EmtsLb /D8Yn6beScKex4KK2GZtD8fGyQoCXj25DBSU9OLXE8bDc0V1z8N/RU6TA8paLS+iculoBu1G NXRE3sdyTIS+OXsgwLh6xrY5Lnowow/HkQ7Ckn7hAgMBAAGjggIaMIICFjAJBgNVHRMEAjAA MBEGCWCGSAGG+EIBAQQEAwIFoDALBgNVHQ8EBAMCBeAwJwYJYIZIAYb4QgENBBoWGEFQTklD IENsaWVudCBDZXJ0aWZpY2F0ZTAdBgNVHQ4EFgQU3b65o54yQEQn+fF94hWGnIeCdlUwgbsG A1UdIwSBszCBsIAUFIYCsK64S7Hv0+vi+5IohXeMBOmhgZSkgZEwgY4xCzAJBgNVBAYTAkFV MQ4wDAYDVQQKEwVBUE5JQzEbMBkGA1UECxMSVGVjaG5pY2FsIFNlcnZpY2VzMS4wLAYDVQQD EyVBUE5JQyBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSBNYW5hZ2VyMSIwIAYJKoZIhvcNAQkB FhNjYW1hbmFnZXJAYXBuaWMubmV0ggEAMBwGA1UdEQQVMBOBEXJvYmVydGxAYXBuaWMubmV0 MB4GA1UdEgQXMBWBE2NhbWFuYWdlckBhcG5pYy5uZXQwNwYDVR0fBDAwLjAsoCqgKIYmaHR0 cHM6Ly93d3cuYXBuaWMubmV0L2NhL2NybC9jYWNybC5jcmwwNQYJYIZIAYb4QgEEBCgWJmh0 dHBzOi8vd3d3LmFwbmljLm5ldC9jYS9jcmwvY2FjcmwuY3JsMDUGCWCGSAGG+EIBAwQoFiZo dHRwczovL3d3dy5hcG5pYy5uZXQvY2EvY3JsL2NhY3JsLmNybDANBgkqhkiG9w0BAQUFAAOC AQEAjhazoKEg7sVuzPifVcwRZYSJq7JApAMyGx0RrxqtmMp/lp2vzB89ducRVq+FUfXQXaJc q4FZmJ+1WyncU/p6yJK0z6/FXMf/5eqk6PTC5NJt/yNBifYBV5MYCwuukY0c2b/io4JojR3D kfmuIkmbZPcCep6rDqrwLHIMLjZmL1U1uVlSnhbX8HdHrsURsroRtfXNlWYTnk/dFLBPRmIV 1RhjVODH72qw+fTcSNWWF5jcIPHXj6LeCxSm24xqbKzMuCEUgdWpFtlSK+utIWXrhvzOKK4C xOE1kPsx7lGfGZ+RsLtB6BGx5UC1NotAB9r2UBxkmiJV79kKjOE8rwMcgjCCBW8wggRXoAMC AQICAhmqMA0GCSqGSIb3DQEBBQUAMIGOMQswCQYDVQQGEwJBVTEOMAwGA1UEChMFQVBOSUMx GzAZBgNVBAsTElRlY2huaWNhbCBTZXJ2aWNlczEuMCwGA1UEAxMlQVBOSUMgQ2VydGlmaWNh dGlvbiBBdXRob3JpdHkgTWFuYWdlcjEiMCAGCSqGSIb3DQEJARYTY2FtYW5hZ2VyQGFwbmlj Lm5ldDAeFw0wNjA4MTYyMzQ0MjJaFw0wNzA4MTYyMzQ0MjJaMEgxCzAJBgNVBAYTAkFQMREw DwYDVQQKEwhBUE5JQy1BUDEXMBUGA1UEAxMOUm9iZXJ0IExvb21hbnMxDTALBgNVBAUTBDY1 NzAwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDIGKArFelrgnyKQHEZnvLP8bvR 3jwpKRmaBp8+PrCJRA8ELT3L4ZtY98cYyjAIfFYdt/n9gQjagRaltoEW4bkKZ9cS91onYYCt 70xnMzwJrh3ms3rDUeXK5JQqUv3AYpQLfvC5ICV+FBNuIQ26b2hzUgiyOP89Lc9YHJ2E02AC HKlfsYyWD/vWCd8UOQYyuijkPgHvCncHaEjuSekg8JnWqi9GQtWLt7EmtsLb/D8Yn6beScKe x4KK2GZtD8fGyQoCXj25DBSU9OLXE8bDc0V1z8N/RU6TA8paLS+iculoBu1GNXRE3sdyTIS+ OXsgwLh6xrY5Lnowow/HkQ7Ckn7hAgMBAAGjggIaMIICFjAJBgNVHRMEAjAAMBEGCWCGSAGG +EIBAQQEAwIFoDALBgNVHQ8EBAMCBeAwJwYJYIZIAYb4QgENBBoWGEFQTklDIENsaWVudCBD ZXJ0aWZpY2F0ZTAdBgNVHQ4EFgQU3b65o54yQEQn+fF94hWGnIeCdlUwgbsGA1UdIwSBszCB sIAUFIYCsK64S7Hv0+vi+5IohXeMBOmhgZSkgZEwgY4xCzAJBgNVBAYTAkFVMQ4wDAYDVQQK EwVBUE5JQzEbMBkGA1UECxMSVGVjaG5pY2FsIFNlcnZpY2VzMS4wLAYDVQQDEyVBUE5JQyBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSBNYW5hZ2VyMSIwIAYJKoZIhvcNAQkBFhNjYW1hbmFn ZXJAYXBuaWMubmV0ggEAMBwGA1UdEQQVMBOBEXJvYmVydGxAYXBuaWMubmV0MB4GA1UdEgQX MBWBE2NhbWFuYWdlckBhcG5pYy5uZXQwNwYDVR0fBDAwLjAsoCqgKIYmaHR0cHM6Ly93d3cu YXBuaWMubmV0L2NhL2NybC9jYWNybC5jcmwwNQYJYIZIAYb4QgEEBCgWJmh0dHBzOi8vd3d3 LmFwbmljLm5ldC9jYS9jcmwvY2FjcmwuY3JsMDUGCWCGSAGG+EIBAwQoFiZodHRwczovL3d3 dy5hcG5pYy5uZXQvY2EvY3JsL2NhY3JsLmNybDANBgkqhkiG9w0BAQUFAAOCAQEAjhazoKEg 7sVuzPifVcwRZYSJq7JApAMyGx0RrxqtmMp/lp2vzB89ducRVq+FUfXQXaJcq4FZmJ+1Wync U/p6yJK0z6/FXMf/5eqk6PTC5NJt/yNBifYBV5MYCwuukY0c2b/io4JojR3DkfmuIkmbZPcC ep6rDqrwLHIMLjZmL1U1uVlSnhbX8HdHrsURsroRtfXNlWYTnk/dFLBPRmIV1RhjVODH72qw +fTcSNWWF5jcIPHXj6LeCxSm24xqbKzMuCEUgdWpFtlSK+utIWXrhvzOKK4CxOE1kPsx7lGf GZ+RsLtB6BGx5UC1NotAB9r2UBxkmiJV79kKjOE8rwMcgjGCA8YwggPCAgEBMIGVMIGOMQsw CQYDVQQGEwJBVTEOMAwGA1UEChMFQVBOSUMxGzAZBgNVBAsTElRlY2huaWNhbCBTZXJ2aWNl czEuMCwGA1UEAxMlQVBOSUMgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgTWFuYWdlcjEiMCAG CSqGSIb3DQEJARYTY2FtYW5hZ2VyQGFwbmljLm5ldAICGaowCQYFKw4DAhoFAKCCAgUwGAYJ KoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDcwNzExMDI1NzAwWjAj BgkqhkiG9w0BCQQxFgQUZDbIZU6Nsp5dsHXfC5hsrnLCxXgwUgYJKoZIhvcNAQkPMUUwQzAK BggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYI KoZIhvcNAwICASgwgaYGCSsGAQQBgjcQBDGBmDCBlTCBjjELMAkGA1UEBhMCQVUxDjAMBgNV BAoTBUFQTklDMRswGQYDVQQLExJUZWNobmljYWwgU2VydmljZXMxLjAsBgNVBAMTJUFQTklD IENlcnRpZmljYXRpb24gQXV0aG9yaXR5IE1hbmFnZXIxIjAgBgkqhkiG9w0BCQEWE2NhbWFu YWdlckBhcG5pYy5uZXQCAhmqMIGoBgsqhkiG9w0BCRACCzGBmKCBlTCBjjELMAkGA1UEBhMC QVUxDjAMBgNVBAoTBUFQTklDMRswGQYDVQQLExJUZWNobmljYWwgU2VydmljZXMxLjAsBgNV BAMTJUFQTklDIENlcnRpZmljYXRpb24gQXV0aG9yaXR5IE1hbmFnZXIxIjAgBgkqhkiG9w0B CQEWE2NhbWFuYWdlckBhcG5pYy5uZXQCAhmqMA0GCSqGSIb3DQEBAQUABIIBAAfosaKEDeXi XfpeX0u5LkmVm+f5HX+ugOqFSb6cJReLybABPS66Cf65TvZGMMJCJZNSubDczIcey0EjE7LU hKxl4q6ODgZHiX9QubgIVQmPVL8p4N1pTxUV01mVbVKIzMh2EtDIysODiiuy8sSQT9adpAp8 m+z/73uyKNE0LM1Sl5EJM6ty7jDJar4otAqWhczDeaUe4B3DOmxPct38q+x/k/gBcotNStNP Tv+sMDO29U4feBWjY8oP7olEGq0Y9d2uAOwlA6l3sFgDJQkA1n/cyL0iwPjF8jvpdAtgdXs6 plk+KdAORrAANX9o6tS1rF0bio3N7JKpuXeFZf5vq9sAAAAAAAA= --------------ms010509040306000501070000-- --===============1649251929== 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://www1.ietf.org/mailman/listinfo/sidr --===============1649251929==-- From sidr-bounces@ietf.org Wed Jul 11 10:01:44 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8clD-0007Dz-Tz; Wed, 11 Jul 2007 10:01:43 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8clB-00079A-N1 for sidr@ietf.org; Wed, 11 Jul 2007 10:01:41 -0400 Received: from mx12.bbn.com ([128.33.0.81]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I8cl1-0001CY-Gs for sidr@ietf.org; Wed, 11 Jul 2007 10:01:41 -0400 Received: from dhcp89-089-071.bbn.com ([128.89.89.71]) by mx12.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1I8ckS-0003GH-4v; Wed, 11 Jul 2007 10:00:56 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <469446FC.4080709@apnic.net> References: <469446FC.4080709@apnic.net> Date: Wed, 11 Jul 2007 09:55:19 -0400 To: Robert Loomans From: Stephen Kent Subject: Re: [Sidr] I-D ACTION:draft-ietf-sidr-roa-format-01.txt Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: sidr@ietf.org X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: sidr-bounces@ietf.org At 12:57 PM +1000 7/11/07, Robert Loomans wrote: >Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; > micalg=sha1; boundary="------------ms010509040306000501070000" > >In section 3 "ROA Validation": > >> 4. Verify that the EE certificate has an IP Address Delegation >> extension [RFC3779] and that the IP address prefix(es) in that >> extension exactly matches the IP address prefix(es) in the ROA. > >I assume this does not require that the encoding match. > >If it did, it would conflict with RFC3779 which requires the minimal >encoding. > >eg, A ROA could have two prefixes, say 11.0.0.0/8 and 12.0.0.0/8, >encoded as two IPAddress fields, whereas RFC3779 would dictate that they >would be encoded as a range 11.0.0.0-12.255.255.255. > >Rob Rob, You are correct; the term "exactly" is a bit misleading here. The 3779 encoding is different because it is mandated to be minimal. We should add text to clarify that point, and maybe we should include your example to illustrate what one must do to effect the comparison. There is also a divergence from 3779 because 3779 accommodates ranges, whereas ROAs accommodate only prefixes, since BGP deals with prefixes but not ranges. Steve _______________________________________________ Sidr mailing list Sidr@ietf.org https://www1.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Thu Jul 26 11:29:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IE5HS-0005Xl-48; Thu, 26 Jul 2007 11:29:34 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IE5HQ-0005Xf-FX for sidr@ietf.org; Thu, 26 Jul 2007 11:29:32 -0400 Received: from smtp109.biz.mail.mud.yahoo.com ([68.142.201.178]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IE5HQ-0007qa-2h for sidr@ietf.org; Thu, 26 Jul 2007 11:29:32 -0400 Received: (qmail 42364 invoked from network); 26 Jul 2007 15:29:31 -0000 Received: from unknown (HELO Wylie) (turners@ieca.com@130.129.18.223 with login) by smtp109.biz.mail.mud.yahoo.com with SMTP; 26 Jul 2007 15:29:31 -0000 X-YMail-OSG: pBpKEbEVM1mnSj1sjSqWng4pdn7Gf6Z.h0rWk2f6.m_YypO6EPkB84_BPyRRyhP43C_5WFsYMw-- From: "Turner, Sean P." To: Date: Thu, 26 Jul 2007 10:19:25 -0500 Organization: IECA, Inc. Message-ID: <001401c7cf98$5a6e38a0$df128182@Wylie> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Thread-Index: AcfPmFmhsYrTDvaNSRefOojl0omt0g== X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Subject: [Sidr] Comments on draft-ietf-sidr-format-01.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: turners@ieca.com List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: sidr-bounces@ietf.org Just minor nits: Sec 2.1.3.2: - Missing ',' after the exactMatch BOOLEAN - "SEQUENCE of" should be "SEQUENCE OF" - I like it when the SEQUENCE OF includes a SIZE OF(X..MAX) to indicate whether the SEQUENCE OF can have 0 or more or 1 or more members in the SEQUENCE OF. This applies to the ROAIPAddrBlocks and addresses fields. Sec 2.1.6.2: - It might be useful to point to the res-certs ID for how to make the subjectKeyIdentifier. Additionally, I think it might be good to say the SID must match the SKI of the signer in this section because it talks about making the fields. I know it's in sec 3 step during the "check it" process but I think it should be in the "make it" process section. Sec 2.1.6.5: - RFC3370 says MUST support the rsaEncryption OID and MAY support the shaXYZWithRSAEncryption (where XYZ in this case will be 256) identifier. Should we allow the hash to be explicitly identified? General: - Why no ASN.1 module? spt _______________________________________________ Sidr mailing list Sidr@ietf.org https://www1.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Thu Jul 26 11:32:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IE5KA-00006b-93; Thu, 26 Jul 2007 11:32:22 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IE5K9-0008Up-8G for sidr@ietf.org; Thu, 26 Jul 2007 11:32:21 -0400 Received: from smtp102.biz.mail.mud.yahoo.com ([68.142.200.237]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IE5K8-0007wQ-Q3 for sidr@ietf.org; Thu, 26 Jul 2007 11:32:21 -0400 Received: (qmail 88696 invoked from network); 26 Jul 2007 15:32:20 -0000 Received: from unknown (HELO Wylie) (turners@ieca.com@130.129.18.223 with login) by smtp102.biz.mail.mud.yahoo.com with SMTP; 26 Jul 2007 15:32:19 -0000 X-YMail-OSG: m_KRbV4VM1n4IRA2uouKtNkvHYVFuGvsFQFs5I_gVfT4QWuDvjr84_tNsJkqijENpk0f4c1WTA-- From: "Turner, Sean P." To: Date: Thu, 26 Jul 2007 10:22:13 -0500 Organization: IECA, Inc. Message-ID: <001501c7cf98$bf05b770$df128182@Wylie> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Thread-Index: AcfPmL44KpJ+Ga7hR1aaWauAvzueIw== X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Subject: [Sidr] Comments on draft-ietf-sidr-res-certs-07.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: turners@ieca.com List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: sidr-bounces@ietf.org I searched the mail list archives messages that address these topics, if I missed them forgive me. Sec 3.9.2, 3.9.3, 3.9.6, and 4.7.1: Authority Key Identifier, Subject Key Identifier, and Authority Information Access use the SHA-1 160-bit hash of the key. Since you're using SHA-256 in the certificates why not use the SHA-256 160-bit hash in AKI, SKI, and AIA? It just seems odd you're going to get the CA to issue a certificates with SHA-256 why make them implement another hash algorithm to do SHA-1? Note - I am not raising this a security concern these fields are used as "hint" to build certificate chains. Sec 3.9.4: (Key Usage) If the CA is going to reply with a response to a certificate-request then shouldn't the digitalSignature bit also be set? This is not required but the way it is in the draft now means the CA has a certificate to sign certificates and CRLs and another for certificate-request responses. Sec 3.9.9: (Subject Alternative Name): Seems odd you'd require an X.501 name in this and the subject field (as discussed at the meeting). Sec 5: I think you have to specify the proof-of-possession mechanism. Sec 5.2: (CRMF Profile): While PKCS #10 includes a security encapsulating security protocol CRMF does not. You have to specify what the encapsulating security protocol is - may I suggest a CMS SignedData. Sec 5.2.1: Need to explicitly prohibit issuerUID and subjectUID fields. Sec 5.3: (Key Usage) Change CertificateSigning to keyCertSign and CRLSigning to crlSign. May have to add digitalSignature for CA certs (see comment on Sec 3.9.4). spt _______________________________________________ Sidr mailing list Sidr@ietf.org https://www1.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Thu Jul 26 16:18:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IE9mh-0000L5-90; Thu, 26 Jul 2007 16:18:07 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IE9mf-0000L0-9y for sidr@ietf.org; Thu, 26 Jul 2007 16:18:05 -0400 Received: from mint.apnic.net ([202.12.29.58]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IE9me-00078o-3C for sidr@ietf.org; Thu, 26 Jul 2007 16:18:05 -0400 Received: from [130.129.23.125] (dhcp-177d.ietf69.org [130.129.23.125]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mint.apnic.net (Postfix) with ESMTP id F2D7ED5F36; Fri, 27 Jul 2007 06:18:01 +1000 (EST) Message-ID: <46A901F5.9070503@apnic.net> Date: Fri, 27 Jul 2007 06:20:05 +1000 From: Geoff Huston User-Agent: Thunderbird 2.0.0.5 (Windows/20070716) MIME-Version: 1.0 To: sidr@ietf.org Content-Type: multipart/mixed; boundary="------------010707060208030308030909" X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b6657e60309a1317174c9db2ae5f227 Cc: Sandy Murphy Subject: [Sidr] Minutes of the SIDR WG session at IETF 69 X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: sidr-bounces@ietf.org This is a multi-part message in MIME format. --------------010707060208030308030909 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit As attached - in the absence of any comment these will be submitted to the proceedings Thanks indeed Paul for taking the minutes Geoff & Sandy --------------010707060208030308030909 Content-Type: text/plain; name="minutes.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="minutes.txt" SIDR WG June 26, 2007, 9AM Minutes by Paul Hoffman (Read the slides for more depth) Agenda was bashed 1. Action items left over from IETF68 SIDR WG meeting Steve Kent to consider CAs issuing overalpping certificated to different entities: considered Sandy Murphy to consider rsync as a registered URI Type: would ential direct or third party registration Paul Hoffman had the comment about being specific as to CPS text that should be changed. Noted that provided clear indication where text is to be provided. Joe Abley investigated RIPE database structure vs use in other RIRs (posted 20 Jan 2007) Paul: Question as to architecture as informational or standards track: no clear resolution so far. Steve Kent to add test for 4-byte ASN in ROA format. done. All: match of NLRI to ROA? done. All: Document use cases in architecutre draft. 2. CP/CPS update - Steve Kent presenting Changed in the draft: ERX: how it is represented Added discussion of manifests Added local cache maintenance for RPs Gave overview of the protocol Added: Subject name conventions Discussion of default trust anchors (IANA? RIRs?) ERX How RIRs deal with early registration Need to add discussion of how to match prefixes and ranges by algorithm Need to create a separate document on repository operations Added semantics and syntax for manifest Per-CA signed blob use to detect active attacks against the repository Local cache management for RPs Suggestions for how to manage Operations section Added discussion of when you don't need a cert Dealing with 4-byte ASs and 2-byte ASs Question about matching ROAs to BGP updates Maybe we need to break the one-to-one mapping between the ROA and signing certificate example case of a /19 announcement based on /20 prefixes with different validation paths revise the ROA spec to allow ROAs to be signed by 2 or more EE certificates. Lots of people have read the draft 3. CP & CPS for RIRs & CPS for ISP - Steve Kent Removed references to certificate acceptance by Subject Certificates are being issued as a side-effect Subjects don't even ask for a particular name No commitment process CPSs are usually written from a template Suggestion to not take anything else Steve is concerned that not enough people are reading the CP Wants each RIR to review the document 4. Resource Certificate Profile - George Michaelson Humorous comment on bordellos and the meeting room Background overview Most important: do not give out more than you have authorization to give Lots of language cleanup in -07 Suggestions for revision Remove SubjectAltName Require PKCS#10, allow CRMF for interactive Issuer determines the subject name Rsync is mandatory? Question about why Subject CommonName vs AltName Can the name be present but NULL? No; at least stick in maybe a hash of the public key Yes; it doesn't matter because the issued cert will have a unique name Made a bunch of normative changes (see the slides) Next steps One more round, then WG last call Not as many people have read this document as the architecture document 5. ROA Format - Matt Lepinski Overview of ROA design and use Changes since -00 Now only include IP address prefixes, not ranges Added an "exact match" flag for how the owner can announce Described how a ROA is validated Open issues Need more detail about how to compare IP address ranges Maybe requiring exact match on prefixes is too restrictive Proposal to add a boolean flag for ExactMatch Discussion of use cases and needs for range matching for smaller ranges Discussion of pushing RPSL into a ROA Where do we stop? RPSL is very expressive Is this enough for the policies we want, or do we need more? Balance complication vs. expressiveness General view that existing boolean allows for particular policies to be expressed by the set of enumerated of exact match permit ROAs, so that min/max prefix size constraint in the ROA is not required - the boolean flag is considered to be adequate here 6. Private Address Space - Sandy Murphy What should people do with RFC 1918 address space? 1) Don't announce it at all 2) Use a local trust anchor and SIDR For IPv6, the issues are similar but different due to unique local addresses (ULAs) IPv6 WG is discussing registering ULAs Maybe these will be chosen by RIRs Should we add this to the architecture draft? Do we want to wait for ULA to finish? Question about why this is even a question Should the architecture document even cover this? Maybe IANA needs to leave it as an unsigned delegation Related question: does IANA sign 0/0 or not? More consideration needed on this topic 7. Open discussion Steve Kent suggested that there where three new drafts that might be written: Repository structure? Manifest? Up down protocol from the RIR?  APNIC author group volunteered to edit the repository structure draft Manifest is already described in architecture document, and no clear support from the WG to work on this as a separate document Further consideration fo the UP/DOWN protocol as this is not necessarily part of the SIDR charter per se. Noted that DNSSEC has similar issue as 0/0 Specify in your config file "Space X is covered by trust anchor A" and so on It's a pruned tree Good to be able to specify scoping in a standardized way Comparison of IANA assertions: 1) Everything (and you know what are private), or: 2) Public addresses only Note that the latter allows someone else to claim they are authoritative for some of the private space in local contexts. This may be a feature. --------------010707060208030308030909 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://www1.ietf.org/mailman/listinfo/sidr --------------010707060208030308030909-- From sidr-bounces@ietf.org Mon Jul 30 13:15:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFYq0-00055D-Jj; Mon, 30 Jul 2007 13:15:20 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFYpj-0004nE-Uq; Mon, 30 Jul 2007 13:15:04 -0400 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IFYpj-0001y2-Fl; Mon, 30 Jul 2007 13:15:03 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id 243B917610; Mon, 30 Jul 2007 17:15:03 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1IFYpi-0004nQ-FK; Mon, 30 Jul 2007 13:15:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Mon, 30 Jul 2007 13:15:02 -0400 X-Spam-Score: 0.0 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Cc: sidr@ietf.org Subject: [Sidr] I-D ACTION:draft-ietf-sidr-res-certs-08.txt X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , 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-08.txt Pages : 30 Date : 2007-7-30 This document defines a standard profile for X.509 certificates for the purposes of supporting validation of assertions of "right-to-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-08.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sidr-res-certs-08.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sidr-res-certs-08.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. 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: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-7-30123937.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sidr-res-certs-08.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sidr-res-certs-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-7-30123937.I-D@ietf.org> --OtherAccess-- --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://www1.ietf.org/mailman/listinfo/sidr --NextPart-- From sidr-bounces@ietf.org Mon Jul 30 16:03:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFbSK-0007Of-LP; Mon, 30 Jul 2007 16:03:04 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFbSJ-0007OQ-50 for sidr@ietf.org; Mon, 30 Jul 2007 16:03:03 -0400 Received: from mx12.bbn.com ([128.33.0.81]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IFbSI-00084j-Es for sidr@ietf.org; Mon, 30 Jul 2007 16:03:02 -0400 Received: from dhcp89-089-071.bbn.com ([128.89.89.71]) by mx12.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1IFbSH-0007mU-6F for sidr@ietf.org; Mon, 30 Jul 2007 16:03:02 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <46A901F5.9070503@apnic.net> References: <46A901F5.9070503@apnic.net> Date: Mon, 30 Jul 2007 16:03:30 -0400 To: sidr@ietf.org From: Stephen Kent Subject: Re: [Sidr] Minutes of the SIDR WG session at IETF 69 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: sidr-bounces@ietf.org Geoff & Sandy, The meeting minutes labeled item #2 as "CP/CPS update" but it was really an update on the Architecture document. I'd also like to add some additional comments to the discussion of local and reserved addresses and the representation of these address types in the PKI. I have previously suggested that IANA issued certs for RFC 1918 addresses. If IANA has a cert with the 0/0 address space extension, certs for these 1918 address blocks will verify properly under the RFC 3779 rules. If IANA destroys/forgets the private keys for these certs, then nobody will be able to generate valid certs for them under the default set of trust anchors. If an ISP or enterprise uses 1918 addresses, then it can configure a trust anchor for them and issue certs for these address blocks under that TA. Because the certs would be issued under that TA, standard cert chaining (based on Issuer/Subject name matching) will automatically cause these certs to be traced to that locally controlled TA. I believe the same analysis will apply to ULA address in IPv6 (in response to Sandy's question). The bottom line is that use of locally-controlled TAs allows an ISP or enterprise to make use of RFC 1918 IPv4 and IPv6 ULA addresses in a way that is completely consistent with the proposed architecture, and with standard cert path discovery and validation mechanisms. Thus IANA can have a 0/0 address extension in its cert and can issue certs for the 1918 addresses to preclude accidental validation via the default TA set without impinging on the ability of nets to use local addresses. Finally, If we choose to adopt IANA as the default TA for the PKI, it can have the 0/0 address space extension, to make its allocations to the RIRs consistent with the RFC 3779 path validation model. Of course this last topic is a separate decision form the others described above. Steve _______________________________________________ Sidr mailing list Sidr@ietf.org https://www1.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Mon Jul 30 18:01:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFdIw-00064t-Al; Mon, 30 Jul 2007 18:01:30 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFdIv-00064j-1W; Mon, 30 Jul 2007 18:01:29 -0400 Received: from pacdcimo01.cable.comcast.com ([24.40.8.145]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IFdIu-0003wX-Dz; Mon, 30 Jul 2007 18:01:28 -0400 Received: from ([24.40.15.92]) by pacdcimo01.cable.comcast.com with ESMTP id KP-BXT38.6017934; Mon, 30 Jul 2007 18:01:10 -0400 Received: from mail pickup service by PACDCEXCSMTP03.cable.comcast.com with Microsoft SMTPSVC; Mon, 30 Jul 2007 18:01:09 -0400 Received: from PACDCEXCSMTP04.cable.comcast.com ([24.40.15.118]) by PAOAKEXCSMTP01.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 30 Jul 2007 13:19:26 -0400 Received: from cable.comcast.com ([24.40.8.142]) by PACDCEXCSMTP04.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 30 Jul 2007 13:19:23 -0400 Received: from ([24.40.8.144]) by PACDCIMI01.cable.comcast.com with ESMTP id KP-NTD71.27051711; Mon, 30 Jul 2007 13:19:05 -0400 Received: from ([156.154.16.145]) by pacdcedge02.cable.comcast.com with ESMTP with TLS id 5302274.EDGE; Mon, 30 Jul 2007 13:19:05 -0400 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFYpo-0004qL-55; Mon, 30 Jul 2007 13:15:08 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFYpj-0004nE-Uq; Mon, 30 Jul 2007 13:15:04 -0400 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IFYpj-0001y2-Fl; Mon, 30 Jul 2007 13:15:03 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id 243B917610; Mon, 30 Jul 2007 17:15:03 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1IFYpi-0004nQ-FK; Mon, 30 Jul 2007 13:15:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Mon, 30 Jul 2007 13:15:02 -0400 X-Spam-Score: 0.0 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b X-BeenThere: i-d-announce@ietf.org X-Mailman-Version: 2.1.5 Precedence: list X-ESP: ESP<-34>=RBL:<-49> SHA:<15> UHA:<0> BAYES:<0> SenderID:<0> Spam Dictionary (TRU10):<0> embed_spam:<0> scam_spam:<0> Obscenities Dictionary (TRU10):<0> Scam Dictionary (TRU10):<0> lotto_spam:<0> Adult Dictionary (TRU10):<0> Embed HTML Dictionary (TRU10):<0> stock_spam:<0> watch_spam:<0> Float Dictionary (TRU10):<0> html_image_spam:<0> money_spam:<0> HTML Dictionary (TRU10):<0> URL Real-Time Signatures:<0> Spam Dictionary 2 (TRU10):<0> SIG: X-OriginalArrivalTime: 30 Jul 2007 17:19:23.0161 (UTC) FILETIME=[C5C6B090:01C7D2CD] X-Spam-Score: 0.0 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 Cc: sidr@ietf.org Subject: [Sidr] I-D ACTION:draft-ietf-sidr-res-certs-08.txt X-BeenThere: sidr@ietf.org Reply-To: internet-drafts@ietf.org List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , 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-08.txt Pages : 30 Date : 2007-7-30 This document defines a standard profile for X.509 certificates for the purposes of supporting validation of assertions of "right-to-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-08.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sidr-res-certs-08.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sidr-res-certs-08.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. 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: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-7-30123937.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sidr-res-certs-08.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sidr-res-certs-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-7-30123937.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce --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://www1.ietf.org/mailman/listinfo/sidr --NextPart-- From sidr-bounces@ietf.org Tue Jul 31 10:16:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFsWK-0001db-Sc; Tue, 31 Jul 2007 10:16:20 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFsWK-0001dR-3m for sidr@ietf.org; Tue, 31 Jul 2007 10:16:20 -0400 Received: from mx11.bbn.com ([128.33.0.80]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IFsWJ-0003J1-PJ for sidr@ietf.org; Tue, 31 Jul 2007 10:16:20 -0400 Received: from dhcp89-089-119.bbn.com ([128.89.89.119] helo=[127.0.0.1]) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1IFsWJ-0004M1-4A; Tue, 31 Jul 2007 10:16:19 -0400 Message-ID: <46AF4432.7030106@bbn.com> Date: Tue, 31 Jul 2007 10:16:18 -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: turners@ieca.com Subject: Re: [Sidr] Comments on draft-ietf-sidr-format-01.txt References: <001401c7cf98$5a6e38a0$df128182@Wylie> In-Reply-To: <001401c7cf98$5a6e38a0$df128182@Wylie> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: sidr@ietf.org X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: sidr-bounces@ietf.org Sean, Thanks a lot for the feedback. Comments are inline. Turner, Sean P. wrote: >Just minor nits: > >Sec 2.1.3.2: > - Missing ',' after the exactMatch BOOLEAN > - "SEQUENCE of" should be "SEQUENCE OF" > - I like it when the SEQUENCE OF includes a SIZE OF(X..MAX) to indicate >whether the SEQUENCE OF can have 0 or more or 1 or more members in the >SEQUENCE OF. This applies to the ROAIPAddrBlocks and addresses fields. > > It seems reasonable to include a SIZE OF(1..MAX) to the ROAIPAddrBlocks and addresses fields. >Sec 2.1.6.2: > - It might be useful to point to the res-certs ID for how to make the >subjectKeyIdentifier. Additionally, I think it might be good to say the SID >must match the SKI of the signer in this section because it talks about >making the fields. I know it's in sec 3 step during the "check it" process >but I think it should be in the "make it" process section. > > I wholeheartedly agree. >Sec 2.1.6.5: > - RFC3370 says MUST support the rsaEncryption OID and MAY support the >shaXYZWithRSAEncryption (where XYZ in this case will be 256) identifier. >Should we allow the hash to be explicitly identified? > > Since the SignerInfo object includes a DigestAlgorithmIdentifier, I see no need to explicitly specify the hash algorithm as part of the signatureAlgorithm. >General: > - Why no ASN.1 module? > > I need to give this a little more thought, but it does seem reasonable to include an ASN.1 module _______________________________________________ Sidr mailing list Sidr@ietf.org https://www1.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Tue Jul 31 10:53:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFt6Y-0007C3-FJ; Tue, 31 Jul 2007 10:53:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFt6Y-0007By-3X for sidr@ietf.org; Tue, 31 Jul 2007 10:53:46 -0400 Received: from mx11.bbn.com ([128.33.0.80]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IFt6W-0002ef-Sx for sidr@ietf.org; Tue, 31 Jul 2007 10:53:46 -0400 Received: from dhcp89-089-119.bbn.com ([128.89.89.119] helo=[127.0.0.1]) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1IFt6W-0005ED-4u; Tue, 31 Jul 2007 10:53:44 -0400 Message-ID: <46AF4CF8.5080100@bbn.com> Date: Tue, 31 Jul 2007 10:53:44 -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: sidr@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Cc: rescert@apnic.net Subject: [Sidr] Multiple Signatures on a ROA X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: sidr-bounces@ietf.org At the Sidr meeting at IETF 69, the following issue was raised in regards to matching ROAs with NLRI in a BGP update. Consider an ISP that receives an allocation of a /20 prefix from source A, and an allocation of an adajecnt /20 prefix from source B, but wants to issue an advertisement for the aggregate /19 prefix. Note that since the allocations are received from different sources, the ISP will have one certificate for each alloation and the certificates will have different validation paths. Therefore, the ISP cannot create a single end-entity certificate the encompasses the entire /19 prefix (i.e. any certificate encompassing the entire /19 prefix would fail validation according to RFC 3779 rules). This means that under the current one-to-one correspondence between ROAs and end-entity certificates, the ISP would have to create 2 separate ROAs, one for each of the /20 prefixes. Similarly, one can imagine a scenario where an ISP receives adjacent allocations from three sources and wants to announce an aggregate prefix (e.g. the ISP receives a /19, a /20 and a second /20 and wants to announce a /18). This would currently require issuing three separate ROAs. Thus, if we continue to mandate a one-to-one correspondence between ROAs and end-entity certificates, we place the burden on the recipient of a BGP Update to determine if there is any collection of valid ROAs that could be aggregated to form the NLRI in the Update message. That is, upon receiving an advertisement for a /18 prefix originated by AS 123, one must example all of the ROAs containing AS 123 and determine if any subset of them can be aggregated to form the /18 prefix in question. No one in the room at the Sidr meeting indicated that they believed this was a good idea. An alternative approach is to break the one-to-one correspondence between ROAs and end-entity certificates by allowing two signatures on a single ROA. Returning to our original example, the ISP would now create two end-entity certificates, one containing the /20 prefix from source A and the other containing the /20 prefix from source B. The ISP would then issue a single ROA for the aggregate /19 prefix and attach two signatures, one that could be verified using the first end-entity certificate and one that could be verified using the second end-entity certificate. Several people in the room at the Sidr meeting indicated that they believed this was a good idea. Therefore, I was wondering if there was consensus that the ROA format should be changed to allow multiple signatures? Or if the working group felt there was a better approach for matching ROAs against the NLRI in a BGP Update? If we are going to allow two signatures on a ROA, I'd like to begin revising the ROA format draft at some point next week so that we have time to go through two versions of the ROA draft (if needed) before the next IETF meeting. Therefore, if you do not believe that allowing multiple signatures on a ROA is a good approach, please let me know before August 8. Thanks, - Matt Lepinski :-> _______________________________________________ Sidr mailing list Sidr@ietf.org https://www1.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Tue Jul 31 11:07:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFtKA-0007JU-Ug; Tue, 31 Jul 2007 11:07:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFtK9-0007JI-41 for sidr@ietf.org; Tue, 31 Jul 2007 11:07:49 -0400 Received: from out002.apptix.savvis.net ([216.91.32.45] helo=out002a.email.savvis.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IFtK7-00030L-Of for sidr@ietf.org; Tue, 31 Jul 2007 11:07:49 -0400 Received: from S228130HZ1EW24.apptix-01.savvis.net ([10.146.4.22]) by out002a.email.savvis.net with Microsoft SMTPSVC(6.0.3790.1830); Tue, 31 Jul 2007 10:07:47 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: Re: [Sidr] Multiple Signatures on a ROA Date: Tue, 31 Jul 2007 10:07:46 -0500 Message-ID: <2DC6358FAE5D5F44A12DC5ABFDA8AC4D0A4FA9@s228130hz1ew24.apptix-01.savvis.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sidr] Multiple Signatures on a ROA Thread-Index: AcfThI3YH987cxjmQsOjgB+WGtgMgg== From: "Schliesser, Benson" To: , X-OriginalArrivalTime: 31 Jul 2007 15:07:47.0440 (UTC) FILETIME=[8DF90700:01C7D384] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7e439b86d3292ef5adf93b694a43a576 Cc: rescert@apnic.net X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1556763915==" Errors-To: sidr-bounces@ietf.org This is a multi-part message in MIME format. --===============1556763915== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7D384.8DD8C9AF" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7D384.8DD8C9AF Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 TWF0dC0NCg0KTGVhdmluZyBhc2lkZSB0aGUgcXVlc3Rpb24gb2YgbXVsdGlwbGUgc2lnbmF0dXJl cywgSSdtIGRvdWJ0ZnVsIG9mIHlvdXIgZXhhbXBsZS4NCg0KSG93IG9mdGVuIGRvZXMgdGhpcyBz aXR1YXRpb24gYXJpc2UgaW4gcHJhY3Rpc2U/IFRoZSBvZGRzIG9mIHJlY2VpdmluZyBhZGphY2Vu dCBhbGxvY2F0aW9ucyBmcm9tIGRpZmZlcmVudCBzb3VyY2VzIHNlZW1zIGxpa2UgaXQgd291bGQg YmUgZmFpcmx5IGxvdywgaW4gd2hpY2ggY2FzZSB0aGlzIGlzIGEgbm9uLWlzc3VlLg0KDQooUGVy aGFwcyBzb21lYm9keSBrbm93cyBiZXR0ZXIgdGhhbiBtZT8gQ291bGQgYW4gYW5hbHlzaXMgb2Yg cm91dGUgcmVnaXN0cmllcywgZ2xvYmFsIEJHUCB0YWJsZSwgZXRjIHByb3ZpZGUgc29tZSBzdGF0 cz8pDQoNCi1CZW5zb24NCg0KDQotLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0tDQpGcm9tOiBN YXR0IExlcGluc2tpDQpUbzogc2lkckBpZXRmLm9yZw0KQ2M6IHJlc2NlcnRAYXBuaWMubmV0DQpT ZW50OiBKdWwgMzEsIDIwMDcgMTA6NTMNClN1YmplY3Q6IFtTaWRyXSBNdWx0aXBsZSBTaWduYXR1 cmVzIG9uIGEgUk9BDQoNCkF0IHRoZSBTaWRyIG1lZXRpbmcgYXQgSUVURiA2OSwgdGhlIGZvbGxv d2luZyBpc3N1ZSB3YXMgcmFpc2VkIGluIA0KcmVnYXJkcyB0byBtYXRjaGluZyBST0FzIHdpdGgg TkxSSSBpbiBhIEJHUCB1cGRhdGUuDQoNCkNvbnNpZGVyIGFuIElTUCB0aGF0IHJlY2VpdmVzIGFu IGFsbG9jYXRpb24gb2YgYSAvMjAgcHJlZml4IGZyb20gc291cmNlIA0KQSwgYW5kIGFuIGFsbG9j YXRpb24gb2YgYW4gYWRhamVjbnQgLzIwIHByZWZpeCBmcm9tIHNvdXJjZSBCLCBidXQgd2FudHMg DQp0byBpc3N1ZSBhbiBhZHZlcnRpc2VtZW50IGZvciB0aGUgYWdncmVnYXRlIC8xOSBwcmVmaXgu DQoNCk5vdGUgdGhhdCBzaW5jZSB0aGUgYWxsb2NhdGlvbnMgYXJlIHJlY2VpdmVkIGZyb20gZGlm ZmVyZW50IHNvdXJjZXMsIHRoZSANCklTUCB3aWxsIGhhdmUgb25lIGNlcnRpZmljYXRlIGZvciBl YWNoIGFsbG9hdGlvbiBhbmQgdGhlIGNlcnRpZmljYXRlcyANCndpbGwgaGF2ZSBkaWZmZXJlbnQg dmFsaWRhdGlvbiBwYXRocy4gVGhlcmVmb3JlLCB0aGUgSVNQIGNhbm5vdCBjcmVhdGUgYSANCnNp bmdsZSBlbmQtZW50aXR5IGNlcnRpZmljYXRlIHRoZSBlbmNvbXBhc3NlcyB0aGUgZW50aXJlIC8x OSBwcmVmaXggDQooaS5lLiBhbnkgY2VydGlmaWNhdGUgZW5jb21wYXNzaW5nIHRoZSBlbnRpcmUg LzE5IHByZWZpeCB3b3VsZCBmYWlsIA0KdmFsaWRhdGlvbiBhY2NvcmRpbmcgdG8gUkZDIDM3Nzkg cnVsZXMpLiBUaGlzIG1lYW5zIHRoYXQgdW5kZXIgdGhlIA0KY3VycmVudCBvbmUtdG8tb25lIGNv cnJlc3BvbmRlbmNlIGJldHdlZW4gUk9BcyBhbmQgZW5kLWVudGl0eSANCmNlcnRpZmljYXRlcywg dGhlIElTUCB3b3VsZCBoYXZlIHRvIGNyZWF0ZSAyIHNlcGFyYXRlIFJPQXMsIG9uZSBmb3IgZWFj aCANCm9mIHRoZSAvMjAgcHJlZml4ZXMuDQoNClNpbWlsYXJseSwgb25lIGNhbiBpbWFnaW5lIGEg c2NlbmFyaW8gd2hlcmUgYW4gSVNQIHJlY2VpdmVzIGFkamFjZW50IA0KYWxsb2NhdGlvbnMgZnJv bSB0aHJlZSBzb3VyY2VzIGFuZCB3YW50cyB0byBhbm5vdW5jZSBhbiBhZ2dyZWdhdGUgcHJlZml4 IA0KKGUuZy4gdGhlIElTUCByZWNlaXZlcyBhIC8xOSwgYSAvMjAgYW5kIGEgc2Vjb25kIC8yMCBh bmQgd2FudHMgdG8gDQphbm5vdW5jZSBhIC8xOCkuIFRoaXMgd291bGQgY3VycmVudGx5IHJlcXVp cmUgaXNzdWluZyB0aHJlZSBzZXBhcmF0ZSBST0FzLg0KDQpUaHVzLCBpZiB3ZSBjb250aW51ZSB0 byBtYW5kYXRlIGEgb25lLXRvLW9uZSBjb3JyZXNwb25kZW5jZSBiZXR3ZWVuIFJPQXMgDQphbmQg ZW5kLWVudGl0eSBjZXJ0aWZpY2F0ZXMsIHdlIHBsYWNlIHRoZSBidXJkZW4gb24gdGhlIHJlY2lw aWVudCBvZiBhIA0KQkdQIFVwZGF0ZSB0byBkZXRlcm1pbmUgaWYgdGhlcmUgaXMgYW55IGNvbGxl Y3Rpb24gb2YgdmFsaWQgUk9BcyB0aGF0IA0KY291bGQgYmUgYWdncmVnYXRlZCB0byBmb3JtIHRo ZSBOTFJJIGluIHRoZSBVcGRhdGUgbWVzc2FnZS4gVGhhdCBpcywgDQp1cG9uIHJlY2VpdmluZyBh biBhZHZlcnRpc2VtZW50IGZvciBhIC8xOCBwcmVmaXggb3JpZ2luYXRlZCBieSBBUyAxMjMsIA0K b25lIG11c3QgZXhhbXBsZSBhbGwgb2YgdGhlIFJPQXMgY29udGFpbmluZyBBUyAxMjMgYW5kIGRl dGVybWluZSBpZiBhbnkgDQpzdWJzZXQgb2YgdGhlbSBjYW4gYmUgYWdncmVnYXRlZCB0byBmb3Jt IHRoZSAvMTggcHJlZml4IGluIHF1ZXN0aW9uLiBObyANCm9uZSBpbiB0aGUgcm9vbSBhdCB0aGUg U2lkciBtZWV0aW5nIGluZGljYXRlZCB0aGF0IHRoZXkgYmVsaWV2ZWQgdGhpcyANCndhcyBhIGdv b2QgaWRlYS4NCg0KQW4gYWx0ZXJuYXRpdmUgYXBwcm9hY2ggaXMgdG8gYnJlYWsgdGhlIG9uZS10 by1vbmUgY29ycmVzcG9uZGVuY2UgDQpiZXR3ZWVuIFJPQXMgYW5kIGVuZC1lbnRpdHkgY2VydGlm aWNhdGVzIGJ5IGFsbG93aW5nIHR3byBzaWduYXR1cmVzIG9uIGEgDQpzaW5nbGUgUk9BLiBSZXR1 cm5pbmcgdG8gb3VyIG9yaWdpbmFsIGV4YW1wbGUsIHRoZSBJU1Agd291bGQgbm93IGNyZWF0ZSAN CnR3byBlbmQtZW50aXR5IGNlcnRpZmljYXRlcywgb25lIGNvbnRhaW5pbmcgdGhlIC8yMCBwcmVm aXggZnJvbSBzb3VyY2UgQSANCmFuZCB0aGUgb3RoZXIgY29udGFpbmluZyB0aGUgLzIwIHByZWZp eCBmcm9tIHNvdXJjZSBCLiBUaGUgSVNQIHdvdWxkIA0KdGhlbiBpc3N1ZSBhIHNpbmdsZSBST0Eg Zm9yIHRoZSBhZ2dyZWdhdGUgLzE5IHByZWZpeCBhbmQgYXR0YWNoIHR3byANCnNpZ25hdHVyZXMs IG9uZSB0aGF0IGNvdWxkIGJlIHZlcmlmaWVkIHVzaW5nIHRoZSBmaXJzdCBlbmQtZW50aXR5IA0K Y2VydGlmaWNhdGUgYW5kIG9uZSB0aGF0IGNvdWxkIGJlIHZlcmlmaWVkIHVzaW5nIHRoZSBzZWNv bmQgZW5kLWVudGl0eSANCmNlcnRpZmljYXRlLiBTZXZlcmFsIHBlb3BsZSBpbiB0aGUgcm9vbSBh dCB0aGUgU2lkciBtZWV0aW5nIGluZGljYXRlZCANCnRoYXQgdGhleSBiZWxpZXZlZCB0aGlzIHdh cyBhIGdvb2QgaWRlYS4NCg0KVGhlcmVmb3JlLCBJIHdhcyB3b25kZXJpbmcgaWYgdGhlcmUgd2Fz IGNvbnNlbnN1cyB0aGF0IHRoZSBST0EgZm9ybWF0IA0Kc2hvdWxkIGJlIGNoYW5nZWQgdG8gYWxs b3cgbXVsdGlwbGUgc2lnbmF0dXJlcz8gT3IgaWYgdGhlIHdvcmtpbmcgZ3JvdXAgDQpmZWx0IHRo ZXJlIHdhcyBhIGJldHRlciBhcHByb2FjaCBmb3IgbWF0Y2hpbmcgUk9BcyBhZ2FpbnN0IHRoZSBO TFJJIGluIGEgDQpCR1AgVXBkYXRlPw0KDQpJZiB3ZSBhcmUgZ29pbmcgdG8gYWxsb3cgdHdvIHNp Z25hdHVyZXMgb24gYSBST0EsIEknZCBsaWtlIHRvIGJlZ2luIA0KcmV2aXNpbmcgdGhlIFJPQSBm b3JtYXQgZHJhZnQgYXQgc29tZSBwb2ludCBuZXh0IHdlZWsgc28gdGhhdCB3ZSBoYXZlIA0KdGlt ZSB0byBnbyB0aHJvdWdoIHR3byB2ZXJzaW9ucyBvZiB0aGUgUk9BIGRyYWZ0IChpZiBuZWVkZWQp IGJlZm9yZSB0aGUgDQpuZXh0IElFVEYgbWVldGluZy4gVGhlcmVmb3JlLCBpZiB5b3UgZG8gbm90 IGJlbGlldmUgdGhhdCBhbGxvd2luZyANCm11bHRpcGxlIHNpZ25hdHVyZXMgb24gYSBST0EgaXMg YSBnb29kIGFwcHJvYWNoLCBwbGVhc2UgbGV0IG1lIGtub3cgDQpiZWZvcmUgQXVndXN0IDguDQoN ClRoYW5rcywNCi0gTWF0dCBMZXBpbnNraSA6LT4NCg0KDQoNCl9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQpTaWRyIG1haWxpbmcgbGlzdA0KU2lkckBpZXRm Lm9yZw0KaHR0cHM6Ly93d3cxLmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2lkcg0KDQo= ------_=_NextPart_001_01C7D384.8DD8C9AF Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDMuMi8vRU4iPg0KPEhUTUw+ DQo8SEVBRD4NCjxNRVRBIEhUVFAtRVFVSVY9IkNvbnRlbnQtVHlwZSIgQ09OVEVOVD0idGV4dC9o dG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxNRVRBIE5BTUU9IkdlbmVyYXRvciIgQ09OVEVOVD0iTVMg RXhjaGFuZ2UgU2VydmVyIHZlcnNpb24gNi41Ljc2NTEuNTkiPg0KPFRJVExFPlJlOiBbU2lkcl0g TXVsdGlwbGUgU2lnbmF0dXJlcyBvbiBhIFJPQTwvVElUTEU+DQo8L0hFQUQ+DQo8Qk9EWT4NCjwh LS0gQ29udmVydGVkIGZyb20gdGV4dC9wbGFpbiBmb3JtYXQgLS0+DQoNCjxQPjxGT05UIFNJWkU9 Mj5NYXR0LTxCUj4NCjxCUj4NCkxlYXZpbmcgYXNpZGUgdGhlIHF1ZXN0aW9uIG9mIG11bHRpcGxl IHNpZ25hdHVyZXMsIEknbSBkb3VidGZ1bCBvZiB5b3VyIGV4YW1wbGUuPEJSPg0KPEJSPg0KSG93 IG9mdGVuIGRvZXMgdGhpcyBzaXR1YXRpb24gYXJpc2UgaW4gcHJhY3Rpc2U/IFRoZSBvZGRzIG9m IHJlY2VpdmluZyBhZGphY2VudCBhbGxvY2F0aW9ucyBmcm9tIGRpZmZlcmVudCBzb3VyY2VzIHNl ZW1zIGxpa2UgaXQgd291bGQgYmUgZmFpcmx5IGxvdywgaW4gd2hpY2ggY2FzZSB0aGlzIGlzIGEg bm9uLWlzc3VlLjxCUj4NCjxCUj4NCihQZXJoYXBzIHNvbWVib2R5IGtub3dzIGJldHRlciB0aGFu IG1lPyBDb3VsZCBhbiBhbmFseXNpcyBvZiByb3V0ZSByZWdpc3RyaWVzLCBnbG9iYWwgQkdQIHRh YmxlLCBldGMgcHJvdmlkZSBzb21lIHN0YXRzPyk8QlI+DQo8QlI+DQotQmVuc29uPEJSPg0KPEJS Pg0KPEJSPg0KLS0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tLTxCUj4NCkZyb206IE1hdHQgTGVw aW5za2k8QlI+DQpUbzogc2lkckBpZXRmLm9yZzxCUj4NCkNjOiByZXNjZXJ0QGFwbmljLm5ldDxC Uj4NClNlbnQ6IEp1bCAzMSwgMjAwNyAxMDo1MzxCUj4NClN1YmplY3Q6IFtTaWRyXSBNdWx0aXBs ZSBTaWduYXR1cmVzIG9uIGEgUk9BPEJSPg0KPEJSPg0KQXQgdGhlIFNpZHIgbWVldGluZyBhdCBJ RVRGIDY5LCB0aGUgZm9sbG93aW5nIGlzc3VlIHdhcyByYWlzZWQgaW48QlI+DQpyZWdhcmRzIHRv IG1hdGNoaW5nIFJPQXMgd2l0aCBOTFJJIGluIGEgQkdQIHVwZGF0ZS48QlI+DQo8QlI+DQpDb25z aWRlciBhbiBJU1AgdGhhdCByZWNlaXZlcyBhbiBhbGxvY2F0aW9uIG9mIGEgLzIwIHByZWZpeCBm cm9tIHNvdXJjZTxCUj4NCkEsIGFuZCBhbiBhbGxvY2F0aW9uIG9mIGFuIGFkYWplY250IC8yMCBw cmVmaXggZnJvbSBzb3VyY2UgQiwgYnV0IHdhbnRzPEJSPg0KdG8gaXNzdWUgYW4gYWR2ZXJ0aXNl bWVudCBmb3IgdGhlIGFnZ3JlZ2F0ZSAvMTkgcHJlZml4LjxCUj4NCjxCUj4NCk5vdGUgdGhhdCBz aW5jZSB0aGUgYWxsb2NhdGlvbnMgYXJlIHJlY2VpdmVkIGZyb20gZGlmZmVyZW50IHNvdXJjZXMs IHRoZTxCUj4NCklTUCB3aWxsIGhhdmUgb25lIGNlcnRpZmljYXRlIGZvciBlYWNoIGFsbG9hdGlv biBhbmQgdGhlIGNlcnRpZmljYXRlczxCUj4NCndpbGwgaGF2ZSBkaWZmZXJlbnQgdmFsaWRhdGlv biBwYXRocy4gVGhlcmVmb3JlLCB0aGUgSVNQIGNhbm5vdCBjcmVhdGUgYTxCUj4NCnNpbmdsZSBl bmQtZW50aXR5IGNlcnRpZmljYXRlIHRoZSBlbmNvbXBhc3NlcyB0aGUgZW50aXJlIC8xOSBwcmVm aXg8QlI+DQooaS5lLiBhbnkgY2VydGlmaWNhdGUgZW5jb21wYXNzaW5nIHRoZSBlbnRpcmUgLzE5 IHByZWZpeCB3b3VsZCBmYWlsPEJSPg0KdmFsaWRhdGlvbiBhY2NvcmRpbmcgdG8gUkZDIDM3Nzkg cnVsZXMpLiBUaGlzIG1lYW5zIHRoYXQgdW5kZXIgdGhlPEJSPg0KY3VycmVudCBvbmUtdG8tb25l IGNvcnJlc3BvbmRlbmNlIGJldHdlZW4gUk9BcyBhbmQgZW5kLWVudGl0eTxCUj4NCmNlcnRpZmlj YXRlcywgdGhlIElTUCB3b3VsZCBoYXZlIHRvIGNyZWF0ZSAyIHNlcGFyYXRlIFJPQXMsIG9uZSBm b3IgZWFjaDxCUj4NCm9mIHRoZSAvMjAgcHJlZml4ZXMuPEJSPg0KPEJSPg0KU2ltaWxhcmx5LCBv bmUgY2FuIGltYWdpbmUgYSBzY2VuYXJpbyB3aGVyZSBhbiBJU1AgcmVjZWl2ZXMgYWRqYWNlbnQ8 QlI+DQphbGxvY2F0aW9ucyBmcm9tIHRocmVlIHNvdXJjZXMgYW5kIHdhbnRzIHRvIGFubm91bmNl IGFuIGFnZ3JlZ2F0ZSBwcmVmaXg8QlI+DQooZS5nLiB0aGUgSVNQIHJlY2VpdmVzIGEgLzE5LCBh IC8yMCBhbmQgYSBzZWNvbmQgLzIwIGFuZCB3YW50cyB0bzxCUj4NCmFubm91bmNlIGEgLzE4KS4g VGhpcyB3b3VsZCBjdXJyZW50bHkgcmVxdWlyZSBpc3N1aW5nIHRocmVlIHNlcGFyYXRlIFJPQXMu PEJSPg0KPEJSPg0KVGh1cywgaWYgd2UgY29udGludWUgdG8gbWFuZGF0ZSBhIG9uZS10by1vbmUg Y29ycmVzcG9uZGVuY2UgYmV0d2VlbiBST0FzPEJSPg0KYW5kIGVuZC1lbnRpdHkgY2VydGlmaWNh dGVzLCB3ZSBwbGFjZSB0aGUgYnVyZGVuIG9uIHRoZSByZWNpcGllbnQgb2YgYTxCUj4NCkJHUCBV cGRhdGUgdG8gZGV0ZXJtaW5lIGlmIHRoZXJlIGlzIGFueSBjb2xsZWN0aW9uIG9mIHZhbGlkIFJP QXMgdGhhdDxCUj4NCmNvdWxkIGJlIGFnZ3JlZ2F0ZWQgdG8gZm9ybSB0aGUgTkxSSSBpbiB0aGUg VXBkYXRlIG1lc3NhZ2UuIFRoYXQgaXMsPEJSPg0KdXBvbiByZWNlaXZpbmcgYW4gYWR2ZXJ0aXNl bWVudCBmb3IgYSAvMTggcHJlZml4IG9yaWdpbmF0ZWQgYnkgQVMgMTIzLDxCUj4NCm9uZSBtdXN0 IGV4YW1wbGUgYWxsIG9mIHRoZSBST0FzIGNvbnRhaW5pbmcgQVMgMTIzIGFuZCBkZXRlcm1pbmUg aWYgYW55PEJSPg0Kc3Vic2V0IG9mIHRoZW0gY2FuIGJlIGFnZ3JlZ2F0ZWQgdG8gZm9ybSB0aGUg LzE4IHByZWZpeCBpbiBxdWVzdGlvbi4gTm88QlI+DQpvbmUgaW4gdGhlIHJvb20gYXQgdGhlIFNp ZHIgbWVldGluZyBpbmRpY2F0ZWQgdGhhdCB0aGV5IGJlbGlldmVkIHRoaXM8QlI+DQp3YXMgYSBn b29kIGlkZWEuPEJSPg0KPEJSPg0KQW4gYWx0ZXJuYXRpdmUgYXBwcm9hY2ggaXMgdG8gYnJlYWsg dGhlIG9uZS10by1vbmUgY29ycmVzcG9uZGVuY2U8QlI+DQpiZXR3ZWVuIFJPQXMgYW5kIGVuZC1l bnRpdHkgY2VydGlmaWNhdGVzIGJ5IGFsbG93aW5nIHR3byBzaWduYXR1cmVzIG9uIGE8QlI+DQpz aW5nbGUgUk9BLiBSZXR1cm5pbmcgdG8gb3VyIG9yaWdpbmFsIGV4YW1wbGUsIHRoZSBJU1Agd291 bGQgbm93IGNyZWF0ZTxCUj4NCnR3byBlbmQtZW50aXR5IGNlcnRpZmljYXRlcywgb25lIGNvbnRh aW5pbmcgdGhlIC8yMCBwcmVmaXggZnJvbSBzb3VyY2UgQTxCUj4NCmFuZCB0aGUgb3RoZXIgY29u dGFpbmluZyB0aGUgLzIwIHByZWZpeCBmcm9tIHNvdXJjZSBCLiBUaGUgSVNQIHdvdWxkPEJSPg0K dGhlbiBpc3N1ZSBhIHNpbmdsZSBST0EgZm9yIHRoZSBhZ2dyZWdhdGUgLzE5IHByZWZpeCBhbmQg YXR0YWNoIHR3bzxCUj4NCnNpZ25hdHVyZXMsIG9uZSB0aGF0IGNvdWxkIGJlIHZlcmlmaWVkIHVz aW5nIHRoZSBmaXJzdCBlbmQtZW50aXR5PEJSPg0KY2VydGlmaWNhdGUgYW5kIG9uZSB0aGF0IGNv dWxkIGJlIHZlcmlmaWVkIHVzaW5nIHRoZSBzZWNvbmQgZW5kLWVudGl0eTxCUj4NCmNlcnRpZmlj YXRlLiBTZXZlcmFsIHBlb3BsZSBpbiB0aGUgcm9vbSBhdCB0aGUgU2lkciBtZWV0aW5nIGluZGlj YXRlZDxCUj4NCnRoYXQgdGhleSBiZWxpZXZlZCB0aGlzIHdhcyBhIGdvb2QgaWRlYS48QlI+DQo8 QlI+DQpUaGVyZWZvcmUsIEkgd2FzIHdvbmRlcmluZyBpZiB0aGVyZSB3YXMgY29uc2Vuc3VzIHRo YXQgdGhlIFJPQSBmb3JtYXQ8QlI+DQpzaG91bGQgYmUgY2hhbmdlZCB0byBhbGxvdyBtdWx0aXBs ZSBzaWduYXR1cmVzPyBPciBpZiB0aGUgd29ya2luZyBncm91cDxCUj4NCmZlbHQgdGhlcmUgd2Fz IGEgYmV0dGVyIGFwcHJvYWNoIGZvciBtYXRjaGluZyBST0FzIGFnYWluc3QgdGhlIE5MUkkgaW4g YTxCUj4NCkJHUCBVcGRhdGU/PEJSPg0KPEJSPg0KSWYgd2UgYXJlIGdvaW5nIHRvIGFsbG93IHR3 byBzaWduYXR1cmVzIG9uIGEgUk9BLCBJJ2QgbGlrZSB0byBiZWdpbjxCUj4NCnJldmlzaW5nIHRo ZSBST0EgZm9ybWF0IGRyYWZ0IGF0IHNvbWUgcG9pbnQgbmV4dCB3ZWVrIHNvIHRoYXQgd2UgaGF2 ZTxCUj4NCnRpbWUgdG8gZ28gdGhyb3VnaCB0d28gdmVyc2lvbnMgb2YgdGhlIFJPQSBkcmFmdCAo aWYgbmVlZGVkKSBiZWZvcmUgdGhlPEJSPg0KbmV4dCBJRVRGIG1lZXRpbmcuIFRoZXJlZm9yZSwg aWYgeW91IGRvIG5vdCBiZWxpZXZlIHRoYXQgYWxsb3dpbmc8QlI+DQptdWx0aXBsZSBzaWduYXR1 cmVzIG9uIGEgUk9BIGlzIGEgZ29vZCBhcHByb2FjaCwgcGxlYXNlIGxldCBtZSBrbm93PEJSPg0K YmVmb3JlIEF1Z3VzdCA4LjxCUj4NCjxCUj4NClRoYW5rcyw8QlI+DQotIE1hdHQgTGVwaW5za2kg Oi0mZ3Q7PEJSPg0KPEJSPg0KPEJSPg0KPEJSPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX188QlI+DQpTaWRyIG1haWxpbmcgbGlzdDxCUj4NClNpZHJAaWV0 Zi5vcmc8QlI+DQo8QSBIUkVGPSJodHRwczovL3d3dzEuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9zaWRyIj5odHRwczovL3d3dzEuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zaWRyPC9BPjxC Uj4NCjxCUj4NCjwvRk9OVD4NCjwvUD4NCg0KPC9CT0RZPg0KPC9IVE1MPg== ------_=_NextPart_001_01C7D384.8DD8C9AF-- --===============1556763915== 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://www1.ietf.org/mailman/listinfo/sidr --===============1556763915==-- From sidr-bounces@ietf.org Tue Jul 31 11:59:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFu8P-00066B-Gc; Tue, 31 Jul 2007 11:59:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFu8O-000661-LT for sidr@ietf.org; Tue, 31 Jul 2007 11:59:44 -0400 Received: from mx11.bbn.com ([128.33.0.80]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IFu8N-0005Bn-H3 for sidr@ietf.org; Tue, 31 Jul 2007 11:59:44 -0400 Received: from dhcp89-089-071.bbn.com ([128.89.89.71]) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1IFu8M-0006gf-5c; Tue, 31 Jul 2007 11:59:42 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <46AF4CF8.5080100@bbn.com> References: <46AF4CF8.5080100@bbn.com> Date: Tue, 31 Jul 2007 12:00:13 -0400 To: Matt Lepinski From: Stephen Kent Subject: Re: [Sidr] Multiple Signatures on a ROA Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: rescert@apnic.net, sidr@ietf.org X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: sidr-bounces@ietf.org Matt, The discussion in SIDR addressed a different, more limited problem. The question was what if an ISP receives two, adjacent allocations from the SAME source at different times, and the source refuses to issue one cert for both allocations, because they have different validity periods. That was the motivation cited by Geoff Houston in the meeting. The possibility of two adjacent allocations coming from different sources is much, much smaller, but it would be covered by the same mechanism, i.e., one that allows multiple signatures on a ROA, each linked to a different EE cert. Steve _______________________________________________ Sidr mailing list Sidr@ietf.org https://www1.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Tue Jul 31 12:27:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFuZY-0005Jp-Pi; Tue, 31 Jul 2007 12:27:48 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFuZX-0005IB-Fr for sidr@ietf.org; Tue, 31 Jul 2007 12:27:47 -0400 Received: from mx12.bbn.com ([128.33.0.81]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IFuZX-0008KA-6w for sidr@ietf.org; Tue, 31 Jul 2007 12:27:47 -0400 Received: from dhcp89-089-119.bbn.com ([128.89.89.119] helo=[127.0.0.1]) by mx12.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1IFuZW-0000jO-5p; Tue, 31 Jul 2007 12:27:46 -0400 Message-ID: <46AF6302.5050005@bbn.com> Date: Tue, 31 Jul 2007 12:27:46 -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: Stephen Kent Subject: Re: [Sidr] Multiple Signatures on a ROA References: <46AF4CF8.5080100@bbn.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: rescert@apnic.net, sidr@ietf.org X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: sidr-bounces@ietf.org Steve, Thanks, I did indeed have the wrong example from the Sidr meeting. - Matt L. :-> Stephen Kent wrote: > Matt, > > The discussion in SIDR addressed a different, more limited problem. > The question was what if an ISP receives two, adjacent allocations > from the SAME source at different times, and the source refuses to > issue one cert for both allocations, because they have different > validity periods. That was the motivation cited by Geoff Houston in > the meeting. > > The possibility of two adjacent allocations coming from different > sources is much, much smaller, but it would be covered by the same > mechanism, i.e., one that allows multiple signatures on a ROA, each > linked to a different EE cert. > > Steve > _______________________________________________ Sidr mailing list Sidr@ietf.org https://www1.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Tue Jul 31 14:19:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFwK5-0003om-U6; Tue, 31 Jul 2007 14:19:57 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFwK4-0003oe-8M for sidr@ietf.org; Tue, 31 Jul 2007 14:19:56 -0400 Received: from ns1.tislabs.com ([192.94.214.100] helo=nutshell.tislabs.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IFwK3-0002yu-Rp for sidr@ietf.org; Tue, 31 Jul 2007 14:19:56 -0400 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id l6VIG2eq019231; Tue, 31 Jul 2007 14:16:02 -0400 (EDT) Received: from pecan.tislabs.com(10.66.1.30) by nutshell.tislabs.com via csmap (V6.0) id srcAAAJBayGL; Tue, 31 Jul 07 14:15:36 -0400 Received: by pecan.tislabs.com (Postfix, from userid 2005) id 60C5E3F478; Tue, 31 Jul 2007 12:12:11 -0400 (EDT) To: mlepinski@bbn.com, sidr@ietf.org Subject: Re: [Sidr] Multiple Signatures on a ROA In-Reply-To: <46AF4CF8.5080100@bbn.com> Message-Id: <20070731161211.60C5E3F478@pecan.tislabs.com> Date: Tue, 31 Jul 2007 12:12:11 -0400 (EDT) From: sandy@tislabs.com (Sandy Murphy) X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: rescert@apnic.net X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: sidr-bounces@ietf.org >At the Sidr meeting at IETF 69, the following issue was raised in >regards to matching ROAs with NLRI in a BGP update. > >Consider an ISP that receives an allocation of a /20 prefix from source >A, and an allocation of an adajecnt /20 prefix from source B, but wants >to issue an advertisement for the aggregate /19 prefix. I believe that there was another wrinkle to the issue. (Since I was the one who raised it, I know what I *meant*, although others might have heard differently.) The issue is that some RIRs, when allocating a prefix, will reserve a matching adjacent prefix for future requests, so that the two allocations are aggregatable. This helps limit routing table bloat. Note the difference: this is a *single* source allocating multiple aggregatable allocations. And I believe that it happens frequently, by deliberate process. (Actually, I'm having trouble visualizing allocations from *multiple* sources that are aggregatable - perhaps this only happens when ranges rather than prefixes are involved? I'm lazy and I don't want to do the math - if you have an example of *prefixes* allocated from multiple sources that were aggregatable, could you describe it?) An aggregated cert from a single source does not run afoul of the encompassing rules of 3779 and the res-certs draft, since it is from a single source. But the architecture notes that an RIR (or a source further down the allocation chain) might not always want to create a cert for the aggregate, as the validity times of the two longer prefix allocations might be different. Hence the need for multiple certs, and the choice between either interpreting the validity of a BGP UPDATE based on multiple (singly signed) ROAs or multiply signed ROAs. I believe that multiply signed ROAs are a direct indication of the intent of the prefix holder, while interpreting UPDATEs based on multiple singly signed ROAs is trying to derive the intent of the prefix holder. I am in favor of multiple signatures on the ROAs. --Sandy _______________________________________________ Sidr mailing list Sidr@ietf.org https://www1.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Tue Jul 31 16:03:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFxwc-0004UN-7b; Tue, 31 Jul 2007 16:03:50 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFxwb-0004SI-3m for sidr@ietf.org; Tue, 31 Jul 2007 16:03:49 -0400 Received: from mx11.bbn.com ([128.33.0.80]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IFxwa-0005jh-QP for sidr@ietf.org; Tue, 31 Jul 2007 16:03:49 -0400 Received: from dhcp89-089-071.bbn.com ([128.89.89.71]) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1IFxwa-0003Zf-3z; Tue, 31 Jul 2007 16:03:48 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <46AF8945.2060303@psg.com> References: <46AF4CF8.5080100@bbn.com> <46AF8945.2060303@psg.com> Date: Tue, 31 Jul 2007 16:04:10 -0400 To: Randy Bush From: Stephen Kent Subject: Re: [Rescert] [Sidr] Multiple Signatures on a ROA Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: rescert@apnic.net, sidr@ietf.org X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: sidr-bounces@ietf.org At 9:11 AM -1000 7/31/07, Randy Bush wrote: > > The question was what if an ISP receives two, adjacent allocations >> from the SAME source at different times, and the source refuses to >> issue one cert for both allocations, because they have different >> validity periods. > >and we agreed many moons ago that the issuer would not play silly games >with validity periods. > >for once, can we see if we can do the simple thing and not look for how >complex we can make it by pushing functionally useless corner cases? > >randy Randy, I'd rather have just one signature on a ROA, to make life as simple as possible. But, I also was "sensitized" to the notion of not imposing undue restrictions on how a registry operates. So, if a registry drives cert issuance based on its allocation database, and if that database treats two allocations as having different lifetimes, based on when they were made, when fees are assessed, etc., I don't know how to reconcile both sets of goals. Steve _______________________________________________ Sidr mailing list Sidr@ietf.org https://www1.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Tue Jul 31 16:09:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFy1p-0007hY-8l; Tue, 31 Jul 2007 16:09:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFy1o-0007hS-6d for sidr@ietf.org; Tue, 31 Jul 2007 16:09:12 -0400 Received: from mint.apnic.net ([202.12.29.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IFy1m-0004EN-R3 for sidr@ietf.org; Tue, 31 Jul 2007 16:09:12 -0400 Received: from [203.10.60.15] (dhcp15.potaroo.net [203.10.60.15]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mint.apnic.net (Postfix) with ESMTP id 65241D5F31; Wed, 1 Aug 2007 06:09:09 +1000 (EST) Message-ID: <46AF9763.2080606@apnic.net> Date: Wed, 01 Aug 2007 06:11:15 +1000 From: Geoff Huston User-Agent: Thunderbird 2.0.0.5 (Windows/20070716) MIME-Version: 1.0 To: Matt Lepinski Subject: Re: [Sidr] Multiple Signatures on a ROA References: <46AF4CF8.5080100@bbn.com> In-Reply-To: <46AF4CF8.5080100@bbn.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: rescert@apnic.net, sidr@ietf.org X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: sidr-bounces@ietf.org Matt Lepinski wrote: > > Therefore, I was wondering if there was consensus that the ROA format > should be changed to allow multiple signatures? Like Sandy, I support this change to the ROA format. I can envisage situations where a holder's address space is certified in a number of certificates, yet the join of this address space describes a single advertised prefix. In this case there is no way in the currently described ROA format that the ROA can be formed. Geoff _______________________________________________ Sidr mailing list Sidr@ietf.org https://www1.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Tue Jul 31 17:06:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFyv0-0002s6-D9; Tue, 31 Jul 2007 17:06:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFyuz-0002s0-Jy for sidr@ietf.org; Tue, 31 Jul 2007 17:06:13 -0400 Received: from ns1.tislabs.com ([192.94.214.100] helo=nutshell.tislabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IFyux-0005gb-Q1 for sidr@ietf.org; Tue, 31 Jul 2007 17:06:13 -0400 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id l6VL1oIm002610; Tue, 31 Jul 2007 17:01:51 -0400 (EDT) Received: from pecan.tislabs.com(10.66.1.30) by nutshell.tislabs.com via csmap (V6.0) id srcAAA2zai_e; Tue, 31 Jul 07 17:00:45 -0400 Received: by pecan.tislabs.com (Postfix, from userid 2005) id A5BEA3F44B; Tue, 31 Jul 2007 16:58:38 -0400 (EDT) To: mlepinski@bbn.com, sandy@tislabs.com, sidr@ietf.org Subject: Re: [Sidr] Multiple Signatures on a ROA In-Reply-To: <20070731161211.60C5E3F478@pecan.tislabs.com> Message-Id: <20070731205838.A5BEA3F44B@pecan.tislabs.com> Date: Tue, 31 Jul 2007 16:58:38 -0400 (EDT) From: sandy@tislabs.com (Sandy Murphy) X-Spam-Score: -0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Cc: rescert@apnic.net X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: sidr-bounces@ietf.org >I believe that there was another wrinkle to the issue. >... >I am in favor of multiple signatures on the ROAs. I did not put in here the obligatory message that these statements were made strictly as a member of the wg, not as a wg chair pronouncement. My opinion on this matter should matter no more or less than any other wg member. --Sandy _______________________________________________ Sidr mailing list Sidr@ietf.org https://www1.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Tue Jul 31 17:28:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFzG8-0007yI-3R; Tue, 31 Jul 2007 17:28:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFzG7-0007yC-IY for sidr@ietf.org; Tue, 31 Jul 2007 17:28:03 -0400 Received: from mint.apnic.net ([202.12.29.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IFzG6-00063B-6b for sidr@ietf.org; Tue, 31 Jul 2007 17:28:03 -0400 Received: from [203.10.60.15] (dhcp15.potaroo.net [203.10.60.15]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mint.apnic.net (Postfix) with ESMTP id DAB8AD5F31; Wed, 1 Aug 2007 07:28:00 +1000 (EST) Message-ID: <46AFA9DF.3040706@apnic.net> Date: Wed, 01 Aug 2007 07:30:07 +1000 From: Geoff Huston User-Agent: Thunderbird 2.0.0.5 (Windows/20070716) MIME-Version: 1.0 To: Sandy Murphy , sidr@ietf.org Subject: Re: [Sidr] Multiple Signatures on a ROA References: <20070731205838.A5BEA3F44B@pecan.tislabs.com> In-Reply-To: <20070731205838.A5BEA3F44B@pecan.tislabs.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: rescert@apnic.net X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: sidr-bounces@ietf.org Sandy Murphy wrote: >> I believe that there was another wrinkle to the issue. >> ... >> I am in favor of multiple signatures on the ROAs. > > I did not put in here the obligatory message that these statements > were made strictly as a member of the wg, not as a wg chair pronouncement. > My opinion on this matter should matter no more or less than any > other wg member. ditto for my comment as well! Geoff _______________________________________________ Sidr mailing list Sidr@ietf.org https://www1.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Tue Jul 31 17:41:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFzSi-0007SX-Ma; Tue, 31 Jul 2007 17:41:04 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IFzSh-0007SS-Sc for sidr@ietf.org; Tue, 31 Jul 2007 17:41:03 -0400 Received: from ns1.tislabs.com ([192.94.214.100] helo=nutshell.tislabs.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IFzSh-0007yS-CC for sidr@ietf.org; Tue, 31 Jul 2007 17:41:03 -0400 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id l6VLbV6d006045; Tue, 31 Jul 2007 17:37:31 -0400 (EDT) Received: from pecan.tislabs.com(10.66.1.30) by nutshell.tislabs.com via csmap (V6.0) id srcAAA0jaGIl; Tue, 31 Jul 07 17:36:18 -0400 Received: by pecan.tislabs.com (Postfix, from userid 2005) id 750043F47F; Tue, 31 Jul 2007 17:34:06 -0400 (EDT) To: rescert@apnic.net, sidr@ietf.org Subject: Re: [Rescert] [Sidr] Multiple Signatures on a ROA In-Reply-To: Message-Id: <20070731213406.750043F47F@pecan.tislabs.com> Date: Tue, 31 Jul 2007 17:34:06 -0400 (EDT) From: sandy@tislabs.com (Sandy Murphy) X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: sandy@tislabs.com X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: sidr-bounces@ietf.org Obligatory statement: The following opinions are stated strictly as a member of the wg, not as a wg chair pronouncement. My opinion on this matter should matter no more or less than that of any other wg member. Right now, prefix holders who have been allocated multiple aggregatable prefixes can originate an advertisement for the aggregate. I imagine that we (sidr) would want the architecture to premit the authorization of such an aggregate advertisement - no one wants to give up current features. The choices seem to be: (1) create multiple singly signed ROAs, say for two /20's, and let the recipient interpret whether you meant to authorize the origination of the /19 as well. (IMHO, I don't care for the recipient reading the mind of the prefix holder - the wg must choose a common interpretation to make this work, and if the common choice is wrong for some prefix holder, there's no way for that prefix holder to recover.) (2) mandate that all sources (all CAs) MUST produce an aggregate cert when there are aggregatable certs. (IMHO, mandating a CA activity like this is out of character for PKIs, but there's always a first time...) (3) tell prefix holders whose source is not willing to sign an aggregate cert that they are just out of luck in originating the aggregate, maybe just until the next prefix renewal period, maybe forever. (IMHO, this would not be a popular option.) (4) allow a prefix holder whose source is not willing to sign an aggregate to sign an aggregate ROA with multiple signatures. (IMHO, this does add a bit of complication to the ROA validation algorithm, but for the computers not the humans - and that's what computers are good for.) It could be that the chosen interpretation in (1) is so very seldom wrong, that we can decide that this is a good engineering choice and go with that. But I dislike the idea of going to some large effort to strongly assert an authorization that won't be exactly followed by the recipients. --Sandy _______________________________________________ Sidr mailing list Sidr@ietf.org https://www1.ietf.org/mailman/listinfo/sidr