From sidr-bounces@ietf.org Tue Nov 01 12:53:24 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EX0K4-0006v7-2j; Tue, 01 Nov 2005 12:53:24 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EX0K0-0006sL-B3 for sidr@megatron.ietf.org; Tue, 01 Nov 2005 12:53:20 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04863 for ; Tue, 1 Nov 2005 12:52:58 -0500 (EST) Received: from kahuna.telstra.net ([203.50.0.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EX0YP-0002HW-Io for sidr@ietf.org; Tue, 01 Nov 2005 13:08:15 -0500 Received: from gihm3.apnic.net (dhcp18.potaroo.net [203.10.60.18]) by kahuna.telstra.net (8.12.3/8.11.3) with ESMTP id jA1HqPXt011293 for ; Wed, 2 Nov 2005 04:52:27 +1100 (EST) (envelope-from gih@apnic.net) Message-Id: <6.2.0.14.2.20051102045148.02a7cb88@kahuna.telstra.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14 Date: Wed, 02 Nov 2005 04:52:25 +1100 To: sidr@ietf.org From: Geoff Huston Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed Subject: [Sidr] SIDR BOF agenda for IETF 64 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: , Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org The agenda is available at: http://www3.ietf.org/proceedings/05nov/agenda/sidr.html thanks, Geoff _______________________________________________ Sidr mailing list Sidr@ietf.org https://www1.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Thu Nov 10 10:52:43 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EaEjD-0001Ha-Qk; Thu, 10 Nov 2005 10:52:43 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EaEjD-0001Fi-3j for sidr@megatron.ietf.org; Thu, 10 Nov 2005 10:52:43 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11917 for ; Thu, 10 Nov 2005 10:52:14 -0500 (EST) Received: from netcore.fi ([193.94.160.1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EaEzQ-00063b-Ko for sidr@ietf.org; Thu, 10 Nov 2005 11:09:30 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id jAAFqLi24928 for ; Thu, 10 Nov 2005 17:52:21 +0200 Date: Thu, 10 Nov 2005 17:52:21 +0200 (EET) From: Pekka Savola To: sidr@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Subject: [Sidr] a reminder on operator requirements 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: , Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org Hi, Food for thought before the BOF. Unless the operational requirements are suitably well considered from the start, we don't accomplish anything as the solution will not be deployed. So, with my operator hat on, let me provide a couple for starters: 1) No configuration required: this must not add significant amount of config/management on the routers. 2) No observable impact on processing: the route convergence or processing delays must not be observable. 3) No new hardware on routers: the solution must not require adding new hardware (e.g., crypto hardware) on all the routers; it may be acceptable to have it on one or two, but no more than that. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ Sidr mailing list Sidr@ietf.org https://www1.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Fri Nov 11 09:21:11 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EaZmB-00046p-6h; Fri, 11 Nov 2005 09:21:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EaZgl-0002wC-6O for sidr@megatron.ietf.org; Fri, 11 Nov 2005 09:15:35 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06884 for ; Fri, 11 Nov 2005 09:15:04 -0500 (EST) Received: from kahuna.telstra.net ([203.50.0.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EaZch-0005Ma-57 for sidr@ietf.org; Fri, 11 Nov 2005 09:11:24 -0500 Received: from gihm3.apnic.net (kahuna.telstra.net [203.50.0.6]) by kahuna.telstra.net (8.12.3/8.11.3) with ESMTP id jABDrbXt030846 for ; Sat, 12 Nov 2005 00:53:39 +1100 (EST) (envelope-from gih@apnic.net) Message-Id: <6.2.0.14.2.20051112004928.02f03b90@localhost> X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14 Date: Sat, 12 Nov 2005 00:53:35 +1100 To: sidr@ietf.org From: Geoff Huston Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Subject: [Sidr] Summary of the SIDR BOF 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: , Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org Thanks to all those who participated in the SIDR BOF. Presentations made at the BOF have now been uploaded tot he IETF Proceedings page, and minutes are being prepared. The following has been passed to the ADs as a summary of the BOF. Geoff ==== SIDR SUMMARY The BOF reviewed the current status of RPSEC, and the current state of design activity in the area of secure inter-domain frameworks. The proposition was advanced that while RPSEC has not concluded as yet, there is sufficient impetus to commence work on infrastructure and protocol support mechanisms intended to address aspects of securing inter-domain routing. The specific area where there has been clear agreement in the requirements specification activity is that of authentication of route origination. The proposed work would include consideration of the relevant certificate infrastructure to support information validation. It was noted that the outcomes of this activity should be capable of supporting hierarchical rooted PKI models as well as decentralized "web of trust" models if at all possible, as the intended scope of application of this framework encompasses a broad diversity of deployment environments. There was support from the BOF attendees for the aspects of the work where there is clear agreement on requirements, concerning authentication of route origination information and use of associated certificate frameworks, to be undertaken immediately. The question of charter scope was considered and the rough consensus in the BOF was to support a charter that encompassed a more comprehensive security framework for inter-domain routing, but with a caveat that commencement on any particular component of the work would be conditional on clear agreement on requirements from the RPSEC Working Group. Next steps are to draft a charter and associated milestones for this work for IESG review. _______________________________________________ Sidr mailing list Sidr@ietf.org https://www1.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Fri Nov 11 10:57:06 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EabH0-0005qO-5u; Fri, 11 Nov 2005 10:57:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EabGy-0005qJ-Vf for sidr@megatron.ietf.org; Fri, 11 Nov 2005 10:57:05 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14927 for ; Fri, 11 Nov 2005 10:56:36 -0500 (EST) Received: from kahuna.telstra.net ([203.50.0.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EabXP-0001Fq-IE for sidr@ietf.org; Fri, 11 Nov 2005 11:14:05 -0500 Received: from gihm3.apnic.net (kahuna.telstra.net [203.50.0.6]) by kahuna.telstra.net (8.12.3/8.11.3) with ESMTP id jABFu8Xt033221; Sat, 12 Nov 2005 02:56:10 +1100 (EST) (envelope-from gih@apnic.net) Message-Id: <6.2.0.14.2.20051112025129.02b3bdf8@localhost> X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14 Date: Sat, 12 Nov 2005 02:56:07 +1100 To: sidr@ietf.org From: Geoff Huston Subject: Re: [Sidr] a reminder on operator requirements In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) 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: , Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org A first pass of the minutes of the SIDR BOF can be found at https://onsite.ietf.org/public/meeting_materials.cgi?meeting_num=64 (look for SIDR BIF in the Routing Area) comments & corrections welcome thanks, Geoff _______________________________________________ Sidr mailing list Sidr@ietf.org https://www1.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Fri Nov 11 11:14:21 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EabXh-0002U3-Ex; Fri, 11 Nov 2005 11:14:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EabXg-0002Ty-Fc for sidr@megatron.ietf.org; Fri, 11 Nov 2005 11:14:20 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16274 for ; Fri, 11 Nov 2005 11:13:51 -0500 (EST) Received: from kahuna.telstra.net ([203.50.0.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Eabo8-00025i-5Q for sidr@ietf.org; Fri, 11 Nov 2005 11:31:20 -0500 Received: from gihm3.apnic.net (kahuna.telstra.net [203.50.0.6]) by kahuna.telstra.net (8.12.3/8.11.3) with ESMTP id jABGE7Xt033598 for ; Sat, 12 Nov 2005 03:14:09 +1100 (EST) (envelope-from gih@apnic.net) Message-Id: <6.2.0.14.2.20051112031331.044471f8@localhost> X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14 Date: Sat, 12 Nov 2005 03:14:06 +1100 To: sidr@ietf.org From: Geoff Huston Subject: Re: [Sidr] a reminder on operator requirements In-Reply-To: <6.2.0.14.2.20051112025129.02b3bdf8@localhost> References: <6.2.0.14.2.20051112025129.02b3bdf8@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 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: , Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org s/BIF/BOF/ :-) geoff At 02:56 AM 12/11/2005, Geoff Huston wrote: >A first pass of the minutes of the SIDR BOF can be found at > >https://onsite.ietf.org/public/meeting_materials.cgi?meeting_num=64 > >(look for SIDR BIF in the Routing Area) > >comments & corrections welcome > >thanks, > > 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 Fri Nov 25 15:46:47 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EfkT1-0003Wh-Cc; Fri, 25 Nov 2005 15:46:47 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EfkSz-0003Wc-Nz for sidr@megatron.ietf.org; Fri, 25 Nov 2005 15:46:45 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15005 for ; Fri, 25 Nov 2005 15:46:04 -0500 (EST) Received: from kahuna.telstra.net ([203.50.0.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EfkmK-0005eE-1Q for sidr@ietf.org; Fri, 25 Nov 2005 16:06:44 -0500 Received: from gihm3.apnic.net (dhcp5.potaroo.net [203.10.60.5]) by kahuna.telstra.net (8.12.3/8.11.3) with ESMTP id jAPKkLXt014449; Sat, 26 Nov 2005 07:46:23 +1100 (EST) (envelope-from gih@apnic.net) Message-Id: <6.2.0.14.2.20051126074145.0301c218@kahuna.telstra.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14 Date: Sat, 26 Nov 2005 07:46:20 +1100 To: sidr@ietf.org From: Geoff Huston In-Reply-To: <6.2.0.14.2.20051112031331.044471f8@localhost> References: <6.2.0.14.2.20051112025129.02b3bdf8@localhost> <6.2.0.14.2.20051112031331.044471f8@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 944ecb6e61f753561f559a497458fb4f Cc: Subject: [Sidr] initial draft of SIDR Charter 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: , Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org Hi, At the SIDR BOF the ADs asked for a draft charter to be prepared by the end of November. I realize that time is getting close now, and I've prepared the following. I trust it encompasses the considerations mentioned at the BOF, and provides a reasonable framework for moving forward on this topic. Please have a look over it and provide any comments to the list (or directly to me if you prefer) and I'll post revisions as appropriate. I'd like to get this completed and shipped to the ADs in as final format by the _30th November_ so please send me any comments as soon as you can! many thanks, Geoff =================== DRAFT (26/11/05) Secure Inter-Domain Routing (sidr) Chair(s): TBD Routing Area Director(s): Bill Fenner Alex Zinin Routing Area Advisor: TBD Other Advisors: ? Security: TBD ? Routing: TBD Mailing Lists: General Discussion: sidr@ietf.org To Subscribe: sidr-request@ietf.org In Body: (un)subscribe Archive: http://www.ietf.org/mail-archive/web/sidr/index.html Description of Working Group: One of the areas of vulnerability for large scale Internet environments lies in the area of inter-domain routing. The basic security questions that can be posed regarding routing information is that of the validity of the address prefix being advertised, the validity of the originating Autonomous System Number, and the existence of an explicit permission from the address prefix holder to allow the prefix to be advertised from this origin. A related question concerns the level of trust than can be ascribed to attributes of a routed object in terms of their authenticity. The Routing Protocol Security Group (RPSEC) has been chartered to document the security requirements for routing systems, and, in particular, to produce a document on BGP security requirements. The scope of work in the SIDR working group is to formulate an extensible interdomain routing security architecture that is capable of supporting incremental additions to a security framework for interdomain routing. As and when interdomain routing security requirements are completed within the RPSEC Working Group, these requirements will be defined within the SIDR framework as functional components of a secure interdomain routing system. The scope or work will include the definition of certification objects that can be used to support the distribution of authentication information. Both strict hierarchical and distributed non-hierarchical trust systems are intended to be supported within this framework. The scope of work is limited to inter-domain router-to-router protocols only for both unicast and multicast systems. The SIDR working group is charged with the following tasks: - Document an extensible interdomain routing security architecture - Document the certification objects to be used by this secure routing framework - Document specific routing functionality modules with this architecture designed to address specific secure routing requirements as they are determined by the RPSEC Working Group Goals and Milestones: April-06 Submit initial draft on inter-domain routing security architecture May-06 Submit initial draft on certificate objects to be used within this framework May-06 Submit initial draft on securing origination of routing information Sept-06 Submit routing security architecture for publication as an Informational RFC Nov-06 Submit definition of certificate objectes to be used as a Proposed Standard Dec-06 Submit secure origination mechanism as a Proposed Standard Jan-06 Evaluate progress, recharter with new goals or shutdown. _______________________________________________ Sidr mailing list Sidr@ietf.org https://www1.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Fri Nov 25 20:36:59 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Efozr-0001Te-6u; Fri, 25 Nov 2005 20:36:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Efozq-0001TZ-MT for sidr@megatron.ietf.org; Fri, 25 Nov 2005 20:36:58 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA11955 for ; Fri, 25 Nov 2005 20:36:16 -0500 (EST) Received: from sokol.elan.net ([216.151.192.200]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EfpJB-0006KB-Qg for sidr@ietf.org; Fri, 25 Nov 2005 20:57:00 -0500 Received: from sokol.elan.net (sokol [127.0.0.1]) by sokol.elan.net (8.13.1/8.13.1) with ESMTP id jAQ1aZkg027045; Fri, 25 Nov 2005 17:36:35 -0800 Received: from localhost (william@localhost) by sokol.elan.net (8.13.1/8.13.1/Submit) with ESMTP id jAQ1aQJ0027042; Fri, 25 Nov 2005 17:36:35 -0800 X-Authentication-Warning: sokol.elan.net: william owned process doing -bs Date: Fri, 25 Nov 2005 17:36:26 -0800 (PST) From: "william(at)elan.net" To: Geoff Huston Subject: Re: [Sidr] initial draft of SIDR Charter In-Reply-To: <6.2.0.14.2.20051126074145.0301c218@kahuna.telstra.net> Message-ID: References: <6.2.0.14.2.20051112025129.02b3bdf8@localhost> <6.2.0.14.2.20051112031331.044471f8@localhost> <6.2.0.14.2.20051126074145.0301c218@kahuna.telstra.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 29dc808194f5fb921c09d0040806d6eb 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: , Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org On Sat, 26 Nov 2005, Geoff Huston wrote: > Hi, > > At the SIDR BOF the ADs asked for a draft charter to be prepared by the end > of November. I realize that time is getting close now, and I've prepared the > following. I trust it encompasses the considerations mentioned at the BOF, > and provides a reasonable framework for moving forward on this topic. > > Please have a look over it and provide any comments to the list (or directly > to me if you prefer) and I'll post revisions as appropriate. I'd like to get > this completed and shipped to the ADs in as final format by the _30th > November_ so please send me any comments as soon as you can! > > many thanks, > > Geoff > > > =================== > > DRAFT (26/11/05) > Secure Inter-Domain Routing (sidr) > > Chair(s): > TBD > > Routing Area Director(s): > Bill Fenner > Alex Zinin I guess its close to 50/50 in both routing ad security, but to me it seems we'd be doing more security then routing, so maybe this should be under security area or at least as special case have both routing and security area directors overseeing the effort. > Routing Area Advisor: > TBD > > Other Advisors: > ? Security: TBD > ? Routing: TBD > > Mailing Lists: > General Discussion: sidr@ietf.org > To Subscribe: sidr-request@ietf.org > In Body: (un)subscribe > Archive: http://www.ietf.org/mail-archive/web/sidr/index.html > > Description of Working Group: > > One of the areas of vulnerability for large scale Internet environments > lies in the area of inter-domain routing. The basic security questions that > can be posed regarding routing information is that of the validity of the > address prefix being advertised, the validity of the originating Autonomous > System Number, and the existence of an explicit permission from the address > prefix holder to allow the prefix to be advertised from this origin. Above is ok (small pick at "this" - maybe replace with "given"). One note is that it is unclear if system will deal only with the very first origin ASN's permission to advertise the prefix or would also deal with transit/peer relationships (ASN->ASN permission to advertise prefix). > A > related question concerns the level of trust than can be ascribed to > attributes of a routed object in terms of their authenticity. The above is not clear to me, maybe more specific about what attributes. > The Routing Protocol Security Group (RPSEC) has been chartered to document > the security requirements for routing systems, and, in particular, to > produce a document on BGP security requirements. > > The scope of work in the SIDR working group is to formulate an extensible > interdomain routing security architecture that is capable of supporting > incremental additions to a security framework for interdomain routing. As > and when interdomain routing security requirements are completed within the > RPSEC Working Group, these requirements will be defined within the SIDR > framework as functional components of a secure interdomain routing system. I'm not sure of above. It seems to make start of the work in SIDR dependent upon completion of the work within another WG. While I agree on it in principle, what it means to me is that SIDR can not be formed until those requirements are ready. When the requirements are ready that would mean charter text for SIDR could directly reference requirements document rather then to reference that RPSEC would produce the document. > The scope or work will include the definition of certification objects > that can be used to support the distribution of authentication information. > Both strict hierarchical and distributed non-hierarchical trust systems are > intended to be supported within this framework. Both? I think this is too strict in requiring final system that can support both at the same time where as this may not be achievable. How about changing this to something like: "Both strict hierarchical and distributed non-hierarchical trust systems are within scope of work and either one or both (if possible) will be supported in the final framework" > The scope of work is limited to inter-domain router-to-router protocols > only for both unicast and multicast systems. > > The SIDR working group is charged with the following tasks: > > - Document an extensible interdomain routing security architecture > > - Document the certification objects to be used by this secure > routing framework > > - Document specific routing functionality modules with this > architecture designed to address specific secure routing requirements as > they are determined by the RPSEC Working Group Is documenting how to exchange the certification objects (and how to publish them in the first place) fits within one of the above? > Goals and Milestones: > > April-06 Submit initial draft on inter-domain routing security > architecture > > May-06 Submit initial draft on certificate objects to be used > within this framework > > May-06 Submit initial draft on securing origination of routing > information > > Sept-06 Submit routing security architecture for publication as an > Informational RFC > > Nov-06 Submit definition of certificate objectes to be used as a > Proposed Standard > > Dec-06 Submit secure origination mechanism as a Proposed Standard > > Jan-06 Evaluate progress, recharter with new goals or shutdown. Typo above - should be "Jan-07". In general I think above schedule of less then one year is too aggressive - IETF does not seem to have very many examples of WGs being able to produce such a substantial work within this short period of time. -- William Leibzon Elan Networks william@elan.net _______________________________________________ Sidr mailing list Sidr@ietf.org https://www1.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Sat Nov 26 12:52:04 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eg4DU-0005e5-RU; Sat, 26 Nov 2005 12:52:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eg4DT-0005e0-PV for sidr@megatron.ietf.org; Sat, 26 Nov 2005 12:52:04 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09215 for ; Sat, 26 Nov 2005 12:51:21 -0500 (EST) Received: from kahuna.telstra.net ([203.50.0.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Eg4Ww-0001c7-5J for sidr@ietf.org; Sat, 26 Nov 2005 13:12:13 -0500 Received: from gihm3.apnic.net (dhcp5.potaroo.net [203.10.60.5]) by kahuna.telstra.net (8.12.3/8.11.3) with ESMTP id jAQHoqXt081804; Sun, 27 Nov 2005 04:50:53 +1100 (EST) (envelope-from gih@apnic.net) Message-Id: <6.2.0.14.2.20051127043332.0305c0a8@kahuna.telstra.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14 Date: Sun, 27 Nov 2005 04:50:54 +1100 To: "william(at)elan.net" From: Geoff Huston Subject: Re: [Sidr] initial draft of SIDR Charter In-Reply-To: References: <6.2.0.14.2.20051112025129.02b3bdf8@localhost> <6.2.0.14.2.20051112031331.044471f8@localhost> <6.2.0.14.2.20051126074145.0301c218@kahuna.telstra.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b6657e60309a1317174c9db2ae5f227 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: , Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org Thanks for this response - I'll revise the charter with these comments in mind. I'd like to make a few clarifying comments in response: - the work is in the routing area because ultimately it it a routing protocol that we are working on. Personally I'm not concerned about this at all - I know the security ADs and the security area folk are keenly interested in this activity and we will have the benefit of their perspectives as we progress. I did leave space in the charter for a security advisor to the wg to ensure that we can get specific advice as required. - the transit/peer issues you raise are not in the area of concluded (agreed) requirements from the RPSEC WG - as and when they complete their requirements the SIDR WG will take on the work. - the reliance on RPSEC outputs was a fundamental part of the SIDR charter according to the RPSEC charter and the SIDR BOF (see the minutes from the BOF at IETF-64).The BOF discussed the option you put forward in your comments and the general consensus in the room was to encompass in the charter the broader set of work and explicitly note that embarking on any part of the work was conditional of RPSEC outcomes. I have drafted the charter in accordance with that approach. - the requirement for supporting both strict hierarchical and distributed trust models was a clear outcome of the BOF. The assertion was made in a number of presentations in the BOF that both forms of trust models are degenerate cases of the other. It appears that while the public Internet may well benefit for a hierarchy of trust there are other inter-domain routing environments that use a distributed trust model. I understood from the BOF sessions that there was no desire to 'pick one', but to head in a direction that defined a standard technology that could encompass various trust models. - and yes, the schedule is aggressive. On the other hand, RPSEC has done all the requirements work, there is a certain amount of impatience in getting some progress in the IETF in this area, and I see a number of folk who are keen to contribute, so I am confident that it is possible to complete the documents in this timeframe. regards, Geoff At 12:36 PM 26/11/2005, william(at)elan.net wrote: >On Sat, 26 Nov 2005, Geoff Huston wrote: > >>Hi, >> >>At the SIDR BOF the ADs asked for a draft charter to be prepared by the >>end of November. I realize that time is getting close now, and I've >>prepared the following. I trust it encompasses the considerations >>mentioned at the BOF, and provides a reasonable framework for moving >>forward on this topic. >> >>Please have a look over it and provide any comments to the list (or >>directly to me if you prefer) and I'll post revisions as appropriate. I'd >>like to get this completed and shipped to the ADs in as final format by >>the _30th November_ so please send me any comments as soon as you can! >> >>many thanks, >> >> Geoff >> >> >>=================== >> >>DRAFT (26/11/05) >>Secure Inter-Domain Routing (sidr) >> >>Chair(s): >> TBD >> >>Routing Area Director(s): >> Bill Fenner >> Alex Zinin > >I guess its close to 50/50 in both routing ad security, but to me it >seems we'd be doing more security then routing, so maybe this should >be under security area or at least as special case have both routing >and security area directors overseeing the effort. > >>Routing Area Advisor: >> TBD >> >>Other Advisors: >> ? Security: TBD >> ? Routing: TBD >> >>Mailing Lists: >> General Discussion: sidr@ietf.org >> To Subscribe: sidr-request@ietf.org >> In Body: (un)subscribe >> Archive: http://www.ietf.org/mail-archive/web/sidr/index.html >> >>Description of Working Group: >> >>One of the areas of vulnerability for large scale Internet environments >>lies in the area of inter-domain routing. The basic security questions >>that can be posed regarding routing information is that of the validity >>of the address prefix being advertised, the validity of the originating >>Autonomous System Number, and the existence of an explicit permission >>from the address prefix holder to allow the prefix to be advertised from >>this origin. > >Above is ok (small pick at "this" - maybe replace with "given"). >One note is that it is unclear if system will deal only with the very >first origin ASN's permission to advertise the prefix or would also deal >with transit/peer relationships (ASN->ASN permission to advertise prefix). > >>A related question concerns the level of trust than can be ascribed to >>attributes of a routed object in terms of their authenticity. > >The above is not clear to me, maybe more specific about what attributes. > >>The Routing Protocol Security Group (RPSEC) has been chartered to >>document the security requirements for routing systems, and, in >>particular, to produce a document on BGP security requirements. >> >>The scope of work in the SIDR working group is to formulate an extensible >>interdomain routing security architecture that is capable of supporting >>incremental additions to a security framework for interdomain routing. As >>and when interdomain routing security requirements are completed within >>the RPSEC Working Group, these requirements will be defined within the >>SIDR framework as functional components of a secure interdomain routing system. > >I'm not sure of above. It seems to make start of the work in SIDR >dependent upon completion of the work within another WG. While I agree >on it in principle, what it means to me is that SIDR can not be formed >until those requirements are ready. When the requirements are ready that >would mean charter text for SIDR could directly reference requirements >document rather then to reference that RPSEC would produce the document. > >>The scope or work will include the definition of certification objects >>that can be used to support the distribution of authentication >>information. Both strict hierarchical and distributed non-hierarchical >>trust systems are intended to be supported within this framework. > >Both? I think this is too strict in requiring final system that can >support both at the same time where as this may not be achievable. > >How about changing this to something like: >"Both strict hierarchical and distributed non-hierarchical trust systems > are within scope of work and either one or both (if possible) will be > supported in the final framework" > >>The scope of work is limited to inter-domain router-to-router protocols >>only for both unicast and multicast systems. >> >> The SIDR working group is charged with the following tasks: >> >> - Document an extensible interdomain routing security architecture >> >> - Document the certification objects to be used by this secure >> routing framework >> >> - Document specific routing functionality modules with this >> architecture designed to address specific secure routing requirements >> as they are determined by the RPSEC Working Group > >Is documenting how to exchange the certification objects (and how to >publish them in the first place) fits within one of the above? > >>Goals and Milestones: >> >>April-06 Submit initial draft on inter-domain routing security >> architecture >> >>May-06 Submit initial draft on certificate objects to be used >> within this framework >> >>May-06 Submit initial draft on securing origination of routing >> information >> >>Sept-06 Submit routing security architecture for publication as an >> Informational RFC >> >>Nov-06 Submit definition of certificate objectes to be used as a >> Proposed Standard >> >>Dec-06 Submit secure origination mechanism as a Proposed Standard >> >>Jan-06 Evaluate progress, recharter with new goals or shutdown. > >Typo above - should be "Jan-07". > >In general I think above schedule of less then one year is too aggressive - >IETF does not seem to have very many examples of WGs being able to produce >such a substantial work within this short period of time. > >-- >William Leibzon >Elan Networks >william@elan.net _______________________________________________ Sidr mailing list Sidr@ietf.org https://www1.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Sun Nov 27 08:18:52 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EgMQe-0006GT-4w; Sun, 27 Nov 2005 08:18:52 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EgMQc-0006FI-2v for sidr@megatron.ietf.org; Sun, 27 Nov 2005 08:18:50 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA12645 for ; Sun, 27 Nov 2005 08:18:06 -0500 (EST) Received: from eikenes.alvestrand.no ([158.38.152.233]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EgMb9-00038H-AC for sidr@ietf.org; Sun, 27 Nov 2005 08:29:43 -0500 Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 9C11825973D; Sun, 27 Nov 2005 14:08:38 +0100 (CET) Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 23893-04; Sun, 27 Nov 2005 14:08:34 +0100 (CET) Received: from [192.168.1.160] (163.80-203-220.nextgentel.com [80.203.220.163]) by eikenes.alvestrand.no (Postfix) with ESMTP id 6589325973C; Sun, 27 Nov 2005 14:08:34 +0100 (CET) Date: Sun, 27 Nov 2005 14:11:07 +0100 From: Harald Tveit Alvestrand To: Geoff Huston , sidr@ietf.org Subject: Re: [Sidr] initial draft of SIDR Charter Message-ID: In-Reply-To: <6.2.0.14.2.20051126074145.0301c218@kahuna.telstra.net> References: <6.2.0.14.2.20051112025129.02b3bdf8@localhost> <6.2.0.14.2.20051112031331.044471f8@localhost> <6.2.0.14.2.20051126074145.0301c218@kahuna.telstra.net> X-Mailer: Mulberry/3.1.6 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Virus-Scanned: by amavisd-new at alvestrand.no X-Spam-Score: 0.0 (/) X-Scan-Signature: 2086112c730e13d5955355df27e3074b Content-Transfer-Encoding: 7bit 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: , Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org language/clarity comments..... > DRAFT (26/11/05) > Secure Inter-Domain Routing (sidr) > > Chair(s): > TBD > > Routing Area Director(s): > Bill Fenner > Alex Zinin > > Routing Area Advisor: > TBD > > Other Advisors: > ? Security: TBD > ? Routing: TBD > > Mailing Lists: > General Discussion: sidr@ietf.org > To Subscribe: sidr-request@ietf.org > In Body: (un)subscribe > Archive: http://www.ietf.org/mail-archive/web/sidr/index.html > > Description of Working Group: > > One of the areas of vulnerability for large scale Internet > environments lies in the area of inter-domain routing. The basic security > questions that can be posed regarding routing information is that of the > validity of the address prefix being advertised, the validity of the > originating Autonomous System Number, and the existence of an explicit > permission from the address prefix holder to allow the prefix to be > advertised from this origin. A related question concerns the level of > trust than can be ascribed to attributes of a routed object in terms of > their authenticity. I think this section may be detailed... the BASIC question that should be asked in routing is "if I believe this information, will the result be what I want it to be" - but authenticity of the information is usually a good start.... unless others have alternative language to propose, this is OK. Q: should "a routed object" be "a routing information object" or "an object passed in a routing protocol"? To me, "a routed object" is a packet, and that doesn't seem to make sense.... > > The Routing Protocol Security Group (RPSEC) has been chartered to > document the security requirements for routing systems, and, in > particular, to produce a document on BGP security requirements. > > The scope of work in the SIDR working group is to formulate an > extensible interdomain routing security architecture that is capable of > supporting incremental additions to a security framework for interdomain > routing. I got lost in that sentence.... what about: The scope of work in the SIDR working group is to formulate an extensible architecture for an interdomain routing security framework. This framework must be capable of supporting incremental additions of new functional components, but should at the outset be capable of supporting the security functions described . > As and when interdomain routing security requirements are > completed within the RPSEC Working Group, these requirements will be > defined within the SIDR framework as functional components of a secure > interdomain routing system. > > The scope or work will include the definition of certification objects > that can be used to support the distribution of authentication > information. Both strict hierarchical and distributed non-hierarchical > trust systems are intended to be supported within this framework. Q: Does the work involve revisiting RFC 3779 AS number/address range certs, using these certs, or ignoring these certs and do something completely different? > The scope of work is limited to inter-domain router-to-router > protocols only for both unicast and multicast systems. > > The SIDR working group is charged with the following tasks: > > - Document an extensible interdomain routing security architecture > > - Document the certification objects to be used by this secure > routing framework "secure routing architecture", for consistency with the sentence above? > - Document specific routing functionality modules with this s/with/within/? > architecture designed to address specific secure routing > requirements as they are determined by the RPSEC Working Group > > Goals and Milestones: > > April-06 Submit initial draft on inter-domain routing security > architecture > > May-06 Submit initial draft on certificate objects to be used > within this framework -> "architecture"? > > May-06 Submit initial draft on securing origination of routing > information > > Sept-06 Submit routing security architecture for publication as an > Informational RFC > > Nov-06 Submit definition of certificate objectes to be used as a > Proposed Standard > > Dec-06 Submit secure origination mechanism as a Proposed Standard Suggest using exactly the same words to describe the documents in each milestone that refers to them. Saves confusion. > > Jan-06 Evaluate progress, recharter with new goals or shutdown. No more comments.... _______________________________________________ Sidr mailing list Sidr@ietf.org https://www1.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Sun Nov 27 15:20:56 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EgT16-0001dt-EA; Sun, 27 Nov 2005 15:20:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EgT14-0001dj-Ky for sidr@megatron.ietf.org; Sun, 27 Nov 2005 15:20:54 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24339 for ; Sun, 27 Nov 2005 15:20:10 -0500 (EST) Received: from kahuna.telstra.net ([203.50.0.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EgTKn-0008AL-Kf for sidr@ietf.org; Sun, 27 Nov 2005 15:41:18 -0500 Received: from gihm3.apnic.net (dhcp5.potaroo.net [203.10.60.5]) by kahuna.telstra.net (8.12.3/8.11.3) with ESMTP id jARKK1Xv005089 for ; Mon, 28 Nov 2005 07:20:03 +1100 (EST) (envelope-from gih@apnic.net) Message-Id: <6.2.0.14.2.20051128071901.02aeefd0@kahuna.telstra.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14 Date: Mon, 28 Nov 2005 07:19:53 +1100 To: sidr@ietf.org From: Geoff Huston In-Reply-To: References: <6.2.0.14.2.20051112025129.02b3bdf8@localhost> <6.2.0.14.2.20051112031331.044471f8@localhost> <6.2.0.14.2.20051126074145.0301c218@kahuna.telstra.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db Subject: [Sidr] V2 draft of SIDR Charter 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: , Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org Secure Inter-Domain Routing (sidr) Last Modified: 2005-11-28 Chair(s): TBD Routing Area Director(s): Bill Fenner Alex Zinin Routing Area Advisor: TBD Other Advisors: ? Security: TBD ? Routing: TBD Mailing Lists: General Discussion: sidr@ietf.org To Subscribe: sidr-request@ietf.org In Body: (un)subscribe Archive: http://www.ietf.org/mail-archive/web/sidr/index.html Description of Working Group: One of the areas of vulnerability for large scale Internet environments lies in the area of inter-domain routing. The basic security questions that can be posed regarding routing information is that of the validity of the address prefix being advertised, the validity of the originating Autonomous System Number, and the existence of an explicit permission from the address prefix holder to allow the prefix to be advertised from this origin. A related question concerns the level of trust than can be ascribed to attributes of a routed object in terms of their authenticity, including consideration of the AS Path attribute.. The Routing Protocol Security Group (RPSEC) has been chartered to document the security requirements for routing systems, and, in particular, to produce a document on BGP security requirements. The scope of work in the SIDR working group is to formulate an extensible interdomain routing security architecture that is capable of supporting incremental additions to a security framework for interdomain routing. The scope of work in the SIDR working group is to formulate an extensible architecture for an interdomain routing security framework. This framework must be capable of supporting incremental additions of functional components. As and when interdomain routing security requirements are completed within the RPSEC Working Group, these requirements will be defined within the SIDR framework as functional components of a secure interdomain routing system. The scope or work will include the definition of certification objects that can be used to support the distribution of authentication information. Both strict hierarchical and distributed non-hierarchical trust systems are intended to be supported within this framework. The scope of work is limited to inter-domain router-to-router protocols only for both unicast and multicast systems. The SIDR working group is charged with the following tasks: - Document an extensible interdomain routing security architecture - Document the certification objects to be used by this secure routing architecture - Document specific routing functionality modules within this architecture that are designed to address specific secure routing requirements as they are determined by the RPSEC Working Group Goals and Milestones: April-06 Submit initial draft on inter-domain routing security architecture May-06 Submit initial draft on certificate objects to be used within this architecture May-06 Submit initial draft on securing origination of routing information Sept-06 Submit routing security architecture for publication as an Informational RFC Nov-06 Submit definition of certificate objectes to be used as a Proposed Standard Dec-06 Submit secure origination mechanism as a Proposed Standard Jan-07 Evaluate progress, recharter with new goals or shutdown. _______________________________________________ Sidr mailing list Sidr@ietf.org https://www1.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Sun Nov 27 15:20:57 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EgT17-0001eN-K4; Sun, 27 Nov 2005 15:20:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EgT16-0001do-1R for sidr@megatron.ietf.org; Sun, 27 Nov 2005 15:20:56 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24338 for ; Sun, 27 Nov 2005 15:20:10 -0500 (EST) Received: from kahuna.telstra.net ([203.50.0.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EgTKn-0008AX-Kj for sidr@ietf.org; Sun, 27 Nov 2005 15:41:18 -0500 Received: from gihm3.apnic.net (dhcp5.potaroo.net [203.10.60.5]) by kahuna.telstra.net (8.12.3/8.11.3) with ESMTP id jARKK1Xt005089; Mon, 28 Nov 2005 07:20:02 +1100 (EST) (envelope-from gih@apnic.net) Message-Id: <6.2.0.14.2.20051128070004.02b0b268@kahuna.telstra.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14 Date: Mon, 28 Nov 2005 07:19:00 +1100 To: Harald Tveit Alvestrand , sidr@ietf.org From: Geoff Huston Subject: Re: [Sidr] initial draft of SIDR Charter In-Reply-To: References: <6.2.0.14.2.20051112025129.02b3bdf8@localhost> <6.2.0.14.2.20051112031331.044471f8@localhost> <6.2.0.14.2.20051126074145.0301c218@kahuna.telstra.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 6640e3bbe8a4d70c4469bcdcbbf0921d 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: , Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org >> >> One of the areas of vulnerability for large scale Internet >>environments lies in the area of inter-domain routing. The basic security >>questions that can be posed regarding routing information is that of the >>validity of the address prefix being advertised, the validity of the >>originating Autonomous System Number, and the existence of an explicit >>permission from the address prefix holder to allow the prefix to be >>advertised from this origin. A related question concerns the level of >>trust than can be ascribed to attributes of a routed object in terms of >>their authenticity. > >I think this section may be detailed... the BASIC question that should be >asked in routing is "if I believe this information, will the result be >what I want it to be" - but authenticity of the information is usually a >good start.... unless others have alternative language to propose, this is OK. Personally I find the definition of "what I want it to be" a far more troublesome phrase to pin down!. I have not seen alternative language, and the language used here draws on many of the commentaries I've seen and heard on this topic. >Q: should "a routed object" be "a routing information object" or "an >object passed in a routing protocol"? To me, "a routed object" is a >packet, and that doesn't seem to make sense.... I thought about this and to me a "routed object" was the expression I was searching for. Its a relatively minor thing I admit but I was looking to describe the basic route object (the prefix) and distinguishing that from the attributes that a routing system may permit to be associated with the basic object. "an object passed in a routing protocol" is perhaps the best equivalent phrase, but for a WG charter text that's getting to be a bit of a mouthful isn't it! >> The scope of work in the SIDR working group is to formulate an >>extensible interdomain routing security architecture that is capable of >>supporting incremental additions to a security framework for interdomain >>routing. > >I got lost in that sentence.... what about: > >The scope of work in the SIDR working group is to formulate an extensible >architecture for an interdomain routing security framework. This framework >must be capable of supporting incremental additions of new functional >components, but should at the outset be capable of supporting the security >functions described . I'd prefer to omit the "but should at the outset..." phrase, as the area of agreement, concerning secure origination is not described in a standalone RPSEC document. >>As and when interdomain routing security requirements are >>completed within the RPSEC Working Group, these requirements will be >>defined within the SIDR framework as functional components of a secure >>interdomain routing system. >> >> The scope or work will include the definition of certification objects >>that can be used to support the distribution of authentication >>information. Both strict hierarchical and distributed non-hierarchical >>trust systems are intended to be supported within this framework. > >Q: Does the work involve revisiting RFC 3779 AS number/address range >certs, using these certs, or ignoring these certs and do something >completely different? I's my assumption that this work is a normative reference to the SIDR work. I've not heard anyone suggest redoing this work in a different way until your note above. >> The scope of work is limited to inter-domain router-to-router >>protocols only for both unicast and multicast systems. >> >> The SIDR working group is charged with the following tasks: >> >> - Document an extensible interdomain routing security architecture >> >> - Document the certification objects to be used by this secure >> routing framework > >"secure routing architecture", for consistency with the sentence above? yes >> - Document specific routing functionality modules with this > >s/with/within/? yes >> architecture designed to address specific secure routing >>requirements as they are determined by the RPSEC Working Group >> >>Goals and Milestones: >> >>April-06 Submit initial draft on inter-domain routing security >> architecture >> >>May-06 Submit initial draft on certificate objects to be used >> within this framework >-> "architecture"? >> >>May-06 Submit initial draft on securing origination of routing >> information >> >>Sept-06 Submit routing security architecture for publication as an >> Informational RFC >> >>Nov-06 Submit definition of certificate objectes to be used as a >> Proposed Standard >> >>Dec-06 Submit secure origination mechanism as a Proposed Standard > >Suggest using exactly the same words to describe the documents in each >milestone that refers to them. Saves confusion. > >> >>Jan-06 Evaluate progress, recharter with new goals or shutdown. > >No more comments.... thanks for these Geoff _______________________________________________ Sidr mailing list Sidr@ietf.org https://www1.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Sun Nov 27 15:26:22 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EgT6M-0002YK-6v; Sun, 27 Nov 2005 15:26:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EgT6K-0002We-KU for sidr@megatron.ietf.org; Sun, 27 Nov 2005 15:26:20 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24776 for ; Sun, 27 Nov 2005 15:25:36 -0500 (EST) Received: from eikenes.alvestrand.no ([158.38.152.233]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EgTQ3-0008Jo-QG for sidr@ietf.org; Sun, 27 Nov 2005 15:46:44 -0500 Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id AC0D625973A; Sun, 27 Nov 2005 21:25:32 +0100 (CET) Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 02540-07; Sun, 27 Nov 2005 21:25:29 +0100 (CET) Received: from [192.168.1.160] (163.80-203-220.nextgentel.com [80.203.220.163]) by eikenes.alvestrand.no (Postfix) with ESMTP id DCB83259737; Sun, 27 Nov 2005 21:25:28 +0100 (CET) Date: Sun, 27 Nov 2005 21:28:03 +0100 From: Harald Tveit Alvestrand To: Geoff Huston , sidr@ietf.org Subject: Re: [Sidr] initial draft of SIDR Charter Message-ID: <2F57CBABD34601081A75DAFB@svartdal.hjemme.alvestrand.no> In-Reply-To: <6.2.0.14.2.20051128070004.02b0b268@kahuna.telstra.net> References: <6.2.0.14.2.20051112025129.02b3bdf8@localhost> <6.2.0.14.2.20051112031331.044471f8@localhost> <6.2.0.14.2.20051126074145.0301c218@kahuna.telstra.net> <6.2.0.14.2.20051128070004.02b0b268@kahuna.telstra.net> X-Mailer: Mulberry/3.1.6 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Virus-Scanned: by amavisd-new at alvestrand.no X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Content-Transfer-Encoding: 7bit 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: , Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org --On mandag, november 28, 2005 07:19:00 +1100 Geoff Huston wrote: >> Q: should "a routed object" be "a routing information object" or "an >> object passed in a routing protocol"? To me, "a routed object" is a >> packet, and that doesn't seem to make sense.... > > > I thought about this and to me a "routed object" was the expression I was > searching for. Its a relatively minor thing I admit but I was looking to > describe the basic route object (the prefix) and distinguishing that from > the attributes that a routing system may permit to be associated with the > basic object. "an object passed in a routing protocol" is perhaps the > best equivalent phrase, but for a WG charter text that's getting to be a > bit of a mouthful isn't it! a "route object" would do it for me... but are you saying that you think "route object" means "prefix"? >>> The scope of work in the SIDR working group is to formulate an >>> extensible interdomain routing security architecture that is capable of >>> supporting incremental additions to a security framework for interdomain >>> routing. >> >> I got lost in that sentence.... what about: >> >> The scope of work in the SIDR working group is to formulate an >> extensible architecture for an interdomain routing security framework. >> This framework must be capable of supporting incremental additions of >> new functional components, but should at the outset be capable of >> supporting the security functions described . > > I'd prefer to omit the "but should at the outset..." phrase, as the area > of agreement, concerning secure origination is not described in a > standalone RPSEC document. no problem for me, but it seems strange to describe an initially-empty framework... >>> As and when interdomain routing security requirements are >>> completed within the RPSEC Working Group, these requirements will be >>> defined within the SIDR framework as functional components of a secure >>> interdomain routing system. >>> >>> The scope or work will include the definition of certification >>> objects that can be used to support the distribution of >>> authentication >>> information. Both strict hierarchical and distributed non-hierarchical >>> trust systems are intended to be supported within this framework. >> >> Q: Does the work involve revisiting RFC 3779 AS number/address range >> certs, using these certs, or ignoring these certs and do something >> completely different? > > > I's my assumption that this work is a normative reference to the SIDR > work. I've not heard anyone suggest redoing this work in a different way > until your note above. That seems like a Good Thing to me - should the language perhaps read The scope of work will include describing the use of certification objets for supporting the distribution of authentication information so that we avoid saying "defining objects" where we think that these are already defined? ("the scope or work" is, I assume, a typo) _______________________________________________ Sidr mailing list Sidr@ietf.org https://www1.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Sun Nov 27 15:52:07 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EgTVH-0006lX-Cw; Sun, 27 Nov 2005 15:52:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EgTVG-0006lS-Nh for sidr@megatron.ietf.org; Sun, 27 Nov 2005 15:52:06 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26749 for ; Sun, 27 Nov 2005 15:51:22 -0500 (EST) Received: from kahuna.telstra.net ([203.50.0.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EgTp0-0000kU-3A for sidr@ietf.org; Sun, 27 Nov 2005 16:12:30 -0500 Received: from gihm3.apnic.net (dhcp5.potaroo.net [203.10.60.5]) by kahuna.telstra.net (8.12.3/8.11.3) with ESMTP id jARKpqXt005449; Mon, 28 Nov 2005 07:51:53 +1100 (EST) (envelope-from gih@apnic.net) Message-Id: <6.2.0.14.2.20051128074620.02b03a48@kahuna.telstra.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14 Date: Mon, 28 Nov 2005 07:51:50 +1100 To: Harald Tveit Alvestrand , sidr@ietf.org From: Geoff Huston Subject: Re: [Sidr] initial draft of SIDR Charter In-Reply-To: <2F57CBABD34601081A75DAFB@svartdal.hjemme.alvestrand.no> References: <6.2.0.14.2.20051112025129.02b3bdf8@localhost> <6.2.0.14.2.20051112031331.044471f8@localhost> <6.2.0.14.2.20051126074145.0301c218@kahuna.telstra.net> <6.2.0.14.2.20051128070004.02b0b268@kahuna.telstra.net> <2F57CBABD34601081A75DAFB@svartdal.hjemme.alvestrand.no> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a 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: , Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org At 07:28 AM 28/11/2005, Harald Tveit Alvestrand wrote: >--On mandag, november 28, 2005 07:19:00 +1100 Geoff Huston >wrote: > >>>Q: should "a routed object" be "a routing information object" or "an >>>object passed in a routing protocol"? To me, "a routed object" is a >>>packet, and that doesn't seem to make sense.... >> >> >>I thought about this and to me a "routed object" was the expression I was >>searching for. Its a relatively minor thing I admit but I was looking to >>describe the basic route object (the prefix) and distinguishing that from >>the attributes that a routing system may permit to be associated with the >>basic object. "an object passed in a routing protocol" is perhaps the >>best equivalent phrase, but for a WG charter text that's getting to be a >>bit of a mouthful isn't it! > >a "route object" would do it for me... but are you saying that you think >"route object" means "prefix"? route object it is then I did imply that 'route object' is the 'primitive' and it is adorned with attributes. But I sugest that we are perhaps wandering in a direction that is not getting us close to closure on a charter text - so if 'route object' works for you, it also works for me! >>>> The scope of work in the SIDR working group is to formulate an >>>>extensible interdomain routing security architecture that is capable of >>>>supporting incremental additions to a security framework for interdomain >>>>routing. >>> >>>I got lost in that sentence.... what about: >>> >>>The scope of work in the SIDR working group is to formulate an >>>extensible architecture for an interdomain routing security framework. >>>This framework must be capable of supporting incremental additions of >>>new functional components, but should at the outset be capable of >>>supporting the security functions described . >> >>I'd prefer to omit the "but should at the outset..." phrase, as the area >>of agreement, concerning secure origination is not described in a >>standalone RPSEC document. > >no problem for me, but it seems strange to describe an initially-empty >framework... If the RPSEC WG managed to come to closure on their requirements document then we'd have a document to refer to. But until then there's no agreed document. The issue here is that RPEC has come to closure on origination, but remain unable to resolve the AS Path issues to a consensus text. >>>>As and when interdomain routing security requirements are >>>>completed within the RPSEC Working Group, these requirements will be >>>>defined within the SIDR framework as functional components of a secure >>>>interdomain routing system. >>>> >>>> The scope or work will include the definition of certification >>>> objects that can be used to support the distribution of >>>>authentication >>>>information. Both strict hierarchical and distributed non-hierarchical >>>>trust systems are intended to be supported within this framework. >>> >>>Q: Does the work involve revisiting RFC 3779 AS number/address range >>>certs, using these certs, or ignoring these certs and do something >>>completely different? >> >> >>I's my assumption that this work is a normative reference to the SIDR >>work. I've not heard anyone suggest redoing this work in a different way >>until your note above. > >That seems like a Good Thing to me - should the language perhaps read > > The scope of work will include describing the use of certification > objets for supporting the distribution of authentication information > >so that we avoid saying "defining objects" where we think that these are >already defined? >("the scope or work" is, I assume, a typo) > yep - good suggestion - thanks! Geoff _______________________________________________ Sidr mailing list Sidr@ietf.org https://www1.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Mon Nov 28 03:21:32 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EgeGS-0006N0-Sz; Mon, 28 Nov 2005 03:21:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EgeGR-0006LI-PO for sidr@megatron.ietf.org; Mon, 28 Nov 2005 03:21:31 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA28568 for ; Mon, 28 Nov 2005 03:20:47 -0500 (EST) Received: from kahuna.telstra.net ([203.50.0.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EgeaE-0003R6-LT for sidr@ietf.org; Mon, 28 Nov 2005 03:42:01 -0500 Received: from gihm3.apnic.net (dhcp5.potaroo.net [203.10.60.5]) by kahuna.telstra.net (8.12.3/8.11.3) with ESMTP id jAS8L7Xt014258 for ; Mon, 28 Nov 2005 19:21:07 +1100 (EST) (envelope-from gih@apnic.net) Message-Id: <6.2.0.14.2.20051128191945.02b75cb8@kahuna.telstra.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14 Date: Mon, 28 Nov 2005 19:20:55 +1100 To: sidr@ietf.org From: Geoff Huston In-Reply-To: <6.2.0.14.2.20051128074620.02b03a48@kahuna.telstra.net> References: <6.2.0.14.2.20051112025129.02b3bdf8@localhost> <6.2.0.14.2.20051112031331.044471f8@localhost> <6.2.0.14.2.20051126074145.0301c218@kahuna.telstra.net> <6.2.0.14.2.20051128070004.02b0b268@kahuna.telstra.net> <2F57CBABD34601081A75DAFB@svartdal.hjemme.alvestrand.no> <6.2.0.14.2.20051128074620.02b03a48@kahuna.telstra.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 Subject: [Sidr] V3 draft of SIDR Charter 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: , Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org (included Harald's suggestions in this version) Secure Inter-Domain Routing (sidr) Last Modified: 2005-11-28 (V3) Chair(s): TBD Routing Area Director(s): Bill Fenner Alex Zinin Routing Area Advisor: TBD Other Advisors: ? Security: TBD ? Routing: TBD Mailing Lists: General Discussion: sidr@ietf.org To Subscribe: sidr-request@ietf.org In Body: (un)subscribe Archive: http://www.ietf.org/mail-archive/web/sidr/index.html Description of Working Group: One of the areas of vulnerability for large scale Internet environments lies in the area of inter-domain routing. The basic security questions that can be posed regarding routing information is that of the validity of the address prefix being advertised, the validity of the originating Autonomous System Number, and the existence of an explicit permission from the address prefix holder to allow the prefix to be advertised from this origin. A related question concerns the level of trust than can be ascribed to attributes of a route object in terms of their authenticity, including consideration of the AS Path attribute.. The Routing Protocol Security Group (RPSEC) has been chartered to document the security requirements for routing systems, and, in particular, to produce a document on BGP security requirements. The scope of work in the SIDR working group is to formulate an extensible interdomain routing security architecture that is capable of supporting incremental additions to a security framework for interdomain routing. The scope of work in the SIDR working group is to formulate an extensible architecture for an interdomain routing security framework. This framework must be capable of supporting incremental additions of functional components. As and when interdomain routing security requirements are completed within the RPSEC Working Group, these requirements will be defined within the SIDR framework as functional components of a secure interdomain routing system. The scope of work will include describing the use of certification objects for supporting the distribution of authentication information. Both strict hierarchical and distributed non- hierarchical trust systems are intended to be supported within this framework. The scope of work is limited to inter-domain router-to-router protocols only, for both unicast and multicast systems. The SIDR working group is charged with the following tasks: - Document an extensible interdomain routing security architecture - Document the use of certification objects within this secure routing architecture - Document specific routing functionality modules within this architecture that are designed to address specific secure routing requirements as they are determined by the RPSEC Working Group Goals and Milestones: April-06 Submit initial draft on inter-domain routing security architecture May-06 Submit initial draft on certificate objects to be used within this architecture May-06 Submit initial draft on securing origination of routing information Sept-06 Submit routing security architecture for publication as an Informational RFC Nov-06 Submit description of use certificate objects by this architecture as an Informational RFC Dec-06 Submit secure origination mechanism as a Proposed Standard Jan-07 Evaluate progress, recharter with new goals or shutdown. _______________________________________________ Sidr mailing list Sidr@ietf.org https://www1.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Mon Nov 28 03:41:54 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EgeaA-0001fQ-G7; Mon, 28 Nov 2005 03:41:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Egea9-0001f2-St for sidr@megatron.ietf.org; Mon, 28 Nov 2005 03:41:53 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA00309 for ; Mon, 28 Nov 2005 03:41:09 -0500 (EST) Received: from sokol.elan.net ([216.151.192.200]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Egety-000459-Q8 for sidr@ietf.org; Mon, 28 Nov 2005 04:02:24 -0500 Received: from sokol.elan.net (sokol [127.0.0.1]) by sokol.elan.net (8.13.1/8.13.1) with ESMTP id jAS8fV06031905; Mon, 28 Nov 2005 00:41:31 -0800 Received: from localhost (william@localhost) by sokol.elan.net (8.13.1/8.13.1/Submit) with ESMTP id jAS8fV0Q031902; Mon, 28 Nov 2005 00:41:31 -0800 X-Authentication-Warning: sokol.elan.net: william owned process doing -bs Date: Mon, 28 Nov 2005 00:41:30 -0800 (PST) From: "william(at)elan.net" To: Geoff Huston Subject: Re: [Sidr] V3 draft of SIDR Charter In-Reply-To: <6.2.0.14.2.20051128191945.02b75cb8@kahuna.telstra.net> Message-ID: References: <6.2.0.14.2.20051112025129.02b3bdf8@localhost> <6.2.0.14.2.20051112031331.044471f8@localhost> <6.2.0.14.2.20051126074145.0301c218@kahuna.telstra.net> <6.2.0.14.2.20051128070004.02b0b268@kahuna.telstra.net> <2F57CBABD34601081A75DAFB@svartdal.hjemme.alvestrand.no> <6.2.0.14.2.20051128074620.02b03a48@kahuna.telstra.net> <6.2.0.14.2.20051128191945.02b75cb8@kahuna.telstra.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb 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: , Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org I still think you need to specify that work will include information on how to publish certification objects. Either have this as separate point below or addition to existing one. > The SIDR working group is charged with the following tasks: > > - Document an extensible interdomain routing security architecture > > - Document the use of certification objects within this secure > routing architecture Possibly change to: - Document use and publication of certification objects within secure interdomain routing architecture > - Document specific routing functionality modules within this > architecture that are designed to address specific secure routing > requirements as they are determined by the RPSEC Working Group > > Goals and Milestones: > > April-06 Submit initial draft on inter-domain routing security > architecture > > May-06 Submit initial draft on certificate objects to be used > within this architecture > > May-06 Submit initial draft on securing origination of routing > information > > Sept-06 Submit routing security architecture for publication as an > Informational RFC > > Nov-06 Submit description of use certificate objects by this > architecture as an Informational RFC > > Dec-06 Submit secure origination mechanism as a Proposed Standard > > Jan-07 Evaluate progress, recharter with new goals or shutdown. _______________________________________________ Sidr mailing list Sidr@ietf.org https://www1.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Mon Nov 28 04:37:45 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EgfSD-0005Ab-Nq; Mon, 28 Nov 2005 04:37:45 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EgfSC-0005AW-7w for sidr@megatron.ietf.org; Mon, 28 Nov 2005 04:37:44 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA06270 for ; Mon, 28 Nov 2005 04:36:59 -0500 (EST) Received: from kahuna.telstra.net ([203.50.0.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Egfm1-00060o-Ha for sidr@ietf.org; Mon, 28 Nov 2005 04:58:15 -0500 Received: from gihm3.apnic.net (dhcp5.potaroo.net [203.10.60.5]) by kahuna.telstra.net (8.12.3/8.11.3) with ESMTP id jAS9adXt015246; Mon, 28 Nov 2005 20:36:40 +1100 (EST) (envelope-from gih@apnic.net) Message-Id: <6.2.0.14.2.20051128203425.02acf120@kahuna.telstra.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14 Date: Mon, 28 Nov 2005 20:36:23 +1100 To: "william(at)elan.net" From: Geoff Huston Subject: Re: [Sidr] V3 draft of SIDR Charter In-Reply-To: References: <6.2.0.14.2.20051112025129.02b3bdf8@localhost> <6.2.0.14.2.20051112031331.044471f8@localhost> <6.2.0.14.2.20051126074145.0301c218@kahuna.telstra.net> <6.2.0.14.2.20051128070004.02b0b268@kahuna.telstra.net> <2F57CBABD34601081A75DAFB@svartdal.hjemme.alvestrand.no> <6.2.0.14.2.20051128074620.02b03a48@kahuna.telstra.net> <6.2.0.14.2.20051128191945.02b75cb8@kahuna.telstra.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a 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: , Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org At 07:41 PM 28/11/2005, william(at)elan.net wrote: >I still think you need to specify that work will include information >on how to publish certification objects. Either have this as separate >point below or addition to existing one. > >> The SIDR working group is charged with the following tasks: >> >> - Document an extensible interdomain routing security architecture >> >> - Document the use of certification objects within this secure >> routing architecture > >Possibly change to: > > - Document use and publication of certification objects within > secure interdomain routing architecture Now one way or another we are talking about certificate repositories. What did you have in mind to specify here above and beyond normal repository operation? thanks, Geoff _______________________________________________ Sidr mailing list Sidr@ietf.org https://www1.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Mon Nov 28 07:08:43 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EghoJ-0008G8-A7; Mon, 28 Nov 2005 07:08:43 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EghoG-0008G0-Ut for sidr@megatron.ietf.org; Mon, 28 Nov 2005 07:08:41 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA24345 for ; Mon, 28 Nov 2005 07:07:57 -0500 (EST) Received: from sokol.elan.net ([216.151.192.200]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Egi87-0002kU-Lf for sidr@ietf.org; Mon, 28 Nov 2005 07:29:13 -0500 Received: from sokol.elan.net (sokol [127.0.0.1]) by sokol.elan.net (8.13.1/8.13.1) with ESMTP id jASC8PSa002246; Mon, 28 Nov 2005 04:08:26 -0800 Received: from localhost (william@localhost) by sokol.elan.net (8.13.1/8.13.1/Submit) with ESMTP id jASC8Gs5002237; Mon, 28 Nov 2005 04:08:25 -0800 X-Authentication-Warning: sokol.elan.net: william owned process doing -bs Date: Mon, 28 Nov 2005 04:08:16 -0800 (PST) From: "william(at)elan.net" To: Geoff Huston Subject: Re: [Sidr] V3 draft of SIDR Charter In-Reply-To: <6.2.0.14.2.20051128203425.02acf120@kahuna.telstra.net> Message-ID: References: <6.2.0.14.2.20051112025129.02b3bdf8@localhost> <6.2.0.14.2.20051112031331.044471f8@localhost> <6.2.0.14.2.20051126074145.0301c218@kahuna.telstra.net> <6.2.0.14.2.20051128070004.02b0b268@kahuna.telstra.net> <2F57CBABD34601081A75DAFB@svartdal.hjemme.alvestrand.no> <6.2.0.14.2.20051128074620.02b03a48@kahuna.telstra.net> <6.2.0.14.2.20051128191945.02b75cb8@kahuna.telstra.net> <6.2.0.14.2.20051128203425.02acf120@kahuna.telstra.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 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: , Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org On Mon, 28 Nov 2005, Geoff Huston wrote: > At 07:41 PM 28/11/2005, william(at)elan.net wrote: > >> I still think you need to specify that work will include information >> on how to publish certification objects. Either have this as separate >> point below or addition to existing one. >> >>> The SIDR working group is charged with the following tasks: >>> >>> - Document an extensible interdomain routing security architecture >>> >>> - Document the use of certification objects within this secure >>> routing architecture >> >> Possibly change to: >> >> - Document use and publication of certification objects within >> secure interdomain routing architecture > > Now one way or another we are talking about certificate repositories. What > did you have in mind to specify here above and beyond normal repository > operation? That is pretty much it. I do not see it clearly spelled out in the charter that we would work on specifying access to (or at least linking rules for specifying PKI repository) PKI repositories and format of the data that is to be retrieved. There are actually quite a number of ways to run a repository or certificate verification service that have been developed (plus add related issues and formats for publication of CRL data as well), these are just a few these: SCVP (draft-ietf-pkix-scvp-21.txt) DVCS (RFC3029) OSCP (RFC2560) PKIXREP locator (draft-ietf-pkix-pkixrep-04.txt) HTTP Certificate Store (draft-ietf-pkix-certstore-http-09.txt) LDAP Certificate server PGP (HTTP based) key & certificate server etc. And it may well be that none of the above will work because one of the key issues is that BGP (like DNS) is a base protocol so one can not fully rely on some "higher" application protocol as part of BGP route establishment (see also SBGP & soBGP and compare how they propose to store cert data). I think info on considerations and issues involved in setting up and running repositories that would be used for BGP security should be considered and documented as well at least in some way. Also the format for certificates and any necessary extensions are all in scope (i.e. if we decide we need extension of RFC3779) and this I also see as publication-related issue. -- William Leibzon Elan Networks william@elan.net _______________________________________________ Sidr mailing list Sidr@ietf.org https://www1.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Mon Nov 28 18:41:42 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Egscw-0008UD-QO; Mon, 28 Nov 2005 18:41:42 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Egscv-0008Rz-8H for sidr@megatron.ietf.org; Mon, 28 Nov 2005 18:41:41 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09645 for ; Mon, 28 Nov 2005 18:40:55 -0500 (EST) Received: from kahuna.telstra.net ([203.50.0.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Egswr-0001fY-Id for sidr@ietf.org; Mon, 28 Nov 2005 19:02:19 -0500 Received: from gihm3.apnic.net (rsdhcp5.telstra.net [203.50.0.197]) by kahuna.telstra.net (8.12.3/8.11.3) with ESMTP id jASNedXt008874; Tue, 29 Nov 2005 10:40:39 +1100 (EST) (envelope-from gih@apnic.net) Message-Id: <6.2.0.14.2.20051129103756.02884288@kahuna.telstra.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14 Date: Tue, 29 Nov 2005 10:40:40 +1100 To: "william(at)elan.net" From: Geoff Huston Subject: Re: [Sidr] V3 draft of SIDR Charter In-Reply-To: References: <6.2.0.14.2.20051112025129.02b3bdf8@localhost> <6.2.0.14.2.20051112031331.044471f8@localhost> <6.2.0.14.2.20051126074145.0301c218@kahuna.telstra.net> <6.2.0.14.2.20051128070004.02b0b268@kahuna.telstra.net> <2F57CBABD34601081A75DAFB@svartdal.hjemme.alvestrand.no> <6.2.0.14.2.20051128074620.02b03a48@kahuna.telstra.net> <6.2.0.14.2.20051128191945.02b75cb8@kahuna.telstra.net> <6.2.0.14.2.20051128203425.02acf120@kahuna.telstra.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 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: , Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org At 11:08 PM 28/11/2005, william(at)elan.net wrote: >On Mon, 28 Nov 2005, Geoff Huston wrote: > >>At 07:41 PM 28/11/2005, william(at)elan.net wrote: >> >>>I still think you need to specify that work will include information >>>on how to publish certification objects. Either have this as separate >>>point below or addition to existing one. >>> >>>> The SIDR working group is charged with the following tasks: >>>> - Document an extensible interdomain routing security architecture >>>> - Document the use of certification objects within this secure >>>> routing architecture >>>Possibly change to: >>> - Document use and publication of certification objects within >>> secure interdomain routing architecture >> >>Now one way or another we are talking about certificate repositories. >>What did you have in mind to specify here above and beyond normal >>repository operation? > >That is pretty much it. I do not see it clearly spelled out in the >charter that we would work on specifying access to (or at least linking >rules for specifying PKI repository) PKI repositories and format of the >data that is to be retrieved. There are actually quite a number of ways >to run a repository or certificate verification service that have been >developed (plus add related issues and formats for publication of CRL >data as well), these are just a few these: > SCVP (draft-ietf-pkix-scvp-21.txt) > DVCS (RFC3029) > OSCP (RFC2560) > PKIXREP locator (draft-ietf-pkix-pkixrep-04.txt) > HTTP Certificate Store (draft-ietf-pkix-certstore-http-09.txt) > LDAP Certificate server > PGP (HTTP based) key & certificate server > etc. >And it may well be that none of the above will work because one of the key >issues is that BGP (like DNS) is a base protocol so one can not fully rely >on some "higher" application protocol as part of BGP route establishment >(see also SBGP & soBGP and compare how they propose to store cert data). > >I think info on considerations and issues involved in setting up and >running repositories that would be used for BGP security should be >considered and documented as well at least in some way. > >Also the format for certificates and any necessary extensions are all in >scope (i.e. if we decide we need extension of RFC3779) and this >I also see as publication-related issue. I am unsure how nmuch of this belongs in a SIDR charter and how much belongs in a security area as a work item and how much is beyond the scope of standards-related activities. For a charter I'm personally more comfortable with the more general phrase of " Document the use of certification objects within this secure routing architecture" and not specifying the form of repository nor the form of repository access as charter work items at this point in time. regards, Geoff _______________________________________________ Sidr mailing list Sidr@ietf.org https://www1.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Mon Nov 28 18:58:09 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Egssr-0000pQ-V6; Mon, 28 Nov 2005 18:58:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Egssp-0000nh-Is for sidr@megatron.ietf.org; Mon, 28 Nov 2005 18:58:09 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11793 for ; Mon, 28 Nov 2005 18:57:24 -0500 (EST) Received: from sokol.elan.net ([216.151.192.200]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EgtCm-0002Pm-Lk for sidr@ietf.org; Mon, 28 Nov 2005 19:18:46 -0500 Received: from sokol.elan.net (sokol [127.0.0.1]) by sokol.elan.net (8.13.1/8.13.1) with ESMTP id jASNvrCU015714; Mon, 28 Nov 2005 15:57:53 -0800 Received: from localhost (william@localhost) by sokol.elan.net (8.13.1/8.13.1/Submit) with ESMTP id jASNvrd0015711; Mon, 28 Nov 2005 15:57:53 -0800 X-Authentication-Warning: sokol.elan.net: william owned process doing -bs Date: Mon, 28 Nov 2005 15:57:53 -0800 (PST) From: "william(at)elan.net" To: Geoff Huston Subject: Re: [Sidr] V3 draft of SIDR Charter In-Reply-To: <6.2.0.14.2.20051129103756.02884288@kahuna.telstra.net> Message-ID: References: <6.2.0.14.2.20051112025129.02b3bdf8@localhost> <6.2.0.14.2.20051112031331.044471f8@localhost> <6.2.0.14.2.20051126074145.0301c218@kahuna.telstra.net> <6.2.0.14.2.20051128070004.02b0b268@kahuna.telstra.net> <2F57CBABD34601081A75DAFB@svartdal.hjemme.alvestrand.no> <6.2.0.14.2.20051128074620.02b03a48@kahuna.telstra.net> <6.2.0.14.2.20051128191945.02b75cb8@kahuna.telstra.net> <6.2.0.14.2.20051128203425.02acf120@kahuna.telstra.net> <6.2.0.14.2.20051129103756.02884288@kahuna.telstra.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 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: , Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org On Tue, 29 Nov 2005, Geoff Huston wrote: > At 11:08 PM 28/11/2005, william(at)elan.net wrote: >> That is pretty much it. I do not see it clearly spelled out in the >> charter that we would work on specifying access to (or at least linking >> rules for specifying PKI repository) PKI repositories and format of the >> data that is to be retrieved. There are actually quite a number of ways >> to run a repository or certificate verification service that have been >> developed (plus add related issues and formats for publication of CRL >> data as well), these are just a few these: >> SCVP (draft-ietf-pkix-scvp-21.txt) >> DVCS (RFC3029) >> OSCP (RFC2560) >> PKIXREP locator (draft-ietf-pkix-pkixrep-04.txt) >> HTTP Certificate Store (draft-ietf-pkix-certstore-http-09.txt) >> LDAP Certificate server >> PGP (HTTP based) key & certificate server >> etc. >> And it may well be that none of the above will work because one of the key >> issues is that BGP (like DNS) is a base protocol so one can not fully rely >> on some "higher" application protocol as part of BGP route establishment >> (see also SBGP & soBGP and compare how they propose to store cert data). >> >> I think info on considerations and issues involved in setting up and >> running repositories that would be used for BGP security should be >> considered and documented as well at least in some way. >> >> Also the format for certificates and any necessary extensions are all in >> scope (i.e. if we decide we need extension of RFC3779) and this >> I also see as publication-related issue. > > I am unsure how nmuch of this belongs in a SIDR charter and how much belongs > in a security area as a work item and how much is beyond the scope of As I said before I view SIDR work as something that is more security centric then routing but like others I personally dont care that much if its officially under security or under routing area. But in general IETF usually has security area WGs work on security additions to other protocols (when its whole WG rather then one document in WG that is mostly working on something else). > standards-related activities. For a charter I'm personally more comfortable > with the more general phrase of > " Document the use of certification objects within this secure routing > architecture" > > and not specifying the form of repository nor the form of repository access > as charter work items at this point in time. Strongly disagree. You can not attempt global deployment unless you deal with repository access issues. -- William Leibzon Elan Networks william@elan.net _______________________________________________ Sidr mailing list Sidr@ietf.org https://www1.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Mon Nov 28 23:57:46 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EgxYo-0006rL-Gu; Mon, 28 Nov 2005 23:57:46 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EgxYl-0006r7-Ba for sidr@megatron.ietf.org; Mon, 28 Nov 2005 23:57:44 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA10175 for ; Mon, 28 Nov 2005 23:56:57 -0500 (EST) Received: from kahuna.telstra.net ([203.50.0.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Egxsj-0003F8-Eo for sidr@ietf.org; Tue, 29 Nov 2005 00:18:24 -0500 Received: from gihm3.apnic.net (rsdhcp5.telstra.net [203.50.0.197]) by kahuna.telstra.net (8.12.3/8.11.3) with ESMTP id jAT4v7Xt018711; Tue, 29 Nov 2005 15:57:08 +1100 (EST) (envelope-from gih@apnic.net) Message-Id: <6.2.0.14.2.20051129155139.02adab00@kahuna.telstra.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14 Date: Tue, 29 Nov 2005 15:56:50 +1100 To: "william(at)elan.net" From: Geoff Huston Subject: Re: [Sidr] V3 draft of SIDR Charter In-Reply-To: References: <6.2.0.14.2.20051112025129.02b3bdf8@localhost> <6.2.0.14.2.20051112031331.044471f8@localhost> <6.2.0.14.2.20051126074145.0301c218@kahuna.telstra.net> <6.2.0.14.2.20051128070004.02b0b268@kahuna.telstra.net> <2F57CBABD34601081A75DAFB@svartdal.hjemme.alvestrand.no> <6.2.0.14.2.20051128074620.02b03a48@kahuna.telstra.net> <6.2.0.14.2.20051128191945.02b75cb8@kahuna.telstra.net> <6.2.0.14.2.20051128203425.02acf120@kahuna.telstra.net> <6.2.0.14.2.20051129103756.02884288@kahuna.telstra.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 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: , Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org At 10:57 AM 29/11/2005, william(at)elan.net wrote: >On Tue, 29 Nov 2005, Geoff Huston wrote: > >>At 11:08 PM 28/11/2005, william(at)elan.net wrote: >>>That is pretty much it. I do not see it clearly spelled out in the >>>charter that we would work on specifying access to (or at least linking >>>rules for specifying PKI repository) PKI repositories and format of the >>>data that is to be retrieved. There are actually quite a number of ways >>>to run a repository or certificate verification service that have been >>>developed (plus add related issues and formats for publication of CRL >>>data as well), these are just a few these: >>> SCVP (draft-ietf-pkix-scvp-21.txt) >>> DVCS (RFC3029) >>> OSCP (RFC2560) >>> PKIXREP locator (draft-ietf-pkix-pkixrep-04.txt) >>> HTTP Certificate Store (draft-ietf-pkix-certstore-http-09.txt) >>> LDAP Certificate server >>> PGP (HTTP based) key & certificate server >>> etc. >>>And it may well be that none of the above will work because one of the key >>>issues is that BGP (like DNS) is a base protocol so one can not fully >>>rely on some "higher" application protocol as part of BGP route establishment >>>(see also SBGP & soBGP and compare how they propose to store cert data). >>>I think info on considerations and issues involved in setting up and >>>running repositories that would be used for BGP security should be >>>considered and documented as well at least in some way. >>>Also the format for certificates and any necessary extensions are all in >>>scope (i.e. if we decide we need extension of RFC3779) and this >>>I also see as publication-related issue. >> >>I am unsure how nmuch of this belongs in a SIDR charter and how much >>belongs in a security area as a work item and how much is beyond the scope of > >As I said before I view SIDR work as something that is more security >centric then routing but like others I personally dont care that much >if its officially under security or under routing area. But in general >IETF usually has security area WGs work on security additions to other >protocols (when its whole WG rather then one document in WG that is >mostly working on something else). > >>standards-related activities. For a charter I'm personally more >>comfortable with the more general phrase of > >>" Document the use of certification objects within this secure routing >>architecture" >> >>and not specifying the form of repository nor the form of repository >>access as charter work items at this point in time. > >Strongly disagree. You can not attempt global deployment unless you deal >with repository access issues. This is an effort at creating a set of techology standards, not a specific deployment specification for a particular networked environment. Given the diversity of potential deployment scenarios across various forms of Internet environments I think that some division of the activity is entirely appropriate and necessary, and the generation of deployment profiles may well be an outcome of such a division of effort - but from the point of view of specification of technology standards and the charter for such an activity, I believe it to be appropriate to will pass on this draft charter to the ADs with the wording as proposed above. Geoff _______________________________________________ Sidr mailing list Sidr@ietf.org https://www1.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Tue Nov 29 00:03:46 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Egxec-00040y-P2; Tue, 29 Nov 2005 00:03:46 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Egxeb-00040t-I7 for sidr@megatron.ietf.org; Tue, 29 Nov 2005 00:03:45 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA11047 for ; Tue, 29 Nov 2005 00:03:00 -0500 (EST) Received: from kahuna.telstra.net ([203.50.0.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Egxya-0003Vv-P0 for sidr@ietf.org; Tue, 29 Nov 2005 00:24:26 -0500 Received: from gihm3.apnic.net (rsdhcp5.telstra.net [203.50.0.197]) by kahuna.telstra.net (8.12.3/8.11.3) with ESMTP id jAT53VXt019021; Tue, 29 Nov 2005 16:03:31 +1100 (EST) (envelope-from gih@apnic.net) Message-Id: <6.2.0.14.2.20051129155729.02b00950@kahuna.telstra.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14 Date: Tue, 29 Nov 2005 16:03:14 +1100 To: Alex Zinin , Bill Fenner From: Geoff Huston Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Spam-Score: 0.0 (/) X-Scan-Signature: 6d95a152022472c7d6cdf886a0424dc6 Cc: sidr@ietf.org Subject: [Sidr] DRAFT SIDR Charter 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: , Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org Alex, Bill, I recall at the NOF that you mentioned generating a draft charter for SIDR by the 28th November. AS its (just) still the 28th at least somewhere in the world, here's what's been drafted to date. The residual area of discussion concerns specifying the form of certificate repository and the form(s) of repository access, where one view is that these should be within the chartered activity for this working group and another view is that the potential deployment scenarios are sufficiently broad such that a single profile of certificate repository structure and access makes little sense in terms of a base technology standard. In any case here's the draft charter for your consideration thanks, Geoff ----------------------- Secure Inter-Domain Routing (sidr) Last Modified: 2005-11-28 (V4) Chair(s): TBD Routing Area Director(s): Bill Fenner Alex Zinin Routing Area Advisor: TBD Other Advisors: ? Security: TBD ? Routing: TBD Mailing Lists: General Discussion: sidr@ietf.org To Subscribe: sidr-request@ietf.org In Body: (un)subscribe Archive: http://www.ietf.org/mail-archive/web/sidr/index.html Description of Working Group: One of the areas of vulnerability for large scale Internet environments lies in the area of inter-domain routing. The basic security questions that can be posed regarding routing information is that of the validity of the address prefix being advertised, the validity of the originating Autonomous System Number, and the existence of an explicit permission from the address prefix holder to allow the prefix to be advertised from this origin. A related question concerns the level of trust than can be ascribed to attributes of a route object in terms of their authenticity, including consideration of the AS Path attribute.. The Routing Protocol Security Group (RPSEC) has been chartered to document the security requirements for routing systems, and, in particular, to produce a document on BGP security requirements. The scope of work in the SIDR working group is to formulate an extensible architecture for an interdomain routing security framework. This framework must be capable of supporting incremental additions of functional components. As and when interdomain routing security requirements are completed within the RPSEC Working Group, these requirements will be defined within the SIDR framework as functional components of a secure interdomain routing system. The scope of work will include describing the use of certification objects for supporting the distribution of authentication information. Both strict hierarchical and distributed non- hierarchical trust systems are intended to be supported within this framework. The scope of work is limited to inter-domain router-to-router protocols only, for both unicast and multicast systems. The SIDR working group is charged with the following tasks: - Document an extensible interdomain routing security architecture - Document the use of certification objects within this secure routing architecture - Document specific routing functionality modules within this architecture that are designed to address specific secure routing requirements as they are determined by the RPSEC Working Group Goals and Milestones: April-06 Submit initial draft on inter-domain routing security architecture May-06 Submit initial draft on certificate objects to be used within this architecture May-06 Submit initial draft on securing origination of routing information Sept-06 Submit routing security architecture for publication as an Informational RFC Nov-06 Submit description of use certificate objects by this architecture as an Informational RFC Dec-06 Submit secure origination mechanism as a Proposed Standard Jan-07 Evaluate progress, recharter with new goals or shutdown. _______________________________________________ Sidr mailing list Sidr@ietf.org https://www1.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Tue Nov 29 01:03:03 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EgyZz-0001Fw-8A; Tue, 29 Nov 2005 01:03:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EgyZx-0001Fo-4A for sidr@megatron.ietf.org; Tue, 29 Nov 2005 01:03:01 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA16920 for ; Tue, 29 Nov 2005 01:02:15 -0500 (EST) Received: from postman.ripe.net ([193.0.0.199]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Egytt-0005JR-DV for sidr@ietf.org; Tue, 29 Nov 2005 01:23:42 -0500 Received: by postman.ripe.net (Postfix, from userid 4008) id 4372E24DF1; Tue, 29 Nov 2005 07:02:41 +0100 (CET) Received: from cod.ripe.net (cod.ripe.net [193.0.1.202]) by postman.ripe.net (Postfix) with ESMTP id 57DC824DA0; Tue, 29 Nov 2005 07:02:40 +0100 (CET) Received: from Geir.ripe.net (cow.ripe.net [193.0.1.239]) by cod.ripe.net (Postfix) with ESMTP id 2A817726A3; Tue, 29 Nov 2005 07:02:40 +0100 (CET) Message-Id: <6.2.3.4.2.20051128172253.02cea8e0@localhost> X-Mailer: QUALCOMM Windows Eudora Version 6.2.3.4 Date: Mon, 28 Nov 2005 17:34:10 +0100 To: Geoff Huston , sidr@ietf.org From: Henk Uijterwaal Subject: Re: [Sidr] V3 draft of SIDR Charter In-Reply-To: <6.2.0.14.2.20051128191945.02b75cb8@kahuna.telstra.net> References: <6.2.0.14.2.20051112025129.02b3bdf8@localhost> <6.2.0.14.2.20051112031331.044471f8@localhost> <6.2.0.14.2.20051126074145.0301c218@kahuna.telstra.net> <6.2.0.14.2.20051128070004.02b0b268@kahuna.telstra.net> <2F57CBABD34601081A75DAFB@svartdal.hjemme.alvestrand.no> <6.2.0.14.2.20051128074620.02b03a48@kahuna.telstra.net> <6.2.0.14.2.20051128191945.02b75cb8@kahuna.telstra.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-RIPE-Spam-Tests: ALL_TRUSTED,BAYES_00,DATE_IN_PAST_12_24 X-RIPE-Spam-Status: N 0.000000 / -5.2 X-RIPE-Signature: 7ef4eef7febf8c120aee81ac8de92fdb X-Spam-Score: 0.4 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 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: , Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org At 09:20 28/11/2005, Geoff Huston wrote: >Description of Working Group: > > One of the areas of vulnerability for large scale Internet > environments lies in the area of inter-domain routing. [...] I like the charter as it is, but would add two tasks: 1. Whatever this group builds, will have to be deployed by operators. This group should explicitly ask operators if the proposed solutions can be easily implemented against acceptable costs (for them). Any solution that fails this requirement, won't be deployed. Work to define it is essentially lost. 2. The group should liaise with other efforts in this area. In the US, DHS is active in this field, there might be more. We need a solution that is acceptable to all parties in this field. 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 ------------------------------------------------------------------------------ Look here junior, don't you be so happy. And for Heaven's sake, don't you be so sad. (Tom Verlaine) _______________________________________________ Sidr mailing list Sidr@ietf.org https://www1.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Tue Nov 29 01:14:50 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EgylO-0007wU-85; Tue, 29 Nov 2005 01:14:50 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EgylM-0007wO-Nk for sidr@megatron.ietf.org; Tue, 29 Nov 2005 01:14:48 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA18076 for ; Tue, 29 Nov 2005 01:14:03 -0500 (EST) Received: from sokol.elan.net ([216.151.192.200]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Egz5M-0005gT-3I for sidr@ietf.org; Tue, 29 Nov 2005 01:35:30 -0500 Received: from sokol.elan.net (sokol [127.0.0.1]) by sokol.elan.net (8.13.1/8.13.1) with ESMTP id jAT6EUXm021903; Mon, 28 Nov 2005 22:14:31 -0800 Received: from localhost (william@localhost) by sokol.elan.net (8.13.1/8.13.1/Submit) with ESMTP id jAT6EUHZ021900; Mon, 28 Nov 2005 22:14:30 -0800 X-Authentication-Warning: sokol.elan.net: william owned process doing -bs Date: Mon, 28 Nov 2005 22:14:30 -0800 (PST) From: "william(at)elan.net" To: Geoff Huston Subject: Re: [Sidr] V3 draft of SIDR Charter In-Reply-To: <6.2.0.14.2.20051129155139.02adab00@kahuna.telstra.net> Message-ID: References: <6.2.0.14.2.20051112025129.02b3bdf8@localhost> <6.2.0.14.2.20051112031331.044471f8@localhost> <6.2.0.14.2.20051126074145.0301c218@kahuna.telstra.net> <6.2.0.14.2.20051128070004.02b0b268@kahuna.telstra.net> <2F57CBABD34601081A75DAFB@svartdal.hjemme.alvestrand.no> <6.2.0.14.2.20051128074620.02b03a48@kahuna.telstra.net> <6.2.0.14.2.20051128191945.02b75cb8@kahuna.telstra.net> <6.2.0.14.2.20051128203425.02acf120@kahuna.telstra.net> <6.2.0.14.2.20051129103756.02884288@kahuna.telstra.net> <6.2.0.14.2.20051129155139.02adab00@kahuna.telstra.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 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: , Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org On Tue, 29 Nov 2005, Geoff Huston wrote: >>> " Document the use of certification objects within this secure routing >>> architecture" >>> >>> and not specifying the form of repository nor the form of repository >>> access as charter work items at this point in time. >> >> Strongly disagree. You can not attempt global deployment unless you deal >> with repository access issues. > > This is an effort at creating a set of techology standards, not a specific > deployment specification for a particular networked environment. How many BGP networking environments do you know (especially those that have "trust issues" and need security as far as who can can announce what ip routes by what ASNs)? This is not OSPF or ISIS where each company has its own independent network that it configures the way it wants and can use various scenarios on how to run it. BGP use is almost entirely used as primary routing protocol for one very large network we call Internet (yes, there are couple organizations that use BGP in their labs independent of the global internet, but I do not believe such use is of serious matter for this security work). -- William Leibzon Elan Networks william@elan.net _______________________________________________ Sidr mailing list Sidr@ietf.org https://www1.ietf.org/mailman/listinfo/sidr From sidr-bounces@ietf.org Tue Nov 29 01:15:56 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EgymS-00086B-IC; Tue, 29 Nov 2005 01:15:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EgymQ-000866-PB for sidr@megatron.ietf.org; Tue, 29 Nov 2005 01:15:55 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA18210 for ; Tue, 29 Nov 2005 01:15:09 -0500 (EST) Received: from kahuna.telstra.net ([203.50.0.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Egz6N-0005gu-Rk for sidr@ietf.org; Tue, 29 Nov 2005 01:36:33 -0500 Received: from gihm3.apnic.net (rsdhcp5.telstra.net [203.50.0.197]) by kahuna.telstra.net (8.12.3/8.11.3) with ESMTP id jAT6F9Xt020526; Tue, 29 Nov 2005 17:15:09 +1100 (EST) (envelope-from gih@apnic.net) Message-Id: <6.2.0.14.2.20051129171242.02b13e58@kahuna.telstra.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14 Date: Tue, 29 Nov 2005 17:13:45 +1100 To: Henk Uijterwaal , sidr@ietf.org From: Geoff Huston Subject: Re: [Sidr] V3 draft of SIDR Charter In-Reply-To: <6.2.3.4.2.20051128172253.02cea8e0@localhost> References: <6.2.0.14.2.20051112025129.02b3bdf8@localhost> <6.2.0.14.2.20051112031331.044471f8@localhost> <6.2.0.14.2.20051126074145.0301c218@kahuna.telstra.net> <6.2.0.14.2.20051128070004.02b0b268@kahuna.telstra.net> <2F57CBABD34601081A75DAFB@svartdal.hjemme.alvestrand.no> <6.2.0.14.2.20051128074620.02b03a48@kahuna.telstra.net> <6.2.0.14.2.20051128191945.02b75cb8@kahuna.telstra.net> <6.2.3.4.2.20051128172253.02cea8e0@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb 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: , Sender: sidr-bounces@ietf.org Errors-To: sidr-bounces@ietf.org Yes, they are useful (and necessary) tasks. Geoff At 03:34 AM 29/11/2005, Henk Uijterwaal wrote: >At 09:20 28/11/2005, Geoff Huston wrote: > >>Description of Working Group: >> >> One of the areas of vulnerability for large scale Internet >> environments lies in the area of inter-domain routing. [...] > >I like the charter as it is, but would add two tasks: > >1. Whatever this group builds, will have to be deployed by operators. > This group should explicitly ask operators if the proposed solutions > can be easily implemented against acceptable costs (for them). Any > solution that fails this requirement, won't be deployed. Work > to define it is essentially lost. > >2. The group should liaise with other efforts in this area. In the US, > DHS is active in this field, there might be more. We need a solution > that is acceptable to all parties in this field. > >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 >------------------------------------------------------------------------------ > >Look here junior, don't you be so happy. >And for Heaven's sake, don't you be so sad. (Tom Verlaine) _______________________________________________ Sidr mailing list Sidr@ietf.org https://www1.ietf.org/mailman/listinfo/sidr