From sidr-bounces@ietf.org Wed Aug 01 14:44:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGJB2-0005sn-ME; Wed, 01 Aug 2007 14:44:08 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGJB1-0005dX-Mz for sidr@ietf.org; Wed, 01 Aug 2007 14:44:07 -0400 Received: from relay.cooperix.net ([192.139.46.41] helo=cod.sandelman.ca) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IGJAw-0007gj-AL for sidr@ietf.org; Wed, 01 Aug 2007 14:44:02 -0400 Received: from sandelman.ottawa.on.ca (76-10-144-4.dsl.teksavvy.com [76.10.144.4]) by cod.sandelman.ca (Postfix) with ESMTP id 5349018437 for ; Wed, 1 Aug 2007 18:21:35 +0000 (UTC) Received: from marajade.sandelman.ca (unknown [127.0.0.1]) by sandelman.ottawa.on.ca (Postfix) with ESMTP id 34D994E7AC for ; Wed, 1 Aug 2007 05:59:54 -0400 (EDT) From: Michael Richardson To: sidr@ietf.org Subject: Re: [Sidr] Multiple Signatures on a ROA In-Reply-To: Message from sandy@tislabs.com (Sandy Murphy) of "Tue, 31 Jul 2007 12:12:11 EDT." <20070731161211.60C5E3F478@pecan.tislabs.com> References: <20070731161211.60C5E3F478@pecan.tislabs.com> X-Mailer: MH-E 7.82; nmh 1.1; XEmacs 21.4 (patch 19) Date: Wed, 01 Aug 2007 05:59:54 -0400 Message-ID: <22426.1185962394@marajade.sandelman.ca> X-Spam-Score: 1.9 (+) X-Scan-Signature: 25620135586de10c627e3628c432b04a 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 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >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. >>>>> "Sandy" == Sandy Murphy writes: Sandy> I believe that there was another wrinkle to the issue. Sandy> (Since I was the one who raised it, I know what I *meant*, Sandy> although others might have heard differently.) Sandy> The issue is that some RIRs, when allocating a prefix, will Sandy> reserve a matching adjacent prefix for future requests, so Sandy> that the two allocations are aggregatable. This helps limit Sandy> routing table bloat. Note the difference: this is a *single* Sandy> source allocating multiple aggregatable allocations. And I Sandy> believe that it happens frequently, by deliberate process. Sandy> (Actually, I'm having trouble visualizing allocations from Sandy> *multiple* sources that are aggregatable - perhaps this only Sandy> happens when ranges rather than prefixes are involved? I'm Sandy> lazy and I don't want to do the math - if you have an example Sandy> of *prefixes* allocated from multiple sources that were Sandy> aggregatable, could you describe it?) I think that it would be exceedingly rare. For it to occur, the two sources would have to have received allocations from a parent RIR that were not powers of two. Even if source A had been allocated: A: 10.10/16 and had delegated 10.10.240.0/20 B: 10.11/16 and had delegated 10.11.0.0/20 no aggregatable /19 would be posssible. yes, a range from 10.10.240.0 to 10.11.15.255 exists, but it wouldn't aggregate. The case where additional address space is allocated (as Sandy mentions, from the same RIR) seems simpler to me. You give a reason why the RIR couldn't just issue the /19 certificate at that point: Sandy> it is from a single source. But the architecture notes that Sandy> an RIR (or a source further down the allocation chain) might Sandy> not always want to create a cert for the aggregate, as the Sandy> validity times of the two longer prefix allocations might be Sandy> different. Hence the need for multiple certs, and the choice Sandy> between either interpreting the validity of a BGP UPDATE Sandy> based on multiple (singly signed) ROAs or multiply signed Sandy> ROAs. But, if the validity times are significantly different such that one prefix is going to change prior to the certificates expiring, should the ISP really even be advertising the aggregate? - -- ] Bear: "Me, I'm just the shape of a bear." | firewalls [ ] Michael Richardson, Xelerance Corporation, Ottawa, ON |net architect[ ] mcr@xelerance.com http://www.sandelman.ottawa.on.ca/mcr/ |device driver[ ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Finger me for keys iQEVAwUBRrBZmYCLcPvd0N1lAQKevAf8C9/iJcrBU40yRxLjUD+i2yjmYpmVHETH gk0zkoAy9M+9rR13MZfKeEI49h+MuV9/ylxz0zskZF59VfV0GHwITHk0e1sLne5V /7gt0c7O4dg0Av9JAWyfMblX821GsqKadZeVtGiSW5VpoQIcAwxKaVBk7rOeSDgE VHMKjo59IvDCdD1/PJota21fEWbR8uJO0uaLgYIdtn5nRnNQFjSkug400NsaIG99 ZdMIUBVmMa/f/rv/eKyh08Xovvg2km70eIWU22eDjZvYpuZHpCMrKZiT0R1KAPzG 9WmaLXTsOepCQnOkKJ3t3xCjmkKsW2KMuvUdeq0Fz+jew8xxF1873Q== =0z2q -----END PGP SIGNATURE----- _______________________________________________ Sidr mailing list Sidr@ietf.org https://www1.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Wed Aug 01 17:27:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGLir-0007qU-EE; Wed, 01 Aug 2007 17:27:13 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGLip-0007qN-Uf for sidr@ietf.org; Wed, 01 Aug 2007 17:27:11 -0400 Received: from mx11.bbn.com ([128.33.0.80]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IGLip-0003lz-IU for sidr@ietf.org; Wed, 01 Aug 2007 17:27:11 -0400 Received: from dhcp89-089-071.bbn.com ([128.89.89.71]) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1IGLio-0003nn-56; Wed, 01 Aug 2007 17:27:10 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <22426.1185962394@marajade.sandelman.ca> References: <20070731161211.60C5E3F478@pecan.tislabs.com> <22426.1185962394@marajade.sandelman.ca> Date: Wed, 1 Aug 2007 17:27:43 -0400 To: Michael Richardson 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: 798b2e660f1819ae38035ac1d8d5e3ab 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 5:59 AM -0400 8/1/07, Michael Richardson wrote: >... > But, if the validity times are significantly different such that one >prefix is going to change prior to the certificates expiring, should the >ISP really even be advertising the aggregate? > The allocation certs may have validity intervals that overlap for a number of months so why not advertise the aggregate for that time interval? The ROA would have to have a validity interval that does not exceed that of the cert(s) used to verify it, but that could still be a usefully long interval. There is no sense that the resource holder will loose the allocation when it expires. Typically the allocation is renewed. However, if the issuer (an RIR, NIR or LIR) wants to keep its life simple and drive cert lifetimes off of its allocation management database, then it may not be willing to issue a single cert covering the two allocations, hence the motivation cited by Geoff and Sandy for this added complexity for ROAs. Steve _______________________________________________ Sidr mailing list Sidr@ietf.org https://www1.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Wed Aug 01 19:29: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 1IGNco-0004bE-8r; Wed, 01 Aug 2007 19:29:06 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGNcm-0004NR-L1 for sidr@ietf.org; Wed, 01 Aug 2007 19:29:04 -0400 Received: from mint.apnic.net ([202.12.29.58]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IGNcm-00064e-0K for sidr@ietf.org; Wed, 01 Aug 2007 19:29:04 -0400 Received: from [192.94.63.110] (dhcp110.yarralumla.aarnet.edu.au [192.94.63.110]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mint.apnic.net (Postfix) with ESMTP id 7C081D5F38; Thu, 2 Aug 2007 09:29:02 +1000 (EST) Message-ID: <46B117BB.4000603@apnic.net> Date: Thu, 02 Aug 2007 09:31:07 +1000 From: Geoff Huston User-Agent: Thunderbird 2.0.0.5 (Windows/20070716) MIME-Version: 1.0 To: Stephen Kent Subject: Re: [Sidr] Multiple Signatures on a ROA References: <20070731161211.60C5E3F478@pecan.tislabs.com> <22426.1185962394@marajade.sandelman.ca> 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: 7baded97d9887f7a0c7e8a33c2e3ea1b 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 *Working group chair hat _off_* Stephen Kent wrote: > At 5:59 AM -0400 8/1/07, Michael Richardson wrote: >> ... >> But, if the validity times are significantly different such that one >> prefix is going to change prior to the certificates expiring, should the >> ISP really even be advertising the aggregate? >> > > The allocation certs may have validity intervals that overlap for a > number of months so why not advertise the aggregate for that time > interval? The ROA would have to have a validity interval that does not > exceed that of the cert(s) used to verify it, but that could still be a > usefully long interval. > > There is no sense that the resource holder will loose the allocation > when it expires. Typically the allocation is renewed. However, if the > issuer (an RIR, NIR or LIR) wants to keep its life simple and drive cert > lifetimes off of its allocation management database, then it may not be > willing to issue a single cert covering the two allocations, hence the > motivation cited by Geoff and Sandy for this added complexity for ROAs. > It is not only validity dates that motivated my comment to support multiple signings of a ROA - if one looked into the old B and C space and follow the various trails of movement of some of these address blocks then there may well be situations where there are adjacent aggregateable prefixes that have different validation paths and hence cannot be aggregated into a single certificate that covers the aggregate prefix. If you want to have a ROA that covers the prefix and does not ential the replying party making guessing games as to intent (ugh!) then having multiple signings over the ROA makes sense to me as a capability in the ROA specification. Geoff _______________________________________________ Sidr mailing list Sidr@ietf.org https://www1.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Thu Aug 02 15:42: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 1IGgZK-0003EM-E3; Thu, 02 Aug 2007 15:42:46 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGgZJ-0003EF-2I for sidr@ietf.org; Thu, 02 Aug 2007 15:42:45 -0400 Received: from postman.ripe.net ([193.0.19.2]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IGgZI-0001RN-CC for sidr@ietf.org; Thu, 02 Aug 2007 15:42:44 -0400 Received: by postman.ripe.net (Postfix, from userid 4008) id 7D67823F73; Thu, 2 Aug 2007 21:42:43 +0200 (CEST) Received: from herring.ripe.net (herring.ripe.net [193.0.1.203]) by postman.ripe.net (Postfix) with ESMTP id 8EB9923FEA; Thu, 2 Aug 2007 21:42:42 +0200 (CEST) Received: from [10.10.10.35] (gw.office.nsrp.ripe.net [193.0.1.126]) by herring.ripe.net (Postfix) with ESMTP id 740192F5CF; Thu, 2 Aug 2007 21:42:42 +0200 (CEST) Message-ID: <46B22457.3060308@ripe.net> Date: Thu, 02 Aug 2007 20:37:11 +0200 From: Henk Uijterwaal User-Agent: Thunderbird 1.5.0.9 (Macintosh/20061207) 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-RIPE-Spam-Level: X-RIPE-Spam-Tests: ALL_TRUSTED,BAYES_00 X-RIPE-Spam-Status: N 0.021707 / -4.4 X-RIPE-Signature: e69cc94fa95e54a26f8afca6738c0c79 X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 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 All, > 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. I'm not sure if this would ever happen in practice. Our current thinking is that certs will be valid for the period for which LIRs have paid their membership dues (plus some grace period after that). So, if two allocations are made on different dates, the end date for the cert will always be the same and there is no reason why one would refuse handing out a cert for the aggregate. Henk -- ------------------------------------------------------------------------------ Henk Uijterwaal Email: henk.uijterwaal(at)ripe.net RIPE Network Coordination Centre http://www.amsterdamned.org/~henk P.O.Box 10096 Singel 258 Phone: +31.20.5354414 1001 EB Amsterdam 1016 AB Amsterdam Fax: +31.20.5354445 The Netherlands The Netherlands Mobile: +31.6.55861746 ------------------------------------------------------------------------------ # Lawyer: "Now sir, I'm sure you are an intelligent and honest man--" # Witness: "Thank you. If I weren't under oath, I'd return the compliment." _______________________________________________ Sidr mailing list Sidr@ietf.org https://www1.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Sat Aug 04 20:40: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 1IHUAS-0006Rl-Ef; Sat, 04 Aug 2007 20:40:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IHUAR-0006Rg-1e for sidr@ietf.org; Sat, 04 Aug 2007 20:40:23 -0400 Received: from [2001:418:1::19] (helo=adrilankha.hactrn.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IHUAQ-0007pO-IK for sidr@ietf.org; Sat, 04 Aug 2007 20:40:23 -0400 Received: from thangorodrim.hactrn.net (c-66-30-17-169.hsd1.ma.comcast.net [66.30.17.169]) (using SSLv3 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "thangorodrim.hactrn.net", Issuer "Grunchweather Associates" (verified OK)) by adrilankha.hactrn.net (Postfix) with ESMTP id B00C3CB60; Sun, 5 Aug 2007 00:40:21 +0000 (UTC) Received: from thangorodrim.hactrn.net (localhost [IPv6:::1]) by thangorodrim.hactrn.net (Postfix) with ESMTP id 3E17311CA5; Sat, 4 Aug 2007 17:40:39 +0000 (UTC) Date: Sat, 04 Aug 2007 13:40:39 -0400 From: Rob Austein To: rescert@apnic.net, sidr@ietf.org Subject: Re: [Sidr] Multiple Signatures on a ROA In-Reply-To: <46AF9763.2080606@apnic.net> References: <46AF4CF8.5080100@bbn.com> <46AF9763.2080606@apnic.net> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20070804174039.3E17311CA5@thangorodrim.hactrn.net> X-Spam-Score: 4.1 (++++) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: 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 Having thought about this a bit, I remain skeptical about the need for or desirability of multiple signatures on ROAs. First, as others have mentioned, this is a relatively low-probability hypothetical case, and if it occurs at all it would be the result of an issuer deliberately chosing to make life complicated for its subjects. This does not strike me as a strong case for complicating the protocol (if anything, it strikes me as the opposite, absent proof that this complexity really is necessary). Second, I don't see why this can't be handled via multiple ROAs instead of multiple signatures on a single ROA. As I understand it, relying parties in this system are going to have to deal with the possibility of multiple ROAs for the same AS number in any case; adding multiple signatures to ROAs will not change that. So I don't see a big gain here, just another code path that will need to be debugged and a more complicated algorithm for deciding whether a ROA is valid (what's a relying party supposed to do if if one signature on a ROA is valid and the other is not? If five are valid and three are not? Is there an upper limit to the number of signatures? At one point does this become a denial of service attack on the relying party? ...). So, since on the one hand this whole mess can be avoided by an issuer who wants to avoid it, and on the other hand there's a perfectly good way to handle it that we're going to have to support anyway, on the gripping hand I do not support the proposed change to allow multiple signatures. _______________________________________________ Sidr mailing list Sidr@ietf.org https://www1.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Sat Aug 04 21:25:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IHUri-00073R-C4; Sat, 04 Aug 2007 21:25:06 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IHUrh-00073M-Vg for sidr@ietf.org; Sat, 04 Aug 2007 21:25:06 -0400 Received: from mint.apnic.net ([202.12.29.58]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IHUrh-00079r-2m for sidr@ietf.org; Sat, 04 Aug 2007 21:25:05 -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 9583ED5F4A; Sun, 5 Aug 2007 11:25:00 +1000 (EST) Message-ID: <46B52765.4020005@apnic.net> Date: Sun, 05 Aug 2007 11:27:01 +1000 From: Geoff Huston User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Rob Austein Subject: Re: [Rescert] [Sidr] Multiple Signatures on a ROA References: <46AF4CF8.5080100@bbn.com> <46AF9763.2080606@apnic.net> <20070804174039.3E17311CA5@thangorodrim.hactrn.net> In-Reply-To: <20070804174039.3E17311CA5@thangorodrim.hactrn.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 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 *wg chair hat off* Rob Austein wrote: > Having thought about this a bit, I remain skeptical about the need for > or desirability of multiple signatures on ROAs. > > First, as others have mentioned, this is a relatively low-probability > hypothetical case, and if it occurs at all it would be the result of > an issuer deliberately chosing to make life complicated for its > subjects. This does not strike me as a strong case for complicating > the protocol (if anything, it strikes me as the opposite, absent proof > that this complexity really is necessary). > > Second, I don't see why this can't be handled via multiple ROAs > instead of multiple signatures on a single ROA. As I understand it, > relying parties in this system are going to have to deal with the > possibility of multiple ROAs for the same AS number in any case; > adding multiple signatures to ROAs will not change that. So if seems to me that you are saying that an advertisement for 192.0.2.0/24 originated from AS65000 could be validated by two ROAs, namely 192.0.2.0/25 authorizing AS65000 and 192.0.2.128/25 authorizing AS65000 To me, this appears to make the relying party's job harder given that the relying party is no longer just looking for either exact match ROAs or covering aggregate ROAs but now also has to search for a collection of more specific ROAs that could be used to construct an aggregate that matches the prefix to be validated. In your model does either of the signing /25 parties need to demonstate knowledge of the other? Do they need to indicate their permission to have the aggregated originated rather than the more specific? How can they demonstrate that they are in effect the same party even though there may be different validation paths for the certs associated with each more prefix? How can a validating party uncover the original intent of the signers in this case? > So, since on the one hand this whole mess can be avoided by an issuer > who wants to avoid it, and on the other hand there's a perfectly good > way to handle it that we're going to have to support anyway, on the > gripping hand I do not support the proposed change to allow multiple > signatures. > I don't agree with this assessment and to me ruling out the ability of multiple signatures on a ROA introduces the potential for undue levels of uncertainty in relying party validation of route objects. For that reason I continue to support the concept of allowing multiple signatures on a ROAs. _______________________________________________ Sidr mailing list Sidr@ietf.org https://www1.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Mon Aug 06 04:12:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IHxha-0007vE-LH; Mon, 06 Aug 2007 04:12:34 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IHxhZ-0007v3-T8 for sidr@ietf.org; Mon, 06 Aug 2007 04:12:33 -0400 Received: from postman.ripe.net ([193.0.19.2]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IHxhZ-0001Bl-9w for sidr@ietf.org; Mon, 06 Aug 2007 04:12:33 -0400 Received: by postman.ripe.net (Postfix, from userid 4008) id 5255A23F77; Mon, 6 Aug 2007 10:12:32 +0200 (CEST) Received: from herring.ripe.net (herring.ripe.net [193.0.1.203]) by postman.ripe.net (Postfix) with ESMTP id 4959123EFD; Mon, 6 Aug 2007 10:12:31 +0200 (CEST) Received: from [10.10.10.35] (gw.office.nsrp.ripe.net [193.0.1.126]) by herring.ripe.net (Postfix) with ESMTP id 424902F583; Mon, 6 Aug 2007 10:12:31 +0200 (CEST) Message-ID: <46B6B3BE.8060405@ripe.net> Date: Mon, 06 Aug 2007 07:38:06 +0200 From: Henk Uijterwaal User-Agent: Thunderbird 1.5.0.9 (Macintosh/20061207) MIME-Version: 1.0 To: Rob Austein Subject: Re: [Sidr] Multiple Signatures on a ROA References: <46AF4CF8.5080100@bbn.com> <46AF9763.2080606@apnic.net> <20070804174039.3E17311CA5@thangorodrim.hactrn.net> In-Reply-To: <20070804174039.3E17311CA5@thangorodrim.hactrn.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-RIPE-Spam-Level: X-RIPE-Spam-Tests: ALL_TRUSTED,BAYES_00 X-RIPE-Spam-Status: U 0.306688 / -4.4 X-RIPE-Signature: 3afa6c027e7a4abcb6abbb02a1b2323f X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 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 All, > Having thought about this a bit, I remain skeptical about the need for > or desirability of multiple signatures on ROAs. > > First, as others have mentioned, this is a relatively low-probability > hypothetical case, and if it occurs at all it would be the result of > an issuer deliberately chosing to make life complicated for its > subjects. This does not strike me as a strong case for complicating > the protocol (if anything, it strikes me as the opposite, absent proof > that this complexity really is necessary). I agree with Rob here. I'd have no problem with extending the protocol if there was a valid case for doing so. However, the two cases that were mentioned on the list so-far, are low probability cases that can be handled by having 2 ROAs. Until somebody comes up with a third case that needs this, let's not make things more complicated than they already are. Henk -- ------------------------------------------------------------------------------ Henk Uijterwaal Email: henk.uijterwaal(at)ripe.net RIPE Network Coordination Centre http://www.amsterdamned.org/~henk P.O.Box 10096 Singel 258 Phone: +31.20.5354414 1001 EB Amsterdam 1016 AB Amsterdam Fax: +31.20.5354445 The Netherlands The Netherlands Mobile: +31.6.55861746 ------------------------------------------------------------------------------ # Lawyer: "Now sir, I'm sure you are an intelligent and honest man--" # Witness: "Thank you. If I weren't under oath, I'd return the compliment." _______________________________________________ Sidr mailing list Sidr@ietf.org https://www1.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Mon Aug 06 10:22:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1II3T0-0007hk-Lf; Mon, 06 Aug 2007 10:21:54 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1II3Sz-0007he-1Q for sidr@ietf.org; Mon, 06 Aug 2007 10:21:53 -0400 Received: from mx12.bbn.com ([128.33.0.81]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1II3Sy-0001Sz-LA for sidr@ietf.org; Mon, 06 Aug 2007 10:21:52 -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 1II3Ss-0007ue-3I; Mon, 06 Aug 2007 10:21:46 -0400 Message-ID: <46B72E79.4020900@bbn.com> Date: Mon, 06 Aug 2007 10:21:45 -0400 From: Matt Lepinski Organization: BBN User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Geoff Huston Subject: Re: [Rescert] [Sidr] Multiple Signatures on a ROA References: <46AF4CF8.5080100@bbn.com> <46AF9763.2080606@apnic.net> <20070804174039.3E17311CA5@thangorodrim.hactrn.net> <46B52765.4020005@apnic.net> In-Reply-To: <46B52765.4020005@apnic.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: Rob Austein , 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 Geoff, Geoff Huston wrote: > So if seems to me that you are saying that an advertisement for > 192.0.2.0/24 originated from AS65000 could be validated by two ROAs, > namely 192.0.2.0/25 authorizing AS65000 and 192.0.2.128/25 authorizing > AS65000 > > To me, this appears to make the relying party's job harder given that > the relying party is no longer just looking for either exact match > ROAs or covering aggregate ROAs but now also has to search for a > collection of more specific ROAs that could be used to construct an > aggregate that matches the prefix to be validated. I completely agree. This option makes life very difficult for a relying party. For instance, an advertisement for 192.0.0.0/18 could be authorized by - A single ROA for 192.0.0.0/18 - A pair of ROAs, one for 192.0.0.0/19 and one for 192.0.32.0/19 - Three ROAs for 192.0.0.0/19, 19.0.32.0/20 and 19.0.48.0/20, respectively - A large number of other possibilities including ROAs for the following set of prefixes: 192.0.0.0/20 192.0.16.0/22 192.0.20.0/22 192.0.24.0/22 192.0.28.0/22 192.0.32.0/21 192.0.40.0/21 192.0.48.0/20 At the very least, if we're going to pursue this option, we need to provide a description of the algorithm that a relying party would use to determine if AS65000 is authorized to advertise the prefix 192.0.0.0/18. (E.g., would the relying party take the collection of all ROAs for AS65000 and then construct all possible aggregates?) - Matt Lepinski :-> _______________________________________________ Sidr mailing list Sidr@ietf.org https://www1.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Mon Aug 06 17:08:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1II9oH-0008FZ-A6; Mon, 06 Aug 2007 17:08:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1II9oF-0008EM-IS for sidr@ietf.org; Mon, 06 Aug 2007 17:08:15 -0400 Received: from [2002:425c:4242:0:210:5aff:fe86:1f54] (helo=cyteen.hactrn.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1II9oE-0002Fu-R0 for sidr@ietf.org; Mon, 06 Aug 2007 17:08:15 -0400 Received: from thrintun.hactrn.net (thrintun.hactrn.net [IPv6:2002:425c:4242:0:219:d1ff:fe12:5d30]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "thrintun.hactrn.net", Issuer "Grunchweather Associates" (verified OK)) by cyteen.hactrn.net (Postfix) with ESMTP id 4551228463 for ; Mon, 6 Aug 2007 21:08:14 +0000 (UTC) Received: from thrintun.hactrn.net (localhost [IPv6:::1]) by thrintun.hactrn.net (Postfix) with ESMTP id 0B6C222828 for ; Mon, 6 Aug 2007 17:08:14 -0400 (EDT) Date: Mon, 06 Aug 2007 17:08:14 -0400 From: Rob Austein To: sidr@ietf.org Subject: Re: [Rescert] [Sidr] Multiple Signatures on a ROA In-Reply-To: <46B52765.4020005@apnic.net> References: <46AF4CF8.5080100@bbn.com> <46AF9763.2080606@apnic.net> <20070804174039.3E17311CA5@thangorodrim.hactrn.net> <46B52765.4020005@apnic.net> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20070806210814.0B6C222828@thrintun.hactrn.net> X-Spam-Score: -0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 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 Sun, 05 Aug 2007 11:27:01 +1000, Geoff Huston wrote: > > Rob Austein wrote: > > Having thought about this a bit, I remain skeptical about the need for > > or desirability of multiple signatures on ROAs. > > > > First, as others have mentioned, this is a relatively low-probability > > hypothetical case, and if it occurs at all it would be the result of > > an issuer deliberately chosing to make life complicated for its > > subjects. This does not strike me as a strong case for complicating > > the protocol (if anything, it strikes me as the opposite, absent proof > > that this complexity really is necessary). I still stand by this part of what I said. > > Second, I don't see why this can't be handled via multiple ROAs > > instead of multiple signatures on a single ROA. As I understand it, > > relying parties in this system are going to have to deal with the > > possibility of multiple ROAs for the same AS number in any case; > > adding multiple signatures to ROAs will not change that. > > So if seems to me that you are saying that an advertisement for > 192.0.2.0/24 originated from AS65000 could be validated by two ROAs, > namely 192.0.2.0/25 authorizing AS65000 and 192.0.2.128/25 authorizing > AS65000 > > To me, this appears to make the relying party's job harder given that > the relying party is no longer just looking for either exact match ROAs > or covering aggregate ROAs but now also has to search for a collection > of more specific ROAs that could be used to construct an aggregate that > matches the prefix to be validated. Upon further consideration and some offline discussion, I agree with you on this point. I was confused about the other cases where I thought one might need to construct an aggregate from multiple ROAs. But this was a side point. That my proposed work-around to a non-problem is itself unworkable does not change the nature of the non-problem. > > So, since on the one hand this whole mess can be avoided by an issuer > > who wants to avoid it, and on the other hand there's a perfectly good > > way to handle it that we're going to have to support anyway, on the > > gripping hand I do not support the proposed change to allow multiple > > signatures. > > > > I don't agree with this assessment and to me ruling out the ability of > multiple signatures on a ROA introduces the potential for undue levels > of uncertainty in relying party validation of route objects. For that > reason I continue to support the concept of allowing multiple signatures > on a ROAs. I don't see how this follows. I still don't believe that there's any real need for multiple signatures, because there's no good reason for the issuer to force this mess upon its subjects. As far as I can tell this is a non-problem to which we do not need a solution. _______________________________________________ Sidr mailing list Sidr@ietf.org https://www1.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Tue Aug 07 01:03:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IIHDh-0007Tl-3G; Tue, 07 Aug 2007 01:03:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IIHDf-0007Tf-Sd for sidr@ietf.org; Tue, 07 Aug 2007 01:02:59 -0400 Received: from mint.apnic.net ([202.12.29.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IIHDf-0003mk-Bf for sidr@ietf.org; Tue, 07 Aug 2007 01:02:59 -0400 Received: from asmtp.apnic.net (garlic.apnic.net [202.12.29.224]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mint.apnic.net (Postfix) with ESMTP id EC675D5F2D; Tue, 7 Aug 2007 15:02:57 +1000 (EST) Date: Tue, 7 Aug 2007 15:02:57 +1000 From: George Michaelson To: Rob Austein Subject: Re: [Rescert] [Sidr] Multiple Signatures on a ROA Message-ID: <20070807150257.77a80243@garlique.algebras.org> In-Reply-To: <20070806210814.0B6C222828@thrintun.hactrn.net> References: <46AF4CF8.5080100@bbn.com> <46AF9763.2080606@apnic.net> <20070804174039.3E17311CA5@thangorodrim.hactrn.net> <46B52765.4020005@apnic.net> <20070806210814.0B6C222828@thrintun.hactrn.net> X-Mailer: Claws Mail 2.10.0 (GTK+ 2.10.14; i386--netbsdelf) X-Fruit-Of-The-Month-Club: persimmon Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f 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 Mon, 06 Aug 2007 17:08:14 -0400 Rob Austein wrote: > At Sun, 05 Aug 2007 11:27:01 +1000, Geoff Huston wrote: > > I don't agree with this assessment and to me ruling out the ability > > of multiple signatures on a ROA introduces the potential for undue > > levels of uncertainty in relying party validation of route objects. > > For that reason I continue to support the concept of allowing > > multiple signatures on a ROAs. > > I don't see how this follows. I still don't believe that there's any > real need for multiple signatures, because there's no good reason for > the issuer to force this mess upon its subjects. As far as I can tell > this is a non-problem to which we do not need a solution. > I can foresee plausible circumstances where even if we didn't want them, purposeful multiple signings could exist. You say above 'the issuer' but we already know that ERX has resulted in thousands of swampy fragments being distributed amongst the RIR, such that there isn't one 'issuer' to sign over any re-combined prefixes in the space. I think that a standard in ROA which didn't admit of multiple signings would be weak. I think we'd be forcing single-sign imperatives on the community before we fully understand what people expect to do in ROA, and in the litany of related signings which will exist under 3779 qualified certificates. I want there to be a good definition of what a multiple sign looks like, and I support the WG defining it. I suspect that it adds a very small amount of ASN1 'overhead' in the simple case of a single-sign, and I don't see why it causes you such a problem as a code developer. -George _______________________________________________ Sidr mailing list Sidr@ietf.org https://www1.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Tue Aug 07 17:57:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IIX3p-0007iW-HS; Tue, 07 Aug 2007 17:57:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IIX3o-0007iR-RH for sidr@ietf.org; Tue, 07 Aug 2007 17:57:52 -0400 Received: from mint.apnic.net ([202.12.29.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IIX3o-0004Ms-9q for sidr@ietf.org; Tue, 07 Aug 2007 17:57:52 -0400 Received: from asmtp.apnic.net (c220-237-86-126.rochd3.qld.optusnet.com.au [220.237.86.126]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mint.apnic.net (Postfix) with ESMTP id A46BFD5F2D; Wed, 8 Aug 2007 07:57:50 +1000 (EST) Date: Wed, 8 Aug 2007 07:57:49 +1000 From: George Michaelson To: Randy Bush Subject: Re: [Rescert] [Sidr] Multiple Signatures on a ROA Message-ID: <20070808075749.44e8d8f8@garlique.algebras.org> In-Reply-To: <46B8B3B0.8080202@psg.com> References: <46AF4CF8.5080100@bbn.com> <46AF9763.2080606@apnic.net> <20070804174039.3E17311CA5@thangorodrim.hactrn.net> <46B52765.4020005@apnic.net> <20070806210814.0B6C222828@thrintun.hactrn.net> <20070807150257.77a80243@garlique.algebras.org> <46B8B3B0.8080202@psg.com> X-Mailer: Claws Mail 2.10.0 (GTK+ 2.10.14; i386--netbsdelf) X-Fruit-Of-The-Month-Club: persimmon Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: Resource Cert List , 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 Tue, 07 Aug 2007 08:02:24 -1000 Randy Bush wrote: > [ imiho, it is strange and ill-mannered that this thread has been > moved off the rescert list. this should rectify that. ] The issue came up in an IETF WG. The document in question is going into IETF WG process. I think the primary driver here is going to be WG consensus. > > the last three times we went around this discussion (were you not on > the other side?), we agreed that, for the exceedingly rare cases > where an issuer might want a bit to expire at a time other than the > rest of the resources, there was always reissue and revoke. That does not directly affect why I believe we need multiple signatures on a ROA. I'm finding this a bit of a non-sequiteur. What part of what I wrote related to lifetimes? > > this is not to say that i believe that different lifetimes for a > resource subset from one issuer to one subject is operationally > useful. i think it is yet one of a large and uninteresting set of > "wow, we could have a nice feature someone might use someday." but I was not addressing different lifetimes. I believe we need to encompass ROAs with multiple signatures over them because we will not be able to always ensure that resources lie under one trust anchor path, and yet want to create signings over more efficient prefixes. > > as, i think it was, steve kent said, this is already complex enough. > and complexity and security protocols do not make good bedfellows. The amount of complexity that is introduced by defining multiple signatures is understood: It is purposeful. I don't believe its avoidable. -George > > randy > _______________________________________________ Sidr mailing list Sidr@ietf.org https://www1.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Tue Aug 07 19:46: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 1IIYlG-0006uR-B0; Tue, 07 Aug 2007 19:46:50 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IIYlF-0006uM-I1 for sidr@ietf.org; Tue, 07 Aug 2007 19:46:49 -0400 Received: from mint.apnic.net ([202.12.29.58]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IIYlE-0003c8-MR for sidr@ietf.org; Tue, 07 Aug 2007 19:46:49 -0400 Received: from [192.94.63.110] (dhcp110.yarralumla.aarnet.edu.au [192.94.63.110]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mint.apnic.net (Postfix) with ESMTP id 8687AD5F33 for ; Wed, 8 Aug 2007 09:46:47 +1000 (EST) Message-ID: <46B904E7.6060601@apnic.net> Date: Wed, 08 Aug 2007 09:48:55 +1000 From: Geoff Huston User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: sidr@ietf.org 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: 4d87d2aa806f79fed918a62e834505ca 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? 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. *wg chair hat off* I've been reviewing the WG consideration of this topic so far From the thread of WG email so far on this topic it appears evident that no better approach for matching ROAs against the NLRI in a BGP update has been proposed in the case that the NLRI encompasses a span of addresses that are certified by multiple certificates. The thread of conversation appears to be the view on the one hand that such a situation is sufficiently unlikely that it should not be encompassed in a ROA format specification, and on the other hand the view has been that a standard interoperable specification should cover all eventualities and leave nothing to creativity of individual implementors and that multiple signatures on a ROA should be allowed. I don't believe that anyone has argued that this case would be one that would be commonly encountered. Equally, I have not seen a case made that this could _never_ happen under _any_ circumstances. The question I ask myself is should a standard specification provide guidance to implementors and users of the tool that covers all envisaged situations or should it only cover the cases that are most likely to occur and leave the remainder unspecified? My preference is the former approach, namely that a standard should be useful for interoperation in all envisaged use cases. Given the lack of workable alternatives here I remain of the view that the ROA specification should include this case, with the implication that a 'standard' ROA within this specification may contain multiple signatures. Geoff _______________________________________________ Sidr mailing list Sidr@ietf.org https://www1.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Thu Aug 09 09:53:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJ8SQ-0002QH-Nh; Thu, 09 Aug 2007 09:53:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJ8SO-0002Hr-S0 for sidr@ietf.org; Thu, 09 Aug 2007 09:53:44 -0400 Received: from mx12.bbn.com ([128.33.0.81]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IJ8SN-0002IT-Lv for sidr@ietf.org; Thu, 09 Aug 2007 09:53:44 -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 1IJ8SN-0006ZT-4r; Thu, 09 Aug 2007 09:53:43 -0400 Message-ID: <46BB1C66.9050206@bbn.com> Date: Thu, 09 Aug 2007 09:53:42 -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 Subject: Re: [Sidr] Multiple Signatures on a ROA References: <46AF4CF8.5080100@bbn.com> <46B904E7.6060601@apnic.net> In-Reply-To: <46B904E7.6060601@apnic.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 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 Geoff, Personally, I'm happy to have multiple signatures on a ROA. However, I think that multiple signatures is not the only way that we can provide guidence in all envisaged situations. Sandy had previously posted the following list of possible solutions: (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. (2) mandate that all sources (all CAs) MUST produce an aggregate cert when there are aggregatable certs (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. (4) allow a prefix holder whose source is not willing to sign an aggregate to sign an aggregate ROA with multiple signatures. There seems to be consensus that (1) is not a workable solution. Some people (including myself) like option (4), but others feel that implementing multiple signatures would introduce needless complexity. However, if the cases we are discussing are truly rare, then a combination of (2) and (3) may also be reasonable. Our documents could specify that a CA MUST produce an aggregate cert whenever possible and that a prefix holder needs to have an aggregate cert in order to advertise an aggregate prefix (otherwise, the prefix holder can only advertise the longer [non-aggregate] prefixes). - Matt Lepinski :-> Geoff Huston wrote: > Matt Lepinski wrote: > >> 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. > > > *wg chair hat off* > > I've been reviewing the WG consideration of this topic so far > > > From the thread of WG email so far on this topic it appears evident > that no better approach for matching ROAs against the NLRI in a BGP > update has been proposed in the case that the NLRI encompasses a span > of addresses that are certified by multiple certificates. > > The thread of conversation appears to be the view on the one hand that > such a situation is sufficiently unlikely that it should not be > encompassed in a ROA format specification, and on the other hand the > view has been that a standard interoperable specification should cover > all eventualities and leave nothing to creativity of individual > implementors and that multiple signatures on a ROA should be allowed. > > I don't believe that anyone has argued that this case would be one > that would be commonly encountered. Equally, I have not seen a case > made that this could _never_ happen under _any_ circumstances. > > The question I ask myself is should a standard specification provide > guidance to implementors and users of the tool that covers all > envisaged situations or should it only cover the cases that are most > likely to occur and leave the remainder unspecified? > > My preference is the former approach, namely that a standard should be > useful for interoperation in all envisaged use cases. Given the lack > of workable alternatives here I remain of the view that the ROA > specification should include this case, with the implication that a > 'standard' ROA within this specification may contain multiple signatures. > > Geoff > > > > > > > > _______________________________________________ > Sidr mailing list > Sidr@ietf.org > https://www1.ietf.org/mailman/listinfo/sidr > _______________________________________________ Sidr mailing list Sidr@ietf.org https://www1.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Thu Aug 09 18:37:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJGdZ-00045P-DR; Thu, 09 Aug 2007 18:37:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJGdY-00045J-Fs for sidr@ietf.org; Thu, 09 Aug 2007 18:37:48 -0400 Received: from mint.apnic.net ([202.12.29.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IJGdX-0007eC-LU for sidr@ietf.org; Thu, 09 Aug 2007 18:37:48 -0400 Received: from [203.10.60.23] (dhcp23.potaroo.net [203.10.60.23]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mint.apnic.net (Postfix) with ESMTP id 6101FD5F2D; Fri, 10 Aug 2007 08:37:46 +1000 (EST) Message-ID: <46BB97BA.7090708@apnic.net> Date: Fri, 10 Aug 2007 08:39:54 +1000 From: Geoff Huston User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Matt Lepinski Subject: Re: [Sidr] Multiple Signatures on a ROA References: <46AF4CF8.5080100@bbn.com> <46B904E7.6060601@apnic.net> <46BB1C04.5000705@bbn.com> In-Reply-To: <46BB1C04.5000705@bbn.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 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 Matt, Firstly, this posting has the *wg chair hat off* disclaimer > Personally, I'm happy to have multiple signatures on a ROA. However, I > think that multiple signatures is not the only way that we can provide > guidence in all envisaged situations. > > Sandy had previously posted the following list of possible solutions: > > (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. > > (2) mandate that all sources (all CAs) MUST produce an aggregate cert > when there are aggregatable certs > > (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. > > (4) allow a prefix holder whose source is not willing to sign an > aggregate to sign an aggregate ROA with multiple signatures. > > There seems to be consensus that (1) is not a workable solution. yes, I agree with this perspective Some > people (including myself) like option (4), but others feel that > implementing multiple signatures would introduce needless complexity. as is evident from the discussion in this wg mailing list. > > However, if the cases we are discussing are truly rare, then a > combination of (2) and (3) may also be reasonable. I disagree with that position. in response to 2) I am if the view that the entire discussion is about those cases where this does not happen. (i.e. yes, you can mandate that the tide must not come back in, but frankly its an exercise in Canutian posturing if issuers have local policies relating to certificate issuance that create differing validation paths of more specifics of an intended aggregate address advertisement!) And in response to 3), it seems like the cart is placed before the horse here. One would've thought that any sensible exercise in securing BGP would be able to secure what we do today, rather than only a subset. Our documents could > specify that a CA MUST produce an aggregate cert whenever possible and > that a prefix holder needs to have an aggregate cert in order to > advertise an aggregate prefix (otherwise, the prefix holder can only > advertise the longer [non-aggregate] prefixes). I find multiple signatures on a ROA a personally preferred option, supported already in available software and one that imposes minimal constraints on issuer policies, and minimal constraints on the ablity to secure BGP as we use it today. regards, Geoff _______________________________________________ Sidr mailing list Sidr@ietf.org https://www1.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Thu Aug 09 21:17:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJJ8C-0005Ob-25; Thu, 09 Aug 2007 21:17:36 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJJ8B-0005OW-79 for sidr@ietf.org; Thu, 09 Aug 2007 21:17:35 -0400 Received: from mint.apnic.net ([202.12.29.58]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IJJ8A-00077s-C1 for sidr@ietf.org; Thu, 09 Aug 2007 21:17:35 -0400 Received: from [192.94.63.110] (dhcp110.yarralumla.aarnet.edu.au [192.94.63.110]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mint.apnic.net (Postfix) with ESMTP id A9144D5F2D; Fri, 10 Aug 2007 11:17:32 +1000 (EST) Message-ID: <46BBBD2B.3080508@apnic.net> Date: Fri, 10 Aug 2007 11:19:39 +1000 From: Geoff Huston User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Randy Bush Subject: Re: [Sidr] Multiple Signatures on a ROA References: <46AF4CF8.5080100@bbn.com> <46B904E7.6060601@apnic.net> <46BB1C04.5000705@bbn.com> <46BB97BA.7090708@apnic.net> <46BBA435.9050708@psg.com> In-Reply-To: <46BBA435.9050708@psg.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Cc: Matt Lepinski , 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 Randy Bush wrote: > geoff, > > your mail user agent has a bug. somehow it repeatedly drops rescert > list from cc:s, as in the message to which i am replying. would > appreciate your checking into it. thanks. Thank you for this advice. I will look at this. On a similar topic, I note that your messages are not making it to the SIDR Working Group mailing list. It may be a bug in your mail user agent, or possibly a bug in the IETF's mailing list software, or possibly because you may not be subscribed to that mailing list. If you wish the SIDR Working Group to have the benefit of your perspectives on this topic you may want to check into this. >> I find multiple signatures on a ROA a personally preferred option, > > and many of us don't, as you have read. This has been noted in previous WG messages on this topic, all of which may not have reached you if you are not subscribed to the mailing list. (an archive of the SIDR WG mailing list is at http://www.ietf.org/html.charters/sidr-charter.html) > when there is no consensus, > possibly one should not add a feature. and this is an addition. Conventionally, the role of calling WG consensus of a WG topic is the responsibility of the WG Chairs. This particular co-chair thanks you for your advice concerning this role, and will be mindful of all advice and comments posted to the WG mailer as and when a WG consensus call is appropriate on this (or any other) topic. >> supported already in available software > > not in the sbgp implementations of which i am aware. not in the code > arin is producing. in what code does it exist? *WG co-chair hat OFF* it is my understanding that OpenSSL supports such functionality. To quote from: http://www.openssl.org/docs/apps/smime.html "a signing certificate when signing or resigning a message, this option can be used multiple times if more than one signer is required. If a message is being verified then the signers certificates will be written to this file if the verification was successful." I trust that this answers your query. regards, Geoff Huston _______________________________________________ Sidr mailing list Sidr@ietf.org https://www1.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Fri Aug 10 09:13: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 1IJUIX-0004ox-Lg; Fri, 10 Aug 2007 09:13:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJUIW-0004jq-P8 for sidr@ietf.org; Fri, 10 Aug 2007 09:13:00 -0400 Received: from [2002:425c:4242:0:210:5aff:fe86:1f54] (helo=cyteen.hactrn.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IJUIW-000598-9l for sidr@ietf.org; Fri, 10 Aug 2007 09:13:00 -0400 Received: from thrintun.hactrn.net (thrintun.hactrn.net [IPv6:2002:425c:4242:0:219:d1ff:fe12:5d30]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "thrintun.hactrn.net", Issuer "Grunchweather Associates" (verified OK)) by cyteen.hactrn.net (Postfix) with ESMTP id AAC0228465; Fri, 10 Aug 2007 13:12:59 +0000 (UTC) Received: from thrintun.hactrn.net (localhost [IPv6:::1]) by thrintun.hactrn.net (Postfix) with ESMTP id 6A41822828; Fri, 10 Aug 2007 09:12:59 -0400 (EDT) Date: Fri, 10 Aug 2007 09:12:59 -0400 From: Rob Austein To: sidr@ietf.org Subject: Re: [Rescert] [Sidr] Multiple Signatures on a ROA In-Reply-To: <20070807150257.77a80243@garlique.algebras.org> <20070804174039.3E17311CA5@thangorodrim.hactrn.net> References: <46AF4CF8.5080100@bbn.com> <46AF9763.2080606@apnic.net> <20070804174039.3E17311CA5@thangorodrim.hactrn.net> <46B52765.4020005@apnic.net> <20070806210814.0B6C222828@thrintun.hactrn.net> <20070807150257.77a80243@garlique.algebras.org> User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Message-Id: <20070810131259.6A41822828@thrintun.hactrn.net> X-Spam-Score: -0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a 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 Tue, 7 Aug 2007 15:02:57 +1000, George Michaelson wrote: > > I want there to be a good definition of what a multiple sign looks > like, and I support the WG defining it. I suspect that it adds a very > small amount of ASN1 'overhead' in the simple case of a single-sign, > and I don't see why it causes you such a problem as a code developer. ASN.1 overhead isn't the issue. The problems start to arise when you think about error handling and infrequently used code paths. As I said earlier in this thread: At Sat, 04 Aug 2007 13:40:39 -0400, Rob Austein wrote: > > ... just another code path that will need to be debugged and a more > complicated algorithm for deciding whether a ROA is valid (what's a > relying party supposed to do if if one signature on a ROA is valid > and the other is not? If five are valid and three are not? Is > there an upper limit to the number of signatures? At one point does > this become a denial of service attack on the relying party? ...). Seldom-used code paths tend not to get debugged. Whacky error cases that almost never occur tends not to get debugged. "Tend not to get debugged" is a technical term, meaning, among other things, that even if the developer attempts to simulate the error condition, that's still just a lab test; the code doesn't get exercised in real life until years later when some nogoodnik figures out how to turn it into a security exploit. If this were a feature I believed we needed, that need would dominate. Absent such a need, all I see is the downside. _______________________________________________ Sidr mailing list Sidr@ietf.org https://www1.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Mon Aug 13 06:55:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKXZy-0006pd-Sl; Mon, 13 Aug 2007 06:55:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKXZx-0006pX-9Z for sidr@ietf.org; Mon, 13 Aug 2007 06:55:21 -0400 Received: from smtp2.arin.net ([192.149.252.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IKXZw-0001Rg-4U for sidr@ietf.org; Mon, 13 Aug 2007 06:55:21 -0400 Received: by smtp2.arin.net (Postfix, from userid 5003) id 5F0FF1447A2; Mon, 13 Aug 2007 06:55:17 -0400 (EDT) Received: from ex.arin.net (ex.arin.net [192.149.252.56]) by smtp2.arin.net (Postfix) with ESMTP id AD6AF144769; Mon, 13 Aug 2007 06:55:16 -0400 (EDT) Received: from EDAMAME.arin.net ([192.136.136.194]) by ex.arin.net ([192.149.252.56]) with mapi; Mon, 13 Aug 2007 06:55:44 -0400 From: Tim Christensen To: Henk Uijterwaal , Rob Austein Date: Mon, 13 Aug 2007 06:55:15 -0400 Subject: RE: [Sidr] Multiple Signatures on a ROA Thread-Topic: [Sidr] Multiple Signatures on a ROA Thread-Index: AcfYAZOcpYKI4l4ZSniu6VhfndhTPQA5TsKw Message-ID: References: <46AF4CF8.5080100@bbn.com> <46AF9763.2080606@apnic.net> <20070804174039.3E17311CA5@thangorodrim.hactrn.net> <46B6B3BE.8060405@ripe.net> In-Reply-To: <46B6B3BE.8060405@ripe.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Spam-Checker-Version: SpamAssassin 2.63-arin1 (2004-01-11) on smtp2.arin.net X-Spam-Level: X-Spam-Status: No, hits=-73.0 required=5.0 tests=AWL,BAYES_00, USER_IN_WHITELIST autolearn=ham version=2.63-arin1 X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 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 > -----Original Message----- > From: Henk Uijterwaal [mailto:henk@ripe.net] > Sent: Monday, August 06, 2007 1:38 AM > Subject: Re: [Sidr] Multiple Signatures on a ROA > > All, > > > Having thought about this a bit, I remain skeptical about > the need for > > or desirability of multiple signatures on ROAs. > > > > First, as others have mentioned, this is a relatively > low-probability > > hypothetical case, and if it occurs at all it would be the > result of > > an issuer deliberately chosing to make life complicated for its > > subjects. This does not strike me as a strong case for > complicating > > the protocol (if anything, it strikes me as the opposite, > absent proof > > that this complexity really is necessary). > > I agree with Rob here. I'd have no problem with extending > the protocol if there was a valid case for doing so. > However, the two cases that were mentioned on the list > so-far, are low probability cases that can be handled by > having 2 ROAs. Until somebody comes up with a third case > that needs this, let's not make things more complicated than > they already are. Sorry I am late to this conversation, I've been on holiday for some time. ARIN has never assigned address space in a manner consistent with the hypot= hetical cases raised on the SIDR list, and it is unlikely that it would eve= r do so. Best regards to all, and happy to be back Tim Christensen _______________________________________________ Sidr mailing list Sidr@ietf.org https://www1.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Mon Aug 13 11:01: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 1IKbPr-0000aJ-Tl; Mon, 13 Aug 2007 11:01:11 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKbPq-0000Uy-DE for sidr@ietf.org; Mon, 13 Aug 2007 11:01:10 -0400 Received: from sentry.gw.tislabs.com ([192.94.214.100] helo=nutshell.tislabs.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IKbPq-0008K7-20 for sidr@ietf.org; Mon, 13 Aug 2007 11:01:10 -0400 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id l7DEvUk9010611; Mon, 13 Aug 2007 10:57:30 -0400 (EDT) Received: from pecan.tislabs.com(10.66.1.30) by nutshell.tislabs.com via csmap (V6.0) id srcAAA9GaaQu; Mon, 13 Aug 07 10:57:15 -0400 Received: by pecan.tislabs.com (Postfix, from userid 2005) id 437723F44B; Mon, 13 Aug 2007 10:55:02 -0400 (EDT) To: henk@ripe.net, sra@isc.org, timc@arin.net Subject: RE: [Sidr] Multiple Signatures on a ROA In-Reply-To: Message-Id: <20070813145502.437723F44B@pecan.tislabs.com> Date: Mon, 13 Aug 2007 10:55:02 -0400 (EDT) From: sandy@tislabs.com (Sandy Murphy) X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 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 >ARIN has never assigned address space in a manner consistent with the hypot= >hetical cases raised on the SIDR list, and it is unlikely that it would eve= >r do so. I'm confused. The ARIN NPRM says: 6.3.4. Aggregation ... Further, RIRs should apply practices that maximize the potential for subsequent allocations to be made contiguous with past allocations currently held. However, there can be no guarantee of contiguous allocation. and 6.5.7. Existing IPv6 address space holders Organizations that received /35 IPv6 allocations under the previous IPv6 address policy (RIRv6-Policies) are immediately entitled to have their allocation expanded to a /32 address block, without providing justification, so long as they satisfy the criteria in Section 6.5.1.1. The /32 address block will contain the already allocated smaller address block (one or multiple /35 address blocks in many cases) that was already reserved by the RIR for a subsequent allocation to the organization. Requests for additional space beyond the minimum /32 size will be evaluated as discussed elsewhere in the document. That's the sort of reserve for future allocation I was talking about. These quotes are from the IPv6 portion of the manual, but I thought from many references in conversation, email, etc. to space reserved for expansion that this occurred in IPv4 as well. --Sandy _______________________________________________ Sidr mailing list Sidr@ietf.org https://www1.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Mon Aug 13 12:35: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 1IKcsr-0002qf-IG; Mon, 13 Aug 2007 12:35:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKcsq-0002qU-8g for sidr@ietf.org; Mon, 13 Aug 2007 12:35:12 -0400 Received: from smtp2.arin.net ([192.149.252.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IKcsp-0002TO-3J for sidr@ietf.org; Mon, 13 Aug 2007 12:35:12 -0400 Received: by smtp2.arin.net (Postfix, from userid 5003) id 9D421144838; Mon, 13 Aug 2007 12:35:08 -0400 (EDT) Received: from ex.arin.net (ex.arin.net [192.149.252.56]) by smtp2.arin.net (Postfix) with ESMTP id E4E3A144833; Mon, 13 Aug 2007 12:35:07 -0400 (EDT) Received: from EDAMAME.arin.net ([192.136.136.194]) by ex.arin.net ([192.149.252.56]) with mapi; Mon, 13 Aug 2007 12:35:09 -0400 From: Tim Christensen To: Sandy Murphy , "henk@ripe.net" , "sra@isc.org" Date: Mon, 13 Aug 2007 12:35:06 -0400 Subject: RE: [Sidr] Multiple Signatures on a ROA Thread-Topic: [Sidr] Multiple Signatures on a ROA Thread-Index: AcfdusowhmLAkCEpQtea6tyYEMPpBAACqh9Q Message-ID: References: <20070813145502.437723F44B@pecan.tislabs.com> In-Reply-To: <20070813145502.437723F44B@pecan.tislabs.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Spam-Checker-Version: SpamAssassin 2.63-arin1 (2004-01-11) on smtp2.arin.net X-Spam-Level: X-Spam-Status: No, hits=-73.0 required=5.0 tests=AWL,BAYES_00, USER_IN_WHITELIST autolearn=ham version=2.63-arin1 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 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 > -----Original Message----- > From: Sandy Murphy [mailto:sandy@tislabs.com] > Sent: Monday, August 13, 2007 10:55 AM > To: henk@ripe.net; sra@isc.org; Tim Christensen > Cc: rescert@apnic.net; sidr@ietf.org > Subject: RE: [Sidr] Multiple Signatures on a ROA > > >ARIN has never assigned address space in a manner consistent > with the > >hypot=3D hetical cases raised on the SIDR list, and it is > unlikely that > >it would eve=3D r do so. > > I'm confused. > > The ARIN NPRM says: > [policy regarding reserves elided] > > That's the sort of reserve for future allocation I was talking about. > > These quotes are from the IPv6 portion of the manual, but I > thought from many references in conversation, email, etc. to > space reserved for expansion that this occurred in IPv4 as well. The examples raised on-list, in my understanding, referred to the following= : -- The possibility of two adjacent allocations from the same source being i= ssued at different times with different validity periods and the single iss= uer being unwilling to issue an aggregate cert (Dr. Kent, 7/31/07) For this example (and ignoring the unwilling-to-issue part) ARIN has never,= and will likely never, issue adjacent allocations at different times, ***w= ith different validity periods*** (end point validity, that is). All reser= ves allocations of adjacent space conform to the validity period of the add= ress block being extended. (FWIW, ARIN would not issue 'experimental' spac= e that is contiguous/aggregatable with 'normal' space either, and has never= been asked to nor done so.) -- The possibility of two (or more) adjacent allocations, received by the s= ame entity, coming from two (or more) different sources. For this example, ARIN has never issued resources to two (or more) differen= t organizations who, by happenstance or purpose, have registered further ad= jacent, aggregatable downstream reallocations to a single third-party entit= y. To be clear, I understood from the thread that the issues centered on diffe= ring-validity-periods-while-adjacent (not happening at ARIN) and split-pare= nt-while-adjacent (in my opinion rare, and not seen at ARIN from our observ= ations). Tim _______________________________________________ Sidr mailing list Sidr@ietf.org https://www1.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Mon Aug 13 17:52: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 1IKhpV-0000Dd-QB; Mon, 13 Aug 2007 17:52:05 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKhpU-0000DX-FE for sidr@ietf.org; Mon, 13 Aug 2007 17:52:04 -0400 Received: from mint.apnic.net ([202.12.29.58]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IKhpT-0008P8-U9 for sidr@ietf.org; Mon, 13 Aug 2007 17:52:04 -0400 Received: from [203.10.60.23] (dhcp23.potaroo.net [203.10.60.23]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mint.apnic.net (Postfix) with ESMTP id 0E6C3D5F31; Tue, 14 Aug 2007 07:52:01 +1000 (EST) Message-ID: <46C0D303.3070002@apnic.net> Date: Tue, 14 Aug 2007 07:54:11 +1000 From: Geoff Huston User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Tim Christensen Subject: Re: [Rescert] [Sidr] Multiple Signatures on a ROA References: <20070813145502.437723F44B@pecan.tislabs.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: 8b30eb7682a596edff707698f4a80f7d Cc: "sidr@ietf.org" , Sandy Murphy 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 *wg chair hat off* Tim, I did not say that ARIN would or would not generate such a situation within its own issuance policies, nor did I mention any other RIR. It may well be the case that RIR certificate issuance practices would attempt to avoid such a situation, but I don't believe that this adequately addresses the issue here about the scope of the standard specification. I took a more general view in my posting of the 10th when I noted that it was possible for "issuers [to] have local policies relating to certificate issuance that create differing validation paths of more specifics of an intended aggregate address advertisement" I noted, however that this was a possibility, and also noted in my posting of the 8th that: "The question I ask myself is should a standard specification provide guidance to implementors and users of the tool that covers all envisaged situations or should it only cover the cases that are most likely to occur and leave the remainder unspecified? My preference is the former approach, namely that a standard should be useful for interoperation in all envisaged use cases. Given the lack of workable alternatives here I remain of the view that the ROA specification should include this case, with the implication that a 'standard' ROA within this specification may contain multiple signatures. " regards, Geoff _______________________________________________ Sidr mailing list Sidr@ietf.org https://www1.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Tue Aug 14 22:48:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IL8vd-0003bx-Hs; Tue, 14 Aug 2007 22:48:13 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IL8vb-0003TX-U1 for sidr@ietf.org; Tue, 14 Aug 2007 22:48:11 -0400 Received: from skink.reptiles.org ([198.96.210.227] helo=mailbox.reptiles.org) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IL8vb-0002sZ-Id for sidr@ietf.org; Tue, 14 Aug 2007 22:48:11 -0400 Received: from mail.reptiles.org ([198.96.210.227] port=50570) by mailbox.reptiles.org([198.96.210.227] port=25) via TCP with esmtp (2335 bytes) (sender: ) (ident using UNIX) id for ; Tue, 14 Aug 2007 22:47:55 -0400 (EDT) (Smail-3.2.0.121 2005-Nov-17 #4 built 2006-Nov-28) Date: Tue, 14 Aug 2007 22:47:54 -0400 (EDT) From: Cat Okita X-X-Sender: gwen@gecko.reptiles.org To: Geoff Huston Subject: Re: [Rescert] [Sidr] Multiple Signatures on a ROA In-Reply-To: <46C0D303.3070002@apnic.net> Message-ID: <20070814224640.P34125@gecko.reptiles.org> References: <20070813145502.437723F44B@pecan.tislabs.com> <46C0D303.3070002@apnic.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: Sandy Murphy , "sidr@ietf.org" X-BeenThere: sidr@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Cat Okita List-Id: Secure Interdomain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: sidr-bounces@ietf.org On Tue, 14 Aug 2007, Geoff Huston wrote: > I noted, however that this was a possibility, and also noted in my posting of > the 8th that: > > "The question I ask myself is should a standard specification provide > guidance to implementors and users of the tool that covers all envisaged > situations or should it only cover the cases that are most likely to occur > and leave the remainder unspecified? > > My preference is the former approach, namely that a standard should be useful > for interoperation in all envisaged use cases. Given the lack of workable > alternatives here I remain of the view that the ROA specification should > include this case, with the implication that a 'standard' ROA within this > specification may contain multiple signatures. " I agree - it's easier to have the capability defined in a way that ensures interoperability in all cases than to have to shoehorn incompatible implementations together later, when it turns out that we -do- have more cases than we'd previously expected cheers!. ========================================================================== "A cat spends her life conflicted between a deep, passionate and profound desire for fish and an equally deep, passionate and profound desire to avoid getting wet. This is the defining metaphor of my life right now." _______________________________________________ Sidr mailing list Sidr@ietf.org https://www1.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Sat Aug 18 21:14: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 1IMZNK-0003aQ-VT; Sat, 18 Aug 2007 21:14:42 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IMZNJ-0003Ua-BY for sidr@ietf.org; Sat, 18 Aug 2007 21:14:41 -0400 Received: from mint.apnic.net ([202.12.29.58]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IMZNI-0005iK-Cb for sidr@ietf.org; Sat, 18 Aug 2007 21:14:41 -0400 Received: from [203.10.60.9] (dhcp9.potaroo.net [203.10.60.9]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mint.apnic.net (Postfix) with ESMTP id A257FD5F31; Sun, 19 Aug 2007 11:14:37 +1000 (EST) Message-ID: <46C799FF.4070608@apnic.net> Date: Sun, 19 Aug 2007 11:16:47 +1000 From: Geoff Huston User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: "Turner, Sean P." Subject: Re: [Sidr] Comments on draft-ietf-sidr-res-certs-07.txt References: <001501c7cf98$bf05b770$df128182@Wylie> <00be01c7e1b0$e5871f40$0301a8c0@Wylie> In-Reply-To: <00be01c7e1b0$e5871f40$0301a8c0@Wylie> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 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, *wg chair hat off* disclaimer Thanks indeed for this, and my apologies for not responding sooner. > > 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. The speficiation of SHA-1 was a direct cut and paste of method (1) of sections 4.2.1.2 and 4.2.1.1 of RFC 3280. We are trying not to deviate from that spec, and we view this resource certificate construct as an extension profile that does not alter the remainder of the specification of the certificate's fields. (The AIA field does not reference SHA-1) > > 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. That was the intent, yes. This was following from the advice of Steve Kent and Russ Housley who were telling us that it made sense to limit the extent that any key would be used. > > 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). Subject Alternative Name has been removed from the latest rev (-08) of the document For Subject Name, RFC3280 states that: "The subject name field is defined as the X.501 type Name." The res cert draft states that "The value of this field is a valid X.501 name." This would appear to be consistent, ues? > > Sec 5: I think you have to specify the proof-of-possession mechanism. The issue here is that there is no "standard" proof-of-possession mechanism, so we've used the form of approach used in RFC2986, note 3, in Section 3. > > 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. RFC4211 explicitly does not define a certificate request protocol (as noted in the Abstract) The res cert draft is similar in that is not not define a protocol for certificate requests, nor for any other action. The scope of the document is limited to the specification of the profile of resource certificates, the profile of CRLs, the profile of certificate requests and the definition of validtion within the scope of this profile. We don't believe, given the scope of this draft, that it is necessary to define an encapsulating protocol for the transmission of certificate requests. > > Sec 5.2.1: Need to explicitly prohibit issuerUID and subjectUID fields. > Both of these are explicitly prohibited in rfc4211. the res cert draft defines its profile as additional constraints on top of the constraints in rfc4211. > 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). > To use the RFC3280 field names for the sake of consistency? Yes, fair comment - we'll make this change. thanks, Geoff _______________________________________________ Sidr mailing list Sidr@ietf.org https://www1.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Mon Aug 20 13:58:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1INBWH-00031x-CB; Mon, 20 Aug 2007 13:58:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1INBWG-0002zF-4q for sidr@ietf.org; Mon, 20 Aug 2007 13:58:28 -0400 Received: from mx11.bbn.com ([128.33.0.80]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1INBWE-0004P2-Vx for sidr@ietf.org; Mon, 20 Aug 2007 13:58:28 -0400 Received: from dhcp89-089-071.bbn.com ([128.89.89.71]) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1INBWE-0000Wu-48; Mon, 20 Aug 2007 13:58:26 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <46C799FF.4070608@apnic.net> References: <001501c7cf98$bf05b770$df128182@Wylie> <00be01c7e1b0$e5871f40$0301a8c0@Wylie> <46C799FF.4070608@apnic.net> Date: Mon, 20 Aug 2007 13:57:37 -0400 To: Geoff Huston From: Stephen Kent Subject: Re: [Sidr] Comments on draft-ietf-sidr-res-certs-07.txt Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 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 I agree with Geoff re the use of SHA-1 vs. SHA-256. SHA-1 is called out in 3280 for SKI/AKI, although one could use other hash algorithms (or non-hash algorithms) for this purpose. My guess is that most CA software supports this. There seem to be no serious security problems arising from use of SHA-1 here. In contrast, we have been advised to migrate to SHA-256 for cert signatures, at least until NIST certifies a replacement. So, it makes sense to call for SHA-256 in that context, and I have been told that software for SHA-256 support for signatures is available as well. _______________________________________________ Sidr mailing list Sidr@ietf.org https://www1.ietf.org/mailman/listinfo/sidr