From sidr-bounces@ietf.org Wed Nov 08 13:30:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhsBK-0006UI-KW; Wed, 08 Nov 2006 13:29:50 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhsBK-0006Ti-0k for sidr@ietf.org; Wed, 08 Nov 2006 13:29:50 -0500 Received: from outbound-mail.lax.untd.com ([64.136.28.164]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GhsBI-0005wp-Kr for sidr@ietf.org; Wed, 08 Nov 2006 13:29:49 -0500 Received: from webmail18.lax.untd.com (webmail18.lax.untd.com [10.131.27.158]) by smtpout08.lax.untd.com with SMTP id AABCXEJRCACEKPVA for (sender ); Wed, 8 Nov 2006 10:28:50 -0800 (PDT) X-UNTD-OriginStamp: AcganUYbgVGZ0C6nm/9IPatablCmMCeKuQbiCprCq0x3pnzTDulAEw== Received: (from fergdawg@netzero.net) by webmail18.lax.untd.com (jqueuemail) id L6N4BHRW; Wed, 08 Nov 2006 10:28:31 PST Received: from [130.129.70.90] by webmail18.lax.untd.com with HTTP: Wed, 8 Nov 2006 18:27:53 GMT X-Originating-IP: [130.129.70.90] Mime-Version: 1.0 From: "Fergie" Date: Wed, 8 Nov 2006 18:27:53 GMT To: sidr@ietf.org X-Mailer: Webmail Version 4.0 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Content-Type: text/plain Message-Id: <20061108.102831.21495.1401412@webmail18.lax.untd.com> X-ContentStamp: 3:4:3924132306 X-MAIL-INFO: 48016d0821296d2929a5010ce11dc969696cc5e869fc9ce11c55d5257919196d35ec4508 X-UNTD-Peer-Info: 10.131.27.158|webmail18.lax.untd.com|webmail18.lax.untd.com|fergdawg@netzero.net X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Subject: [Sidr] Reminder: WG Mtg. Slides 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 When the slides from today's meeting as available, would some kind soul please provide a pointer to the list? Thanks, - ferg -- "Fergie", a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawg(at)netzero.net ferg's tech blog: http://fergdawg.blogspot.com/ _______________________________________________ Sidr mailing list Sidr@ietf.org https://www1.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Wed Nov 08 17:05:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhvWz-0008LH-Tb; Wed, 08 Nov 2006 17:04:25 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhvWz-0008LC-1v for sidr@ietf.org; Wed, 08 Nov 2006 17:04:25 -0500 Received: from kahuna.telstra.net ([2001:360::4]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhvWx-0005rD-Gu for sidr@ietf.org; Wed, 08 Nov 2006 17:04:25 -0500 Received: from gihm3.apnic.net (kahuna.telstra.net [IPv6:2001:360::4]) by kahuna.telstra.net (8.12.11/8.12.11) with ESMTP id kA8M42xO041972; Thu, 9 Nov 2006 09:04:07 +1100 (EST) (envelope-from gih@apnic.net) Message-Id: <7.0.0.16.2.20061109085908.014b9048@apnic.net> X-Mailer: QUALCOMM Windows Eudora Version 7.0.0.16 Date: Thu, 09 Nov 2006 09:04:00 +1100 To: sidr@ietf.org From: Geoff Huston Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: -2.8 (--) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: saag@mit.edu Subject: [Sidr] SIDR Working Group meeting summary 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 SIDR Working Group Summary The SIDR working group met at IETF 67, 0900-1130 on Wednesday. The WG agenda items covered the progress with the charter milestones, the resource certificate profile and the initial thoughts and considerations regarding routing origination attestations and their content and format. In considering the WG status as against the milestones, it is the case that the WG's efforts on an architecture for inter-domain routing security are falling behind. In the WG meeting a group of authors volunteered to work on this topic in the coming months, so that there is now some confidence that while this milestone is going to be late (as the milestone was August 2006!), a path of progress has been identified. Work on the secure origination charter item is also now underway. We received an informal report from Russ White, the RSPEC WG co-chair that the IDR Security Requirements documents was close to completion and that the RPSEC WG are unable to resolve one way or another the issues relating to distinct approaches with respect to path validation that have been considered in RPSEC for some months. The implication is that the issues that surfaced in RPSEC may be replayed in SIDR. At his stage we will await the RPSEC outcomes to understand the situation a little better. Presentations (and minutes, when prepared) can be views in the SIDR section of https://datatracker.ietf.org/public/meeting_materials.cgi?meeting_num=67 In short - productive WG meeting, people interested in working on the next steps, progress is being made, and the charter milestones are, at this stage, not too badly behind the original estimates! thanks, Geoff and Sandy co-chairs, SIDR WG Geoff and Sandy _______________________________________________ Sidr mailing list Sidr@ietf.org https://www1.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Wed Nov 08 17:05:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhvXa-00007K-7l; Wed, 08 Nov 2006 17:05:02 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhvXY-0008U9-Lq for sidr@ietf.org; Wed, 08 Nov 2006 17:05:00 -0500 Received: from kahuna.telstra.net ([2001:360::4]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhvXX-0005zn-W0 for sidr@ietf.org; Wed, 08 Nov 2006 17:05:00 -0500 Received: from gihm3.apnic.net (kahuna.telstra.net [IPv6:2001:360::4]) by kahuna.telstra.net (8.12.11/8.12.11) with ESMTP id kA8M4uPf041993; Thu, 9 Nov 2006 09:04:57 +1100 (EST) (envelope-from gih@apnic.net) Message-Id: <7.0.0.16.2.20061109090409.014a9730@apnic.net> X-Mailer: QUALCOMM Windows Eudora Version 7.0.0.16 Date: Thu, 09 Nov 2006 09:04:54 +1100 To: "Fergie" , sidr@ietf.org From: Geoff Huston Subject: Re: [Sidr] Reminder: WG Mtg. Slides In-Reply-To: <20061108.102831.21495.1401412@webmail18.lax.untd.com> References: <20061108.102831.21495.1401412@webmail18.lax.untd.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: -2.8 (--) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad 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 At 05:27 AM 9/11/2006, Fergie wrote: >When the slides from today's meeting as available, would some >kind soul please provide a pointer to the list? sure - The presentations for SIDR, and all other WG meetings this week can be found at: https://datatracker.ietf.org/public/meeting_materials.cgi?meeting_num=67 cheers, Geoff _______________________________________________ Sidr mailing list Sidr@ietf.org https://www1.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Wed Nov 08 17:05:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhvWz-0008LH-Tb; Wed, 08 Nov 2006 17:04:25 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhvWz-0008LC-1v for sidr@ietf.org; Wed, 08 Nov 2006 17:04:25 -0500 Received: from kahuna.telstra.net ([2001:360::4]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhvWx-0005rD-Gu for sidr@ietf.org; Wed, 08 Nov 2006 17:04:25 -0500 Received: from gihm3.apnic.net (kahuna.telstra.net [IPv6:2001:360::4]) by kahuna.telstra.net (8.12.11/8.12.11) with ESMTP id kA8M42xO041972; Thu, 9 Nov 2006 09:04:07 +1100 (EST) (envelope-from gih@apnic.net) Message-Id: <7.0.0.16.2.20061109085908.014b9048@apnic.net> X-Mailer: QUALCOMM Windows Eudora Version 7.0.0.16 Date: Thu, 09 Nov 2006 09:04:00 +1100 To: sidr@ietf.org From: Geoff Huston Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: -2.8 (--) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: saag@mit.edu Subject: [Sidr] SIDR Working Group meeting summary 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 SIDR Working Group Summary The SIDR working group met at IETF 67, 0900-1130 on Wednesday. The WG agenda items covered the progress with the charter milestones, the resource certificate profile and the initial thoughts and considerations regarding routing origination attestations and their content and format. In considering the WG status as against the milestones, it is the case that the WG's efforts on an architecture for inter-domain routing security are falling behind. In the WG meeting a group of authors volunteered to work on this topic in the coming months, so that there is now some confidence that while this milestone is going to be late (as the milestone was August 2006!), a path of progress has been identified. Work on the secure origination charter item is also now underway. We received an informal report from Russ White, the RSPEC WG co-chair that the IDR Security Requirements documents was close to completion and that the RPSEC WG are unable to resolve one way or another the issues relating to distinct approaches with respect to path validation that have been considered in RPSEC for some months. The implication is that the issues that surfaced in RPSEC may be replayed in SIDR. At his stage we will await the RPSEC outcomes to understand the situation a little better. Presentations (and minutes, when prepared) can be views in the SIDR section of https://datatracker.ietf.org/public/meeting_materials.cgi?meeting_num=67 In short - productive WG meeting, people interested in working on the next steps, progress is being made, and the charter milestones are, at this stage, not too badly behind the original estimates! thanks, Geoff and Sandy co-chairs, SIDR WG Geoff and Sandy _______________________________________________ Sidr mailing list Sidr@ietf.org https://www1.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Wed Nov 08 17:05:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhvXa-00007K-7l; Wed, 08 Nov 2006 17:05:02 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhvXY-0008U9-Lq for sidr@ietf.org; Wed, 08 Nov 2006 17:05:00 -0500 Received: from kahuna.telstra.net ([2001:360::4]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhvXX-0005zn-W0 for sidr@ietf.org; Wed, 08 Nov 2006 17:05:00 -0500 Received: from gihm3.apnic.net (kahuna.telstra.net [IPv6:2001:360::4]) by kahuna.telstra.net (8.12.11/8.12.11) with ESMTP id kA8M4uPf041993; Thu, 9 Nov 2006 09:04:57 +1100 (EST) (envelope-from gih@apnic.net) Message-Id: <7.0.0.16.2.20061109090409.014a9730@apnic.net> X-Mailer: QUALCOMM Windows Eudora Version 7.0.0.16 Date: Thu, 09 Nov 2006 09:04:54 +1100 To: "Fergie" , sidr@ietf.org From: Geoff Huston Subject: Re: [Sidr] Reminder: WG Mtg. Slides In-Reply-To: <20061108.102831.21495.1401412@webmail18.lax.untd.com> References: <20061108.102831.21495.1401412@webmail18.lax.untd.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: -2.8 (--) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad 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 At 05:27 AM 9/11/2006, Fergie wrote: >When the slides from today's meeting as available, would some >kind soul please provide a pointer to the list? sure - The presentations for SIDR, and all other WG meetings this week can be found at: https://datatracker.ietf.org/public/meeting_materials.cgi?meeting_num=67 cheers, Geoff _______________________________________________ Sidr mailing list Sidr@ietf.org https://www1.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Wed Nov 08 17:32:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ghvxz-00053l-Oc; Wed, 08 Nov 2006 17:32:19 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ghvxy-00053g-P2 for sidr@ietf.org; Wed, 08 Nov 2006 17:32:18 -0500 Received: from nutshell.tislabs.com ([192.94.214.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ghvxx-00036I-HV for sidr@ietf.org; Wed, 08 Nov 2006 17:32:18 -0500 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id kA8MUtOL001963; Wed, 8 Nov 2006 17:30:55 -0500 (EST) Received: from pecan.tislabs.com(10.66.1.30) by nutshell.tislabs.com via csmap (V6.0) id srcAAAKlaGQd; Wed, 8 Nov 06 17:30:11 -0500 Received: by pecan.tislabs.com (Postfix, from userid 2005) id EEB633F49A; Wed, 8 Nov 2006 17:01:06 -0500 (EST) To: fergdawg@netzero.net, sidr@ietf.org Subject: Re: [Sidr] Reminder: WG Mtg. Slides In-Reply-To: <20061108.102831.21495.1401412@webmail18.lax.untd.com> Message-Id: <20061108220106.EEB633F49A@pecan.tislabs.com> Date: Wed, 8 Nov 2006 17:01:06 -0500 (EST) From: sandy@tislabs.com (Sandy Murphy) X-Spam-Score: 0.0 (/) X-Scan-Signature: 2870a44b67ee17965ce5ad0177e150f4 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 Check out the IETF meeting presentation page: https://datatracker.ietf.org/public/meeting_materials.cgi?meeting_num=67 --Sandy _______________________________________________ Sidr mailing list Sidr@ietf.org https://www1.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Wed Nov 08 17:36:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ghw1z-0006S0-60; Wed, 08 Nov 2006 17:36:27 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ghw1y-0006Rv-Fs for sidr@ietf.org; Wed, 08 Nov 2006 17:36:26 -0500 Received: from outbound-mail.lax.untd.com ([64.136.28.164]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Ghw1t-00042X-3O for sidr@ietf.org; Wed, 08 Nov 2006 17:36:26 -0500 Received: from webmail53.lax.untd.com (webmail53.lax.untd.com [10.131.27.193]) by smtpout06.lax.untd.com with SMTP id AABCXEY84AG9ZNU2 for (sender ); Wed, 8 Nov 2006 14:36:10 -0800 (PDT) X-UNTD-OriginStamp: AcganUYbgVGZ0C6nm/9IPatablCmMCeKI7Z+ws1QDnzlHjNDZUdQPw== Received: (from fergdawg@netzero.net) by webmail53.lax.untd.com (jqueuemail) id L6PJFCY6; Wed, 08 Nov 2006 14:35:17 PST Received: from [130.129.69.175] by webmail53.lax.untd.com with HTTP: Wed, 8 Nov 2006 22:34:46 GMT X-Originating-IP: [130.129.69.175] Mime-Version: 1.0 From: "Fergie" Date: Wed, 8 Nov 2006 22:34:46 GMT To: sandy@tislabs.com Subject: Re: [Sidr] Reminder: WG Mtg. Slides X-Mailer: Webmail Version 4.0 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Content-Type: text/plain Message-Id: <20061108.143517.717.929143@webmail53.lax.untd.com> X-ContentStamp: 2:3:128512406 X-MAIL-INFO: 3b6dd445d44041c44030418941388520c000fdc06524f08db1a9b4342d516d2d7154d1a401404531d16d94f5c46df438c45dc46d19ed2541251545b5c191198574 X-UNTD-Peer-Info: 10.131.27.193|webmail53.lax.untd.com|webmail53.lax.untd.com|fergdawg@netzero.net X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c 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 -- sandy@tislabs.com (Sandy Murphy) wrote: >Check out the IETF meeting presentation page: >https://datatracker.ietf.org/public/meeting_materials.cgi?meeting_num=3D= 67 > >--Sandy > Thanks guys -- finally found 'em. :-) - ferg _______________________________________________ Sidr mailing list Sidr@ietf.org https://www1.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Thu Nov 09 09:52:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiBEh-0007I3-Eo; Thu, 09 Nov 2006 09:50:35 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiBEf-0007Hv-BD for sidr@ietf.org; Thu, 09 Nov 2006 09:50:33 -0500 Received: from kahuna.telstra.net ([2001:360::4]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GiBEe-0002RC-2r for sidr@ietf.org; Thu, 09 Nov 2006 09:50:33 -0500 Received: from gihm3.apnic.net (kahuna.telstra.net [IPv6:2001:360::4]) by kahuna.telstra.net (8.12.11/8.12.11) with ESMTP id kA9Eo7gq074340; Fri, 10 Nov 2006 01:50:11 +1100 (EST) (envelope-from gih@apnic.net) Message-Id: <7.0.0.16.2.20061110014555.0147ae48@apnic.net> X-Mailer: QUALCOMM Windows Eudora Version 7.0.0.16 Date: Fri, 10 Nov 2006 01:50:03 +1100 To: sidr@ietf.org From: Geoff Huston Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: -2.8 (--) X-Scan-Signature: 142a000676f5977e1797396caab8b611 Cc: fenner@research.att.com, Sandy Murphy Subject: [Sidr] draft on minutes of the SIDR WG meeting 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 thanks Henk for your notes! Geoff Secure Inter-Domain Routing WG (sidr) IETF 67, San Diego WEDNESDAY, November 8, 2006 0900-1130 Morning Session I ==================================================== CHAIR(s): Geoff Huston Sandra Murphy AGENDA: 1) Administrivia 5 minutes - Mailing list: http://www.ietf.org/mail-archive/web/sidr/index.html - Scribe: Henk Uijterwal - Blue Sheets - Agenda Bashing 2) WG Status Report 10 minutes Chairs 3) Certificate Discussion (Geoff Huston) 30 minutes A Profile for X.509 PKIX Resource Certificates draft-ietf-sidr-res-certs-02.txt Available at: http://www.ietf.org/internet-drafts/draft-ietf-sidr-res-certs-02.txt This will discuss the latest version of the resource certificate draft and report on the status of a trial implementation of resource certificates. 4) Certificate Policy and Certificate Practice Statement (Steve Kent) 30 minutes Template for an Internet Registry's Certification Practice Statement (CPS) for the Internet IP Address and AS Number (PKI) draft-ietf-sidr-cps-irs-00.txt Available at: http://www.ietf.org/internet-drafts/draft-ietf-sidr-cps-irs-00.txt Certificate Policy (CP) for the Internet IP Address and AS Number (PKI) draft-ietf-sidr-cp-00.txt Available at: http://www.ietf.org/internet-drafts/draft-ietf-sidr-cp-00.txt This will discuss both a certificate policy for a PKI used for resource certificates and a template for a Certification Practice Statement (CPS) for an Internet Registry. 5) Route Origination Attestation (Sandy Murphy) 30 minutes Discussion of route origination attestation issues. SUMMARY: The WG agenda items covered the progress with the charter milestones, the resource certificate profile and the initial considerations regarding routing origination attestations. The efforts on an architecture for inter-domain routing security are falling behind. A group of authors volunteered to work on this in the coming months, so that there is now some confidence that while this milestone is going to be late, a path of progress has been identified. Work on secure origination is also now visible. We had a report from Russ White, the RSPEC WG co-chair that the IDR requirements documents was close to completion and that they are unable to resolve the issues relating to distinct approaches with respect to path validation. We will await the RPSEC outcomes to understand the situation a little better. NOTES: 2. WG Status Report Sandy Murphy (Co-Chair) reviewed the WG milestones and note that the WG was slipping behind on the document on a secure inter-domain routing architecture. ACTION: Sure Hares and Steve Kent volunteer to work on this draft The certificate profile specification is largely completed, and the ROA activity is starting up. The upcoming deadlines to complete this work in the period March - June 2007 remain possible. 3. Certificate Discussion a. Resource Certificate Profile The draft to which this item is speaking to is from APNIC together with an inter-RIR design team. A resource certificate is based on specific choices made from the PKIX profile (RFC3780 (not the draft 3280bis)), and RFC3779 Resource Extensions. The general constraints are that the RFC3779 extensions are critical and MUST be present. In terms of specific profile, the AIA is cast as a persistent URL, and EE certs are used as one-off signing certificates where the private key is destroyed after a single signing. Questions / Comments: Russ White: When should people turn the CA bit off? The draft should offer some guidance. Steve Kent: The scope of the CRL is all certificates issued by this issuer when using this key. Under key rollover the CRLDP will also follow the new key, so that the CRL is not constant across key rollover. Steve Kent: We should analyze the impact of this choice of one-off EE certificates. It is an elegant solution for some things, but there might be more. The example cited was the routing table, in the case where an ISP with a /x prefix allocates sub blocks to customers, where those customers become multi homed in the routing system. How many EE certs are involved in this case? Based on use-once principle, it appears that many more EE certs are needed to support sub allocations. Geoff Huston: Does not envisaging this happening to a large extent (assuming in the response that EE certs are not 1:1 matched with routing objects in terms of constraints on advertisement of more specific prefixes) Brian Wise: Is the one-off use nature of an EE cert mandatory or a suggested requirement? Geoff: This is a suggested requirement. b. Resource Certificate Trial progress report. (This report was noted as being an informational item.) Questions / Comments: Steve Kent: With respect to your illustration of the use of signing a database object with a signature that was supported by a Resource Certificate then the semantics of the signing need to be carefully defined. The signer is a resource holder, and the result of the signing relates to the resources in the database object. Steve Kent: Is worried about the opportunity to retrofit data in into existing data structures. Registries can have a diverse range of data, while Resource Certificates only attest to resource holdings. We don't want to create situation where seeing a signature implies trust in all the fields in the object. This unrelated information has to be checked. George Michaelson: Yes, a Relying Party has to validate this information, and existence of signature is not of itself enough for all the fields in the registry object. Sandy Murphy: How does AS65000 know the person really is ISPx, entitled to advertise this prefix? Shouldn't this advertising party want email signed by the prefix holder's private key? In your example the resource holder has just destroyed it? Steve Kent: What Sandy is asking, is, if I send email to my ISP, how do they know that the info I provide, claim to be a particular subscriber of the ISP, is correct, so they bind the (valid) ROA info to the subscriber. Geoff Huston: The Resource Certificate has limited use. This does not cover secure communication and identity attestation. For such purposes the parties may want to use some other trusted communication framework. Use an identity certificate if identity is the issue in this form of communication. Steve Kent: The ISP can decide. Geoff Huston: These Resource Certificates provide tools for validation in the context of use of resources, and are to be used only for this role. They should not be used for unrelated purposes. Sandy Murphy: We need guidelines for good usage of these certificates. 4. Certificate Policy and Certificate Practice Statement The goal here are informational RFCs. The draft CP and CPS documents need review and comments from the Working Group. Questions / Comments: Paul Wilson, Is it possible that CPS will conflict as a result of local differences? Steve Kent: The CPS is per issuer, so there cannot be a conflict here. The template does not instruct an Issuer what it must do. Brian Weiss: This is necessary work, and an informational RFC is a good outcome here. How is a PKI-wide CP enforced? Steve Kent: Is averse to the term "enforce". However, issuers will declare that they use the CP and hopefully do it according to the CP. Russ Housley, This can be summarized as a CP for resources. CAs that chose to issue certs will reference this CP by the OID in the issued certificates. Issuers will also write a CPS to state how they meet the requirements in CP. Taijii: CP and CPS are helpful are not only helpful afterwards (to see what happened), also useful to build trust infrastructure and planning. Sandy Murphy: The key pair generation. Is this requestor generated and issuer signs, or issuer generated and signed. Is there a recommended method? Steve Kent: Its requestor generated and issuer-signed. This does not preclude the requestor using an agent, and the issuer undertaking that agent role. 5. Route Origination attestation a. ROA Content Questions / Comments: Steve Kent: Is there benefit in having more than one AS in a ROA?. It could be useful for ISPs running a collection of AS. Geoff Huston: more than one would be viable, as long as it is one ISP. The multiple-AS ROA fate shares in terms of validity across all the listed AS's. Steve Kent: When talking about a ROA, the associated resource certificate for the prefix should be validating the ROA for exact prefix or any more specific. From a safety standpoint, should we want an exact match, and explicitly disallow more specifics to be validated from a covering prefix in a ROA? If both the listed aggregate and more specifics can match then is this risky? If you require an exact match without more specifics then isn't this less risky in terms of validating unintended leakage of more specifics? Simon Leinen: This sounds convincing to me. Ruediger Volk: In the world of existing allocated prefixes Steve's example may break things. Ruediger always asks for precise prefixes. Geoff Huston: Noted that more than half the routing table are more specifics that share a common origin. Making the ROA precise would cause the number of ROAs and the number of EE certs to increase proportionately. The issue of whether a ROA allows more specifics or not requires some further consideration. William Liebzon: In some cases you want constraints, but perhaps we should consult with operational folks as to what they want. Ruediger Volk: Where do operators communicate routes? Would prefer specific routes for specific address blocks. If this is not expressed in the ROA, where then? If we don't do it here, we are deferring to another level. Geoff Huston: What do you want from a ROA? Do you want to put routing policy in the ROA? This was not intended as a route policy vehicle as far as I was aware. Larry Blunk: Allowing more specifics seems to allow lying in path, given correct origin AS. William Liebzon: Prefers not to have policy in ROAS. Suggests that this be referred to the WG list. Ruediger Volk: Resource Certs are for address space, while the ROA is to switch over from there to the routing system. Description doesn't imply policy here - it allows you to define more precisely what you are authorizing. Geoff Huston: will take this to the list. This is a draft being written, so we can do anything at this early stage! Steve Kent: Trust anchors are chosen by relying party. Geoff Huston: A ROA doesn't come with trust anchor sets. b. ROA format and content proposal Similar work, started from a different point of view. No Questions / Comments c. Issues Questions / Comments: Ruediger Volk: Within RPSL, don't touch. For new system: just the address holder is right. Path checking is the thing, and a ROA can't do this. Geoff Huston: It would be better not to overload ROAs with path validation. We're waiting for RPSEC to give us requirements for paths. Sandy Murphy: The problem is in ROA, not in path. Steve Kent: Mixed feelings, if ROA is a right to originate, then it does not need a second signature from the originating AS. It wouldn't solve all path attacks in any case. Russ White (RPSEC co-chair): The RPSEC IDR current requirements doc is most likely what we'll end up with, and as there have been no comments recently this like the candidate document for a WG last call. This document is not specific on the level of validation required for path validity. The document is expected to be in last call before March 2007. _______________________________________________ Sidr mailing list Sidr@ietf.org https://www1.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Thu Nov 09 11:18:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiCc2-0001mN-PR; Thu, 09 Nov 2006 11:18:46 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiCc1-0001lm-3u for sidr@ietf.org; Thu, 09 Nov 2006 11:18:45 -0500 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 1GiCbz-0002uN-T7 for sidr@ietf.org; Thu, 09 Nov 2006 11:18:45 -0500 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id kA9GHFcY003319; Thu, 9 Nov 2006 11:17:15 -0500 (EST) Received: from pecan.tislabs.com(10.66.1.30) by nutshell.tislabs.com via csmap (V6.0) id srcAAAtMaWBg; Thu, 9 Nov 06 11:16:53 -0500 Received: by pecan.tislabs.com (Postfix, from userid 2005) id D087C3F44B; Thu, 9 Nov 2006 10:13:41 -0500 (EST) To: gih@apnic.net, sidr@ietf.org In-Reply-To: <7.0.0.16.2.20061110014555.0147ae48@apnic.net> Message-Id: <20061109151341.D087C3F44B@pecan.tislabs.com> Date: Thu, 9 Nov 2006 10:13:41 -0500 (EST) From: sandy@tislabs.com (Sandy Murphy) X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: sandy@tislabs.com Subject: [Sidr] Re: draft on minutes of the SIDR WG meeting 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 >Brian Wise Brian Weis >b. ROA format and content proposal > > Similar work, started from a different point of view. > > No Questions / Comments Russ Housley did note that CMS provided exactly the signed object with multiple signatures structure shown in the ASN.1 encoding. --Sandy _______________________________________________ Sidr mailing list Sidr@ietf.org https://www1.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Thu Nov 09 11:28:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiClI-0007vq-QR; Thu, 09 Nov 2006 11:28:20 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiClH-0007sf-Uf for sidr@ietf.org; Thu, 09 Nov 2006 11:28:19 -0500 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 1GiClG-0003tq-J7 for sidr@ietf.org; Thu, 09 Nov 2006 11:28:19 -0500 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id kA9GQupo004466 for ; Thu, 9 Nov 2006 11:26:56 -0500 (EST) Received: from pecan.tislabs.com(10.66.1.30) by nutshell.tislabs.com via csmap (V6.0) id srcAAA5TaODi; Thu, 9 Nov 06 11:25:47 -0500 Received: by pecan.tislabs.com (Postfix, from userid 2005) id 7D3AB3F43A; Thu, 9 Nov 2006 11:25:41 -0500 (EST) To: sidr@ietf.org Subject: Re: [Sidr] draft on minutes of the SIDR WG meeting In-Reply-To: <7.0.0.16.2.20061110014555.0147ae48@apnic.net> Message-Id: <20061109162541.7D3AB3F43A@pecan.tislabs.com> Date: Thu, 9 Nov 2006 11:25:41 -0500 (EST) From: sandy@tislabs.com (Sandy Murphy) X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 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 >b. ROA format and content proposal > > Similar work, started from a different point of view. > > No Questions / Comments One more (this could have been an off-mike exchange, if so, sorry) Sandy Murphy: why a list of signatures? Brian Weis/Geoff Huston: with mulitiple trust anchors, it is possible that you might have multiple resource certificates for the same prefixes. You would need to sign the ROA with all those certificates so that it would validate no matter what trust anchor "relying parties" might use. --Sandy _______________________________________________ Sidr mailing list Sidr@ietf.org https://www1.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Thu Nov 09 12:00:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiDFx-0000rN-2N; Thu, 09 Nov 2006 12:00:01 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiDFw-0000ne-Es for sidr@ietf.org; Thu, 09 Nov 2006 12:00:00 -0500 Received: from mx12.bbn.com ([128.33.0.81]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GiDFu-0007Q0-86 for sidr@ietf.org; Thu, 09 Nov 2006 12:00:00 -0500 Received: from dommiel.bbn.com ([192.1.122.15] helo=[12.105.247.171]) by mx12.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1GiDFr-0002Ra-3c; Thu, 09 Nov 2006 11:59:55 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: <20061109162541.7D3AB3F43A@pecan.tislabs.com> References: <20061109162541.7D3AB3F43A@pecan.tislabs.com> Date: Thu, 9 Nov 2006 11:59:49 -0500 To: sandy@tislabs.com (Sandy Murphy) From: Stephen Kent Subject: Re: [Sidr] draft on minutes of the SIDR WG meeting Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: sandy@tislabs.com, 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 11:25 AM -0500 11/9/06, Sandy Murphy wrote: > >b. ROA format and content proposal >> >> Similar work, started from a different point of view. >> >> No Questions / Comments > >One more (this could have been an off-mike exchange, if so, sorry) > > Sandy Murphy: why a list of signatures? > > Brian Weis/Geoff Huston: with mulitiple trust anchors, it is possible > that you might have multiple resource certificates for the same > prefixes. You would need to sign the ROA with all those certificates > so that it would validate no matter what trust anchor "relying > parties" might use. > >--Sandy > This is not the way that a PKI would be expected to work, in general. A signer of data cannot in general know what TAs RPs may select, so it is not incumbent on a signer to try to provide multiple signatures to accommodate this uncertainty. In our context, a signer selects a cert that embodies the necessary authorization and uses the corresponding private key. It is up to an RP to construct a path to one of his TAs to verify the signature. Steve _______________________________________________ Sidr mailing list Sidr@ietf.org https://www1.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Thu Nov 09 15:33:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiGZW-0002fN-V8; Thu, 09 Nov 2006 15:32:26 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiGZV-0002eo-Ou for sidr@ietf.org; Thu, 09 Nov 2006 15:32:25 -0500 Received: from nutshell.tislabs.com ([192.94.214.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GiGZT-0004vu-IJ for sidr@ietf.org; Thu, 09 Nov 2006 15:32:25 -0500 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id kA9KUrbj026251 for ; Thu, 9 Nov 2006 15:30:53 -0500 (EST) Received: from pecan.tislabs.com(10.66.1.30) by nutshell.tislabs.com via csmap (V6.0) id srcAAA0MaicZ; Thu, 9 Nov 06 15:26:58 -0500 Received: by pecan.tislabs.com (Postfix, from userid 2005) id 0FB9A3F462; Thu, 9 Nov 2006 14:58:27 -0500 (EST) To: sidr@ietf.org In-Reply-To: Message-Id: <20061109195827.0FB9A3F462@pecan.tislabs.com> Date: Thu, 9 Nov 2006 14:58:27 -0500 (EST) From: sandy@tislabs.com (Sandy Murphy) X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: sandy@tislabs.com Subject: [Sidr] list of signatures in ROAs 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 not the way that a PKI would be expected to work, in general. >A signer of data cannot in general know what TAs RPs may select, so >it is not incumbent on a signer to try to provide multiple signatures >to accommodate this uncertainty. (This isn't a matter for the minutes, since it wasn't mentioned in the meeting. So I changed the subject.) So you are saying that there is no need for the list of signatures in the ROA that Brian Weiss was showing? Suppose there were a small handful of commonly used trust anchors Would you then say that a list of signatures made sense? (Obviously, if there were a wild plethora of trust anchors in use, trying to list all needed ones would be infeasible. And we don't know which will be the case.) Having a list of single signature ROAs works as well as a single ROA with a list of signatures, I believe. So this is not a functional difference, more an engineering decision. --Sandy _______________________________________________ Sidr mailing list Sidr@ietf.org https://www1.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Thu Nov 09 16:16:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiHG6-0004Kf-Qz; Thu, 09 Nov 2006 16:16:26 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiHG5-0004K7-62 for sidr@ietf.org; Thu, 09 Nov 2006 16:16:25 -0500 Received: from mx11.bbn.com ([128.33.0.80]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GiHG3-00047f-VC for sidr@ietf.org; Thu, 09 Nov 2006 16:16:25 -0500 Received: from dommiel.bbn.com ([192.1.122.15] helo=[130.129.67.141]) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1GiHG1-0003MX-4d; Thu, 09 Nov 2006 16:16:21 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: <20061109195827.0FB9A3F462@pecan.tislabs.com> References: <20061109195827.0FB9A3F462@pecan.tislabs.com> Date: Thu, 9 Nov 2006 16:14:30 -0500 To: sandy@tislabs.com (Sandy Murphy) From: Stephen Kent Subject: Re: [Sidr] list of signatures in ROAs Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: sandy@tislabs.com, 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 2:58 PM -0500 11/9/06, Sandy Murphy wrote: > >This is not the way that a PKI would be expected to work, in general. >>A signer of data cannot in general know what TAs RPs may select, so >>it is not incumbent on a signer to try to provide multiple signatures >>to accommodate this uncertainty. > >(This isn't a matter for the minutes, since it wasn't mentioned in >the meeting. So I changed the subject.) > >So you are saying that there is no need for the list of signatures >in the ROA that Brian Weiss was showing? not for the reasons cited in your message. >Suppose there were a small handful of commonly used trust anchors >Would you then say that a list of signatures made sense? well, if the list is "commonly used" then you could pick any one, right :-)? >(Obviously, if there were a wild plethora of trust anchors in use, >trying to list all needed ones would be infeasible. >And we don't know which will be the case.) right. >Having a list of single signature ROAs works as well as a single ROA >with a list of signatures, I believe. So this is not a functional >difference, more an engineering decision. I still think this is the wrong model. The original rationale for multiple signatures for a ROA was NOT to accommodate multiple TAs, but rather to accommodate a ROA that contained prefixes acquired from multiple sources, and thus no EE cert could be created that merged these prefixes (due to RFC 3779 constraints). Thus there may still be a good basis for supporting multiple signatures for a ROA, if we want to allow a ROA to contain prefixes. However, if we become comfortable with the notion that one should just create multiple ROAs in these circumstances, we can live with a single signature ROA syntax. This also would obviate a security issue Geoff raised, i.e., stripping a signature from a ROA. Steve _______________________________________________ Sidr mailing list Sidr@ietf.org https://www1.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Thu Nov 09 18:18:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiJ9k-0002ba-2B; Thu, 09 Nov 2006 18:18:00 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiJ9i-0002a8-6L for sidr@ietf.org; Thu, 09 Nov 2006 18:17:58 -0500 Received: from ns1.tislabs.com ([192.94.214.100] helo=nutshell.tislabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GiJ9g-0003uI-Vu for sidr@ietf.org; Thu, 09 Nov 2006 18:17:58 -0500 Received: (from uucp@localhost) by nutshell.tislabs.com (8.12.9/8.12.9) id kA9NBTDw013634; Thu, 9 Nov 2006 18:11:29 -0500 (EST) Received: from pecan.tislabs.com(10.66.1.30) by nutshell.tislabs.com via csmap (V6.0) id srcAAANzaqxA; Thu, 9 Nov 06 18:09:25 -0500 Received: by pecan.tislabs.com (Postfix, from userid 2005) id D77B43F411; Thu, 9 Nov 2006 18:09:19 -0500 (EST) To: kent@bbn.com, sandy@tislabs.com Subject: Re: [Sidr] list of signatures in ROAs In-Reply-To: Message-Id: <20061109230919.D77B43F411@pecan.tislabs.com> Date: Thu, 9 Nov 2006 18:09:19 -0500 (EST) From: sandy@tislabs.com (Sandy Murphy) X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 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 >>Suppose there were a small handful of commonly used trust anchors >>Would you then say that a list of signatures made sense? > >well, if the list is "commonly used" then you could pick any one, right :-)? I meant suppose there were a set of TAs that covered the TAs that were commonly used. Not that common use was to use the entire set. >I still think this is the wrong model. The original rationale for >multiple signatures for a ROA was NOT to accommodate multiple TAs, >but rather to accommodate a ROA that contained prefixes acquired from >multiple sources, and thus no EE cert could be created that merged >these prefixes (due to RFC 3779 constraints). That is a different answer than was given in the meeting, but it is an answer I had half expected. The question then becomes whether we have to relate each signature to the prefixes it covers, or whether we are OK with a validation rule that as long as the stated prefixes are completely covered by the union of the prefixes associated with the signatures, the ROA is valid. --Sandy _______________________________________________ Sidr mailing list Sidr@ietf.org https://www1.ietf.org/mailman/listinfo/sidr